Internet Engineering Task Force                             Erik Guttman
INTERNET DRAFT                                           Charles Perkins
21 June 1998                                            Sun Microsystems
                                                           John Veizades
                                                           @Home Network
                                                             Michael Day

                  Service Location Protocol, Version 2

Status of This Memo

   This document is a submission by the Service Location Working Group
   of the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).


   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

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page i]

Internet Draft          Service Location Protocol           21 June 1998


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1
     1.1. Applicability Statement . . . . . . . . . . . . . . . . .    2
     1.2. Changes to the Service Location Protocol from v1 to v2  .    2

 2. Terminology                                                        3
     2.1. Notation Conventions  . . . . . . . . . . . . . . . . . .    3

 3. Protocol Overview                                                  4

 4. URLs used with Service Location                                    5
     4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . .    6
     4.2. Naming Authorities  . . . . . . . . . . . . . . . . . . .    7
     4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . .    7

 5. Service Attributes                                                 7

 6. Required Features                                                  9
     6.1. Use of Ports, UDP, and Multicast  . . . . . . . . . . . .   10
     6.2. Use of TCP  . . . . . . . . . . . . . . . . . . . . . . .   11
     6.3. Retransmission of SLP messages  . . . . . . . . . . . . .   12
     6.4. Strings in SLP messages . . . . . . . . . . . . . . . . .   12

 7. Errors                                                            13

 8. Required SLP Messages                                             14
     8.1. Service Request . . . . . . . . . . . . . . . . . . . . .   15
     8.2. Service Reply . . . . . . . . . . . . . . . . . . . . . .   17
     8.3. Service Registration  . . . . . . . . . . . . . . . . . .   18
     8.4. Service Acknowledgment  . . . . . . . . . . . . . . . . .   19
     8.5. Directory Agent Advertisement . . . . . . . . . . . . . .   19
     8.6. Service Agent Advertisement . . . . . . . . . . . . . . .   20

 9. Optional Features                                                 21
     9.1. Service Location Protocol Extensions  . . . . . . . . . .   21
     9.2. Authentication Blocks . . . . . . . . . . . . . . . . . .   22
           9.2.1. MD5 with RSA in Authentication Blocks . . . . . .   23
           9.2.2. DSA with SHA-1 in Authentication Blocks . . . . .   24
           9.2.3. Keyed HMAC with MD5 in Authentication Blocks  . .   24
     9.3. Authentication of a SrvRply . . . . . . . . . . . . . . .   25
     9.4. Incremental Service Registration  . . . . . . . . . . . .   25
     9.5. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . .   25

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page ii]

Internet Draft          Service Location Protocol           21 June 1998

10. Optional SLP Messages                                             26
    10.1. Service Type Request  . . . . . . . . . . . . . . . . . .   26
    10.2. Service Type Reply  . . . . . . . . . . . . . . . . . . .   27
    10.3. Attribute Request . . . . . . . . . . . . . . . . . . . .   27
    10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . .   28
    10.5. Attribute Request/Reply Examples  . . . . . . . . . . . .   29
    10.6. Service Deregistration  . . . . . . . . . . . . . . . . .   30

11. Scopes                                                            31
    11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . .   31
    11.2. Administrative and User Selectable Scopes . . . . . . . .   32
    11.3. Protected Scopes  . . . . . . . . . . . . . . . . . . . .   32

12. Directory Agents                                                  32
    12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . .   33
    12.2. Directory Agent Discovery . . . . . . . . . . . . . . . .   34
          12.2.1. Active DA Discovery . . . . . . . . . . . . . . .   34
          12.2.2. Passive DA Advertising  . . . . . . . . . . . . .   34
    12.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . .   35
    12.4. DA Scope Configuration  . . . . . . . . . . . . . . . . .   35
    12.5. DAs and Authentication Blocks . . . . . . . . . . . . . .   35

13. SLP Protocol Extensions                                           36
    13.1. Required Attribute Missing Option . . . . . . . . . . . .   36
    13.2. Cryptographic Request Option  . . . . . . . . . . . . . .   36

14. Protocol Timing Defaults                                          37

15. Optional Configuration                                            38

16. IANA Considerations                                               39

17. Internationalization Considerations                               39

18. Security Considerations                                           40

19. Acknowledgments                                                   41

20. Full Copyright Statement                                          41

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

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 1]

