Network Working Group C. Perkins Request for Comments: 2610 E. Guttman Category: Standards Track Sun Microsystems June 1999 DHCP Options for Service Location Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.
AbstractThe 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. 2] provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol, Version 2  and Service Location Protocol, Version 1  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 .
The SLPv2 specification  defines how to use this option. 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]. 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.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", Work in Progress.  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.  Yergeau, F., "UTF-8, a transformation format of unicode and ISO 10646", RFC 2279, October 1998.
http://www.svrloc.org/~charliep Erik Guttman Technology Development Group Mail Stop UFRA02 Sun Microsystems, Inc. Bahnstr. 2 74915 Waibstadt, Germany Phone: +49 7263 911 701 or: +1 650 786 5992 EMail: Erik.Guttman@Sun.Com
Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.