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