Internet Draft          Service Location Protocol           21 June 1998

   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

   This document specifies the Service Location Protocol (SLP) in
   two main 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

1.2. Changes to the Service Location Protocol from v1 to v2

   SLP version 2 (SLPv2) corrects race conditions present in SLPv1.
   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 reduced the number of 'required features.'  SLPv2 clarifies
   and changes the use of 'Scopes', eliminating support for 'unscoped
   directory agents' and 'unscoped requests'.  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

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 2]

Internet Draft          Service Location Protocol           21 June 1998

   the absence of administrative configuration and DAs.  This was not
   possible in SLPv1.

   SLPv2 is incompatible in some respects with SLPv1.  If a DA supports
   both SLPv1 and SLPv2 with the same scope, services advertised by SAs
   using either version of the protocol will be available to both SLPv1
   and SLPv2 UAs.

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 [9].

      SLPv1     The version of SLP specified in RFC 2165 [22].

2.1. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119  [10].

      Syntax        Syntax for string based protocols follow the
                    conventions defined for ABNF [13].

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 3]

Internet Draft          Service Location Protocol           21 June 1998

      Strings       All strings are encoded using the UTF8 [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.

3. Protocol Overview

   SLP allows client applications to discover services.  To do this,
   User Agents issue a SrvRqst message specifying the characteristics
   of the desired service.  The service is advertised by a Service
   Agent, automatically.  The User Agent receives a Service Reply
   which contains enough information for the client to make use of the

   SLP is a request-reply protocol; in a typical operation a User Agent
   (UA) issues a request for service information and awaits one or more
   replies containing the requested information.

   Services on a particular host are represented by a Service Agent
   (SA). The SA takes care of advertising the services using SLP.

   A Directory Agent (DA) serves as a central clearinghouse of
   information for SLP. Service advertisements are registered by SAs
   with DAs.  UAs make requests of DAs that they either discovered or
   are configured to use.  DAs announce themselves using 'Directory
   Agent Advertisements' or DAAdvert messages.

   Depending on the environment, replies will be sent to the UA by a SA
   or a DA. For smaller environments, SLP allows a simple deployment
   consisting only of UAs and SAs.  For larger environments, SLP allows
   the collection of service configuration data at one or more DAs.

                      Wants this information:
   Client Application - - - - - - - - - - - -> Service
        USES                                     USES
      User Agent -----------------------+--> Service Agent
                 Request                |    ^       | (Request: SrvReg
                                        |    |       |  Reply:   SrvAck)
                 Reply or DAAdvert      |   DAAdvert v
                 <--------------------  +---> Directory Agent

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 4]

Internet Draft          Service Location Protocol           21 June 1998

   The above diagram illustrates the relationship between SLP agents.
   The UA either multicasts requests to SAs or unicasts them to DAs.
   Replies are unicast.  DAs multicast DAAdvertisements which are
   received by both UAs and SAs.

   SLP Messages are typically transmitted in datagrams using UDP/IP.
   Requests may be unicast, multicast, or broadcast.  When a UA
   multicasts or broadcasts a request, it MAY receive more than one
   reply.  Such replies must be unicast.  Requests which do not fit into
   a datagram MUST be sent using TCP. If a reply cannot fit within a
   datagram, the UA MAY reissue the request using TCP.

   Strings called 'scopes' are associated with sets of services
   and assigned to SLP agents.  Scopes are used to increase the
   protocol scalability.  A UA will only discover services in scopes
   it is configured to use.  This allows 'administrative service
   provisioning'.  A scope is called 'protected' if it is associated
   with a particular mechanism for authentication (see section 11).

   There are required and optional messages in SLP. The only required
   request to implement is the Service Request (which discovers service
   instances).  Optional requests include the Service Type Request
   (which discovers all service types supported on the network) and
   Attribute Request (which discovers all attributes of a given service
   or of a type of service).  These optional requests enable 'service
   browser' applications to be built using SLP.

   Hosts may be configured statically or by using DHCP options 78 and 79
   to issue requests to specific scopes or DAs.  Otherwise, SLP allows
   a host to "bootstrap" itself, beginning with no knowledge of any
   services or SLP agents beyond its own UA. To bootstrap itself, the
   host must multicast or broadcast its first request.

   A SLPv2 implementation MAY support SLPv1 [22].

