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

Owen DeLong owen at delong.com
Wed Nov 30 04:19:17 UTC 2011


> That said; neighbor table exhaustion is a real problem.  A few lines
> of C can kill IPv6 on enterprise- and carrier-grade routers.  It's a
> problem that has gone largely ignored because people are still in a
> private address space mindset.
> 

Only if you don't have rational ACLs in place or you are compromised
from within. If you're compromised from within, this attack makes it
easy to identify and resolve the compromised boxes, so, it's a net win.

> We use 126-bit prefixes for link networks (we would have used 127, but
> the arguments against them in RFC 3627 were compelling enough to avoid
> them; after all we don't have a lack of space).  There are a few
> reasons for this:
> 

That's obsolete and only applies to buggy routers that have implementations
that comply with an RFC deprecated more than 5 years ago.

> 1. It let's us keep link address short by using the beginning of our
> allocation (e.g. you'll see things like 2610:48::66 in traceroutes to
> us), which are easily memorized in the event of DNS failure (face it;
> there are still some addresses you'll memorize; even if they are
> IPv6).
> 
Doing this with /64s out of the first /xx of your allocation/assignment
can work equally well. For /32s, I usually suggest reserving the first /48,
for example. Scale according to your particular networks needs.

There's not a whole lot of difference between remembering
2610:48:0:66::1 vs. 2610:48::66. If you wanted to get really cute
about it, you could even go with 2610:48:0:66:1:: using the
2610:48:0:66:2:: for the other end of the link. (yes, those are
both valid /64 static addresses).

> 2. We know that the number of hosts on these networks is finite; it
> will always be 2, so using a 64-bit prefix isn't useful in any way;
> and until we see routers hardened against neighbor table exhaustion,
> they're actually harmful.
> 

You can easily harden against this in a variety of ways. Yes, vendors
should provide additional features in this area. But until they do, you
can take out 99% of the attack surface with very simple ACLs.

> 3. We have thousands of link networks; giving them all a 64-bit prefix
> seems rather wasteful.
> 

So I have to ask... What do you do with all those prefixes you didn't
use? You can waste them in a router or you can waste them on a shelf.
Either way, they're idle addresses not being used.

> We've been running IPv6 in production since 2009, and when we first
> jumped into it I was in the same camp of being a purist; thinking
> SLAAC was the best; that DHCPv6 wasn't needed; that every network
> should always be a 64-bit prefix; etc.
> 

I think SLAAC and DHCPv6 both have their issues. Primarily because
a bunch of purists from both camps spent all their time in the IETF
damaging the other camp's protocol instead of perfecting their own.
Hopefully now that the IETF is starting to get some additional input
from actual operators this will eventually get corrected (on both sides).

> A few years of experience with using IPv6 in an operational
> environment has taught me otherwise.

Are you saying you've seen actual ND attacks actually attack
your production network other than deliberate tests? So far,
I haven't seen or heard of an actual ND attack in the wild.

> I'm not saying posts on list about not using anything but a 64-bit
> prefix are wrong; but it's a little more complicated than
> one-size-fits-all networking.

Agreed. However, there's a lot to be said for one-size-fits-all and
if you just mitigate the ND attack issue with simple ACLs, you're
back to a place where one-size-fits-all works pretty well.

> It is perfectly valid to make use of prefixes other than 64-bit; so
> long as you understand the implications of doing so.

Absolutely. It's more likely to cause you harm than do you any
good, but, you can run your network however you see fit.

> SLAAC is a great bootstrapping mechanism for ad-hoc networking; and
> the link-local scope (allowing all IPv6 traffic to happen over IPv6;
> even neighbor discovery).  Just because it's a neat and useful way of
> addressing doesn't mean it's the best way for every network.
> Different strokes for different blokes and all that.

You'll have a link-local with at least a /64 anyway on every link.
(Technically link-local is supposed to be a /10)

> To those who noticed me and Owen seem to have this argument on-list a
> few times a year, sorry for the recycled content. ;-)

And yet you still don't just accept that I'm right and move on. ;-)

But at least it gives us a break from those that think NAT is somehow
relevant to security.

Owen





More information about the NANOG mailing list