Subject: [dhcwg] Review of Service-Discovery-Type options in DHCP

From: Stuart Cheshire <[email-masked]>
Date: Tue, 16 Jul 2002 02:54:50 -0700

At the Yokohama meeting I pointed out that many DHCP options carry 
information that might be better served via an explicit service discovery 
mechanism.

Thomas Narten pointed out that the IETF community has not arrived at an 
undisputed consensus about how to do service discovery.

I agree with this in the broad sense, but for simple service discovery 
the world does seem to have arrived at an ad-hoc) solution -- functional 
hostnames in DNS.

Common practice is that most companies have a hostname of the form 
"www.company.com." which resolves to the address of the company's web 
server.

Similar examples are:

ntp.company.com.     (NTP Time Server)
mail.company.com.    (Incoming mail)
smtp.company.com.    (SMTP relay for outgoing mail)
pop.company.com.     (POP mailbox host)
imap.company.com.    (IMAP mail access)

This is an ugly solution for two reasons:
1. It is a misuse of DNS host names to name things that are logical 
services, not hosts.
2. The names are not standardized --
is it "ntp.company.com.", or "time.company.com." ?

Fortunately, DNS already has a solution that addresses these two 
deficiencies: SRV records

1. SRV records explicitly names services, not hosts, and
2. SRV records have a formalized naming convention -- the name of the SRV
   record for NTP service at "company.com." is "_ntp._udp.company.com."

The only missing piece of information that the client need to learn is 
the "company.com." component of the service names it should be looking up.

Perhaps the existing DHCP "Domain Name" option (option code 15) meets 
this need.

If you bring your laptop to Apple, and boot it using DHCP, then the DHCP 
"Domain Name" option will say, "apple.com.", and you can find:

1. A time server by looking up SRV record "_ntp._udp.apple.com."
2. An SMTP relay by looking up SRV record "_smtp._tcp.apple.com."

The people at the Apple offices in Europe get a DHCP "Domain Name" option 
which says, "euro.apple.com.", and they find services by looking up names 
like: "_ntp._udp.euro.apple.com." and "_smtp._tcp.euro.apple.com."

If not the existing "Domain Name" option, perhaps the "Domain Search 
List", or something like it, is the right answer. That way, a single DHCP 
option points you to the place in the DNS name space where all your SRV 
records can be found, instead of every service having to have 
yet-another-separate-option-of-its-own in DHCP.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Jul 2002 19:20:41 +0900

What you propose is perfectly workable, but I don't see how it's *better* 
than what DHCP already provides.   That is, we have something that works 
now.   Why is the DNS a better choice as a resource discovery server?   I 
can think of some reasons, but I'm not sure why you think this makes sense,
  so I'm grasping at straws a bit - the reasons I can think of in favor of 
DNS are ones you have stated, and I don't have a real problem with them, 
but I don't find them particularly compelling either.

DNS is better:

     1. I already have to have a DNS server.   With IPv6,
        I don't have to have a DHCP server.   So this is
        one less thing I have to configure/deploy.
     2. DNS servers understand administrative domains,
        and administrative domains are a good way to
        determine which clients should use which servers.

DHCP is better:

     1. DHCP already solves the problem of locating services,
        so we don't have to kludge something into the DNS
        namespace.
     2. DHCP servers understand the network topology, and
        topology is a good way to determine which clients
        should use which servers.
     3. You have to have a DHCP server anyway - how are you
        going to get the IP address of your DNS server?

Arguments (1) are true, although I don't find argument 1 for DNS 
particularly compelling.   The other arguments aren't true - they're just 
opinions, and not necessarily even particularly valid opinions.   My 
feeling here is that using DNS as a server location protocol is chancy at 
best, and so I don't want to switch from DHCP to DNS, but I can't prove 
that I'm right on this.

Can you come up with a really compelling argument for using one over the 
other?

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Jul 2002 07:30:09 -0400

>information that might be better served via an explicit service discovery 

Yes, but where host configuration should be managed by the network operator, 
DHCP is an appropriate mechanism. Why make it more complicated?

>is it "ntp.company.com.", or "time.company.com." ?

This is not just common practice it is BCP 17 - RFC 2219, which documents a
  "sensible set of
   defaults which may be used as an aid in determining the hosts which
   offer particular services for a given domain name."

John

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Jul 2002 20:33:12 -0400

I'm going to pick a small item out of the middle of Stuart's message that 
caught my attention...

>"Domain Name" option will say, "apple.com.", and you can find:

I have always thought of the "Domain Name" option as specifying the domain 
name that the client should attach to its hostname to form its 
FQDN.  Stuart suggests a somewhat different definition - the "Domain Name" 
option simply identifies the domain name for the network to which the 
client is attached.  The client can then use that information in any way it 
wants: to form an FQDN if it needs one, to form service names.

- Ralph

---

From: Roop Mukherjee <[email-masked]>
Date: Tue, 16 Jul 2002 11:44:57 -0400 (EDT)

