Service Location James Kempf INTERNET DRAFT Sun Microsystems December 23, 1999 Mikael Pahmp Axis Communications Roger Holm Novell, Inc. SLP Scope and DA Configuration draft-kempf-scope-rules-03.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are work- ing documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute 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." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract RFC 2608, RFC 2610, and RFC 2614 provide rules for configuring SLP agents with scopes and DAs from the protocol, DHCP, and API view- points, respectively. The rules presented in these three documents, while not in conflict, are ambiguous in certain cases. There are also cases that fall into the cracks between the three documents. For example, if the mandatory byte is off in DHCP for scopes and there are no statically configured scopes, but there are DHCP scopes, should an agent use the DHCP scopes or not? This document specifies a sequence of steps that interoperable implementations of Kempf, Pahmp, Holm expires June 2000 [Page 1] INTERNET DRAFT December 1999 SLP must follow in order to obtain a clear and unambiguous scope and DA configuration. 1. Introduction The RFCs specifying the design of the Service Location Protocol (SLP) contain descriptions about how to configure an SLP agent with scopes and DAs. These descriptions contain ambiguities and cases in which the procedure to follow in order to obtain a scope and DA con- figuration is inconsistent between the RFCs or missing. This docu- ment clarifies the scope and DA configuration policy for SLP, by specifying a sequence of steps that implementations of SLP must fol- low for an interoperable configuration procedure 2. Notation Conventions 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 RFC 2119 [1]. 3. Terminology In this section, some terms used later in the document are defined and related to definitions in RFCs 2608 [1], 2610 [2], and 2614 [3]. Dynamic scope discovery - Dynamic scope discovery is equivalent to user scope configuration as defined in RFC 2608. The UA performs active DA discovery or, if there are no DAs, active SA discovery. The scopes from the returned DAAdverts or SAAdverts are used. Dynamic DA Discovery - Dynamic DA discovery is equivalent to active DA discovery as defined in RFC 2608. The agent performs active DA discovery and uses the returned DAs. DA scopes - DA scopes are scope names obtained from DAAdverts returned in response to an active DA discovery, or in response to a unicast request for a DAAdvert to a configured DA. DHCP scopes - DHCP scopes are scope names contained in DHCP Option 79. Static config or static configuration- For scopes, the terms indicate the value of the net.slp.useScopes property. For DAs, the terms indicate the value of the net.slp.DAAddresses property. These properties are defined in RFC 2614. SA scopes - SA scopes are scopes that are discovered through SA discovery. Kempf, Pahmp, Holm expires June 2000 [Page 2] INTERNET DRAFT December 1999 4. Ambiguities in Scope and DA Configuration In this section, the major ambiguities pertaining to SLP scope and DA configuration are discussed. 4.1 Are Scopes Configured Through DA Scopes? The SLP protocol specification, RFC 2608 [1], states that UAs and SAs are configured with a list of scopes according to the following prioritized rules: 1. The scopes are set with DHCP. 2. The scopes are set with a static configuration file. The specification also states that the static configuration may be explicitly set to "no scope" for UAs, if the user selectable scope model (i.e. dynamic scope discovery) is desired. 3. If there is no configuration information, the agent's scope is "DEFAULT". RFC 2608 additionally states that when dynamic scope discovery is not used for UAs, if a system administrator wants SAs and UAs to use a scope other than the default, the scopes are configured, and can be configured automatically by DHCP options 78 or 79 (described in RFC 2610 [2]). Finally, RFC 2608 says this about DHCP configuration [1]: DHCP options 78 and 79 may be used to configure SLP. If DA locations are configured using DHCP, these SHOULD be used in preference to DAs discovered actively or passively. One or more of the scopes configured using DHCP MUST be used in requests. The entire configured MUST be used in registration and DA configuration messages. This discussion does not specify what scopes should be used if there is no scope configuration information from any source but there is DA configuration information, and the scopes of the DAs are not "DEFAULT". Should the agent get its scope information from the DAs or not? This question comes up in relation to the API specification, RFC 2614 [3], because the section on scope configuration implies that agents may, in fact, obtain scope configuration from configured DAs, rather than having the scopes configured directly. RFC 2614 has this to say about scope configuration in the API library: Kempf, Pahmp, Holm expires June 2000 [Page 3] INTERNET DRAFT December 1999 Scopes configured by DHCP and scopes of DAs configured by DHCP have first priority (in that order) and must be returned if they are available. The net.slp.useScopes property has second priority, and scopes discovered through the net.slp.useScopes property must be returned if this property is set and there are no scopes available from DHCP. If scopes are not available from either of these sources and the net.slp.DAAddresses property is set, then the scopes available from the configured DAs must be returned. The implication here is that scopes from DAs configured by DHCP can be used even if there are no scopes directly configured through DHCP, and similarly for statically configured scopes and DAs. 4.2 Interpretation of the Mandatory Flag The DHCP configuration option specification for SLP, RFC 2610 [2], specifies that option 78 (DA configuration) and option 79 (scope configuration) have a mandatory byte. The mandatory byte has dif- ferent effect depending on whether it is in option 78 or option 79. RFC 2610 states the following for the mandatory flag in option 78: The `MANDATORY' flag 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. This statement says nothing about what should occur if the mandatory flag is not set and static configuration information is present for DAs. Should the UA or SA use the static configuration information exclusively? Should it use the static configuration information and also perform dynamic DA discovery? Should it ignore the static con- figuration information and only perform DA discovery? RFC 2610 states the following for the mandatory flag in option 79: 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. Again, this statement is not clear about certain cases. What happens if the mandatory byte is not set, and there is a list of scopes in Kempf, Pahmp, Holm expires June 2000 [Page 4] INTERNET DRAFT December 1999 option 79 but there is no static configuration information? Should the agent use the DHCP-provided information, should it configure the scopes as "DEFAULT", or should it use scopes advertised by DAs discovered with dynamic DA discovery? 5. Scope and DA Configuration Procedure This section specifies how an interoperable SLP agent MUST config- ure its scope and DA lists. Scope configuration MUST precede DA con- figuration, except for UAs with no configured scopes. UAs without configured scopes derive scope information from configured DAs, dynamically discovered DAs, or dynamically discovered SAs if no DAs are discovered. DA and SA scopes MUST always be configured, in accordance with RFC 2608. When a UA doesn't have scopes configured through DHCP or stati- cally,it first checks whether any DAs are configured through DHCP or statically. If so, it contacts those DAs through unicast and uses the scopes provided by those DAs. If no DAs are configured through DHCP or statically, the UA performs an initial active discovery for DAs, and the scopes of those DAs are used by the UA. If no DAs are discovered, the UA uses SA discovery on demand to determine which scopes to use. Periodically thereafer, the UA does active and pas- sive discovery as determined by its configuration (net.slp.pas- siveDADetection and net.slp.DAActiveDiscoveryInterval). The scopes offered by the UA are determined by the results of active or passive discovery or by SA discovery if no DAs are found. Figure 1 contains the flow chart for scope configuration and Figure 2 contains the flow chart for DA configuration. Kempf, Pahmp, Holm expires June 2000 [Page 5] INTERNET DRAFT December 1999 Figure 1 Flow Chart for Scope Configuration ______________ YES __/DHCP Option 79\__ NO ^ | \ available? / | / \ | -------------- | \1/ | ^ v |________ / \ | YES __/Mandatory\__ NO /GO \ ___|___ | \ byte 1?/ | \ TO/ / DHCP \ | --------- | \2/ YES __/ Option \__ NO | | v | \ has / | ^ ^ | \scopes?/ | / \ / \ | ------- | /GO \ /GO \ ________ | \ TO/ \ TO/ |Use DHCP| | \1/ \4/ | scopes.| | v v -------- | | ^ / \ /GO \ \ TO/ \2/ v Kempf, Pahmp, Holm expires June 2000 [Page 6] INTERNET DRAFT December 1999 ^ / \ \2/ v | __________ / scope \ YES __/ static \__ NO | \ config / | ^ | \available?/ | / \ | ---------- | \3/ __________ | v |Use static| | | | config. | | _________ ---------- | YES __/Agent is \__ NO | | \DA or SA?/ | ^ | --------- | / \ ____________ __________ /GO \ |Use DEFAULT.|| Perform | \ TO/ ------------ | DA | \3/ | config | v ----------- | _____________| | ________|___ YES / DAs found? \ NO ------\ /--- | ------------ | | | ______|____ _____|_____ | Use DA | | Perform | | scopes | | SA | --------- |discovery,| | use | | DEFAULT | | if none | | found. | ---------- Kempf, Pahmp, Holm expires June 2000 [Page 7] INTERNET DRAFT December 1999 ^ / \ \4/ v | __________ / scope \ YES __/ static \__ NO | \ config / | | \available?/ | | ---------- | __________ | |Use static| | | config. | | ---------- | | _______ / DHCP \ YES __/ Option \__ NO | \ has / | | \scopes?/ | | ------- | ________ | |Use DHCP| | | scopes.| | -------- | ^ / \ /GO \ \ TO/ \3/ v Kempf, Pahmp, Holm expires June 2000 [Page 8] INTERNET DRAFT December 1999 Figure 2 Flow chart for DA configuration ______________ YES __/DHCP Option 78\_____________________________ NO | \ available? / | | -------------- | _________ | YES __/Mandatory\_____________________NO | | \ byte 1?/ | | | --------- | | ______ ______ | / DHCP \ / DHCP \ | YES __/ Option \__ NO YES __/ Option \____ NO | | \ has / | | \ has / | | | \ DAs? / | | \ DAs? / | | | ------ | | ------ | | ________ _______________ | | | |Use DHCP| |invalid DHCP | | _______________ | | DAs. | |config., report| | |invalid DHCP | | -------- |error. | | |config., report| | --------------- | |error. | | | --------------- | | | | | | | | | | | _______________________| | ______|______ | YES __/Static config\__ NO | | \ available? / | | | ------------- | | ___________ ___________ | |Merge DHCP,| |Merge DHCP | | |static, and| | and | | |dynamically| |dynamically| | |discovered | |discovered | | | DAs. | | DAS. | | ----------- ----------- | | Kempf, Pahmp, Holm expires June 2000 [Page 9] INTERNET DRAFT December 1999 |---------------------------------------| _____________ YES __/Static config\__ NO | \ available? / | | ------------- | | | __________ __________________ |Use static| | Perform dynamic | | config. | | DA discovery | ---------- ------------------ Note that the flowchart prohibits a DHCP Option 78 without a DA record, because RFC 2610 specifies that if Option 78 is present, the minimum length is 5, the mandatory byte plus at least one IP address. If the length is less than 5, the DHCP configuration is in error. 6. Resolution of Specific Ambiguities In this section, we discuss the resolution of ambiguities raised in Section 3. 6.1 Are Scopes Configured Through DA Scopes? >From Figure 1, the answer is that scopes are never configured through DA scopes, unless the agent is a UA. A UA with no configured scopes uses DA scopes if DAs are configured or discovered. 6.2 Interpretation of the Mandatory Flag for DHCP Option 78 >From Figure 2, if the mandatory flag is not set and static configu- ration information is present for DAs, the agent uses the static configuration information even if DHCP information is available. This allows a system administrator or power user to override a glo- bal, DHCP supplied configuration on an individual host basis. 6.3 Interpretation of the Mandatory Flag for DHCP Option 79 >From Figure 1, if the mandatory flag is not set and static configu- ration information is present for scopes, the agent uses the static configuration information even if DHCP information is present. As with DA configuration, this allows a system administrator or power user to override a global, DHCP supplied configuration on an indi- vidual host basis. 7. Security Considerations Kempf, Pahmp, Holm expires June 2000 [Page 10] INTERNET DRAFT December 1999 Dynamic discovery of scopes and DAs are subject to the security con- siderations discussed in RFC 2608. Scopes and DAs discovered with DHCP are subject to the security considerations associated with DHCP. 8. Full Copyright Statement Copyright (C) The Internet Society (1997). 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 devel- oping Internet standards in which case the procedures for copy- rights 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." 9. References [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [2] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol. RFC 2608. June 1999. [3] C. Perkins and E. Guttman DHCP Options for Service Location Pro- tocol. RFC 2610 June 1999. [4] J. Kempf and E. Guttman An API for Service Location. RFC 2614 June 1999. 10. Author's Addresses Kempf, Pahmp, Holm expires June 2000 [Page 11] INTERNET DRAFT December 1999 James Kempf Mikael Pahmp Roger Holm Sun Microsystems Axis Communications Novell, Inc. 901 San Antonio Rd. Scheelev. 16 122 East 1700 South UMPK15-214 S-223 70 Lund Provo, UT, 84606-6194 Palo Alto, CA, 94043 Sweden USA USA +1 650 786 5890 +46 46 270 1881 +1 801 861 7000 james.kempf@sun.com mikael.pahmp@axis.com rholm@novell.com Kempf, Pahmp, Holm expires June 2000 [Page 12]