RFC 2608
Service Location Protocol, Version 2
Part 1 of 12 🎀
Network Working Group 🌸
Request for Comments: 2608 💖 (this is the RFC number, bestie, so remember it!)
Title: Service Location Protocol, Version 2 ✨
Authors: E. Guttman, C. Perkins, J. Veizades, and M. Day. The affiliations are Sun Microsystems (Guttman, Perkins), @Home Network (Veizades), and Vinca Corporation (Day). 👑
Category: Standards Track. This is an official, real-deal Internet standard. 🔥
Date: June 1999 🦋
Updates: RFC 2165 (SLPv1). This doc fixes protocol errors in v1, adds some enhancements, and removes some requirements. 🧚
Status of This Memo 💅
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🌈
Copyright Notice 🫶
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract ⭐
Okay so the Service Location Protocol gives you a scalable way to discover and select network services. With it, computers on 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 as users become less tolerant of, or less able to handle, the demands of network system administration. Main character energy for your devices 💜
Table of Contents 📖
1. Introduction 3
1.1. Applicability Statement . . . . . . . . . . . . . . . 3
2. Terminology 4
2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview 5
4. URLs used with Service Location 8
4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9
4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10
4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10
5. Service Attributes 10
6. Required Features 12
6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14
6.3. Retransmission of SLP messages . . . . . . . . . . . 15
6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16
6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16
7. Errors 17
8. Required SLP Messages 17
8.1. Service Request . . . . . . . . . . . . . . . . . . . 19
8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21
8.3. Service Registration . . . . . . . . . . . . . . . . . 22
8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23
8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24
8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25
9. Optional Features 26
9.1. Service Location Protocol Extensions . . . . . . . . . 27
9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28
9.2.1. SLP Message Authentication Rules . . . . . . . 29
9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30
9.3. Incremental Service Registration . . . . . . . . . . 30
9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31
10. Optional SLP Messages 32
10.1. Service Type Request . . . . . . . . . . . . . . . . 32
10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32
10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33
10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34
10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34
10.6. Service Deregistration . . . . . . . . . . . . . . . 36
11. Scopes 37
11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37
11.2. Administrative and User Selectable Scopes. . . . . . . 38
12. Directory Agents 38
12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39
12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39
12.2.1. Active DA Discovery . . . . . . . . . . . . . 40
12.2.2. Passive DA Advertising . . . . . . . . . . . . 40
12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41
12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41
12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41
13. Protocol Timing Defaults 42
14. Optional Configuration 43
15. IANA Considerations 44
16. Internationalization Considerations 45
17. Security Considerations 46
A. Appendix: Changes to the Service Location Protocol from
v1 to v2 48
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48
C. Appendix: DAAdverts with arbitrary URLs 49
D. Appendix: SLP Protocol Extensions 50
D.1. Required Attribute Missing Option . . . . . . . . . . 50
E. Acknowledgments 50
F. References 51
G. Authors' Addresses 53
H. Full Copyright Statement 541. Introduction ✨
Okay bestie, so the Service Location Protocol (SLP) gives hosts a flexible, scalable framework for finding out about networked services: whether they exist, where they live, and how they're configured. 🧚 Traditionally, users had to find services by knowing the name of a network host (a human-readable text string that's an alias for a network address). That was so annoying. SLP eliminates the need for a user to know the name of the host supporting a service. Instead, the user supplies the type of service they want and a set of attributes that describe it, and then SLP resolves the network address of the service for them. Iconic. 💅
SLP also 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. When there are lots of clients and/or services, the protocol makes use of nearby Directory Agents, which act as a centralized repository for advertised services. 🦋
This document updates SLPv1 [RFC 2165], correcting protocol errors, adding some enhancements, and removing some requirements. 🌸 The spec has two parts. The first describes the required features of the protocol. The second describes the extended features, which are optional and allow greater scalability. 💜
1.1. Applicability Statement 🌈
Real talk, SLP is meant to run inside networks under cooperative administrative control. Those networks can implement a policy around security, multicast routing, and how services and clients are organised into groups. That level of control isn't feasible on the scale of the whole Internet, so don't get it twisted. 🙈
SLP was designed for enterprise networks with shared services. It may not necessarily scale to wide-area service discovery across the global Internet, or to networks with hundreds of thousands of clients or tens of thousands of services. Know your limits, periodt. 💀
2. Terminology 📚
Here's the vocabulary you need, no cap:
- User Agent (UA): A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents. 👑
- Service Agent (SA): A process working on the behalf of one or more services to advertise the services. 🎀
- Directory Agent (DA): A process which collects service advertisements. There can only be one DA present per given host. ✨
- Service Type: Each type of service has a unique Service Type string. 🍓
- Naming Authority: The agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA. 🌷
- Scope: A set of services, typically making up a logical administrative group. 🫧
- URL: A Universal Resource Locator [8]. 🔗
2.1. Notation Conventions 🧠
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9]. These are the official requirement words, so pay attention to them! 💖
Syntax: Syntax for string-based protocols follows the conventions defined for ABNF [11]. 🩷
Strings: All strings are encoded using the UTF-8 [23] transformation of the Unicode [6] character set and are NOT null terminated when transmitted. Strings are preceded by a two-byte length field. Lowkey the most important detail in this whole section 😭
The <string-list> notation is a comma-delimited list of strings, with this grammar:
string-list = string / string `,' string-listIn format diagrams, any field ending with a \ indicates a variable-length field, given by a prior length field in the protocol. That backslash is basically a little arrow pointing back to the length field that tells you how big it is. Iykyk 🌟
3. Protocol Overview ✨
okay so SLP is giving framework energy 💅 Client apps get modeled as 'User Agents', services get advertised by 'Service Agents', and a third entity called a 'Directory Agent' is the scalability queen 👑 that keeps everything running smoothly.
The User Agent sends a 'Service Request' (SrvRqst) for the client app, spelling out exactly what kind of service the client needs 🎀 Then it gets a Service Reply (SrvRply) listing the location of every service on the network that matches. Iconic.
The framework lets the User Agent talk straight to Service Agents too 🦋 In that case the request gets multicast. Any Service Agent that advertises the service it's asked about sends back a unicast reply with that service's location.
+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast SrvRply------ +---------------+In bigger networks, one or more Directory Agents show up 🌸 The Directory Agent works as a cache. Service Agents send register messages (SrvReg) with all the services they advertise to the Directory Agents, and they get acknowledgements back (SrvAck). These advertisements must be refreshed with the Directory Agent or they expire, so keep them fresh bestie 💖 Also, User Agents send unicast requests to Directory Agents instead of Service Agents whenever any Directory Agents are known.
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+User and Service Agents can find Directory Agents in two ways 🧚 First, they send a multicast Service Request for the 'Directory Agent' service when they start up. Second, the Directory Agent occasionally sends an unsolicited advertisement, and the User and Service Agents just listen for it. Either way, the Agents get a DA Advertisement (DAAdvert) 💅
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast DAAdvert- +-----------+Services get grouped using 'scopes' 🌈 These are strings that identify services that are administratively identified. A scope can mean a location, an administrative grouping, proximity in a network topology, or some other category. Service Agents and Directory Agents always get assigned a scope string.
A User Agent is usually assigned a scope string, which means it can only discover that particular grouping of services 🍓 This is how a network admin can 'provision' services to users. Or the User Agent can be configured with no scope at all. Then it discovers all the available scopes and lets the client app request any service on the network. Main character energy 👑
+---------+ Multicast +-----------+ Unicast +-----------+
| Service | <--SrvRqst-- | User | --SrvRqst-> | Directory |
| Agent | | Agent | | Agent |
| Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y |
+---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+In the example above, the User Agent is configured with scopes X and Y. If it wants a service in scope X, the request gets multicast. If it wants one in scope Y, the request gets unicast to the DA. And if the request is for both scopes, it has to be both unicast and multicast 🫶
Service Agents and User Agents may verify digital signatures that come with DAAdverts 🔐 User Agents and Directory Agents may verify service information that Service Agents registered. The keying material used to verify digital signatures is identified with an SLP Security Parameter Index, or SLP SPI.
Every host that's set up to generate a digital signature includes the SLP SPI used to verify it in the Authentication Block it sends 💜 Every host that can verify a digital signature must be configured with keying material and other parameters that match the SLP SPI, so it can do the verifying math.
SAs MUST accept multicast service requests and unicast service requests. SAs MAY accept other requests (Attribute and Service Type Requests). SAs MUST listen for multicast DA Advertisements.
The features we've covered so far are required to implement 🎀 The bare minimum implementation is a User Agent, a Service Agent, or both.
There are a few optional features too. DAs MUST support all of these message types, but DA support is itself optional to deploy on networks that use SLP. UAs and SAs MAY support these message types. These operations are mainly for interactive use, like browsing or selectively updating service registrations. UAs and SAs either support them or don't, depending on the requirements and constraints of the environment where they'll be used 🦋
Service Type Request A request for all types of service on the
network. This allows generic service browsers
to be built.
Service Type Reply A reply to a Service Type Request.
Attribute Request A request for attributes of a given type of
service or attributes of a given service.
Attribute Reply A reply to an Attribute Request.
Service Deregister A request to deregister a service or some
attributes of a service.
Service Update A subsequent SrvRqst to an advertisement.
This allows individual dynamic attributes to
be updated.
SA Advertisement In the absence of Directory Agents, a User
agent may request Service Agents in order
to discover their scope configuration. The
User Agent may use these scopes in requests.Without Multicast support, Broadcast MAY be used 📡 The location of DAs may be staticly configured, found with SLP as described above, or configured using DHCP. If a message is too large, it may be unicast using TCP 🌸
A SLPv2 implementation SHOULD support SLPv1 [22]. This support includes:
- SLPv2 DAs are deployed, phasing out SLPv1 DAs.
- Unscoped SLPv1 requests are considered to be of DEFAULT scope. SLPv1 UAs MUST be reconfigured to have a scope if possible.
- There is no way for an SLPv2 DA to behave as an unscoped SLPv1 DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
- SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 requests with SLPv2 replies.
- SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same way. That is, incoming requests from agents using either version of the protocol will be matched against this common set of registered services.
- SLPv2 registrations which use Language Tags which are greater than 2 characters long will be inaccessible to SLPv1 UAs.
- SLPv2 DAs MUST return only service type strings in SrvTypeRply messages which conform to SLPv1 service type string syntax, ie. they MUST NOT return Service Type strings for abstract service types.
- SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service URLs with abstract service types. They only match Service URLs with concrete service types.
SLPv1 UAs won't get replies from SLPv2 SAs, and SLPv2 UAs won't get replies from SLPv1 SAs 😭 So to get UAs and SAs of different versions to interoperate, you need an SLPv2 DA on the network that supports both protocols 🫶
Abstract service types in SLPv2 cause a backward compatibility issue for SLPv1 🙈 It's possible that a SLPv1 UA will request a service type that's actually an abstract service type. Based on the rules above, the SLPv1 UA will never get an abstract Service URL reply. For example, the service type 'service:x' in a SLPv1 AttrRqst won't return the attributes of 'service:x:y://orb'. If the request was made with SLPv2, it would return the attributes of this service.
4. URLs used with Service Location
A Service URL shows where a service lives 📍 It can use the service: scheme [13] (reviewed in section 4.1), or any other URL scheme that follows the URI standard [8]. The one exception is that URLs without address specifications SHOULD NOT be advertised by SLP. The service type for a 'generic' URL is its scheme name. For example, the service type string for "http://www.srvloc.org" would be "http" 💅
Reserved characters in URLs follow the rules in RFC 2396 [8].
4.1. Service: URLs
Service URL syntax and semantics are defined in [13]. Any network service can be encoded in a Service URL 🌈
This section gives an intro to Service URLs and an example showing a simple use of them, representing standard network services 🍓
A Service URL may look like this:
"service:"<srvtype>"://"<addrspec>The Service Type of this service: URL is the string up to (but not including) the final : before <addrspec>, the address specification 🎀
<addrspec> is a hostname (which should be used if possible) or dotted decimal notation for a hostname, followed by an optional : and port number 🧚
A service: scheme URL can be formed with any standard protocol name by sticking "service:" in front of the reserved port [1] name. For example, "service:tftp://myhost" would indicate a tftp service. A tftp service on a nonstandard port could be "service:tftp://bad.glad.org:8080" 💖
Service Types SHOULD be defined by a "Service Template" [13], which provides expected attributes, values and protocol behavior ✨ An abstract service type (also described in [13]) has this form:
"service:<abstract-type>:<concrete-type>"The service type string "service:<abstract-type>" matches all services of that abstract type 👑 If the concrete type is included too, only those services match the request. For example: a SrvRqst or AttrRqst that specifies "service:printer" as the Service Type will match the URL service:printer:lpr://hostname and service:printer:http://hostname. If the requests specified "service:printer:http" they would match only the latter URL 🖨️
An optional substring MAY follow the last . character in the <srvtype> (or <abstract-type> in the case of an abstract service type URL) 🦋 This substring is the Naming Authority, as described in Section 9.6. Service types with different Naming Authorities are quite distinct. In other words, service:x.one and service:x.two are different service types, as are service:abstract.one:y and service:abstract.two:y 🫶
4.2. Naming Authorities ✨
Okay so a Naming Authority MAY optionally be tacked onto the end of a Service Type string 💅 The Naming Authority of a service is basically the boss of what the Service Types and attributes mean, since it defines them for Service Location 👑 It's usually a string that uniquely identifies an organization 🎀 If you don't append any string, IANA is the implied Naming Authority, and IANA itself MUST NOT be included explicitly 🙈
Naming Authorities can define Service Types that are experimental, proprietary, or for private use 🧚 You can either ignore attributes when you register, or make a local-use only set of attributes for your own site. The move is to pick a 'unique' Naming Authority string and then specify the Standard Attribute Definitions described above 💖 That Naming Authority comes along for the ride with registrations and queries, as described in Sections 8.1 and 8.3 🫶 Service Types SHOULD be registered with IANA so everyone across the whole Internet can actually talk to each other 🌈
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 inside protocol elements called URL Entries 🎀 Each one ties together a length, a lifetime, and possibly some authentication info along with the URL itself. URL Entries are laid out exactly as shown above, and they show up in Service Replies and Service Registrations ✨
5. Service Attributes 💜
A service advertisement is often sent with Service Attributes attached 🍓 UAs use these to pick the right services when they make Service Requests 🎯
Which attributes you're allowed to use is usually spelled out by a Service Template [13] for a particular service type. Services advertised according to a standard template MUST register every service attribute that the standard template requires 🫶 URLs with schemes other than "service:" MAY be registered with attributes too 🌸
Non-standard attribute names SHOULD start with x-, because no standard attribute name will ever begin with those characters 🙌
An attribute list is just a string that encodes a service's attributes 🧚 Here's the ABNF [11] grammar that defines attribute lists:
attr-list = attribute / attribute `,' attr-list
attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
attr-val-list = attr-val / attr-val `,' attr-val-list
attr-tag = 1*safe-tag
attr-val = intval / strval / boolval / opaque
intval = [-]1*DIGIT
strval = 1*safe-val
boolval = "true" / "false"
opaque = "\FF" 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, star and bad-tag.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
escape-val = `\' HEXDIG HEXDIG
bad-tag = CR / LF / HTAB / `_'
star = `*'Here's the escaping situation 🔥 The <attr-list>, if it's present, MUST be scanned for every escape character \ before anything gets evaluated. Reserved characters MUST be escaped, and every other character MUST NOT be escaped. Before you attempt any string matching, all escaped characters need to be restored to their real value. Opaque values are the exception: their escaped characters are not converted and get interpreted as bytes 💀
Now the value types, all in one little table 💅
Boolean Strings which have the form "true" or "false" can
only take one value and may only be compared with
'='. Booleans are case insensitive when compared.
Integer Strings which take the form [-] 1*<digit> and fall
in the range "-2147483648" to "2147483647" are
considered to be Integers. These are compared using
integer comparison.
String All other Strings are matched using strict lexical
ordering (see Section 6.4).
Opaque Opaque values are sequences of bytes. These are
distinguished from Strings since they begin with
the sequence "\FF". This, unescaped, is an illegal
UTF-8 encoding, indicating that what follows is a
sequence of bytes expressed in escape notation which
constitute the binary value. For example, a '0' byte
is encoded "\FF\00".Any string that has escaped values outside the reserved set of characters is illegal 🚫 If one of those shows up in an <attr-list>, a <tag-list>, or a search filter, the SA or DA that receives it MUST return a PARSE_ERROR to the message 😭
A keyword is just an <attr-tag> with no values attached 🌷 Attributes can have one value or several, and every value is written as a string 💖
Once values have been advertised by a SA or registered in a DA, they can pick up implicit typing rules for matching incoming requests 🔮
Stored values have to be consistent, so something like x=4,true,sue,\ff\00\00 is disallowed 🙅♀️ A DA or SA that receives an <attr-list> like that MUST return an INVALID_REGISTRATION error 🥲
6. Required Features 🎀
This section lays out the minimum implementation requirements for SAs and UAs, plus how they work with DAs 🧚 A DA isn't required for SLP to function, but if one is present, the UA and SA MUST interact with it exactly as defined below 💜
A minimal implementation can be a UA, an SA, or both ✨ A UA's only required features are that it can send SrvRqsts following the rules below and that it can interpret DAAdverts, SAAdverts, and SrvRply messages 💅 The UA MUST issue requests to DAs as soon as they're discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or SAAdvert messages, and it MUST also register with DAs as they're discovered 🫶
UAs do discovery by sending Service Request messages 🔍 SrvRqst messages go out over UDP, following these prioritized rules:
- A UA issues a request to a DA it was configured with by DHCP.
- A UA issues requests to DAs it was statically configured with.
- A UA uses multicast/convergence SrvRqsts to discover DAs, then sticks with that set of DAs. A UA that doesn't know of any DAs SHOULD retry DA discovery, and it SHOULD increase the waiting interval between attempts exponentially (doubling the wait interval each time). The recommended minimum waiting interval is
CONFIG_DA_FINDseconds 🌸 - A UA with no knowledge of DAs sends requests using multicast convergence to SAs. SAs unicast replies back to UAs according to the multicast convergence algorithm 🦋
UAs and SAs get their list of scopes using these prioritized rules 👑
- With DHCP.
- With static configuration. The static configuration may be explicitly set to NO SCOPE for UAs, if the User Selectable Scope model is used. See section 11.2.
- In the absence of configuration, the agent's scope is "DEFAULT".
A UA MUST issue requests with one or more of the scopes it has been configured to use 💖
A UA that was statically configured with NO SCOPE LIST will use DA or SA discovery to figure out its scope list dynamically 🔥 In this case it sends an empty scope list to discover DAs and possibly SAs. After that, it uses the scope list it gets from DAAdverts and possibly SAAdverts in later requests 🧠
The SA MUST register all its services with any DA it discovers, as long as that DA advertises at least one of the scopes the SA was configured with 🫶 A SA gets info about DAs the same way a UA does. On top of that, the SA MUST listen for multicast unsolicited DAAdverts 👂 The SA registers by sending SrvReg messages to DAs, and the DAs reply with SrvReg messages to confirm success. SAs register in ALL the scopes they were configured to use ✨
6.1. Use of Ports, UDP, and Multicast 🌈
DAs MUST accept unicast requests and multicast directory agent discovery service requests (for the service type service:directory-agent) 🙌
SAs MUST accept both multicast requests and unicast requests 🧚 An SA can tell them apart by checking whether the REQUEST MCAST flag is set in the SLP Message header 💅
By default, the Service Location Protocol uses multicast to discover DAs and to send requests to SAs 🦋
The reserved listening port for SLP is 427 🎀 That's the destination port for every SLP message. SLP messages MAY be sent from an ephemeral port. Replies and acknowledgements go back to the port the request came from 💜 The default maximum transmission unit for UDP messages is 1400 bytes, not counting UDP and other headers ✨
If an SLP message doesn't fit into a UDP datagram, it MUST be truncated to fit, and the OVERFLOW flag gets set in the reply message 😭 A UA that 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 try to make use of the truncated reply, or reformulate a more restrictive request that results in a smaller reply 🫶
SLP Requests messages are multicast to The Administratively Scoped SLP Multicast [17] address, which is 239.255.255.253 🌸 The default TTL for multicast is 255 🔥
On isolated networks, broadcasts can work in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast Service Location messages on port 427 🙈 This lets UAs that don't support multicast still use Service Location on isolated networks 🧚
Setting the multicast TTL below 255 (the default) limits how far SLP discovery reaches across a network, and it keeps service information localized 🍓
6.2. Use of TCP 💖
A SrvReg or SrvDeReg may be too big to fit into a datagram 😳 To send large SLP messages like that, a TCP (unicast) connection MUST be established 🔒
To avoid having to implement TCP, one MUST insure that:
- UAs never issue requests larger than the Path MTU. SAs can leave out 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.
- A SA can always send a SrvRply, SrvReg, or SrvDeReg in a single datagram. That means limiting the size of URLs, the number of attributes, and the number of authenticators transmitted 💅
DAs MUST be able to respond to UDP and TCP requests, as well as multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVER receive a request or send a reply that will exceed a datagram in size (e.g., some embedded systems) 🧠
A TCP connection MAY be used for a single SLP transaction or for several transactions 🌷 Since the message headers have length fields, SLP Agents can send multiple requests along one 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 keep things robust, even if the initiating agent forgets to close it 🥹 See Section 13 for timing rules ⏰
6.3. Retransmission of SLP messages 🔁
Okay so if a request doesn't get a response, it gets sent again 🔁 The first retransmission happens after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). This applies to unicast as well as multicast SLP requests 💅
Unicast requests to a DA or SA should be retransmitted until either a response (which might be an error) has been obtained, or for CONFIG_RETRY_MAX seconds.
Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds until a result has been obtained. UAs need only wait till they obtain the first reply which matches their request. That is, retransmission is not required if the requesting agent is prepared to use the 'first reply' instead of 'as many replies as possible within a bounded time interval.' ✨
When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a <PRList> of previous responders. Initially the <PRList> is empty. When these requests are unicast, the <PRList> is always empty 🧺
Any DA or SA which sees its address in the <PRList> MUST NOT respond to the request. 🙈
The message SHOULD be retransmitted until the <PRList> causes no further responses to be elicited or the previous responder list and the request will not fit into a single datagram or until CONFIG_MC_MAX seconds elapse.
UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very briefly. XIDs SHOULD be randomly chosen to avoid duplicate XIDs in requests if UAs restart frequently. the XID drama is real 🦋
6.4. Strings in SLP messages 🎀
So the escape character is a backslash (UTF-8 0x5c) followed by the two hexadecimal digits of the escaped character. Only reserved characters get escaped. For example, a comma (UTF-8 0x29) is escaped as \29', and a backslash \' is escaped as \5c'. String lists in SLP define the comma as the delimiter between list elements, so commas in data strings must be escaped this way. Backslashes are the escape character, so they also must always be escaped when included in a string literally 💅
String comparison for order and equality in SLP MUST be case insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII character encoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encoded Unicode [6] character set. 🔥
The case insensitivity rule applies to all string matching in SLPv2, including Scope strings, SLP SPI strings, service types, attribute tags and values in query handling, language tags, previous responder lists. Comparisons of URL strings, however, is case sensitive. 🙈
White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. White space preceding or following a string value is ignored for the purposes of string comparison. For example, " Some String " matches "SOME STRING". ✨
String comparisons (using comparison operators such as <=' or >=') are done using lexical ordering in UTF-8 encoded characters, not using any language specific rules. 🧚
The reserved character `*' may precede, follow or be internal to a string value in order to indicate substring matching. The query including this character matches any character sequence which conforms to the letters which are not wildcarded. 🌈
6.4.1. Scope Lists in SLP 🌸
Scope Lists in SLPv2 have the following grammar:
scope-list = scope-val / scope-val `,' scope-list
scope-val = 1*safe
safe = ; Any character except reserved.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
/ `;' / `*' / `+'
escape-val = `\' HEXDIG HEXDIGScopes which include any reserved characters must replace the escaped character with the escaped-val format. Lowkey the grammar does all the heavy lifting here 🫶
7. Errors 💀
If the Error Code in a SLP reply message is nonzero, the rest of the message MAY be truncated. No data is necessarily transmitted or should be expected after the header and the error code, except possibly for some optional extensions to clarify the error, for example as in section D.1.
Errors are only returned for unicast requests. Multicast requests are silently discarded if they result in an error. 🤫
Here's the full list of error codes 👑
LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
the scope in the AttrRqst or SrvRqst, but not in the requested
language.
PARSE_ERROR = 2: The message fails to obey SLP syntax.
INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
lifetime or an omitted Language Tag.
SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
its <scope-list> supported by the SA or DA.
AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
unsupported SLP SPI.
AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
authentication in the SrvReg and did not receive it.
AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
an Authentication block.
VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
from the mandatory range (see section 9.1).
INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
an unregistered service or with inconsistent Service Types.
MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
and does not support it.
REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
DA more frequently than the DA's min-refresh-interval.8. Required SLP Messages 🫶
All length fields in SLP messages are in network byte order. Where ' tuples' are defined, these are sequences of bytes, in the precise order listed, in network byte order. 🧠
SLP messages all begin with the following header: 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|F|R| reserved |Next Ext Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Extension Offset, contd.| XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Tag Length | Language Tag \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the message type cheat sheet 📋
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 11SAs 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. 🦋
Now the header fields, one by one 🧚
- Length is the length of the entire SLP message, header included. 📏
- The flags are:
OVERFLOW(0x80) is set when a message's length exceeds what can fit into a datagram. 🚨FRESH(0x40) is set on every new SrvReg. ✨REQUEST MCAST(0x20) is set when multicasting or broadcasting requests. 📡- Reserved bits MUST be 0. 🙅♀️
- Next Extension Offset is set to 0 unless extensions are used. The first extension begins at 'offset' bytes, from the message's beginning. It is placed after the SLP message data. See Section 9.1 for how to interpret unrecognized SLP Extensions. 🧩
- XID is set to a unique value for each unique request. If the request is retransmitted, the same XID is used. Replies set the XID to the same value as the xid in the request. Only unsolicited DAAdverts are sent with an XID of 0. 🆔
- Lang Tag Length is the length in bytes of the Language Tag field. 🌍
- Language Tag conforms to [7]. The Language Tag in a reply MUST be the same as the Language Tag in the request. This field must be encoded
1*8ALPHA *("-" 1*8ALPHA). 🏳️🌈
If an option is specified, and not included in the message, the receiver MUST respond with a PARSE_ERROR. no cap, this one is important 🚫
8.1. Service Request 🎀
okay so a Service Request is the SrvRqst message, and it's laid out like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For a Service to count as a match for a SrvRqst, it has to belong to at least one requested scope, support the requested service type, and match the predicate. If there's a predicate, the language of the request (ignoring the dialect part of the Language Tag) has to match the advertised service. 🌸
<PRList> is the Previous Responder List 🫶. It's a <string-list> of dotted decimal notation IP (v4) addresses, and it gets multicast over and over to collect every possible result (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they aren't already configured with DA addresses some other way.
An SA silently drops all requests that include the SA's address in the <PRList>. An SA that has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList that doesn't conform to an IPv4 dotted decimal address is ignored: the rest of the <PRList> is processed normally and an error is not returned. 💖
Once a <PRList> plus the request exceeds the path MTU, multicast convergence stops. This algorithm isn't meant to find every instance. It finds "enough" to give useful results, and that's the whole vibe ✨
The <scope-list> is a <string-list> of configured scope names. SAs and DAs that have been configured with any of the scopes in this 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 gets a SrvRply, but 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 it's set to "service:service-agent", SAs respond with a SAAdvert (see Section 8.6.). If this field is omitted, a PARSE_ERROR is returned, because this field is REQUIRED. 🙈
The <predicate> is a LDAPv3 search filter [14]. This field is OPTIONAL. Services can be discovered just by type and scope. Otherwise, you get the services that satisfy the <predicate>. If it's present, it's 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. So (x=3) matches a registration of (x=1,2,3), and (!(Y=0)) matches (y=0,1) since Y can be nonzero. The matching is case insensitive, so no drama there. Keywords (attributes without values) get matched with a "presence" filter, like (keyword=*). 🦋
An incoming request term MUST have the same type as the attribute in a registration in order to match. So (x=33) won't match ' x=true', etc. But (y=foo) will match 'y=FOO'. And (|(x=33)(y=foo)) gets satisfied even though (x=33) can't be, because of the | (boolean disjunction) 🧚
Wildcard matching MUST be done with the = filter. In any other case, a PARSE_ERROR is returned. Request terms that include wildcards get interpreted as Strings. That means (x=34*) would match 'x=34foo', but not 'x=3432', since the first value is a String and the second is an Integer. Strings don't match Integers, bestie 🙅♀️
Here are some predicate examples. <t> is the service type of the SrvRqst, <s> gives the <scope-list>, and <p> is the predicate string.
<t>=service:http <s>=DEFAULT <p>= (empty string)This is the minimal request string. It matches all http services advertised with the default scope. Simple and iconic 🌈
<t>=service:pop3 <s>=SALES,DEFAULT <p>=(user=wump)This asks for all pop3 services available in the SALES or DEFAULT scope that serve mail to the user wump. 📬
<t>=service:backup <s>=BLDG 32 <p>=(&(q<=3)(speed>=1000))This returns the backup service with a queue length less than 3 and a speed greater than 1000. It only returns this for services registered with the BLDG 32 scope. Very specific, very main character 👑
<t>=service:directory-agent <s>=DEFAULT <p>=This returns DAAdverts for all DAs in the DEFAULT scope. 🫧
DAs are discovered by sending a SrvRqst with the service type set to "service:directory-agent". If a predicate is included in the SrvRqst, the DA SHOULD respond only if the predicate can be satisfied with the DA's attributes. The <scope-list> MUST contain all scopes configured for the UA or SA that's discovering DAs. 🔍
The <SLP SPI> string indicates an SLP SPI that the requester has been configured with. If this string is omitted, the responder doesn't include any Authentication Blocks in its reply. If it is included, the responder MUST return a reply that has an associated authentication block with the SLP SPI in the SrvRqst. If no replies can be returned because the SLP SPI isn't supported, the responder returns an AUTHENTICATION_UNKNOWN error. 🔐
8.2. Service Reply 🍓
Here's the SrvRply layout 🎀
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A service reply holds zero or more URL entries (see Section 4.3). A service reply with zero URL entries MUST be returned in response to a unicast Service Request if no matching URLs are present. But a service reply with zero URL entries MUST NOT be sent in response to a multicast or broadcast service request. Instead, if there was no match or there was an error processing the request, the service reply should not be generated at all. Less noise, more vibes 🤫
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's a URL Authenticator block present. In that case, the cache lifetime is indicated by the Timestamp in the URL Authenticator (see Section 9.2). ⏳
An authentication block is returned in the URL Entries, including the SLP SPI in the SrvRqst. If no SLP SPI was included in the request, no Authentication Blocks are returned in the reply. URL Authentication Blocks are defined in Section 9.2.1. 🔏
If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless it fits entirely without truncation. No cut-off entries allowed, periodt 💅
8.3. Service Registration 🧚
Here's the SrvReg layout 🌸
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 do it more often than once per second. ⏰ The Lifetime MAY be set to any value between 0 and 0xffff (that's the maximum, around 18 hours). Long-lived registrations stay stale longer if the service fails and the SA doesn't deregister it, so keep that in mind 🙈
The <service-type> defines the service type of the URL being registered, regardless of the scheme of the URL. The <scope-list> MUST contain the names of all scopes configured for the SA that the DA it's registering with supports. The default value for the <scope-list> is "DEFAULT" (see Section 11). 🫶
The SA MUST register consistently with all DAs. Say a SA is configured with scopes X and Y and there are three DAs, with scopes "X", "Y" and "X,Y" respectively. The SA will register with all three DAs in their respective scopes. All future updates and deregistrations of the service must be sent to the same set of DAs in the same scopes the service was first registered in. No skipping the group chat 💬
The <attr-list>, if present, specifies the attributes and values that the DA associates with the URL (see Section 5). 🏷️
A SA configured with the ability to sign service registrations MUST sign each of the URLs and Attribute Lists using each of the keys it is configured to use, and the DA it is registering with accepts. The SA MUST acquire DAAdverts for all DAs it will register with, so it can get the DA's SLP SPI list and attributes, as described in Section 8.5. The SA supplies an SLP SPI in each authentication block, indicating the SLP SPI configuration needed to verify the digital signature. The format of the digital signatures used is defined in section 9.2.1. 🔑
Subsequent registrations of previously registered services MUST contain the same list of SLP SPIs as the previous ones, or else DAs will reject them with an AUTHENTICATION_ABSENT error. Consistency is everything 🥹
A registration with the FRESH flag set will replace entirely any previous registration for the same URL in the same language. If the FRESH flag is not set, the registration is an "incremental" registration (see Section 9.3). Fresh means fresh, no leftovers 🧼
8.4. Service Acknowledgment ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck = 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so the SrvAck 💌 is what a DA sends back to an SA after a SrvReg. It's tiny, just a two byte Error Code 🫶. For the list of error codes, peek at 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | DA Stateless Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DA Stateless Boot Time,, contd.| Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <SLP SPI List> | <SLP SPI List> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This one's the big boss of adverts 👑. The Error Code is set to 0 when the DAAdvert is multicast. If the DAAdvert is coming back because of a unicast SrvRqst (aka a request without the REQUEST MCAST flag set), the DA returns the same errors a SrvRply would 🙈.
The <scope-list> in the SrvRqst has to be either left out or include a scope the DA supports 💅. The DA Stateless Boot Timestamp tells you what state the DA is in (see section 12.1) 🧚.
The DA MAY include a list of its attributes in the DAAdvert 💜. This list SHOULD be kept short, since the DAAdvert has to fit in one datagram to get multicast 🍓.
Okay the scaling drama 😭: if SAs pick a Lifetime that's too low, they end up reregistering like crazy as more services get deployed. SLPv2 lets DAs control how often SAs register 💅. A DA MAY reissue a DAAdvert with a fresh set of attributes whenever it wants, to change how SAs reregister 🦋. These only apply to later registrations, so existing ones keep the lifetimes they already have ✨.
If the DAAdvert includes the attribute "min-refresh-interval", it MUST be a single Integer value, counted in seconds 🌸. If that attribute is there, SAs MUST NOT refresh any given service advertisement more often than that number 🔥. If the DA gets SrvReg messages without the FRESH FLAG set, or SrvDereg messages with a non-empty tag list for a particular service, more often than the DA's advertised "min-refresh-interval", the DA SHOULD reject the message and send back a REFRESH_REJECTED error in the SrvAck 🙅.
The DA's URL is "service:directory-agent://"<addr>, where <addr> is the dotted decimal numeric address of the DA 🌈. The DA's <scope-list> MUST NOT be NULL 💀.
The SLP SPI List is the list of SPIs the DA can verify 🔐. SAs MUST NOT register services with authentication blocks for any SLP SPIs that aren't on that list. DAs will bounce any registration they can't verify, sending back an AUTHENTICATION_UNKNOWN error 🙃.
The format of DAAdvert signatures is defined in Section 9.2.1 🧾.
The SLP SPI used to verify the DAAdvert is included in the Authentication Block. When DAAdverts get multicast, they can end up needing several DAAdvert Authentication Blocks 📦. If the DA is set up to generate signatures for more than one SPI, the DA MUST include one Authentication Block for each SPI 🎯. If all those blocks won't fit in one datagram (to multicast or broadcast), the DA MUST send separate DAAdverts so that the Authentication Blocks for every SPI it can generate actually get sent 🚀.
If the DAAdvert is a reply to a SrvRqst, it only carries the authentication block for the SLP SPI in that SrvRqst, as long as the DA can produce digital signatures with that SLP SPI 🦢. If the SrvRqst is unicast to the DA (the REQUEST MCAST flag isn't set) and it includes an unsupported SLP SPI, the DA replies with a DAAdvert whose Error Code is AUTHENTICATION_UNKNOWN 😬.
UAs SHOULD be configured with SLP SPIs that let them verify DA Advertisements 🔑. If a UA has SLP SPIs configured and gets a DAAdvert that fails verification with all of them, the UA MUST discard it 🗑️.
8.6. Service Agent Advertisement 🌷
User Agents MUST NOT solicit SA Advertisements if they're configured to use a particular DA, if they've been given a <scope-list>, or if DAs have already been discovered 🙅♀️. UAs only solicit SA Advertisements when they're explicitly configured to use User Selectable scopes (see Section 11.2), so they can find out which scopes SAs support 🔍. That way, UAs with no scope configuration can use DAs or SAs with no functional difference except performance ⭐.
A SA MAY be configured with attributes, and SHOULD support the attribute 'service-type', whose value is every service type of the services the SA represents 🧁. SAs MUST NOT respond if the SrvRqst predicate isn't satisfied 🚫. For example, only SAs offering 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for service type "service:service-agent" that includes the predicate "(service-type=nfs)" 🐚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SAAdvert = 11) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+An SA only answers multicast SA discovery requests that either have no <scope-list> or name a scope the SA is set up to use 📡.
The SAAdvert MAY include a list of the attributes the SA supports 💫. This attribute list SHOULD be kept short, so the SAAdvert doesn't go over the path MTU in size 📏.
The SA's URL is "service:service-agent://"<addr>, where <addr> is the dotted decimal numeric address of the SA 🏠. The SA's <scope-list> MUST NOT be null 🙈.
The SAAdvert has one SAAdvert Authentication block for each SLP SPI the SA can make Authentication Blocks for 🪪. If the UA can verify the SAAdvert's Authentication Block and the SAAdvert fails verification, the UA MUST discard it 🫗.
9. Optional Features 🎁
The features in this section aren't required 💖. Some are handy for interactive use of SLP (say, a person picking services from a browsing interface instead of a program), and others help SLP scale up to bigger networks 🌐.
9.1. Service Location Protocol Extensions 🧩
Here's the format of a Service Location Extension:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Extension IDs get handed out like this 🎟️:
0x0000-0x3FFF Standardized. Optional to implement. Ignore if
unrecognized.
0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA
which receives this option in a reply and does not understand
it MUST silently discard the reply. A DA or SA which receives
this option in a request and does not understand it MUST return
an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF For private use (not standardized). Optional to
implement. Ignore if unrecognized.
0x9000-0xFFFF Reserved.Heads up 🚨: the 0x4000-0x7FFF range is the strict one. If a UA or SA gets one of those in a reply and doesn't understand it, it MUST silently discard the reply, and if a DA or SA gets one in a request it doesn't understand, it MUST return an OPTION_NOT_UNDERSTOOD error 💀.
The three byte offset to the next extension tells you where the next extension starts, counted from the beginning of the SLP message 📍.
If there are no extensions after the current one, the offset is 0 🫠.
When the offset is 0, you work out the length of the current Extension Data by taking the total length of the SLP message (from the SLP message header) and subtracting the offset of the current extension 🧮.
The extensions defined in this document live in Section D 📚. For the procedures you need when specifying new SLP extensions, check out section 15 🧠.
9.2. Authentication Blocks ✨
Okay bestie, here's the vibe: authentication blocks ride along with certain SLP messages so agents can check two things, that nobody messed with the contents and that an authorized agent actually sent them 🔐. The authentication data inside the Structured Authentication Block is usually case sensitive 🙈. Registration data like attribute values usually isn't case sensitive, but the registering DA still has to keep the original case, so UAs can verify the exact data that was used for the digital signature 💅.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Structure Descriptor | Authentication Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLP SPI String Length | SLP SPI String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Structured Authentication Block ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Block Structure Descriptor (BSD) tells you the format of the Authenticator that follows 🧚. BSDs 0x0000-0x7FFF are maintained by IANA, and BSDs 0x8000-0x8FFF are for private use 🌈.
The Authentication Block Length is the length of the whole block, counting from the BSD onward 🦋.
The Timestamp is when the authenticator expires, which is how replay attacks get shut down 🚫. It's a 32-bit unsigned fixed-point number of seconds counted from 0h on 1 January 1970. SAs use it to say when the validity of the digital signature runs out ⏰. Heads up, this Timestamp wraps back to 0 in the year 2106 😭. Once it wraps, the epoch it's measured from resets too. For example, after 06h28 and 16 seconds 5 February 2106, every Timestamp value is relative to that new epoch date 🗓️.
The SLP Security Parameters Index (SPI) string identifies the key length, algorithm parameters and keying material that agents use to verify the signature data in the Structured Authentication Block 🔑. It follows the same grammar as the <scope-val> from Section 6.4.1 🎀.
Any reserved characters in SLP SPI strings have to be escaped using the same convention used all throughout SLPv2 💖.
Here's the rule-set for the block, no cap:
- SLP SPIs deployed in a site MUST be unique. ✨
- An SLP SPI used for BSD=0x0002 must not be the same as used for some other BSD. 🙅♀️
- All SLP agents MUST implement DSA [20] (BSD=0x0002). 👑
- SAs MUST register services with DSA authentication blocks, and they MAY register them with other authentication blocks using other algorithms. 💜
- SAs MUST use DSA authentication blocks in SrvDeReg messages, and DAs MUST use DSA authentication blocks in unsolicited DAAdverts. 🔥
9.2.1. SLP Message Authentication Rules
Here's how you figure out the value that goes into the algorithm named by the BSD 🧮. Each component listed gets treated like one contiguous, byte-aligned buffer, in exactly the order given. Don't shuffle anything, periodt 💅.
URL
16-bit Length of SLP SPI String, SLP SPI String,
16-bit Length of URL, URL,
32-bit Timestamp.
Attribute List
16-bit Length of SLP SPI String, SLP SPI String,
16-bit length of <attr-list>, <attr-list>,
32-bit Timestamp.
DAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
32-bit DA Stateless Boot Timestamp,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of DA's <scope-list>, DA's <scope-list>,
16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>,
32-bit Timestamp.
The first SLP SPI is the SLP SPI in the Authentication
Block. This SLP SPI indicates the keying material and other
parameters to use to verify the DAAdvert. The SLP SPI List is
the list of SLP SPIs the DA itself supports, and is able to
verify.
SAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of <scope-list>, <scope-list>,
32-bit Timestamp.9.2.2 DSA with SHA-1 in Authentication Blocks
BSD=0x0002 is DSA with SHA-1, full stop 🦋. The signature calculation comes from [20]. The signature format follows the one in the X.509 v3 certificate, and it's made of three parts:
- The signature algorithm identifier (an OID)
- The signature value (an octet string)
- The certificate path.
Everything is represented in ASN.1 encoding 🧾. The algorithm identifier is:
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }Which is the ASN.1 encoding of 1.2.840.10040.4.3, immediately followed by:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }That's the binary ASN.1 encoding of r and s, computed using DSA and SHA-1 🔐. After that comes a certificate path, as defined by X.509 [10], [2], [3], [4], [5] 📜.
Authentication Blocks for BSD=0x0002 look like this. Future BSDs might get assigned different formats, so keep your eyes open 👀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 encoded DSA signature \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+9.3. Incremental Service Registration
Incremental registrations update attribute values for a service that's already registered 🔄. They're super handy when only one attribute changed, you know? ✨ For an incremental registration, the FRESH flag in the SrvReg header is NOT set 🙅♀️.
The new registration's attributes replace the old ones, but attributes that were included before and aren't in the update just stick around 🧚.
Here's an example. Say service:x://a.org was registered with attributes A=1, B=2, C=3. If an incremental registration for service:x://a.org comes in with attributes C=30, D=40, then after the update the attributes are A=1, B=2, C=30, D=40 💖.
Incremental registrations MUST NOT be performed for services registered with Authentication Blocks. ⚠️ These must be registered with ALL attributes, with the FRESH flag in the SrvReg header set. DAs that get these registration messages send back an AUTHENTICATION_FAILED error. 💀
If the FRESH flag isn't set and the DA doesn't have a prior registration for the service, the incremental registration fails with error code INVALID_UPDATE 🙈.
The SA MUST use the same <scope-list> in an update message as was used in the prior registration. If it doesn't, the DA returns a SCOPE_NOT_SUPPORTED error 😬. If you want to change the scope of a service advertisement, it MUST be deregistered first and then reregistered with a new <scope-list> 🔁.
The SA MUST use the same <service-type> in an update message as was used in a prior registration of the same URL. If that's not done, the DA returns an INVALID_UPDATE error 🫶.
9.4. Tag Lists
Tag lists show up in SrvDeReg and AttrReq messages 🏷️. Here's the syntax for a <tag-list> item:
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 give you features for user interaction and for efficiently updating service advertisements that have dynamic attributes 🧚.
10.1. Service Type Request
The Service Type Request (SrvTypeRqst) lets a UA discover all the types of service on a network 🔍. It's really 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> and <scope-list> are interpreted just like in Section 8.1 🫶.
The Naming Authority string, if it's in the request, limits the reply to Service Type strings with that Naming Authority 🎯. If the Naming Authority string is absent, the IANA registered service types get returned. And if the length of the Naming Authority is set to 0xFFFF, the Naming Authority string is omitted and ALL Service Types are returned, regardless of Naming Authority 👑.
10.2. Service Type Reply
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvTypeRply = 10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <srvType-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <srvtype--list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The service-type Strings (as described in Section 4.1) come back 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 don't include a Naming Authority string 🍓.
10.3. Attribute Request ✨
okay so the Attribute Request (AttrRqst) is how a UA goes hunting for the attributes of a service, either by giving the service's URL or by asking about a whole service type 🔍💖 That second option is lowkey genius because it lets the UA build a query by picking the features it wants. The UA can ask for every attribute, or just a few of them 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRqst = 6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <tag-list> string | <tag-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <PRList>, <scope-list> and <SLP SPI> strings are read exactly the same way as in Section 8.1 💅
The URL field comes in two flavours 🦋 It can be just a Service Type (see Section 4.1), like "http" or "service:tftp". When it's that, you get back all the attributes, and every value each attribute can have, for every service of that type. It can also be a full URL, like "service:printer:lpr://igore.wco.ftp.com:515/draft" or "nfs://max.net/znoo". With a full URL, you only get the attributes that are registered for that exact URL 🌸
The <tag-list> field is a <string-list> of attribute tags, as defined in Section 9.4, and it tells the AttrRply which attributes to send back. If you leave <tag-list> out, you get all the attributes ✨ Here's the big warning, though 💀 <tag-list> MUST be omitted and a full URL MUST be included whenever a SLP SPI List string is present, or the DA will reply with an AUTHENTICATION_FAILED error.
⚠️ bestie, this is the main gotcha: if there's an SLP SPI List string, drop the <tag-list> and put a full URL in. Otherwise the DA says AUTHENTICATION_FAILED 😭
10.4. Attribute Reply 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <attr-list> and the Authentication Block follow the exact same format as SrvReg (see Section 9.2.1) 🎀
Attribute replies SHOULD come back with the original capitalisation of the string registration intact 💅 That's because they're probably human readable, so the casing matters. If the AttrRqst was by service type, you get every attribute defined for that type, along with all of their values 🌈
Okay, this one is so important 😭 Even though white space is folded for string matching, attribute tags and values MUST be returned with their original white space preserved 🫶
Now the dedup part 🧹 Only one copy of each attribute tag or String value should be returned, and the reply gets to arbitrarily pick which version to keep, ignoring upper and lower case and the white space inside strings. Duplicate attributes and values SHOULD be removed. The tag name and string value that survive the merge are also arbitrary. For example, "(A=a a,b)" merged with "(a=A A,B)" might come out as "(a=a a,B)" 🦋
10.5. Attribute Request/Reply Examples 📚
Let's say some printer services have been registered like this 🖨️✨
Registered Service:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = en
Attributes = (Name=Igore),(Description=For developers only),
(Protocol=LPR),(location-description=12th floor),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
(Protocol=LPR),(location-description=13te Etage),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
scope-list = Development
Lang. Tag = en
Attributes = (Name=Not),(Description=Experimental IPP printer),
(Protocol=http),(location-description=QA bench),
(media-size=na-letter),(resolution=other),x-BUSYNotice that the first printer, "Igore", is registered in both English and German 🇩🇪 The < and > characters in the Operator value, which belong to the Email address, had to be escaped, because they're reserved characters for values 🙈
Attribute tags don't get translated, but attribute values can, see [13] 💜
Here's the Attribute Request:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
tag-list = resolution,loc*And it gets back this Attribute Reply:
(location-description=13te Etage),(resolution=res-600)Next up, another Attribute Request:
URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocolThis one gets an Attribute Reply containing:
(protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSYThe first request is by service instance and returns the requested values in German 🥨 The second one is by abstract service type (see Section 4), so it pulls values from both "Igore" and "Not" 💅
An attribute Authentication Block comes back if an authentication block with the SLP SPI from the AttrRqst can be returned 🔐 Heads up: the <attr-list> a DA sends back with an Authentication Block MUST be identical to the <attr-list> the SA registered, otherwise the authentication verification math can't work 🧮
A SA or DA only returns an Attribute Authentication Block if the AttrRqst included a full URL and no tag list 🎀
If an SLP SPI is named in a unicast request (the REQUEST MCAST flag in the header is not set) and the SA or DA can't return an Authentication Block with that SLP SPI, you get an AUTHENTICATION_UNKNOWN error 😬 The # of AttrAuths field is 0 when there's no Authentication Block included, and 1 when an Authentication Block follows ✨
10.6. Service Deregistration 🧹
A DA deletes a service registration once its Lifetime runs out 💀 That said, services SHOULD be deregistered as soon as they stop being available, instead of leaving the registrations to time out. Main character behaviour 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvDeReg = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <tag-list> | <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <scope-list> is a <string-list> (see section 2.1) 🧵
If the SA gets no response from the DA, it MUST retry (see Section 12.3) 🔁 The DA confirms a SrvDeReg with a SrvAck. Once the SA gets an acknowledgment that says it worked, the DA stops advertising the service and/or attributes. The DA removes the service or service attributes from every scope named in the SrvDeReg that they were previously registered in 🫧
The SA MUST deregister all services that use the same scope list it used to register them with a DA 🗂️ If that doesn't happen in the SrvDeReg message, the DA sends back a SCOPE_NOT_SUPPORTED error. The Lifetime field in the URL Entry gets ignored for SrvDeReg purposes 💅
The <tag-list> is a <string-list> of attribute tags to deregister, as defined in Section 9.4 🏷️ If there's no <tag-list>, the SrvDeReg deregisters the service in every language it was registered in. If there is a <tag-list>, the SrvDeReg deregisters only the attributes whose tags are listed in it. Services registered with Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg message, because the DA will reply with an AUTHENTICATION_FAILED error in that case 🙅♀️
If the service being deregistered was registered with an authentication block or blocks, you have to include a URL authentication block for each SLP SPI it was registered with in the SrvDeReg. Otherwise the DA returns an AUTHENTICATION_ABSENT error. If the DA can't verify the message, it returns an AUTHENTICATION_FAILED error 🔐
11. Scopes 🌈
Scopes are sets of services, and their main job is to make administrative groupings 🎀 Network administrators can assign a set of services to a scope. A client looking for services is set up to use one or more scopes, so the user only finds the services that were configured for them to use. By configuring UAs and SAs with scopes, administrators can provision services 🧚 Scope strings are case insensitive, and the default SCOPE string is "DEFAULT" 💖
Scopes are the main tool an administrator has for scaling SLP deployments to bigger networks 📈 When DAs with NON-DEFAULT scopes are on the network, you get even more gains by setting UAs and SAs up with a predefined non-default scope. Those agents can then do DA discovery and make requests using that scope, which limits the number of replies 🦋
11.1. Scope Rules 📜
SLP messages that don't contain a scope the receiving Agent is configured to use get dropped if the request was multicast, or they get a SCOPE_NOT_SUPPORTED error if the request was unicast 🙈 Every SrvRqst (except for DA and SA discovery requests), SrvReg, AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a <scope-list> 🫶
A UA MUST unicast its SLP messages to a DA that supports the desired scope, and that's preferred over multicasting a request to SAs 💅 A UA MAY multicast the request if no DA is available in the scope it's configured to use 🌸
11.2. Administrative and User Selectable Scopes 🗂️
Okay so every request and service is scoped, no cap 💅 The only two exceptions are SrvRqsts for service:directory-agent and service:service-agent. Those MAY have a zero-length <scope-list> when they're used to let the user pick scopes 🎀 In that case UAs get their scope list from DAAdverts, or from SAAdverts if there are no DAs 🦋
Otherwise, if SAs and UAs want any scope besides the default (that's "DEFAULT" 💜), system admins configure the UAs and SAs with lists of scopes to use. Sometimes that happens automatically through DHCP option 78 or 79 [21]. Admin scoping is lowkey amazing because services get provisioned so users only see the services they're supposed to see ✨
User configurable scopes let a user discover any service, but they have to do their own scope selection 💀 It's kind of like how AppleTalk [12] and SMB [19] networking let users pick an AppleTalk Zone or workgroup 🌸
Heads up, bestie: these two configuration choices are not compatible ⚠️ One model gives admins control over service provision. The other hands that job to users, who might not be ready to configure anything on their system 🙈
12. Directory Agents 🧚
DAs cache service location and attribute information. They exist to level up the performance and scalability of SLP 📈 Multiple DAs add even more scalability and robustness, since each one can store service info for the same SAs. So if one DA fails, the others still have it 🫶
A DA is a centralized store for service info, which is super useful in a network with several subnets or lots of SLP Agents 🌈 The DA address can be configured dynamically with UAs and SAs using DHCP, or set statically.
SAs configured to use DAs with DHCP or static configuration MUST unicast a SrvRqst to the DA when the SA initializes. That SrvRqst leaves out the scope list and sets the service type to service:directory-agent ✨ The DA replies with a DAAdvert containing its attributes, SLP SPI list, and other parameters that are essential for proper SA-to-DA communication 💖
Passive detection of DAs by SAs means services get advertised consistently among DAs of the same scope 🦋 Advertisements expire if they aren't renewed, so only transient stale registrations are left in DAs, even if an SA fails 💀
A single DA can support many UAs. UAs send the same requests to DAs that they'd send to SAs, and they expect the same results. DAs take load off SAs, which makes simpler SA implementations possible 🍓
UAs MUST be ready for the possibility that the service info they get from DAs is stale 😭
12.1. Directory Agent Rules
When DAs are present, each SA MUST register its services with DAs that support one or more of its scope(s) 💅
UAs MUST unicast requests directly to a DA (when scoping rules allow), which means skipping the multicast convergence algorithm, to get service info. That cuts down network utilization and speeds up how fast UAs get service info 🔥
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 says when all previous registrations were lost, aka the last stateless reboot 🕰️ The Timestamp is set to 0 in a DAAdvert to tell UAs and SAs that the DA is going down 👋 DAs MUST NOT use equal or lesser Boot Timestamps than previous ones if they go down and restart without service registration state. Otherwise SAs would be misled into not reregistering with the DA 🙅
DAs that 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) doesn't include a scope they're configured to use. Otherwise the DA MUST respond with a DAAdvert ✨
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.)
12.2. Directory Agent Discovery
UAs can discover DAs using static configuration, DHCP options 78 and 79, or by multicasting (or broadcasting) Service Requests with the convergence algorithm in Section 6.3 🔍
Check out Section 6 for unsolicited DAAdverts. Section 12.2.2 explains how SAs can cut down how often they have to reregister with DAs when unsolicited DAAdverts show up 🙌
DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts passively, as described in Section 8.5. UAs MAY do this. If they don't listen for unsolicited DAAdverts, though, they won't discover DAs as they become available 😬 In that case UAs SHOULD do periodic active DA discovery, see Section 6.
A URL with the scheme service:directory-agent shows the DA's location as defined in Section 8.5. For example: service:directory-agent://foobawooba.org.
The following sections suggest timing algorithms that boost SLP's scalability 📊
12.2.1. Active DA Discovery
After a UA or SA restarts, its initial DA discovery request SHOULD be delayed for some random time uniformly distributed from 0 to CONFIG_START_WAIT seconds.
The UA or SA sends the DA Discovery request using a SrvRqst, as described in Section 8.1. DA Discovery requests MUST include a Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT be sent more than once per CONFIG_DA_FIND seconds.
After discovering a new DA, an SA MUST wait a random time between 0 and CONFIG_REG_ACTIVE seconds before registering its 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 that receive the unsolicited DAAdvert SHOULD examine its DA stateless Boot Timestamp. If it's set to 0, the DA is going down, and no further messages should be sent to it.
If a SA detects a DA it has never encountered (with a nonzero timestamp), the SA must register with it. SAs MUST examine the DAAdvert's timestamp to determine if the DA has had a stateless reboot since the SA last registered with it. If so, it registers with the DA. SAs MUST wait a random interval between 0 and CONFIG_REG_PASSIVE before beginning DA registration.
12.3. Reliable Unicast to DAs and SAs
If a DA or SA fails to respond to a unicast UDP message in CONFIG_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If a DA or SA fails to respond after CONFIG_RETRY_MAX seconds, the sender should consider the receiver to have gone down. The UA should use a different DA. If no such DA responds, DA discovery should be used to find a new DA. If no DA is available, multicast requests to SAs are used.
12.4. DA Scope Configuration
By default, DAs are configured with the "DEFAULT" scope. Administrators may add other configured scopes, in order to support UAs and SAs in non-default scopes. The default configuration MUST NOT be removed from the DA unless:
- There are other DAs which support the
"DEFAULT"scope, or - All UAs and SAs have been configured with non-default scopes.
Non-default scopes can be phased in as the SLP deployment grows. Default scopes should be phased out only when the non-default scopes are universally configured.
If a DA and SA are coresident on a host (quite possibly implemented by the same process), configuration of the host is considerably simplified if the SA supports only scopes also supported by the DA. That is, the SA SHOULD NOT advertise services in any scopes that are not supported by the coresident DA. This means incoming requests can be answered by a single data store, so the SA and DA registrations do not need to be kept separately.
12.5. DAs and Authentication Blocks
DAs are not configured to sign service registrations or attribute lists. They simply cache services registered by Service Agents. DAs MUST NOT accept registrations including authentication blocks for SLP SPIs which it is not configured with, see Section 8.5.
A DA protects registrations that are made with authentication blocks using SLP SPIs it is configured to use. If a service S is registered, a subsequent registration (which will replace the advertisement) or a deregistration (which will remove it) MUST include an Authentication Block with the corresponding SLP SPI, see Section 8.3 and Section 10.6.
Example:
A DA is configured to be able to verify Authentication Blocks with SLP SPIs "X,Y", that is X and Y.
An SA registers a service with an Authentication Block with SPI "Z". The DA stores the registration, but discards the Authentication Block. If a UA requests a service with an SLP SPI string "Z", the DA will respond with an AUTHENTICATION_UNKNOWN error.
An SA registers a service S with Authentication Blocks including SLP SPIs "X" and "Y". If a UA requests a service with an SLP SPI string "X", the DA will be able to return S (if the service type, language, scope and predicate of the SrvRqst match S). The DA will also return the Authentication Block with SLP SPI set to "X". If the DA receives a subsequent SrvDeReg for S (which will remove the advertisement) or a subsequent SrvReg for S (which will replace it), the message must include two URL Authentication Blocks, one each for SPIs "X" and "Y". If either of these were absent, the DA would return an AUTHENTICATION_ABSENT error.
13. Protocol Timing Defaults ⏰
Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a
complete multicast query
response (all values.)
CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA
discovery on reboot.
CONFIG_RETRY 12.3 2 seconds Wait interval before
initial retransmission
of multicast or unicast
requests.
CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast
request retransmission.
CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
before repeating Active
DA discovery.
CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle
connections.14. Optional Configuration ✨
Okay bestie, so this section is all the stuff an agent can be set up to do. Every one of these is a knob you can turn 🎛️
Broadcast Only 📡 Any SLP agent SHOULD be configurable to use broadcast only. Check out Sections 6.1 and 12.2 for the details 💅
Predefined DA 🏠 A UA or SA SHOULD be configurable to use a predefined DA. Hard-coding the DA location is a total power move 💪
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. So no searching around on its own, it just sticks with the DAs it was given 🫶
Multicast TTL 🌐 The default multicast TTL is 255. Agents SHOULD be configurable to use other values. A lower value focuses the multicast convergence algorithm on smaller subnetworks, which means fewer responses and better service location performance ✨ But heads up: UAs might get different results for the exact same request depending on where they're plugged into the network 👀
Timing Values ⏱️ Time values other than the default MAY be configurable. See Section 13 for all the timing tea ☕
Scopes 🎯 A UA MAY be configurable to support User Selectable scopes by omitting all predefined scopes. See Section 11.2 for that. 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. If nothing else is set, a DA defaults to the scope "DEFAULT" 🩷
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, so DHCP wins the popularity contest 🏆 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 🧾
Service Template 📝 UAs and SAs MAY be configured by using Service Templates. Besides making attribute values way easier to write, this also lets them enforce the inclusion of 'required' attributes in SrvRqst, SrvReg and SrvDeReg messages. DAs MAY be configured with templates so they can WARN UAs and SAs in those cases. See Section 10.4 🧚
SLP SPI for service discovery 🔐 Agents SHOULD be configurable to support SLP SPIs using the following parameters: BSD=2 (DSA with SHA-1) and a public key identified by the SLP SPI String. Later on, once a Public Key Infrastructure exists, SLP Agents may be able to grab public keys and cryptographic parameters that match the names used in SLP SPI Strings. Future vibes 🔮
Here's a fun one: if the SLP SPI string you pick is identical to a scope string, it's basically the same as a Protected Scope in SLPv1. Every SA advertising in that scope gets the same Private Key, and every DA and UA of that scope gets the matching Public Key to verify signatures. It's a super convenient way to set things up when there's no Public Key Infrastructure. Managing keys for UAs and DAs would be way too painful if every SA had its own key 😭
SLP SPI for Directory Agent discovery 🔍 Agents SHOULD be configurable to support SLP SPIs as above, for use when discovering DAs. This SPI SHOULD be sent in SrvRqsts to discover DAs, and it should be used to verify multicast DAAdvert messages 🛡️
SA and DA Private Key 🗝️ SAs and DAs which can generate digital signatures require a Private Key and a corresponding SLP SPI indentifier to include in the Authentication Block. The SLP SPI identifies the Public Key used to verify the digital signature in the Authentication Block. Basically, the key and the ID are a matched pair 💜
15. IANA Considerations 🗂️
SLP includes four sets of identifiers that may be registered with IANA. The policies for these registrations (See [18]) are noted in each case.
The Block Structure Descriptor (BSD) identifies the format of the Authenticator that follows. BSDs 0x8000-0x8FFF are for Private Use.
Further Block Structured Descriptor (BSD) values, from the range 0x0003-0x7FFF, may be standardized in the future by submitting a document that describes:
- The data format of the Structured Authenticator block.
- Which cryptographic algorithm to use (including a reference to a technical specification of the algorithm).
- The format of any keying material required for preconfiguring UAs, DAs and SAs. Also include any considerations regarding key distribution.
- Security considerations to alert others to the strengths and weaknesses of the approach.
The IANA will assign Cryptographic BSD numbers on the basis of IETF Consenus.
New function-IDs, in the range 12-255, may be standardized by the method of IETF Consensus.
New SLP Extensions with types in the range 2-65535 may be registered following review by a Designated Expert.
New error numbers in the range 15-65535 are assigned on the basis of a Standards Action.
Protocol elements used with Service Location Protocol may also require IANA registration actions. SLP is used in conjunction with "service:" URLs and Service Templates [13]. These are standardized by review of a Designated Expert and a mailing list (See [13].) 📬
16. Internationalization Considerations 🌍
SLP messages support multiple languages by providing a Language Tag field in the common message header (see Section 8). Bilingual energy 🗣️
Services MAY be registered in multiple languages. This gives you attributes so users with different language skills can pick services interactively 🫧
Attribute tags are not translated. Attribute values may be translated unless the Service Template [13] defines the attribute values to be 'literal' 💬
A service 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 isn't supported, a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply messages are always in the same language as the request 🙃
A DA or SA MAY be configured with translations of Service Templates [13] for the same service type. This lets the DA or SA translate a request (say, from Italian) into the language of the service advertisement (say, 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 that can be fulfilled by matching both language and dialect are preferred over those that match only the language portion. Otherwise, dialects have no effect on matching requests 🎀
17. Security Considerations 🔒
Okay this one is serious, so listen up 🫢
SLP provides for authentication of service URLs and service attributes. This gives UAs and DAs knowledge of the integrity of the service URLs and attributes in SLP messages. The only systems that can generate digital signatures are the ones administrators configured in advance. Agents that verify signed data may assume it is 'trustworthy' insofar as administrators have made sure the cryptographic keying of SAs and DAs reflects 'trustworthiness.'
Service Location does not provide confidentiality. Since the goal of this protocol is to advertise services to a community of users, confidentiality might not generally be needed in non-sensitive environments. Specialized schemes might be able to provide confidentiality in the future if it's needed. Sites that need confidentiality should implement the IP Encapsulating Security Payload (ESP) [3] to protect Service Location messages 🔐
Big warning here 🚨 If Agents are not configured to generate Authentication Blocks, and they're also not configured to verify them, an adversary could easily use this protocol to advertise services on servers they control and thereby gain access to users' private information. An adversary using this protocol would also find it much easier to run selective denial of service attacks. Sites in potentially hostile environments (for example, directly connected to the Internet) should weigh the benefits of distributing keys associated with SLP SPIs before deploying the sensitive directory agents or service agents. This is not a drill 😱
SLP is useful as a bootstrap protocol. It may be used in environments where no preconfiguration is possible. In those situations, a certain amount of "blind faith" is required: without any prior configuration, it's impossible to use any of the security mechanisms described above. SLP will make use of the key distribution mechanisms provided by the IETF Security Area as they become available. For now, the benefits of Authentication Blocks are only available if cryptographic information and SLP SPIs can be preconfigured on the end systems before they use SLP 🫠
SLPv2 enables a number of security policies with the mechanisms it includes. For instance, a SLPv2 UA could reject any SLP message that didn't carry an authentication block it could verify. That's not the only policy you could implement, though 🌈
A. Appendix: Changes to the Service Location Protocol from v1 to v2 ✨
okay bestie, SLPv2 is the glow-up 💖 It fixes the race conditions that were lowkey messing with SLPv1 [22] 😭 Authentication also got a whole makeover so it's more flexible and better protected, especially for DA Advertisements 🔐 SLPv2 changes the formats and definitions of a bunch of flags and values 🎀 and it cuts down on the number of 'required features' 💅 The whole Scopes situation got clarified too, and unscoped directory agents and unscoped requests are gone 🙅♀️ It uses LDAPv3 compatible string encodings for attributes and search filters 🧚 And the Language and Character set handling now follows practices recommended by the Internet Engineering Steering Group 🌈
Real talk, the designers wanted SLPv2 to act the same whether DAs are around or not 🦋 That's why there's a brand new message, the SAAdvert ✨ It lets UAs find out about scope information even when there's no admin configuration and no DAs, and SLPv1 could not do that at all 🙈
SLPv2 is incompatible with SLPv1 in some ways, so heads up 💀 If a DA supports both versions with the same scope, then services advertised by SAs using either version can be seen by both SLPv1 and SLPv2 UAs 🫶 SLPv1 DAs SHOULD be phased out and replaced with SLPv2 DAs that support both versions of the protocol 🍓
SLPv1 let services be advertised and requested with no scope, and DAs could be set up with no scope either. That's incompatible with SLPv2 and causes scalability problems 😬 So for a smooth migration, SLPv1 agents MUST use scopes for all registrations and requests, and SLPv1 DAs MUST be configured with a scope list 👑 This is a revision of RFC 2165 [22] 📜
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 🌸
Service Agents can advertise services without attributes 🍃 This only enables discovery of services by type. Service types found this way have a Service Template [13] that explicitly says no attributes are associated with the advertisement. Service types whose Service Templates specify attributes MUST NOT be advertised by SAs that don't support attributes 🚫
Discovering by service type is a subset of what SLPv2 can do, but it matches the current generation of products that let people casually browse every service in a 'zone' or 'workgroup' by type 👀 In some cases, attribute discovery, security and feature negotiation are handled by application layer protocols, so all that's really needed is basic discovery of services that support a certain service 💖
UAs that only want services of a given type only need to support the service type and scope fields of the Service Request 🎀 They still do DA discovery, and once they find DAs in their scope, they send unicast SLPv2 SrvRqst messages to those DAs instead of multicasting ✨
SAs also do DA discovery and use an SLPv2 SrvReg to register all their advertised services with SLPv2 DAs in their scope 🫧 Obviously, these advertisements contain no attribute string 🙃
These minimal SAs can ignore the Language Tag in requests, since SrvRqst messages contain no attributes and that means no strings get internationalized 🌍 Also, any non-null predicate string will fail to match an advertisement with no attributes, so these SAs don't have to parse and interpret search filters 🧠 Overflow never happens in SrvRqst, SrvRply or SrvReg messages, so TCP message handling doesn't have to be implemented 🚀 And finally, the SA can drop all AttrRqst messages, since no attributes are supported 💅
C. Appendix: DAAdverts with arbitrary URLs 🦋
Using Active DA Discovery, you send a SrvRqst with its service type field set to "service:directory-agent" ✨ DAs respond with a DAAdvert that contains a URL with the "service:directory-agent:" scheme 💌 It's the same DAAdvert that such a DA would multicast in unsolicited DA advertisements 📣
A UA or SA that receives an unsolicited DAAdvert MUST examine the URL to determine whether it has a recognized scheme. If the UA or SA doesn't recognize the DAAdvert's URL scheme, the DAAdvert is silently discarded 🤫 This document only specifies how to use URLs with the "service:directory-agent:" scheme 📝
This leaves room for forward compatibility with future versions of SLP 🔮 and it lets other services advertise that they can act as a clearinghouse for service location information 🏠
For example, if LDAPv3 [15] is used for service registration and discovery by a set of end systems, they could interpret an LDAP URL [16] to passively discover the LDAP server to use for this purpose 🧚 This document doesn't say how that's done. SLPv2 agents without further support would simply discard this DAAdvert 🗑️
D. Appendix: SLP Protocol Extensions 🎀
D.1. Required Attribute Missing Option 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type = 0x0001 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template IDVer Length | Template IDVer String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Required Attr <tag-list> Length| Required Attr <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Required attributes and the format of the IDVer string are defined by [13] 📖
If a SA or DA receives a SrvRqst or a SrvReg that fails to include a Required Attribute for the requested Service Type (according to the Service Template), it MAY return the Required Attribute Extension along with the reply to that message 🙌 The sender SHOULD reissue the message with a search filter that includes the attributes listed in the returned Required Attribute Extension 🔁 In the same way, the Required Attribute Extension may be returned in response to a SrvDereg message that contains a required attribute tag 🏷️
The Template IDVer String is the name and version number string of the Service Template that defines the given attribute as required 🧾 It SHOULD be included, but it can be left out if a given SA or DA has been individually configured to have 'required attributes' ⚙️
The Required Attribute <tag-list> MUST NOT include wild cards. 🚫✨
E. Acknowledgments 🫶
This document pulls in ideas from work on several discovery protocols, including RDP by Perkins and Harjono, and PDS by Michael Day 🙏 Thanks to Ye Gu and Peter Ford for their contributions 💕 John Veizades was instrumental in standardizing the Service Location Protocol 👑 And implementors at Novell, Axis Communications and Sun Microsystems contributed a ton to make this a much clearer and more consistent document 🌟
F. References 📚
- [1] Port numbers, July 1997.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. - [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 4 to ISO/IEC 9594-2, December 1996.
- [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 2 to ISO/IEC 9594-6, December 1996.
- [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-7, December 1996.
- [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-8, December 1996.
- [6] Unicode Technical Report #8. The Unicode Standard, version 2.1. Technical report, The Unicode Consortium, 1998.
- [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
- [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [10] CCITT. The Directory Authentication Framework. Recommendation X.509, 1988.
- [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. Addison-Wesley, 1990.
- [13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.
- [14] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
- [15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
- [16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
- [17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
- [18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998.
- [19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, Document Version 1.09, November 1989.
- [20] National Institute of Standards and Technology. Digital signature standard. Technical Report NIST FIPS PUB 186, U.S. Department of Commerce, May 1994.
- [21] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
- [22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.
- [23] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
G. Authors' Addresses 🌷
Erik Guttman
Sun Microsystems
Bahnstr. 2
74915 Waibstadt
Germany
Phone: +49 7263 911 701
EMail: Erik.Guttman@sun.comCharles Perkins
Sun Microsystems
901 San Antonio Road
Palo Alto, CA 94040
USA
Phone: +1 650 786 6464
EMail: cperkins@sun.comJohn Veizades
@Home Network
425 Broadway
Redwood City, CA 94043
USA
Phone: +1 650 569 5243
EMail: veizades@home.netMichael Day
Vinca Corporation.
1201 North 800 East
Orem, Utah 84097 USA
Phone: +1 801 376-5083
EMail: mday@vinca.comH. Full Copyright Statement 💖
Copyright (C) The Internet Society (1999). All Rights Reserved. 🎀
Okay bestie, this part is the legal bit, but it's still a vibe. You're allowed to copy this document and hand it to other people, and you can translate it too. You can also write derivative works that comment on it, explain it, or help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. ✨
The original document itself is a no-touch zone 🙅♀️. You can't modify it in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is if you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process. The second is if you want to translate it into a language other than English. 🌈
These permissions are forever 🦋. The Internet Society or its successors or assigns can't take them back.
The document and everything in it is provided on an "AS IS" basis, and honestly the Internet Society and the Internet Engineering Task Force are not promising anything. They disclaim all warranties, and that includes the no-infringement one and the implied ones for merchantability and fitness for a particular purpose 😭:
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Last but not least, the shout-out. Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 So the people keeping these documents tidy and published have their lights on because of ISOC. Iconic support 👑.
📦 where this page comes from
- ietf: rfc2608 1999-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms