[ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD

Hello list,

On Thu, 2009-12-03 at 14:28 +0100, Alex Le Heux wrote:
> Dear Colleagues,
> 
> During the discussion on the APWG list about 6rd, several people have  
> inquired about the exact way Registration Services evaluates requests  
> for 6rd deployment. This email will try to answer these inquiries.
> 
> The RIPE NCC considers current policy to be completely agnostic to  
> 6rd, it neither specifically supports nor disallows 6rd deployment.  
> This means that Registration Services will evaluate IPv6 allocation  
> requests that include 6rd deployments according to the established  
> policies and procedures of justified need.

<snip>

> Another LIR, who has 3 million customers, intends to deploy 6rd with / 
> 60 assignments. Currently, the IPRA would consider 3 million /60  
> assignments to fit into a /38, thus the default /32, while the 6rd  
> deployment would require a /28.
> 
> Note that neither of these LIRs would qualify easily for an additional  
> allocation under the HD-ratio rules.

I am curious how LIRs that employ 6RD today plan to motivate their need
for the 15 extra /32:s they would be allocated following the example
above, with the /28-instead-of-/32, once the 6RD transition phase is
complete.

IIRC RIPE are currently spacing their /32 assignments on a /29 basis.

Eg, 
anticimex at hsa:~$ for i in `seq 0 8`; do whois 2a02:9a$i::/32 | egrep
'(inet6num|netname)' ; done
inet6num:       2a02:9a0::/32
netname:        SE-SCS-20090203
inet6num:       2a00::/12
netname:        EU-ZZ-2A00
[...]
inet6num:       2a02:9a8::/32
netname:        IT-SPIN-20090204

I guess that it would be trivial to fall back to the first /32, or
whatever less-than-6RD-inflated prefix you had before, once the
transition is over, as long as the LIR plans ahead accordingly.

Best regards,
-- 
Martin Millnert <millnert at csbnet.se>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20100311/6e5a09df/attachment.sig>