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