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

Brian Utterback <brian.utterback@sun.com> Wed, 21 November 2007 15:01 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 1Iur4x-0007VY-Kd; Wed, 21 Nov 2007 10:01:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur4w-0007VO-Nt for dhcwg@ietf.org; Wed, 21 Nov 2007 10:01:26 -0500
Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iur4t-0007ho-42 for dhcwg@ietf.org; Wed, 21 Nov 2007 10:01:26 -0500
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALF1J6L017944; Wed, 21 Nov 2007 15:01:20 GMT
Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lALF1IN5062596; Wed, 21 Nov 2007 10:01:19 -0500 (EST)
Message-ID: <4744483E.6080304@sun.com>
Date: Wed, 21 Nov 2007 10:01:18 -0500
From: Brian Utterback <brian.utterback@sun.com>
User-Agent: Thunderbird 2.0.0.10pre (X11/20071118)
MIME-Version: 1.0
To: "David L. Mills" <mills@udel.edu>
Subject: Re: [ntpwg] [dhcwg] Re: 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> <4743B902.3030406@udel.edu>
In-Reply-To: <4743B902.3030406@udel.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.0 (-)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "dhcwg@ietf.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

Dave, I think you misunderstood. By saying the "hard-coded address"
sceanrio as "not very likely" I meant that a DHCP caused fiasco like
the Netgear/Wisc. one was not likely, even if IP addresses are supplied
in the DHCP field. In other words, we are once again in violent
agreement here.

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."
>>
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg

-- 
blu

"You've added a new disk. Do you want to replace your current
drive, protect your data from a drive failure or expand your
storage capacity?" - Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

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