Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6
Hal Murray <hmurray@megapathdsl.net> Wed, 28 November 2007 13:55 UTC
Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNNi-0006Tg-9Y; Wed, 28 Nov 2007 08:55:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwHR-0006vH-Dt for dhcwg@ietf.org; Tue, 27 Nov 2007 03:58:57 -0500
Received: from ip-64-139-1-69.sjc.megapath.net ([64.139.1.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwwHL-0004yv-0P for dhcwg@ietf.org; Tue, 27 Nov 2007 03:58:57 -0500
Received: by ip-64-139-1-69.sjc.megapath.net (Postfix, from userid 500) id 49A24BE31; Tue, 27 Nov 2007 00:58:50 -0800 (PST)
Received: from glypnod (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 3D98FBE2F; Tue, 27 Nov 2007 00:58:50 -0800 (PST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: Mark Stapp <mjs@cisco.com>
From: Hal Murray <hmurray@megapathdsl.net>
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6
In-Reply-To: Message from Mark Stapp <mjs@cisco.com> of "Mon, 26 Nov 2007 14:08:14 EST." <474B199E.3060700@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 Nov 2007 00:58:49 -0800
Message-Id: <20071127085850.49A24BE31@ip-64-139-1-69.sjc.megapath.net>
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
X-Mailman-Approved-At: Wed, 28 Nov 2007 08:55:11 -0500
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Hal Murray <hmurray@megapathdsl.net>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
> I do wonder why some folks seem to think that using DNS names would > somehow be "safer" than using v6 addresses. if someone shipped a > server with a canned list of DNS names for NTP servers, there would > be a problem until the owners of the NTP servers named moved them. I > don't see how that'd be any better than the analogous mistake > involving IP addresses. I think that suggestion is coming from the NTP community rather than DHCP. Using names rather than addresses provides a layer of indirection which is a powerful tool for recovering from screwups. If Joe-Idiot hard wires 123.123.123.123 into his dumb box and then ships a zillion units, the guy who owns 123.123.123.123 is screwed. Updating the firmware on enough units to make a difference won't ever happen. If ntp.example.com gets wired in, you at least have a chance to play DNS games to distribute the load. > shipping a DHCP server with a canned configuration would not be good, > so let's hope it doesn't happen. Mark Andrews's email seems to me to > summarize what happens: 'home' routers have a dhcp client face and a > dhcp server face, and use the client to populate the server. That's another form of indirection. It seems like a sensible approach to me. On the other hand, a lot of boxes were shipped that didn't work that way. For those who haven't read it, Wikipedia has a good summary of the NTP mess: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse This problem has code in (at least) two places: One is the DHCP server. The other is the NTP client. Either can screw it up. The examples on the Wiki page didn't involve DHCP but a simple screwup in a DHCP server could generate similar results. The obvious example is that if somebody has a NTP server address they are using for an internal NTP client and it is hard wired, they could easily use the same variable when they need something to stuff into a DHCP packet. My vote would be to add some extra wording to emphasize this area. Just saying "MUST" is too likely to get ignored. I think the key idea is that you have to be very careful if the addresses (or names) you are giving out are not on your network. As far as I can tell, all of this discussion holds for both IPv4 and IPv6. I have no strong opinions on name vs address. The extra level of indirection might be important. On the other hand, it might be simpler to cleanly document and correctly implement a system that didn't have that extra layer of complexity. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqd… Mark Stapp
- [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-op… Ralph Droms
- [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-op… Mark Stapp
- [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-op… Stuart Cheshire
- Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqd… Stuart Cheshire
- [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-op… Stuart Cheshire
- RE: [dhcwg] Re: Last call for <draft-ietf-dhc-fqd… Bernie Volz (EUD)
- RE: [dhcwg] Re: Last call for <draft-ietf-dhc-fqd… Christian Huitema
- Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqd… Mark Stapp
- [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-op… Ted Lemon
- [dhcwg] How to encode DNS labels in DHCP options Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NT… Hal Murray