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 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A97611E80E2; Wed, 9 Oct 2013 10:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.582
X-Spam-Status: No, score=-107.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9pDW2RT3iMge; Wed, 9 Oct 2013 10:53:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E05E221F9FB6; Wed, 9 Oct 2013 10:53:25 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 09 Oct 2013 10:53:25 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 655811B82CE; Wed, 9 Oct 2013 10:53:25 -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 5775B190061; Wed, 9 Oct 2013 10:53:25 -0700 (PDT) (envelope-from
Received: from [] ( by CAS-01.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Wed, 9 Oct 2013 10:53:25 -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 13:53:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <> <> <> <>
To: Cullen Jennings <>
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: []
Cc: "" <>, "" <>
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 17:53:35 -0000

On Oct 9, 2013, at 1:32 PM, Cullen Jennings <> wrote:
> Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with no user interaction. Getting the correct time is often really useful to have - particularly with synchronization protocols. 

An AFTR IP address is like a router IP address, but for a particular IPv4 transition technology.   Other transition technologies of this sort are classic examples of services that make sense to configure with DHCP, because they are part of the network infrastructure.

> One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like .

Apple hard-codes the FQDN of a set of NTP servers they control into all their products.   I think other OS vendors do as well, but am not clear on the details.   The advantage of doing this is that you can then authenticate your communication with the NTP server.   If you use DHCP to configure your NTP server, you cannot validate your communication with your NTP server.   Of course there's a bit of a chicken-and-egg problem here in terms of replay attacks and key repudiation, but in principle you get more security if you hard code the FQDN of your NTP server than if you use DHCP to configure it.

Of course there are cases where this doesn't matter, and DHCP is just fine, but I can't think of any other than perhaps a self-setting wall clock.

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.

> Another approach is for DHCP to provide the NTP server info. I would argue that getting a FQDN of the NTP server pool is a better design for DHCP than getting an IP address because this allow DNS load balancing across the pool and allows the server IP to change over time and still not have client failures. 

You'd get the same effect if the DHCP server did the lookup.   I agree that if you want to suddenly add an NTP server and need it to be adopted in a time frame shorter than your typical lease time, and your DNS TTL is shorter than your typical lease time, you will get better service using DNS, but there's no clear win here—this would be a pretty weird requirement.

> You agree that FQDN is would be a better design than IP for NTP ?

No.   I think the boxes that need NTP configuration via DHCP are most likely constrained devices, and that requiring them to do a DNS lookup in addition to the DHCP transaction is unnecessary.   Probably not a hugely bad thing, but that depends on the device.   A device with severe constraints probably isn't using DHCP anyway.

> Agree - it does not change as phones move network to network. It is uses DHCP the first time the phone is plugged in.  The whole design is around making sure the phone can go from the manufacture to the end user without ever being removed from the box or powered up be an admin. The admin configures the call control system based on knowledge about the phone and which user the phone is going to but the admin does not need to touch the phone. When the phone first boots it imprint baby duck style on a network to get the configuration information which is encrypted with that phones public key. After that the phone use that configuration information not the DHCP (unless the phone is factory reset). It's actually a lot more complicated than that because security relies on replacement of manufacture certificates with the service provider certificates to make sure a comprise of the manufactures CA only results in service provider not being able to enroll new phones but does not compromise security of operational phone network. 

> However, the first time the phone boots, DHCP needs to let the phone know who the likely service provider might be. If the phone gets the wrong DHCP information from an attacker or wrong network, the phone fails to configure but does not suffer MITM attacks. Using DHCP for phones has been used by pretty much every IP phone manufactures and most enterprise deployments and many residential providers including folks ranging from vonage to AT&T take advantage of it.  DHCP greatly reduce the deployment costs of setting up VoIP networks. 
> We had a lot of learning from the phone deployments and I expect us to use what we learned there for how we do IoT. (I presented a paper on this at the IAB workshop on IoT). One of the things we learned the hard way was names work better than numbers. 

So what you've done here is to invent a service configuration protocol that leverages existing DHCP server infrastructure, uses packets that look just like DHCP packets, but is not actually DHCP.   A client that behaves in the way you have described is not following RFC3315.   It might be following the letter of RFC2131, but that's because RFC2131 has a known bug in that it doesn't _require_ clients to use new information they get from DHCP servers during lease renewals.

This is not an academic distinction: I've seen all sorts of support calls and questions about IP phones from at least one manufacturer, because these phones do not follow the DHCP protocol specification, and their behavior is surprising to network administrators.   I didn't realize until now that this was by design, and not just a bug in the implementation.