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

Ted Lemon <> Tue, 22 October 2013 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F8CB11E821B; Tue, 22 Oct 2013 11:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 49n3xwvJetwe; Tue, 22 Oct 2013 11:56:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B61311E822A; Tue, 22 Oct 2013 11:55:46 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUmbKHQ/; Tue, 22 Oct 2013 11:55:47 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 45B0C1B813B; Tue, 22 Oct 2013 11:55: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 2CB65190052; Tue, 22 Oct 2013 11:55:25 -0700 (PDT) (envelope-from
Received: from MBX-01.WIN.NOMINUM.COM ([]) by CAS-01.WIN.NOMINUM.COM ([]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 11:55:25 -0700
From: Ted Lemon <>
To: Cullen Jennings <>
Subject: Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
Thread-Topic: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
Thread-Index: AQHOxG6vvYfRrCcaWUK4N3Cm629TPZns9HaA///CyYCAAGBrgP//wqiAgACIuQD///LeAAANvZ8AAAxP5AACbNgWAAAB/XiA
Date: Tue, 22 Oct 2013 18:55:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 22 Oct 2013 18:56:38 -0000

On Oct 22, 2013, at 1:58 PM, Cullen Jennings <> wrote:
> Ted, one of the hallmarks of a successful protocol is people use it for things it's designers think are an awful idea and it ends up working fairly well for them. I think the heart of the issue here is that you don't believe that DHCP should be used to configure application-layer services, like SIP.  I disagree - I think the text in the draft about when to use this is about right 

Argh.   No.   The hallmark of a successful protocol is not that it attracts barnacles and gets used in ways that ultimately fail, either due to a really bad security model, or a bad fit, or other reasons.

DHCP in fact has been very successful in the IETF as a place to add barnacles.   There are lots of DHCP option extensions that do all kinds of really exciting things.   Most of them were implemented once, shortly after publication, never deployed, and now, if they exist at all, exist only as an attack surface that nobody has yet exploited hard enough to cause the feature to be removed from the client implementation.

The actual success of DHCP is its core ability to configure devices with the information they need to get online.   If you look at a typical DHCP packet from a typical host, it doesn't ask for SIP servers.   It doesn't ask for printers.   It doesn't ask about SMTP or IMAP or POP.

My DHCPv4 client asks for: Subnet Mask, Default Gateway, Domain Name Server, Domain Name, Domain Search List, LDAP Server Address, WPAD Proxy URL, Netbios Name Server and Netbios Node Type.   My DHCPv6 client requests DNS Server address and Domain Search List.

You will notice that it doesn't ask for an NTP option, even though it uses NTP.   This is because asking for an NTP option will generate support calls.  It doesn't ask for a printer address.   This is because although DHCPv4 provides a way to deliver printer addresses, nobody uses it.   Bonjour is easier and more convenient, and generates fewer support calls.   Even though I have an email client running, it doesn't ask for IMAP server, SMTP server or POP server, because that would be ridiculous.

So yes, DHCP is a successful protocol.   And yes, application protocol designers have attempted to use it to configure their protocols.   But they haven't succeeded, in the large, because it's a bad idea.   It is not a successful _applications service discovery_ protocol.   It is a successful _host configuration_ protocol.

> I've build small battery powered sensors that use DHCP, DNS and reports environmental measurements periodically to a server and have a very good handle on the power usage of these devices. I've done ones that use ethernet and  802.15.4, (and also ones that don't use DNS or DHCp but run over satellite links). On those networks, I have concrete measurements that indicate for that system you are wrong about DNS making a significant difference to battery life. I realize there might be other applications where it does make a difference but so I'm having a hard time imagine such an system. The reason why is simple, the bulk of traffic a sensor sends over a 30 day period is mostly sensor data not DHCP or DNS. 

Indeed, in this scenario, power consumed by DNS and DHCP will not be an issue.

> On the flip side, for SIP phones we have seen that the level of indirection form DNS really helps make the operational issues easier.

Yes, and SIP is a lousy example, because it's not generally configured using DHCP—it's generally configured through a user interface.   When it _is_ configured using DHCP, it's done in a constrained environment.   The configuration model used in that environment would be a security disaster on the open internet.

> I think the draft should not say that IPs are preferred over FQDNs. I think it should say the choice of IP or FQDNs depends on the applications and factors that should be considered are size, power, extra RTT, if a DNS stack is available, code size, and so on. But also point out some of the operational management advantages of DNS. 

I agree that these are all good things to mention.   However, I think the document should steer people away from using FQDNs, because if they need to use FQDNs, they will regardless of what direction the document tries to steer them.

> Really we are talking about if you have a parameter in some new protocol X to control, this BCP is taking the opinion that it knows more about protocol X than the protocol X WG and that it thinks the parameter should be an IP not FQDN. I think this is wrong, DHCP should deal with how transport the configuration parameter that protocol X needs and if that is an IP or FQDN is probably a choice best left to experts of protocol X.  Heck, I'll go a scope further, I think it is not in charter of the DHC working to determine if IP or FQDN are best to configure a parameter in some future protocol done by some other WG.

It is in the charter to recommend best practices for DHCP.

> On Oct 10, 2013, at 9:41 AM, Ted Lemon <> wrote:
>> On Oct 9, 2013, at 11:49 PM, Cullen Jennings <> wrote:
>>>> If this argument were correct, we'd expect to see major O.S. vendors supporting the NTP option, but we don't—instead, it's something that can be configured in the UI for situations like the one you describe, and that otherwise is defaulted to the preconfigured value, which of course can be updated when the operating system is updated.
>>> Right - I am certainly more focused on the devices that don't have an administrator that can configure them locally. 
>> This is great, but that's not all devices.   And devices of this type often wind up being very vulnerable to attack precisely because no usable escape mechanism is offered.   DHCP may be your only choice for configuring such a device, but it's a really lousy choice.
> Louse choice? What exactly would you propose that would work better ?

What would be better would be a secure mechanism for configuring them.   E.g., going to a well-known URL and downloading a configuration signed using a tool that allows the device to validate the configuration.   This is what e.g. Microsoft Exchange clients do.   It works quite well.

>> Right, and I think I already said that (a) SIP is a bad example of a use case for DHCP, because it's a node-specific service, not a network-specific service, and (b) it's probably fine, if you must use DHCP to configure SIP, to use an FQDN, as I already said several messages back.
> Sure, and why does that same argument not hold for configuring similar services which is what I complained about in the draft. 

In general, configuring similar services using DHCP won't work.   I'm not convinced it works for SIP.   I'm fairly sure it doesn't work for configuring NTP.

> Look, I am not arguing that one should not us IP address in some cases. I'm arguing that there are equally good cases where one should use FQDN. I realize they are not popular with the layer 2/3 folks but they are very popular with the application layer folks because of the flexibility and easy of managment they provide. 

Can you give me an example of a use case that is _not_ an APPS-area protocol?

BTW, you mentioned that you think NTP and DNS are application layer, but they are in the INT area for a reason.   I mean a protocol that's in the APPS area, for an equally good reason.

>> SRV records are normally used for application-layer services, like SIP, which I don't think should be configured with DHCP.   Similarly, would you use DHCP to configure the address of an HTTP server? :)
> This seems to be the heart of it. You don't think this should be used for application layer services but I don't think that ship sailed long long ago. 

The ship sailed long ago, and sank out at sea, yes.   I was on it at the time—like you, I used to think DHCP was for configuring applications.   I did not arrive at my current opinion accidentally.

> Once again, please give me an example where the ext ran DNS traffic from the device forms any relevant percentage of the traffic and/or power usage. 

Any time the frequency of reports from the device is similar in frequency to refreshes required by the DNS TTL expiring.

> The refresh on DNS TTL is same as refresh on DHCP lease time

Yes, and if you have to do six DNS queries per DHCP renewal, that's six more packet exchanges.

>> DHCP does all the queries for you at the same time and hands you a single packet with all the information you need to contact all the services offered by DHCP.   This can be expected to result in many fewer packet round trips, and consequently much less power spent.   This is a significant feature; getting rid of it in order to make life a little more convenient for operators who do not have to deal with these constraints is a poor value proposition for the protocol as a whole.
>> BTW, another example of a constrained device is a network booted device, where despite the fact that the node itself is quite capable once it's booted, the boot prom is quite constrained.   I think this was a primary motivation for the choice of address versus FQDN back in DHCPv4 days; I suspect relevant in fewer cases now, but still relevant in some.
> Again, that's a fine argument why BOOTP should use IP, however it is not an argument about why nothing else should use FQDN

I don't think you said what you meant here.   BOOTP is a predecessor to DHCP—what does that have to do with this conversation?

>> (I will note, by the way, that you have yet to raise a point that was not considered and addressed by the working group.   I think this discussion is useful, because it points to clarifications that should be made to the document, but I don't yet see anything that would suggest to me that the consensus call went the wrong way.)
> Well, why don't you come over to RAI and do a presentation on why we should not use FQDN in DHCP and see what the consensus is over there. I'm sure the ADs could arrange some agenda time in the dispatch meeting which is closest things that RAI has to an area meeting at IETF 88.  The consensus of a particular WG does not necessarily represent the consensus of the IETF. 

(a) I can't.
(b) It would be useless.   Of course RAI is going to say DHCP should support configuring application protocols.   Why not?   It's a cost-free assertion from your perspective.
(c) This document is saying what the DHC working group recommends.   RAI working groups are free to go against these recommendations.   So this document shouldn't say what RAI recommends.   It should say what DHC recommends.   If a working group doesn't want to follow the advice, they don't have to, because it's just advice, not a requirement.