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 <scope-list> 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]