[181919] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Thu Jul 9 03:43:56 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: "Israel G. Lugo" <israel.lugo@lugosys.com>
Date: Thu, 9 Jul 2015 02:34:58 +0000
In-Reply-To: <559DDBE9.2060401@lugosys.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
None of those applications benefit from address mapping. They can be done w=
ith IPv6 as it stands today. This is where the atoms argument you don't wan=
t us to make comes in :)
-mel via cell
> On Jul 8, 2015, at 7:27 PM, Israel G. Lugo <israel.lugo@lugosys.com> wrot=
e:
>=20
> I'm sorry Mel, I only now saw your email.
>=20
> I'll quote from my reply to Owen, for the motivation behind my question:
>=20
>> Speaking of IPv6's full potential: we're considering 32 subscriptions
>> per client. I've read people thinking of things like IPv6-aware soda
>> cans. Refrigerators. Wearables. Cars and their internal components...
>> You could have the on-board computer talking to the suspension via IPv6,
>> and reporting back to the manufacturer or whatnot.
>>=20
>> Personally, I'm not particularly fond of the whole "refrigerators
>> ordering milk bottles" craze, but hey, it may very well become a thing.
>> And other stuff we haven't thought of yet.
>>=20
>> My point is: we're changing to a brand new protocol, and only now
>> beginning to scratch its full potential. Yes, everything seems very big
>> right now. Yes, 128 bits can be enough. Even 64 bits could be more than
>> enough. But why limit ourselves? Someone decided (corretly) that 64
>> would be too limiting.
>>=20
>> Please don't fall into the usual "you've got more addresses than
>> atoms"... I've heard that, and am not disputing it. I'm not just talking
>> about individual addresses (or /48's).
>>=20
>> What I am proposing here, as food for thought, is: what if we had e.g.
>> 192 bits, or 256? For one, we could have much sparser allocations. Heck,
>> we could even go as far as having a bit for each day of the month. What
>> would this be good for? I don't know. Perhaps someone may come up with a
>> use for it.
>=20
> Regards,
> Israel
>=20
>=20
>=20
>> On 07/09/2015 02:46 AM, Mel Beckman wrote:
>> Israel,
>>=20
>> A better question is why bit-map your allocation plan at all? That seems=
ill advised, since you must arbitrarily allocate huge swaths of ip space e=
qually between category classes when it's rarely efficient to do so. For ex=
ample, two bits for network infrastructure because infrastructure addresses=
are likely far fewer than any customer class. Similarly three bits for geo=
graphic region on the /38 boundary illogically assumes all geographic regio=
ns are the same size.
>>=20
>> There isn't a good routing reason for a bitwise address structure, since=
nobody routes that way. The only other rationale I can think of is human m=
nemonic value, but 128-bit addresses are not very amenable to such mnemonic=
s (::DEAD:BEEF not withstanding :)
>>=20
>> -mel beckman
>>=20
>>> On Jul 8, 2015, at 6:32 PM, Owen DeLong <owen@delong.com> wrote:
>>>=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.
>>> Here=92s the problem=85 You started at the wrong end and worked in the =
wrong direction in your planning.
>>>=20
>>> Let=92s say you=92re a national ISP. Let=92s say you want to support 4 =
levels of aggregation.
>>> Let=92s say that at the lowest level (POP/City) you serve 50,000 end-si=
tes in your largest POP/City. (16 bits)
>>> Let=92s say you plan to max out at 32 POPs/Cities per region (your numb=
er 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 th=
e 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 fo=
r =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=
round 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=
plan 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 di=
fferent end-sites =97 224 billion end-sites world wide.
>>> 224,000,000,000 / 67,000,000 =3D 3,344 (rounded up) total ISPs requirin=
g /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=
world /20s, we still have 1,045,232 remaining.
>>>=20
>>> Let=92s assume that every end-site goes with dual-address multi-homing =
(an IPv6 prefix from each provider).
>>>=20
>>> We are now left with only 1,041,888 /20s remaining. You still haven=92t=
put a dent in it.
>>>=20
>>> 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.
>>>=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 hav=
e
>>>> more than 32 customers per city. But I don't think it's a very
>>>> far-fetched example.
>>> It=92s not=85 It=92s a great example of how not to plan your address sp=
ace in IPv6.
>>>=20
>>> However, if we repeat the same exercise in the correct direction, not o=
nly does each of your end-sites get a /48, you get the /20 you need in orde=
r to properly deploy your network. You get lots of space left over, and we =
still 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=
.
>>> The problem is that you not only stopped counting beans, you stopped co=
unting bean piles and you lost track of just how big the pile that you are =
making smaller piles from really is.
>>>=20
>>> I hope that this will show you a better way.
>>>=20
>>> Owen
>=20