4. URLs used with Service Location

   A Service URL indicates the location of a service.  This URL may be
   of the service: scheme [14] (reviewed in section 4.1), or any other
   URL scheme conforming to the URL standard [9], except that URLs
   without address specifications SHOULD NOT be advertised by SLP. The
   service type for an arbitrary URL is typically its scheme name.  For
   example, the service type string for "" would be

   Reserved characters in URLs follow the rules in [9].

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 5]

Internet Draft          Service Location Protocol           21 June 1998

4.1. Service: URLs

   Service URL syntax and semantics are defined in [14].  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

   A Service URL may be of the form:


   The Service Type of this service: URL is defined to be the string up
   to (but not including) the final `:'  before <addrspec>, the address

   <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.  An http service on a nonstandard port could be

   Service Types SHOULD be defined by a "service template" [14], which
   provides expected attributes, values and protocol behavior.  An
   abstract service type (also described in [14]) has the form


   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, and service:x.two
   are different service types, as are and

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 6]

Internet Draft          Service Location Protocol           21 June 1998

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  [14] 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

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 7]

Internet Draft          Service Location Protocol           21 June 1998

   with schemes other than "service:" MAY be registered with attributes.
   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 [13] 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 = `\' HEXDIGIT HEXDIGIT
   bad-tag = CR / LF / HT / `_'
    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
                   UTF8 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,Perkins,Veizades,Day      Expires 21 December 1998      [Page 8]

Internet Draft          Service Location Protocol           21 June 1998

   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

   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

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

   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. A 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 once every CONFIG_DA_FIND seconds.

    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.

Guttman,Perkins,Veizades,Day      Expires 21 December 1998      [Page 9]

Internet Draft          Service Location Protocol           21 June 1998

   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
       explicitely set to NO SCOPE for UAs, if the User Selectable Scope
       model is used.  See section 11.2.

    3. In the absense 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

   The Service Location Protocol uses multicast 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
   from which the request was issued.  The default maximum transmission
   unit for UDP messages is 1400 bytes.

   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  The default
   TTL to use for multicast is 32.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 10]

Internet Draft          Service Location Protocol           21 June 1998

   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 to use of Service Location on isolated networks.

   Setting multicast TTL to less than 32 (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

   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

   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 14 for timing

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 11]

Internet Draft          Service Location Protocol           21 June 1998

6.3. Retransmission of SLP messages

   Requests to SAs are multicast repeatedly (with a recommended wait
   interval of CONFIG_MC_RETRY) until there are no new responses, or
   CONFIG_MC_MAX seconds have elapsed.  DA discovery requests use
   different timing for repeated requests, CONFIG_DA_RETRY.

   Multicast requests SHOULD be reissued over 15 seconds (say 3 times
   total) until a result has been obtained.  UAs need only wait till
   they obtain the first reply which matches their request.  Unicast
   requests (SrvReg or SrvRqst) to a DA should be retried until either
   a response (which might be an error) has been obtained, or for 5

   When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
   they contain a <PRList> of previous responders.  Initially the
   <PRList> is empty.  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.
   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.'

   Any DA or SA which sees its address in the <PRList> MUST NOT respond
   to the request.

   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
   duplicate XIDs in requests if UAs restart frequently.

6.4. Strings in SLP messages

   The escape character is a backslash (UTF8 0x5c) followed by the
   two hexadecimal digits of the escaped character.  Only reserved
   characters are escaped.  For example, a comma (UTF8 0x29) is escaped
   as `\29'.  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.

   String comparison for order and equality in SLP MUST be case
   insensitive inside the 0x00-0x7F subrange of UTF8 (which corresponds
   to ASCII character encoding) Case insensitivity SHOULD be supported
   throughout the entire UTF8 encoded Unicode [6] character set.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 12]

Internet Draft          Service Location Protocol           21 June 1998

   White space (SPACE, CR, LF, TAB) internal to a string value is folded
   to a single SPACE character for the sake of string comparisons.  For
   example, "  Some String  " matches "SOME    STRING".

   String comparisons (using comparison operators such as `<=' or `>=')
   are done using lexical ordering in UTF8 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.

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 13.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
   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 a
         cryptographic algorithm or key generation it cannot support.
         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.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 13]

Internet Draft          Service Location Protocol           21 June 1998

