RFC 3105

Finding an RSIP Server with SLP

📅 published October 2001, from ietf

Finding an RSIP Server with SLP 🧚

  • RFC: 3105
  • Stream: Network Working Group
  • Authors: J. Kempf (NTT DoCoMo USA Labs) and G. Montenegro (Sun Microsystems) 👑
  • Category: Experimental 🧪
  • Date: October 2001 📅
  • Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🫶

Status of this Memo 🌸

Okay so this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈 Discussion and suggestions for improvement are totally welcome, and distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 💖

IESG Note 💀

The IESG is flagging that the RSIP documents imply some serious host and gateway changes for a full implementation 😭 On top of that, floating port numbers can cause problems for some applications, so an RSIP-enabled host might not interoperate transparently with existing apps in some cases (IPsec is the example they give) 🙈 There may also be significant operational complexities with RSIP. Some of these complications are outlined in section 6 of the RFC 3102, and more are in the Appendices of RFC 3104 📚 So the costs and benefits of using RSIP need to be carefully weighed against other ways of relieving address shortage 🍓

Abstract 🦋

This doc has an SLP service type template that describes the advertisements RSIP servers make for their services. SLP (Service Location Protocol) is an IETF standards track protocol built specifically so clients can find servers offering particular services 🧚 RSIP (Realm Specific IP) clients need a way to discover RSIP servers, so SLP is a natural match, honestly iconic 💅 The service type template is the basis for an IANA (Internet Assigned Numbers Authority) standard definition of the advertisements RSIP servers offer, which is a big step toward interoperability 🌈

Table of Contents 📖

1.  Introduction ...............................................  2
2.  Notation Conventions .......................................  2
3.  Terminology ................................................  2
4.  Using SLP for RSIP Service Discovery .......................  3
5.  Using Scopes for Server Provisioning .......................  4
6.  Load Balancing .............................................  6
7.  The RSIP Service Type Template .............................  7
8.  Security Considerations ....................................  9
9.  Summary ....................................................  9
References .....................................................  9
Authors' Addresses ............................................. 10
Full Copyright Statement ....................................... 11

1. Introduction ✨

Realm Specific IP (RSIP) [7] lets an RSIP client in one realm borrow addresses and other resources from a different realm 🦋 It does this by doing an RSIP protocol [1] exchange with an RSIP server. The RSIP protocol requires the RSIP server to have a permanent presence on both realms, which is a big ask but that's the deal 💅

There are a bunch of traditional ways an RSIP client could find the right RSIP server 🧐 But Service Location Protocol (SLP) [2][11] is an IETF standards track protocol designed specifically to help clients locate services and their servers, and it has a bunch of features that make finding RSIP servers way easier 🎀 In this doc, we walk through how RSIP clients can use SLP to discover RSIP servers 🫶

2. Notation Conventions 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. These are the special capital words that carry real weight, so read them carefully bestie 🧠

3. Terminology 🎀

Here we're reproducing some SLP terminology from [2] for anyone who isn't familiar with SLP yet 📚

User Agent (UA)

A process working on the user's behalf to establish contact with some service. The UA gets service information from the Service Agents or Directory Agents 🙌

Service Agent (SA)

A process working on behalf of one or more services to advertise the services and their capabilities 📣

Directory Agent (DA)

A process that collects service advertisements. There can only be one DA present per given host, no more, no less 🏠

Scope

A set of services, usually making up a logical administrative group 🗂️

Service Advertisement

A URL, attributes, and a lifetime (indicating how long the advertisement is valid), giving service access information and a capabilities description for a particular service 🪪

4. Using SLP for RSIP Service Discovery 💅

SLP is the framework where RSIP clients and servers make contact 🤝 Here's how an RSIP server and client find each other using SLP, step by step:

  1. The RSIP server implements an SLP SA, and the RSIP client implements an SLP UA 🧩
  2. The RSIP SA builds a service advertisement made of a service URL, attributes, and a lifetime. The URL has the service type service:rsip, and its attributes follow the template in Section 7 📝
  3. If an SLP DA is found, the SA contacts the DA and registers the advertisement. If no DA is found, the SA keeps the advertisement itself and answers multicast UA queries directly 📮
  4. When the RSIP client needs contact info for an RSIP server, the UA either contacts the DA using unicast or the SA using multicast. The UA includes a query based on the attributes to say what kind of server it's after 🔍
  5. Once the UA has the host name or address of the RSIP server plus the port number, it can start negotiating with the RSIP protocol 🚀

This procedure is exactly the same for any client/server pair implementing SLP. It is not specific to RSIP, so it's giving universal 🌸

