[arin-ppml] Controlling the IPv6 address consumption rate

[William Herrin]

On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong <owen at delong.com> wrote:
> Bill... See my previous post. End sites should get at least a
>/48... If you serve 20,000,000 end sites, you need 23 bits to
>define those customers. 48-23 is 25. The closest larger nibble
>boundary is 20.  There are few enough providers serving
>20,000,000 subscribers that I don't see it as a problem.
>Most providers should probably get /28s with larger ones
>getting /24s and smaller ones getting /32s.

Hi Owen,

Let's dig into the math a little more and see what meaning we can
tease out. For anyone who wants to skip the analysis, jump to the last
two paragraphs.


First, IPv6's protocol design robs us of 64 bits. It's technically
possible to build a LAN on a non-/64 boundary but the tools for
dynamic addressing don't work right. So, for better or for worse we
shouldn't talk about 128 bits of host addresses but rather 64 bits of
LAN addresses.

You believe ISPs should preemptively assign 16 bits of LAN addresses
to end sites, even residential customers with a PC or two. Let's set
the upper bound there. I've heard a couple rationales for this. One is
that we'll almost never need to assign more to an end site, so /48
gives us a uniform size for automating the address management process.
Another is that whatever we do assign, networks which grow beyond it
will want additional addresses without renumbering out of their old
ones. Minimizing the number of organizations which need additional
addresses will keep our interior routing tables small.

The lower bound for preemptive assignments appears to be 4 bits.
Assigning only one /64 will cause obvious problems - we can
demonstrate routine uses of 2 and 3 subnets in the home even today and
4 bits allows growth to 16 such subnets. More, nibble boundaries
follow IPv6's design well, minimizing the likely human error when
configuring all those users.

In a previous email you stated that an ISP with 20M customers should
receive a /16, or 32 bits more than their downstream assignment you
recommended at /48. As I understand it, this allows flexibility with
hierarchic routing designs that swap address space for routing slots.
However, we have examples of technology, like 6rd, which will usefully
cause the ISP to consume 33 bits despite their size - 32 bits for 6rd
and separate space for native. Ideally we want nibble boundaries too,
pushing the upper bound for the ISP's consumption lying between
allocation and assignment to an upper bound of 36 bits.

On the other hand, 20M customers will consume at least 25 bits of
assignments. 25 bits is 32M, 24 bits is only 16M.Given networking
inefficiencies, it would be irresponsible not to add at least one bit
to that, so figure 26 bits as a lower bound for tolerable network
design for an ISP with 20M users.

7 billion people in the world, each of which consumes Internet
service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
ISPs to serve them.

The upper bound recognizes that these users have multiple ISPs -- for
their mobile phone, their home, their work. Maybe soon for their
electric meter, their car, etc. Better figure 12 bits worth of 20M-ISP
equivalents.

Finally, we need to hold some bits against the development of new
technologies which use IPv6 differently. We were blindsided in the
ARIN region by 6rd. Perhaps we shouldn't get caught with our pants
down again. Provide an upper bound of 8 bits so that ISPs don't have
to run back to us next time. Lower bound of 4 bits because really, it
would be irresponsible not to include at least some padding.

Sum it:

Upper bound: 64 + 16 + 36 + 12 + 8 = 136 bits.
Lower bound: 64 + 4  + 26 + 9 + 4 = 107 bits.

Now, that's interesting. 136 bits is well over two orders of magnitude
more addresses than we actually have. Three orders more if you
consider only the /3 allocated to the public Internet. This tells us
that we do have to pay at least some attention to IPv6 consumption
rates. The bits aren't as infinite as they at first appear.

Let's see if we can tease out some more instructive meaning. Back down
the number of ISPs needed to serve the world and let's look at only a
single 20M-user ISP again. Today, that ISP requests and receives a /8
of IPv4 space, or about 0.4% of IPv4's total addresses. And we
basically understand consumption rates under that model.

Our upper bound puts the same ISP consuming /4's of IPv6 space, or 6%
of IPv6's address space. That's obviously not a helpful angle, so lets
start at the lower bound and work our way back up instead.

The lower bound requires the 20M user ISP to consume at least a /30.
Take away the /8 we know it consumes in IPv4 and we're left with 22
bits. This means we have a grand total of 22 bits available to fulfill
two criteria:

1. Slowing the IPv6 consumption rate below that of IPv4.
2. Increasing allocations and assignments from the lower bound numbers
for convenience's sake.


ARIN's current model basically puts all 22 bits into responsibly slow
consumption leaving little left over for convenience.

With the 6rd proposal, we've seen a reasonably compelling case for
splitting the 22 bits between 4 bits of convenience and 18 bits of
responsibly slow consumption.

In light of a couple French and German allocations, RIPE has
apparently joined the race to the bottom with 11 bits of convenience
and only 11 bits of responsibly slow consumption.

In prior comments, Owen, you suggest what boils down to 14 bits of
convenience and a mere 8 bits of responsibly slow consumption.



So, I put it to everybody else: how should we divvy up the 22 bits
between IPv4's consumption rate and IPv6's minimum needful consumption
rate? How many bits of convenience and how many bits of responsibly
slow consumption?

We already know we don't have enough bits to apply them everywhere
they'd be nice to have. Once we know how many bits we want to save for
responsibly slow consumption we can look at the evolving choice of
where exactly the convenience bits offer the best bang for the buck.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004