--- 1/draft-ietf-dhc-slp-05.txt 2006-02-04 23:05:52.000000000 +0100 +++ 2/draft-ietf-dhc-slp-06.txt 2006-02-04 23:05:52.000000000 +0100 @@ -1,18 +1,18 @@ Internet Engineering Task Force C. Perkins INTERNET DRAFT E. Guttman Sun Microsystems - 14 October 1998 + 16 December 1998 DHCP Options for Service Location Protocol - draft-ietf-dhc-slp-05.txt + draft-ietf-dhc-slp-06.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. @@ -36,39 +36,39 @@ 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 [4] provides a framework + 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 [6] need to + Entities using the Service Location Protocol, Version 2 [3] 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 [2]. + document are to be interpreted as described in [1]. 2. Introduction The DHCP options described below are used to configure Agents using - the Service Location Protocol, Version 2 [6]. + the Service Location Protocol, Version 2 [3]. 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 @@ -87,55 +87,59 @@ preference, if there is an order of preference. The address of the Directory Agent is given in network byte order. The length of the option MUST always be divisible by 4 and has a minimum length of 4. 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 [6] defines how to use this option. + 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 | String ... + | Code = 79 | Length | MANDATORY | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length indicates the number of bytes which follow. Since the - Scope-List String is encoded using UTF8 characters, it may be the - cast that the Length is not the same as the number of characters in - the Scope-List String. + Scope-List String is encoded using UTF-8 [4] 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 minimum length is 0, and the maximum length is 256. This imposes - a limit on the size of the Scope-List String which can be delivered - which does not exist in SLP. DHCP administrators will therefore have - to be careful to not configure very long scope names or very long - lists of scopes for any Agents in their network. + The 'MANDATORY' byte determines whether SLP Agents override their + static configuration for scopes with the 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 zero, static configuration takes + precedence over the DHCP provided scope list. If the MANDATORY byte + is nonzero, the provided in this option MUST be used by + the SLP Agent. The Scope List String syntax and usage are defined in the SLPv2 - specification [6]. + specification [3]. 4.1. Zero Length Scope-List String Configuration - A SLP Service Scope Option which indicates a Length of 0 configures - the SLP Agent to use "User Selectable Scopes". - + A SLP Service Scope Option which indicates a Length of 1 (in other + words, omitting the 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 [6]. + 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. 5. Security Considerations If a malicious host is able to insert fraudulent information in @@ -147,55 +151,67 @@ 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 +6. Full Copyright Statement - [1] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource - Identifiers (URI): Generic Syntax. RFC 2396, August 1998. + Copyright (C) The Internet Society (1997). All Rights Reserved. - [2] S. Bradner. Key words for use in RFCs to Indicate Requirement - Levels. RFC 2119, March 1997. + 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. - [3] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, - February 1996. + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. - [4] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March - 1997. + 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." - [5] E. Guttman, C. Perkins, and J. Kempf. Service Templates and - service: Schemes. draft-ietf-svrloc-service-scheme-11.txt, - October 1998. (work in progress). +References - [6] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service - Location Protocol version 2. draft-ietf-svrloc-protocol-v2-09.txT, - October 1998. (work in progress). + [1] S. Bradner. Key words for use in RFCs to Indicate Requirement + Levels. RFC 2119, March 1997. - [7] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service - Location Protocol. RFC 2165, July 1997. + [2] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March + 1997. - [8] F. Yergeau. UTF-8, a transformation format of unicode and ISO - 10646. RFC 2279, October 1998. + [3] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service + Location Protocol version 2. draft-ietf-svrloc-protocol-v2-11.txt, + October 1998. (work in progress). - [9] D. Crocker and P. Overell. Augmented BNF for Syntax - Specifications: ABNF. RFC 2234, November 1997. + [4] F. Yergeau. UTF-8, a transformation format of unicode and ISO + 10646. RFC 2279, October 1998. 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.. + 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