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

[Mark Andrews]

In message <AANLkTi=9pkqS+T8L75tmHtb04UMexfj9+cM5Az+Tr8pi at mail.gmail.com>, Lore
nzo Colitti writes:
> --000e0cd47f1c54172104929f8666
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 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 have dozens of 6rd prefixes.  The space to support a dozen 6rd prefixes
is still less than that required to encode all of IPv4 address space into
one 6rd prefix.

> You can either give the customer IPv4 or 6rd but not both.
> Guess which one you're going to choose.

Guess what.  All you customers can't get a public IPv4 address as
there are not enough to go around.  You will need to start giving
them to those that REQUIRE them and share the rest (NAT444 and
eventually DS-lite or start with DS-lite over 6rd so there is only
a single NAT translation in the IPv4 path).  Yes this is a paradigm
shift.

That doesn't mean that they can't all use 6rd while waiting for all
the of the required equipement to be upgraded to support 6rd natively.

The 6rd parameters for 10.0.0.0/8 and 193.0.0.0/8 are identical.  You
can just pack more customers into the 6rd prefix for 10.0.0.0/8 than
you can in 193.0.0.0/8 because you have all of 10.0.0.0/8.

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

This proposal is not particularly messy.

> 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,

But it is big enough for all your customers that live in one /8.

> 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 get a IPv6 /32 per IPv4 /8 that you have address space allocated in.
Add in a /32 for 10.0.0.0/8 which would be allocated under the existing
allocation policies.

> 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.

Your customers CPE gear will support it.  All the complicated parts are
on the ISP's end.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org