[181913] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 03:28:56 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <559DC43E.5020005@lugosys.com>
Date: Wed, 8 Jul 2015 18:31:56 -0700
To: "Israel G. Lugo" <israel.lugo@lugosys.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
>=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.
Here=E2=80=99s the problem=E2=80=A6 You started at the wrong end and =
worked in the wrong direction in your planning.
Let=E2=80=99s say you=E2=80=99re a national ISP. Let=E2=80=99s say you =
want to support 4 levels of aggregation.
Let=E2=80=99s say that at the lowest level (POP/City) you serve 50,000 =
end-sites in your largest POP/City. (16 bits)
Let=E2=80=99s say you plan to max out at 32 POPs/Cities per region (your =
number from above) (5 bits)
Let=E2=80=99s say you plan to divide the country into 8 regions (3 bits)
Let=E2=80=99s 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=E2=80=99ll =
go with it for now) and that you have 4 service classes (2 bits)
Further, let=E2=80=99s say you decide to set aside half your address =
space for =E2=80=9Cfuture allocation schemes=E2=80=9D.
Each POP needs a /32.
We can combine the Region/POP number into an 8-bit field =E2=80=94 You =
need a /24 per Region.
You need 3 additional bits for your higher level sub-divisions. Let=E2=80=99=
s round to a nibble boundary and give you a /20.
With that /20, you can support up to 67 Million end sites in your first =
plan still leaving 3/4 of your address space fallow.
(That=E2=80=99s at /48 per end-site, by the way).
Now, let=E2=80=99s consider: 7 Billion People, each of which represents =
32 different end-sites =E2=80=94 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.
There are 1,048,576 /20s total, so after allocating all the ISPs in the =
world /20s, we still have 1,045,232 remaining.
Let=E2=80=99s assume that every end-site goes with dual-address =
multi-homing (an IPv6 prefix from each provider).
We are now left with only 1,041,888 /20s remaining. You still haven=E2=80=99=
t put a dent in it.
Even if we divide by 8 and just consider the current /3 being allocated =
as global unicast, you still have 130,236 free /20s
left.
> 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.
It=E2=80=99s not=E2=80=A6 It=E2=80=99s a great example of how not to =
plan your address space in IPv6.
However, if we repeat the same exercise in the correct direction, not =
only 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 still don=E2=80=99t make a dent in the IPv6 free pool. Everyone =
wins.
> 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=E2=80=9D.
The problem is that you not only stopped counting beans, you stopped =
counting bean piles and you lost track of just how big the pile that you =
are making smaller piles from really is.
I hope that this will show you a better way.
Owen
