On Fri, Mar 11, 2011 at 1:07 PM, <Valdis.Kletnieks@vt.edu> wrote:
Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions.
Why should SLAAC dictate the size of *every subnet* on the IPv6 Internet? This is what people who I label "IPv6 Fundamentalists" wish to do. They refuse to admit that their ideas were conceived in the mid-90s, that technology has advanced a great deal since that time, and ARP/NDP is a real limit now, while VLSM is no longer a tough challenge (vendors have had a couple decades to make it work really well!) I think there are a lot of people who throw around the SLAAC argument like it's actually good for something. Do these people know what SLAAC does? For core networks, it doesn't do anything. For hosting/datacenter networks and cluster/VPS environments, again, it doesn't do anything. Zero benefit. You probably don't configure these things using DHCP today. Wait, you do? Oh, it's a good thing we've got DHCPv6, which clearly can run alongside your DHCP for IPv4. Is SLAAC for end-user access networks? Not so much. See recent discussions on this list about things which are not included in SLAAC that DHCPv6 does do today. SLAAC can provide an advantage if you can live without those things, but that advantage is limited to one thing: the subnet doesn't need a DHCPv6 server (or proxy/forwarding of packets to same.) IPv4 has gotten along just fine for a long time with both full-featured and light-weight DHCP servers, and statically configured subnets. Is SLAAC solving any problem? Sure, for some situations, like SOHO networks, it's a nice option, but it's just that, an option. It isn't needed. Is SLAAC for fully peer-to-peer networks, with no central gateway? No. To function, SLAAC requires an RA message from something that decides it is a router. It isn't going to facilitate a headless, ad-hoc network to support the next revolution with peer-to-peer cell phones. So what we know is that the sole arguments from "IPv6 Fundamentalists" in favor of /64 LANs are * VLSM is hard (it isn't; vendors are really good at it now, otherwise IPv4 wouldn't work) * SLAAC needs it to work (not all LANs need SLAAC) * it's the standard (more on this below) I believe everything except the "it's the standard" argument is fully and completely debunked. If anyone disagrees with me, feel free to correct me, or argue your point until you are blue in the face. I have often been reminded that I should have been more vocal about this matter 10+ years ago, but frankly, I thought vendors, large ISPs, veterans with more public credibility than myself, or the standards folks themselves, would have straightened this out a long time ago. If you can decide for yourself that VLSM is easy and you trust your vendor to do it right (if you don't, summarize to /64 towards your core, or do one great thing IPv6 allows us to do, and summarize to *even shorter* prefixes towards your core, and carry fewer routes in core) then you are half-way there. If you realize SLAAC isn't a tool for your VPS farm or on your backbone link-nets, you're all the way there. At this point, you can deploy your IPv6 without it being broken by design. The only thing broken here is the "Fundamentalists," who are stuck in a mid-1990s mindset. These guys need to get out of the way, because they are impeding deployment (for those smart enough to recognize this problem) and they are creating an almost certain need for a future re-design (for those who aren't smart.) This "future" doesn't depend on anything except v6 actually getting deployed enough to where DDoS happens over it at any appreciable scale. In the current state of the Internet, it is certain that this problem will happen. No visible progress has been made on solving it, except by guys like myself who are happy to cry "the sky is falling," configure our networks in a "non-standard" way, and tell the standards folks they are wrong. The Cisco knob is "progress" only in that Cisco recognizes customers are concerned about this problem and allow them to steer their failure mode. If the DDoS happens before vendors provide a real solution, or before standards are revised or thrown out, you can thank those of us on the "sky is falling" side of this argument for testing the work-around (by never having exposed ourselves to the problem in the first place.)
It's one thing to say "it should be redesigned". It's another matter entirely to actually come up with a scheme that doesn't suck even harder than "screw it, it's a /64".
This is true. I think the price of energy is continuing to rise and our future is very uncertain as a result. I don't know how to fix it. Does that mean I should keep my opinion to myself? Of course not. Recognizing a problem is the first step on the path to a solution. I imagine the same arguments taking place before VLSM and again before CIDR, which pre-dates my entry into this field by a few years. I don't think most people in our field today understand why the IPv6 standard ended up the way it did. They haven't been around long enough to understand the context of IPv6 being developed in what was truly a different era. I don't have a better idea for SLAAC, in large part because I do not care about SLAAC. I don't think SLAAC should dictate the size of *every subnet.* I do think SLAAC should be an *option* available to those who want it on a given LAN. I've got three feasible "fixes" to the NDP flooding problem. One is dead simple: don't configure /64 LANs. How hard is that? It's a lot easier than the alternatives. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts