The RFC Archive
 The RFC Archive   RFC 2610   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 2610

DHCP Options for Service Location Protocol

Last modified on Tuesday, June 8th, 1999

Permanent link to RFC 2610
Search GitHub Wiki for RFC 2610
Show other RFCs mentioning RFC 2610







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 © The Internet Society (1999).  All Rights Reserved.

 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.

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, 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].






Perkins & Guttman           Standards Track                  PAGE 1 top


RFC 2610 DHCP Options for Service Location Protocol June 1999 2. 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. 3. 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, 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. Perkins & Guttman Standards Track PAGE 2 top

RFC 2610 DHCP Options for Service Location Protocol June 1999 The SLPv2 specification [3] defines how to use this option. 4. 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]. 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. Perkins & Guttman Standards Track PAGE 3 top

RFC 2610 DHCP Options for Service Location Protocol June 1999 5. 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. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", Work in Progress. [4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997. [5] Yergeau, F., "UTF-8, a transformation format of unicode and ISO 10646", RFC 2279, October 1998. Perkins & Guttman Standards Track PAGE 4 top

RFC 2610 DHCP Options for Service Location Protocol June 1999 Authors' Addresses Charles E. Perkins Technology Development Group Mail Stop MPK15-214 Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 Phone: +1 650-786-6464 Fax: +1 650-786-6445 EMail: Charles.Perkins@Sun.Com Web: 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 Perkins & Guttman Standards Track PAGE 5 top

RFC 2610 DHCP Options for Service Location Protocol June 1999 Full Copyright Statement Copyright © 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. Perkins & Guttman Standards Track PAGE 6 top

DHCP Options for Service Location Protocol RFC TOTAL SIZE: 10859 bytes PUBLICATION DATE: Tuesday, June 8th, 1999 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 2610: The IETF Trust, Tuesday, June 8th, 1999
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement