Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose

  • To: "Naresh" <ajwaninaresh at gmail dot com>
  • Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
  • From: "Terence Zhang YH" <zhangyinghao at cnnic dot cn>
  • Date: Wed, 18 Aug 2010 11:46:58 +0800
  • Cc: sig-policy at lists dot apnic dot net
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <4C692702.8070507@cisco.com><482010507.00791@cnnic.cn><482012544.30171@cnnic.cn> <482014256.28633@cnnic.cn> <482015457.27110@cnnic.cn> <482028510.30556@cnnic.cn>
    • Then the question may be 'how many is too many?'
      
      Regards
      Terence
      
      
      ----- Original Message ----- 
      From: "Naresh" <ajwaninaresh at gmail dot com>
      To: "'Terence Zhang YH'" <zhangyinghao at cnnic dot cn>; "'Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"'" <fujisaki at syce dot net>
      Cc: <pfs at cisco dot com>; <sig-policy at lists dot apnic dot net>
      Sent: Tuesday, August 17, 2010 2:57 PM
      Subject: RE: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
      
      
      > Too many Technology complexities may deter the objective.
      > 
      > Regards
      > 
      > -----Original Message-----
      > From: sig-policy-bounces at lists dot apnic dot net
      > [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Terence Zhang YH
      > Sent: Tuesday, August 17, 2010 8:54 AM
      > To: Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"
      > Cc: pfs at cisco dot com; sig-policy at lists dot apnic dot net
      > Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
      > purposes
      > 
      > Hi, Tomohiro,
      > 
      > I am not talking about renumbering,
      > I am talking about adding additional 10/8 addresses when you deploy/upgrade
      > 6RD CE,
      > so 6RD tunnels are using 10/8 addresses and normal IPv4 services are
      > still using the oringinal IPv4 addresses, is this a viable solution?
      > 
      > Another option,  keep the non-aggregatable address blocks in
      > separate 6RD domains, then aggregate and encode
      > less bits in each domain.  Is this a viable solution?
      > 
      > Regards
      > 
      > Terence Zhang
      > 
      > 
      > ----- Original Message -----
      > From: "Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"" <fujisaki at syce dot net>
      > To: <zhangyinghao at cnnic dot cn>
      > Cc: <pfs at cisco dot com>; <sig-policy at lists dot apnic dot net>
      > Sent: Tuesday, August 17, 2010 11:04 AM
      > Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
      > purposes
      > 
      > 
      >>
      >> Hi Terence,
      >>
      >> 6rd is just a technology to establish automatic tunnels between users
      >> (6rd CPEs at user site) and 6rd relays in an ISP. So if ISPs can
      >> renumber their IPv4 users to use 10.0.0.0/8 and LSN, it will be
      >> possible to encode 24 bits or smaller bits in a IPv6 header, as you
      >> say. In this case, you can use /32 or longer IPv6 address prefix to
      >> deploy 6rd.
      >>
      >> I suppose ISPs who try to implement 6rd will not want to change their
      >> IPv4 addressing.
      >>
      >>
      >> Yours Sincerely,
      >> --
      >> Tomohiro Fujisaki
      >>
      >> From: "Terence Zhang YH" <zhangyinghao at cnnic dot cn>
      >> Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
      > purposes
      >> Date: Tue, 17 Aug 2010 10:35:42 +0800
      >>
      >> | Hi, All,
      >> |
      >> | If I understand correctly,  6RD have multiple technique to avoid
      >> | ecoding the whole 32-bit IPv4 addresses even if there are
      >> | non-aggregatable blocks.
      >> |
      >> | Such as,   using private 10/8  addresses in addition to public IP
      > addresses
      >> | (kind of dual IPv4 addresses), so only 24-bit need to be
      >> | encoded in, or using multiple 6RD domain,  so they can aggregate
      >> | within each domain, like if a ISP have non-adjacent 3 */16,  they
      >> | can have 3*6RD domain, and encode only 16-bit.  In that way,
      >> | they are not neccesarily need longer prefix.
      >> |
      >> | Is my understanding correct?
      >> |
      >> | I believe another /32 block is needed for 6RD deployment,
      >> | but I think there should be more details about how to evaluate.
      >> |
      >> | Regards
      >> |
      >> | Terence Zhang
      >> | CNNIC
      >> |
      >> |
      >> | ----- Original Message -----
      >> | From: "Tomohiro -INSTALLER-"Fujisaki/藤崎 智宏"" <fujisaki at syce dot net>
      >> | To: <pfs at cisco dot com>
      >> | Cc: <sig-policy at lists dot apnic dot net>
      >> | Sent: Tuesday, August 17, 2010 9:54 AM
      >> | Subject: Re: [sig-policy] prop-087: IPv6 address allocation
      > fordeployment purposes
      >> |
      >> |
      >> | >
      >> | > Hi Philip,
      >> | >
      >> | > Thank you for your reply.
      >> | >
      >> | > | > ----------------------------------
      >> | > | >
      >> | > | > Current IPv6 address allocation policy is basically based on
      > number of
      >> | > | > subscribers the applicant will have [1], but this does not allow
      >> | > | > sufficient allocation size to adequately deploy some IPv6
      >> | > | > protocols. For example, the "6rd" protocol needs more than /32 to
      >> | > | > implement adequately in an ISP network due to technical reasons
      >> | > | > [2].
      >> | > |
      >> | > | Reference [2] does not say that 6rd needs more than a /32 for
      >> | > | implementation.
      >> | > |
      >> | > | It says that it needs more than a /32 should the ISP want to encode
      > the
      >> | > | entire IPv4 address the customer uses.
      >> | > |
      >> | > | How many ISPs use the entire IPv4 address space for their customer
      >> | > | public address space?
      >> | > |
      >> | > | I think the answer is none. ;-)
      >> | >
      >> | > I'm sorry if I misunderstand your comment, but the problem is not
      >> | > number of addresses but prefixes of the addresses.
      >> | >
      >> | > If ISPs use a same address prefix for all users, it is possible to
      >> | > shorten the encoded prefix. I'm not sure how many ISPs request and get
      >> | > additional address blocks under same IPv4 address prefixes, but I
      >> | > suppose there are not so many ISPs that use a single prefix for all
      >> | > of their customers.
      >> | >
      >> | > | So using 6rd as a justification for getting more than a /32 seems
      > rather
      >> | > | surprising to me.
      >> | > |
      >> | > | Perhaps the proposal would benefit from an explanation as to why
      >> | > | (technically and operationally) the entire IPv4 address needs to be
      >> | > | encoded, rather than, say the final 16 bits which would still give
      > the
      >> | > | end user an entire /48 to play with. Even an ISP who uses an IPv4 /8
      > for
      >> | > | customer facing addresses can still give each customer a /56. And
      > even
      >> | > | if they had an IPv4 /8, they could in theory use that to justify /24
      >> | > | worth of IPv6 address space - which would then let them encode the
      >> | > | entire IPv4 address for 6rd to give each customer a /56 - or the
      > final
      >> | > | 24 bits to give the customer a /48. Etc.
      >> | >
      >> | > OK, I'll try to explain this point in my proposed text or presentation
      >> | > materials.
      >> | >
      >> | > One request to APNIC Secretariat, could you show the allocation
      >> | > statistics that how many IPv4 address holders obtain addinional
      >> | > address blocks, and if possible, how may multiple IPv4 address block
      >> | > holders above got same IPv4 address prefixes? (e.g. initial address is
      >> | > 1.0.0.0/22 and additonal address is also under 1.0.0.0/8)
      >> | >
      >> | >
      >> | > Yours Sincerely,
      >> | > --
      >> | > Tomohiro Fujisaki
      >> | > *              sig-policy:  APNIC SIG on resource management policy
      > *
      >> | > _______________________________________________
      >> | > sig-policy mailing list
      >> | > sig-policy at lists dot apnic dot net
      >> | > http://mailman.apnic.net/mailman/listinfo/sig-policy
      >> | *              sig-policy:  APNIC SIG on resource management policy
      > *
      >> | _______________________________________________
      >> | sig-policy mailing list
      >> | sig-policy at lists dot apnic dot net
      >> | http://mailman.apnic.net/mailman/listinfo/sig-policy
      >> |
      >> |
      > *              sig-policy:  APNIC SIG on resource management policy
      > *
      > _______________________________________________
      > sig-policy mailing list
      > sig-policy at lists dot apnic dot net
      > http://mailman.apnic.net/mailman/listinfo/sig-policy