On 1/5/11 8:49 AM, Jeff Wheeler wrote:
On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used
It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive.
It appears you want to have a semantic argument. I could grant that, and every point in my message would still stand. However, given that the necessary knobs to protect the network with /64 LANs do not exist on any platform today, vendors are not talking about whether or not they may in the future, and that no implementation with /64 LANs connected to the Internet, or any other routed network which may have malicious or compromised hosts, "design flaw" is correct.
This is a much smaller issue with IPv4 ARP, because routers generally have very generous hardware ARP tables in comparison to the typical size of an IPv4 subnet.
no it isn't, if you've ever had your juniper router become unavailable because the arp policer caused it to start ignoring updates, or seen systems become unavailable due to an arp storm you'd know that you can abuse arp on a rather small subnet.
You seem to think the issue is generating NDP NS. While that is a part of the problem, even if a router can generate NS at an unlimited rate (say, by implementing it in hardware) it cannot store an unlimited number of entries. The failure modes of routers that have a full ARP or NDP table obviously vary, but it is never a good thing. In addition, the high-rate NS inquiries will be received by some or all of the hosts on the LAN, consuming their resources and potentially congesting the LAN. Further, if the router's NDP implementation depends on tracking the status of "incomplete" on-going inquiries, the available resource for this can very easily be used up, preventing the router from learning about new neighbors (or worse.) If it does not depend on that, and blindly learns any entry heard from the LAN, then its NDP table can be totally filled by any compromised / malicious host on the LAN, again, breaking the router. Either way is bad.
This is a fundamentally different and much larger problem than those experienced with ARP precisely because the typical subnet size is now, quite literally, seventy-quadrillion times as large as the typical IPv4 subnet.
On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use.
It would certainly be nice to have a stateful firewall on every single LAN connection. Were there high-speed, stateful firewalls in 1994? Perhaps the IPng folks had this solution in mind, but left it out of the standards process. No doubt they all own stock in SonicWall and are eagerly awaiting the day when "Anonymous" takes down a major ISP every day with a simple attack that has been known to exist, but not addressed, for many years.
You must also realize that the stateful firewall has the same problems as the router. It must include a list of allocated IPv6 addresses on each subnet in order to be able to ignore other traffic. While this can certainly be accomplished, it would be much easier to simply list those addresses in the router, which would avoid the expense of any product typically called a "stateful firewall." In either case, you are now maintaining a list of valid addresses for every subnet on the router, and disabling NDP for any other addresses. I agree with you, this knob should be offered by vendors in addition to my list of possible vendor solutions.
On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away.
I do not conceptually disagree with sparse subnets. With the equipment limitations of today, they are a plan to fail. Let's hope that all vendors catch up to this before malicious people/groups.