Subject: [dhcwg] Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

From: The IESG <[email-masked]>
Date: Tue, 26 Sep 2006 13:22:08 -0400

The IESG has received a request from the Dynamic Host Configuration WG 
to consider the following document:

- 'Domain Suffix Option for DHCPv6 '
   <draft-ietf-dhc-dhcpv6-opt-dnsdomain-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-10-10.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsdomain-03.txt

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Sep 2006 13:41:34 -0400

There's something terribly broken about any DHCP option that specifies 
things that are characteristics of the host, rather than characteristics 
of the network.  The host is, or should be, viewed as something that is 
conceptually independent of the network to which it is attached, rather 
than something that is subject to arbitrary reconfiguration by the 
network.  An increasing number of hosts roam from one network to 
another; the behavior of such hosts should, to the extent possible, 
remain the same from one network attachment point to another.

I realize that other DHCP options are also broken in this way, but 
errors made in the past are not a justification to make errors in the 
present.

So I'm finding difficulty justifying this option.

-------- Original Message --------

> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Sep 2006 12:22:44 -0700

Keith Moore wrote:
> network.

Hm.   I see where you're coming from, and for the use case you state,
you are in fact completely correct.   DHCP clients that are things like
laptops have no business trusting the domain suffix option provided by
the DHCP server.   However, while this is a rather large class of DHCP
clients, it is not the only class.   Other clients include such things
as printers, cable modems, etc.   And there are also large installed
bases of devices like desktop computers that are not mobile, for which
being able to be configured by a local DHCP server with a consistent
domain suffix is in fact very useful.

So I see where you're coming from, and indeed I think it might be
reasonable to add a caveat to the draft explaining your objection.   But
I don't think that your argument is a good objection to actually
advancing the draft, as you seem to be asserting; rather, it is merely
an argument for adding some text to the draft clarifying use cases for
the option.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Sep 2006 13:07:31 -0700

> things that are characteristics of the host, rather than characteristics 

I disagree fully, and see no reason to alter or delay this document.

There is nothing broken about DHCP options that specify host
characteristics, in this or any other option.

Controlling Hosts is what this protocol does.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Sep 2006 15:41:12 -0700

> Controlling Hosts is what this protocol does.

Er, just to be clear, I agree with David that there's no need to alter
or delay the document.   However, Keith does have a point.   The point
of my previous message wasn't to argue for delaying the document, but
rather to propose a solution if the IESG decides that something needs to
be changed.   I do not agree with Keith's basic premise that DHCP should
_never_ do anything to configure anything other than network parameters.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Sep 2006 15:41:12 -0700

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Sep 2006 16:51:29 -0700

> _never_ do anything to configure anything other than network parameters.

Sounds like we're in agreement.

Secifically, it's my opinion that changes are not warranted (too much
work for too little benefit), and it would be better not to make any.

Any client that doesn't want this option (or any other) merely needs
to neglect to include it on the ORO (see section 2.1 of this draft).

It's a DHCP architecture thing, this is not specific to this option
or use cases for this option.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Sep 2006 23:00:34 -0700

Keith Moore wrote:
> I suppose I agree.  Certainly the document would be much improved by
> stating the intended purpose(s) of the domain suffix.  Is it for
> searches or something else?  And if it's for searches why can there be
> only a single domain?  (And by the way, do you really want to encourage
> appliances to use DNS for local resource discovery?)

In general, the reason why we don't say "the option is for THIS" is that
we're specifying a building block, not a system.   So while the author
envisions a particular use for the option, if you say that the option is
intended only for that purpose, then you're excluding other potential
uses.   I have to confess that during WG review I actually advised the
authors *not* to specify a particular use for this option precisely
because I thought that the use they'd specified was too restrictive.

One obvious use for an option like this is in a case where a DHCP client
is not configured to assert a particular domain, and you want to tell it
what its DNS domain is - that is, the domain in which its hostname will
appear.   I think the authors had in mind specifically the case of cable
modems in a wholesale/retail ISP configuration, which is fairly common
in Japan and Korea, and fairly uncommon here in the U.S.   In such an
environment, you have a lot of devices and you'd like to be able to tell
them all what their domain name is using a single centralized service.
 Since DHCP is already a service that we expect the cable modem to use
