[121724] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jan 25 20:01:11 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4B5DE7E6.7000200@cox.net>
Date: Mon, 25 Jan 2010 16:58:29 -0800
To: Larry Sheldon <LarrySheldon@cox.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 25, 2010, at 10:50 AM, Larry Sheldon wrote:
> On 1/25/2010 4:45 AM, Richard A Steenbergen wrote:
>> On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
>>> There are 4,294,967,296 /64s in my own /32 allocation. If we only =
ever
>>> use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952
>>> /64s. This is enough to fill over seven Lake Eries. The total =
amount
>>> of ipv6 address space is exponentially larger still - I have just =
looked
>>> at 2000::/3 in these maths.
>>>=20
>>> THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
>>=20
>> Don't get carried away with all of that "IPv6 is huge" math, it =
quickly
>> deteriorates when you start digging into it. Auto-configuration =
reduces
>> it from 340282366920938463463374607431768211456 to =
18446744073709551616
>> (that's 0.000000000000000005% of the original 128 bit space). Now as =
an
>> end user you might get anything ranging from a /56 to a /64, that's =
only
>> between 1 - 256 IPs, barely a significant increase at all if you were =
to
>> actually use a /64 for each routed IP rather than as each routed =
subnet.
>> As a small network you might get a /48, so that even if you gave out
>> /64s to everyone it would be only 16 bits of space for you (the
>> equivalent of getting a class B back in IPv4 land), something like a
>> 8-16 bit improvement over what a similar sized network would have =
gotten
>> in IPv4. As a bigger ISP you might get a /32, but it's the same =
thing,
>> only 16 bits of space when you have to give out /48s. All we've =
really
>> done is buy ourselves an 8 to 16 bit improvement at every level of
>> allocation space (and a lot of prefix bloat for when we start using =
more
>> than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we
>> can give every molecule an IPv6 address" math of the popular
>> imagination. :)
>=20
> And it does not account for the factor that I was trying to shine a =
light on--the it-is-infinitely-huge is at risk of failing due to =
inventions we can not conceive of.
>=20
> Who knew, in the 1940's that every person would be assigned as many as =
five or more telephone numbers (exaggeration? In this house, occupied =
by two people there are 4 addressable PSTN devices, only one of which =
leaves the house if one of us does, and there are 6 devices that share =
an address but could easily have individual addresses, and would if we =
were using one of the VOIP services).
>=20
Sure, but, to put this in perspective, the entire 10-digit NANP could be =
numbered in a single /64 with several
copies of NANP worth of addresses left over...
NANP: 1,000,000,000 addresses.
/64: 18,446,744,073,709,551,616 addresses
An RIR /12 contains enough end-user /48s to hold NANP and then some:
NANP: 1,000,000,000 addresses
/12: 68,719,476,736 /48s (End User Sites)
/12: 1,048,576 /32s (ISPs) (there are currently less than 50,000 =
registered phone companies)
> Who knew in the 1980's that refrigerator's would need IP addresses? =
(We should not have been surprised, Coke machines did.)
>=20
As to refrigerators, probably all the appliances in a house can share a =
handful of subnets. A /56 per household
provides for MANY appliance networks as well as separate networks for =
just about everything else you can
imagine. Worst case, even if all households end up with /48s the =
address space is still sufficient.
> And for all the concern about IPv4 exhaustion, what would have =
happened if the people who fought fiercely against RFC 1918 had won the =
day?
>=20
IPv6 deployment would be a lot further along and we wouldn't have spent =
nearly so much money
overcoming the pitfalls and problems created by NAT. We wouldn't now =
have to spend even more
money trying to get past the errant NAT=3DSecurity thinking.
> Yes the numbers in IPv6 are huge, no doubt about it.
>=20
> But I say, to say "impossible to exhaust" is a fools errand. Somebody =
will find a way to exhaust the pool, just to be contrary, if for no =
currently recognized "legitimate" reason.
>=20
No, they're not impossible to exhaust, just pretty difficult.
However, If we see exhaustion coming too soon in this /3, we can always =
apply a more conservative
numbering policy to the next /3. (And still have 5 /3s left to innovate =
and try other alternatives).
Owen
