Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

Ted Lemon <> Wed, 09 October 2013 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F78F21E805F; Wed, 9 Oct 2013 11:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.602
X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgq-QzsJeZxX; Wed, 9 Oct 2013 11:11:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 27B0E21F9A71; Wed, 9 Oct 2013 11:11:17 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 09 Oct 2013 11:11:17 PDT
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 9E4031B82D5; Wed, 9 Oct 2013 11:11:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 98716190061; Wed, 9 Oct 2013 11:11:16 -0700 (PDT) (envelope-from
Received: from [] ( by CAS-01.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Wed, 9 Oct 2013 11:11:16 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
Subject: Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
From: Ted Lemon <>
In-Reply-To: <>
Date: Wed, 09 Oct 2013 14:11:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <> <> <> <> <> <>
To: Joe Abley <>
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: []
Cc: "" <>, "" <>, Cullen Jennings <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Oct 2013 18:11:37 -0000

On Oct 9, 2013, at 1:59 PM, Joe Abley <> wrote:
> DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). There is a possible future in which such validation takes place on end hosts, rather than intermediate resolvers. (We may wind up somewhere else, but there are certainly people who think that is the Right Way).

Sure.   Including me.

> In that sense any device that needs to look up names in the DNS has a potential requirement for time sync.

Yes, definitely.

> Of course even the wall clock you imagine might have a vendor who is capable of running their own array of time servers as (e.g.) Apple does, but it seems reasonable to imagine that there will be people who are not in that position, and since I agree with you when you say:
>> Of course, if a CPE vendor were to hard-code the FQDN of an NTP server belonging to someone else into their devices, that would be disastrous.
> it seems to me that there's a plausible use case for a DHCP client to receive direction on what servers to chime against.

Yup.   There's an equally plausible use case for distributing DNSSEC root keys using DHCP, so that the DHCP client has a current copy of the keys.   This totally solves the key rollover problem!


Of course, the situations are not precisely analogous, but the point is that just because DHCP could be conveniently used to suit some purpose, does not mean that it _should_ be used to suit that purpose.  I think reasonable people can differ about configuring NTP over DHCP, but it really does depend on how you are using NTP.   I think the main justification for using DHCP to configure NTP is in fact that it is expedient, even though it's not secure.