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.