[dhcwg] What sorts of services does DHCP configure?

Ted Lemon <mellon@fugue.com> Mon, 14 October 2013 18:26 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4253121E80EA for <dhcwg@ietfa.amsl.com>; Mon, 14 Oct 2013 11:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbv5SMKKY0+5 for <dhcwg@ietfa.amsl.com>; Mon, 14 Oct 2013 11:25:56 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B921E80CD for <dhcwg@ietf.org>; Mon, 14 Oct 2013 11:25:41 -0700 (PDT)
Received: from [IPv6:2001:470:88a3::b5e5:37d4:74de:f011] (unknown [IPv6:2001:470:88a3:0:b5e5:37d4:74de:f011]) by toccata.fugue.com (Postfix) with ESMTPSA id BB34B238033F for <dhcwg@ietf.org>; Mon, 14 Oct 2013 14:25:37 -0400 (EDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com>
Date: Mon, 14 Oct 2013 14:25:35 -0400
To: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
X-Mailer: Apple Mail (2.1812)
Subject: [dhcwg] What sorts of services does DHCP configure?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2013 18:26:09 -0000

During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP.   This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs.

The dichotomy that I would like us to discuss is between network-specific services and node-specific services.

To illustrate what I mean, consider DNS.   DNS is the same everywhere (at least in principle).   If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS.   So DNS is a network-specific service: the DNS server you use probably should be the one closest to you.

Now, consider IMAP.   If you use IMAP, you probably have one or more IMAP servers.   These servers are fixed in location.   You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work.   So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network.

If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services.   I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP.

At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases.   For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore.

I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim.   My claim is that DHCP doesn't make sense for configuring node-specific services.   There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative.   And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities.

Thoughts?