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