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

[Erik Guttman <[e-mail]>]

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




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