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

Cullen Jennings <> Wed, 09 October 2013 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FCA621E825E; Wed, 9 Oct 2013 15:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qWoiTpzCeuB2; Wed, 9 Oct 2013 15:02:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8A8F521E8238; Wed, 9 Oct 2013 15:02:47 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F2578509B5; Wed, 9 Oct 2013 18:02:45 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
From: Cullen Jennings <>
In-Reply-To: <>
Date: Wed, 09 Oct 2013 16:02:44 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1510)
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 22:02:58 -0000

On Oct 9, 2013, at 11:53 AM, Ted Lemon <> wrote:

> 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.

Hard coding it means you can't make your device work if you are on a network that behind a firewall that does not allow the traffic or is on a networks that is not part of the internet or is being set up for use in emergency communications where the the device is on a network say in Hati that has become partitioned from rest of network after an disaster.  Obviously one can fallback to a hard coded option if no DHCP option is found but it's pretty important to have a chance of being able to configure things to work on networks with less than ideal connectivity. 

> 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.

I think this is the part where we disagree. I don't think you get the same effect if the DHCP server did the lookup and returned a single IP address. I realize you understand DNS better than me but DNS returns a  lot more than a single IP address. In the most simple case it can be returning a list of IP so that if one server is down, the client can contact another. I don't see how to do that with single IP returned from DHCP. (yes, I realize that some people have requested DHCP options to return a list of IP). But more impotently if someone wants to do something like move the server from one data center to another, it is well understood by admins how to do that when clients access the server by FQDN. It's much harder when it's an IP address that has to be updated in DHCP servers. Not to mention opening up the use DNS tools like SRV and NAPTR. 

>> 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.

This is not really a constrained device issue - it has to do with hosts that don't have an IT administrator and need to just work. They might be constrained, but right now my house has devices doing DHCP, DNS, and HTTP all fitting in 12 k of flash, 512 bytes of ram, and an 8 bit processor at 16Mhz so don't think that DNS needs to be big - probably not fully standards compliant but it works. My house also has things like NAS, WiFI GW, TVs etc that have pretty powerful computers yet still need to turn on and just work with no administration. 

>   Probably not a hugely bad thing, but that depends on the device.   A device with severe constraints probably isn't using DHCP anyway.

Seriously ? How do you think IPv4 constrained devices get an IP address?

>> 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.

Hmm - this is much more interesting - help me understand what part it does not follow 3315. When it boots, it uses DHCP to find the address of a configuration server. If it needs a configuration, it downloads that from the configuration server. If it does not need a configuration, it does not download it. I would not be shocked to find out that this was not following 3315 but I think I can speak for at least most the folks doing this that they did not know it was not consistent with 3315 and would be very interested in hearing why.