## ARIN-PPML Message

### [arin-ppml] Controlling the IPv6 address consumption rate

**From:**William Herrin (*bill at herrin.us*)**Date:**Sun Oct 10 10:09:57 EDT 2010- Next message (by thread): [arin-ppml] Controlling the IPv6 address consumption rate
- Previous message (by thread): [arin-ppml] IPv4 Crumbs Straw Poll

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