It seems that the problem of service discovery, probably better termed as 
server discovery, at the moment is simply that of locating a server for a 
service that a end-node may desire. Locating the address of a server (for 
time, ftp etc.) is a naming function.

That being the case, locating the names of servers seems more up the alley 
of DNS than DHCP.

-- Roop
__________________________________

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Jul 2002 14:40:55 +0900

> name that the client should attach to its hostname to form its FQDN.  
> Stuart suggests a somewhat different definition - the "Domain Name" option 
> simply identifies the domain name for the network to which the client is 
> attached.  The client can then use that information in any way it wants: 
> to form an FQDN if it needs one, to form service names.
>

I think Stuart's definition is more generally correct.   The only time when 
the domain name option specifies the client's domain name is when the 
client doesn't have a domain name that it cares to assert.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Jul 2002 14:29:37 +0900

> That being the case, locating the names of servers seems more up the alley

This seems to be a statement of opinion.   I was looking more for logical 
arguments - that is, you present *reasons* why you believe that DNS is a 
better choice than DHCP.   I don't see any reasons here - just opinions.

I am not saying you are definitely wrong.  I just don't see how this 
statement helps us to decide what to do.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 17 Jul 2002 12:28:43 +0200 (CEST)

Folks,

Here's my take on this topic.

---

DHCP and DNS are reasonably equivalent for the purpose of service discovery.

 * DHCP associates a type of service (ie. an option id) with an address.

 * DNS SRV RRs associate a server name with a host name, and
   that name, using an A RR, with an address.

Both DHCP and DNS are centrally administered, so neither is 'more natural'
a place to administer service type to service location mappings, inside
a single enterprise.   In the Internet as a whole, however, DNS SRV RRs
clearly supply a function which DHCP lacks - namely, obtaining the 
locations of services *in other administrative domains.*

---

In dynamic environments, it would be nice if the *availability* of the
service would imply its discoverability.  

SLP achieves this by requiring an agent to 'register' the service when 
the service is available.  When the service goes down, the agent
can deregister it, or let the soft-state registration expire.  With 
multicast SLP, agents respond directly - potentially one 'agent' per
service (running in a thread of the service process, even).

Other possibilities include:

  * An agent registering the service with an LDAP server using LDAP.

  * An agent registering the service with DNS using DNS dynamic update
    of an SRV RR.

  * A management framework (SNMP, CIM/WBEM, JINI, etc) which allows
    service information to be made available.  The network management
    protocol can then be used to generate a map of which services are
    available where, and push this information to clients, somehow.

  * An agent could respond to 'stateless DHCPv6' requests, as per
    draft-droms-dhcpv6-stateless-guide-00.txt

  * An agent could respond to multicast DNS requests for SRV RRs,
    as per 
        Stuart Cheshire's suggestions (drafts expired)
     OR draft-ietf-dnsext-opcode-discover-00.txt
     OR draft-ietf-dnsext-mdns-10.txt

In summary, neither DNS nor DHCP have any standard mechanism for
supporting dynamic registration of services based upon their 
availability.  One could standardize such a mechanism and the
basic mechanisms to support this are already under discussion.

---

Other mechanisms, such as LDAP or SLP allow service information
to be obtained by a client on the basis of *attributes* and not
simply by an id # or service name.  For applications which require
'locate-by-characteristic' service discovery instead of 
'locate-by-type', DHCP and DNS are not sufficient.  Examples of 
these types of service (for which SLP has *actually been used*) are:

  * Management agents (which can be managed by a particular kind of
    manager)

  * Printers with distinguishing characteristics

  * File services exported with distinguishing characteristics

  * Databases with distinguishing characteristics (only certain
    users or groups can access them)

  * Coarse grain dynamic load balancing applications (see RFC 3049)

---

Using DHCPINFORM, a client can request a particular option.  Note
however, the DHCPINFORM cannot set the 'lease expiration time.'
See RFC 2131, Section 4.3.5.  This is unfortunate, as it is useful
to tag a cache timeout for service location information.  This can
be done with DNS SRV RRs (TTL) and SLP (lifetime) or in an LDAP
entry (for example, with a 'valid until' timestamp attribute).

A DHCP server could use RECONFIGURE to signal DHCP clients to 
request new service information when necessary, but this only
partially makes up for the lack of a time limit on server address
options.

---

Summary:

My feeling is there are many approaches to service discovery being
pursued and this is not a service to the user and administrator
communities.  I believe that while no approach has all the features
that everyone wants, we should try to rally arround a single approach.

Proposal:

Many working groups create DHCP options for service discovery.
Others are specifying use of DNS SRV RRs.  What if we specify a
simple mapping between the two and create a registration process:

  IETF Standards Track Service => DHCP Option # and DNS SRV Name

