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

Hi Sander

he didn't refuse it, yet.

He asked me to get to the wg because he was unsure if this scenario is in the spirit of the RIPE policies.

Cheers
Jan

Am 25.11.2009 um 17:35 schrieb Sander Steffann:

> Hi Jan, 
> 
> With that many customers getting more than a /32 shouldn't be any problem... Why did the IPRA refuse it? This might just be a misunderstanding somewhere...
> 
> Sander
> 
> Jan Boogman <boogman at ip-plus.net>schreef:
> 
>> Hi Sander
>> 
>>>> We asked RIPE NCC for a larger than /32 allocation (because of the way how
>>>> 6RD encapsulates the customers IPv4 address in his IPv6 address and also
>>>> because we want to give the customer a small subnet).
>>> 
>>> In draft-townsley-ipv6-6rd-01 the following example is given:
>>> 
>>> This example show how the 6rd prefix is created based on a /32 IPv6 prefix
>>> with a private IPv4 address were the first octet is "compressed" out:
>>> SP prefix: 2001:0DB8::/32
>>> 6rd IPv4 prefix: 10.0.0.0/8
>>> 6rd router IPv4 address: 10.100.100.1
>>> 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
>>> 
>>> With this scheme you can still give every customer out of an IPv4 /8 an
>>> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could
>>> "compress" so that every customer has an IPv6 /48. And if you have more
>>> than 65k customers you should have no problem with getting a bigger IPv6
>>> allocation.
>> 
>>> 
>>> Because the IPRA refuses to give you more addresses based on your customer
>>> base I suspect that you have less than 65k customers. With a smart IPv4
>>> <--> IPv6-RD mapping that should not be a problem for IPv6-RD.
>>> 
>>> Can you give some extra background information that explains why you need
>>> more than a /32?
>> 
>> we have much more than 65k customers, with IPv4 addresses dispersed in many different /8
>> We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. 
>> However, we plan to allocate only a /60 subnet to the end customer.
>> This results in a request for a /28
>> 
>> Jan