Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose
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
|
|