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

  • To: zhangyinghao at cnnic dot cn
  • Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
  • From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <fujisaki at syce dot net>
  • Date: Tue, 17 Aug 2010 12:04:01 +0900 (JST)
  • Cc: pfs at cisco dot com, sig-policy at lists dot apnic dot net
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <482012544.30171 at cnnic dot cn>
  • 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>
    • 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
       | 
       |