home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2610.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  10.9 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Perkins
  8. Request for Comments: 2610                                    E. Guttman
  9. Category: Standards Track                               Sun Microsystems
  10.                                                                June 1999
  11.  
  12.  
  13.                DHCP Options for Service Location Protocol
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  26.  
  27. Abstract
  28.  
  29.    The Dynamic Host Configuration Protocol provides a framework for
  30.    passing configuration information to hosts on a TCP/IP network.
  31.    Entities using the Service Location Protocol need to find out the
  32.    address of Directory Agents in order to transact messages.  Another
  33.    option provides an assignment of scope for configuration of SLP User
  34.    and Service Agents.
  35.  
  36. 1. Introduction
  37.  
  38.    The Dynamic Host Configuration Protocol [2] provides a framework for
  39.    passing configuration information to hosts on a TCP/IP network.
  40.    Entities using the Service Location Protocol, Version 2 [3] and
  41.    Service Location Protocol, Version 1 [4] need to obtain the address
  42.    of Directory Agents and Scope configuration.  The Service Location
  43.    Protocol (SLP) provides a default configuration for Scopes and
  44.    Directory Agents may be discovered using multicast or broadcast.  It
  45.    is useful in a larger deployment to be able to configure SLP Agents
  46.    using DHCP, so as to centralize the administration and to deploy SLP
  47.    in networks where multicast routing is not available.
  48.  
  49.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  50.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  51.    document are to be interpreted as described in [1].
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Perkins & Guttman           Standards Track                     [Page 1]
  59.  
  60. RFC 2610       DHCP Options for Service Location Protocol      June 1999
  61.  
  62.  
  63. 2. Introduction
  64.  
  65.    The DHCP options described below are used to configure Agents using
  66.    the Service Location Protocol, Version 2 [3] and Version 1 [4].
  67.  
  68.    The SLP Directory Agent option is used to configure User Agents and
  69.    Service Agents with the location of Directory Agents in the network.
  70.  
  71.    The SLP Scope Option takes precedence over both default and static
  72.    scope configuration of SLP agents.
  73.  
  74. 3. SLP Directory Agent Option
  75.  
  76.    This option specifies the location of one or more SLP Directory
  77.    Agents.
  78.  
  79.     0                   1                   2                   3
  80.     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
  81.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  82.    |   Code = 78   |    Length     |   Mandatory   |      a1       |
  83.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  84.    |      a2       |       a3      |       a4      |      ...
  85.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  86.  
  87.    The SLP Directory Agent Option specifies a list of IP addresses for
  88.    Directory Agents.  Directory Agents MUST be listed in order of
  89.    preference, if there is an order of preference.
  90.  
  91.    The Length value must include one for the 'Mandatory' byte and
  92.    include four for each Directory Agent address which follows.  Thus,
  93.    the Length minus one of the option MUST always be divisible by 4 and
  94.    has a minimum value of 5.
  95.  
  96.    The address of the Directory Agent is given in network byte order.
  97.  
  98.    The 'Mandatory' byte in the Directory Agent option may be set to
  99.    either 0 or 1.  If it is set to 1, the SLP User Agent or Service
  100.    Agent so configured MUST NOT employ either active or passive
  101.    multicast discovery of Directory Agents.
  102.  
  103.    Note that for backward compatibility with some deployed software the
  104.    Mandatory byte MUST NOT be set to any byte value for which the high
  105.    order bit (0x80) is set.
  106.  
  107.    The Directory Agents listed in this option MUST be configured with
  108.    the a non-empty subset of the scope list that the Agent receiving the
  109.    Directory Agent Option is configured with.  See the notes below.
  110.  
  111.  
  112.  
  113.  
  114. Perkins & Guttman           Standards Track                     [Page 2]
  115.  
  116. RFC 2610       DHCP Options for Service Location Protocol      June 1999
  117.  
  118.  
  119.    The SLPv2 specification [3] defines how to use this option.
  120.  
  121. 4. SLP Service Scope Option
  122.  
  123.    The scope list is a comma delimited list which indicates the scopes
  124.    that a SLP Agent is configured to use.
  125.  
  126.     0                   1                   2                   3
  127.     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
  128.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  129.    |   Code = 79   |     Length    |   Mandatory   | <Scope List>...
  130.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  131.  
  132.    The Length indicates the number of bytes which follow.  Since the
  133.    Scope-List String is encoded using UTF-8 [5] characters, it may be
  134.    the cast that the Length is not the same as the number of characters
  135.    in the Scope-List String.  The Length value must include one for the
  136.    'Mandatory' byte.
  137.  
  138.    The 'Mandatory' byte determines whether SLP Agents override their
  139.    static configuration for scopes with the <Scope List> string provided
  140.    by the option.  This allows DHCP administrators to implement a policy
  141.    of assigning a set of scopes to Agents for service provision.  If the
  142.    Mandatory byte is 0, static configuration takes precedence over the
  143.    DHCP provided scope list.  If the Mandatory byte is 1, the <Scope
  144.    List> provided in this option MUST be used by the SLP Agent.
  145.  
  146.    The Scope List String syntax and usage are defined in the SLPv2
  147.    specification [3].
  148.  
  149. 4.1. Zero Length Scope-List String Configuration
  150.  
  151.    A SLP Service Scope Option which indicates a Length of 1 (in other
  152.    words, omitting the <Scope List> string entirely) validly configures
  153.    the SLP User Agent to use "User Selectable Scopes."
  154.  
  155.    The SLP Agent will use the aggregated list of scopes of all known
  156.    DAs.  If no DAs are known, the UA will use SA discovery to determine
  157.    the list of scopes on the network, as defined in  [3].
  158.  
  159.    Note that this configuration is tantamount to removing all
  160.    centralized control of the scope configuration of hosts on the
  161.    network.  This makes it possible for every User Agent to see every
  162.    service.  This may not be desirable as users may not be able to or
  163.    desire to decide which services are appropriate for them.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Perkins & Guttman           Standards Track                     [Page 3]
  171.  
  172. RFC 2610       DHCP Options for Service Location Protocol      June 1999
  173.  
  174.  
  175. 5. Security Considerations
  176.  
  177.    If a malicious host is able to insert fraudulent information in
  178.    DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent
  179.    will be unable to obtain service, or may unwittingly be directed to
  180.    use the incorrect services.
  181.  
  182.    Many opportunities for denial of service exist.  A service agent
  183.    could find that it might rely on fraudulent or otherwise malicious
  184.    directory agents to advertise its services.  DHCPOFFERs could prevent
  185.    the regular SLP framework from functioning by directing clients to
  186.    not use multicast, to use nonexistent directory agents and so on.
  187.  
  188.    These difficulties are inherited from the much larger and more
  189.    serious problem, viz.  securing or authenticating any information
  190.    whatsoever from a DHCP server (or client!)  is not possible in common
  191.    DHCP deployments.
  192.  
  193. References
  194.  
  195.    [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  196.        Levels", BCP 14, RFC 2119, March 1997.
  197.  
  198.    [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
  199.        1997.
  200.  
  201.    [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
  202.        Location Protocol version 2", Work in Progress.
  203.  
  204.    [4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
  205.        Location Protocol", RFC 2165, July 1997.
  206.  
  207.    [5] Yergeau, F., "UTF-8, a transformation format of unicode and ISO
  208.        10646", RFC 2279, October 1998.
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Perkins & Guttman           Standards Track                     [Page 4]
  227.  
  228. RFC 2610       DHCP Options for Service Location Protocol      June 1999
  229.  
  230.  
  231. Authors' Addresses
  232.  
  233.    Charles E. Perkins
  234.    Technology Development Group
  235.    Mail Stop MPK15-214
  236.    Sun Microsystems, Inc.
  237.    15 Network Circle
  238.    Menlo Park, CA  94025
  239.  
  240.    Phone: +1 650-786-6464
  241.    Fax:   +1 650-786-6445
  242.    EMail: Charles.Perkins@Sun.Com
  243.    Web: http://www.svrloc.org/~charliep
  244.  
  245.  
  246.    Erik Guttman
  247.    Technology Development Group
  248.    Mail Stop UFRA02
  249.    Sun Microsystems, Inc.
  250.    Bahnstr. 2
  251.    74915 Waibstadt, Germany
  252.  
  253.    Phone: +49 7263 911 701
  254.      or:  +1 650 786 5992
  255.    EMail: Erik.Guttman@Sun.Com
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Perkins & Guttman           Standards Track                     [Page 5]
  283.  
  284. RFC 2610       DHCP Options for Service Location Protocol      June 1999
  285.  
  286.  
  287. Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315. Acknowledgement
  316.  
  317.    Funding for the RFC Editor function is currently provided by the
  318.    Internet Society.
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Perkins & Guttman           Standards Track                     [Page 6]
  339.  
  340.