[arin-ppml] Opposed to 2010-9 and 2010-12

[Lorenzo Colitti]

On Thu, Oct 14, 2010 at 7:13 PM, Mark Andrews <marka at isc.org> wrote:

> I would suggest that ARIN allocate space per IPv4 /8 that address
> space has been allocated from.  That's a /32 per /8 that contains
> allocation instead of a /24.  For manual configuration you would
> look at the first octet of your IPv4 address and pick the associated
> 6rd prefix.  This is still very wasteful but no where near as
> wasteful as handing out /24's.
>
> For CMCS (Comcast Cable Communications) they would the have 10 blocks
> of space and 10 6rd prefixes.  Do you think Comcast's network
> engineers can cope with 10 6rd prefixes?  I sure do.
>

And in the future, when people are scrambling for bits and pieces of IPv4
space and ISPs end up with hundreds of small IPv4 prefixes from a dozen
different /8s? You can either give the customer IPv4 or 6rd but not both.
Guess which one you're going to choose.

Yes, it's possible to use multiple 6rd realms to support more users with
less address space, but it's not particularly pretty.

Assume you hand out a /56s to users and you have an IPv6 /32. You have 24
bits to play with. That's not enough bits for the whole IPv4 address, so if
you want to support more than one IPv4 prefix, you need multiple 6rd
realms. Each realm corresponds to an IPv4 prefix you have. So you need to
allocate X bits to number the realm (i.e., the IPv4 prefix) and Y bits to
the host in the prefix. X + Y = 24.

X must be big enough to represent all your prefixes. If you have 100
prefixes, X = 7.
Y must be big enough to represent the number of hosts in the largest prefix.
If your largest prefix is a /16, you have one bit left.

However, if in the future you want to do CGN and assign 10/8 to your
customers, you're out of luck, because for a /8, Y = 24.

You might be able to make it even more complex by using variable-length
realm IDs, but at that point your operators' heads start hurting and you
start to worry about whether your gear and your customers' CPEs support it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/067f6940/attachment.htm>