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

  • To: "'Terence Zhang YH'" <zhangyinghao at cnnic dot cn>, 'Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"' <fujisaki at syce dot net>
  • Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
  • From: "Naresh" <ajwaninaresh at gmail dot com>
  • Date: Tue, 17 Aug 2010 12:27:40 +0530
  • 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: <482015457.27110 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> <482014256.28633@cnnic.cn> <482015457.27110@cnnic.cn>
  • Thread-index: Acs9u7OBAaGLcIYQS6+ViwqetmHyaQAAv7nQ
    • 
      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