Using IPv6 with prefixes shorter than a /64 on a LAN

Owen DeLong owen at delong.com
Tue Jan 25 22:06:18 UTC 2011


On Jan 25, 2011, at 1:17 PM, Ricky Beam wrote:

> On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong <owen at delong.com> wrote:
>> Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s.
> 
> Those who don't learn from history are doomed to repeat it.
> 
Correct, but...

> "Dude, there are 256 /8 in IPv4."
> 
There still are. The difference is that at the time that was said, there were 60 odd
organizations that were expecting to connect to the internet and growth wasn't
expected to exceed ~100.

Today, there are billions of organizations, but, growth isn't expected to hit
a trillion. As such, I think 281,474,976,710,656 (more than 281 trillion)/48s
will cover it for longer than IPv6 will remain a viable protocol.

> "640k ought to be enough for anyone."
> 
If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959
terabytes of RAM. I'd argue that while 640k was short sighted, I think it is
unlikely we will see machines with much more than a terabyte of RAM
in the lifetime of IPv6.

> People can mismange anything into oblivion.  IPv6 will end up the same mess IPv4 has become. (granted, it should take more than 30 years this time.)
> 
IPv4 is not a mess. IPv4 was not mismanaged in my opinion. IPv4 was
properly managed to the best use of the purposes intended at the time.
The uses evolved. The management evolved. We have now reached
the end of the ability to evolve the management enough to continue to
meet the new uses.

As a result, we're now deploying IPv6. IPv6 has learned from the
history of IPv4 and instead of having enough addresses for all
anticipated needs, it has enough addresses to build any conceivable
form of network well beyond the size of what can be expected to
function within the bounds of the protocol.

>> The largest ISPs have thousands (not tens of thousands) of point-to-point links.
> 
> Having worked for small ISPs, I can count over 10k ptp links.  That number goes way up when you count dialup and DSL.
> 
Most people don't implement DSL as point to point. Usually, instead, it is
done as a point to multipoint addressing structure. Using a /64 per DSLAM
is not an issue.

Can you still count over 10k point to point links if you just look at the ones
that need to be numbered? 8,192 /30s is a /15 of address space. That's
not a small provider by almost anyone's definition of the term small.

>>>> You should think of IPv6 as a 64-bit address that happens to include a
>>>> 64-bit host identifier.
>>> 
>>> No, you should not.  That underminds the fundamental concept of IPv6 being *classless*.  And it will lead to idiots writing broken applications and protocols assuming that to be true.
>>> 
>> True, but, in terms of deploying networks, unless you have a really good
>> reason not to, it is best to use /64 for all segments.
> 
> Again, the only reason for this /64 class boundry is SLAAC.  The network is still 128 bits; you still have to pay attention to ALL of those bits.
> 
> (Remember, SLAAC started out as a /80.)
> 
So?

>> Blindly, no. However, it's not impractical to implement fast path switching that
>> handles things on /64s and push anything that requires something else
>> to the slow path.
> 
> Any router that does CPU switching is already trash.  High speed, low latency routing and switches is done in silicon (fpga's); it is not hoised to a general purpose CPU.
> 
Depends on the application. If you're talking core backbone, sure.
If you're talking workgroup switch/router, then, it's a different story.

The number of running quagga boxes present in the internet and the
number of deployed Juniper J-Series and SRX-series platforms
would seem to prove your statement wrong.

Owen





More information about the NANOG mailing list