[165988] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: minimum IPv6 announcement size

daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Sep 27 18:39:35 2013

From: Owen DeLong <owen@delong.com>
In-Reply-To: <524496AA.5070705@bitfreak.org>
Date: Fri, 27 Sep 2013 15:42:41 -0700
To: Darren Pilgrim <nanog@bitfreak.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Sep 26, 2013, at 13:18 , Darren Pilgrim <nanog@bitfreak.org> wrote:

> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>>=20
>> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim <nanog@bitfreak.org>
>> wrote:
>>=20
>>> On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:
>>>> sounds just like folks in 1985, talking about IPv4...
>>>=20
>>> The foundation of that, though, was ignorance of address space
>>> exhaustion.  IPv4's address space was too small for such large
>>> thinking.
>>=20
>> The first dicussion I could find about ipv4 runnout  in email
>> archives is circa 1983
>>=20
>>> IPv6 is far beyond enough to use such allocation policies.
>>=20
>> There are certain tendencies towards profligacy that might
>> prematurely influence the question of ipv6 exhaustion and we should
>> be on guard against them=85 allocating enough /48s as part of direct
>> assignments  is probably not one of them.
>=20
> 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.
>=20

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.

>=20
> - 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.

>=20
> 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.

>=20
> 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.

Owen



home help back first fref pref prev next nref lref last post