[181923] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Thu Jul 9 03:44:01 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Owen DeLong <owen@delong.com>
Date: Thu, 9 Jul 2015 01:46:51 +0000
In-Reply-To: <4DDE4A2C-55B6-449B-A3C8-FB5494E20AC4@delong.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Israel,
A better question is why bit-map your allocation plan at all? That seems il=
l advised, since you must arbitrarily allocate huge swaths of ip space equa=
lly between category classes when it's rarely efficient to do so. For examp=
le, two bits for network infrastructure because infrastructure addresses ar=
e likely far fewer than any customer class. Similarly three bits for geogra=
phic region on the /38 boundary illogically assumes all geographic regions =
are the same size.
There isn't a good routing reason for a bitwise address structure, since no=
body routes that way. The only other rationale I can think of is human mnem=
onic value, but 128-bit addresses are not very amenable to such mnemonics (=
::DEAD:BEEF not withstanding :)
-mel beckman
> On Jul 8, 2015, at 6:32 PM, Owen DeLong <owen@delong.com> wrote:
>=20
>=20
>>=20
>> Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:
>>=20
>> - I reserve 1 bit for future allocation schemes, leaving me a /33;
>> - 2 bits for network type (infrastructure, residential, business, LTE): =
/35
>> - 3 bits for geographic region, state, whatever: /38
>> - 5 bits for PoP, or city: /43
>>=20
>> This leaves me 5 bits for end sites: no joy.
>=20
> Here=92s the problem=85 You started at the wrong end and worked in the wr=
ong direction in your planning.
>=20
> Let=92s say you=92re a national ISP. Let=92s say you want to support 4 le=
vels of aggregation.
> Let=92s say that at the lowest level (POP/City) you serve 50,000 end-site=
s in your largest POP/City. (16 bits)
> Let=92s say you plan to max out at 32 POPs/Cities per region (your number=
from above) (5 bits)
> Let=92s say you plan to divide the country into 8 regions (3 bits)
> Let=92s say for some reason you want to break your aggregation along the =
lines of service class (infrastructure, residential, business)
> as your top level division (rarely a good idea, but I=92ll go with it =
for now) and that you have 4 service classes (2 bits)
> Further, let=92s say you decide to set aside half your address space for =
=93future allocation schemes=94.
>=20
> Each POP needs a /32.
> We can combine the Region/POP number into an 8-bit field =97 You need a /=
24 per Region.
> You need 3 additional bits for your higher level sub-divisions. Let=92s r=
ound to a nibble boundary and give you a /20.
>=20
> With that /20, you can support up to 67 Million end sites in your first p=
lan still leaving 3/4 of your address space fallow.
>=20
> (That=92s at /48 per end-site, by the way).
>=20
> Now, let=92s consider: 7 Billion People, each of which represents 32 diff=
erent end-sites =97 224 billion end-sites world wide.
> 224,000,000,000 / 67,000,000 =3D 3,344 (rounded up) total ISPs requiring =
/20s to serve every possible end-site on the
> planet.
>=20
>=20
> There are 1,048,576 /20s total, so after allocating all the ISPs in the w=
orld /20s, we still have 1,045,232 remaining.
>=20
> Let=92s assume that every end-site goes with dual-address multi-homing (a=
n IPv6 prefix from each provider).
>=20
> We are now left with only 1,041,888 /20s remaining. You still haven=92t p=
ut a dent in it.
>=20
> Even if we divide by 8 and just consider the current /3 being allocated a=
s global unicast, you still have 130,236 free /20s
> left.
>=20
>> Granted, this is just a silly example, and I don't have to divide my
>> address space like this. In fact, I really can't, unless I want to have
>> more than 32 customers per city. But I don't think it's a very
>> far-fetched example.
>=20
> It=92s not=85 It=92s a great example of how not to plan your address spac=
e in IPv6.
>=20
> However, if we repeat the same exercise in the correct direction, not onl=
y does each of your end-sites get a /48, you get the /20 you need in order =
to properly deploy your network. You get lots of space left over, and we st=
ill don=92t make a dent in the IPv6 free pool. Everyone wins.
>=20
>> Perhaps I'm missing something obvious here, but it seems to me that it
>> would've been nice to have these kinds of possibilities, and more. It
>> seems counterintuitive, especially given the "IPv6 way of thinking"
>> which is normally encouraged: "stop counting beans, this isn't IPv4=94.
>=20
> The problem is that you not only stopped counting beans, you stopped coun=
ting bean piles and you lost track of just how big the pile that you are ma=
king smaller piles from really is.
>=20
> I hope that this will show you a better way.
>=20
> Owen
>=20
