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.
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.
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. 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.
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.) 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.
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.) This kind of configuration complexity is exactly what SLAAC hoped to avoid. Unfortunately, the folks who thought that up did so at a time when most access routers were still routing in CPU and main memory, not ASIC. It's important to understand how the underlying technology has changed in the past 15+ years -- if you don't, you must think, "man, those IPv6 standards guys were idiots." They weren't idiots, but they didn't know how routing and switching hardware would evolve, certainly they did not know how long it would take IPv6 to be deployed (it still isn't, effectively), and they probably didn't consider the potential future where DDoS is rampant and virtually unchecked to be a good reason not to craft SLAAC into the standards. They were also coming out of an era where CIDR/VLSM was still kinda new, and I believe there were *zero* boxes at that time which could "route" at wire speed, vs many boxes that would switch at wire speed, thus there were perceived advantages to having fewer, bigger subnets with no requirement for VLSM. Remember when there was no such thing as a layer-3 switch, and installing an RSM in your Cat5500 to get a little bit of routing capability was the greatest thing since sliced bread? This is where IPv6 came from, and it is why we have these design problems today -- the standards people are ideologically married to ideas that made perfect sense in the mid-90s, but they forgot why those ideas made sense back then and don't understand why this is not practical today. 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.
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. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts