Hi Florian, 'it may be messy' is not a particularly strong argument I think, considering that the current deployed IPv4 setup is already more complicated than this. Every IPv4 subnet already has its own DHCP definition, adding a few lines to tell how that will translate isn't going to be hard. As for v6->v4 translation, every piece of v4 will have a separate v6 SP prefix so that's going to be easy, too. I was at RIPE58 to see Free's presentation and I don't see how any of that conflicts with what I'm trying to say here. Remco -----Original Message----- From: Florian Frotzler [mailto:florian@frotzler.priv.at] Sent: donderdag 26 november 2009 9:56 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD 2009/11/26 Remco van Mook <Remco.vanMook@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@frotzler.priv.at] Sent: donderdag 26 november 2009 1:08 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg@ripe.net; ipv6-wg@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@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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg@ripe.net; ipv6-wg@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.