Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                          27 August 1996
                                                           14 March 1997

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

Status of This Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

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.  In
   certain other instances they may need to discover the correct scope
   and naming authority
   to be used in conjunction with the service attributes and URLS which
   are exchanged using the Service Location Protocol.

1. 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 [3] need to find out
   the address of Directory Agents in order to transact messages.  In
   certain other instances they may need to discover the correct scope
   to be used in conjunction with the service attributes and URLs [1]
   which are exchanged using the Service Location Protocol.

   The scope MAY be denoted in any standardized character set.  Values
   for character encoding can be found in IANA's database
         http://www.isi.edu/in-notes/iana/assignments/character-sets
   and have the values referred by the MIBEnum value.

   Note that each option listed below may be included multiple times in
   the same DHCPOFFER or DHCPREQUEST. If so, then the options SHOULD be
   included in order of decreasing preference.

2. Directory Agent Extension Option

   This extension option requests or specifies a Directory Agent (DA) [3], (DA), along with
   zero or more Naming Authorities [2] known to that DA and zero or more scopes supported by that DA.

   The code for this extension is 78.  Each Naming Authority and each
   scope MUST be a null-terminated string of ASCII characters.  The
   lengths of the strings are only indicated implicitly by their null
   termination and the overall length of the extension.

    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     |     Length    |D|   NA count  |  scope count    |D|S|          reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              (if present)                          |
   | Directory Agent address (16 octets)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            NA list ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Char Encoding         |            scope list ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Code     78

      Length   variable

      D        If the 'D' bit is set, the Directory Agent address is
               present.

      NA count
               The number of Naming Authorities indicated by strings in

      S        If the 'S' bit is set, the NA list following. scope count
               The number of scopes indicated by strings is present, encoded in
               the scope
               list following.

      NA list
               A list of strings indicated character set.

      Char Encoding
               The standardized encoding for the characters making up
               the string denoting Naming Authorities. the scope.

      scope list    A list of strings string denoting scopes. the scope.

   Note that more than one Directory Agent extension option may be present in a
   DHCP message.  Each such extension option may have the same or different
   lists of Naming Authorities and scopes. scope.
   The client may request a any Directory Agent with a particular scope, and/or knowledgeable about
   schemes defined by a particular Naming Authority,
   by including the Directory Agent extension option in a DHCP Request message
   with no Directory Agent address included (the 'D' bit set to zero),
   and the appropriate
   strings in string denoting the scope.  The length of the NA list and/or scope list.

2. string is
   only indicated implicitly by the overall length of the option.

3. Service Scope Extension Option

   This extension option indicates a scope that should be used by a Service Agent
   (SA) [3], when responding to Service Request messages as specified by
   the Service Location Protocol.

    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   Len
   +-----+-----+-----+-----     |  79     Length    |  n         Char Encoding         |  Scope
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           scope ...
   +-----+-----+-----+-----

   Scope is a null-terminated ASCII string, of length 'n' including
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Code     79

      Length   variable

      Char Encoding
               The standardized encoding for the
   terminating null character.

3. Naming Authority Extension

   This extension indicates a naming authority (which specifies characters making up
               the
   syntax for schemes string denoting the scope.

      scope    A string denoting the scope.

   Note that more than one Service Scope option may be used present in URLs [1]) for use by entities
   with the Service Location Protocol.

    Code   Len
   +-----+-----+-----+-----+-----+-----
   |  80 |  n  |  Naming Authority ...
   +-----+-----+-----+-----+-----+-----

   Naming Authority is a null-terminated ASCII string, DHCP
   message.  The length of the scope string is only indicated implicitly
   by the overall length 'n'
   including of the terminating null character. option.

4. Security Considerations

   If a malicious host is able to insert fraudulent information in
   DHCPOFFER packets sent to a prospective client of the Service
   Location Protocol, then the client will be unable to obtain service,
   and vulnerable to disclosing information to unauthorized service
   agents.  Likewise, a service agent would find that it might rely on
   fraudulent or otherwise malicious directory agents to advertise its
   services.  Many opportunities for denial of service exist.

   This difficulty is 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.

5. Acknowledgements

   Thanks to Erik Guttman for his helpful suggestions in the creation of
   this draft.

References

   [1] T. Berners-Lee, L. Masinter, and M. McCahill.  Uniform Resource
       Locators (URL).  RFC 1738, December 1994.

   [2] Paul E. Hoffman and Ron Daniel, Jr.  Generic URN Syntax.
       draft-ietf-uri-urn-syntax-00.txt -- work in progress, April 1995. Ralph Droms.  Dynamic Host Configuration Protocol.  RFC 1541,
       October 1993.

   [3] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
       Location Protocol.  draft-ietf-svrloc-protocol-14.txt - work in
       progress, June Protocol, November 1996.  draft-ietf-svrloc-protocol-15.txt
       (work in progress).

Author's Address

   Questions about this memo can be directed to:

   Charles E. Perkins
          Room J1-A25
          T. J. Watson Research Center
          IBM Corporation
          30 Saw Mill River Rd.
          Hawthorne, NY  10532

          Work:
   Sun Microsystems
   2550 Garcia Avenue
   Mountain View, CA  94043

   Phone: +1 914 7847350 415 336 7153
   Fax:   +1 914 7847007
          E-mail: perk@watson.ibm.com 415 336 0670

   EMail: charliep@acm.org