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

Ted Lemon <> Tue, 08 October 2013 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6D1621F9425; Tue, 8 Oct 2013 14:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e8GjRvGWcHF6; Tue, 8 Oct 2013 14:38:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D6A0A21F9E36; Tue, 8 Oct 2013 14:38:12 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Tue, 08 Oct 2013 14:38:12 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 A82C21B82DF; Tue, 8 Oct 2013 14:38:11 -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 6630F190061; Tue, 8 Oct 2013 14:38:10 -0700 (PDT) (envelope-from
Received: from [] ( by CAS-02.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Tue, 8 Oct 2013 14:38:10 -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: Tue, 08 Oct 2013 17:38:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <>
To: "Cullen Jennings (fluffy)" <>
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: Tue, 08 Oct 2013 21:38:28 -0000

On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) <> wrote:
> Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the  OS to redo DHCP when they fail an application level connection. 

This use case is a good example of when to use an FQDN format for a DHCP option.   However, it's not a great example of when to use a DHCP option—configuring SIP servers with DHCP is generally a bad idea, because if your device is connected to a new network, it will blindly take the SIP server IP address or FQDN information from the DHCP server and use it, and that SIP server might well perform an MitM attack or the like.

So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is a good idea.   Of course it's possible that my limited understanding of how SIP works is preventing me from seeing why it's safe to configure SIP service using DHCP, but I'm assuming that that's not the case in this argument; please feel free to correct me.

We've actually been having this same conversation on the iesg mailing list, and I asserted that SIP was something you ought not to configure with DHCP; your use case is the one case where it sort of makes sense.   Can you think of similar use cases where it actually makes sense to configure these parameters via DHCP?

Possibly the right solution is to update the document to talk about this sort of restricted use case as one where FQDNs actually do make sense.   The document certainly doesn't say you _can't_ use FQDNs, but we see people wanting to use them a lot in cases where they really don't make sense, hence the advice.   Historically I don't think we bothered to make this distinction when defining new DHCP options, but it seems like a useful distinction to make.