As far as the consistency of the list of service locations which DHCP 
and DNS servers assign to clients - that could be solved by tighter
integration of DNS and DHCP.  This has long been considered for
the relationship between A and PTR records for DHCP assigned
addresses.  We could start a parallel effort to consider the
relationship between SRV RRs and DHCP assigned server options -
so they are the same list.  This would be especially useful when
'Stateless DHCPv6' and 'multicast DNS' mature as standards and
are supported on the same host.

Should I write this proposal up as an internet draft? 

---

Best regards,

Erik

---

From: Roop Mukherjee <[email-masked]>
Date: Wed, 17 Jul 2002 09:33:57 -0400 (EDT)

Not using imperatives, does not imply that the text expresses opinion.

Let me try to make it simple. The technical point I was trying to make 
was:
Distinguish between the configuration probelm from the naming problem. 

The naming problem is that of finding the address of an entity in the 
network. If there is a name server, like DNS, then nodes can querry it for 
names without having any other association with it. This is important 
becuae one may have non-DHCP hosts wanting to discover names. 
 
The configuration problem is finding your own address, and that 
of some other essential entities. Insisting that the general naming 
function be performed as part of the configuration(DHCP) server is just 
globbing functionality together.

As the internet grows, the naimg problem will likely need something better 
than DNS. At the least keeping it disinct from other problems will help.

Cheers,
-- Roop
______________________________________________

---

From: John Schnizlein <[email-masked]>
Date: Wed, 17 Jul 2002 09:46:15 -0400

What is the problem your proposal intends to solve?

At 06:28 AM 7/17/2002, Erik Guttman wrote:
>...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jul 2002 10:36:29 +0900

> Distinguish between the configuration probelm from the naming problem.

I'm sorry, but this is not a technical argument.   It is a statement of 
opinion.   You are saying that there are two separate problems - 
configuration and naming.   You then describe what you think these problems 
are.   Nowhere do you explain why you think this way of framing the problem 
is correct - you simply assert that it is correct and then explain the 
problem as you see it in more detail.   This is not constructive.

Let me make two observations:

1. There is more than one functional way to state the problem.
2. We don't have to pick only one solution.

It is quite possible that your statement of what the problem is is a 
functional one.   The mere fact that this is so, if it is so, does not mean 
that the way the DHCPv6 group has been framing the problem is *not* a 
functional one.   So advancing this as a reason not to support service 
location options in DHCPv6 doesn't work.   If you think this is the right 
way to solve the problem, go off and write up some drafts, and try to 
advance them in the DNSEXT working group.   But don't say to us, "you must 
stop trying to solve this problem, because I am trying to solve it and my 
way is better."   When you say that, you are simply stating your opinion, 
and that is not a valid reason for us to stop doing what we are doing, 
unless we happen to agree with you without needing to be convinced.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 17 Jul 2002 16:06:22 +0200 (CEST)

> What is the problem your proposal intends to solve?

Rather than consider 'which is better' I believe DHCP and DNS are 
pretty equivalent for this function.  Why not facilitate this
equivalence and provide for making responses from DHCP consistent
with those from DNS?

It would be nice if dhcp option numbers assigned could be paired
with well known names to be used in DNS SRV records.  This would
facilitate DNS and DHCP giving out the same information.  This will
be particularly useful if stateless DHCPv6 and multicast DNS become
pervasive.  A stateless DHCP and multicast DNS server might use the 
same database to answer a request for a particular service type.

Erik

---

From: "Raymond Jayaraj" <[email-masked]>
Date: Mon, 22 Jul 2002 11:32:54 +0800

Hi,

Just my take on this DHCP vs DNS problem, coming from a 'performance'
perspective (i.e. number of bits, messages).

I'm not too sure if DNS doesn't support multiple queries in a message,
but if it doesn't, then you'd have to do 'pointed' queries to find out
if services exist, and where they are located, e.g.:

MN      AR      DNS
-+-     -+-     -+-
 |address/dn config
 |<=====>|       |
 | where's NTP?  |
 |-------------->|
 |     at ::X
 |<--------------
 | where's POP?
 |-------------->
 | no such record
 |<--------------
 | where's BIND
 |-------------->
 |     at ::Y
 |<--------------

On the other hand, using DHCP(v6) extensions, you can do a 'hailing'
type of query:

MN      AR      DHC
-+-     -+-     -+-
 |addr conf.     |
 |<=====>|       |
 |Okay, which of these services have you got - NTP,POP,BIND
 |-------------->|
 |NTP's at ::X, BIND's at ::Y. I don't have POP though.
 |<--------------|

Of course, if DNS do allow multiple queries in a message, or if it is
enhanced to support this, then this argument has no base.

Also, bitwise, DHCP permits the most optimised performance by allowing
the sending of IPv6 addresses of services in raw.

Cheers,
Raymond Jayaraj
ICR, Singapore.

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Roop Mukherjee" <[email-masked]>
Cc: "Stuart Cheshire" <[email-masked]>; "DHCP discussion list"
<[email-masked]>
Sent: Thursday, July 18, 2002 9:36 AM
Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP