Re: IPv6 Router Advertisement Option for Foobar Configuration

Doug Barton <dougb@dougbarton.us> Wed, 21 December 2011 20:22 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079751F0C56 for <ipv6@ietfa.amsl.com>; Wed, 21 Dec 2011 12:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGzteHcB2NeL for <ipv6@ietfa.amsl.com>; Wed, 21 Dec 2011 12:22:39 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DF1F0C4D for <ipv6@ietf.org>; Wed, 21 Dec 2011 12:22:38 -0800 (PST)
Received: (qmail 13719 invoked by uid 399); 21 Dec 2011 20:22:32 -0000
Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 21 Dec 2011 20:22:32 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4EF24007.3030300@dougbarton.us>
Date: Wed, 21 Dec 2011 12:22:31 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: IPv6 Router Advertisement Option for Foobar Configuration
References: <7C362EEF9C7896468B36C9B79200D8350D026F16A8@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EF22786.2070908@dougbarton.us> <4EF2373B.6060905@gmail.com>
In-Reply-To: <4EF2373B.6060905@gmail.com>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2011 20:22:40 -0000

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/