minimum IPv6 announcement size

Owen DeLong owen at
Fri Sep 27 22:42:41 UTC 2013

On Sep 26, 2013, at 13:18 , Darren Pilgrim <nanog at> wrote:

> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim <nanog at>
>> wrote:
>>> On 9/26/2013 1:52 AM, bmanning at wrote:
>>>> sounds just like folks in 1985, talking about IPv4...
>>> The foundation of that, though, was ignorance of address space
>>> exhaustion.  IPv4's address space was too small for such large
>>> thinking.
>> The first dicussion I could find about ipv4 runnout  in email
>> archives is circa 1983
>>> IPv6 is far beyond enough to use such allocation policies.
>> There are certain tendencies towards profligacy that might
>> prematurely influence the question of ipv6 exhaustion and we should
>> be on guard against them… allocating enough /48s as part of direct
>> assignments  is probably not one of them.
> That's just it, I really don't think we actually have an exhaustion risk with IPv6.  IPv6 is massive beyond massive.  Let me explain.

There are some (bizarre) ideas for using IPv6 in really stupid ways that would profligately waste /12 and larger blocks of IPv6.

There are no more /12s in IPv6 than there are /12s in IPv4... Exactly 4096 of them.

If we waste ~4000 /12s, we might be in trouble.

> Current science says Earth can support ten billion humans.  If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's.  If we're generous with Earth's carrying capacity, a /36.

But a /64 is nowhere near enough. You should, instead, be presuming the following:

	a /48 for each human's tablet
	a /48 for each human's phone
	a /48 for each human household (~1 /48 per 3 humans)
	a /48 for each human business site (hard to develop a good ratio here, but I'd guess something like 20 wouldn't be unreasonable,
		so that's another /48 for every 20 humans).

	Then, add to that network infrastructure, servers, etc.

Additionally, we expect IPv6 to last long enough that you may not be able to depend on Earth as a bounding limitation, nor can you count on the limits of current science as a population limit.

> If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52.  Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio.  That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose.

You can't fit multiple /48s in a single /52, so that doesn't work.

There are only 4096 /64s in a /52.

> That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently.  The problem isn't allocation density, but router hardware.  We need room for route aggregation and other means of compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's.  If 10% isn't enough, we can go quite a bit farther:

This just doesn't work mathematically. You can't put multiple /48s into a /60... A /48 consists of 4096 /60s.

> - 1% utilisation would fit all those /48's into a /62.
> - A full /64 of those /48's would be 0.2% utilisation.
> - 0.1%? We'd have to steal a bit and hand out /47's instead.
> - /47 is ugly.  At /52, we'd get .024% (one per 4096).

It's really hard to follow what you are trying to claim given that you seem to have the bit math all backwards.

> That's while maintaining a practice of one /64 per human or device with 65535 devices per human.  Introduce one /64 per subnet and sub-ppm utilisation is possible.  That would be giving a site a /44 and them only ever using the ::/64 of it.

I'm not sure what this is supposed to mean.

> Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.

In terms of current allocation policies for humans, devices, and infrastructure, that is true.

However, at one point, many ISPs wanted a /16 in order to be able to give each IPv4 subscriber a /48 based on their current IPv4 unicast address(es) for 6rd. There are only 65,536 /16s in IPv6. (Which is one of the many reasons this proposal did not make it into policy without
moving some bits to the right). Fortunately, few operators actually implemented 6rd in such a profligate way anyway, so little harm was done.

There are other proposals that have been made. One proposal was to map VIN numbers onto /48 prefixes and give each car manufactured a /48 that would be permanently allocated to the vehicle. Since these network numbers would not be reliably reclaimable at vehicle end-of-life, this
usage pattern could become problematic over time.

There have been others as well.

It is these unusual "special" uses that I think Joel is referring to. Not traditional assignments for traditional internet purposes.


More information about the NANOG mailing list