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

Danny Mayer <mayer@ntp.org> Mon, 19 November 2007 18:07 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 1IuB2F-0003mt-K4; Mon, 19 Nov 2007 13:07:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB2E-0003ft-RQ for dhcwg@ietf.org; Mon, 19 Nov 2007 13:07:50 -0500
Received: from exchdev.pega.com ([198.22.153.35] helo=exchdev.rpega.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuB2E-0006st-F9 for dhcwg@ietf.org; Mon, 19 Nov 2007 13:07:50 -0500
Received: from [10.60.98.36] ([10.60.98.36]) by exchdev.rpega.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:07:50 -0500
Message-ID: <4741D057.4070703@ntp.org>
Date: Mon, 19 Nov 2007 13:05:11 -0500
From: Danny Mayer <mayer@ntp.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
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>
In-Reply-To: <1195484306.9159.13.camel@uma>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Nov 2007 18:07:50.0085 (UTC) FILETIME=[18B41750:01C82AD7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "dhcwg@ietf.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

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