8. Required SLP Messages

   SLP messages all begin with the following 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    |  Function-ID  |            Length             |
     | Length, contd.|O|U|A|F|R| rsvd|       Language Tag Length     |
     |    Next Extension Offset      |              XID              |
     |                         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.  URLSIG (0x40) is set by
       a SA when it registers a signed URL with a DA or a signed URL
       is passed in a SrvRply to a UA. ATTRSIG (0x20) is set by a SA
       when signed attributes are registered with a DA. FRESH (0x10)
       is set on every new SrvReg.  REQUEST MCAST (0x08) is set when
       multicasting or broadcasting requests.  Rsvd bits MUST be 0.
     - Lang Tag Length indicates the length of the Language Tag field.
     - Next Extension Offset is set to 0 unless extensions are used.
       The first extension begins at 'offset' bytes, from the message's
       beginning, after the SLP message data.  See Section 9.1 for how
       to interpret unrecognized options.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 14]

Internet Draft          Service Location Protocol           21 June 1998

     - 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.
     - 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].

   If a flag indicates an authentication block will follow, or an option
   is specified, and these fields are 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>  \

   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 either fully qualified domain names or 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>.  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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 15]

Internet Draft          Service Location Protocol           21 June 1998

   list will respond.  DAs and SAs MUST reply to unicast requests with a
   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.)

   The <predicate> is a LDAPv3 search filter [15].  This field may be
   omitted if services are to 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 can ONLY 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

      <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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 16]

Internet Draft          Service Location Protocol           21 June 1998

      <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

               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> SHOULD contain all scopes configured
               for the service.  If omitted, see Section 11.2.  For

      <t>=service:directory-agent  <s>=DEFAULT  <p>=
               This returns DAAdverts for all DAs in the DEFAULT scope.

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 one or more URL entries (see Section 4.3)
   that satisfy a SrvRqst.  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.  In that case, the cache
   lifetime is indicated by the Timestamp in the URL Authenticator
   (see Section 9.2).  One authentication block is returned for each
   protected scope the service was registered in which was present in
   the <scope-list> of the SrvRqst.  If a SrvRply is sent by UDP,
   a URL Entry MUST NOT be included unless it fits entirely without

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 17]

Internet Draft          Service Location Protocol           21 June 1998

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

   The <service-type> defines the service type of the URL to be
   registered, regardless of the scheme of the URL. The <scope-list>
   MUST be contain the names of all scopes configured for the SA. The
   default value is "DEFAULT" (see Section 11).  The <attr-list>, if
   present, specifies the attributes and values to be associated with
   the URL by the DA (see Section 5).

   If the registration occurs in a protected scope, the ATTRSIG flag is
   set in the header, and an Authentication block (see Section 9.2) is
   included for each protected scope, for each Key Generation Number
   supported.  It is calculated over the ordered tuple (16-bit length of
   <attr-list>, <attr-list>, timestamp, 16-bit length of scope string,
   scope string), where the timestamp is taken from the Authentication

   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.4).

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 18]

Internet Draft          Service Location Protocol           21 June 1998

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 = 4)      |
     |          Error Code           |

   A DA returns a SrvAck to an SA after a SrvReg.  It carries only a two
   byte Error Code (see Section 7).

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)      |
     |                  DA Stateless Boot Timestamp                  |
     |         Length of URL         |              URL              \
     |     Length of <scope-list>    |         <scope-list>          \
     | # Auth Blocks |         Authentication block (if any)         \

   DAs respond with DAAdverts only to SrvRqsts with the MCAST RQST
   flag set.  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.2.2).

   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 DAAdvert MAY contain a URL authenticator, which will be generated
   using a DA Advertising private key.  This authenticator is calculated
   over the following ordered tuple:  (DA Stateless Boot Timestamp,
   Length of URL, URL, Length of <scope-list>, <scope-list>,
   Timestamp), where the Timestamp is taken from the Authentication
   block.  The Protected Scope String of the authentication block is
   omitted in a DAAdvert (i.e., the Protected Scope String Length is
   zero).  The Authenticator Timestamp is set to the time when the
   DAAdvert expires (may no longer be cached).

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 19]

Internet Draft          Service Location Protocol           21 June 1998

   If multiple Key Generation Numbers are supported for DAAdvert
   authenication, the DA MUST include one Authentication Block for each
   generation number.  See Section 9.2.

   UAs SHOULD be configured with DA Advertisement public keys so they
   can verify the authenticity of DAAdverts.  If the UA detects a
   authentication failure of the DAAdvert, 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
   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

      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>          \
     | # 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 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 a URL Authentication block for each protected
   scope the SA supports.  If the UA can verify the protected scope

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 20]

