diff options
Diffstat (limited to 'utils/open-isns/doc/rfc2608.txt')
| -rw-r--r-- | utils/open-isns/doc/rfc2608.txt | 3027 |
1 files changed, 0 insertions, 3027 deletions
diff --git a/utils/open-isns/doc/rfc2608.txt b/utils/open-isns/doc/rfc2608.txt deleted file mode 100644 index fa7de62..0000000 --- a/utils/open-isns/doc/rfc2608.txt +++ /dev/null @@ -1,3027 +0,0 @@ - - - - - - -Network Working Group E. Guttman -Request for Comments: 2608 C. Perkins -Updates: 2165 Sun Microsystems -Category: Standards Track J. Veizades - @Home Network - M. Day - Vinca Corporation - June 1999 - - - Service Location Protocol, Version 2 - -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. - -Abstract - - The Service Location Protocol provides a scalable framework for the - discovery and selection of network services. Using this protocol, - computers using the Internet need little or no static configuration - of network services for network based applications. This is - especially important as computers become more portable, and users - less tolerant or able to fulfill the demands of network system - administration. - -Table of Contents - - 1. Introduction 3 - 1.1. Applicability Statement . . . . . . . . . . . . . . . 3 - 2. Terminology 4 - 2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4 - 3. Protocol Overview 5 - 4. URLs used with Service Location 8 - 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9 - 4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10 - 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10 - 5. Service Attributes 10 - 6. Required Features 12 - 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13 - - - -Guttman, et al. Standards Track [Page 1] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14 - 6.3. Retransmission of SLP messages . . . . . . . . . . . 15 - 6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16 - 6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16 - 7. Errors 17 - 8. Required SLP Messages 17 - 8.1. Service Request . . . . . . . . . . . . . . . . . . . 19 - 8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21 - 8.3. Service Registration . . . . . . . . . . . . . . . . . 22 - 8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23 - 8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24 - 8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25 - 9. Optional Features 26 - 9.1. Service Location Protocol Extensions . . . . . . . . . 27 - 9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28 - 9.2.1. SLP Message Authentication Rules . . . . . . . 29 - 9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30 - 9.3. Incremental Service Registration . . . . . . . . . . 30 - 9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31 - 10. Optional SLP Messages 32 - 10.1. Service Type Request . . . . . . . . . . . . . . . . 32 - 10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32 - 10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33 - 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34 - 10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34 - 10.6. Service Deregistration . . . . . . . . . . . . . . . 36 - 11. Scopes 37 - 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37 - 11.2. Administrative and User Selectable Scopes. . . . . . . 38 - 12. Directory Agents 38 - 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39 - 12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39 - 12.2.1. Active DA Discovery . . . . . . . . . . . . . 40 - 12.2.2. Passive DA Advertising . . . . . . . . . . . . 40 - 12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41 - 12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41 - 12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41 - 13. Protocol Timing Defaults 42 - 14. Optional Configuration 43 - 15. IANA Considerations 44 - 16. Internationalization Considerations 45 - 17. Security Considerations 46 - A. Appendix: Changes to the Service Location Protocol from - v1 to v2 48 - B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48 - C. Appendix: DAAdverts with arbitrary URLs 49 - D. Appendix: SLP Protocol Extensions 50 - D.1. Required Attribute Missing Option . . . . . . . . . . 50 - - - -Guttman, et al. Standards Track [Page 2] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - E. Acknowledgments 50 - F. References 51 - G. Authors' Addresses 53 - H. Full Copyright Statement 54 - -1. Introduction - - The Service Location Protocol (SLP) provides a flexible and scalable - framework for providing hosts with access to information about the - existence, location, and configuration of networked services. - Traditionally, users have had to find services by knowing the name of - a network host (a human readable text string) which is an alias for a - network address. SLP eliminates the need for a user to know the name - of a network host supporting a service. Rather, the user supplies - the desired type of service and a set of attributes which describe - the service. Based on that description, the Service Location - Protocol resolves the network address of the service for the user. - - SLP provides a dynamic configuration mechanism for applications in - local area networks. Applications are modeled as clients that need - to find servers attached to any of the available networks within an - enterprise. For cases where there are many different clients and/or - services available, the protocol is adapted to make use of nearby - Directory Agents that offer a centralized repository for advertised - services. - - This document updates SLPv1 [RFC 2165], correcting protocol errors, - adding some enhancements and removing some requirements. This - specification has two parts. The first describes the required - features of the protocol. The second describes the extended features - of the protocol which are optional, and allow greater scalability. - -1.1. Applicability Statement - - SLP is intended to function within networks under cooperative - administrative control. Such networks permit a policy to be - implemented regarding security, multicast routing and organization of - services and clients into groups which are not be feasible on the - scale of the Internet as a whole. - - SLP has been designed to serve enterprise networks with shared - services, and it may not necessarily scale for wide-area service - discovery throughout the global Internet, or in networks where there - are hundreds of thousands of clients or tens of thousands of - services. - - - - - - -Guttman, et al. Standards Track [Page 3] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -2. Terminology - - User Agent (UA) - A process working on the user's behalf to establish - contact with some service. The UA retrieves service - information from the Service Agents or Directory Agents. - - Service Agent (SA) A process working on the behalf of one or more - services to advertise the services. - - Directory Agent (DA) A process which collects service - advertisements. There can only be one DA present per - given host. - - Service Type Each type of service has a unique Service Type - string. - - Naming Authority The agency or group which catalogues given - Service Types and Attributes. The default Naming - Authority is IANA. - - Scope A set of services, typically making up a logical - administrative group. - - URL A Universal Resource Locator [8]. - -2.1. 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 [9]. - - Syntax Syntax for string based protocols follow the - conventions defined for ABNF [11]. - - Strings All strings are encoded using the UTF-8 [23] - transformation of the Unicode [6] character set and - are NOT null terminated when transmitted. Strings - are preceded by a two byte length field. - - <string-list> A comma delimited list of strings with the - following syntax: - - string-list = string / string `,' string-list - - In format diagrams, any field ending with a \ indicates a variable - length field, given by a prior length field in the protocol. - - - - -Guttman, et al. Standards Track [Page 4] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -3. Protocol Overview - - The Service Location Protocol supports a framework by which client - applications are modeled as 'User Agents' and services are advertised - by 'Service Agents.' A third entity, called a 'Directory Agent' - provides scalability to the protocol. - - The User Agent issues a 'Service Request' (SrvRqst) on behalf of the - client application, specifying the characteristics of the service - which the client requires. The User Agent will receive a Service - Reply (SrvRply) specifying the location of all services in the - network which satisfy the request. - - The Service Location Protocol framework allows the User Agent to - directly issue requests to Service Agents. In this case the request - is multicast. Service Agents receiving a request for a service which - they advertise unicast a reply containing the service's location. - - +------------+ ----Multicast SrvRqst----> +---------------+ - | User Agent | | Service Agent | - +------------+ <----Unicast SrvRply------ +---------------+ - - In larger networks, one or more Directory Agents are used. The - Directory Agent functions as a cache. Service Agents send register - messages (SrvReg) containing all the services they advertise to - Directory Agents and receive acknowledgements in reply (SrvAck). - These advertisements must be refreshed with the Directory Agent or - they expire. User Agents unicast requests to Directory Agents - instead of Service Agents if any Directory Agents are known. - - +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ - | User | | Directory | |Service | - | Agent | | Agent | | Agent | - +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ - - User and Service Agents discover Directory Agents two ways. First, - they issue a multicast Service Request for the 'Directory Agent' - service when they start up. Second, the Directory Agent sends an - unsolicited advertisement infrequently, which the User and Service - Agents listen for. In either case the Agents receive a DA - Advertisement (DAAdvert). - - +---------------+ --Multicast SrvRqst-> +-----------+ - | User or | <--Unicast DAAdvert-- | Directory | - | Service Agent | | Agent | - +---------------+ <-Multicast DAAdvert- +-----------+ - - - - - -Guttman, et al. Standards Track [Page 5] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Services are grouped together using 'scopes'. These are strings - which identify services which are administratively identified. A - scope could indicate a location, administrative grouping, proximity - in a network topology or some other category. Service Agents and - Directory Agents are always assigned a scope string. - - A User Agent is normally assigned a scope string (in which case the - User Agent will only be able to discover that particular grouping of - services). This allows a network administrator to 'provision' - services to users. Alternatively, the User Agent may be configured - with no scope at all. In that case, it will discover all available - scopes and allow the client application to issue requests for any - service available on the network. - - +---------+ Multicast +-----------+ Unicast +-----------+ - | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | - | Agent | | Agent | | Agent | - | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | - +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+ - - In the above illustration, the User Agent is configured with scopes X - and Y. If a service is sought in scope X, the request is multicast. - If it is sought in scope Y, the request is unicast to the DA. - Finally, if the request is to be made in both scopes, the request - must be both unicast and multicast. - - Service Agents and User Agents may verify digital signatures provided - with DAAdverts. User Agents and Directory Agents may verify service - information registered by Service Agents. The keying material to use - to verify digital signatures is identified using a SLP Security - Parameter Index, or SLP SPI. - - Every host configured to generate a digital signature includes the - SLP SPI used to verify it in the Authentication Block it transmits. - Every host which can verify a digital signature must be configured - with keying material and other parameters corresponding with the SLP - SPI such that it can perform verifying calculations. - - SAs MUST accept multicast service requests and unicast service - requests. SAs MAY accept other requests (Attribute and Service Type - Requests). SAs MUST listen for multicast DA Advertisements. - - The features described up to this point are required to implement. A - minimum implementation consists of a User Agent, Service Agent or - both. - - There are several optional features in the protocol. Note that DAs - MUST support all these message types, but DA support is itself - - - -Guttman, et al. Standards Track [Page 6] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - optional to deploy on networks using SLP. UAs and SAs MAY support - these message types. These operations are primarily for interactive - use (browsing or selectively updating service registrations.) UAs - and SAs either support them or not depending on the requirements and - constraints of the environment where they will be used. - - Service Type Request A request for all types of service on the - network. This allows generic service browsers - to be built. - - Service Type Reply A reply to a Service Type Request. - - Attribute Request A request for attributes of a given type of - service or attributes of a given service. - - Attribute Reply A reply to an Attribute Request. - - Service Deregister A request to deregister a service or some - attributes of a service. - - Service Update A subsequent SrvRqst to an advertisement. - This allows individual dynamic attributes to - be updated. - - SA Advertisement In the absence of Directory Agents, a User - agent may request Service Agents in order - to discover their scope configuration. The - User Agent may use these scopes in requests. - - In the absence of Multicast support, Broadcast MAY be used. The - location of DAs may be staticly configured, discovered using SLP as - described above, or configured using DHCP. If a message is too large, - it may be unicast using TCP. - - A SLPv2 implementation SHOULD support SLPv1 [22]. This support - includes: - - 1. SLPv2 DAs are deployed, phasing out SLPv1 DAs. - - 2. Unscoped SLPv1 requests are considered to be of DEFAULT scope. - SLPv1 UAs MUST be reconfigured to have a scope if possible. - - 3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1 - DA. SLPv1 SAs MUST be reconfigured to have a scope if possible. - - 4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 - requests with SLPv2 replies. - - - - -Guttman, et al. Standards Track [Page 7] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - 5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same - way. That is, incoming requests from agents using either version - of the protocol will be matched against this common set of - registered services. - - 6. SLPv2 registrations which use Language Tags which are greater - than 2 characters long will be inaccessible to SLPv1 UAs. - - 7. SLPv2 DAs MUST return only service type strings in SrvTypeRply - messages which conform to SLPv1 service type string syntax, ie. - they MUST NOT return Service Type strings for abstract service - types. - - 8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service - URLs with abstract service types. They only match Service URLs - with concrete service types. - - SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will - not receive replies from SLPv1 SAs. In order to interoperate UAs and - SAs of different versions require a SLPv2 DA to be present on the - network which supports both protocols. - - The use of abstract service types in SLPv2 presents a backward - compatibility issue for SLPv1. It is possible that a SLPv1 UA will - request a service type which is actually an abstract service type. - Based on the rules above, the SLPv1 UA will never receive an abstract - Service URL reply. For example, the service type 'service:x' in a - SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'. - If the request was made with SLPv2, it would return the attributes of - this service. - -4. URLs used with Service Location - - A Service URL indicates the location of a service. This URL may be - of the service: scheme [13] (reviewed in section 4.1), or any other - URL scheme conforming to the URI standard [8], except that URLs - without address specifications SHOULD NOT be advertised by SLP. The - service type for an 'generic' URL is its scheme name. For example, - the service type string for "http://www.srvloc.org" would be "http". - - Reserved characters in URLs follow the rules in RFC 2396 [8]. - - - - - - - - - - -Guttman, et al. Standards Track [Page 8] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -4.1. Service: URLs - - Service URL syntax and semantics are defined in [13]. Any network - service may be encoded in a Service URL. - - This section provides an introduction to Service URLs and an example - showing a simple application of them, representing standard network - services. - - A Service URL may be of the form: - - "service:"<srvtype>"://"<addrspec> - - The Service Type of this service: URL is defined to be the string up - to (but not including) the final `:' before <addrspec>, the address - specification. - - <addrspec> is a hostname (which should be used if possible) or dotted - decimal notation for a hostname, followed by an optional `:' and - port number. - - A service: scheme URL may be formed with any standard protocol name - by concatenating "service:" and the reserved port [1] name. For - example, "service:tftp://myhost" would indicate a tftp service. A - tftp service on a nonstandard port could be - "service:tftp://bad.glad.org:8080". - - Service Types SHOULD be defined by a "Service Template" [13], which - provides expected attributes, values and protocol behavior. An - abstract service type (also described in [13]) has the form - - "service:<abstract-type>:<concrete-type>". - - The service type string "service:<abstract-type>" matches all - services of that abstract type. If the concrete type is included - also, only these services match the request. For example: a SrvRqst - or AttrRqst which specifies "service:printer" as the Service Type - will match the URL service:printer:lpr://hostname and - service:printer:http://hostname. If the requests specified - "service:printer:http" they would match only the latter URL. - - An optional substring MAY follow the last `.' character in the - <srvtype> (or <abstract-type> in the case of an abstract service type - URL). This substring is the Naming Authority, as described in Section - 9.6. Service types with different Naming Authorities are quite - distinct. In other words, service:x.one and service:x.two are - different service types, as are service:abstract.one:y and - service:abstract.two:y. - - - -Guttman, et al. Standards Track [Page 9] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -4.2. Naming Authorities - - A Naming Authority MAY optionally be included as part of the Service - Type string. The Naming Authority of a service defines the meaning - of the Service Types and attributes registered with and provided by - Service Location. The Naming Authority itself is typically a string - which uniquely identifies an organization. IANA is the implied - Naming Authority when no string is appended. "IANA" itself MUST NOT - be included explicitly. - - Naming Authorities may define Service Types which are experimental, - proprietary or for private use. Using a Naming Authority, one may - either simply ignore attributes upon registration or create a local- - use only set of attributes for one's site. The procedure to use is - to create a 'unique' Naming Authority string and then specify the - Standard Attribute Definitions as described above. This Naming - Authority will accompany registration and queries, as described in - Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA - to allow for Internet-wide interoperability. - -4.3. URL Entries - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | Lifetime | URL Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |URL len, contd.| URL (variable length) \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |# of URL auths | Auth. blocks (if any) \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - SLP stores URLs in protocol elements called URL Entries, which - associate a length, a lifetime, and possibly authentication - information along with the URL. URL Entries, defined as shown above, - are used in Service Replies and Service Registrations. - -5. Service Attributes - - A service advertisement is often accompanied by Service Attributes. - These attributes are used by UAs in Service Requests to select - appropriate services. - - The allowable attributes which may be used are typically specified by - a Service Template [13] for a particular service type. Services - which are advertised according to a standard template MUST register - all service attributes which the standard template requires. URLs - with schemes other than "service:" MAY be registered with attributes. - - - -Guttman, et al. Standards Track [Page 10] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Non-standard attribute names SHOULD begin with "x-", because no - standard attribute name will ever have those initial characters. - - An attribute list is a string encoding of the attributes of a - service. The following ABNF [11] grammar defines attribute lists: - - attr-list = attribute / attribute `,' attr-list - attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag - attr-val-list = attr-val / attr-val `,' attr-val-list - attr-tag = 1*safe-tag - attr-val = intval / strval / boolval / opaque - intval = [-]1*DIGIT - strval = 1*safe-val - boolval = "true" / "false" - opaque = "\FF" 1*escape-val - safe-val = ; Any character except reserved. - safe-tag = ; Any character except reserved, star and bad-tag. - reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL - escape-val = `\' HEXDIG HEXDIG - bad-tag = CR / LF / HTAB / `_' - star = `*' - - The <attr-list>, if present, MUST be scanned prior to evaluation for - all occurrences of the escape character `\'. Reserved characters - MUST be escaped (other characters MUST NOT be escaped). All escaped - characters must be restored to their value before attempting string - matching. For Opaque values, escaped characters are not converted - - they are interpreted as bytes. - - Boolean Strings which have the form "true" or "false" can - only take one value and may only be compared with - '='. Booleans are case insensitive when compared. - - Integer Strings which take the form [-] 1*<digit> and fall - in the range "-2147483648" to "2147483647" are - considered to be Integers. These are compared using - integer comparison. - - String All other Strings are matched using strict lexical - ordering (see Section 6.4). - - Opaque Opaque values are sequences of bytes. These are - distinguished from Strings since they begin with - the sequence "\FF". This, unescaped, is an illegal - UTF-8 encoding, indicating that what follows is a - sequence of bytes expressed in escape notation which - constitute the binary value. For example, a '0' byte - is encoded "\FF\00". - - - -Guttman, et al. Standards Track [Page 11] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - A string which contains escaped values other than from the reserved - set of characters is illegal. If such a string is included in an - <attr-list>, <tag-list> or search filter, the SA or DA which receives - it MUST return a PARSE_ERROR to the message. - - A keyword has only an <attr-tag>, and no values. Attributes can have - one or multiple values. All values are expressed as strings. - - When values have been advertised by a SA or are registered in a DA, - they can take on implicit typing rules for matching incoming - requests. - - Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is - disallowed. A DA or SA receiving such an <attr-list> MUST return an - INVALID_REGISTRATION error. - -6. Required Features - - This section defines the minimal implementation requirements for SAs - and UAs as well as their interaction with DAs. A DA is not required - for SLP to function, but if it is present, the UA and SA MUST - interact with it as defined below. - - A minimal implementation may consist of either a UA or SA or both. - The only required features of a UA are that it can issue SrvRqsts - according to the rules below and interpret DAAdverts, SAAdverts and - SrvRply messages. The UA MUST issue requests to DAs as they are - discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or - SAAdvert messages. The SA MUST also register with DAs as they are - discovered. - - UAs perform discovery by issuing Service Request messages. SrvRqst - messages are issued, using UDP, following these prioritized rules: - - 1. A UA issues a request to a DA which it has been configured with - by DHCP. - - 2. A UA issues requests to DAs which it has been statically - configured with. - - 3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses - that set of DAs. A UA that does not know of any DAs SHOULD retry - DA discovery, increasing the waiting interval between subsequent - attempts exponentially (doubling the wait interval each time.) - The recommended minimum waiting interval is CONFIG_DA_FIND - seconds. - - - - - -Guttman, et al. Standards Track [Page 12] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - 4. A UA with no knowledge of DAs sends requests using multicast - convergence to SAs. SAs unicast replies to UAs according to the - multicast convergence algorithm. - - UAs and SAs are configured with a list of scopes to use according to - these prioritized rules: - - 1. With DHCP. - - 2. With static configuration. The static configuration may be - explicitly set to NO SCOPE for UAs, if the User Selectable Scope - model is used. See section 11.2. - - 3. In the absence of configuration, the agent's scope is "DEFAULT". - - A UA MUST issue requests with one or more of the scopes it has been - configured to use. - - A UA which has been statically configured with NO SCOPE LIST will use - DA or SA discovery to determine its scope list dynamically. In this - case it uses an empty scope list to discover DAs and possibly SAs. - Then it uses the scope list it obtains from DAAdverts and possibly - SAAdverts in subsequent requests. - - The SA MUST register all its services with any DA it discovers, if - the DA advertises any of the scopes it has been configured with. A - SA obtains information about DAs as a UA does. In addition, the SA - MUST listen for multicast unsolicited DAAdverts. The SA registers by - sending SrvReg messages to DAs, which reply with SrvReg messages to - indicate success. SAs register in ALL the scopes they were - configured to use. - -6.1. Use of Ports, UDP, and Multicast - - DAs MUST accept unicast requests and multicast directory agent - discovery service requests (for the service type "service:directory- - agent"). - - SAs MUST accept multicast requests and unicast requests both. The SA - can distinguish between them by whether the REQUEST MCAST flag is set - in the SLP Message header. - - The Service Location Protocol uses multicast for discovering DAs and - for issuing requests to SAs by default. - - The reserved listening port for SLP is 427. This is the destination - port for all SLP messages. SLP messages MAY be transmitted on an - ephemeral port. Replies and acknowledgements are sent to the port - - - -Guttman, et al. Standards Track [Page 13] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - from which the request was issued. The default maximum transmission - unit for UDP messages is 1400 bytes excluding UDP and other headers. - - If a SLP message does not fit into a UDP datagram it MUST be - truncated to fit, and the OVERFLOW flag is set in the reply message. - A UA which receives a truncated message MAY open a TCP connection - (see section 6.2) with the DA or SA and retransmit the request, using - the same XID. It MAY also attempt to make use of the truncated reply - or reformulate a more restrictive request which will result in a - smaller reply. - - SLP Requests messages are multicast to The Administratively Scoped - SLP Multicast [17] address, which is 239.255.255.253. The default - TTL to use for multicast is 255. - - In isolated networks, broadcasts will work in place of multicast. To - that end, SAs SHOULD and DAs MUST listen for broadcast Service - Location messages at port 427. This allows UAs which do not support - multicast the use of Service Location on isolated networks. - - Setting multicast TTL to less than 255 (the default) limits the range - of SLP discovery in a network, and localizes service information in - the network. - -6.2. Use of TCP - - A SrvReg or SrvDeReg may be too large to fit into a datagram. To - send such large SLP messages, a TCP (unicast) connection MUST be - established. - - To avoid the need to implement TCP, one MUST insure that: - - - UAs never issue requests larger than the Path MTU. SAs can omit - TCP support only if they never have to receive unicast requests - longer than the path MTU. - - - UAs can accept replies with the 'OVERFLOW' flag set, and make use - of the first result included, or reformulate the request. - - - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in - a single datagram. This means limiting the size of URLs, - the number of attributes and the number of authenticators - transmitted. - - DAs MUST be able to respond to UDP and TCP requests, as well as - multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP - unless the SA will NEVER receive a request or send a reply which will - exceed a datagram in size (e.g., some embedded systems). - - - -Guttman, et al. Standards Track [Page 14] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - A TCP connection MAY be used for a single SLP transaction, or for - multiple transactions. Since there are length fields in the message - headers, SLP Agents can send multiple requests along a connection and - read the return stream for acknowledgments and replies. - - The initiating agent SHOULD close the TCP connection. The DA SHOULD - wait at least CONFIG_CLOSE_CONN seconds before closing an idle - connection. DAs and SAs SHOULD close an idle TCP connection after - CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the - initiating agent neglects to close it. See Section 13 for timing - rules. - -6.3. Retransmission of SLP messages - - Requests which fail to elicit a response are retransmitted. The - initial retransmission occurs after a CONFIG_RETRY wait period. - Retransmissions MUST be made with exponentially increasing wait - intervals (doubling the wait each time). This applies to unicast as - well as multicast SLP requests. - - Unicast requests to a DA or SA should be retransmitted until either a - response (which might be an error) has been obtained, or for - CONFIG_RETRY_MAX seconds. - - Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds - until a result has been obtained. UAs need only wait till they - obtain the first reply which matches their request. That is, - retransmission is not required if the requesting agent is prepared to - use the 'first reply' instead of 'as many replies as possible within - a bounded time interval.' - - When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, - they contain a <PRList> of previous responders. Initially the - <PRList> is empty. When these requests are unicast, the <PRList> is - always empty. - - Any DA or SA which sees its address in the <PRList> MUST NOT respond - to the request. - - The message SHOULD be retransmitted until the <PRList> causes no - further responses to be elicited or the previous responder list and - the request will not fit into a single datagram or until - CONFIG_MC_MAX seconds elapse. - - UAs which retransmit a request use the same XID. This allows a DA or - SA to cache its reply to the original request and then send it again, - should a duplicate request arrive. This cached information should - only be held very briefly. XIDs SHOULD be randomly chosen to avoid - - - -Guttman, et al. Standards Track [Page 15] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - duplicate XIDs in requests if UAs restart frequently. - -6.4. Strings in SLP messages - - The escape character is a backslash (UTF-8 0x5c) followed by the two - hexadecimal digits of the escaped character. Only reserved - characters are escaped. For example, a comma (UTF-8 0x29) is escaped - as `\29', and a backslash `\' is escaped as `\5c'. String lists used - in SLP define the comma to be the delimiter between list elements, so - commas in data strings must be escaped in this manner. Backslashes - are the escape character so they also must always be escaped when - included in a string literally. - - String comparison for order and equality in SLP MUST be case - insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds - to ASCII character encoding). Case insensitivity SHOULD be supported - throughout the entire UTF-8 encoded Unicode [6] character set. - - The case insensitivity rule applies to all string matching in SLPv2, - including Scope strings, SLP SPI strings, service types, attribute - tags and values in query handling, language tags, previous responder - lists. Comparisons of URL strings, however, is case sensitive. - - White space (SPACE, CR, LF, TAB) internal to a string value is folded - to a single SPACE character for the sake of string comparisons. - White space preceding or following a string value is ignored for the - purposes of string comparison. For example, " Some String " - matches "SOME STRING". - - String comparisons (using comparison operators such as `<=' or `>=') - are done using lexical ordering in UTF-8 encoded characters, not - using any language specific rules. - - The reserved character `*' may precede, follow or be internal to a - string value in order to indicate substring matching. The query - including this character matches any character sequence which - conforms to the letters which are not wildcarded. - -6.4.1. Scope Lists in SLP - - Scope Lists in SLPv2 have the following grammar: - - scope-list = scope-val / scope-val `,' scope-list - scope-val = 1*safe - safe = ; Any character except reserved. - reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL - / `;' / `*' / `+' - escape-val = `\' HEXDIG HEXDIG - - - -Guttman, et al. Standards Track [Page 16] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Scopes which include any reserved characters must replace the escaped - character with the escaped-val format. - -7. Errors - - If the Error Code in a SLP reply message is nonzero, the rest of the - message MAY be truncated. No data is necessarily transmitted or - should be expected after the header and the error code, except - possibly for some optional extensions to clarify the error, for - example as in section D.1. - - Errors are only returned for unicast requests. Multicast requests - are silently discarded if they result in an error. - - LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in - the scope in the AttrRqst or SrvRqst, but not in the requested - language. - PARSE_ERROR = 2: The message fails to obey SLP syntax. - INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero - lifetime or an omitted Language Tag. - SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in - its <scope-list> supported by the SA or DA. - AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an - unsupported SLP SPI. - AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR - authentication in the SrvReg and did not receive it. - AUTHENTICATION_FAILED = 7: The DA detected an authentication error in - an Authentication block. - VER_NOT_SUPPORTED = 9: Unsupported version number in message header. - INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. - DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. - OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option - from the mandatory range (see section 9.1). - INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for - an unregistered service or with inconsistent Service Types. - MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst - and does not support it. - REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a - DA more frequently than the DA's min-refresh-interval. - -8. Required SLP Messages - - All length fields in SLP messages are in network byte order. Where ' - tuples' are defined, these are sequences of bytes, in the precise - order listed, in network byte order. - - SLP messages all begin with the following header: - - - - -Guttman, et al. Standards Track [Page 17] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Version | Function-ID | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length, contd.|O|F|R| reserved |Next Ext Offset| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Extension Offset, contd.| XID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Language Tag Length | Language Tag \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Message Type Abbreviation Function-ID - - Service Request SrvRqst 1 - Service Reply SrvRply 2 - Service Registration SrvReg 3 - Service Deregister SrvDeReg 4 - Service Acknowledge SrvAck 5 - Attribute Request AttrRqst 6 - Attribute Reply AttrRply 7 - DA Advertisement DAAdvert 8 - Service Type Request SrvTypeRqst 9 - Service Type Reply SrvTypeRply 10 - SA Advertisement SAAdvert 11 - - SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST - also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support - for other messages are OPTIONAL. - - - Length is the length of the entire SLP message, header included. - - The flags are: OVERFLOW (0x80) is set when a message's length - exceeds what can fit into a datagram. FRESH (0x40) is set on - every new SrvReg. REQUEST MCAST (0x20) is set when multicasting - or broadcasting requests. Reserved bits MUST be 0. - - Next Extension Offset is set to 0 unless extensions are used. - The first extension begins at 'offset' bytes, from the message's - beginning. It is placed after the SLP message data. See - Section 9.1 for how to interpret unrecognized SLP Extensions. - - XID is set to a unique value for each unique request. If the - request is retransmitted, the same XID is used. Replies set - the XID to the same value as the xid in the request. Only - unsolicited DAAdverts are sent with an XID of 0. - - Lang Tag Length is the length in bytes of the Language Tag field. - - Language Tag conforms to [7]. The Language Tag in a reply MUST - be the same as the Language Tag in the request. This field must - be encoded 1*8ALPHA *("-" 1*8ALPHA). - - - - -Guttman, et al. Standards Track [Page 18] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - If an option is specified, and not included in the message, the - receiver MUST respond with a PARSE_ERROR. - -8.1. Service Request - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvRqst = 1) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <PRList> | <PRList> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <service-type> | <service-type> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <scope-list> | <scope-list> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of predicate string | Service Request <predicate> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <SLP SPI> string | <SLP SPI> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - In order for a Service to match a SrvRqst, it must belong to at least - one requested scope, support the requested service type, and match - the predicate. If the predicate is present, the language of the - request (ignoring the dialect part of the Language Tag) must match - the advertised service. - - <PRList> is the Previous Responder List. This <string-list> contains - dotted decimal notation IP (v4) addresses, and is iteratively - multicast to obtain all possible results (see Section 6.3). UAs - SHOULD implement this discovery algorithm. SAs MUST use this to - discover all available DAs in their scope, if they are not already - configured with DA addresses by some other means. - - A SA silently drops all requests which include the SA's address in - the <PRList>. An SA which has multiple network interfaces MUST check - if any of the entries in the <PRList> equal any of its interfaces. - An entry in the PRList which does not conform to an IPv4 dotted - decimal address is ignored: The rest of the <PRList> is processed - normally and an error is not returned. - - Once a <PRList> plus the request exceeds the path MTU, multicast - convergence stops. This algorithm is not intended to find all - instances; it finds 'enough' to provide useful results. - - The <scope-list> is a <string-list> of configured scope names. SAs - and DAs which have been configured with any of the scopes in this - list will respond. DAs and SAs MUST reply to unicast requests with a - - - -Guttman, et al. Standards Track [Page 19] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to - include a scope they support (see Section 11). The only exceptions - to this are described in Section 11.2. - - The <service-type> string is discussed in Section 4. Normally, a - SrvRqst elicits a SrvRply. There are two exceptions: If the - <service-type> is set to "service:directory-agent", DAs respond to - the SrvRqst with a DAAdvert (see Section 8.5.) If set to - "service:service-agent", SAs respond with a SAAdvert (see Section - 8.6.) If this field is omitted, a PARSE_ERROR is returned - as this - field is REQUIRED. - - The <predicate> is a LDAPv3 search filter [14]. This field is - OPTIONAL. Services may be discovered simply by type and scope. - Otherwise, services are discovered which satisfy the <predicate>. If - present, it is compared to each registered service. If the attribute - in the filter has been registered with multiple values, the filter is - compared to each value and the results are ORed together, i.e., - "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches - (y=0,1) since Y can be nonzero. Note the matching is case - insensitive. Keywords (i.e., attributes without values) are matched - with a "presence" filter, as in "(keyword=*)". - - An incoming request term MUST have the same type as the attribute in - a registration in order to match. Thus, "(x=33)" will not match ' - x=true', etc. while "(y=foo)" will match 'y=FOO'. - "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be - satisfied, because of the `|' (boolean disjunction). - - Wildcard matching MUST be done with the '=' filter. In any other - case, a PARSE_ERROR is returned. Request terms which include - wildcards are interpreted to be Strings. That is, (x=34*) would - match 'x=34foo', but not 'x=3432' since the first value is a String - while the second value is an Integer; Strings don't match Integers. - - Examples of Predicates follow. <t> indicates the service type of the - SrvRqst, <s> gives the <scope-list> and <p> is the predicate string. - - <t>=service:http <s>=DEFAULT <p>= (empty string) - This is a minimal request string. It matches all http - services advertised with the default scope. - - <t>=service:pop3 <s>=SALES,DEFAULT <p>=(user=wump) - This is a request for all pop3 services available in - the SALES or DEFAULT scope which serve mail to the user - `wump'. - - - - - -Guttman, et al. Standards Track [Page 20] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - <t>=service:backup <s>=BLDG 32 <p>=(&(q<=3)(speed>=1000)) - This returns the backup service which has a queue length - less than 3 and a speed greater than 1000. It will - return this only for services registered with the BLDG 32 - scope. - - <t>=service:directory-agent <s>=DEFAULT <p>= - This returns DAAdverts for all DAs in the DEFAULT scope. - - DAs are discovered by sending a SrvRqst with the service type set to - "service:directory-agent". If a predicate is included in the - SrvRqst, the DA SHOULD respond only if the predicate can be satisfied - with the DA's attributes. The <scope-list> MUST contain all scopes - configured for the UA or SA which is discovering DAs. - - The <SLP SPI> string indicates a SLP SPI that the requester has been - configured with. If this string is omitted, the responder does not - include any Authentication Blocks in its reply. If it is included, - the responder MUST return a reply which has an associated - authentication block with the SLP SPI in the SrvRqst. If no replies - may be returned because the SLP SPI is not supported, the responder - returns an AUTHENTICATION_UNKNOWN error. - -8.2. Service Reply - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvRply = 2) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Error Code | URL Entry count | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | <URL Entry 1> ... <URL Entry N> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The service reply contains zero or more URL entries (see Section - 4.3). A service reply with zero URL entries MUST be returned in - response to a unicast Service Request, if no matching URLs are - present. A service reply with zero URL entries MUST NOT be sent in - response to a multicast or broadcast service request (instead, if - there was no match found or an error processing the request, the - service reply should not be generated at all). - - If the reply overflows, the UA MAY simply use the first URL Entry in - the list. A URL obtained by SLP may not be cached longer than - Lifetime seconds, unless there is a URL Authenticator block present. - - - - - -Guttman, et al. Standards Track [Page 21] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - In that case, the cache lifetime is indicated by the Timestamp in the - URL Authenticator (see Section 9.2). - - An authentication block is returned in the URL Entries, including the - SLP SPI in the SrvRqst. If no SLP SPI was included in the request, - no Authentication Blocks are returned in the reply. URL - Authentication Blocks are defined in Section 9.2.1. - - If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless - it fits entirely without truncation. - -8.3. Service Registration - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvReg = 3) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | <URL-Entry> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of service type string | <service-type> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <scope-list> | <scope-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of attr-list string | <attr-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |# of AttrAuths |(if present) Attribute Authentication Blocks...\ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The <entry> is a URL Entry (see section 4.3). The Lifetime defines - how long a DA can cache the registration. SAs SHOULD reregister - before this lifetime expires (but SHOULD NOT more often than once per - second). The Lifetime MAY be set to any value between 0 and 0xffff - (maximum, around 18 hours). Long-lived registrations remain stale - longer if the service fails and the SA does not deregister the - service. - - The <service-type> defines the service type of the URL to be - registered, regardless of the scheme of the URL. The <scope-list> - MUST contain the names of all scopes configured for the SA, which the - DA it is registering with supports. The default value for the - <scope-list> is "DEFAULT" (see Section 11). - - The SA MUST register consistently with all DAs. If a SA is - configured with scopes X and Y and there are three DAs, whose scopes - are "X", "Y" and "X,Y" respectively, the SA will register the with - all three DAs in their respective scopes. All future updates and - deregistrations of the service must be sent to the same set of DAs in - - - -Guttman, et al. Standards Track [Page 22] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - the same scopes the service was initially registered in. - - The <attr-list>, if present, specifies the attributes and values to - be associated with the URL by the DA (see Section 5). - - A SA configured with the ability to sign service registrations MUST - sign each of the URLs and Attribute Lists using each of the keys it - is configured to use, and the DA it is registering with accepts. - (The SA MUST acquire DAAdverts for all DAs it will register with to - obtain the DA's SLP SPI list and attributes, as described in Section - 8.5). The SA supplies a SLP SPI in each authentication block - indicating the SLP SPI configuration required to verify the digital - signature. The format of the digital signatures used is defined in - section 9.2.1. - - Subsequent registrations of previously registered services MUST - contain the same list of SLP SPIs as previous ones or else DAs will - reject them, replying with an AUTHENTICATION_ABSENT error. - - A registration with the FRESH flag set will replace *entirely* any - previous registration for the same URL in the same language. If the - FRESH flag is not set, the registration is an "incremental" - registration (see Section 9.3). - -8.4. Service Acknowledgment - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvAck = 5) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Error Code | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - A DA returns a SrvAck to an SA after a SrvReg. It carries only a two - byte Error Code (see Section 7). - - - - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 23] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -8.5. Directory Agent Advertisement - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = DAAdvert = 8) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Error Code | DA Stateless Boot Timestamp | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |DA Stateless Boot Time,, contd.| Length of URL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ URL \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <scope-list> | <scope-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <attr-list> | <attr-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <SLP SPI List> | <SLP SPI List> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | # Auth Blocks | Authentication block (if any) \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The Error Code is set to 0 when the DAAdvert is multicast. If the - DAAdvert is being returned due to a unicast SrvRqst (ie. a request - without the REQUEST MCAST flag set) the DA returns the same errors a - SrvRply would. - - The <scope-list> of the SrvRqst must either be omitted or include a - scope which the DA supports. The DA Stateless Boot Timestamp - indicates the state of the DA (see section 12.1). - - The DA MAY include a list of its attributes in the DAAdvert. This - list SHOULD be kept short, as the DAAdvert must fit into a datagram - in order to be multicast. - - A potential scaling problem occurs in SLPv2 if SAs choose too low a - Lifetime. In this case, an onerous amount of reregistration occurs - as more services are deployed. SLPv2 allows DAs to control SAs - frequency of registration. A DA MAY reissue a DAAdvert with a new - set of attributes at any time, to change the reregistration behavior - of SAs. These apply only to subsequent registrations; existing - service registrations with the DA retain their registered lifetimes. - - If the DAAdvert includes the attribute "min-refresh-interval" it MUST - be set to a single Integer value indicating a number of seconds. If - this attribute is present SAs MUST NOT refresh any particular service - advertisement more frequently than this value. If SrvReg with the - FRESH FLAG not set or SrvDereg with a non-empty tag list updating a - - - -Guttman, et al. Standards Track [Page 24] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - particular service are received more often than the value for the - DA's advertised "min-refresh-interval" attribute the DA SHOULD reject - the message and return a REFRESH_REJECTED error in the SrvAck. - - The URL is "service:directory-agent://"<addr> of the DA, where <addr> - is the dotted decimal numeric address of the DA. The <scope-list> of - the DA MUST NOT be NULL. - - The SLP SPI List is the list of SPIs that the DA is capable of - verifying. SAs MUST NOT register services with authentication blocks - for those SLP SPIs which are not on the list. DAs will reject - service registrations which they cannot verify, returning an - AUTHENTICATION_UNKNOWN error. - - The format of DAAdvert signatures is defined in Section 9.2.1. - - The SLP SPI which is used to verify the DAAdvert is included in the - Authentication Block. When DAAdverts are multicast, they may have to - transmit multiple DAAdvert Authentication Blocks. If the DA is - configured to be able to generate signatures for more than one SPI, - the DA MUST include one Authentication Block for each SPI. If all - these Authentication Blocks do not fit in a single datagram (to - multicast or broadcast) the DA MUST send separate DAAdverts so that - Authentication Blocks for all the SPIs the DA is capable of - generating are sent. - - If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert - contains only the authentication block with the SLP SPI in the - SrvRqst, if the DA is configured to be able to produce digital - signatures using that SLP SPI. If the SrvRqst is unicast to the DA - (the REQUEST MCAST flag in the header is not set) and an unsupported - SLP SPI is included, the DA replies with a DAAdvert with the Error - Code set to an AUTHENTICATION_UNKNOWN error. - - UAs SHOULD be configured with SLP SPIs that will allow them to verify - DA Advertisements. If the UA is configured with SLP SPIs and - receives a DAAdvert which fails to be verified using one of them, the - UA MUST discard it. - -8.6. Service Agent Advertisement - - User Agents MUST NOT solicit SA Advertisements if they have been - configured to use a particular DA, if they have been configured with - a <scope-list> or if DAs have been discovered. UAs solicit SA - Advertisements only when they are explicitly configured to use User - Selectable scopes (see Section 11.2) in order to discover the scopes - that SAs support. This allows UAs without scope configuration to - make use of either DAs or SAs without any functional difference - - - -Guttman, et al. Standards Track [Page 25] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - except performance. - - A SA MAY be configured with attributes, and SHOULD support the - attribute 'service-type' whose value is all the service types of - services represented by the SA. SAs MUST NOT respond if the SrvRqst - predicate is not satisfied. For example, only SAs offering 'nfs' - services SHOULD respond with a SAAdvert to a SrvRqst for service type - "service:service-agent" which includes a predicate "(service- - type=nfs)". - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SAAdvert = 11) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of URL | URL \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <scope-list> | <scope-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <attr-list> | <attr-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | # auth blocks | authentication block (if any) \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The SA responds only to multicast SA discovery requests which either - include no <scope-list> or a scope which they are configured to use. - - The SAAdvert MAY include a list of attributes the SA supports. This - attribute list SHOULD be kept short so that the SAAdvert will not - exceed the path MTU in size. - - The URL is "service:service-agent://"<addr> of the SA, where <addr> - is the dotted decimal numeric address of the SA. The <scope-list> of - the SA MUST NOT be null. - - The SAAdvert contains one SAAdvert Authentication block for each SLP - SPI the SA can produce Authentication Blocks for. If the UA can - verify the Authentication Block of the SAAdvert, and the SAAdvert - fails to be verified, the UA MUST discard it. - -9. Optional Features - - The features described in this section are not mandatory. Some are - useful for interactive use of SLP (where a user rather than a program - will select services, using a browsing interface for example) and for - scalability of SLP to larger networks. - - - - - -Guttman, et al. Standards Track [Page 26] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -9.1. Service Location Protocol Extensions - - The format of a Service Location Extension is: - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Extension ID | Next Extension Offset | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Offset, contd.| Extension Data \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Extension IDs are assigned in the following way: - - 0x0000-0x3FFF Standardized. Optional to implement. Ignore if - unrecognized. - 0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA - which receives this option in a reply and does not understand - it MUST silently discard the reply. A DA or SA which receives - this option in a request and does not understand it MUST return - an OPTION_NOT_UNDERSTOOD error. - 0x8000-0x8FFF For private use (not standardized). Optional to - implement. Ignore if unrecognized. - 0x9000-0xFFFF Reserved. - - The three byte offset to next extension indicates the position of the - next extension as offset from the beginning of the SLP message. - - The offset value is 0 if there are no extensions following the - current extension. - - If the offset is 0, the length of the current Extension Data is - determined by subtracting total length of the SLP message as given in - the SLP message header minus the offset of the current extension. - - Extensions defined in this document are in Section D. See section 15 - for procedures that are required when specifying new SLP extensions. - - - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 27] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -9.2. Authentication Blocks - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Block Structure Descriptor | Authentication Block Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Timestamp | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SLP SPI String Length | SLP SPI String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Structured Authentication Block ... \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Authentication blocks are returned with certain SLP messages to - verify that the contents have not been modified, and have been - transmitted by an authorized agent. The authentication data - (contained in the Structured Authentication Block) is typically case - sensitive. Even though SLP registration data (e.g., attribute - values) are typically are not case sensitive, the case of the - registration data has to be preserved by the registering DA so that - UAs will be able to verify the data used for calculating digital - signature data. - - The Block Structure Descriptor (BSD) identifies the format of the - Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained - by IANA. BSDs 0x8000-0x8FFF are for private use. - - The Authentication Block Length is the length of the entire block, - starting with the BSD. - - The Timestamp is the time that the authenticator expires (to prevent - replay attacks.) The Timestamp is a 32-bit unsigned fixed-point - number of seconds relative to 0h on 1 January 1970. SAs use this - value to indicate when the validity of the digital signature expires. - This Timestamp will wrap back to 0 in the year 2106. Once the value - of the Timestamp wraps, the time at which the Timestamp is relative - to resets. For example, after 06h28 and 16 seconds 5 February 2106, - all Timestamp values will be relative to that epoch date. - - The SLP Security Parameters Index (SPI) string identifies the key - length, algorithm parameters and keying material to be used by agents - to verify the signature data in the Structured Authentication Block. - The SLP SPI string has the same grammar as the <scope-val> defined in - Section 6.4.1. - - Reserved characters in SLP SPI strings must be escaped using the same - convention as used throughout SLPv2. - - - -Guttman, et al. Standards Track [Page 28] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - SLP SPIs deployed in a site MUST be unique. An SLP SPI used for - BSD=0x0002 must not be the same as used for some other BSD. - - All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST - register services with DSA authentication blocks, and they MAY - register them with other authentication blocks using other - algorithms. SAs MUST use DSA authentication blocks in SrvDeReg - messages and DAs MUST use DSA authentication blocks in unsolicited - DAAdverts. - -9.2.1. SLP Message Authentication Rules - - The sections below define how to calculate the value to apply to the - algorithm identified by the BSD value. The components listed are - used as if they were a contiguous single byte aligned buffer in the - order given. - - URL - 16-bit Length of SLP SPI String, SLP SPI String. - 16-bit Length of URL, URL, - 32-bit Timestamp. - - Attribute List - 16-bit Length of SLP SPI String, SLP SPI String, - 16-bit length of <attr-list>, <attr-list>, - 32-bit Timestamp. - - DAAdvert - 16-bit Length of SLP SPI String, SLP SPI String, - 32-bit DA Stateless Boot Timestamp, - 16-bit Length of URL, URL, - 16-bit Length of <attr-list>, <attr-list>, - 16-bit Length of DA's <scope-list>, DA's <scope-list>, - 16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>, - 32-bit Timestamp. - - The first SLP SPI is the SLP SPI in the Authentication - Block. This SLP SPI indicates the keying material and other - parameters to use to verify the DAAdvert. The SLP SPI List is - the list of SLP SPIs the DA itself supports, and is able to - verify. - - SAAdvert - 16-bit Length of SLP SPI String, SLP SPI String, - 16-bit Length of URL, URL, - 16-bit Length of <attr-list>, <attr-list>, - 16-bit Length of <scope-list>, <scope-list>, - 32-bit Timestamp. - - - -Guttman, et al. Standards Track [Page 29] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -9.2.2 DSA with SHA-1 in Authentication Blocks - - BSD=0x0002 is defined to be DSA with SHA-1. The signature - calculation is defined by [20]. The signature format conforms to - that in the X.509 v3 certificate: - - 1. The signature algorithm identifier (an OID) - 2. The signature value (an octet string) - 3. The certificate path. - - All data is represented in ASN.1 encoding: - - id-dsa-with-sha1 ID ::= { - iso(1) member-body(2) us(840) x9-57 (10040) - x9cm(4) 3 } - - i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately - by: - - Dss-Sig-Value ::= SEQUENCE { - r INTEGER, - s INTEGER } - - i.e., the binary ASN.1 encoding of r and s computed using DSA and - SHA-1. This is followed by a certificate path, as defined by X.509 - [10], [2], [3], [4], [5]. - - Authentication Blocks for BSD=0x0002 have the following format. In - the future, BSDs may be assigned which have different formats. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ASN.1 encoded DSA signature \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -9.3. Incremental Service Registration - - Incremental registrations update attribute values for a previously - registered service. Incremental service registrations are useful - when only a single attribute has changed, for instance. In an - incremental registration, the FRESH flag in the SrvReg header is NOT - set. - - The new registration's attributes replace the previous - registration's, but do not affect attributes which were included - previously and are not present in the update. - - - - -Guttman, et al. Standards Track [Page 30] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - For example, suppose service:x://a.org has been registered with - attributes A=1, B=2, C=3. If an incremental registration comes for - service:x://a.org with attributes C=30, D=40, then the attributes for - the service after the update are A=1, B=2, C=30, D=40. - - Incremental registrations MUST NOT be performed for services - registered with Authentication Blocks. These must be registered with - ALL attributes, with the FRESH flag in the SrvReg header set. DAs - which receive such registration messages return an - AUTHENTICATION_FAILED error. - - If the FRESH flag is not set and the DA does not have a prior - registration for the service, the incremental registration fails with - error code INVALID_UPDATE. - - The SA MUST use the same <scope-list> in an update message as was - used in the prior registration. If this is not done, the DA returns - a SCOPE_NOT_SUPPORTED error. In order to change the scope of a - service advertisement it MUST be deregistered first and reregistered - with a new <scope-list>. - - The SA MUST use the same <service-type> in an update message as was - used in a prior registration of the same URL. If this is not done, - the DA returns an INVALID_UPDATE error. - -9.4. Tag Lists - - Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a - <tag-list> item is: - - tag-filter = simple-tag / substring - simple-tag = 1*filt-char - substring = [initial] any [final] - initial = 1*filt-char - any = `*' *(filt-char `*') - final = 1*filt-char - filt-char = Any character excluding <reserved> and <bad-tag> (see - grammar in Section 5). - - Wild card characters in a <tag-list> item match arbitrary sequences - of characters. For instance "*bob*" matches "some bob I know", - "bigbob", "bobby" and "bob". - - - - - - - - - -Guttman, et al. Standards Track [Page 31] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -10. Optional SLP Messages - - The additional requests provide features for user interaction and for - efficient updating of service advertisements with dynamic attributes. - -10.1. Service Type Request - - The Service Type Request (SrvTypeRqst) allows a UA to discover all - types of service on a network. This is useful for general purpose - service browsers. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvTypeRqst = 9) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of PRList | <PRList> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of Naming Authority | <Naming Authority String> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <scope-list> | <scope-list> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The <PRList> list and <scope-list> are interpreted as in Section 8.1. - - The Naming Authority string, if present in the request, will limit - the reply to Service Type strings with the specified Naming - Authority. If the Naming Authority string is absent, the IANA - registered service types will be returned. If the length of the - Naming Authority is set to 0xFFFF, the Naming Authority string is - omitted and ALL Service Types are returned, regardless of Naming - Authority. - -10.2. Service Type Reply - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvTypeRply = 10) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Error Code | length of <srvType-list> | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | <srvtype--list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The service-type Strings (as described in Section 4.1) are provided - in <srvtype-list>, which is a <string-list>. - - - - -Guttman, et al. Standards Track [Page 32] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - If a service type has a Naming Authority other than IANA it MUST be - returned following the service type string and a `.' character. - Service types with the IANA Naming Authority do not include a Naming - Authority string. - -10.3. Attribute Request - - The Attribute Request (AttrRqst) allows a UA to discover attributes - of a given service (by supplying its URL) or for an entire service - type. The latter feature allows the UA to construct a query for an - available service by selecting desired features. The UA may request - that all attributes are returned, or only a subset of them. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = AttrRqst = 6) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of PRList | <PRList> String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of URL | URL \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <scope-list> | <scope-list> string \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <tag-list> string | <tag-list> string \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | length of <SLP SPI> string | <SLP SPI> string \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in - Section 8.1. - - The URL field can take two forms. It can simply be a Service Type - (see Section 4.1), such as "http" or "service:tftp". In this case, - all attributes and the full range of values for each attribute of all - services of the given Service Type is returned. - - The URL field may alternatively be a full URL, such as - "service:printer:lpr://igore.wco.ftp.com:515/draft" or - "nfs://max.net/znoo". In this, only the registered attributes for - the specified URL are returned. - - The <tag-list> field is a <string-list> of attribute tags, as defined - in Section 9.4 which indicates the attributes to return in the - AttrRply. If <tag-list> is omitted, all attributes are returned. - <tag-list> MUST be omitted and a full URL MUST be included when - attributes when a SLP SPI List string is included, otherwise the DA - will reply with an AUTHENTICATION_FAILED error. - - - -Guttman, et al. Standards Track [Page 33] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -10.4. Attribute Reply - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = AttrRply = 7) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Error Code | length of <attr-list> | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | <attr-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |# of AttrAuths | Attribute Authentication Block (if present) \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The format of the <attr-list> and the Authentication Block is as - specified for SrvReg (see Section 9.2.1). - - Attribute replies SHOULD be returned with the original case of the - string registration intact, as they are likely to be human readable. - In the case where the AttrRqst was by service type, all attributes - defined for the service type, and all their values are returned. - - Although white space is folded for string matching, attribute tags - and values MUST be returned with their original white space - preserved. - - Only one copy of each attribute tag or String value should be - returned, arbitrarily choosing one version (with respect to upper and - lower case and white space internal to the strings): Duplicate - attributes and values SHOULD be removed. An arbitrary version of the - string value and tag name is chosen for the merge. For example: - "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)". - -10.5. Attribute Request/Reply Examples - - Suppose that printer services have been registered as follows: - - Registered Service: - URL = service:printer:lpr://igore.wco.ftp.com/draft - scope-list = Development - Lang. Tag = en - Attributes = (Name=Igore),(Description=For developers only), - (Protocol=LPR),(location-description=12th floor), - (Operator=James Dornan \3cdornan@monster\3e), - (media-size=na-letter),(resolution=res-600),x-OK - - URL = service:printer:lpr://igore.wco.ftp.com/draft - scope-list = Development - - - -Guttman, et al. Standards Track [Page 34] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Lang. Tag = de - Attributes = (Name=Igore),(Description=Nur fuer Entwickler), - (Protocol=LPR),(location-description=13te Etage), - (Operator=James Dornan \3cdornan@monster\3e), - (media-size=na-letter),(resolution=res-600),x-OK - - URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn - scope-list = Development - Lang. Tag = en - Attributes = (Name=Not),(Description=Experimental IPP printer), - (Protocol=http),(location-description=QA bench), - (media-size=na-letter),(resolution=other),x-BUSY - - Notice the first printer, "Igore" is registered in both English and - German. The `<' and `>' characters in the Operator attribute value - which are part of the Email address had to be escaped, as they are - reserved characters for values. - - Attribute tags are not translated, though attribute values may be, - see [13]. - - The attribute Request: - - URL = service:printer:lpr://igore.wco.ftp.com/draft - scope-list = Development - Lang. Tag = de - tag-list = resolution,loc* - - receives the Attribute Reply: - - (location-description=13te Etage),(resolution=res-600) - - The attribute Request: - - URL = service:printer - scope-list = Development - Lang. Tag = en - tag-list = x-*,resolution,protocol - - receives an Attribute Reply containing: - - (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY - - The first request is by service instance and returns the requested - values, in German. The second request is by abstract service type - (see Section 4) and returns values from both "Igore" and "Not". - - - - - -Guttman, et al. Standards Track [Page 35] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - An attribute Authentication Block is returned if an authentication - block with the SLP SPI in the AttrRqst can be returned. Note that - the <attr-list> returned from a DA with an Authentication Block MUST - be identical to the <attr-list> registered by a SA, in order for the - authentication verification calculations to be possible. - - A SA or DA only returns an Attribute Authentication Block if the - AttrRqst included a full URL in the request and no tag list. - - If an SLP SPI is specified in a unicast request (the REQUEST MCAST - flag in the header is not set) and the SA or DA cannot return an - Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN - error is returned. The # of Attr Auths field is set to 0 if there no - Authentication Block is included, or 1 if an Authentication Block - follows. - -10.6. Service Deregistration - - A DA deletes a service registration when its Lifetime expires. - Services SHOULD be deregistered when they are no longer available, - rather than leaving the registrations to time out. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Service Location header (function = SrvDeReg = 4) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <scope-list> | <scope-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | URL Entry \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length of <tag-list> | <tag-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The <scope-list> is a <string-list> (see section 2.1). - - The SA MUST retry if there is no response from the DA, see Section - 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA - receives an acknowledgment indicating success, the service and/or - attributes are no longer advertised by the DA. The DA deregisters the - service or service attributes from every scope specified in the - SrvDeReg which it was previously registered in. - - The SA MUST deregister all services with the same scope list used to - register the service with a DA. If this is not done in the SrvDeReg - message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime - field in the URL Entry is ignored for the purposes of the SrvDeReg. - - - - -Guttman, et al. Standards Track [Page 36] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - The <tag-list> is a <string-list> of attribute tags to deregister as - defined in Section 9.4. If no <tag-list> is present, the SrvDeReg - deregisters the service in all languages it has been registered in. - If the <tag-list> is present, the SrvDeReg deregisters the attributes - whose tags are listed in the tag spec. Services registered with - Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg - message: A DA will respond with an AUTHENTICATION_FAILED error in - this case. - - If the service to be deregistered was registered with an - authentication block or blocks, a URL authentication block for each - of the SLP SPIs registered must be included in the SrvDeReg. - Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the - message fails to be verified by the DA, an AUTHENTICATION_FAILED - error is returned by the DA. - -11. Scopes - - Scopes are sets of services. The primary use of Scopes is to provide - the ability to create administrative groupings of services. A set of - services may be assigned a scope by network administrators. A client - seeking services is configured to use one or more scopes. The user - will only discover those services which have been configured for him - or her to use. By configuring UAs and SAs with scopes, - administrators may provision services. Scopes strings are case - insensitive. The default SCOPE string is "DEFAULT". - - Scopes are the primary means an administrator has to scale SLP - deployments to larger networks. When DAs with NON-DEFAULT scopes are - present on the network, further gains can be had by configuring UAs - and SAs to have a predefined non-default scope. These agents can - then perform DA discovery and make requests using their scope. This - will limit the number of replies. - -11.1. Scope Rules - - SLP messages which fail to contain a scope that the receiving Agent - is configured to use are dropped (if the request was multicast) or a - SCOPE_NOT_SUPPORTED error is returned (if the request was unicast). - Every SrvRqst (except for DA and SA discovery requests), SrvReg, - AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a - <scope-list>. - - A UA MUST unicast its SLP messages to a DA which supports the desired - scope, in preference to multicasting a request to SAs. A UA MAY - multicast the request if no DA is available in the scope it is - configured to use. - - - - -Guttman, et al. Standards Track [Page 37] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -11.2. Administrative and User Selectable Scopes - - All requests and services are scoped. The two exceptions are - SrvRqsts for "service:directory-agent" and "service:service-agent". - These MAY have a zero-length <scope-list> when used to enable the - user to make scope selections. In this case UAs obtain their scope - list from DAAdverts (or if DAs are not available, from SAAdverts.) - - Otherwise, if SAs and UAs are to use any scope other than the default - (i.e., "DEFAULT"), the UAs and SAs are configured with lists of - scopes to use by system administrators, perhaps automatically by way - of DHCP option 78 or 79 [21]. Such administrative scoping allows - services to be provisioned, so that users will only see services they - are intended to see. - - User configurable scopes allow a user to discover any service, but - require them to do their own selection of scope. This is similar to - the way AppleTalk [12] and SMB [19] networking allow user selection - of AppleTalk Zone or workgroups. - - Note that the two configuration choices are not compatible. One - model allows administrators control over service provision. The - other delegates this to users (who may not be prepared to do any - configuration of their system). - -12. Directory Agents - - DAs cache service location and attribute information. They exist to - enhance the performance and scalability of SLP. Multiple DAs provide - further scalability and robustness of operation, since they can each - store service information for the same SAs, in case one of the DAs - fails. - - A DA provides a centralized store for service information. This is - useful in a network with several subnets or with many SLP Agents. - The DA address can be dynamically configured with UAs and SAs using - DHCP, or by using static configuration. - - SAs configured to use DAs with DHCP or static configuration MUST - unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst - omits the scope list and sets the service type of the request to - "service:directory-agent". The DA will return a DAAdvert with its - attributes, SLP SPI list, and other parameters which are essential - for proper SA to DA communication. - - Passive detection of DAs by SAs enables services to be advertised - consistently among DAs of the same scope. Advertisements expire if - not renewed, leaving only transient stale registrations in DAs, even - - - -Guttman, et al. Standards Track [Page 38] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - in the case of a failure of a SA. - - A single DA can support many UAs. UAs send the same requests to DAs - that they would send to SAs and expect the same results. DAs reduce - the load on SAs, making simpler implementations of SAs possible. - - UAs MUST be prepared for the possibility that the service information - they obtain from DAs is stale. - -12.1. Directory Agent Rules - - When DAs are present, each SA MUST register its services with DAs - that support one or more of its scope(s). - - UAs MUST unicast requests directly to a DA (when scoping rules - allow), hence avoiding using the multicast convergence algorithm, to - obtain service information. This decreases network utilization and - increases the speed at which UAs can obtain service information. - - DAs MUST flush service advertisements once their lifetime expires or - their URL Authentication Block "Timestamp" of expiration is past. - - DAAdverts MUST include DA Stateless Boot Timestamp, in the same - format as the Authentication Block (see Section 9.2). The Timestamp - in the Authentication Block indicates the time at which all previous - registrations were lost (i.e., the last stateless reboot). The - Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA - is going down. DAs MUST NOT use equal or lesser Boot Timestamps to - previous ones, if they go down and restart without service - registration state. This would mislead SAs to not reregister with - the DA. - - DAs which receive a multicast SrvRqst for the service type - "service:directory-agent" MUST silently discard it if the <scope- - list> is (a) not omitted and (b) does not include a scope they are - configured to use. Otherwise the DA MUST respond with a DAAdvert. - - DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are - OPTIONAL only for SAs, not DAs.) - -12.2. Directory Agent Discovery - - UAs can discover DAs using static configuration, DHCP options 78 and - 79, or by multicasting (or broadcasting) Service Requests using the - convergence algorithm in Section 6.3. - - - - - - -Guttman, et al. Standards Track [Page 39] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - See Section 6 regarding unsolicited DAAdverts. Section 12.2.2 - describes how SAs may reduce the number of times they must reregister - with DAs in response to unsolicited DAAdverts. - - DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An - unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, - passively, as described in Section 8.5. UAs MAY do this. If they do - not listen for unsolicited DAAdverts, however, they will not discover - DAs as they become available. UAs SHOULD, in this case, do periodic - active DA discovery, see Section 6. - - A URL with the scheme "service:directory-agent" indicates the DA's - location as defined in Section 8.5. For example: - "service:directory-agent://foobawooba.org". - - The following sections suggest timing algorithms which enhance the - scalability of SLP. - -12.2.1. Active DA Discovery - - After a UA or SA restarts, its initial DA discovery request SHOULD be - delayed for some random time uniformly distributed from 0 to - CONFIG_START_WAIT seconds. - - The UA or SA sends the DA Discovery request using a SrvRqst, as - described in Section 8.1. DA Discovery requests MUST include a - Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT - be sent more than once per CONFIG_DA_FIND seconds. - - After discovering a new DA, a SA MUST wait a random time between 0 - and CONFIG_REG_ACTIVE seconds before registering their services. - -12.2.2. Passive DA Advertising - - A DA MUST multicast (or broadcast) an unsolicited DAAdvert every - CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to - prevent DAAdverts from using more than 1% of the available bandwidth. - - All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine - its DA stateless Boot Timestamp. If it is set to 0, the DA is going - down and no further messages should be sent to it. - - If a SA detects a DA it has never encountered (with a nonzero - timestamp,) the SA must register with it. SAs MUST examine the - DAAdvert's timestamp to determine if the DA has had a stateless - reboot since the SA last registered with it. If so it registers with - the DA. SAs MUST wait a random interval between 0 and - CONFIG_REG_PASSIVE before beginning DA registration. - - - -Guttman, et al. Standards Track [Page 40] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -12.3. Reliable Unicast to DAs and SAs - - If a DA or SA fails to respond to a unicast UDP message in - CONFIG_RETRY seconds, the message should be retried. The wait - interval for each subsequent retransmission MUST exponentially - increase, doubling each time. If a DA or SA fails to respond after - CONFIG_RETRY_MAX seconds, the sender should consider the receiver to - have gone down. The UA should use a different DA. If no such DA - responds, DA discovery should be used to find a new DA. If no DA is - available, multicast requests to SAs are used. - -12.4. DA Scope Configuration - - By default, DAs are configured with the "DEFAULT" scope. - Administrators may add other configured scopes, in order to support - UAs and SAs in non default scopes. The default configuration MUST - NOT be removed from the DA unless: - - - There are other DAs which support the "DEFAULT" scope, or - - - All UAs and SAs have been configured with non-default scopes. - - Non-default scopes can be phased-in as the SLP deployment grows. - Default scopes should be phased out only when the non-default scopes - are universally configured. - - If a DA and SA are coresident on a host (quite possibly implemented - by the same process), configuration of the host is considerably - simplified if the SA supports only scopes also supported by the DA. - That is, the SA SHOULD NOT advertise services in any scopes which are - not supported by the coresident DA. This means that incoming requests - can be answered by a single data store; the SA and DA registrations - do not need to be kept separately. - -12.5. DAs and Authentication Blocks - - DAs are not configured to sign service registrations or attribute - lists. They simply cache services registered by Service Agents. DAs - MUST NOT accept registrations including authentication blocks for SLP - SPIs which it is not configured with, see Section 8.5. - - A DA protects registrations which are made with authentication blocks - using SLP SPIs it is configured to use. If a service S is - registered, a subsequent registration (which will replace the - adertisement) or a deregistration (which will remove it) MUST include - an Authentication Block with the corresponding SLP SPI, see Section - 8.3 and Section 10.6. - - - - -Guttman, et al. Standards Track [Page 41] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Example: - - A DA is configured to be able to verify Authentication Blocks with - SLP SPIs "X,Y", that is X and Y. - - An SA registers a service with an Authentication Block with SPI "Z". - The DA stores the registration, but discards the Authentication - Block. If a UA requests a service with an SLP SPI string "Z", the DA - will respond with an AUTHENTICATION_UNKNOWN error. - - An SA registers a service S with Authentication Blocks including SLP - SPIs "X" and "Y". If a UA requests a service with an SLP SPI string - "X" the DA will be able to return S (if the service type, language, - scope and predicate of the SrvRqst match S) The DA will also return - the Authentication Block with SLP SPI set to "X". If the DA receives - a subsequent SrvDeReg for S (which will remove the advertisement) or - a subsequent SrvReg for S (which will replace it), the message must - include two URL Authentication Blocks, one each for SPIs "X" and "Y". - If either of these were absent, the DA would return an - AUTHENTICATION_ABSENT error. - -13. Protocol Timing Defaults - -Interval name Section Default Value Meaning -------------------- ------- ------------- ------------------------ -CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a - complete multicast query - response (all values.) -CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA - discovery on reboot. -CONFIG_RETRY 12.3 2 seconds Wait interval before - initial retransmission - of multicast or unicast - requests. -CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast - request retransmission. -CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs - passively detect new DAs. -CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait - before repeating Active - DA discovery. -CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services - on passive DA discovery. -CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services - on active DA discovery. -CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle - connections. - - - - -Guttman, et al. Standards Track [Page 42] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -14. Optional Configuration - - Broadcast Only - Any SLP agent SHOULD be configurable to use broadcast - only. See Sections 6.1 and 12.2. - - Predefined DA - A UA or SA SHOULD be configurable to use a predefined DA. - - No DA Discovery - The UA or SA SHOULD be configurable to ONLY use - predefined and DHCP-configured DAs and perform no active - or passive DA discovery. - - Multicast TTL - The default multicast TTL is 255. Agents SHOULD be - configurable to use other values. A lower value will - focus the multicast convergence algorithm on smaller - subnetworks, decreasing the number of responses and - increases the performance of service location. This - may result in UAs obtaining different results for the - identical requests depending on where they are connected - to the network. - - Timing Values - Time values other than the default MAY be configurable. - See Section 13. - - Scopes - A UA MAY be configurable to support User Selectable - scopes by omitting all predefined scopes. See - Section 11.2. A UA or SA MUST be configurable to use - specific scopes by default. Additionally, a UA or SA - MUST be configurable to use specific scopes for requests - for and registrations of specific service types. The - scope or scopes of a DA MUST be configurable. The - default value for a DA is to have the scope "DEFAULT" if - not otherwise configured. - - DHCP Configuration - 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. - - - - -Guttman, et al. Standards Track [Page 43] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - Service Template - UAs and SAs MAY be configured by using Service Templates. - Besides simplifying the specification of attribute - values, this also allows them to enforce the inclusion - of 'required' attributes in SrvRqst, SrvReg and SrvDeReg - messages. DAs MAY be configured with templates to - allow them to WARN UAs and SAs in these cases. See - Section 10.4. - - SLP SPI for service discovery - Agents SHOULD be configurable to support SLP SPIs using - the following parameters: BSD=2 (DSA with SHA-1) and - a public key identified by the SLP SPI String. In - the future, when a Public Key Infrastructure exists, - SLP Agents may be able to obtain public keys and - cryptographic parameters corresponding to the names used - in SLP SPI Strings. - - Note that if the SLP SPI string chosen is identical - to a scope string, it is effectively the same as a - Protected Scope in SLPv1. Namely, every SA advertising - in that scope would be configured with the same Private - Key. Every DA and UA of that scope would be configured - with the appropriate Public Key to verify signatures - produced by those SAs. This is a convenient way to - configure SLP deployments in the absence of a Public Key - Infrastructure. Currently, it would be too difficult to - manage the keying of UAs and DAs if each SA had its own - key. - - SLP SPI for Directory Agent discovery - Agents SHOULD be configurable to support SLP SPIs as - above, to be used when discovering DAs. This SPI SHOULD - be sent in SrvRqsts to discover DAs and be used to verify - multicast DAAdvert messages. - - SA and DA Private Key - SAs and DAs which can generate digital signatures require - a Private Key and a corresponding SLP SPI indentifier - to include in the Authentication Block. The SLP SPI - identifies the Public Key to use to verify the digital - signature in the Authentication Block. - -15. IANA Considerations - - SLP includes four sets of identifiers which may be registered with - IANA. The policies for these registrations (See [18]) are noted in - each case. - - - -Guttman, et al. Standards Track [Page 44] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - The Block Structure Descriptor (BSD) identifies the format of the - Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use. - - Further Block Structured Descriptor (BSD) values, from the range - 0x0003-0x7FFF may be standardized in the future by submitting a - document which describes: - - - The data format of the Structured Authenticator block. - - - Which cryptographic algorithm to use (including a reference - to a technical specification of the algorithm.) - - - The format of any keying material required for - preconfiguring UAs, DAs and SAs. Also include any - considerations regarding key distribution. - - - Security considerations to alert others to the strengths and - weaknesses of the approach. - - The IANA will assign Cryptographic BSD numbers on the basis of IETF - Consenus. - - New function-IDs, in the range 12-255, may be standardized by the - method of IETF Consensus. - - New SLP Extensions with types in the range 2-65535 may be registered - following review by a Designated Expert. - - New error numbers in the range 15-65535 are assigned on the basis of - a Standards Action. - - Protocol elements used with Service Location Protocol may also - require IANA registration actions. SLP is used in conjunction with - "service:" URLs and Service Templates [13]. These are standardized - by review of a Designated Expert and a mailing list (See [13].) - -16. Internationalization Considerations - - SLP messages support the use of multiple languages by providing a - Language Tag field in the common message header (see Section 8). - - Services MAY be registered in multiple languages. This provides - attributes so that users with different language skills may select - services interactively. - - Attribute tags are not translated. Attribute values may be - translated unless the Service Template [13] defines the attribute - values to be 'literal'. - - - -Guttman, et al. Standards Track [Page 45] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - A service which is registered in multiple languages may be queried in - multiple languages. The language of the SrvRqst or AttrRqst is used - to satisfy the request. If the requested language is not supported, - a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply - messages are always in the same language of the request. - - A DA or SA MAY be configured with translations of Service Templates - [13] for the same service type. This will allow the DA or SA to - translate a request (say in Italian) to the language of the service - advertisement (say in English) and then translate the reply back to - Italian. Similarly, a UA MAY use templates to translate outgoing - requests and incoming replies. - - The dialect field in the Language Tag MAY be used: Requests which - can be fulfilled by matching a language and dialect will be preferred - to those which match only the language portion. Otherwise, dialects - have no effect on matching requests. - -17. Security Considerations - - SLP provides for authentication of service URLs and service - attributes. This provides UAs and DAs with knowledge of the - integrity of service URLs and attributes included in SLP messages. - The only systems which can generate digital signatures are those - which have been configured by administrators in advance. Agents - which verify signed data may assume it is 'trustworthy' inasmuch as - administrators have ensured the cryptographic keying of SAs and DAs - reflects 'trustworthiness.' - - Service Location does not provide confidentiality. Because the - objective of this protocol is to advertise services to a community of - users, confidentiality might not generally be needed when this - protocol is used in non-sensitive environments. Specialized schemes - might be able to provide confidentiality, if needed in the future. - Sites requiring confidentiality should implement the IP Encapsulating - Security Payload (ESP) [3] to provide confidentiality for Service - Location messages. - - If Agents are not configured to generate Authentication Blocks and - Agents are not configured to verify them, an adversary might easily - use this protocol to advertise services on servers controlled by the - adversary and thereby gain access to users' private information. - Further, an adversary using this protocol will find it much easier to - engage in selective denial of service attacks. Sites that are in - potentially hostile environments (e.g., are directly connected to the - Internet) should consider the advantages of distributing keys - associated with SLP SPIs prior to deploying the sensitive directory - agents or service agents. - - - -Guttman, et al. Standards Track [Page 46] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - SLP is useful as a bootstrap protocol. It may be used in - environments in which no preconfiguration is possible. In such - situations, a certain amount of "blind faith" is required: Without - any prior configuration it is impossible to use any of the security - mechanisms described above. SLP will make use of the mechanisms - provided by the Security Area of the IETF for key distribution as - they become available. At this point it would only be possible to - gain the benefits associated with the use of Authentication Blocks if - cryptographic information and SLP SPIs can be preconfigured with the - end systems before they use SLP. - - SLPv2 enables a number of security policies with the mechanisms it - includes. A SLPv2 UA could, for instance, reject any SLP message - which did not carry an authentication block which it could verify. - This is not the only policy which is possible to implement. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 47] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -A. Appendix: Changes to the Service Location Protocol from v1 to v2 - - SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22]. - In addition, authentication has been reworked to provide more - flexibility and protection (especially for DA Advertisements). SLPv2 - also changes the formats and definition of many flags and values and - reduces the number of 'required features.' SLPv2 clarifies and - changes the use of 'Scopes', eliminating support for 'unscoped - directory agents' and 'unscoped requests'. SLPv2 uses LDAPv3 - compatible string encodings of attributes and search filters. Other - changes (such as Language and Character set handling) adopt practices - recommended by the Internet Engineering Steering Group. - - Effort has been made to make SLPv2 operate the same whether DAs are - present or not. For this reason, a new message (the SAAdvert) has - been added. This allows UAs to discover scope information in the - absence of administrative configuration and DAs. This was not - possible in SLPv1. - - SLPv2 is incompatible in some respects with SLPv1. If a DA which - supports both SLPv1 and SLPv2 with the same scope is present, - services advertised by SAs using either version of the protocol will - be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased - out and replace with SLPv2 DAs which support both versions of the - protocol. - - SLPv1 allows services to be advertised and requested without a scope. - Further, DAs can be configured without a scope. This is incompatible - with SLPv2 and presents scalability problems. To facilitate this - forward migration, SLPv1 agents MUST use scopes for all registrations - and requests. SLPv1 DAs MUST be configured with a scope list. This - constitutes a revision of RFC 2165 [22]. - -B. Appendix: Service Discovery by Type: Minimal SLPv2 Features - - Service Agents may advertise services without attributes. This will - enable only discovery of services by type. Service types discovered - this way will have a Service Template [13] defined which specifies - explicitly that no attributes are associated with the service - advertisement. Service types associated with Service Templates which - specify attributes MUST NOT be advertised by SAs which do not support - attributes. - - While discovery of service by service type is a subset of the - features possible using SLPv2 this form of discovery is consistent - with the current generation of products that allow simple browsing of - all services in a 'zone' or 'workgroup' by type. In some cases, - attribute discovery, security and feature negotiation is handled by - - - -Guttman, et al. Standards Track [Page 48] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - application layer protocols - all that is required is the basic - discovery of services that support a certain service. - - UAs requesting only service of that service type would only need to - support service type and scope fields of the Service Request. UAs - would still perform DA discovery and unicast SLPv2 SrvRqst messages - to DAs in their scope once they were discovered instead of - multicasting them. - - SAs would also perform DA discovery and use a SLPv2 SrvReg to - register all their advertised services with SLPv2 DAs in their scope. - These advertisements would needless to say contain no attribute - string. - - These minimal SAs could ignore the Language Tag in requests since - SrvRqst messages would contain no attributes, hence no strings would - be internationalized. Further, any non-null predicate string would - fail to match a service advertisement with no attributes, so these - SAs would not have to parse and interpret search filters. Overflow - will never occur in SrvRqst, SrvRply or SrvReg messages so TCP - message handling would not have to be implemented. Finally, all - AttrRqst messages could be dropped by the SA, since no attributes are - supported. - -C. Appendix: DAAdverts with arbitrary URLs - - Using Active DA Discovery, a SrvRqst with its service type field set - to "service:directory-agent". DAs will respond with a DAAdvert - containing a URL with the "service:directory-agent:" scheme. This is - the same DAAdvert that such a DA would multicast in unsolicited DA - advertisements. - - A UA or SA which receives an unsolicited DAAdvert MUST examine the - URL to determine if it has a recognized scheme. If the UA or SA does - not recognize the DAAdvert's URL scheme, the DAAdvert is silently - discarded. This document specifies only how to use URLs with the - "service:directory-agent:" scheme. - - This provides the possibility for forward compatibility with future - versions of SLP and enables other services to advertise their ability - to serve as a clearinghouse for service location information. - - For example, if LDAPv3 [15] is used for service registration and - discovery by a set of end systems, they could interpret a LDAP URL - [16] to passively discover the LDAP server to use for this purpose. - This document does not specify how this is done: SLPv2 agents - without further support would simply discard this DAAdvert. - - - - -Guttman, et al. Standards Track [Page 49] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -D. Appendix: SLP Protocol Extensions - -D.1. Required Attribute Missing Option - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Extension Type = 0x0001 | Extension Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Template IDVer Length | Template IDVer String \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Required Attr <tag-list> Length| Required Attr <tag-list> \ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Required attributes and the format of the IDVer string are defined by - [13]. - - If a SA or DA receives a SrvRqst or a SrvReg which fails to include a - Required Attribute for the requested Service Type (according to the - Service Template), it MAY return the Required Attribute Extension in - addition to the reply corresponding to the message. The sender - SHOULD reissue the message with a search filter including the - attributes listed in the returned Required Attribute Extension. - Similarly, the Required Attribute Extension may be returned in - response to a SrvDereg message that contains a required attribute - tag. - - The Template IDVer String is the name and version number string of - the Service Template which defines the given attribute as required. - It SHOULD be included, but can be omitted if a given SA or DA has - been individually configured to have 'required attributes.' - - The Required Attribute <tag-list> MUST NOT include wild cards. - -E. Acknowledgments - - This document incorporates ideas from work on several discovery - protocols, including RDP by Perkins and Harjono, and PDS by Michael - Day. We are grateful for contributions by Ye Gu and Peter Ford. - John Veizades was instrumental in the standardization of the Service - Location Protocol. Implementors at Novell, Axis Communications and - Sun Microsystems have contributed significantly to make this a much - clearer and more consistent document. - - - - - - - - -Guttman, et al. Standards Track [Page 50] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -F. References - - [1] Port numbers, July 1997. - ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. - - [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment - DAM 4 to ISO/IEC 9594-2, December 1996. - - [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment - DAM 2 to ISO/IEC 9594-6, December 1996. - - [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment - DAM 1 to ISO/IEC 9594-7, December 1996. - - [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment - DAM 1 to ISO/IEC 9594-8, December 1996. - - [6] Unicode Technical Report #8. The Unicode Standard, version 2.1. - Technical report, The Unicode Consortium, 1998. - - [7] Alvestrand, H., "Tags for the Identification of Languages", - RFC 1766, March 1995. - - [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [10] CCITT. The Directory Authentication Framework. Recommendation - X.509, 1988. - - [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. - Addison-Wesley, 1990. - - [13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and - service: Schemes", RFC 2609, June 1999. - - [14] Howes, T., "The String Representation of LDAP Search Filters", - RFC 2254, December 1997. - - [15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - - - -Guttman, et al. Standards Track [Page 51] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - - [16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, - December 1997. - - [17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, - July 1998. - - [18] Narten, T. and H. Alvestrand, "Guidelines for Writing - an IANA Considerations Section in RFCs, BCP 26, RFC 2434, - October 1998. - - [19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, - Document Version 1.09, November 1989. - - [20] National Institute of Standards and Technology. Digital - signature standard. Technical Report NIST FIPS PUB 186, U.S. - Department of Commerce, May 1994. - - [21] Perkins, C. and E. Guttman, "DHCP Options for Service Location - Protocol", RFC 2610, June 1999. - - [22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service - Location Protocol", RFC 2165, July 1997. - - [23] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - RFC 2279, January 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 52] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -G. Authors' Addresses - - Erik Guttman - Sun Microsystems - Bahnstr. 2 - 74915 Waibstadt - Germany - - Phone: +49 7263 911 701 - EMail: Erik.Guttman@sun.com - - - Charles Perkins - Sun Microsystems - 901 San Antonio Road - Palo Alto, CA 94040 - USA - - Phone: +1 650 786 6464 - EMail: cperkins@sun.com - - - John Veizades - @Home Network - 425 Broadway - Redwood City, CA 94043 - USA - - Phone: +1 650 569 5243 - EMail: veizades@home.net - - - Michael Day - Vinca Corporation. - 1201 North 800 East - Orem, Utah 84097 USA - - Phone: +1 801 376-5083 - EMail: mday@vinca.com - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 53] - -RFC 2608 Service Location Protocol, Version 2 June 1999 - - -H. 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. - - - - - - - - - - - - - - - - - - - -Guttman, et al. Standards Track [Page 54] - |