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

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.