Internet Draft          Service Location Protocol           21 June 1998

   SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard

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.

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          |       Extension Length        |
     |                         Extension Data                        \

   The offset to next extension is 0 if there are no extensions
   following or is set to the length of the current Extension Data.
   If the offset is 0, the length of the current Extension Data is
   determined implicitly by use of the total length of the SLP message
   as given in the SLP message header.

   Extension IDs are assigned in the following way:

   0x0000-0x3FFF Standardized.  Optional to implement.  Ignore if
   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.

   Extensions defined in this document are in Section 13.  See
   section 16 for procedures that are required when specifying new SLP

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 21]

Internet Draft          Service Location Protocol           21 June 1998

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  |
     |     Key Generation Number     | Protected Scope String Length |
     \                   Protected Scope String                      \
     |                           Timestamp                           |
     |              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 even for protected
   scopes, the case of the registration data has to be preserved by the
   registering DA so that UAs will be able to verify the authentication

   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 Key Generation Number (KGN) identifies the 'generation' of the
   key associated with the Protected Scope string which follows.  The
   value 0 MUST NOT be used and the values 1-255 are reserved.

   There may be several 'key generations' deployed in a network
   simultaneously.  This allows gradual rekeying of a network.  For
   example, a network is keyed with keys for protected scope 'foo'
   with KGN 1022.  Later, SAs are rekeyed to also have KGN '1023'.
   Eventually, when all UAs and DAs in the network are rekeyed with keys
   with KGN '1023', SAs need no longer support KGN '1022' keys.

   A SA which supports multiple KGNs for a protected scope MUST register
   Authentication Blocks generated with each KGN with DAs.  DAs and SAs
   MUST include authentication blocks in each KGN associated with a

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 22]

Internet Draft          Service Location Protocol           21 June 1998

   protected scope unless the UA which initiated the request includes a
   Cryptographic Request Option specifying a particular KGN.

   Note that many SLP messages are sent using UDP datagrams.  These have
   a limited payload so few Authentication Blocks will fit into a SLP
   message.  For this reason, as few Key Generations as possible should
   be supported simultaneously:  Ideally only ONE should be used except
   during transitions.

   The Protected scope string identifies the keying material to be
   used by agents to verify the signature data in the Structured
   Authentication Block.

   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 1900, in
   NTP format [18].  SAs and DAs MAY use this value to indicate how
   long they expect the service to be available for (for instance, in
   DAAdverts and SAAdverts).

   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

9.2.1. MD5 with RSA in Authentication Blocks

   BSD=0x0001 indicates that md5WithRSAEncryption is selected as the
   authentication algorithm for the Structured Authentication Block.
   The Authentication Block will start with the ASN.1 Distinguished
   Encoding (DER) [11] for "md5WithRSAEncryption", which has as its
   value the bytes (MSB first in hex):

      "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00"

   This is then immediately followed by an ASN.1 Distinguished Encoding
   (as a "Bitstring") of the RSA encryption (using the protected
   scope's private key) of a bitstring consisting of the OID for "MD5"
   concatenated by the MD5 [21] message digest computed over the fields
   above.  The exact construction of the MD5 OID and digest can be found
   in RFC 1423 [8].

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 23]

Internet Draft          Service Location Protocol           21 June 1998

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

        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 [12], [2], [3], [4], [5].

9.2.3. Keyed HMAC with MD5 in Authentication Blocks

   BSD=0x0003 is defined to be HMAC [16] using keyed-MD5 [21].

   Given a secret key K and the data to authenticate, the Authentication
   Block is computed as follows:
    1. opad := 0x36363636363636363636363636363636 (128 bits)
    2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
    3. zero_extended_key := K extended by zeroes to be 128 bits long
    4. opadded_key := zero_extended_key XOR opad
    5. ipadded_key := zero_extended_key XOR ipad
    6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))

   The authenticator is the 128-bit value HMAC_result.

   Note that this authentication scheme works for peer-to-peer
   implementations (where hosts can both verify and generate
   authenticators) but not for client-server applications where clients
   are NOT trusted to create authenticators for services of a protected
   scope.  In this case, public key cryptography is used.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 24]

Internet Draft          Service Location Protocol           21 June 1998

