This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 allocations for 6RD
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Florian Frotzler
florian at frotzler.priv.at
Thu Nov 26 01:08:18 CET 2009
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. > >
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]