On Mar 11, 2011, at 5:53 AM, Jeff Wheeler wrote:
On Thu, Mar 10, 2011 at 10:51 PM, George Bonser <gbonser@seven.com> wrote:
And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon.
Again, this is the argument put forth by the "RFC wavers," that you can't solve the problem because you must want to configure /64s for ... what, exactly? Oh, right, SLAAC. More on that below.
If I'm a content provider, I don't have to configure a /64 for my content farm. I can configure a /120 or whatever subnet size is practical for my environment. I can also use link-local addressing on my content farm LANs and route subnets to my content boxes, if that is somehow more practical than using a smaller subnet.
Yes, you can bring as much of the pain from IPv4 forward into IPv6 as you like. You can also commit many other acts of masochism. Personally, I prefer to approach IPv6 as a way to reduce some of the more painful aspects of IPv4, such as undersized subnets, having to renumber or add prefixes for growth, limited aggregation, NAT, and more.
If you are a service provider where practically all of your links are point to points, sure.
No, you can avoid configuring /64s if you don't need SLAAC. Who needs SLAAC? I don't. It has absolutely no place in any of my environments. It seems to me that DHCPv6 will do everything which SLAAC does, and everything SLAAC forgot about. The "complexity" argument is pretty much indefensible when the trade-off is configuring DHCPv6 vs turning a bunch of router knobs and hoping no one ever targets your LANs with an NDP DoS.
SLAAC is a very useful and convenient way to deal with client networks. I would agree it's of limited use in a content provider scenario, but, there is utility to /64s beyond just SLAAC. Yes, they are a hard requirement for SLAAC.
We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore.
None of that "standard IPv6 automatic stuff" works today, anyway. The state of IPv6 support on end-user CPE generally ranges from non-existent to untested to verified-to-be-broken. This is the only place in your network where /64 can offer any value, and currently, CPE is just not there. Even the latest Cisco/Linksys CPE does not support IPv6. Sure, that'll change; but what won't change is the total lack of any basis for configuring /64 LANs for "content farms" or any similar non-end-user, non-dynamic segments.
As someone using SLAAC in a number of environments, I'm confused by this statement. It seems to be working quite well in many places and end-user residential networks are certainly not the only places where it is useful. Yes, residential end-user CPE is rather limited and somewhat less than ideal today. I would argue that there are probably at least as many end-user hosts on non-residential networks that could take advantage of SLAAC if the administrators wanted to.
I don't want 16 bits of host addressing. I want to choose an appropriate size for each subnet. Why? Because exactly zero of my access routers can handle 2**16 NDP entries, let alone 2**16 entries on multiple interfaces/VLANs. I would like to see much larger ARP/NDP tables in layer-3 switches, and I think vendors will deliver on that, but I doubt we'll soon see even a 10x increase from typical table sizes of today. VPS farms are already pushing the envelope with IPv4, where customers are already used to conserving addresses. Guess what, customers may still have to conserve addresses with IPv6, not because the numbers themselves are precious, but because the number of ARP/NDP entries in the top-of-rack or distribution switch is finite.
What do your access routers have to do with your content farm? Sounds like you've got some pretty darn small access routers as well if they can't handle 64k NDP entries. Yes, larger tables in switches would be a good thing, but, I hardly think that's a reason to use smaller netmasks. Most of the top-of-rack switches I'm aware of have no problem doing at least 64k NDP/ARP entries. Many won't do more than that, but, most will go at least that far.
And again, are you talking about all the way down to the host subnet level? I suppose I could configure server farms in /112 or even /96 (/96 has some appeal for other reasons mostly having to do with multicast) but then I would wonder how many bugs that would flush out of OS v6 stacks.
I'm not getting reports of problems with smaller-than-/64 subnets from customers yet. Am I confident that I never will? No, absolutely not! Like almost everyone else, I have some customers who have configured IPv6, but the amount of production traffic on it remains trivial. That is why I allocate a /64 but provision a /120 (or similar practical size.) I can grow the subnet if I have to. I do know that /64 LANs will cause me DoS problems, so I choose to work around that problem now. If /120 LANs cause me OS headaches in the future, I have the option to revise my choice with minimal effort (no services get renumbered, only the subnet must grow.)
How many customers are using smaller-than-/64 subnets to do much of anything yet? I find it interesting that you _KNOW_ that /64 LANs will cause you DoS problems and yet we've been running them for years without incident. I believe growing the subnet still requires you to touch every machine unless they're getting all their configuration from DHCP. Again, sounds like an exercise in unnecessary masochism to me.
Why would you suggest /96 as being more practical than /64 from the perspective of NDP DoS? Again, this is an example of the "in-between" folks in these arguments, who seem not to fully understand the problem. Your routers do not have room for 2**(128-96) NDP entries. Typical access switches today have room for a few thousand to perhaps 16k, and typical "bigger" switches are specifying figures below 100k. This doesn't approach the 4.3M addresses in a /96. In short, suggesting /96 is flat out stupid -- you get "the worst of both worlds," potential for OS compatibility issues, AND guaranteed NDP DoS vulnerability.
Yeah, in-between makes little sense. Kind of worst of both worlds. On that we can at least agree. As to your /96, that's 4.3B, not 4.3M. (at least last I looked, 2^32 was 4.3B and 4.3M was approximately a /114).
passing traffic. That doesn't protect against rogue hosts but there might be ways around that, too, or at least limiting the damage a rogue host can cause.
How do you suggest we limit the damage a rogue host can cause? A lot of people would like to hear your idea. Again, in nearly ten years of discussing this with colleagues, I have not seen any idea which is more practical than configuring a /120 instead of a /64. I have not seen any idea, period, which doesn't involve configuring the IPs which are allowed to be used on the LAN, either on the access switch port (NDP inspection), the access router, or in a database (like RADIUS.)
There are several things that could eventually be implemented in the access switch software. Techniques like rapidly timing out unanswered NDP requests, not storing ND entries for SLAAC MAC-based suffixes (after all, the information you need is already in the IP address, just use that). Not storing ND entries for things that don't have an entry in the MAC forwarding table (pass the first ND packet and if you get a response, create the ND entry at that time), etc. Yes, these all involve a certain amount of changing some expected behaviors, but, those changes could probably be easily accommodated in most environments. Finally, the bottom line is that a rogue host behind your firewall is probably going to cause other forms of damage well before it runs you out of ND entries and any time you have such a thing, it's going to be pretty vital to identify and remove it as fast as possible anyway.
I'm glad SLAAC is an option, but that's all it is, an option. /64 LANs must also be considered optional, and should be considered useful only when SLAAC is desired.
They are entirely optional, but, IMHO, avoiding them at all costs such as you seem to be suggesting is unnecessarily painful in most environments.
Something will have to be done at some point ... soon.
I'm glad more people are coming around to this point of view. Cisco certainly is there.
I'd settle for Cisco coming to the point of having RA guard universally available on all switch products. That, to me, is a much more pressing issue than this imagined ND exhaustion attack which, in reality, requires near DDOS levels of traffic for most networks to actually run the ND table meaningfully into overflow. Owen