Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                E. Guttman
                                                        Sun Microsystems
                                                       10 February  1999


               DHCP Options for Service Location Protocol
                       draft-ietf-dhc-slp-07.txt


Status of This Memo

   This document is a submission by the Dynamic Host Configuration
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the dhcp-v4@bucknell.edu mailing
   list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   The Dynamic Host Configuration Protocol provides a framework for
   passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol need to find out the
   address of Directory Agents in order to transact messages.  Another
   option provides an assignment of scope for configuration of SLP User
   and Service Agents.









Perkins, Guttman             Expires 10 August 1999             [Page i]

 
Internet Draft    DHCP Options for Service Location    10 February  1999


. Introduction

   The Dynamic Host Configuration Protocol [2] provides a framework
   for passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol, Version 2 [3] and
   Service Location Protocol, Version 1 [4] need to obtain the address
   of Directory Agents and Scope configuration.  The Service Location
   Protocol (SLP) provides a default configuration for Scopes and
   Directory Agents may be discovered using multicast or broadcast.  It
   is useful in a larger deployment to be able to configure SLP Agents
   using DHCP, so as to centralize the administration and to deploy SLP
   in networks where multicast routing is not available.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].


. Introduction

   The DHCP options described below are used to configure Agents using
   the Service Location Protocol, Version 2 [3] and Version 1 [4].

   The SLP Directory Agent option is used to configure User Agents and
   Service Agents with the location of Directory Agents in the network.

   The SLP Scope Option takes precedence over both default and static
   scope configuration of SLP agents.


. SLP Directory Agent Option

   This option specifies the location of one or more SLP Directory
   Agents.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 78   |    Length     |   Mandatory   |      a1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      a2       |       a3      |       a4      |      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SLP Directory Agent Option specifies a list of IP addresses
   for Directory Agents.  Directory Agents MUST be listed in order of
   preference, if there is an order of preference.

   The Length value must include one for the 'Mandatory' byte and
   include four for each Directory Agent address which follows.  Thus,



Perkins, Guttman             Expires 10 August 1999             [Page 1]

 
Internet Draft    DHCP Options for Service Location    10 February  1999


   the Length minus one of the option MUST always be divisible by 4 and
   has a minimum value of 5.

   The address of the Directory Agent is given in network byte order.

   The 'Mandatory' byte in the Directory Agent option may be set to
   either 0 or 1.  If it is set to 1, the SLP User Agent or Service
   Agent so configured MUST NOT employ either active or passive
   multicast discovery of Directory Agents.

   Note that for backward compatibility with some deployed software the
   Mandatory byte MUST NOT be set to any byte value for which the high
   order bit (0x80) is set.

   The Directory Agents listed in this option MUST be configured with
   the a non-empty subset of the scope list that the Agent receiving the
   Directory Agent Option is configured with.  See the notes below.

   The SLPv2 specification [3] defines how to use this option.


. SLP Service Scope Option

   The scope list is a comma delimited list which indicates the scopes
   that a SLP Agent is configured to use.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 79   |     Length    |   Mandatory   | <Scope List>...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length indicates the number of bytes which follow.  Since the
   Scope-List String is encoded using UTF-8 [5] characters, it may be
   the cast that the Length is not the same as the number of characters
   in the Scope-List String.  The Length value must include one for the
   'Mandatory' byte.

   The 'Mandatory' byte determines whether SLP Agents override their
   static configuration for scopes with the <Scope List> string
   provided by the option.  This allows DHCP administrators to
   implement a policy of assigning a set of scopes to Agents for service
   provision.  If the Mandatory byte is 0, static configuration takes
   precedence over the DHCP provided scope list.  If the Mandatory byte
   is 1, the <Scope List> provided in this option MUST be used by the
   SLP Agent.

   The Scope List String syntax and usage are defined in the SLPv2
   specification [3].



Perkins, Guttman             Expires 10 August 1999             [Page 2]

 
Internet Draft    DHCP Options for Service Location    10 February  1999


4.1. Zero Length Scope-List String Configuration

   A SLP Service Scope Option which indicates a Length of 1 (in other
   words, omitting the <Scope List> string entirely) validly configures
   the SLP User Agent to use "User Selectable Scopes."

   The SLP Agent will use the aggregated list of scopes of all known
   DAs.  If no DAs are known, the UA will use SA discovery to determine
   the list of scopes on the network, as defined in  [3].

   Note that this configuration is tantamount to removing all
   centralized control of the scope configuration of hosts on the
   network.  This makes it possible for every User Agent to see every
   service.  This may not be desirable as users may not be able to or
   desire to decide which services are appropriate for them.


. Security Considerations

   If a malicious host is able to insert fraudulent information in
   DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent
   will be unable to obtain service, or may unwittingly be directed to
   use the incorrect services.

   Many opportunities for denial of service exist.  A service agent
   could find that it might rely on fraudulent or otherwise malicious
   directory agents to advertise its services.  DHCPOFFERs could prevent
   the regular SLP framework from functioning by directing clients to
   not use multicast, to use nonexistent directory agents and so on.

   These difficulties are inherited from the much larger and more
   serious problem, viz.  securing or authenticating any information
   whatsoever from a DHCP server (or client!)  is not possible in common
   DHCP deployments.


















Perkins, Guttman             Expires 10 August 1999             [Page 3]

 
Internet Draft    DHCP Options for Service Location    10 February  1999


. Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


References

   [] S. Bradner.  Key words for use in RFCs to Indicate Requirement
       Levels.  RFC 2119, March 1997.

   [] R. Droms.  Dynamic Host Configuration Protocol.  RFC 2131, March
       1997.

   [] E. Guttman, C. Perkins, J. Veizades, and M. Day.  Service
       Location Protocol version 2.  draft-ietf-svrloc-protocol-v2-12.txt,
       February 1999.  (work in progress).

   [] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
       Location Protocol.  RFC 2165, July 1997.

   [] F. Yergeau.  UTF-8, a transformation format of unicode and ISO
       10646.  RFC 2279, October 1998.






Perkins, Guttman             Expires 10 August 1999             [Page 4]

 
Internet Draft    DHCP Options for Service Location    10 February  1999


Author's Address

   Questions about this memo can be directed to:

  Charles E. Perkins                       Erik Guttman
  Technology Development Group             Technology Development Group
  Mail Stop MPK15-214                      Mail Stop UFRA02
  Sun Microsystems, Inc.                   Sun Microsystems, Inc.
  15 Network Circle                        Bahnstr. 2
  Menlo Park, CA  94025                    74915 Waibstadt, Germany
  phone: +1 650-786-6464            phone: +49 7263 911 701
  fax:   +1 650-786-6445               or:  +1 650 786 5992
  email: Charles.Perkins@Sun.Com           Erik.Guttman@Sun.Com
  Web: http://www.svrloc.org/~charliep






































Perkins, Guttman             Expires 10 August 1999             [Page 5]