There is almost no difference between having RA give out DNS information, and having an "other only" DHCPv6 server from a software standpoint. The difference is that DHCPv6 is in the application space, while RA is in the kernel space. It's easier to modify DHCPv6 than RA; so over time when we add options, we don't need to go back and modify the IPv6 implementation in every OS; just update the DHCPv6 client. We could just re-name DHCPv6 other-only mode and call it "Extended RA" if you like; it wouldn't even require any code change.
Most routers that support IPv6 also support running an "Other Only" (stateless) DHCPv6 server; it's like 3 lines of configuration and costs next to nothing. We haven't seen any DHCPv6 client implementations for "other only" but it would be equally trivial to write them. I think the general feeling, though, is that a full DHCPv6 client should be considered a requirement for any host regardless of if the network makes use of DHCPv6 for address assignment or not. On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong <o...@delong.com> wrote: > > On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: > >> In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy >> wrote: >>> Also agree that I want flexibility to use RA or DHCPv6; the >>> disagreement is that RA needs to be removed or changed from IPv6. >>> Don't go breaking my IPv6 stack for your own ambitions, please. >> >> I want that flexability as well, but the IETF won't deliver. >> >> The two options delivered so far are: >> >> RA's only. > > Only sort of... This only works if you don't want to auto-configure things > like DNS, > NTP, etc. > > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. > >> DHCPv6 with RA's to learn a default route. >> >> I want a third option: >> >> DHCPv6 only. >> >> I have no desire to remove either of the first two options. >> >> In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van >> Beijnum wrote: >>> So we agree on the problem. Now the only thing we have to do is come up >>> with a solution that everybody likes. In a greenfield situation that >>> solution could be "compile DHCPv4 for 128 bits" but guess what, we have >>> "legacy" IPv6 systems that aren't compatible with that, and we want results >>> before those systems are all killed off. >> >> There are various drafts and proposals in the IETF to solve this >> problem, and they pretty much all focus on the DHCP side of things. >> >> You see, in DHCPv6 it was decided to not implment a field for the >> default gateway or subnet mask, under the logic that the former was >> learned via RA's, and the latter was always a /64. While it's not >> quite as trivial as adding those two fields, it's not that much >> more complex. The right behavior for a host that comes up and sees >> no RA's needs to be documented. >> >> To pick on Ray for a moment, the IETF seems to largely have a similar >> attitude to Ray's. I spent a year or so trying to talk to the >> various folks involved, only to be told that I "didn't understand >> IPv6", "didn't know what I was talking about with respect to how >> RA's work", and "wouldn't want a network with only DHCPv6". I can't >> tell you how many times I had been told I clearly didn't have enough >> experience with IPv6, when we've been dual stacked for years. >> >> When I do get someone at the IETF who will listen to my operational >> issues the response is always the same as Ray's. Deploy RA guard. >> Never mind that until a year or so ago no vendors at all had it. >> Never mind that even today only a handful of switch models support >> it. Never mind that it requires me to forklift out every working >> L2 switch I have just to run IPv6. >> >> As far as I can tell the IETF has been killing or stalling the >> necessary DHCP additions for the better part of 7 years now. If >> you really want to fix this problem you either need to get a vendor >> to just implement it and ignore the IETF, or enough operators to >> go to the IETF meeting with pitchforks that perhaps someone finally >> listens. >> >> I really beieve this is going to be the single largest impediment to >> deploying _end user_ IPv6. >> >> -- >> Leo Bicknell - bickn...@ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