Lots of protocols use a mix of traditional methods for service discovery. These include static configuration, purpose-built protocols for discovery, special features in the protocol itself, DNS SRV RRs [5], or DHCP [6] 🧃 SLP has a few advantages over these traditional methods, and they're honestly so good 👑

  1. Discovery with SLP is dynamic, while a lot of the traditional methods only allow static or weakly dynamic discovery (meaning it's hard to update). Clients only discover services that are actually active with SLP 💖 Also, if a server goes down after the initial discovery, the client can reissue an SLP query and get a new server. On the server side, nobody has to update any databases to get dynamic discovery, since the servers advertise themselves 🦋
  2. SLP needs no third party configuration. Only the server offering the service and the client seeking it have to know the details for the particular service type 🙅‍♀️
  3. SLP lets clients specify the attributes describing the server they want, so a client finds only servers that meet a specific set of requirements. This cuts down the network traffic used to pick a server when there are lots of options 🧚
  4. SLP has a bunch of scaling mechanisms (DAs, scopes, and the multicast convergence algorithm) that make it easy to deploy in big enterprise networks as well as smaller ones 🏢

5. Using Scopes for Server Provisioning 🦋

One design feature of SLP that's super useful for RSIP is scopes ✨ In SLP, scopes are a mechanism for provisioning access to particular service advertisements. An administrator assigns UAs and SAs to particular scopes so that UAs only find SAs in those scopes 🗺️ Scopes are not an access control mechanism for the service itself though. UAs from outside the scope can still access services in a particular scope (unless the service itself provides access control). They just won't be able to find those services using SLP 🙈

Scopes are useful for RSIP service advertisement provisioning because they let a system administrator tie particular RSIP clients to specific RSIP servers 💅 For example, think about the network architecture described in Section 4.2.1 of [7]. RSIP clients are recommended to find "the nearest" RSIP server, but exactly how that should be arranged is left unspecified 🤷‍♀️ SLP gives system administrators a way to precisely specify which realm an RSIP client resides in, by tying the realm to an SLP scope. The diagram from Section 14.1 is reproduced below, with SLP scopes added to show how clients could be directed to the right RSIP servers 🌈

                             +-----------+
                             |           |
                             |   RSIP    |
                             |  server   +---- 10.0.0.0/8
                             |     B     |   SLP Scope: B
                             |           |
                             +-----+-----+
                                   |
                                   | 10.0.1.0/24
                    +-----------+  | (149.112.240.0/25)
                    |           |  |
    149.112.240.0/24|    RSIP   +--+
    ----------------+   server  |    SLP Scope: A
                    |      A    +--+
                    |           |  |
                    +-----------+  | 10.0.2.0/24
                                   | (149.112.240.128/25)
                                   |
                             +-----+-----+
                             |           |
                             |   RSIP    |
                             |  server   +---- 10.0.0.0/8
                             |     C     |     SLP Scope: C
                             |           |
                             +-----------+

Clients on the upper 10.0.0.0/8 network are configured to use SLP scope B, while clients on the lower 10.0.0.0/8 network are configured to use SLP scope C 🎀 RSIP servers B and C (as clients of server A) use SLP to locate RSIP server A, and so do the other RSIP clients on the 10.0.1.0/24 and 10.0.2.0/24 subnets. Inside these two subnets, all clients have their scopes configured to be A 💖

Heads up, specifying a particular SLP scope for RSIP clients does not restrict the SLP scope for other services advertised by SLP 👀 SLP UAs can be configured for multiple scopes, so the scope configured for printing might be different from the scope configured for RSIP service 🖨️

Since SLP scopes are configured through a DHCP option [8], along with the IP address, system administrators can easily switch a cluster of machines from one realm to another by just changing the scope and IP address assignments on the DHCP server 🪄 For example, in the architecture above, say a system administrator wanted to remove RSIP server B so that clients on the upper 10.0.0.0/8 subnet were directly on subnet 10.0.1.0/24. Those clients now communicate with RSIP server A. By simply changing the address assignments and scope configuration of these clients on the DHCP server, the realm can be effectively switched, and honestly that's main character energy 👑🔥

6. Load Balancing ⚖️✨

okay bestie, SLP doesn't have a built-in load balancing feature 😭 but you can totally build one with it 💅 the only thing you need is for your service type template to have an attribute that tells everyone how loaded the server is. for RSIP, the template in Section 7 has exactly that, and it counts how many RSIP client sessions the server is currently handling 🎀

the RSIP server has to keep updating its service advertisement as new connections get accepted, so the numbers stay fresh 🔥 then an RSIP client looking for the least busy server runs this little routine:

  1. As in Section 4, the client issues an SLP service request and collects all the returned service URLs.
  2. For each service URL, the client performs an SLP attribute request for the attribute LOAD. The integer load figures are returned.
  3. The client sorts through the returned load figures and selects the URL having the least number of connections. The client establishes its RSIP session with that server.

ngl this isn't a perfect guarantee 🙈 because of network delays you might not always land on the absolute lightest server, but it gives you a really high chance of picking one that's way less busy than the rest 🦋

also, this same kind of trick is used in [9] to balance access to TN3270E telnet servers 🧚

7. The RSIP Service Type Template 🎀

this section is the actual template, so the formatting here is serious business 💅 the submitters, the language, and the security note all live in this block:

Name of submitters: James Kempf <james@docomolabs-usa.com>
                    Gabriel Montenegro <gab@sun.com>

Language of service template: en

Security Considerations:
   RSIP clients can use Service Location Protocol to find RSIP
   servers having particular security characteristics.  If secure
   access to such information is required, SLP security should be
   used.

and here's the template text itself, copied exactly as it is 🫶 don't touch a single character, bestie:

----------------------template begins here -------------------------
template-type = rsip

template-version = 0.0

template-description=
   The service:rsip type provides advertisements for clients seeing
   realm-specific IP (RSIP) servers.  RSIP servers use the Realm
   Specific IP protocol to manage addresses and other resources
   from one realm on behalf of a client in another realm.

template-url-syntax=
   ;No additional URL path information required.  An example service
   ;URL for an RSIP server is: service:rsip://gateway.mydomain:4455

ipsec-support = BOOLEAN O
   #True if the server supports IPSEC as per [10]

ike-support = BOOLEAN O
   #True if the server supports IKE as per [10]

tunnel-type = STRING L M O
IP-IP
   #The tunneling methods supported by the RSIP server.  Clients
   #should include this attribute in a query so that they obtain a
   #server offering a tunneling method for which they have
   #support.  Default is IP-IP.  The values are currently
   #restricted to IP-IP, L2TP, GRE and NONE.  A server can support
   #multiple tunnel types.
IP-IP,L2TP,GRE,NONE

transport = STRING L M O
TCP
   #Transport used by the RSIP protocol itself.
TCP,UDP

load = INTEGER O
   #If the server supports load balancing, this attribute should be
   #set to an integer from 0 to 100.  0 is the lowest indication of
   #load and 100 the highest.  Clients can query for this attribute
   #and obtain load information, from which they can make an
   #intelligent decision about which server to use.
----------------------template ends here ---------------------------
⚠️ heads up: the template is what tells clients how to read everything SLP gives them, so mess with it and things can break in weird ways 💀

8. Security Considerations 🔐

okay this part is super important so pay attention 👑 service type templates are what clients use to make sense of the info they get through SLP. if the RSIP template gets changed, or someone hands out a fake one, RSIP servers might not register themselves properly, and RSIP clients might not be able to understand the service info at all 😭

SLP has an authentication mechanism so UAs can make sure service advertisements only come from trusted SAs [2]. if trust matters, especially for what the client is trying to learn about IPSEC and IKE support, then SLP authentication should be turned on in the network 🔥

9. Summary 🌸

so basically, this document shows how RSIP clients can use SLP to find RSIP servers 🦋 it gives you a service type template for the RSIP SLP service type, plus a few tricks for setting up access to service advertisements for particular gateway servers, and for load balancing with SLP 💖 the big payoff is RSIP service provisioning that's way more dynamic and robust than what you get with traditional service discovery mechanisms ✨

References 📚

  • [1] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, April 2001.
  • [2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
  • [3] Guttman, E, Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
  • [4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
  • [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [7] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
  • [8] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, July 1999.
  • [9] Naugle, J., Kasthurirangan, K. and G. Ledford, "TN3270E Service Location and Session Balancing", RFC 3049, January 2001.
  • [10] Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.
  • [11] E. Guttman, "Service Location Protocol: Automatic Discovery of IP Network Services," IEEE Internet Computing, July/August 1999. Available at: http://computer.org/internet/ic1999/w4toc.htm

Authors' Addresses 💌

Questions about this document may be directed to:

James Kempf
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA
95110

Phone: 408-451-4711
Email: james@docomolabs-usa.com


Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan
FRANCE

Phone: +33 476 18 80 45
EMail: gab@sun.com

the legal bits are kept word for word on purpose, so nothing gets lost 🫶

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from