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

Tue Jan 25 00:46:19 UTC 2011

On Jan 24, 2011, at 4:10 PM, Ricky Beam wrote:

> On Mon, 24 Jan 2011 15:53:32 -0500, Ray Soucy <rps at maine.edu> wrote:
>> Every time I see this question it' usually related to a fundamental
>> misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
> 
> Not exactly.  If it's a point-to-point link, then there are *TWO* machines on it -- one at each end; there will *always* be two machines on it.  There's no sane reason to assign 18trillion addresses to it.  Yes, in this respect it's like not wasting an IPv4 /24, but it's also The Right Tool For The Job.(tm)  If one were to assign a /64 to every p-t-p link in the world, IPv6 address space would be used at an insane rate. (and those assignments aren't free.) Do people not remember the early days of IPv4 where /8's were handed out like Pez?
> 
Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. To put this in
perspective...

There are roughly 30,000 ISPs on Earth.

The largest ISPs have thousands (not tens of thousands) of point-to-point links.

Even if we assume 30,000 Point to point links per ISP and 60,000 ISPs,
you still only used 1,800,000,000 /64s. The remaining 
18,446,744,071,909,551,616 are still available for other uses.

I think a use that does not effect the first 11 significant digits of the
total address space is hard to call "used at an insane rate".

Yes, I remember the early days. Now, let's compare the population
of the internet in those days (60+ organizations vs 256 /8s) to the
current ratio we're talking about (let's be generous and say there
are two end sites for every person on the planet...
12,000,000,000 vs. 281,474,976,710,656/48s).

In the former case, we're talking about a known population representing
23% of all available address space.

In the IPv6 case, we're talking about a generous potential estimate of
the population being less than 0.0043% of the available address space.

>> That said.  Any size prefix will likely work and is even permitted by
>> the RFC.  You do run the risk of encountering applications that assume
>> a 64-bit prefix length, though.  And you're often crippling the
>> advantages of IPv6.
> 
> And such applications are *BROKEN*.  IPv6 is *classless* -- end of discussion.
> 
> /64 (and /80 previous) is a lame optimization so really stupid devices can find an address in 4 bytes of machine code.  This is quite lame given all the other complex baggage IPv6 requires.
> 
> And then /64 is only required by SLAAC, which you are not required to use.
> 
I disagree. There are many useful optimizations that come from /64 other than
just SLAAC. However, SLAAC is also a very useful tool.

> 
>> 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. It preserves what I
like to call the principle of least surprise (the less you surprise the
operators, the less likely they are to make mistakes) and it provides
a very clean, easy to comprehend boundary that works in virtually
any application. You never have to worry about outgrowing your
subnet. SLAAC works wherever you want it to. You don't have to keep
track of complex tables of allocations and optimizations of how you
carved things up at the individual subnet level. You can focus on
optimizing how you carve up aggregates of /64s into regions
or sites or whatever.

Personally I'm also a fan of using a /48 per site as well, allowing
better concentration on optimizing the higher levels of the addressing
hierarchy without getting buried in the minutiae of individual subnets.

>> Another thing to consider is that most processors today lack
>> operations for values that are larger than 64-bit.  By separating the
>> host and network segment at the 64-bit boundary you may be able to
>> take advantage of performance optimizations that make the distinction
>> between the two (and significantly reduce the cost of routing
>> decisions, contributing to lower latency).
> 
> IPv6 is classless; routers cannot blindly make that assumption for "performance optimization".
> 
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.

>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6
>> networks.  I don't think this will be a common or wide-spread problem.
> 
> Myopia doesn't make the problem go away.  The point of such an attack is not to "find things", but to overload the router(s). (which can be done rather easily by a few dozen machines.)
> 
Only if you don't deploy reasonable mitigation strategies.

Owen