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/