Re: [dhcwg] Option 119 (Domain Search Option) and Option 15 (Domain Name Option)
Alfred Hönes <ah@TR-Sys.de> Tue, 30 November 2010 20:52 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1813A6C2A for <dhcwg@core3.amsl.com>; Tue, 30 Nov 2010 12:52:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.534
X-Spam-Level:
X-Spam-Status: No, score=-98.534 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKTWnaVOgKTP for <dhcwg@core3.amsl.com>; Tue, 30 Nov 2010 12:52:20 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 31E013A6BDF for <dhcwg@ietf.org>; Tue, 30 Nov 2010 12:52:18 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA019140389; Tue, 30 Nov 2010 21:53:09 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA06018; Tue, 30 Nov 2010 21:53:09 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201011302053.VAA06018@TR-Sys.de>
To: dhcwg@ietf.org
Date: Tue, 30 Nov 2010 21:53:08 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Subject: Re: [dhcwg] Option 119 (Domain Search Option) and Option 15 (Domain Name Option)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 30 Nov 2010 20:52:21 -0000
Ted Lemon wrote: > On Nov 30, 2010, at 1:07 AM, VithalPrasad Gaitonde wrote: >> Is there any specification on the client behaviour when both >> option 15 and option 119 are provided in the server response: > > Unfortunately, there is no specification. Since the DSL option > was documented after the Domain Name option, one could assume > that it takes precedence. > > It would probably be worth updating RFC3397 to correct this > problem--it's actually a pretty serious omission. I guess everybody once saw RFC 3397 as a functional replacement for option 15, since the DSL (#119) allows a compact representation of multiple domain names by making use of domain name compression as in the DNS protocol. (This pretty much matches your previous comment on space conservation.) Option, OTOH, #15 encodes a single domain name; it cannot reasonably be concatenated, and it doesn't need to, since a single non-FQDN will always be shorter than 253 octets. >From a DNS resolver implentation point of view, any system that supports the configuration of a DSL would admit and prefer a _list_ of domain names, if it's the intent of the administrator to provide it. Since, for a conceptual domain search, list order matters, whereas the order of different DHCP options is arbitrary, it does not make sense to have both options in a DHCP response. Therefore, I propose the following rules: o DHCP servers SHOULD implement option 119; it looks like good implementations should have the ability to send a single domain name supplied by their configuration for a particular client (or group of clients) in either #15 or #119 format; o DHCP clients that would like to get domain search information SHOULD request option 119; if it is configured with a domain search list by other means, it SHOULD NOT request either (note that a configured DSL MUST NOT be overwritten via DHCP); o DHCP clients SHOULD NOT request both options 119 and 15, unless they have an implementation-specific way to resolve ambiguities resulting from both being received; o DHCP servers SHOULD supply options 15 and 119 only if they have been requested to do so; gratuitous supply is a waste of packet space (see note on preconfigured DSL above); o DHCP servers SHOULD ignore requests to supply both #15 and #119 and only send #119 in such case. Do current DHCP server/client implementations already conform to these rules? Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+
- [dhcwg] Option 119 (Domain Search Option) and Opt… VithalPrasad Gaitonde
- Re: [dhcwg] Option 119 (Domain Search Option) and… Ted Lemon
- Re: [dhcwg] Option 119 (Domain Search Option) and… Alfred Hönes
- Re: [dhcwg] Option 119 (Domain Search Option) and… David Hankins
- Re: [dhcwg] Option 119 (Domain Search Option) and… Alfred Hönes