IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

Wed Nov 30 14:48:49 UTC 2011

Yikes, Owen.  That's a lot of responses...

Saying you can mitigate neighbor table exhaustion with a "simple ACL"
is misleading (and you're not the only one who has tried to make that
claim).

You can mitigate it by:

1. Using a stateful firewall (not an ACL) outside the router
responsible for the 64-bit prefix.  This doesn't scale, and is not a
design many would find acceptable (it has almost all the problems of
an ISP running NAT)

2. Using a "simple ACL" that drops traffic to any address not in use.
This has the inherent problem that for it to be successful, it either
needs to: a) dynamically update (e.g. some sort of captive portal
system, where hosts have to register to get access to the outside), or
b) defined as a subset of a 64-bit prefix (e.g. only allow a /126 of
the prefix).

I would put forward the argument that if you're going to call it a
"simple ACL" it's not a dynamic ACL (NAC), so you must be talking
about the second option.

If you're going to create a network that is a /64 and then create an
ACL that only allows traffic to a subset of that prefix; then you
can't use SLAAC, privacy addressing, or any other features that a /64
would provide; what you do get is increased demand on routing
infrastructure to be running many, many, many, ACLs to avoid a problem
that could be avoided by using a longer prefix.

So I'm not really seeing your argument here.  The fact that you apply
the ACL breaks the functionality you're claiming to preserve; and adds
more overhead to your infrastructure in the process.

I could be wrong, but I don't think ACL performance would scale well
if you were doing this dynamically, either.  All traffic having to
traverse an ACL with thousands of statements every packet; it might be
fine for a FCC "broadband" connection of 768K, but if you're providing
people with actual broadband (Gigabit or greater) the cost becomes
very high.  I personally don't want my latency or bandwidth affected
because of excessive use of ACLs and a "drop everything by default"
policy.

As for never seeing an neighbor table exhaustion attack "in the wild".
 I haven't experienced it for IPv6, but I have experienced it for
IPv4, for sites that chose to use a 16-bit prefix for every internal
network (even though they only needed a hundred host addresses).

The only thing preventing it from being an external attack was the
fact that it was safely behind NAT.

With IPv6 that same problem is exposed to external attacks.  I didn't
buy it either until I sat down and was able to quickly reproduce it.
Does that mean I'm going to attack a network just to prove a point?
Of course not.

The fact that it hasn't happened yet (or the people its happened to
haven't realized it is what has happened; which is a bigger issue)
doesn't mean it's a non-issue.

DoS attacks are typically targeted at disrupting highly visible
services; since the vast majority of users on the Internet don't have
IPv6 access; and what IPv6 access is out there is unstable enough on
its own (thanks to people throwing up firewalls that drop all ICMPv6
traffic), it's not exactly a vector anyone cares about right now.  But
that will change as adoption grows.

I think the point is that you can easily avoid this attack vector
today by using longer prefixes for now; and growing a prefix from a
/120 to a /64 is a very easy change.  The opposite is just not true;
even if that is accomplished with an ACL rather than changing the
prefix on the router.  Once you have hosts using addresses, it's not
something you can take away easily without being disruptive (plenty of
experience with such situations as we use public IPv4 for the majority
of our networks; not NAT).

You keep talking about "purists" as if it's a dirty word, but then
proceed to go on about how every network should be a 64-bit prefix,
absolutely.

You've gotta see the humor in that. ;-)

Before we spun this out of control, the OP was asking if there was any
problem using prefixes longer than 64-bit in a DOCSIS environment.

There is no problem using a prefix-length other than 64.  We do it in
production and have not actually encountered a single issue as a
result.  You don't get SLAAC, but SLAAC isn't really desirable for a
lot of the networks we're talking about (link networks, enterprise LAN
networks, etc).  Client systems with mature and stable IPv6 stacks
(which are the only systems we care about giving IPv6 to) "just work",
even when using DHCPv6 and 120-bit prefixes.

If you make use of a prefix longer than 64, but reserve the full
64-bit prefix in your allocation schema, then you can easily migrate
from something like a 120 or 126 to a 64; the same is not true for the
reverse.

If your DOCSIS system has some sort of dynamic ACL system in place
already that is able to open up "registered" connections; then you're
immune from the attacks discussed.  If it doesn't you'll want to find
a way to address that (pun intended).

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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