9.3. Authentication of a SrvRply

   A SrvRply containing a URL from a service in a protected scope MUST
   include an Authentication Block for each protected scope.  The
   Authentication data MUST be calculated over the following ordered
   tuple:  (Length of URL, URL, Timestamp, 16-bit Length of Scope
   String, Scope String).  The Authentication block is calculated
   according to the algorithm indicated by the BSD value using the
   cryptographic key identified by the protected scope string and Key
   Generation Number in the Authentication Block.

9.4. Incremental Service Registration

   Incremental registrations update attribute values for a previously
   registered service.  Incrmental 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.

   For example, suppose service:x:// has been registered with
   attributes A=1, B=2, C=3.  If an incremental registration comes for
   service:x:// 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 in protected scopes.  These must be registered with
   ALL attributes, with the "FRESH" flag in the SrvReg header
   set.  DAs which receive such registration messages return an

   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.

   If the update includes a <scope-list> other than the one in the
   prior registration, 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>.

9.5. Tag Lists

   Tag lists are used in SrvDeReg and AttrReq messages.  The syntax of a
   <tag-list> item is:

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 25]

Internet Draft          Service Location Protocol           21 June 1998

   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".

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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 26]

Internet Draft          Service Location Protocol           21 June 1998

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>.

   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       \

   The <PRList> and <scope-list> 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.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 27]

Internet Draft          Service Location Protocol           21 June 1998

   The URL field may alternatively be a full URL, such as
   "service:printer:lpr://" or
   "nfs://".  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.5 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 are requested in a protected scope from a
   DA, otherwise the DA will reply with an AUTHENTICATION_FAILED error.

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>                           \
     | # Auth Blocks |(if present) Attribute Authentication Blocks...\

   The format of the <attr-list> and the Authentication Block is as
   specified for SrvReg (see Section 9.2).

   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.

   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)".

   One Attribute Authentication Block is returned for each protected
   scope in the <scope-list>, for each Key Generation number supported.
   Note that the <attr-list> returned from a DA in a protected scope
   MUST be identical to the <attr-list> registered by a SA, in order
   for the authentication to be successful.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 28]

Internet Draft          Service Location Protocol           21 June 1998

10.5. Attribute Request/Reply Examples

   Suppose that printer services have been registered as follows:

   Registered Service:
     URL        = service:printer:lpr://
     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),

     URL        = service:printer:lpr://
     scope-list = Entwicklung
     Lang. Tag  = de
     Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler),
                  (Protocol=LPR),(Standort-beschreibung=13te Etage),
                  (Techniker=James Dornan \3cdornan@monster\3e),

     URL        = service:printer:
     scope-list = Development
     Lang. Tag  = en
     Attributes = (Name=Not),(Description=Experimental IPP printer),
                  (Protocol=http),(location-description=QA bench),

   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.

   The string "PROTOCOL" is 'literal' so it is not translated to
   different languages, see [14].

   The attribute Request:

     URL        = service:printer:lpr://
    scope-list = Entwicklung
     Lang. Tag  = de
     tag-list   = Resolution,St*

   receives the Attribute Reply:

     (Standort-beschreibung=13te Etage),(Resolution=res-600)

   The attribute Request:

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 29]

Internet Draft          Service Location Protocol           21 June 1998

     URL        = service:printer
     scope-list = Development
     Lang. Tag  = en
     tag-list   = x-*,resolution,protocol

   receives an Attribute Reply containing:


   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".

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 = 5)     |
     |    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.

   If the URL has not been registered with the DA in the scope specified
   in the SrvDeReg message, an INVALID_REGISTRATION error is returned.
   The Lifetime field in the URL Entry is ignored for the purposes of
   the SrvDeReg.

   The <tag-list> is a <string-list> of attribute tags to deregister
   as defined in Section 9.5.  If no <tag-list> is present, the
   SrvDeReg deregisters the service in all languages it has been

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 30]

Internet Draft          Service Location Protocol           21 June 1998

   registered in.  If the <tag-list> is present, the SrvDeReg
   deregisters the attributes whose tags are listed in the tag
   spec.  Services registered in protected scopes 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 in a protected
   scope, a URL authentication block for that protected scope and Key
   Generation Number MUST be included.  Otherwise, the DA returns an
   AUTHENTICATION_ABSENT error is returned.  If the message fails to be
   verified by the DA, an AUTHENTICATION_FAILED error is returned by the

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

   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,Perkins,Veizades,Day     Expires 21 December 1998      [Page 31]

