Internet Engineering Task Force Erik Guttman (coeditor) INTERNET DRAFT James Kempf (coeditor) Category: Standards Track Obseletes: 2608 December 17, 2001 Expires in six months Service Location Protocol, Version 2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Comments on this document should be sent to the SLP discussion list, srvloc-discuss@lists.sourceforge.net. Internet-Drafts are draft documents of the Internet Engineering Task valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." See http://www.ietf.org/ietf/1id-abstracts.txt. Find shadow directories at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2001). 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. This document updates SLPv2, adding clarifications and removing features which were neither widely implemented or deemed useful. Acknowledgements Authors of previous versions of SLP listed alphabetically are Mike Day, Erik Guttman, Scott Kaplan, Charles Perkins and John Veizades. Contributors to this version include (in alphebetical order) Kevin Arnold, Erik Guttman, Evan Hughes, James Kempf, Terry Lambert, Jim Mayer, Ira McDonald, Mikael Pahmp, Matt Peterson and Weibin Zhao. 1. Introduction The Service Location Protocol (SLP) provides a flexible and scalable framework for providing network nodes with information: the Guttman & Kempf Expires: 18 June 2002 [Page 1] Internet Draft SLPv2 Revision December 2001 existence, location, and configuration of networked services. Traditionally, users have had to find services by knowing the name of a network host (usually 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 returns all required information to communicate with the service. SLP implements a dynamic configuration mechanism for applications in networks under a common administration. Applications are modeled as clients that need to find available services offered by hosts attached on any network 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 obseletes SLPv2 [RFC2608], correcting protocol errors and removing some requirements. A separate SLPv2 applicability statement [SLPv2AS] describes both the protocol's domain of applicability as well as the interoperability of this specification with prior versions of the protocol. 2. Terminology and Conventions used in this Document Network Element A software process capable of network communication. User Agent (UA) A network element 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 network element working on the behalf of services to advertise them. Directory Agent (DA) A network element 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. The default service type for a 'generic' URI is its scheme name. For example, the service type string for "http://www.srvloc.org" would be "http". Naming Authority This is an agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA. Guttman & Kempf Expires: 18 June 2002 [Page 2] Internet Draft SLPv2 Revision December 2001 Scope A Scope is a named collection of service advertisements, making up a logical administrative group. Service URL A Service URL serves two functions in SLP. First, it is a handle to refer to a service advertisement, for purposes of reregistration, deregistration or requesting associated attributes. Second, the Service URL may indicate the location of a service. This URL may be of the service: scheme [RFC2609] or any other scheme conforming to the URI standard [RFC2396]. Attribute An Attribute consists of a tag and a list of typed values. An Attribute without a value list, called a "keyword" attribute, may also appear. Attributes are used to describe instances of a service type. Service Advertisement This is a Service Type, Service URL, a list of Scopes, a language tag, a list of Attributes and a lifetime indicating how long the advertisement is valied. Directory Agent Service Type The Directory Agent Service Type is the service type "service:directory-agent". It is used to discover DAs. Service Agent Service Type The Service Agent Service Type is the service type "service:service-agent". It is used to discover and advertise SAs. 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 [RFC2119]. In packet diagrams, an explicit length field may be followed by a variable length field, terminated by a backslash ('\'). 3. Protocol Overview SLP discovery support for client applications is provided by 'User Agents.' SLP service advertising support for services are provided by 'Service Agents.' A third network element, called a 'Directory Agent' provides scalability to the protocol. The User Agent issues a 'Service Request' (SrvRqst) on behalf of a client application. The SrvRqst specifies the characteristics of a service required by the client. The User Agent receives a Service Reply (SrvRply) specifying the location of all services in the network which match the conditions supplied in the SrvRqst. Guttman & Kempf Expires: 18 June 2002 [Page 3] Internet Draft SLPv2 Revision December 2001 The Service Location Protocol framework allows a User Agent to directly issue requests to Service Agents. Such requests are multicast. A Service Agents unicasts a reply to the User Agent, containing a Service URL and other information, if the Servcie Agent advertises a service matching the request. +------------+ ----Multicast SrvRqst----> +---------------+ | User Agent | | Service Agent | +------------+ <----Unicast SrvRply------ +---------------+ In larger networks, one or more Directory Agents are used. A Directory Agent functions as a cache. Service Agents send Service Registration (SrvReg) messages, containing all the services they advertise to Directory Agents. Service Agents receive Service Acknowledgements (SrvAck) messages in reply. Advertisements registered with Directory Agents must be refreshed or they will expire, since each advertisement has a finite lifetime. If Directory Agents are in use, User Agents unicast requests to a Directory Agent instead of multicasting. Deploying Directory Agents thereyb helps reduce the amount of multicast datagrams in a network. +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ | User | | Directory | |Service | | Agent | | Agent | | Agent | +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ There are three possible ways for User and Service Agents to discover Directory Agents. In each case, the agent obtains a DA Advertisement (DAAdvert). 1) Issue a multicast SrvRqst for the Directory Agent Service Type when they start up, and receive a unicast advertisement in reply, 2) Listen for unsolicited advertisement sent infrequently by Directory Agents, 3) Receive configured Directory Agent addresses via DHCP or statically, then contact the Directory Agent via unicast for an advertisement. +---------------+ --Multicast SrvRqst-> +-----------+ | User or | <--Unicast DAAdvert-- | Directory | | Service Agent | | Agent | +---------------+ <-Multicast DAAdvert- +-----------+ Service advertisements are grouped into named sets called 'scopes'. Scope names are expressed as strings. A scope can indicate a location, administrative grouping, proximity in a network topology or some other category. The mapping between service advertisements and scopes is at the discretion of the network administrator. Service Agents and Directory Agents are always configured with scopes. Guttman & Kempf Expires: 18 June 2002 [Page 4] Internet Draft SLPv2 Revision December 2001 A User Agent is typically assigned scopes, 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, the User Agent discovers all available scopes and client application may issue requests for any service available on the network. In the following figure, the User Agent is configured with scopes X and Y. If a service is sought in scope X, the request is multicast because no DA supports scope X. If a service is sought in scope Y, the request is unicast to the DA. If the request is made in both scopes, the request must be both unicast and multicast. +---------+ Multicast +-----------+ Unicast +-----------+ | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | | Agent | | Agent | | Agent | | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+ 3.1 SLP Message Types Table 1 contains a brief summary of all SLP required and optional messages, along with the requirement level for SLP agents. SAs MUST accept multicast and unicast SrvRqsts. SAs SHOULD accept Attribute Requests (AttrRqsts), see Appendix B. SAs MAY accept Service Type Requests (SrvTypeRqsts). SAs MUST listen for unsolicited multicast DA Advertisements. DAs MUST support all required and optional SLP message types in the table. +----------------------+----+----+-----+-----+-------------------------+ | Message |CODE| UA | SA | DA | Purpose | +----------------------+----+----+-----+-----+-------------------------+ | Service Register | 3 | | MUST| MUST| Register a service (url,| | (SrvReg) | | | send| recv| attrs, etc.) with a DA. | +----------------------+----+----+-----+-----+-------------------------+ | Service Deregister | 4 | | MAY | MUST| Deregisters a service | | (SrvDereg) | | | send| recv| from a DA. | +----------------------+----+----+-----+-----+-------------------------+ | Service Acknowledge | 5 | | MUST| MUST| Contains a DA's response| | (SrvAck) | | | recv| send| to SrvReg and SrvDereg. | +----------------------+----+----+-----+-----+-------------------------+ | Service Request | 1 |MUST| MUST| MUST| Requests services which | | (SrvRqst) | |send|s & r| recv| match query criteria. | +----------------------+----+----+-----+-----+-------------------------+ | Service Reply | 2 |MUST| MUST| MUST| Returns services which | | (SrvRply) | |recv| send| send| match query criteria. | +----------------------+----+----+-----+-----+-------------------------+ | DA Advertisement | 8 |MUST| MUST| MUST| Contains location, DA | | (DAAdvert) | |recv| recv| send| attributes and more. | +----------------------+----+----+-----+-----+-------------------------+ Guttman & Kempf Expires: 18 June 2002 [Page 5] Internet Draft SLPv2 Revision December 2001 | SA Advertisement | 11 |MAY | MUST| | Contains location, SA | | (SAAdvert) | |recv| send| | attributes and more. | +----------------------+----+----+-----+-----+-------------------------+ | Service Type Request | 9 |MAY | MAY | MUST| Get all available | | (SrvTypeRqst) | |send| recv| recv| service types. | +----------------------+----+----+-----+-----+-------------------------+ | Service Type Reply | 10 |MAY | MAY | MUST| Contains all available | | (SrvTypeRply) | |recv| send| recv| service types. | +----------------------+----+----+-----+-----+-------------------------+ | Attribute Request | 6 |MAY |SHOULD MUST| Get all attributes for | | (AttrRqst) | |send| recv| recv| a particular service. | +----------------------+----+----+-----+-----+-------------------------+ | Attribute Reply | 7 |MAY |SHOULD MUST| Contains all attributes | | (AttrRply) | |recv| send| send| of a particular service.| +----------------------+----+----+-----+-----+-------------------------+ Table 1 - Summary of Required and Optional SLP Message Types and Requirement Level In the absence of multicast support, broadcast MAY be used. The location of DAs MAY be statically configured, discovered using SLP as described above, or configured using DHCP. If a message is too large, it MAY be unicast using TCP. 4. Protocol Elements All integer fields in SLP messages MUST be in network byte order. 4.1 Error Codes 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. Errors MUST be return for unicast requests. Multicast requests that result in an error MUST BE silently discarded. A reply MUST NOT be sent if a multicast request results in an error. The following is a list of SLP error codes. Error codes marked with a '*' can be returned in response to any request message, all others are returned only for specific messages. Error codes returned for specific messages are described in the sections where the messages are specified. OK * 0 There request was successful. LANGUAGE_NOT_SUPPORTED 1 The request could not be processed due to the language selected. The request SHOULD NOT fail if sent with the default language tag 'en'. Guttman & Kempf Expires: 18 June 2002 [Page 6] Internet Draft SLPv2 Revision December 2001 PARSE_ERROR 2 The message fails to obey SLP syntax. The error may be due to misalignment in the binary format of the message, a missing header language tag, a syntax error in the header language tag, or a syntax error in a message-specific string such as a service query or scope string. INVALID_REGISTRATION 3 A problem occurred with the parameters of a SrvReg or SrvDereg mesage, other than with the syntax of string parameters. An AttrRqst for a service not advertised. SCOPE_NOT_SUPPORTED * 4 The scope-list lacks a supported scope. VER_NOT_SUPPORTED * 9 The SLP version number is not supported. INTERNAL_ERROR * 10 The DA or SA failed for some reason. DA_BUSY_NOW * 11 The DA is currently busy processing other requests. The UA or SA SHOULD retry, using exponential back off. OPTION_NOT_UNDERSTOOD *12 The DA (or SA) received an unknown SLP option from the mandatory range. INVALID_UPDATE 13 A SrvReg without FRESH set is invalid. MSG_NOT_SUPPORTED 14 The SA received an unsupported request. REFRESH_REJECTED 15 The SA sent a SrvRegs too frequently. The SA SHOULD consult the DA's minimum refresh interval attribute (Section 9.4) and try again when this interval expires. 4.2 SLP Message Header 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 | Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length, contd.|O|F|R| reserved |Next Ext Offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Extension Offset, contd.| XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language Tag Length | Language Tag \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All SLP messages begin with this header. Guttman & Kempf Expires: 18 June 2002 [Page 7] Internet Draft SLPv2 Revision December 2001 - Version: This field MUST be set to 2. - Code: Identifies the messsage type, see Table 1. Any value outside those defined in Table 1 or standards track protocols extending SLP MUST be treated as an error. - Length: Three byte unsigned integer containing the number of bytes in the SLP message including the header. - Flags: All but the following bits are reserved and MUST be 0. O Field is (0x80). "OVERFLOW" MUST be set to 1 when a message length would exceed the path MTU and the mesage contents wouldn't fit into a datagram. See Section 5.1.3. Otherwise, MUST be 0. F Field is (0x40). "FRESH" MUST be set to 1 on every SrvReg. Otherwise, MUST be 0. R Field is (0x20). "REQUEST MCAST" MUST be set when multicasting or broadcasting requests. Otherwise, MUST be 0. Reserved This bits MUST be set to zero on transmission and ignored on reception. - Next Extension Offset: MUST be set to 0 unless the message has any extensions. If the message has extensions, MUST contain the offset from the beginning of the message, in bytes, to the first extension header. This SHOULD come after the message body. See Section 7.1. - XID: The Transaction Identifier MUST be set to a unique value for each unique request. See Section 9 for the special case of unsolicited DAAdverts. - Lang Tag Length: Two byte unsigned integer giving the length in bytes of the Language Tag field. MUST NOT be zero. - Language Tag: MUST contain a variable length field, RFC 3066 language local string. This specifies the language locale for all human readable strings in the message [RFC3066] See Section 14. If the Version field is not 2 a VER_NOT_SUPPORTED error results. A Guttman & Kempf Expires: 18 June 2002 [Page 8] Internet Draft SLPv2 Revision December 2001 PARSE_ERROR results if the Code field has a value other than a legal value in Table 1 or standards track extension to SLP, or if the message is syntactically incorrect. 4.3 Strings Strings in SLP messages MUST be encoded using UTF-8 [RFC2279]. Strings MUST not be null terminated and MUST always be preceded by a two byte unsigned length field indicating the number of bytes which follow. Optional strings MAY be omitted. In this case, the Length field is set to zero and the string MUST be absent. The specifications for the syntax of string-based protocol elements in this document conform to ABNF [RFC2234]. 4.3.1 General String Comparisons White spaces in strings MUST not be elided for the purposes of string comparison. For example, "string1 " is not equal " string1" nor is it equal to "string1". String comparisons MUST not be case sensitive. For example "STRING1" is equal to "String1" and is also equal to "string1". This corresponds to the LDAPv3 string matching rule "EDITOR: FIND THIS" [REF]. 4.3.2 Lists A List is a comma delimited set of strings. List syntax is: list = null / slist null = ; Null indicates no characters at all, an empty list. slist = string / string ',' slist string = ; Allowable strings depend on the List unsafe = ',' / NULL escape = "\" HEXDIG HEXDIG Any unsafe character in a string component of a string list MUST be replaced by an escaped hexadecimal UTF-8 value (ie. "\2c" for ','). 4.3.3 Previous Responder List The Previous Responder List (PR List) is a List of dotted decimal notation IPv4 addresses. When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they SHOULD contain a Previous Responders List (see Section 4.3.1) indicating all responders the sender has received replies from. Each responder's IP address (in dotted decimal form) SHOULD be added to form the new List if the request is multicast again. Guttman & Kempf Expires: 18 June 2002 [Page 9] Internet Draft SLPv2 Revision December 2001 Any DA or SA which sees its address in the SHOULD NOT respond to the request. A multicast request message with a Previous Responder List SHOULD be retransmitted until no further responses are elicited, the Previous Responder List and the request will not fit into a single datagram, or CONFIG_MC_MAX seconds have elapsed. A syntax error in a Previous Responder List results in a PARSE_ERROR. 4.3.4 Service Type String The service type string is a parameter in SrvRqst messages, in which the service type string selects a type of service, and in SrvReg message, in which the service type string identifies the service type of the service advertisement. The syntax of the service type string is: service-type = generic-uri-scheme / service-scheme generic-uri-scheme = ALPHA *( alpha / digit / '+' / '-' / '.' ) service-scheme = "service:" type ['.' na ] [':' type ] type = 1*(alpha / digit / '+' / '-' ) na = 1*(alpha / digit / '+' / '-' ) Service type strings MUST match each other with case insensitive string comparison. However, a complication in comparing service type strings is the abstract service type strings [RFC2609]. These have the form: "service:"":". The service type string "service:" MUST match all service type strings having the same substring regardless of the string. If the concrete type is included also, service type strings MUST match only if both the and substrings match. As an example "service:a" matches "service:a" and "service:a:b", but "service:a:c" does not match either. A further complication in comparing service type strings is naming authority strings. The service: URL scheme syntax allows the first type listed after the 'service:' scheme to be followed by a '.' and a Naming Authority string. Service type strings MUST match with the same Naming Authority string in order for the service type strings to match. For example, "service:a.na" matches "service:a.na" and "service:a.na:b" but it does not match "service:a" or "service:a:b" since the Naming Authority is different. The default Naming Authority is IANA. A Service Type name that is registered with IANA MUST NOT contain a naming authority string. Guttman & Kempf Expires: 18 June 2002 [Page 10] Internet Draft SLPv2 Revision December 2001 Naming Authorities are used to define Service Types which are proprietary, experimental or for private use. Naming authorities SHOULD NOT be used. One has to have a very good reason not register service types with IANA as described in [RFC2609]. A syntax error in a service type name MUST result in the return of a PARSE ERROR to the sending agent, if the request was unicast. 4.3.5 Scope List With two exceptions, all requests, service advertisement registrations, and service advertisement deregistrations MUST contain a scope list. SLP messages that fail to contain a scope list or that contain a scope list having no scopes for which the receiving agent is configured MUST BE either dropped, if the request was multicast, or result in a SCOPE_NOT_SUPPORTED error in reply, if the request was unicast. The two exceptions are SrvRqsts for the Directory Agent Service Type and for the Service Agent Service Type. These MAY be transmitted without a scope list if the transmitting agent is interested in obtaining a list of all configured scopes supported by the replying Directory Agent or Service Agent. 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 Scope names that include any reserved characters MUST replace the escaped character with the escape-val format. If a syntax error in a scope list or scope name is encountered, the receiving agent MUST return a PARSE ERROR if the request was unicast. The default value for the scope list is the scope name "DEFAULT". Scope configuration rules are described in Section 8.0. 4.3.6 Attribute list A service advertisement is often accompanied by attributes. A UA formulates a service query containing attributes in order to select particular service advertisements. A Service Type MAY specify allowable attributes through a defined service template [RFC2609]. The allowable attributes for such a service are defined in the service template. Services that are advertised according to a standard template SHOULD register all Guttman & Kempf Expires: 18 June 2002 [Page 11] Internet Draft SLPv2 Revision December 2001 service attributes required by the standard template. If no service template is available for a Service Type, then any attributes are allowed. Support for service templates is optional. An attribute list is a string encoding of the attributes for a service advertisement. The following grammar defines the attribute list syntax: attr-list = attribute / attribute ',' attr-list attribute = '(' attr-tag '=' val-list ')' / attr-tag val-list = attr-val / attr-val ',' val-list attr-tag = 1*safe-tag / nonstd-tag nonstd-tag = "x-" enum '-' 1*safe-tag enum = 1*DIGIT ; The field corresponds to an Enterprise ; Number registered with IANA. [IANA] Using this ; prefix avoids collisions in interpretation of ; nonstandard attribute name. 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, '*' and bad-tag. reserved = '(' / ')' / ',' / '\' / '!' / '<' / '=' / '>' / '~' / CTL escape-val = '\' HEXDIG HEXDIG bad-tag = CR / LF / HTAB / '_' An Attribute List MUST be scanned prior to evaluation for all occurrences of the escape character '\'. Reserved characters MUST be escaped while other characters MAY be escaped. All escaped characters MUST be restored to their value before attempting string matching. Escaped Opaque values are converted into bytes, not into characters. The following list contains more detail on the various types of attributes: Boolean A Boolean attribute MUST have a value list that is one of the Boolean constants "true" or "false". A Boolean value list MUST only have a single value and MUST only be compared with '='. As with all strings, the Boolean constants are case insensitive. Integer An Integer attribute MUST have a value list consisting of Integer constants. Integer constants MUST be strings that take the form [-] 1*DIGIT and fall in the range "-2147483648" to "2147483647", that is, the range of 32 bit signed integers. Integer values MUST be compared using integer Guttman & Kempf Expires: 18 June 2002 [Page 12] Internet Draft SLPv2 Revision December 2001 comparison. Opaque An Opaque attribute MUST have a value list consisting of opaque values. Opaque values are sequences of bytes. These MUST be distinguished from strings since they begin with the sequence "\FF". Unescaping this sequence results in an illegal UTF-8 encoding, indicating that what follows is a sequence of escaped bytes and not a UTF-8 string. For example, a '0' byte is encoded "\FF\00" and "\ff\00\00\30\39" is a bigendian representation of 12345. Opaque values MUST only be compared with '='. String All other string values are String type. String values MUST be matched using strict lexical ordering. Example of string values with escaped characters: "Hello\0a" (Hello with a newline) and "\48\65\6c\6c\6f\0a" (the same string, entirely escaped). Keyword A Keyword attribute has only a tag. A Keyword attribute MUST be designated by attr-tag in the attribute list, and it MUST have no values. A string containing escaped values other than from the reserved set of characters or syntax errors in the attribute list MUST result in a PARSE ERROR. When values have been advertised by a SA or are registered in a DA, they MUST take on implicit typing rules for matching incoming requests, according to the types described above. Stored value types in attribute lists MUST be consistent, i.e., x=4,true,sue,\ff\00\00 is in error. Inconsistent stored value types MUST result in a PARSE ERROR. A DA MUST consolidate multiple instances of the same attribute within an attribute list before storing and an SA MUST consolidate multiple instances before sending the attribute in an AttrRply. For example, if the attribute list received by a DA is: "(x=5,6,7),(y=a,b,c),(x=6,7,8)" one attribute, "x", is stored having value list "5,6,7,8". Embedded blanks in attribute tags and value lists MUST be processed as part of the tags or values in which they appear, embedded blanks MUST NOT be ignored. For example, in the attribute list "(attra = -345)", the attribute tag is "attra " and the value is the String " -345". The value is not an Integer due to the embedded blank. Guttman & Kempf Expires: 18 June 2002 [Page 13] Internet Draft SLPv2 Revision December 2001 4.3.7 Search Filter A SrvRqst message may include a LDAPv3 search filter [RFC2254], with certain restrictions. RFC 2254 describes the syntax of LDAPv3 search filters. A DA MUST accept any LDAPv3 query, excluding those with extensible matching rules. A SA MAY accept only simple queries; otherwise, it MUST accept service queries as a DA would. A UA SHOULD send only simple queries. The syntax for a simple query is: simple-query = conjoin / term conjoin = "(&" term-list ')' term-list = term term-list / term term = '(' tag querytype item ')' / '(' tag "=*)" ; The "=*" term tests if the attribute is ; present. tag = 1*tag-safe querytype = '=' / "~=" / ">=" / "<=" ; These correspond to equal, approx, ; greater than or equal, less than or ; equal. item = value / substring ; Only substring matching is supported. value = 1*val-safe substring = [ value ] any [ value ] any = '*' *(value "*") tag-unsafe = val-unsafe / CR / LF / HTAB / '_' tag-safe = ; All UTF-8 characters are included except ; those in tag-unsafe. Tag-unsafe must be ; escaped. val-unsafe = '(' / ')' / ',' / '' / '!' / '<' / '=' / '>' / '~' / CTL val-safe = ; All UTF-8 characters are included ; except those in val-unsafe. Val-unsafe ; must be escaped. escaped = '' HEXDIG HEXDIG Attribute tags and String values MUST be case-folded within the locale of the request before performing string matching. Matching rules for other types are as described in 4.3.6. If a Service Template [RFC2609] is available, the Service Template SHOULD be used to guide matching of types. If no Service Template is available, for ordered string matching, values MUST be matched using an implicit type system. Values of ['-']1*DIGIT MUST be treated as integers, so a service advertisement with attribute list "(x=12),(y=-55)" would match the Guttman & Kempf Expires: 18 June 2002 [Page 14] Internet Draft SLPv2 Revision December 2001 query "(&(x>6)(y<-44))". Note that integers MUST NOT match strings, for example, the search query "(x=34*)" matches an attribute list "(x=34foo)", but not "(x=3432)" since the first value is a String while the second value is an Integer. Embedded blanks MUST NOT be ignored. For example, the query "(&(x= -345)(y=7))" matches the service advertisement with attribute list "(x= -345)" but not the service advertisement with attribute list "(x=-345)". If the attribute in the query has been registered with multiple values, the query MUST be compared to each value and the results MUST be combined with logical 'OR', i.e., "(x=\ff\00)" matches a registration of (x=\ff\33,\ff\00); "(Y<=0))" matches (y=0,-1). Keywords (i.e., attributes without values) MUST be matched with a "presence" query, as in "(keyword=*)". A syntax error in a service query results in a PARSE_ERROR. 4.3.8 Attribute Tag List This is a List of attr-tags, as defined in Section 4.3.4, above. 4.3.9 SLP SPI Previous versions of SLP used this string to identify authentication parameters. This is no longer supported and SLP SPI fields sent MUST be of zero length. A DA SHOULD accept and support SLPv2 SLP SPIs [SLPv2AS] 4.4 URL Entry 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) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# authblocks =0| +-+-+-+-+-+-+-+-+ SLP stores URLs in protocol elements called URL Entries, which associate a URL with a lifetime. Reserved MUST be set to 0. Lifetime An unsigned two byte integer giving the lifetime which the URL is valid (that is, may be cached), in seconds. URL Length, URL String Guttman & Kempf Expires: 18 June 2002 [Page 15] Internet Draft SLPv2 Revision December 2001 The Length MUST NOT be zero, the URL MUST NOT be omitted. 5. Required Features This section lists requirements for any conforming implementation of SLP. All requirements are identified by a letter (U, S or D, for UA, SA or DA requirement) and a number, throughout this specification. A minimal implementation may consist of either a UA or SA or both. 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 UA MUST be able to [U1] issue SrvRqst messages and [U2] interpret SrvRply messages. These messages are transported via either [U3] unicast requests to DAs if one is available (in the desired scope) using UDP or [U4] multicast requests if no DA is available (in the desired scope). A UA MUST [U5] perform DA discovery initially, then either periodically or passively if no DA is known, interpreting DAAdvert messages. A UA MUST also [U6] be configurable with a scope list and DA locations. A SA MUST be able to [S1] advertise a set of services, [S2] receive and process unicast and multicast SrvRqsts. A SA MUST process search filters unless it only ever advertises services without attributes. A [S3] SrvRply message is sent in reply to all SrvRqst messages, except a [S4] SAAdvert is returned for requests for the Service Agent Service Type. A SA MUST perform [S5] active DA discovery initially, then either periodically or passively, interpreting DAAdvert messages. A SA MUST [S6] register all currently advertised services with DAs as they are discovered, then periodically if appropriate, before they expire. A SA MUST be [S7] be configurable with a scope list and DA locations. A DA MUST receive and process unicast requests [D1] SrvRqst, [D2] SrvTypeRqst and [D3] AttrRqst, for which they MUST send replies [D4] SrvRply, [D5] SrvTypeRply and [D6] AttrRply, respectively. The only exception is a SrvRqst for the Directory Agent Service Type, to which the DA responds with a [D7] DAAdvert. These same DAAdverts are [D8] multicast initially and periodically. A DA MUST [D9] process SrvReg messages and cache service advertisements registered, [D10] expire cached services when lifetimes expire and [D11] process SrvDereg messages to remove specified cached services. A DA MUST be [D12] configurable with a scope list. 5.1 Transport of SLP messages SLP messages can be sent using four different transport algorithms: (1) Multicast requests soliciting unicast replies (2) Unicast UDP requests soliciting unicast UDP replies (3) TCP requests soliciting TCP replies Guttman & Kempf Expires: 18 June 2002 [Page 16] Internet Draft SLPv2 Revision December 2001 (4) Multicast unsolicited announcements The reserved listening port for SLP is 427, for both UDP and TCP. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port by UAs. Replies and acknowledgement messages MUST be sent from port 427 by SAs and DAs to the port from which the request was issued. The Previous Responder List SHOULD be used to provide a very limited form of reliable multicast. By default, this list is empty. Retransmitted requests use the same XID. This facillitates a DA or SA to briefly cache its reply to the original request and then send it again, should a duplicate request arrive. XIDs SHOULD be randomly chosen to avoid duplicate XIDs in requests if UAs restart frequently. 5.1.1 UDP message transmission The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers. Requests sent using UDP MUST NOT exceed 1400 bytes. If a SLP reply 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 receiving a truncated message MAY open a TCP connection (see section 5.1.3) with the DA or SA and retransmit the request, using the same XID. The UA MAY also attempt to make use of the truncated reply or it MAY reformulate a more restrictive request which will result in a smaller reply. UDP 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. The initial retransmission MUST occur after a CONFIG_RETRY wait period. Retransmissions MUST occur after exponentially increasing wait intervals; that is, by doubling the wait each time, or the range of a uniformly distributed random wait interval. 5.1.1.1 Multicast UDP transmission 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. 5.1.1.2 Multicast requests Multicast messages MUST set the RQST Flag in the SLP header. Multicast requests are used in three cases: Guttman & Kempf Expires: 18 June 2002 [Page 17] Internet Draft SLPv2 Revision December 2001 - Active DA Discovery (UAs and SAs MUST support this). - Active SA Discovery (UAs MAY support Active SA discovery). - Multicast Requests (UAs MUST be able to multicast SrvRqst messages to SAs, who MUST be prepared to receive and process them.) One or more replies may be sent via unicast UDP. Errors are not returned in response to multicast messages, only non-error, non-zero results. The one exception to this is a multicast AttrRqst for a service s registered without any attributes. A multicast AttrRqst for s will result in a unicast AttrRply with a NULL attribute list. 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. DAs MUST accept multicast requests as part of DA discovery (see Section 9), otherwise they accept unicast requests. Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds until a result has been obtained. 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.' The initial retransmission occurs after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals; that is,(doubling the wait each time, or the range of the uniformly distributed random wait interval. The message SHOULD be retransmitted until no further responses are elicited (see Section 4.3.1) or until CONFIG_MC_MAX seconds elapse. 5.1.1.3 Unicast UDP 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. The initial retransmission occurs after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). 5.1.2 TCP requests 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 Guttman & Kempf Expires: 18 June 2002 [Page 18] Internet Draft SLPv2 Revision December 2001 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, and the length of attribute lists 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). 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. 5.1.3 Multicast announcement Unsolicited DAAdvert messages are sent initially and periodically sent by DAs via multicast. The XID is set to 0. See Section 9.1.4. 6. Required messages 6.1 Service Request This is the primary request message in SLP. 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 | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.3.7) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.6) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList string Guttman & Kempf Expires: 18 June 2002 [Page 19] Internet Draft SLPv2 Revision December 2001 The PRList SHOULD be included. (Section 4.3 describes omitted strings). Length of Service Type, Service Type String A Service Type String MUST be included. Length of Scope List, Scope List String A Scope List MUST be included, unless the Service Type String is either the Directory Agent or Service Agent Service Type. In this case the Scope List MAY be omitted (see Section 4.3). Length of Filter, Filter String A Filter string is OPTIONAL (see Section 4.3 on omitted strings). Length of SLP SPI This field MUST be zero, the SLP SPI MUST be omitted. A DA MUST, however, be prepared to receive an SLP SPI string for backward compatibility. (See [SLPv2AS].) Response messages differ depending on the Service Type field. If the Service Type field is set to Directory Agent Service Type, DAs MUST respond to the SrvRqst with a DAAdvert (see Section 9.2.1). If the Service Type field is set to the Service Agent Service Type, SAs MUST respond with a SAAdvert (see Section 10). All other SrvRqst messages elicit a SrvRply. The Service Type field, Scope List field, and Language Tag field of the header MUST establish the base set of service advertisements over which the Filter is applied. If the Filter field is absent, the request MUST match all service advertisements having the indicated service type, scopes, and language locale. If the Filter field is present, the service query MUST be compared to each registered service, such that the language tag of the request matches the advertised service. See Sections 4.2.6 and 4.2.7 for a description of how to apply the query and Section 14 on how to apply Language Tags. Matching services are returned in the reply message. Possible error results returned in SrvRply or DAAdvert, in addition to those listed in Section 4.1 with a '*' are: LANGUAGE_NOT_SUPPORTED When the Service Type field and at least one scope from the Scope List field match, the Service Query field is not absent, but no services are advertised in the language specified in the Language Tag field of the header, though there are service advertisements registered under other language tags. MUST NOT be returned if there are no other service advertisements for the service type. MSG_NOT_SUPPORTED An SA that only accepts simple service queries receives a unicast SrvRqst including a complex search query. Guttman & Kempf Expires: 18 June 2002 [Page 20] Internet Draft SLPv2 Revision December 2001 Note that SAAdverts do not contain an error field because they are always sent in response to multicast. Error replies to multicast requests are not returned (see Section 5.1.1.2). 6.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status Code of the message (see Section 4.1 and 6.1). URL Entry Count The number of URL entry blocks following. MAY be zero. URL Entry 1 ... URL Entry N The URL Entry blocks. MUST be absent if URL Entry Count is 0. The SrvRply contains zero or more URL Entries (see Section 4.4). A SrvRply with zero URL entries MUST be returned in response to a unicast Service Reply if no matching service advertisements are present. If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless it fits entirely without truncation. If the reply overflows a datagram and the 'O' flag in the header is set, the UA MAY simply use the URL entries in the list. A URL obtained by SLP MUST NOT be cached longer than the number of seconds in the Lifetime field of the URL Entry. 6.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | (Section 4.3.1)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman & Kempf Expires: 18 June 2002 [Page 21] Internet Draft SLPv2 Revision December 2001 | length of attr-list string | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# AttrAuths = 0| +-+-+-+-+-+-+-+-+ URL-Entry A URL Entry corresponding to the service advertisement MUST be present. Length of Service Type, Service Type String The service type of the service advertisement MUST be present. Length of Scope List, Scope List The scope list of the service advertisement MUST be present. Length of Attribute List, Attribute List The attribute list of the service advertisement MAY be omitted. See Section 4.3 concerning omitted strings. Number of Authblocks This number MUST be set to 0. A DA MUST be prepared to process SrvReg messages with a nonzero value for Authblocks to support backwards compatibility with previous versions of SLP. (See [SLPv2AS]). The Lifetime of the URL Entry 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 MUST contain the names of all scopes configured for the SA. The Attribute List, if present, specifies the attributes and values to be associated with the URL by the DA. The header FRESH flag MUST be set on all registrations. A new registration received for an existing service advertisement in which the header language tag, URL, service type, and scope list all match MUST replace the previous advertisement. 6.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman & Kempf Expires: 18 June 2002 [Page 22] Internet Draft SLPv2 Revision December 2001 | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the message. A DA MUST return a SrvAck to an SA after a SrvReg or SrvDereg. The SrvAck carries only a two byte Error Code. In addition to the errors listed in Section 4.1 with a '*', the following error codes apply to SrvReg and SrvDereg messages: REFRESH_REJECTED If the 'F' flag is not set, a DA MAY reject a SrvReg. If a SrvDereg includes an attribute query, a DA SHOULD reject it. INVALID_REGISTRATION The SrvReg has problems with a non-string parameter, like a zero URL Entry Lifetime field. A SrvDereg was sent for a nonexisting service advertisement. An attempt was made to delete a service advertisement and the SrvDereg scope list contains only a partial list of the scopes in which the advertisement is registered. 6.5 Directory Agent Advertisement The DAAdvert is used for DA Discovery (see Section 9). 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 | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of List = 0 | # Authblocks = 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the message. See Section 4.1 and 6.1 for values. The Error Code is set to 0 when the DAAdvert is multicast. DA Stateless Boot Timestamp Indicates DA boot time and state. See Section 9.2 for details. Guttman & Kempf Expires: 18 June 2002 [Page 23] Internet Draft SLPv2 Revision December 2001 Length of URL, URL The DA URL MUST NOT be omitted. Length of Scope List, Scope List The Scope List string. MUST NOT be absent. This list contains the scope list of the DA, though it MAY include only the scope list present in the SrvRqst which solicited the DAAdvert. If multicast, the scope list MUST be the DA's entire configured scope list. Length of Attribute List, Attribute List The DA attribute list string MAY be omitted. See Section 9.2 for possible DA attributes. Length of SPI List, SPI List The SPI List MUST be omitted (see Section 4.3 on omitted strings). # of Auth Blocks This field MUST be set to 0. The URL is "service:directory-agent://" of the DA, where is the dotted decimal numeric address of the DA. 6.6. Service Agent Advertisement The SAAdvert is used by UAs to accumulate information about SAs on the network, see Section 10. 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 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# authblocks =0| +-+-+-+-+-+-+-+-+ Length of URL, URL The Service Agent's URL MUST NOT be omitted. Length of Scope List, Scope List The Service Agent's Scope List MUST NOT be omitted. Length of Attribute List, Attribute List The attribute list MAY be omitted only if the service agent advertises no services (see Section 10). On omitted strings, see Guttman & Kempf Expires: 18 June 2002 [Page 24] Internet Draft SLPv2 Revision December 2001 Section 4.3. # Auth Blocks This field MUST be set to 0. The SA responds only to multicast SA discovery requests which - either have an empty or one of the SA's scopes - have set to "service:service-agent". - if a is included, the SA must match it against its attributes. The SAAdvert MUST 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 attribute 'service-type' MUST be included in the attribute list. The value of this attribute is each service type the SA is advertising (not including "service:service- agent"). The URL is "service:service-agent://" of the SA, where is the dotted decimal numeric address of the SA. The of the SA MUST NOT be null. 7. Optional Features A UA or SA can be fully compliant without implementing any features from this section. A SA SHOULD, however, support responding to AttrRqst unless the SA will never be used to advertise services with attributes (see Appendix B). 7.1 SLP 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 ID The extension identifier. Next Extension Offset Number of bytes to the next extension as an offset from the beginning of the SLP message. If the Next Extension Offset field is zero, there are no extensions following the current extension, and the length of the current extension MUST be calculated by subtracting offset of the current extension from the total length of the SLP message as given in the header. Guttman & Kempf Expires: 18 June 2002 [Page 25] Internet Draft SLPv2 Revision December 2001 Extension Data The contents of the extension. If an extension offset is specified, and an extension is not included in the request, the receiver MUST respond with a PARSE_ERROR, if the request was unicast. 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: Optional to implement. Ignore if unrecognized. 0x9000-0xFFFF Reserved: Do not use. Section 13 defines procedures for specifying new SLP extensions. 7.2 Service Type Request The Service Type Request (SrvTypeRqst) allows a UA to discover all types of service on a network. 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 | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Naming Authority | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList The PRList MAY be omitted. See Section 4.3.3 and 4.3. Length of Naming Authority, Naming Authority The naming authority string MAY be omitted, in which case service types in the default naming authority (IANA) are returned. WARNING! SPECIAL CASE: If the length field is set to 0xFFFF, this indicates (1) the naming authority string is omitted, (2) all service types in all naming authorities are returned. THIS FIELD IS AN EXCEPTION TO HOW STRING LENGTHS ARE ENCODED IN SLP! Guttman & Kempf Expires: 18 June 2002 [Page 26] Internet Draft SLPv2 Revision December 2001 Otherwise, if a naming authority string is included, only service types in that naming authority are returned. Length of Scope List, Scope List Only service types advertised in a scope included in the scope list are returned. The Naming Authority string determines which service types will be returned in the reply, as described above. Possible error returns, aside from those in Section 4.1 with a '*': MSG_NOT_SUPPORTED An SA that does not support SrvTypeRqst returns this error if a SrvTypeRqst is unicast to it. 7.3 Service Type Reply The list includes all service types advertised by the DA (or SA, if the SA supports this message). 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 List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the messages. See section 4.1 and 7.3. Length of Service Type List, Service Type List The list of service types. The service type names MUST include the naming authority string, if any. This string MUST be absent if the Service Type List result is zero (see Section 4.3). 7.4 Attribute Request The Attribute Request (AttrRqst) allows a UA to discover attributes of a given service (by supplying its URL). This information is also available by using the Attrlist Extension to the SrvRqst [RFC 3059]. 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 | String \ Guttman & Kempf Expires: 18 June 2002 [Page 27] Internet Draft SLPv2 Revision December 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.5) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.6) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList The PRList MAY be omitted. See Section 4.3.3 and 4.3. Length of URL, URL The URL of the service whose attributes are being requested. MUST NOT be absent. Length of Scope List, Scope List The scope list of the service whose attributes are being requested. MUST NOT be absent. Length of Attribute Tag List, Attribute Tag List This string MAY be omitted, see Section 4.3. If present, only those attributes whose tags are present on in the list are returned in the AttrRply. Length of SLP SPI This field MUST be set to 0. A DA MUST be able to process a request with a non-zero SLP SPI, for backwards compatibility with previous versions of SLP. The indicates the attributes to return in the AttrRply. [EDITOR: Do we continue to support wildcards in attribute tag lists?] Possible error returns, aside from those in Section 4.1 with a '*': LANGUAGE_NOT_SUPPORTED When the URL and at least one scope in the Scope list fields match an advertised service, but there are no attributes registered under the requested Language Tag, this error is returned. MSG_NOT_SUPPORTED An SA which does not support AttrRqst and receives a unicast AttrRqst anyway, will respond with this error. INVALID_REGISTRATION The URL in the AttrRqst does not correspond to a service which the SA or DA is advertising. An SA returns these errors only if an AttrRqst is unicast. Guttman & Kempf Expires: 18 June 2002 [Page 28] Internet Draft SLPv2 Revision December 2001 7.5 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# Authblocks =0| +-+-+-+-+-+-+-+-+ Error Code Status code of the message. See section 4.1 and 7.5. Length of Attribute List, Attribute List This field is omitted if the status code of the result is not 0 or the service requested has no attributes associated with it. # Authblocks This field MUST be set to 0. WARNING! SPECIAL CASE: A SA (which supports AttrRqst) MUST return an AttrRply in response to a multicast AttrRqst for a service advertisement if the attribute list is an empty strin. THIS IS UNLIKE SrvTypeRply and SrvRply WHERE ONLY NONZERO RESULTS ARE RETURNED IN RESPONSE TO MULTICAST QUERIES. Attribute replies SHOULD be returned with the original case of the string registration intact, as they are likely to be human readable. 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)". 7.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman & Kempf Expires: 18 June 2002 [Page 29] Internet Draft SLPv2 Revision December 2001 | Length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Entry (Section 4.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Scope List, Scope List MUST NOT be omitted. URL Entry The URL of the service to deregister. The URL in the entry MUST NOT be omitted. The lifetime in the URL Entry is ignored. Length of Attribute Tag List This field MUST be 0. A DA MUST be prepared to accept and process a Attribute Tag List string for backward compatibility with previous versions of SLP [SLPv2AS]. See section 4.3 on omitted strings. The URL indicates which service advertisement to deregister. This deregistration will remove all service advertisements associated with the URL, irregardless of the scope, language tag or service type it the service advertisements were registered with. The SA MUST deregister all services with the same scope list used to register the service with the DA. If this is not done in the SrvDereg message, the DA MUST return a SCOPE_NOT_SUPPORTED error. DA acknowledges a SrvDereg with a SrvAck. Once the SA receives an acknowledgment indicating success, the service is no longer advertised by the DA. Possible error codes beyond those in Section 4.1 marked with a '*': INVALID_REGISTRATION A DA sends this error if the SrvDeReg seeks to deregister a service which has not been registered with the DA. INVALID_UPDATE A DA sends this error in response to a non-zero Attribute Tag List Length. 8. Scope list configuration The default scope list configuration for any agent is the string "DEFAULT". All SLP Agents MUST support static configuration of a scope list. Other mechanisms are optional. These options are in prioritized order. If a static scope list exists, DHCP option 79 is ignored, for example. Guttman & Kempf Expires: 18 June 2002 [Page 30] Internet Draft SLPv2 Revision December 2001 Preference Mechanism Requirement level (1) Static configuration of scope list MUST (2) Static configuration of DAs * MUST (3) DHCP SLP Scope configuration SHOULD (4) DHCP SLP DA configuration * SHOULD (5) Dynamic discovery (DAAdverts) ** MAY (6) Dynamic discovery (SAAdverts) ** MAY (7) Use of the scope "DEFAULT" MUST (2) A SA or UA with a static configured list of DAs will unicast DA Discovery messages (see Section 9) to the DAs on the list and create a list of all scopes those DAs support. This forms the agent's scope list. (3) DHCP option 79 can explicitely configure a UA or SA's scope list. [RFC 2610] (4) DHCP option 78 can supply a list of DA locations. The UA or SA acquires their scope list, as per (2), above. [RFC 2610] (5) A UA or SA can use active and passive DA Discovery (see Section 9) to acquire a list of DAs. The combined list of their scopes forms the agent's scope list. (6) A UA can use active SA discovery (see Section 10) to obtain SAAdverts from SAs on the network. The combined list becomes the UA's scope list. UAs can issue requests with any subset of scopes they are configured with. It is left up to the implementator whether to enable clients to synthesize their own scope lists (by using DA and SA discovery) or only to support static and DHCP discovery. 9. Directory Agent Discovery UAs and SAs MUST attempt to discover DAs unless specifically configured not to do so. UAs and SAs MUST perform active DA discovery initially, upon initialization. SAs MUST and UAs SHOULD perform passive DA discovery (UAs MAY instead periodically perform active DA discovery, for example, before requests are made, after [CONFIG_DA_FIND] seconds). 9.1 Active DA discovery 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 MUST contain all scopes configured for the UA or SA which is discovering DAs. If the UA or SA has not scope list, Guttman & Kempf Expires: 18 June 2002 [Page 31] Internet Draft SLPv2 Revision December 2001 however, the used in active DA discovery MAY be empty. This allows the UA or SA to derive a scope list from DAAdverts it receives. 9.2 Passive DA discovery 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. An unsolicited DAAdvert has an XID of 0. All UAs and SAs that receive the unsolicited DAAdvert SHOULD examine the DAAdvert DA Stateless Boot Timestamp. If the Stateless Boot Timestamp is zero, the DA is going down and no further messages should be sent to it. If a UA receives a DAAdvert which supports any scope on its scope list, it adds this DA to the list of DAs it can send requests to. If a SA detects a DAAdvert with a nonzero DA Stateless Boot Timestamp but the SA has never encountered the DA before, the SA MUST send SrvRegs for all services advertised by the DA if examination of the DAAdvert fields indicate the SA must register. The SA 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, and if the DA supports some set of scopes with which the SA is configured, the SA registers with the DA. SAs MUST wait a random interval between 0 and CONFIG_REG_PASSIVE before beginning DA registration. 9.3 Directory Agent Attributes DAs may advertise attributes. One attribute is defined by SLPv2. 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 or SrvDereg for a particular service is 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. Guttman & Kempf Expires: 18 June 2002 [Page 32] Internet Draft SLPv2 Revision December 2001 10. Service Agent Discovery A User Agent MAY, in the absence of knowledge of DAs, and other scope list configuration, obtain SAAdverts from SAs on the network. This allows the UA to synthesize a scope list it can use to issue requests. The SAAdverts may carry other information of potential use (their location and attribute list, see Section 6.6). A SA MAY be configured with attributes, and MUST support the attribute 'service-type' whose value is all the service types of services represented by the SA. Further, SAs which support only simple search filters MUST include the attribute "simple-query- only=true" in their attribute list. SAs MUST NOT respond if the SrvRqst predicate is not satisfied. For example, only SAs advertising 'nfs' services MUST respond with a SAAdvert to a SrvRqst for service type "service:service-agent" which includes a predicate "(service-type=nfs)". Further, a UA which requires the use of complex search filters could discover whether SAs which support it and the service type desired. 11. 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 & Kempf Expires: 18 June 2002 [Page 33] Internet Draft SLPv2 Revision December 2001 12. Optional Configuration Broadcast Only Any SLP agent SHOULD be configurable to use broadcast only. 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 may result in UAs obtaining different results for the identical requests depending on where they are connected to the network. Timing Values Time values in Section 11 MAY be configurable. Scopes The Scope list string must be configurable. DHCP Configuration DHCP options 78 and 79 may be used to configure SLP. [RFC 2610] Service Templates Service Template UAs and SAs MAY be configured by using Service Templates. These allow language translation, setting default values and API error checking. 13. IANA Considerations SLP includes four sets of identifiers which may be registered with IANA. The policies for these registrations (See [RFC 2434]) are noted in each case. 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 [RFC 2609]. These are standardized by review of a Designated Expert and a mailing list (See [RFC 2609].) 14. Internationalization Considerations SLP messages support the use of multiple languages by providing a Language Tag field in the common message header (see Section 8). Language Tags are compared for case insensitive equality. If a service advertisement's Language Tag doesn't match a request's the strings in the advertisement are considered unintelligible to the Guttman & Kempf Expires: 18 June 2002 [Page 34] Internet Draft SLPv2 Revision December 2001 requester. Services SHOULD be registered in English 'EN', the default language. 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 [RFC 2609] defines the attribute values to be 'literal'. 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 [RFC 2609] 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. 15. Security Considerations The threats posed to clients using SLP to locate services and services which use SLP to advertise themselves are threefold. First, a UA may be prevented from discovering a service which is present and should in fact be discoverable. SLP is vulnerable to denial of service attacks by (a) an attacker posing as a DA which withholds normally available service information, (b) an attacker actively deregistering services with DAs which should otherwise be available. Second, a UA may discover a service which is not 'trustworthy' according to some policy of trust in an administered network. This is a masquerading attack. A user could be fooled into revealing confidential information in interactions with a service registered by an attacker. Third, an attacker could use SLP to catalogue either clients or services on a network by observing and issuing SLP queries. The threat here is breach of confidentiality: An attacker can learn what services the user likes to use and what services are present on the network. This information could be useful to an attacker, for example, to inform her how of what software to launch further attacks on. Previous versions of SLP provided for authentication of service URLs Guttman & Kempf Expires: 18 June 2002 [Page 35] Internet Draft SLPv2 Revision December 2001 and service attributes. See [SLPv2AS]. This was not adopted, as it required SLP-specific key management. This version of SLP does not provide an intrinsic security mechanism to counter the security threats described above. Instead, SLP agents use IPsec security associates for unicast messages to provide the necessary protections. Multicast requests are considered to be insecure. The following policies will protect unicast SLP traffic: 1. Messages unicast from SAs and DAs (from port 427) SHOULD initiate an IKE establishment of a security association. This will occur when - An SA or DA responds to a UA request - An SA registers or deregisters with a DA 2. Those hosts which receive unicast SLP messages (from port 427) SHOULD have a policy requiring the initiation of a IPsec security association. This will occur when - A UA receives a reply from a DA or SA - A SA receives a SrvAck from a DA - A DA receives a SrvReg or SrvDereg from a SA 3. IKE security association establishment for use with SLP MUST be predicated on possession of a certificate indicating that a host is a legitimite source of SLP messages. This requires distribution of certificates to all SLP agents, signed by a certificate authority operated by a trusted administration. During IKE security association establishment, certificates are verified versus the certificate authority's public key. If verified, the SA can be established and messages transmitted will be protected against the attacks listed above. 4. SLP messages which cannot be validated against an IPsec Authentication Header (AH) SHOULD be silently discarded. 5. For environments where confidentiality is desired, SLP messages MAY be protected by an IPsec Encapsulating Security Payload (ESP). The security provided by the above policy is no replacement for application level security. That is, even if SLP can be protected against denial of service, masquerading and catalog attacks, this does no substitute for client-server protocol security appropriate to satisfy the application's own security requirements. 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 secure SLP. Guttman & Kempf Expires: 18 June 2002 [Page 36] Internet Draft SLPv2 Revision December 2001 Appendix A: Changes to SLPv2 compared to RFC 2608 This appendix outlines changes to SLPv2 from RFC 2608. [SLPv2AS] presents the details and backward compatibility issues concerning this specification compared to previous versions of SLP. - Agents SHOULD implement PR lists. In RFC 2608 this was REQUIRED. - UAs SHOULD NOT send complex search filters. SAs MAY support only simple search filters. In RFC 2608, no distinction was made. - All unicast replies and acknowledgements as well as SrvReg and SrvDereg MUST be sent from port 427. Previously SAs and DAs could send these messages from an ephemeral port. - SLP Authentication Blocks and SLP SPI fields MUST be zero. (Support for SLP authentication has been deprecated). Instead IPsec SHOULD be used to authenticate or encrypt SLP replies, SrvAck, SrvReg and SrvDereg. - Any character may be escaped in SLP strings, not only reserved ones. [EDITOR: COMPLETE THIS LIST] Appendix B: SA support for Attributes Some special purpose SAs which will only ever advertise services without attributes need not implement SrvRqst search filters or respond to AttrRqst with an AttrRply. All other SAs need to. This is the meaning of the statement SAs SHOULD reply to AttrRqst messages. References [FIPS] National Institute of Standards and Technology. Digital signature standard. Technical Report NIST FIPS PUB 186, U.S. Department of Commerce, May 1994. [IANA] http://www.iana.org/numbers.html [IPSEC] EDITOR: Add references for IKE, AH and ESP. [LDAPv3] EDITOR: Add this reference, for the string comparison rule used in SLP. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC 2254] Howes, T., "The String Representation of LDAP Search Guttman & Kempf Expires: 18 June 2002 [Page 37] Internet Draft SLPv2 Revision December 2001 Filters", RFC 2254, December 1997. [RFC 2279] Yergeau, F., "UTF-8, a transformation format of unicode and ISO 10646", RFC 2279, October 1998. [RFC 2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998. [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", RFC 2608, July 1999. [RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999. [RFC 2610] Guttman, E., "DHCP Options for Service Location", draft- guttman-svrloc-rfc2610bis-01.txt, September 2001. A work in progress. [RFC 3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. Editors' Contact Information Erik Guttman James Kempf Sun Microsystems, Inc. Docomo Labs, USA Phone: +49 172 865 5497 Phone: EDITOR: ADD JIM'S PHONE # Email: Erik.Guttman@Sun.Com Email: kempf@docomolabs-usa.com Full Copyright Statement Copyright (C) The Internet Society (2001). 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 Guttman & Kempf Expires: 18 June 2002 [Page 38] Internet Draft SLPv2 Revision December 2001 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." Table of Contents Abstract . . . . . . . . . . . 1 6.4 Service Acknowledgment . . 22 Acknowledgements . . . . . . . 1 6.5 Directory Agent 1. Introduction . . . . . . . 1 Advertisement . . . . . . 23 2. Terminology and Conventions 2 6.6. Service Agent 3. Protocol Overview . . . . . 3 Advertisement . . . . . . 24 3.1 SLP Message Types . . . . 5 7. Optional Features . . . . . 25 4. Protocol Elements . . . . . 6 7.1 SLP Extensions . . . . . . 25 4.1 SLP Message Header . . . . 6 7.2 Service Type Request . . . 26 4.2 Error Codes . . . . . . . 7 7.3 Service Type Reply . . . . 27 4.3 Strings . . . . . . . . . 9 7.4 Attribute Request . . . . 27 4.3.1 General String Comparison 9 7.5 Attribute Reply . . . . . 29 4.3.2 Lists . . . . . . . . . 9 7.6 Service Deregistration . . 29 4.3.3 Previous Responder List 9 8. Scope list configuration . 30 4.3.4 Service Type String . . 10 9. Directory Agent Discovery . 31 4.3.5 Scope List . . . . . . . 11 9.1 Active Discovery . . . . . 31 4.3.6 Attribute List . . . . . 11 9.2 Passive Discovery . . . . 32 4.3.7 Search Filter . . . . . 14 9.3 Directory Agent Attributes 32 4.3.8 Attribute Tag List . . . 15 10. Service Agent Discovery . 33 4.3.9 SLP SPI . . . . . . . . 15 11. Protocol Timing Defaults . 33 4.4 URL Entry . . . . . . . . 15 12. Optional Configuration . . 34 5. Required Features . . . . . 16 13. IANA Considerations . . . 34 5.1 Transport of SLP messages 16 14. Internationalization 5.1.1.1 Multicast transmission 17 Considerations . . . . . . 34 5.1.1.2 Multicast Requests . . 17 15. Security Considerations . 35 5.1.1.3 Unicast Requests . . . 18 Appendix A: Changes to SLPv2 5.1.2 TCP Requests . . . . . . 18 compared to RFC 2608 . . . 37 5.1.3 Multicast Announcement . 19 Appendix B: SA support for 6. Required Messages . . . . . 19 Attributes . . . . . . . . 37 6.1 Service Request . . . . . 19 References . . . . . . . . . . 37 6.2 Service Reply . . . . . . 21 Editors' Contact Information . 38 6.3 Service Registration . . . 21 Full Copyright Statement . . . 38 Guttman & Kempf Expires: 18 June 2002 [Page 39]