Re: IPv6 Router Advertisement Option for Foobar Configuration

[Doug Barton <[e-mail]>]

Yeah, and/or the recently approved multicast DNS draft. Personally I
like DHCP, but I'm not saying it's the only answer.

What I *am* saying is that extending RA is always the *wrong* answer.


Doug


On 12/21/2011 14:07, Brian E Carpenter wrote:
> 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.
>>



-- 

		[^L]

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/