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/
- IPv6 Router Advertisement Option for NTP Server C… Bhatia, Manav (Manav)
- Re: IPv6 Router Advertisement Option for NTP Serv… Doug Barton
- IPv6 Router Advertisement Option for Foobar Confi… Brian E Carpenter
- Re: IPv6 Router Advertisement Option for Foobar C… Doug Barton
- Re: IPv6 Router Advertisement Option for Foobar C… Brian E Carpenter
- RE: IPv6 Router Advertisement Option for NTP Serv… Bhatia, Manav (Manav)
- RE: IPv6 Router Advertisement Option for NTP Serv… Samita Chakrabarti
- Re: IPv6 Router Advertisement Option for NTP Serv… Hing-Kam (Kam) Lam
- RE: IPv6 Router Advertisement Option for NTP Serv… Wuyts Carl
- re: IPv6 Router Advertisement Option for NTP Serv… Dacheng Zhang(Dacheng)
- Re: IPv6 Router Advertisement Option for NTP Serv… Sander Steffann
- 答复: IPv6 Router Advertisement Option for NTP Serv… Dacheng Zhang(Dacheng)
- Re: IPv6 Router Advertisement Option for NTP Serv… Sander Steffann
- RE: IPv6 Router Advertisement Option for NTP Serv… Eric Vyncke (evyncke)
- Re: IPv6 Router Advertisement Option for NTP Serv… Brian Haberman
- RE: IPv6 Router Advertisement Option for NTP Serv… Bhatia, Manav (Manav)
- Re: IPv6 Router Advertisement Option for NTP Serv… Simon Perreault
- RE: IPv6 Router Advertisement Option for NTP Serv… Bhatia, Manav (Manav)
- Re: IPv6 Router Advertisement Option for NTP Serv… Brian Haberman
- Re: IPv6 Router Advertisement Option for NTP Serv… Bjoern A. Zeeb
- Re: IPv6 Router Advertisement Option for NTP Serv… Warren Kumari
- Re: [TICTOC] IPv6 Router Advertisement Option for… Dave Hart
- Re: IPv6 Router Advertisement Option for Foobar C… Doug Barton
- Re: IPv6 Router Advertisement Option for NTP Serv… Doug Barton
- Re: IPv6 Router Advertisement Option for NTP Serv… Brian E Carpenter
- Re: IPv6 Router Advertisement Option for NTP Serv… Scott Schmit
- Re: IPv6 Router Advertisement Option for NTP Serv… sthaug
- Re: IPv6 Router Advertisement Option for Foobar C… Roger Jørgensen
- RE: IPv6 Router Advertisement Option for Foobar C… STARK, BARBARA H
- Re: IPv6 Router Advertisement Option for Foobar C… Jared Mauch
- Re: IPv6 Router Advertisement Option for Foobar C… Warren Kumari