[165959] in North American Network Operators' Group
Re: minimum IPv6 announcement size
daemon@ATHENA.MIT.EDU (joel jaeggli)
Thu Sep 26 16:42:58 2013
From: joel jaeggli <joelja@bogus.com>
In-Reply-To: <524496AA.5070705@bitfreak.org>
Date: Thu, 26 Sep 2013 13:36:07 -0700
To: Darren Pilgrim <nanog@bitfreak.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_F30369F8-F0B9-4EE2-9044-8BEBD36D3595
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Sep 26, 2013, at 1:18 PM, 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
Instead of explaining to me how awesomely big ipv6 is you might figure =
out who you're talking to, or maybe consider the problem a bit more.
Semantic addressing schemes can soak up as many bits as you're willing =
to give them.
ISP(s) using (for example) 6rd or other automatic prefix mapping =
mechanisms can potentially use rather large prefixes.
128 bits is not so many that we can't trivially soak them all up and we =
should not pretend otherwise. We are stewards of the resource and we =
should manage it with care that reflect's long term thinking, both so =
that allocations we make now are not inappropriately small in the future =
and such that we are not again confronting the shortcomings of our =
decision-making again in 20 years.
> We have this idea of the "/64 boundary". All those nifty automatic =
addressing things rely on it. We now have two generations of hardware =
and software that would more or less break if we did away with it. In =
essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but =
still quite large.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=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).
>=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.
>=20
> Even with sloppy, sparse allocation policies and allowing limitless =
human and device population growth, we very likely can not exhaust IPv6.
>=20
--Apple-Mail=_F30369F8-F0B9-4EE2-9044-8BEBD36D3595
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlJEmrcACgkQ8AA1q7Z/VrLh2wCfRufW/hVupi85PlND8WEyTAwV
dPcAn24yIPaQQXZiZK7q6njMiqqimCn4
=r7SV
-----END PGP SIGNATURE-----
--Apple-Mail=_F30369F8-F0B9-4EE2-9044-8BEBD36D3595--