for other configuration information, it makes sense to use it for this
information as well, and this is in fact common practice in DHCPv4
already, where a similar option exists.

To respond to Bill Fenner's question, the reason for not using the
domain search list option is that in some cases you want to be able to
call out a specific individual domain, not a list of domains to search,
for example in the case where the client might be configured with a
hostname, but not know its FQDN.   One could configure both hostname and
FQDN manually, but in some cases dynamic configuration is preferable.

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Sep 2006 23:06:48 -0400

> domain suffix is in fact very useful.

Mumble.  Desktop computers, printers, and other appliances _are_ mobile, 
though not as mobile as laptops.  They routinely get unplugged from one 
place and plugged into another.  Why should it be assumed that the 
network decides the configuration of such devices?

I think what has happened is that we've gotten used to using the wrong 
tools for configuring computers and appliances because most users don't 
know how to configure their own computers, and because most appliances 
don't have keyboards and displays that allow them to be configured 
easily.  So for some kinds of shops, anyway, the accepted solution has 
become to move the configuration of the computer or appliance to the 
network.  And that even makes sense to a point - remote administration 
is definitely useful.  But what it ends up doing is blurring the 
boundary between the computer and the network on an architectural level, 
which is bad - or at least the consequences of doing so need to be 
well-understood.

Clarifying use cases also seems desirable, but maybe this needs to be 
done for DHCP in general...though I would not want to hold up this 
document until that were done.

Keith

---

From: Bill Fenner <[email-masked]>
Date: Tue, 26 Sep 2006 22:41:11 -0700

>Certainly the document would be much improved by 
>only a single domain?

This was my biggest question when this came up - what's it for?
DHCPv6 already has a domain search list (option 24).

  Bill

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Sep 2006 23:06:48 -0400

Keith

---

From: Bill Fenner <[email-masked]>
Date: Tue, 26 Sep 2006 22:41:11 -0700

Bill

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Sep 2006 02:21:31 -0400

> In general, the reason why we don't say "the option is for THIS" is 
> that we're specifying a building block, not a system.   So while the 
> author envisions a particular use for the option, if you say that the
>  option is intended only for that purpose, then you're excluding
> other potential uses.

sure, but if you don't define what this is with significant precision
you can (and in all probability will) get conflicts between different
uses of it.  so if you don't want to define the use cases (and I
understand why you might not want to do that), it seems like you need to 
supply the precision some other way.

and it's really not obvious what a domain suffix in DHCP is good for. 
in particular, there's no inherent association between a domain suffix 
and a (sub)network or even a host or network interface that I can see.

(especially in the IPv6 world we need to get away from this notion that
a host is only connected to one network at a time - IPv6 is already
forcing hosts and apps to deal with multiple addresses per host, and in 
such a world there's no reason to assume that all of those addresses are 
on the same network.  it therefore becomes appropriate to think of 
DHCPv6 options as specifying something about a network interface or 
network attachment point rather than a host.)

> I have to confess that during WG review I actually advised the 
> One obvious use for an option like this is in a case where a DHCP 
> client is not configured to assert a particular domain, and you want 
> to tell it what its DNS domain is - that is, the domain in which its 
> hostname will appear.

actually, the notion that a host has "a" DNS domain seems to me to be
anachronistic.  these days hosts routinely have multiple DNS names, and
the same DNS name is routinely mapped to multiple hosts.  furthermore,
bindings between DNS names and hosts can be changed at a whim.  DNS
names aren't host names any more, and there isn't even a firm notion of
a distinguished DNS name for a host in the architecture.

> I think the authors had in mind specifically the case of cable modems
> in a wholesale/retail ISP configuration, which is fairly common in
> Japan and Korea, and fairly uncommon here in the U.S.   In such an
> environment, you have a lot of devices and you'd like to be able to
> tell them all what their domain name is using a single centralized
> service. Since DHCP is already a service that we expect the cable
> modem to use for other configuration information, it makes sense to
> use it for this information as well, and this is in fact common
> practice in DHCPv4 already, where a similar option exists.

