RFC 3082

Notification and Subscription for SLP

📅 published March 2001, from ietf

Notification and Subscription for SLP ✨

Okay bestie, let's get into this one 🦋. It's an RFC by J. Kempf and J. Goldschmidt from Sun Microsystems, dated March 2001. Its category is Experimental, so it's a proposal the community is poking at, not an Internet standard 🧪. The title block doesn't list anything it obsoletes or updates, so there's no drama with older RFCs here 💅.

Status of this Memo 📜

This memo defines an Experimental Protocol for the Internet community 🔬. It doesn't specify an Internet standard of any kind. Discussion and suggestions for improvement are requested, so if you've got ideas, speak up 🗣️. Distribution of this memo is unlimited 🌈.

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

Abstract 🌸

So the Service Location Protocol (SLP) is the thing that lets service agent clients advertise services and user agent clients go looking for them 🔍. The whole design is super demand-driven, which means user agents only get service info when they actually ask for it 🙃. BUT there's a whole other class of user agent apps that need a heads-up whenever a new service shows up or disappears 👀. In the RFC 2608 design, those apps are stuck polling the network over and over just to catch changes, which is so exhausting 😭. This document describes a protocol that lets those clients get notified when something changes, so the constant polling can go away 🎀.

1. Introduction 💖

The Service Location Protocol (SLP) [1] gives service agent (SA) clients a way to advertise network services, and gives user agent (UA) clients a way to find them ✨. It's demand-driven, meaning UAs get service info by actively querying for it, and they don't get anything unless they ask 🙋‍♀️. That works great for most apps, but some apps need fresher info about services they care about appearing or disappearing 🥺.

Ideally, those apps want a ping the moment a new service comes up or when one goes away 🔔. The catch is that with SLP as described in RFC 2608, those apps have to keep polling the network on a schedule to refresh their local cache of service advertisements 😩.

Here's a relatable example: a desktop GUI that wants to show network service icons the second they appear, so users always see an accurate picture of every service available to them 🖥️✨.

Polling is inefficient and wastes network and processor resources, which is not it 🙅‍♀️. So we want to give these apps a way to be explicitly notified of changes instead. This document describes a scalable mechanism that lets UAs get notified when service availability changes 🦋.

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 RFC 2119 [2]. Those are the official keywords, so read them as the RFC 2119 meanings 🤓.

3. Terminology 📖

In this section, the doc adds some extra terms on top of the ones in [1] and [3] 🧠.

Notification - A message sent to an interested agent to tell that agent a service has appeared or disappeared 🔔.

Subscription - A request to be told about changes in service availability for a particular service type and set of scopes 📬.

4. Design Considerations 🎯

The main goal for a notification protocol in SLP is that it's just as scalable and robust as base SLP already is 💪. Notification should work in tiny networks with only a few SAs, and also in huge enterprise networks with thousands of SAs and hundreds of DAs 🏢. Small networks shouldn't be required to deploy DAs just to get the perks of notification 🙌. We also want to make sure notification in big networks doesn't dump heavy processing loads onto one SLP agent 😤. That means the notification job needs to be distributed instead of centralized, so no single agent gets buried doing all the work 🐝. And finally, notification should hold up when DAs fail, just like base SLP does 🛡️.

Timeliness matters too: UA clients should get notifications of SA events quickly 🏃‍♀️. If a UA has subscribed to a particular service type, it should get that notification no matter what state the DAs in between are in 🫧. SLP is transparent about DAs that support a particular scope, which means a UA can use any DA with that scope and expect the same service advertisements back 🔁. Notifications should work the same way. Whether a UA gets a notification shouldn't depend on which DA it happens to connect to, because that keeps the DAs' identity as a pure cache 💜.

Another goal: notification messages should carry enough info about the event that the UA can tell if it cares in the vast majority of cases, without having to send another SLP request first 🕵️‍♀️. The UA can still send an SLP request for other reasons, but in most cases it shouldn't need one just to learn more about the event that triggered the notification 🙅‍♀️. That keeps the network traffic tied to the event small 🪶.

To keep implementation simple, we want similar mechanisms for notification in both large and small networks 🧩. They won't be identical, obviously, but we don't want totally different mechanisms that need completely separate implementations 😵‍💫. Similar mechanisms mean less code in UA and SA clients, which is a whole vibe 💅.

A minor goal is to reuse existing SLP message types and mechanisms wherever possible ♻️. That cuts down the code needed for notification, since a lot of code can be shared between base SLP and the notification mechanism 🧃. In particular, the plan is to use the SLP extension mechanism in certain cases to support subscription 🔌.

