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

Danny Mayer <mayer@ntp.org> Sun, 25 November 2007 02:18 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 1Iw74e-0007YC-Dv; Sat, 24 Nov 2007 21:18:20 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw74b-0007Y4-5Z for dhcwg@ietf.org; Sat, 24 Nov 2007 21:18:17 -0500
Received: from mx04.gis.net ([208.218.130.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iw74a-00050N-QD for dhcwg@ietf.org; Sat, 24 Nov 2007 21:18:17 -0500
Received: from [10.10.10.101] ([63.209.224.211]) by mx04.gis.net; Sat, 24 Nov 2007 21:17:56 -0500
Message-ID: <4748DAB1.2030506@ntp.org>
Date: Sat, 24 Nov 2007 21:15:13 -0500
From: Danny Mayer <mayer@ntp.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Harlan Stenn <stenn@ntp.org>
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options for DHCPv6
References: <20071121052610.DD3EF39E3F@mail1.ntp.org>
In-Reply-To: <20071121052610.DD3EF39E3F@mail1.ntp.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, Ted Lemon <mellon@fugue.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

Harlan Stenn wrote:
> Guys,
> 
> Is this about mechanism or policy?
> 
> I would suspect (and hope) it is about mechanism.
> 
> In that case one must be able to "offer" either a name or an IPv4
> address or an IPv6 address.
> 
> If one *also* wishes to address policy issues, that's OK (IMO).
> 
> But (again IMO) the underlying mechanism needs to support names and/or
> addresses.

Let me make an alternative suggestion which would make sense (at least
to me).

The IPv6 address sent by the server MUST be a site-local or link-local
address or, for an IPv4 address a local LAN address as specified by the
netmask. The client MUST ignore any addresses that don't meet this criteria.

This way the DHCP admins are restricted to use only those NTP servers
that the business owns and cannot configure one outside their own
address spaces.

Would this satisfy both sides?

The other issues with the options we've already discussed and we leave
open for now the issue of specifying NTP authentication keys for a
separate discussion.

Danny

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