RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6

<anthony.flavin@bt.com> Mon, 26 November 2007 17:15 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 1IwhYD-0004nL-Ni; Mon, 26 Nov 2007 12:15:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhYC-0004jb-D5 for dhcwg@ietf.org; Mon, 26 Nov 2007 12:15:16 -0500
Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhY4-0004Nn-3C for dhcwg@ietf.org; Mon, 26 Nov 2007 12:15:16 -0500
Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:15:07 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6
Date: Mon, 26 Nov 2007 17:15:05 -0000
Message-ID: <548EC156325C6340B2E85DF90CAE85860199F7B0@E03MVB3-UKBR.domain1.systemhost.net>
In-Reply-To: <A05118C6DF9320488C77F3D5459B17B706594DC6@xmb-ams-333.emea.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6
Thread-Index: AcgsWTKjavik0Bj5SHaEIj8EDwiasQD9VtSwAABJxFA=
From: anthony.flavin@bt.com
To: blourdel@cisco.com, mjs@cisco.com, mills@udel.edu
X-OriginalArrivalTime: 26 Nov 2007 17:15:07.0259 (UTC) FILETIME=[E46764B0:01C8304F]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org
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

That's not really a surprise. A box that is powering up, needs IP
addresses as it may not be able to resolve DNS yet. However DHCP is not
restricted to passing addresses.

Tony 

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org
[mailto:ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org] On Behalf Of
Benoit Lourdelet (blourdel)
Sent: 26 November 2007 17:10
To: Mark Stapp (mjs); David L. Mills
Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for
DHCPv6

Mark and David,

If we consider the already defined DHCPv4 and DHCPv6 Options, IP
services are, in (almost) all cases, passed as an address and not as a
name.  
If we come to the conclusion that FQDN is really mandatory for NTP, I
don't see why we should not retrofit this to all existing IP services
Options.

Honestly, I would like the DHCP veterans to come forward and tell us why
they made so many bad decisions in the past :-;

Benoit

> -----Original Message-----
> From: Mark Stapp (mjs)
> Sent: Wednesday, November 21, 2007 5:10 PM
> To: David L. Mills
> Cc: ntpwg@lists.ntp.org; dhcwg@ietf.org
> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options 
> for DHCPv6
> 
> yes, this is another reason why the DHCP folks have generally used 
> addresses in options. it just removes a dependency among the various 
> clients in the system, and it doesn't usually have any significant 
> drawback.
> 
> there seems to be a concern that delivering addresses via DHCP somehow

> makes them difficult to update over time. just to reiterate: it's 
> often the case that the information at the DHCP server is updated. the

> updated information flows out to clients as they renew. if the lease 
> timers were very long, a client who got NTP addresses and found itself

> having trouble with them all could also use the INFORMATION-REQUEST 
> message to check whether the addresses were still valid, outside of 
> the normal renewal timers.
> 
> -- Mark
> 
> David L. Mills wrote:
> > Brian,
> > 
> > Trying to put out fires when the network is burning is a good 
> > excercise in fault containment. When the DNS is broken and
> the repair
> > party arrives, it's good to know the gateway works even if DNS 
> > doesn't. I'm not sure this exactly applies to NTP, but I sure would 
> > like to see the NTP servers options include hard coded addresses.
> > 
> > Dave
> > 
> > Brian Utterback wrote:
> > 
> >>
> >> Danny Mayer wrote:
> >>
> >>> There is *no* avantage to not sending a FQDN and plenty of 
> >>> disadvantages to not doing so.
> >>> Would you like a list of vendors who have hardcoded IP addresses 
> >>> into their devices without permission of the operator of that NTP 
> >>> server causing headaches for not just the owner of the NTP Server 
> >>> but also for the users of those devices? The NTP reference 
> >>> implementation expects the existence of a resolver so you haven't 
> >>> gained anything.
> >>>
> >>
> >> As already noted, there is an advantage, namely that the
> client does
> >> not have to have a resolver. And even if the reference
> implementation
> >> requires one (Is that really true? Even if no name resolution is
> >> required?) DHCP should remain implementation agnostic.
> >>
> >> As far the "hard coded address" problem goes, I don't see that 
> >> scenario as very likely. DHCP clients don't tend to remain up for 
> >> very long periods. And you don't have the same IP addresses being 
> >> served by thousands of DHCP servers. The thing to be careful of is 
> >> that the DHCP server not be embedded and replicated with
> hard coded
> >> addresses, not that the clients only get IP addresses.
> >>
> >> That having been said, I would like to see a way to pass a
> FQDN as an
> >> option, perhaps passing both. Then you could have logic
> like "Here's
> >> both, use the name if you can, and use the address if you must."
> >>
> > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ntpwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg