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

"Cullen Jennings (fluffy)" <> Wed, 09 October 2013 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEBED11E81B0; Wed, 9 Oct 2013 08:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3y5ZAqeIGv0t; Wed, 9 Oct 2013 08:27:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2426811E81A7; Wed, 9 Oct 2013 08:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2731; q=dns/txt; s=iport; t=1381332423; x=1382542023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jubzkgbSbqERMjtJAeztuR6yTTZVdoDs9f7hl0UjD7Q=; b=lXMUfdjK4b+TlYUqdVIeVLiTSN2xVAij4olj36oqyS6mu5iPB6NgokJI Ie++TiAQbDYudDsz5NGBdGuT0XjyXlCcTo7IyoWnQ5lkWjRmIThU/A8/S en4C7zXvTyeESMxzvedxjBWa+rQjEWZE7y/b0CJCJZwQVs9ARpcZlwkOC g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="267025528"
Received: from ([]) by with ESMTP; 09 Oct 2013 15:26:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r99FQwn7029704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 15:26:58 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 10:26:58 -0500
From: "Cullen Jennings (fluffy)" <>
To: Ted Lemon <>
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: AQHOxG6tx36dkMJ3pkem9MOxfSCBUpns0u+A
Date: Wed, 09 Oct 2013 15:26:57 +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: Wed, 09 Oct 2013 15:27:51 -0000

On Oct 8, 2013, at 3:38 PM, Ted Lemon <> wrote:

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

Nah, it's not quite like that - Long story how that it but the security mechanism make sure you authenticate both ends to stop that. 

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

Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that have come up would make it easier to see what advice is needed.