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

"Benoit Lourdelet (blourdel)" <blourdel@cisco.com> Wed, 21 November 2007 07:05 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 1IujeA-0005R6-JU; Wed, 21 Nov 2007 02:05:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuje8-0005R0-Mg for dhcwg@ietf.org; Wed, 21 Nov 2007 02:05:16 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuje8-00060m-2O for dhcwg@ietf.org; Wed, 21 Nov 2007 02:05:16 -0500
X-IronPort-AV: E=Sophos;i="4.21,444,1188770400"; d="scan'208";a="158328016"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 08:05:15 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAL75FpO000826; Wed, 21 Nov 2007 08:05:15 +0100
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAL759Um013102; Wed, 21 Nov 2007 07:05:14 GMT
Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 08:05:09 +0100
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: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
Date: Wed, 21 Nov 2007 08:06:19 +0100
Message-ID: <A05118C6DF9320488C77F3D5459B17B7064D89D2@xmb-ams-333.emea.cisco.com>
In-Reply-To: <4741D057.4070703@ntp.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
Thread-Index: Acgq1y1Q3aiDcf4+T8eKgYySBn/5LwBNUTlQ
References: <A05118C6DF9320488C77F3D5459B17B7062ED3C6@xmb-ams-333.emea.cisco.com> <4733482A.7020302@sun.com> <A05118C6DF9320488C77F3D5459B17B70634E4E5@xmb-ams-333.emea.cisco.com> <473D0C34.4030507@ntp.org> <1195185173.26090.4.camel@uma> <474114E3.9040309@ntp.org> <474198BA.3000109@sun.com> <1195484306.9159.13.camel@uma> <4741D057.4070703@ntp.org>
From: "Benoit Lourdelet (blourdel)" <blourdel@cisco.com>
To: Danny Mayer <mayer@ntp.org>, Ted Lemon <mellon@fugue.com>
X-OriginalArrivalTime: 21 Nov 2007 07:05:09.0784 (UTC) FILETIME=[DA8B2180:01C82C0C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3021; t=1195628715; x=1196492715; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20<blourdel@cisco.com> |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20[ntpwg]=20Network=20Time=20Protocol =20(NTP)=20Options=09for=09DHCPv6 |Sender:=20; bh=/dbt5HOZTSzwYas70kEphuAJsq6dAHII81EwC6g+P9k=; b=Q6JWm/F58xDDEqlbS26kqxhtluTi8s2vhEWVNkyy1ZYHZoHev4EbuHfYRmmbrZ+JJlgCeMPJ VniKi9LWxiCl7RE+WEarHboNKNxGc8NhqW8rvM54FgEth3R5WuegOrdj;
Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, Brian Utterback <brian.utterback@sun.com>, "Richard Gayraud (rgayraud)" <rgayraud@cisco.com>
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

About those 50 options ... For DHCPv6, listing already defined options
specifying an IP service,
I find option : 22,27,28,31,34, 40 that have hardcoded IPv6 addresses.

So far, I cant find any IP service defined by an FQDN for DHCPv6.

Benoit 

> -----Original Message-----
> From: Danny Mayer [mailto:mayer@ntp.org] 
> Sent: Monday, November 19, 2007 7:05 PM
> To: Ted Lemon
> Cc: Brian Utterback; Benoit Lourdelet (blourdel); 
> ntpwg@lists.ntp.org; dhcwg@ietf.org; Richard Gayraud (rgayraud)
> Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) 
> Options for DHCPv6
> 
> Ted Lemon wrote:
> > On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote:
> >   
> >> 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."
> >>     
> >
> > An option in a protocol that produces no different behavior 
> is just an 
> > opportunity for interoperability problems.
> >
> > This is actually an old discussion.   Danny's position 
> isn't unheard of,
> > but the fact is that there's really no way in which this option is 
> > different from the other fifty options that tell DHCP 
> clients how to 
> > contact servers.
> >
> > There's no reason why this option should use FQDNs while the other 
> > fifty use IP addresses, and there are a number of good 
> reasons not to 
> > send FQDNs, the first and most obvious of which is that 
> they take up 
> > more space in the packet, and space in the packet is very limited.
> >
> >   
> There is no way of answering that claim without knowing more 
> about a) those other 50 options; and
> b) how those options are obtained.
> 
> So let's step back here for a moment and have someone from 
> the DHCP community explain exactly how and when these options 
> are sent to the client. Remember that those of us 
> concentrating on NTP have only some idea how DHCP is sending 
> these options. Does DHCP:
> a) Send these options unsolicited when it is requested to 
> send an IP address to be used by the client?;
> b) Only send these options when requested by the client?;
> c) something else?
> 
> When does the client send/receive the request?
> a) Upon boot
> b) upon lease renew
> c) some other time?
> 
> Except for a) the NTP server is not going to be taking any 
> options from the DHCP server unless some other mechanism 
> (which NTP has not designed) tells it to. That means that the 
> NTP can be up for months never updating it's list of NTP 
> server addresses. In the meantime, Server 1 has stopped 
> running, Server 2 has moved to a different address, Server 3 
> was always suspect. DCHP has no say in what to do about this, 
> at least so far. DNS at least provides a way of getting a 
> fresh set of addresses.
> 
> Danny
> 

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