Re: Nat

[Owen DeLong <owen () delong com>]

> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog () ics-il net> wrote:
>
> There's nothing that can really be done about it now and I certainly wasn't able to participate when these things 
> were decided. 
>
> However, keeping back 64 bits for the host was a stupid move from the beginning. We're reserving 64 bits for what's 
> currently a 48 bit number. You can use every single MAC address whereas IPS are lost to subnetting and other such 
> things. I could have seen maybe holding back 56 bits for the host if for some reason we need to replace the current 
> system of MAC addresses at some point before IPv6 is replaced. 

That’s not what happened. What happened was that we added 64 bits to the address space (the original thought was a 64 
bit address space) in order to allow for simplified host autoconf based on EUI-64 addresses. It did seem like a good 
idea at the time.

At the time, IEEE had realized that they were running out of EUI-48 addresses and had decided that the next generation 
would be EUI-64 and in fact, if you look at newer interfaces (e.g. firewire) you will see that they do, in fact, ship 
with EUI-64 addresses baked in. Given that IEEE had already decided on EUI-64 as the way forward for “MAC” addresses, 
it seems to me that 64 bits makes more sense than 56.

> There may be address space to support it, but is there nimble boundary space for it?

I think you mean nibble-boundary space for it and the answer is yes.

> The idea that there's a possible need for more than 4 bits worth of subnets in a home is simply ludicrous and we have 
> people advocating 16 bits worth of subnets. How does that compare to the entire IPv4 Internet? 

I have more than 16 subnets in my house, so I can cite at least one house with need for more than 4 bits just in a 
hand-coded network.

Considering the future possibilities for automated topological hierarchies using DHCP-PD with dynamic joining and 
pruning routers, I think 8 bits is simply not enough to allow for the kind of flexibility we’d like to give to 
developers, so 16 bits seems like a reasonable compromise.

> There is little that can be done about much of this now, but at least we can label some of these past decisions as 
> ridiculous and hopefully a lesson for next time. 


TL;DR version: Below is a detailed explanation of why giving a /48 to every residence is harmless and just makes sense.

If you find that adequate, stop here. If you are still skeptical, read on…

Except that the decisions weren’t ridiculous. They not only made sense then, but for the most part, if you consider a 
bigger picture and a wider longer-term view than just what we are experiencing today, they make even more sense.

First, unlike the 100 gallon or 10,000 gallon fuel tank analogy, extra bits added to the address space come at a near 
zero cost, so adding them if there’s any potential use is what I would classify as a no-brainer. At the time IPv6 was 
developed, 64-bit processors were beginning to be deployed and there was no expectation that we’d see 128-bit 
processors. As such, 128 bit addresses were cheap and easily implementable in anticipated hardware and feasible in 
existing hardware, so 128-bits made a lot of sense from that perspective.

From the 64-bits we were considering, adding another 64 bits so that we could do EUI-based addressing also made a lot 
of sense. 48-bits didn’t make much sense because we already knew that IEEE was looking at moving from 48-bits to 
64-bits for EUI addresses. A very simple mechanism for translating EUI-48 into a valid unique EUI-64 address was 
already documented by IEEE (Add an FF suffix to the OUI portion and an EE Prefix to the ESI portion, and ensure that 
the Locally Generated bit is 1). As such, a locally generated 02:a9:3e:8c:7f:1d address becomes 02:a9:3e:ff:ee:8c:7f:1d 
while a registered address ac:87:a3:23:45:67 would become ae:87:a3:ff:fe:23:45:67.

The justification for 16 bits of subnetting is a little more pie-in-the-sky, I’ll grant you, but given a 64-bit network 
numbering space, there’s really no disadvantage to giving out /48s and very little (or no) advantage to giving out 
smaller chunks to end-sites, regardless of their residential or commercial nature.

Let’s assume that ISPs come in essentially 3 flavors. MEGA (The Verizons, AT&Ts, Comcasts, etc. of the world) having 
more than 5 million customers, LARGE (having between 100,000and 5 million customers) and SMALL (having fewer than 
100,000 customers).

Let’s assume the worst possible splits and add 1 nibble to the minimum needed for each ISP and another nibble for 
overhead.

Further, let’s assume that 7 billion people on earth all live in individual households and that each of them runs their 
own small business bringing the total customer base worldwide to 14 billion.

If everyone subscribes to a MEGA and each MEGA serves 5 million customers, we need 2,800 MEGA ISPs. Each of those will 
need 5,000,000 /48s which would require a /24. Let’s give each of those an additional 8 bits for overhead and bad 
splits and say each of them gets a /16. That’s 2,800 out of
65,536 /16s and we’ve served every customer on the planet with a lot of extra overhead, using approximately 4% of the 
address space.

Now, let’s make another copy of earth and serve everyone on a LARGE ISP with only 100,000 customers each. This requires 
 140,000 LARGE ISPs each of whom will need a /28 (100,000 /48s doesn’t fit in a /32, so we bump them up to /28). Adding 
in bad splits and overhead at a nibble each, we give each of them a /20. 140,000 /20s out of 1,048,576 total of which 
we used 44,800 for the MEGA ISPS leaves us with 863,776 /20s still available. We’ve now managed to burn approximately 
18% of the total address space and we’ve served the entire world twice.

Finally, let us serve every customer in the world using a small ISP. Let’s assume that each small ISP only serves about 
5,000 customers. For 5,000 customers, we would need a /32. Backing that off two nibbles for bad splits and overhead, we 
give each one a /24.

This will require 2,800,000 /24s. (I realize lots of ISPs server fewer than 5,000 customers, but those ISPs also don’t 
serve a total of 14 billion end sites,
so I think in terms of averages, this is not an unreasonable place to throw the dart).

There are 16,777,216 /24s in total, but we’ve already used 2,956,800 for the MEGA and LARGE ISPs, bringing our total 
utilization to 5,756,800 /24s.

We have now built three complete copies of the internet with some really huge assumptions about number of households 
and businesses added in and we still have only used roughly 34% of the total address space, including nibble boundary 
round-ups and everything else.

I propose the following: Let’s give out /48s for now. If we manage to hit either of the following two conditions in 
less than 50 years, I will happily (assuming I am still alive when it happens) assist in efforts to shift to more 
restrictive allocations.

        Condition 1: If any RIR fully allocates more than 3 /12s worth of address space total
        Condition 2: If we somehow manage to completely allocate all of 2000::/3

I realize that Condition 2 is almost impossible without meeting condition 1 much much earlier, but I put it there just 
in case.

If we reach a point where EITHER of those conditions becomes true, I will be happy to support more restrictive 
allocation policy. In the worst case, we have roughly 3/4 of the address space still unallocated when we switch to more 
restrictive policies. In the case of condition 1, we have a whole lot more. (At most we’ve used roughly 15[1] of the 
512 /12s in 2000::/3 or less than 0.004% of the total address space.

My bet is that we can completely roll out IPv6 to everyone with every end-site getting a /48 and still not burn more 
than 0.004% of the total address space.

If anyone can prove me wrong, then I’ll help to push for more restrictive policies. Until then, let’s just give out 
/48s and stop hand wringing about how wasteful it is. Addresses that sit in the free pool beyond the end of the useful 
life of a protocol are also wasted.


Owen



[1] This figure could go up if we add more RIRs. However, even if we double it, we move from 0.004% to 0.008% 
utilization risk with 10 RIRs.


> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> ----- Original Message -----
>
> From: "Daniel Corbe" <corbe () corbe net> 
> To: "Mike Hammett" <nanog () ics-il net> 
> Cc: "Mark Andrews" <marka () isc org>, "North American Network Operators' Group" <nanog () nanog org> 
> Sent: Saturday, December 19, 2015 10:55:03 AM 
> Subject: Re: Nat 
>
> Hi. 
>
> > On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog () ics-il net> wrote: 
> >
> > "A single /64 has never been enough and it is time to grind that 
> > myth into the ground. ISP's that say a single /64 is enough are 
> > clueless." 
> >
> >
> >
> > LLLLOOOOOOLLLLL 
> >
> >
> > A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 
> > like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 
>
> You’re being deliberately flippant. 
>
> There are technical reasons why a single /64 is not enough for an end user. A lot of it has to do with the way auto 
> configuration works. The lower 64 bits of the IP address are essentially host entropy. EUI-64 (for example) is a 64 
> bit number derived from the mac address of the NIC. 
>
> The requirement for the host portion of the address to be 64 bits long isn’t likely to change. Which means a /64 is 
> the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet. 
>
> Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it. It’s a good 
> practice and there’s certainly enough address space available to support it.