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