Subject: Re: [dhcwg] Option 119 (Domain Search Option) and Option 15 (Domain Name Option)

From: Alfred Hönes <[email-masked]>
Date: Tue, 30 Nov 2010 21:53:08 +0100 (MEZ)

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:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: David Hankins <[email-masked]>
Date: Tue, 30 Nov 2010 13:43:28 -0800

> comment on space conservation.)

Not precisely.  There is some value in informing some clients of their
'domain name', as being separate from their domain-search list.  Although at
one time these two were one in the same (and in time, people began to
identify with it only for domain search behavior), the domain name can
actually feed other behaviors, and is useful to some clients separately from
their domain-search configuration.

We have actually heard a proposal not too long ago to add a domain-name
option to the DHCPv6 lineup of options for this purpose.

> it does not make sense to have both options in a DHCP response.

It is certainly true that it would be inappropriate to concatenate the two
together in some way.

Note that some DNS resolvers (as configured from /etc/resolv.conf for
example) are sensitive to the order in which these options are configured.
 Configuring the domain-search path before the domain-name results in an
implicit domain-seach path equal to the domain-name, which probably isn't
what the client desires.

It's not very tractable to reference all of these client-specific behaviors
for digesting configuration state in IETF protocols.  So far it doesn't seem
to have been a problem to ask clients to do what they find the most useful.

>    client (or group of clients) in either #15 or #119 format;

Sure, I guess.  Most DHCP servers support arbitrary options anyway - you
generally do not need a software upgrade to support new option definitions,
but instead have some facility to configure a value for any option code.
 Seems like this would lack teeth.

>    ambiguities resulting from both being received;

That's not useful.  A client that supports both domain-name and
domain-search-list is better served by requesting both, because it cannot
predict what the server 1) is capable of and 2) is configured to supply.  A
good implementation would wish to operate in whatever environment it finds
itself.

>    of packet space (see note on preconfigured DSL above);

I don't know why you would enumerate this since it is explicit in RFC 2131
Parameter-Request-List (PRL) processing.  Unless you are trying to specify a
behavior for when the PRL is not present, that is different from that
specified in RFC 2131?  Let me suggest that this is not a useful
enumeration.  If there is some DSL client implementation that concerns you,
it may be better to simply reference RFC 2131 on the subject of conformance.

>    and only send #119 in such case.

That's ridiculous.  We are not going to start updating, testing, and
distributing DHCP software every time there's a new option out the door that
looks familiar, and encode special rules for specific code points in DHCP
parser code.  The rules and exceptions just to make a DHCP packet would grow
without bounds.

If domain-name and domain-search both appear on the PRL, and both are
configured, send both.  Sure, it wastes packet space in the order of tens of
octets, big deal.

If you want to preserve DHCPv4 payload space, Ted Lemon long ago suggested a
much more useful general platform - instrumenting the PRL so that clients
could specify sets of options of which they only want one option in reply.
 Servers that don't support the instrumenting option codes simply wouldn't
have values to return for those codes anyway, and just wouldn't have the
space savings benefit.  Realistically, this has never been an issue to date,
so no one has looked towards implementing this (but as time wears on, it
continues to be a growing threat).