[arin-ppml] Controlling the IPv6 address consumption rate

[Owen DeLong]

On Oct 10, 2010, at 7:09 AM, William Herrin wrote:

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

> 
> 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.
> 
Rob is a strong term. I think that SLAAC is a good thing overall. I think
it's a worthwhile use of 64 bits, and, that it's not unlikely that without
it we'd be looking at a 64-bit IPv6 rather than 128 bits. In any case,
it is what it is and we're there.

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

> 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.
> 
Additionally, nibble boundaries facilitate rDNS delegations.

> 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.
> 
We really should be regarding 6rd as a temporary and very limited
technology. I would oppose facilitating /48s in 6rd because of the
vast amount of inefficiency of the 6rd protocol. I think that /56s are
pretty much the only rational end-site result under 6rd.

I actually would suggest ISPs doing 6rd should get that from a
completely separate address space than their native IPv6 space
and that all 6rd allocations should, ideally, come from a separate
address space at the RIR level to facilitate a subsequent community
decision to deprecate it.

I really think we should avoid damaging native deployment because
we are concerned about use for 6rd. That's a very long term consequence
for a relatively short term pragmatism.

> 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.
> 
I think that's what I said. Further, I felt that rounding to a nibble was
a practical consideration, so, I went to 28. 48 - 28 = 20, so, /20
was my suggestion as a minimum with the possible result of
/16 in extreme cases.

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

People don't map directly to end sites. First, most people will be members
of multiple end sites... Work, home, public access networks, etc.
Second, most end sites incorporate multiple people. (average household
size is, IIRC, 2.8 people). Households, businesses, organizations,
public access networks, etc., all have multiple people among their
address consumers.

So, 7 billion people translates to ~2.5 billion households and probably
about 1 billion other forms of end sites. For convenience, we can round
that up to ~4.2 billion total end sites.

4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent
ISPs. However, it won't actually work out that way. The vast majority
of ISPs will be much smaller and there will be many more of 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.
> 
I think the math I did above produces a more accurate analysis, but, if
you can make a more detailed analysis that you think is better, I'm
open to reviewing it.

> 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.
> 
This is only true if you assume that EVERY ISP requires the same
number of bits and that the distribution is even. The real world
doesn't work that way.

> 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.
> 
I've never suggested otherwise. Hence my opposition to both 6rd
proposals as they were written and my call for protections in the
6rd proposals before I could support them.

> 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.
> 
Actually, they'd get at least a /7.

> 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.
> 
Your upper bound.. My upper bound had them at /20, or, perhaps /16.

> 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:
> 
I don't follow your relationship here between IPv4 and IPv6. It seems
illogical to me.

> 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.
> 
So, we agree that the current model is flawed.. That's a good starting point
even if we arrived there via radically different paths.

> 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.
> 
Not as compelling to me as you believe, and certainly I am not convinced
of the 4 bit point.

> 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.
> 
I think characterizing this as a race to the bottom is neither accurate
nor useful.

> In prior comments, Owen, you suggest what boils down to 14 bits of
> convenience and a mere 8 bits of responsibly slow consumption.
> 
If you say so... Your characterizations still don't entirely make sense
to me, so, it's hard to argue the coefficients when the terms that
the coefficients are supposed to quantify are still vague.
> 
> 
> 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?
> 
_IF_ I understand what you mean by these terms correctly, then, yes,
I think an 8/14 ratio isn't such a bad ratio (although I am not completely
convinced that is the accurate ratio in the current situation as I stated
above).

> 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.
> 
We get a LOT of bits back if we make sure we plan to deprecate 6rd when
it is no longer necessary. Hence my claim that this should be a critical
part of ANY 6rd policy or plan.

Owen