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

Tue Jan 25 14:44:44 UTC 2011

On Mon, Jan 24, 2011 at 7:10 PM, Ricky Beam <jfbeam at gmail.com> 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?

Not sure we disagree?  I happily use 126-bit prefixes on
point-to-point networks.  The discussion is on LAN networks, though.

>> 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.

Yes, they are broken, but if you think the fact that 1% of users using
prefixes smaller than 64-bit will make those bad developers change
their ways I'm not sure what to tell you.  The horse has already left
the barn on that one.  But I'm not going to stop you from using
120-bit prefixes on all your networks if that's what you want.

Having to shuffle LAN networks around because they no longer have the
address space to support the number of hosts on it goes away if you
stick with the 64 rule.  DoS problems exists regardless of the prefix
length.  I'd rather find a solution to the problem than simply try to
mitigate it by turning IPv6 into IPv4.

> /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.
>
>
>> 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.

IPv6 is classless.  You can have any size prefix you want.  Chopping
off the last 64-bits and calling it a host segment essentially turns
IPv6 into a 64-bit address that will never have a need for PAT (NAT
overload) which was the reasoning to go with the 128-bit address
space.  You can use any size prefix you want for routing.

Are you of the mindset that everyone should use a 120-bit prefix for
each network, then advertise each of those into BGP without route
aggregation?  I'm not really sure where you're going here.

The argument can also be made that using smaller prefixes with
sequential host numbering will lead to making network sweeps and port
scanning viable in IPv6 where it would otherwise be useless.  At that
point you just need evidence of one IPv6 address being in use and you
know that a few hundred next to it have the interesting hosts
connected.

>> 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".

I'm not saying its make-or-break.  It certainly does help.  Especially
when we're trying to shave nanoseconds off.  I don't foresee 128-bit
CPUs simply to accommodated IPv6 anytime soon.  These kinds of
optimizations happen every day already in other applications.  IPv6
will likely be no different as vendors begin to compete on who has the
best IPv6 hardware.

>> 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.)
>
> --Ricky
>

Neither does avoiding it until it gets ignored?  There are plenty of
solutions and best practices that have nothing to do with the prefix
length.  I'm saying that you shouldn't use the possibility of a
specific type of DoS attack (that is less attractive to attackers than
nearly every other type of DoS attack out there) be your determinant
for what prefix length you use.  If an attacker wants to DoS a router
and has the capacity to use this attack vector, they also have the
capacity to achieve it with a dozen other ones.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/