Doug, Excuse front posting, but I think there's another aspect to this, which is that the Service Location Protocol (RFC 2165) was standardised in 1997, when DHCP was still a newcomer, and it offers a multicast service discovery mechanism that doesn't need *any* central server (the SLP Directory Agent is optional).
A combination of basic RA plus directory-less SLP would be necessary and sufficient for small unmanaged networks, I think. Regards Brian On 2011-12-22 09:22, Doug Barton wrote: > On 12/21/2011 11:44 AM, Brian E Carpenter wrote: >> On 2011-12-22 07:37, Doug Barton wrote: >>> On 12/19/2011 5:24 PM, Bhatia, Manav (Manav) wrote: >>>> Hi, >>>> >>>> We have posted a new draft that extends Router Advertisements to >>>> include information about the one or more NTP servers present in the >>>> network. This is useful where the delays in acquiring server >>>> addresses and communicating with the servers are critical (mobile >>>> environment for example). >>> Sort of surprised that no one else has responded so far, but I'll bite. >>> Quite simply, "no." Slightly less simply, "use DHCP since that's what >>> it's for." >>> >>> I'm happy to expound on the evils of "camel's nose already too far under >>> the tent," etc. >> There is of course a broader issue here, illustrated by the endless loop >> over in MIF about draft-ietf-mif-dhcpv6-route-option. > > ... or the endless loop of "we need DNS info in RA" until it finally got > adopted. > >> What is the intended scope of the RA mechanism? >> >> I was a strong proponent of standardising the DNS server option >> in RA, because it is an absolute requirement for even the most >> minimal host to get onto the Internet. But I am also a strong >> proponent of -dhcpv6-route-option, because it seems clear that >> more complex environments will inevitably require the extensibility >> that comes with DHCPv6. > > So, expound it is. :) > > When I first got interested in IPv6 protocol work back in 2000 or so I > was curious about this "RA" thing. Given that DHCP was already widely > deployed and successful in the IPv4 world I wondered why such a thing > was necessary/useful.* I was told at the time that a key feature of IPv6 > was going to be the ability to bring "dumb" devices onto the network > that only needed to be addressable (light switches were a commonly used > example). The RA mechanism was perfect for this as it involved no state, > and anything that needed to be even slightly "smart" would use DHCPv6. > As much as I was dubious about it at the time, I accepted that > explanation at face value. > > Then someone realized that RA was great for getting a thing on the > network, but at that point the thing wasn't really all that useful. So > the logical next step was to extend RA to allow for sending out > resolving DNS info. The point I (and others) tried to make at the time > went something like this (I will use the first person so as to take 100% > of the blame, but that's not meant to exclude the others who made > significant contributions to the line of argument that I support): > > Me: Um, if it's not a dumb device, why can't it use DHCP? > Them: DHCP is too heavy-weight. We just need one more piece of > information provided by RA and then we'll have a fully-functional client > without the need for DHCP at all, isn't that great! > Me: Um, well, I see what you're saying, but doesn't that sort of open > the door for adding more things down the road? And as both a system > administrator and an operating system developer I have serious concerns > about having to support 2 different host configuration protocols. It > will inevitably lead to problems, and ... > Them: No no no, don't be silly! We JUST want to add this ONE little > thing. After that we promise, no more! > Me: I just think it's a bad precedent. Besides, adding only the > nameserver info isn't enough, you also need the domain and/or search > string to make it useful. > Them: *snap* Oh, right! Thanks for pointing that out. Ok, we'll add that > too, but after that, NO MORE. I PROMISE! > Me: Um .... > >> I think we need a standards track document that defines the maximum >> scope of the RA mechanism once and for all. Personally I would >> probably freeze it where it is today, but we need a reasoned >> architectural decision about this. > > Given that using RA for DNS info isn't widely deployed yet, I would vote > for rolling RA back to its originally designed purpose, THEN saying "no > more, really, I mean it." But I doubt that either of those options will > be successful. I would be ecstatic to be proven wrong however. > > > Doug > > * I realize that when RA was first conceived DHCP wasn't that well > established yet, and furthermore I understand that some people disagree > on how well established it was even as late as 2000. My experience at > the time was that DHCP was already widely used in both the SOHO and > large enterprise markets. In any case I don't think anyone can argue > that in the last 11 years it hasn't been firmly established. Failure to > recognize why DHCP is popular, and why RA isn't, is a bug in the > protocol development process. > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
