Re: [dhcwg] What sorts of services does DHCP configure?

Ole Troan <otroan@employees.org> Tue, 22 October 2013 16:57 UTC

Return-Path: <otroan@employees.org>
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 F0B5211E81D1 for <dhcwg@ietfa.amsl.com>; Tue, 22 Oct 2013 09:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 MB8jo5RRkcoD for <dhcwg@ietfa.amsl.com>; Tue, 22 Oct 2013 09:57:04 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5037B11E81BF for <dhcwg@ietf.org>; Tue, 22 Oct 2013 09:56:49 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-AV: E=Sophos; i="4.93,549,1378857600"; d="asc'?scan'208"; a="160909828"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2013 16:56:44 +0000
Received: from dhcp-10-61-107-167.cisco.com (dhcp-10-61-107-167.cisco.com [10.61.107.167]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGucYU004491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 16:56:39 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_E296504C-E58B-4FB9-AD36-7CC21118E1CC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
Date: Tue, 22 Oct 2013 18:56:38 +0200
Message-Id: <47131EA3-9EE6-4A10-8A7B-A4897D3078F0@employees.org>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [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: Tue, 22 Oct 2013 16:57:09 -0000

Ted,

>> Taking a more specific example, "Distributing Address Selection Policy using DHCPv6", draft-ietf-6man-addr-select-opt. For now, this draft only propagates generic address selection policy. It is little controversy to be DHCPv6 configuration, in my eyes.
> 
> It's pretty clear to me that this option is not a very good idea in most cases.   I don't think the DHC working group is in a position to say no to it, but we are certainly in a position to say "this isn't a good general solution to the source address selection problem."

are you sure you don't mean to say, "building networks this way is not a very good idea in most cases"?
because if you suspend enough disbelief, then the requirement for the network to be able to give hosts
information about the SAS/DAS policy table is hard to get around.

a good general solution to the source address selection problem? we don't have one, and I think it
unlikely that we will ever get one. active probing, aka multi-prefix Happy Eyeballs is the only thing that may work everywhere, and even that as a set of problems associated with it.

> Of course, there are constrained environments where it may make sense—e.g., in a PE router<->CE router situation.  But this is not something that ought to be enabled on all DHCP clients.

to solve the use case described in:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05

then that does exactly that, recommend it to be enabled on all DHCP clients.

cheers,
Ole