[167218] in North American Network Operators' Group
Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Dec 4 15:52:40 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAH1iCioaR1X+2zqW_wUFK9=U01qATtBf+AuRjsUwCFy=ytSyCw@mail.gmail.com>
Date: Wed, 4 Dec 2013 12:50:42 -0800
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Dec 4, 2013, at 12:43 , Brian Dickson <brian.peter.dickson@gmail.com> =
wrote:
>=20
>=20
>=20
> On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong <owen@delong.com> wrote:
>=20
> On Dec 4, 2013, at 10:21 , Brian Dickson =
<brian.peter.dickson@gmail.com> wrote:
>=20
> Second of all, what would make much more sense in your scenario is
> to aggregate at one or two of those levels. I'd expect probably the =
POP
> and the Border device levels most likely, so what you're really =
looking
> at is 5000*100 =3D 500,000 /48s per border. To make this even, we'll
> round that up to 524,288 (2^19) and actually to make life easy, let's
> take that to a nibble boundary (2^20) 1,048,576, which gives us a
> /28 per Border Device.
>=20
>=20
>=20
> Except that we have a hard limit of 1M total, which after a few 100K =
from the
> global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.
> =20
Only if you feel the need to carry those global routes all the way down
to your border devices (which is unlikely in the kind of residential =
scenario
proposed).
>=20
> > And root of the problem was brought into existence by the insistence =
that
> > every network (LAN) must be a /64.
>=20
> Not really. The original plan was for everything to be 64 bits, so by =
adding
> another 64 bits and making every network a /64, we're actually better =
off
> than we would have been if we'd just gone to 64 bit addresses in toto.
>=20
> Thanks for playing.
>=20
> Owen
>=20
> Understand, I am not saying anyone got it wrong, but rather, that =
there is a risk associated
> with continuing forever to use a /64 fixed LAN size. Yes, we are =
better than we
> were, but the point I'm making is, if push comes to shove, that the =
/64 is a small thing
> to sacrifice (at very small incremental cost, SEND + AUTOCONF =
modifications).
>=20
I think it is already too entrenched to change, but I guess time will =
tell.
Since we are only talking about how we use the first 1/8th of the =
address space and we
didn't even exhaust that in your particularly overblown example, I am =
unconcerned.
> I can't believe I just called 2**64 small.
Well, it's smaller than 2^128. ;-)
Owen