I get the impression that we're trying to solve a very specific problem 
with a general solution, without trying to understand the consequences 
of generalizing that solution.  and there are reasons to believe that 
some of the consequences are undesirable.

> domain search list option is that in some cases you want to be able 
> to call out a specific individual domain, not a list of domains to 
> search, for example in the case where the client might be configured 
> with a hostname, but not know its FQDN.   One could configure both 
> hostname and FQDN manually, but in some cases dynamic configuration 
> is preferable.

again it seems to me that the authoritative source for name-to-address
bindings is the DNS.  it's an engineering principle that you don't want
to have two different authoritative sources of the same information.  so
if DNS says that the name corresponding to IPv6 address x:x:x:x:x:x:x:x
is foo.example.com, and DHCP says that the name of the host attached to
IPv6 address x:x:x:x:x:x:x:x is bar.example.com, which one is right?

id 1GSSnc-0001sm-6q; Wed, 27 Sep 2006 02:21:40 -0400
Date: Wed, 27 Sep 2006 02:21:31 -0400
From: Keith Moore <[email-masked]>
To: Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] Re: Last Call: 'Domain Suffix Option for DHCPv6' to
	Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
Cc: [email-masked], [email-masked], [email-masked]

> In general, the reason why we don't say "the option is for THIS" is 
> that we're specifying a building block, not a system.   So while the 
> author envisions a particular use for the option, if you say that the
>  option is intended only for that purpose, then you're excluding
> other potential uses.

sure, but if you don't define what this is with significant precision
you can (and in all probability will) get conflicts between different
uses of it.  so if you don't want to define the use cases (and I
understand why you might not want to do that), it seems like you need to 
supply the precision some other way.

and it's really not obvious what a domain suffix in DHCP is good for. 
in particular, there's no inherent association between a domain suffix 
and a (sub)network or even a host or network interface that I can see.

(especially in the IPv6 world we need to get away from this notion that
a host is only connected to one network at a time - IPv6 is already
forcing hosts and apps to deal with multiple addresses per host, and in 
such a world there's no reason to assume that all of those addresses are 
on the same network.  it therefore becomes appropriate to think of 
DHCPv6 options as specifying something about a network interface or 
network attachment point rather than a host.)

> I have to confess that during WG review I actually advised the 
> One obvious use for an option like this is in a case where a DHCP 
> client is not configured to assert a particular domain, and you want 
> to tell it what its DNS domain is - that is, the domain in which its 
> hostname will appear.

actually, the notion that a host has "a" DNS domain seems to me to be
anachronistic.  these days hosts routinely have multiple DNS names, and
the same DNS name is routinely mapped to multiple hosts.  furthermore,
bindings between DNS names and hosts can be changed at a whim.  DNS
names aren't host names any more, and there isn't even a firm notion of
a distinguished DNS name for a host in the architecture.

> I think the authors had in mind specifically the case of cable modems
> in a wholesale/retail ISP configuration, which is fairly common in
> Japan and Korea, and fairly uncommon here in the U.S.   In such an
> environment, you have a lot of devices and you'd like to be able to
> tell them all what their domain name is using a single centralized
> service. Since DHCP is already a service that we expect the cable
> modem to use for other configuration information, it makes sense to
> use it for this information as well, and this is in fact common
> practice in DHCPv4 already, where a similar option exists.

I get the impression that we're trying to solve a very specific problem 
with a general solution, without trying to understand the consequences 
of generalizing that solution.  and there are reasons to believe that 
some of the consequences are undesirable.

> domain search list option is that in some cases you want to be able 
> to call out a specific individual domain, not a list of domains to 
> search, for example in the case where the client might be configured 
> with a hostname, but not know its FQDN.   One could configure both 
> hostname and FQDN manually, but in some cases dynamic configuration 
> is preferable.

again it seems to me that the authoritative source for name-to-address
bindings is the DNS.  it's an engineering principle that you don't want
to have two different authoritative sources of the same information.  so
if DNS says that the name corresponding to IPv6 address x:x:x:x:x:x:x:x
is foo.example.com, and DHCP says that the name of the host attached to
IPv6 address x:x:x:x:x:x:x:x is bar.example.com, which one is right?