[address-policy-wg] IPv6 allocations for 6RD

2009/11/26 Remco van Mook <Remco.vanMook at eu.equinix.com>:
> Hi Florian

Hi Remco,

> It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like:

Free.fr is one of the largest providers in Europe offering IPv6
services to its customers. They are the reason why 6RD became known
because they have a working installation of 6RD and are very
successful. Please take a look at the link Jan postet in his original
message.

> - You can only do 6rd once in an entire network

If you have enought bits, you can subnet -> in front <- of the
embedded IPv4 prefix (like free.fr did) and so you can address
different 6RD gateways. This is infrastructure subnetting and not to
be confused with customer subnetting like what Jan tries to establish.
Multiple 6RD GWs are therefore technically possible IMHO, but may be
messy regarding your CPE provisioning.

> - It only works for IPv4 /8s and larger
> - It only works for IPv6 /32s and larger
>

Why? You can aggregate on any boundary as long as there are common
high order bits.

> I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft:
>
>           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
>
> I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement.
>
> If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever.

Can you give an example? How does the GW chose the prefix for
encapsulation if there is more than one possible?

> Remco
>
Florian

>
> -----Original Message-----
> From: Florian Frotzler [mailto:florian at frotzler.priv.at]
> Sent: donderdag 26 november 2009 1:08
> To: Remco van Mook
> Cc: Jan Boogman; Sander Steffann; address-policy-wg at ripe.net; ipv6-wg at ripe.net
> Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
>
> Hi Remco,
>
> Either you or me have a wrong understanding of how 6RD works. I
> understand it like that some high order bits of the IPv4 prefixes need
> to match so that you can aggregate. How many high order bits of IP
> addresses of which the first octet is <128 do you see matching with an
> octet being >=128?
>
> Cheers,
> Florian
>
>
> 2009/11/25 Remco van Mook <Remco.vanMook at eu.equinix.com>:
>> Hi Jan,
>>
>> I see the problem you have trying to get a fragmented address space such
>> as yours play nicely with 6rd. However, given the dimension of your
>> network (some quick digging gave me a figure of roughly a million v4
>> addresses) do you think that asking for 4 billion /60 prefixes is a good
>> idea? To borrow somebody else's words here, that doesn't scale.
>>
>> Here's another idea. You've got ~135 prefixes announced, but if I
>> aggregate those to the nearest /16 (remember, if there are blocks of
>> space that aren't yours in between it doesn't matter for 6rd because the
>> ipv6 sp prefix will be different anyway) you end up with a (sparsely
>> filled) block or 30. From there on it's a matter of a simple mapping to
>> about 21 bits of uniquely identified addresses, removing an easy 3
>> orders of magnitude from your address requirement. All of a sudden, you
>> no longer need to have a /28 for just migrating your v4 customers but a
>> mere /39, giving you tons of space for deployment of new and exciting
>> IPv6 services for years even with the standard /32 allocation.
>>
>> Since we're talking about drafts, not standards, perhaps something like
>> this should be taken in consideration reviewing a new version of the
>> draft. We've wasted enough IPv6 space in standards already, IMNSHO.
>>
>> Best,
>>
>> Remco
>>
>> -----Original Message-----
>> From: address-policy-wg-admin at ripe.net
>> [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman
>> Sent: woensdag 25 november 2009 17:13
>> To: Sander Steffann
>> Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net
>> Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
>>
>> 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
>>
>>
>> This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately.  Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
>>
>>
>