IPv6 is an opportunity/excuse to make networks make sense - think about what you really want your architecture to be, plan it and start migrating to that. IF that means adding something to v6, great - do it, solve problems. I am not saying "the way we do it know" is always just a bad excuse, but when it is _just_ that maybe the situation needs another look :) ... (Specifically - on an enterprise side - Align "life cycle refresh" and IPv6 deployment; once the "IPv4 only things" are identified they will simply not be migrated to new dual-stack segments ... Easy!) (Oh - As for SLAAC, you can just do the default gateway part and still use DHCPv6 for the rest ... I have yet to see implementations that ignore A=0, and have never tried of using ~/80s to force non-autoconf.(My gut says the odds of hosts mis-handling a /80 are far greater than ignoring A=0 :) )) In the end - I agree that SLAAC and DHCPv6 both fulfill valid roles ... /TJ ... Not (just) an idealist :) Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Ray Soucy <rps@maine.edu> Date: Sun, 18 Oct 2009 17:38:26 To: Steven Bellovin<smb@cs.columbia.edu> Cc: <nanog@nanog.org> Subject: Re: IPv6 Deployment for the LAN Thanks for the response, if only to force me put my thoughts down into words. On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:
...
My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking.
Not my place to implement policy; I'm not a lawyer. We already have monitoring in place for accountability that maps each address used on a network (regardless of IP or IPv6) to a device and interface for incident response. The greater concern is that SLAAC makes IPv6 available to hosts that may not be prepared for it. If administrators are asked if they would like IPv6 enabled, having been explained the implications of such if SLAAC is used for configuration, the majority of the time they come back and say "thanks, but no thanks." In this situation, SLAAC is holding back deployment of IPv6. I suspect other have seen this as well. Part of the problem here is that IPv6 isn't new; it's old. Implementations have been in place for years on certain systems without proper testing as they have gone largely unused. We've seen cases where older versions of Linux can be crashed by enabling SLAAC on a network being one example. By using DHCPv6 we gain some advantages: We can automatically update DNS for hosts so that IPv4 records and IPv6 records match; We have the ability to roll out DHCPv6 on a per-host basis without causing problems on the production IP network; and we can roll it in to our existing [home grown] tools for network management in a way that is easy for users of the system to understand (keep in mind, we provide tools to delegate network control to hundreds of sub-administrators throughout the State). The original question here wasn't SLAAC vs. DHCPv6. I think many network operators here who are tasked with managing anything of scale will agree that SLAAC doesn't quite cut it and is often a step backwards. The overhead of implementing and administering such a system at this scale generally wins out over not doing so. The question I was mainly concerned with was if anyone has encountered issues with the use of an 80-bit prefix to prevent SLAAC from being active. While the prefix advertisement does have the autonomous flag which can be set to false, the underlying problem of IPv6 implementations not being consistent across hosts operating systems yet doesn't change. I'm not convinced that there aren't implementations out there that will enable SLAAC regardless of what the prefix flag is set to, so using a prefix other than a 64 provides an easy way to [attempt to] avoid this, all the while allowing for us to eventually migrate to a 64-bit prefix when host support improves. Another concern is that we certainly don't want to use SLAAC for servers, and I'm hesitant to promote the use of manual IP configuration as it can quickly become a nightmare if you need to move networks (admittedly there should be less need for network moves, but all the same). DHCP has long solved many of these issues in the IP world, and it is perfectly reasonable, and desirable, to apply them to IPv6 though the use of DHCPv6. Perhaps in the future, as we see less legacy hosts online we'll be in a position to make use of both SLAAC and DHCPv6 for host configuration, but in all honesty, once DHCPv6 is in place, why would you want to use SLAAC? My other question was DHCPv6 support from Apple (who seems to be one of the few in resistance of DHCPv6). This list managed to point me in the right direction to nag them about it.
I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/