5. Notification Design Description 🌈

To support scalability, the design is split into two parts 🪓. A small network design is used when there are no DAs in the network, and a large network design is used in networks that do have DAs 🏘️. The following subsections describe the two designs.

5.1 Small Network Design 🐣

In networks without DAs, UAs are notified by an SA when that SA first appears and when it disappears 👋. That lets UAs know which service types the SA supports 📋. In small networks there's no centralized agent around to handle subscriptions for newly appearing SAs 😬. That rules out any subscription design where a UA subscribes to a particular service type in particular scopes of interest. The reason is that a newly appearing SA can't tell whether there are any subscriptions, because nobody centralized is there to tell it 🤷‍♀️.

So instead, SAs send notifications when they come online and right before they shut down, no matter their scope or service type, as long as they're capable of doing notification 🔛. That means a UA gets notified about every type of change for every scope and every service type, and it has to be ready to filter out the stuff it doesn't care about (other scopes, other service types) 🗑️.

The design requires SAs to send notifications by IP multicasting (or broadcasting in IPv4 if multicast isn't available) SLP SrvReg or SrvDereg messages, using the multicast transmit algorithm described in Section 9.0 📡. The notification port isn't the default SLP port, because on some operating systems that port is only accessible to privileged users 🔒. Instead, notifications use port 1847, which is assigned by IANA 🎟️.

In IPv4, the SA multicasts on the SLP multicast address 239.255.255.253, with a default TTL of 255, and it's administratively scoped the same way SLP is [4] 🌍. IPv4 UAs that want notifications join the multicast group 239.255.255.253 and listen on port 1847 👂.

In IPv6, the multicast goes to the scoped IPv6 addresses for the service type being advertised, as described in [8] 🧭. The SA advertises on every address up to and including the largest multicast scope it supports 📶. IPv6 UAs that want notifications join the multicast groups for the scopes and service type they care about, and listen on port 1847 🎧. For example, an IPv6 UA with access to site local scope that's interested in a service type whose hash is 42 (calculated using the algorithm in [8]) joins the groups FF01:0:0:0:0:0:10042 through FF05:0:0:0:0:0:10042 🌟.

5.2. Large Network Design ✨

Okay so in networks with DAs 🏠, a DA that supports a particular scope can act as an intermediary for managing UA subscriptions 💅. A subscription is a service type plus a collection of scopes. A UA that wants to hear about changes to a particular service type attaches the Subscribe extension to a SrvRqst it sends to the DA. The DA grabs multicast group addresses for notification using the algorithm in Section 8.0 and tucks them into a NotifyAt extension, which rides along on the SrvRply. Then the UA listens on the group addresses from that reply for notifications 🔔.

When a new subscription shows up, existing SAs need to hear about it, and the DA handles that like this 💌. It compares the service type and scopes of the new subscription against its list of existing subscriptions. If no previous subscription has the same service type and scopes, the DA MUST multicast a DAAdvert using the multicast transmit algorithm in Section 9.0, and it MUST include the NotifyAt extension with the multicast group addresses for notification. But if an existing subscription already covers the same service type and scopes as the new one, the DA MUST NOT multicast a DAAdvert 🙅‍♀️.

A DA MUST keep track of the subscriptions it arranged, plus subscriptions arranged by other DAs in any scopes the DA is configured with 🧠. To avoid a pile of multicast NotifyAt messages, a DA MUST wait a random amount of time, uniformly distributed between 0 and 3 seconds, before sending the multicast DAAdvert with NotifyAt ⏳. During that wait, the DA MUST listen for NotifyAt messages that match the one from the new subscription. If it detects a matching NotifyAt, the DA MUST not multicast. 👀

When a new SA registers with a DA that already has subscriptions, the new SA gets told which notifications it should perform 📣. If the service type and scopes in the new SA's SrvReg messages match an existing subscription, a NotifyAt containing the multicast addresses for notification MUST be included in the SrvAck. An SA that doesn't support notification just ignores the extension 🙈. If the service type and scopes in the new SA's SrvReg do not match any existing subscriptions, the DA MUST NOT include a NotifyAt.

The DA itself MUST also perform notification, using the multicast transmit algorithm, when a service advertisement times out ⏰. When that happens, the DA multicasts a SrvDereg for the deregistered URL. That way, interested UAs can find out the service is gone even if the SA vanished without deregistering 👻. A DA MUST NOT perform notification when it receives a SrvReg from an SA, though, because that's the SA's job 🙌.

As in small networks, notification is mostly done by SAs 💖. If an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the following conditions are met:

  1. The SA supports notification.
  2. The SA's service type matches the service type in the NotifyAt extension.
  3. The SA's scopes match one of the scopes of the NotifyAt extension.

then the SA saves the multicast addresses that correspond to the scopes and service types it supports. The SA MUST perform notification immediately after the SA has performed the SrvReg or SrvDereg with the DA. An SA that has detected a DA in its scopes MUST NOT multicast any notifications unless it receives a NotifyAt extension in a SrvAck with service type and scopes matching the SA's service type and scopes. 🔥

6. Subscribe Extension 💜

The Subscribe extension has the following format:

     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 = 0x0004    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ex. Len. (ct) | Abs. Type Fl. |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The scope list and service type of the extension are taken from the accompanying SrvRqst. The abstract type flag tells you whether the UA is interested in hearing from all SAs advertising concrete instances of an abstract type [3]. It only matters if the service type in the SrvRqst is a concrete type. If the flag is 1, the UA is interested in hearing from all SAs advertising concrete types that have the same abstract type as the type of the SrvRqst. If the flag is 0, the UA is only interested in hearing from SAs supporting the particular concrete type in the SrvRqst. If the service type in the accompanying SrvRqst is not a concrete type, the flag gets ignored 🤷‍♀️.

7. NotifyAt 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 Type = 0x0005    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. Len (ct) |  Subscription Lifetime        |SGL List Len.  \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |SGL L. Len (ct)|       Scope/Group List                        \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length of Service Type Name  |        Service Type Name      \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The service type name is in the same format as in the SrvRqst. The scope/group list is a list of scope names and multicast group addresses. The following ABNF [5] syntax describes the list:

     sglist          = sgitem / sgitem "," sglist
     sgitem          = scope-name ":" ip-addr
     ip-addr         = ipv4-number | ipv6-number
     scope-name      =  ; See RFC 2608 for the format of scope names.
     ipv4-number     =  1*3DIGIT 3("." 1*3DIGIT)
     ipv6-number     = ;See RFC 2373 [9] Section 2.2

An example of a scope/group list for IPv4 is:

     eng:239.255.255.42,corp:239.255.255.43

An example of a scope/group list for IPv6 is:

     eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042

The scope/group list gives the multicast addresses to use for notifications involving the service type for the given scopes 🎯.

The service type name can be a simple type name, an abstract type name, or a concrete type name. If the name is an abstract type name, all SAs advertising the abstract type MUST notify. If the name is a concrete or simple type name, ONLY those SAs advertising the simple or concrete type MUST notify, others MUST NOT notify. A DA that receives a subscription for a concrete type with the abstract type flag set, MUST include the abstract type name in all the NotifyAt messages it sends. If the DA receives a subscription for a concrete type with the abstract type flag not set, the DA MUST NOT include the abstract type, but rather MUST include the concrete type name.

There are three cases in which an agent may receive a NotifyAt extension: in a SrvRply returned to a UA, in a multicast DAAdvert, and in a SrvAck returned to an SA. The three subsections below describe the response in each of these cases 📚.

7.1. NotifyAt received with SrvRply

When a UA sends a SrvRqst with a Subscribe extension, the DA responds with a SrvRply including a NotifyAt. The DA MUST NOT unicast a NotifyAt to a UA with any other message, and it MUST NOT send a NotifyAt unless a SrvRqst with a Subscribe extension was received 🚫.

The UA responds by setting up a multicast listener to the group addresses included in the extension, on the SLP notification port 1847. The UA MAY also want to note the expiration lifetime of the subscription assigned by the DA, and reissue a subscription before that lifetime runs out ⏳.

7.2. NotifyAt received with Multicast DAAdvert

The DA multicasts a NotifyAt with a DAAdvert using the multicast transmit algorithm when a UA has requested notification and the scopes and service type in the subscription were not previously seen 🌸. This message tells existing SAs that have the service type and scopes in the announcement that they should multicast notifications when they shut down.

A receiving SA participating in notification responds by noting the multicast address if the service type and scopes match. When the SA is about to go down, the SA MUST first unicast a SrvDereg without attribute tag list to its DAs (as per standard SLP), and then it MUST multicast the same SrvDereg message according to the multicast transmit algorithm. The SA MUST cease performing notification when the subscription lifetime expires, unless a subsequent NotifyAt is received prolonging the subscription 👋.

A UA that is performing passive DA detection will naturally also receive the extension, but the UA SHOULD ignore the extension 🙈.

7.3. NotifyAt received with SrvAck

An SA can receive a NotifyAt with a SrvAck when it first comes up and registers itself with a DA. If the DA has any subscriptions from UAs for the service type and scopes represented by the SA, it MUST return a NotifyAt with the SrvAck 🧚.

The SA, upon receiving the NotifyAt, immediately multicasts the same SrvReg it sent to the DA, according to the multicast transmit algorithm. The SA MUST only perform the multicast algorithm once, even if it registers with more than one DA and receives the NotifyAt in reply from more than one of them. Prior to its demise and after deregistering with a DA, the SA MUST notify with the same SrvDereg, as described in Section 7.2 💜.

8. Multicast Address Allocation 🌈

Enterprise networks that allow SLP notification SHOULD deploy the Multicast Address Allocation Architecture (MAAA), including administratively scoped multicast and Multicast Address Dynamic Client Allocation Protocol (MADCAP) [6] 🏢.

If it is not possible to obtain a multicast address for use in SLP notifications, the SLP multicast address is used.

If the MAAA infrastructure is deployed, DAs and SAs obtain their scope configuration from MADCAP, because the SLP scopes are the same as the MADCAP scopes. Each SLP scope MUST correspond to a multicast scope name, in the sense of [6]. In such a case, a DA allocates, using MADCAP, a new multicast group address for each new service type/scope pair to which a UA subscribes. The allocation is made by MADCAP from the multicast address range for the scope. In this way, only those UAs interested in the service type and scopes in the subscription receive the multicast notification. The DA sets up the lease on the multicast address to correspond with the duration of the subscription. If the MADCAP server runs out of addresses, the SLP multicast group is used as a last resort 🫶.

For example, if the multicast scope has an address range of 239.1.0.0 through 239.1.255.255, the notification group address for service type X in scope A could be 239.1.0.42, and for service type Y in scope B could be 239.1.42.42 🦋.

9. Multicast Transmit Algorithm ✨

okay so the DA and SAs use a multicast transmit algorithm that's basically a cousin of the one SLP uses for finding services (see RFC 2608 [1]) 🦋. The only twist is that the agent doing the notification doesn't wait around for replies, no cap. It sends a notification message over and over across a period of 15 seconds, and the gap between each multicast gets longer every time (that's the exponential backoff 💅). The reason it's so clever is that it keeps the announcement small in reach and short in duration, but still repeats it enough times that the odds of at least one copy getting through go way up 🙈

For an SA, a notification is either a SrvReg or a SrvDereg, depending on whether the SA is registering a new service or deregistering one. When a brand new service gets registered, the SrvReg MUST have the fresh bit set in the SLP header. The whole attribute list for the service SHOULD be included too. A SrvDereg MUST NOT include an attribute tag list. And notifications MUST NOT be sent at any other time, so the multicast traffic stays as lean as possible 🫶

Here's a sneaky problem: a SrvReg can carry an attribute list of basically any length, so the message could overflow the packet MTU for UDP 😭. If an attribute list causes that overflow, the SA MUST set the overflow bit in the SLP header. The attribute list in the notification MUST be formatted so a UA can still use the attributes even when the overflow happens. And if a UA needs more attributes than made it into the notification, it can go ask the SA (if there's no DA around) or the DA for whatever it's missing 🔥

A DA multicasts a DAAdvert when a subscription comes in with a service type and scopes that don't match anything on the DA's list of known subscriptions. The same algorithm MUST be used here too. If the DA attributes plus the NotifyAt message would overflow a UDP packet, the DA attributes MUST be truncated so the NotifyAt can fit, and the overflow bit MUST be set in the header 🎀. An SA can tell the message is about a new subscription and not just a passive advertisement because of the extension, so if the overflow bit is set, it can ignore the DA attribute list field. A DA also sends a SrvDereg when a service advertisement gets deregistered due to timeout, following the same rules as an SA does 🌈

10.0 DA Disappearance 💔

Robustness to DA failure is a huge goal of this design, bestie 👑. When a DA disappears because of something unforeseen, the subscription info from UAs is lost. The UAs still get notifications from the SAs that already exist 👍. But new SAs won't be told about the subscription unless other DAs also have that info. Since a UA might not find a new DA until it tries an active request, it could miss new services showing up, which is a little bit of a vibe killer 😬. So UAs that really care about hearing about absolutely every service that appears SHOULD issue subscriptions to every newly discovered DA that supports the scopes they support. Similarly, if a DA goes down through a controlled shutdown, a UA doing passive discovery can notice the shutdown and resubscribe to an alternate DA 🦋.

On the SA side, when a DA goes down, existing SAs keep notifying until the subscription expires. Before they stop, an SA MUST determine whether the DA is still active and, if it isn't, check with another DA whether the subscription has been extended. If no other DA is available, the SA MUST ignore the subscription expiration time and keep notifying until a new DA shows up. When a new DA is discovered, the SA must send a new SrvReg to that DA, according to RFC 2608 [1]. The SrvAck that comes back contains a NotifyAt extension if the UA has renewed its subscription with that DA. If the SrvAck doesn't contain a NotifyAt message, the SA MUST continue to notify until the subscription expires. And if a UA wants the notifications to keep going, it renews the subscription with the new DA before the old one expires, which tells the SA to keep notifying 💅✨

Heads up though, this procedure still doesn't tell SAs that came up between the time a newly booted DA comes online and the time the UA renews its subscription with that DA 🙈. If that's a concern, you can use multiple DAs so all subscriptions stay covered when one DA goes down 🫶.

11. Network Administration Considerations 🌸

In SLP networks with DAs (as described in RFC 2608), the only multicast is the SrvRqst for DAAdverts during active DA discovery, plus the unsolicited DAAdverts the DA sends periodically for passive discovery. There's no multicast involved in UA queries or SA registrations 🧚. That lets network admins set up DAs for a particular collection of IP subnets and keep all the service discovery traffic as unicast between SA and UA clients and the DA. Administratively scoped multicast can also be used to limit how far active DA discovery and passive DA advertising reach 🍓. The amount of multicast involved isn't high, and DHCP DA and scope configuration can control which DAs a particular UA or SA client sees, or turn multicast off entirely so UAs and SAs only use configured DAs.

With notification, though, multicast traffic about events in SAs shows up, and that's a whole different energy 😭. Because DAs request multicast addresses based on scope and service type, the multicast tied to particular events should only reach the subnets where UAs and SAs of the same scope are interacting. Routers should be configured with administrative multicast scoping to keep multicast in check. If DAs aren't deployed (or the MAAA isn't deployed), the amount of multicast on the SLP multicast address could quickly get really big once notifications are in use. So it's crucial that DAs supporting notification get deployed in large networks where UA clients care about notification 💜.

12. Security Considerations 🔒

Okay, this one is serious, so pay attention 🚨. The SrvReg and SrvDereg messages contain authentication blocks for all the SLP SPIs supported by the DAs the SA registers with. Those SPIs are necessarily the same ones UAs can verify, so a UA that receives a multicast notification is in a position to verify it. It does that by selecting the authentication block or blocks it can verify. If authentication fails, whether because there's no authentication block or because the proper SPI is missing, the UA simply discards the notification 🗑️. In a network without DAs, the SPIs of the UA and the SA must also match. Don't skip this, babe, it's the difference between a notification you can trust and one you can't 💀.

13. IANA Considerations 🦋

The SLP Notification services use the IANA-assigned port number of 1847. The SLP extension identifiers IANA assigned are 0x0004 for Subscribe and 0x0005 for NotifyAt ✨.

14. Acknowledgements 🫶

The authors want to give a big shoutout to Charles Perkins (Nokia) and to Erik Guttman and Jonathan Wood (Sun Microsystems) for their stimulating discussion and suggestions during the early phases of the subscription/notification design 💖. Erik gets an extra-special thank-you for his intense scrutiny of the spec in the later phases, because his comments were instrumental in refining the design 👑. Shivaun Albright (HP) pushed for simplifying the protocol so it focuses on initial registration and deregistration only, and Vaishali Mithbaokar implemented that simplified protocol 🎀. Iconic teamwork, honestly 🌈.

15. References 📚

[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
    Location Protocol", RFC 2608, July 1999.

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

[3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
    service: Schemes", RFC 2609, July 1999.

[4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
    1998.

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

[6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
    Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses

[8] Guttman, E., "Service Location Protocol Modifications for IPv6",
    Work in Progress.

[9] Hinden, R. and S. Deering, "IP Version 6 Addressing
    Architecture", RFC 2375, July 1997.

16. Author's Addresses 🧚

James Kempf
Sun Microsystems
UMPK15-214
901 San Antonio Rd.
Palo Alto, CA 94040
USA

Phone:    +1 650 786 5890
EMail:    james.kempf@sun.com


Jason Goldschmidt
Sun Microsystems
UMPK17-202
901 San Antonio Rd.
Palo Alto, CA 94040
USA

Phone: +1 650 786 3502
EMail: jason.goldschmidt@sun.com

This legal text stays word-for-word, no edits from me 🙏:

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