Internet Draft          Service Location Protocol           21 June 1998

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.  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 and LanManager networking allow user selection of
   AppleTalk Zone or Windows 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).

11.3. Protected Scopes

   A protected scope is identical to a nonprotected scope except that
   it requires authentication of service information.  If a `protected
   scope' is configured, it must be accompanied by a key for the
   authentication calculation.  Typically, public key cryptography is
   used to avoid excessive disclosure of any private shared key with a
   possibly large collection of UAs.

   In protected scopes, certain SLP functions are restricted:  AttrRqst
   and SrvDeReg messages MUST NOT contain a <tag-list>.  DAs MUST
   verify SrvReg and SrvDeReg messages sent by SAs which select
   protected scopes.  UAs MUST verify SrvRply and AttrRply messages sent
   using protected scopes before returning them to client processes.

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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 32]

Internet Draft          Service Location Protocol           21 June 1998

   For use in networks with multiple subnets, a DA provides a
   centralized store for service information.  The DA address can be
   dynamically configured with UAs and DAs using DHCP, or by using
   static configuration.

   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
   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 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 SHOULD 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 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

   DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are
   OPTIONAL only for SAs, not DAs.)

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 33]

Internet Draft          Service Location Protocol           21 June 1998

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.

   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 SHOULD do this.

   A URL with the scheme "service:directory-agent" indicates
   the DA's location as defined in Section 8.5.  For example:

   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

   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 discoverying 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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 34]

Internet Draft          Service Location Protocol           21 June 1998

   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.

12.3. Reliable Unicast to DAs

   If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY
   seconds, the message should be retried.  If a DA fails to respond
   after CONFIG_DA_MAX seconds, the SA should consider the DA 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 is 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 with protected scope private keys.  This means
   they will not be able to sign URLs and <attr-list>s, but only cache
   them for SAs, forwarding them to UAs.  Consequently, in a protected
   scope the DA will not accept:  SrvReg without the FRESH flag set or
   AttrRqst or SrvDeReg with a <tag-list> included.  In these cases an
   AUTHENTICATION_FAILED error is returned.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 35]

Internet Draft          Service Location Protocol           21 June 1998

13. SLP Protocol Extensions

13.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 [14].

   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

   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> may not include wild cards.

13.2. Cryptographic Request Option

   If a UA wishes to obtain an Authentication Block using a non-default
   algorithm (i.e., not using DSA), it SHOULD include a SLP Extension
   requesting a particular BSD and optionally a Key Generation Number.

      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 = 0x0002    |        Extension Length       |
     |        Desired BSD            |Key Generation Number(optional)|

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 36]

Internet Draft          Service Location Protocol           21 June 1998

   The Desired BSD (see Section 9.1) is a two byte value.  If the DA
   or SA does not support this OPTIONAL extension, it will ignore it
   and return a DSA authentication block.  If it supports the Extension
   and the algorithm identified by the Desired BSD it will return an
   Authentication block using the desired algorithm.

   If a Key Generation Number is included, the host receiving the
   request MUST reply with an Authentication Block which uses the key
   with the requested Key Generation Number (see Section 9.2).  To omit
   a Key Generation Number in the Cryptographic Request Option, the Key
   Generation Number field is set to 0.

   If the SA or DA supports this option and receives a multicast request
   for a Key Generation Number or a cryptographic algorithm it does not
   support, it returns an AUTHENTICATION_UNKNOWN error.

14. Protocol Timing Defaults

Interval name        Section  Default Value  Meaning
-------------------  -------  -------------  ------------------------
CONFIG_MC_RETRY      6.3      each second,   Retry multicast query
                              backing off    until no new values
                              gradually      arrive.
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_DA_RETRY      12.3     2 seconds      Retransmit DA discovery,
                                             try it 3 times.
CONFIG_DA_MAX        12.3     6 seconds      Give up on requests sent
                                             to a DA.
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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 37]

Internet Draft          Service Location Protocol           21 June 1998

15. 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 32.  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 14.

               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,Perkins,Veizades,Day     Expires 21 December 1998      [Page 38]

Internet Draft          Service Location Protocol           21 June 1998

      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.

16. IANA Considerations

   Further Block Structured Descriptor (BSD) values 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 BSD numbers (from the range 0x0003 to 0x7FFF) on
   a first come, first served basis.

   New function-IDs, in the range 12-255, may be standardized by the
   method of IETF Consensus [19].  Similarly, new extensions with types
   in the range 3-65535 may be standardized by the method of IETF
   Consensus.  Specification and Expert Review is required for the
   assignment of new error numbers in the range of 15-65535.

   Protocol elements used with Service Location Protocol may also
   require IANA registration actions.  SLP is used in conjunction with
   "service:" URLs and service templates [14].  These are standardized
   by the method of a Designated Expert and a mailing list (see [14].)

17. 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.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 39]

Internet Draft          Service Location Protocol           21 June 1998

   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
   [14] 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.

18. 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.

   Using unprotected scopes, 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
   protected scopes prior to deploying the sensitive directory agents or
   service agents.

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 40]

Internet Draft          Service Location Protocol           21 June 1998

   Service Location 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.  Service Location 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 protected
   scopes if some cryptographic information can be preconfigured with
   the end systems before they use Service Location.

19. Acknowledgments

   This document incorporates ideas from work on several discovery
   protocols, including RDP by Perkins and Harjono, and PDS by
   Michael Day.

20. Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of 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

   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

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 41]

Internet Draft          Service Location Protocol           21 June 1998


    [1] Port numbers, July 1997.

    [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 #4.  The unicode standard, version 2.0.
        Technical Report ISBN 0-201-48345-9, The Unicode Consortium,

    [7] H. Alvestrand.  Tags for the Identification of Languages.  RFC
        1766, March 1995.

    [8] D. Balenson.   Privacy Enhancement for Internet Electronic
        Mail:  Part III: Algorithms, Modes, and Identifiers.  RFC 1423,
        February 1993.

    [9] T. Berners-Lee, L. Masinter, and M. McCahill.  Uniform Resource
        Locators (URL).  RFC 1738, December 1994.

   [10] S. Bradner.  Key Words for Use in RFCs to Indicate Requirement
        Levels.  RFC 2119, March 1997.

   [11] CCITT.  Specification of the Abstract Syntax Notation One
        (ASN.1).  Recommendation X.208, 1988.

   [12] CCITT.  The Directory Authentication Framework.  Recommendation
        X.509, 1988.

   [13] D. Crocker and P. Overell.  Augmented BNF for Syntax
        Specifications:  ABNF.  RFC 2234, November 1997.

   [14] E. Guttman, C. Perkins, and J. Kempf.  Service Templates and
        service:  Schemes.  draft-ietf-svrloc-service-scheme-05.txt,
        November 1997.  (work in progress).

   [15] T. Howes.  The string representation of LDAP search filters.
        draft-ietf-asid-ldapv3-filter-03.txt, October 1997.  (work in

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 42]

Internet Draft          Service Location Protocol           21 June 1998

   [16] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
        for Message Authentication.  RFC 2104, February 1997.

   [17] D. Meyer.  Administratively Scoped IP Multicast.  draft-ietf-
        mboned-admin-ip-space-04.txt, November 1997. (work in progress).

   [18] D. Mills.  Network Time Protocol (Version 3):  Specification,
        Implementation and Analysis.  RFC 1305, March 1992.

   [19] T. Narten, H. Alvestrand.  Guidelines for Writing an IANA
        Considerations Section in RFCs.  draft-iesg-iana-considerations
        -04.txt, May 1998.  (work in progress).

   [20] National Institute of Standards and Technology.  Digital
        signature standard.  Technical Report NIST FIPS PUB 186, U.S.
        Department of Commerce, May 1994.

   [21] R. Rivest.  The MD5 Message-Digest Algorithm.  RFC 1321, April

   [22] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  RFC 2165, July 1997.

   [23] F. Yergeau.  UTF-8, a transformation format of ISO 10646.  RFC
        2279, January 1998.

Authors' Addresses

             Erik Guttman              Charles Perkins
             Sun Microsystems          Sun Microsystems
             Bahnstr. 2                901 San Antonio Road
             74915 Waibstadt           Palo Alto, CA 94040
             Germany                   USA

   Phone:    +49 7263 911 701          +1 650 786 6464

             John Veizades             Michael Day
             @Home Network             Intel
             385 Ravendale Dr.         734 E. Utah Valley Dr., Ste. 300
             Mountain View, CA 94043   American Fork, Utah, 84003
             USA                       USA

   Phone:    +1 650 569 5243           +1 801 763 2341

Guttman,Perkins,Veizades,Day     Expires 21 December 1998      [Page 43]