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

  • To: Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏" <fujisaki at syce dot net>
  • Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
  • From: "Terence Zhang YH" <zhangyinghao at cnnic dot cn>
  • Date: Tue, 17 Aug 2010 11:24:15 +0800
  • Cc: pfs at cisco dot com, 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>
    • 
      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
      > |