RFC 2882

Network Access Servers Requirements: Extended RADIUS Practices

📅 published July 2000, from ietf

Network Access Servers Requirements: Extended RADIUS Practices ✨

Okay bestie, this is RFC 2882 🦋 and the header has all the tea:

  • RFC number: 2882
  • Author: D. Mitton, from Nortel Networks 💜
  • Category: Informational (so it's info, not a standard, no cap) 📚
  • Date: July 2000 🌸
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates

Status of this Memo 📜

This memo is here to give info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ✨

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

Abstract 🌈

Okay so this document describes the current practices that NAS products have been running, which go way beyond what the RADIUS RFCs 2138, 2139 [1,2] cover. 💅 The goal is to show real examples of why we need to address and standardize these ad-hoc functions. Lowkey the big problem is that many of these features need a matching server-side piece too, so deploying and managing NAS and AAA server products that actually work together is severely hindered. 😭

These practices are written down here to show which functions are obviously wanted when they design future AAA protocols for NAS deployments. Main character energy for future protocol design 👑

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
1.1.  Disclaimers . . . . . . . . . . . . . . . . . . . . . . .  3
1.2.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  3
2.  Attribute Usage . . . . . . . . . . . . . . . . . . . . . .  3
2.1. Attribute Conflicts  . . . . . . . . . . . . . . . . . . .  4
2.2. Attribute Value Conflicts  . . . . . . . . . . . . . . . .  4
2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . .  4
2.3   Vendor Specific Attribute Usage . . . . . . . . . . . . .  5
2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . .  5
2.3.2 Clients that support multiple Vendors:  . . . . . . . . .  5
3.  Attribute Data Types  . . . . . . . . . . . . . . . . . . .  6
4.  New Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
5.  Additional Functions  . . . . . . . . . . . . . . . . . . .  7
5.1 Password Change   . . . . . . . . . . . . . . . . . . . . .  8
5.2 Authentication Modes  . . . . . . . . . . . . . . . . . . .  8
5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
5.4 Pseudo Users  . . . . . . . . . . . . . . . . . . . . . . .  9
6.  Resource Management . . . . . . . . . . . . . . . . . . . .  9
6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . .  9
6.2 Resource Management Messages  . . . . . . . . . . . . . . . 10
6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
7. Policy Services  . . . . . . . . . . . . . . . . . . . . . . 11
8. Accounting Extensions  . . . . . . . . . . . . . . . . . . . 12
8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
9. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . 13
11. Implementation Documents  . . . . . . . . . . . . . . . . . 13
11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References  . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Author's Address  . . . . . . . . . . . . . . . . . . . . . 15
14. Full Copyright Statement  . . . . . . . . . . . . . . . . . 16

1. Introduction 🎀

The RADIUS Working Group got formed in 1995 to document the protocol of the same name. It was chartered to stay inside a set of bounds for dial-in terminal servers. 🕰️ Unfortunately, the real world of Network Access Servers (NASes) didn't stay that small and simple, and it keeps evolving at an amazing rate. 🚀

This document shows that some of the current implementations on the market have already outgrown what the RADIUS protocol can do. Quite a few features got built completely outside the protocol. 🙈 They use the RADIUS protocol structure and format, but they run operations and semantics way beyond what the RFC documents cover.

I learn about the details of these functions by reading industry manuals, and I often have to respond to them in competitive bid specifications. 📝 Once they get deployed in the field, they pick up the force of de-facto standards. Iconic glow-up for unofficial stuff 💅

Because they were done outside the scope of the RFCs, they are vendor specific, and that causes big problems when you try to offer an interoperable product. 😭

1.1. Disclaimers ⚠️

The data and numbers in this document were gleaned from public sources and vendor documents along the way. Actual implementation of many of these features, and how they vary from the documentation, has not been confirmed.

This document is a snapshot of known practices at the time of writing. It is not intended to standardize these practices here, or to keep this document current beyond its initial publication. While some detailed information is given, it is not the purpose of this document to directly or sufficiently describe the functions mentioned to the level of a complete functional specification.

The author has not transcribed copyrighted material, and is not aware of whether any of these practices have any intellectual property restrictions.

Any numeric assignments or functional operations are subject to change by vendors without notice. I would appreciate any direct input, preferably first-hand, from implementors. 🫶

1.2. Presentation 🗺️

Without any easy organization for the material, the information is arranged in a simple taxonomy, from bottom-up complexity:

  • Attribute Usage
  • Attribute Data Types
  • Message Codes
  • New Operations

2. Attribute Usage 🧩

The RADIUS RFCs define the attribute type ranges and the specific attribute definitions.

  • There are about 70 defined RADIUS attributes:
  • Values 192-223 are reserved for experimental use
  • Values 224-240 are reserved for implementation-specific use
  • Values 241-255 are reserved and should not be used.

Attribute 26 was defined to be the Vendor Specific Attribute (VSA), with further internal structure to allow vendor expansion. ✨

2.1. Attribute conflicts 💥

In practice, attributes 92-255 are in use by a vendor. And another vendor also uses attributes in the 90-104 range, which conflicts with this usage. 😬

To deal with these issues, server vendors have added vendor specific parameters to their client database files. The administrator has to indicate the vendor type of the NAS along with the client IP address and secret, so that the server can disambiguate the attribute usage. 🕵️

One server has a single large vendors file that describes the mapping of all attributes to an internal format that retains the vendor id. Another server implementation uses multiple dictionaries, each indexed to a NAS and Vendor Model definition list. 📚

2.2. Attribute Value Conflicts 🙃

Adding additional attributes may be more trouble than it's worth for simple features. Often, existing RADIUS attributes could be extended with additional values (particularly attributes that are enumerated choices). But when you do that, there's no way to guarantee you won't conflict with other vendors' extensions. 💀

2.2.1. Vendor Specific Enumerations proposal 🔢

One proposed solution to this problem was Vendor Specific Enumerations (VSEs). The idea is to embed the vendor's management ID in the numeric value (à la VSAs), which divides up the attribute value space. This technique has not seen any acceptance by the working group or other vendors. However, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values. 👑

Example dictionary of VSE values:

VALUE   Service-Type        VSE-Authorize-Only       0x06300001

VALUE   Acct-Status-Type    VSE-User-Reject          0x06300001
VALUE   Acct-Status-Type    VSE-Call-Reject          0x06300002
VALUE   Acct-Status-Type    VSE-IPCP-Start           0x06300003
VALUE   Acct-Status-Type    VSE-IPXCP-Start          0x06300004
VALUE   Acct-Status-Type    VSE-ATCP-Start           0x06300005
VALUE   Acct-Status-Type    VSE-Accounting-Restart   0x06300006
VALUE   Acct-Status-Type    VSE-Accounting-Shutoff   0x06300007
VALUE   Acct-Status-Type    VSE-Tunnel-Start         0x06300008
VALUE   Acct-Status-Type    VSE-Tunnel-Stop          0x06300009
VALUE   Acct-Status-Type    VSE-Tunnel-Reject        0x0630000a
VALUE   Acct-Status-Type    VSE-Tunnel-Link-Start    0x0630000b
VALUE   Acct-Status-Type    VSE-Tunnel-Link-Stop     0x0630000c
VALUE   Acct-Status-Type    VSE-MP-Start             0x0630000d
VALUE   Acct-Status-Type    VSE-MP-Stop              0x0630000e
VALUE   Acct-Status-Type    VSE-Line-Seizure         0x0630000f
VALUE   Acct-Status-Type    VSE-Rlogin-Start         0x06300010
VALUE   Acct-Status-Type    VSE-Rlogin-Stop          0x06300011

2.3. Vendor Specific Attribute Usage 🎁

Because attribute 26 Vendor Specific Attributes (VSAs) came late in the RADIUS working group's development, some server implementations were late to support them. Today, several leading client implementations make extensive use of VSAs. What's unfortunate is that several different VSA formats are also implemented. 😩 This is because the RFC-suggested format doesn't support more than 256 attributes.

2.3.1. VSAs in use by some clients: 🛠️

At the time this document was written, the following had been observed:

  • Microsoft: several for MS-CHAP authentication support [9]
  • ACC: 42 [10]
  • Nortel(Bay): about 60 VSAs and 16 VSEs
  • Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header. Aptis VSAs have shifted from a regular format to a 4-byte header format, due to the large number of attributes implemented.
  • 3Com (USR): about 130 USR VSAs are different than the format suggested in RFC 2138. They have a 4 byte type field and have no internal length.

Some vendors that did not initially use VSAs have shifted, in later releases, to VSA usage as a configuration option. 🔄

2.3.2. Clients that support Multiple Vendor Attributes 🌟

Now that MS-CHAP RADIUS attributes have been published in RFC 2548 [9] as Microsoft VSA attributes, it's going to become typical for NAS clients that support MS-CHAP authentication to process several different vendor VSA types. This has implications for RADIUS servers that filter or "prune" return attributes based on the vendor make/model of the NAS client. 🧹

One NAS implementation can receive up to three different vendor specific attribute sets, but it will only send attributes according to the "mode" that has been configured by the operator. This lets it fit into environments where the customer has become dependent on a particular set of RADIUS attributes, and it lets the NAS "drop-in" without server attribute changes. 🦋

There is another NAS that supports 3 vendor attribute sets concurrently. That means it will normally use a combination of different vendor VSAs in return profiles from the server. It was built this way to support a superset of competing vendors' extensions, as well as its own, and to include extensions from a sister product. It's giving full buffet energy 🍓

3. Attribute Data Types ✨

okay so the base RFCs only define 4 basic data types 🎀

  • integer, 32 bit unsigned
  • string, 1-253 bytes, counted.
  • ipaddr, 32 bit IPv4
  • date, 32 bit Unix format.

since then, people have been adding variations 🌈 the tunnel authentication document [6] adds an optional compound "tag" byte to tunnel attributes. it's a single byte prepended to the data field so that sets of attributes can be returned together 🧚 the byte value must be in the range 01-3F hex or it is considered to be data.

ngl, there's no native support for IPv6 addresses 🙈 IPv6 support is also missing in some fixed message components, which is kind of a lot tbh.

servers have also made their own special attribute types. for packet filters, there's a format called "abinary" 🔥 the user types an ASCII string filter description into the user profile, and the server parses it into a binary string before passing it to the NAS. this lowers the complexity of the NAS parser, so the NAS has less to do, which is honestly iconic of the server 👑 and there's a "phonestring" server data type that allows extra data type checking at the entry application 💅

4. New Messages 🦋

a bunch of new message types have shown up over time from different parties. the base specification has 6, and vendors have added 26 more 😭

these fall into a few categories, which we'll get into in the next section. some of these messages are actually used between the RADIUS server and another resource server, using a RADIUS-like protocol to implement new functions 🫶

         6 Accounting Status
                  (now Interim Accounting [5])
         7 Password Request
         8 Password Ack
         9 Password Reject
         10 Accounting Message

         21 Resource Free Request
         22 Resource Free Response
         23 Resource Query Request
         24 Resource Query Response
         25 Alternate Resource Reclaim Request
         26 NAS Reboot Request
         27 NAS Reboot Response

         29 Next Passcode
         30 New Pin
         31 Terminate Session
         32 Password Expired
         33 Event Request
         34 Event Response
         40 Disconnect Request
         41 Disconnect Ack
         42 Disconnect Nak
         43 Change Filters Request
         44 Change Filters Ack
         45 Change Filters Nak
         50 IP Address Allocate
         51 IP Address Release

5. Additional Functions 💖

these are operations done with RADIUS extensions and some extra message types 💅

5.1. Password Change 🔐

remotely requested password changes were described and proposed, but the working group rejected them. even so, the feature is still deployed in a bunch of products, so it's definitely not dead 💀

Message types:

  • Password Request
  • Password Ack or Reject

5.2. Authentication Modes 🌸

extra message types were added to negotiate passcode changes for token card servers 🎀

  • Next Passcode
  • New PIN
  • Password Expired

they let the NAS or the RADIUS server negotiate passcode changes with an external security server. very secure girlie behavior 🫶

5.3. Menus 🍓

at least two vendors built menu interaction systems for terminal dial-ins 🌈

one implementation uses the Reply-Message string as the menu text to display, and the State attribute to keep track of where you are in the menu ✨ the menu is shown with the Access-Challenge message, and the response is encoded in the User-Password field, just like an ordinary challenge sequence would be.

some RADIUS clients have problems with this, though 😭 they can't handle long or multiple Reply-Message attributes that might have embedded carriage returns and line-feeds. the new Echo attribute should also control echo behavior on the menu response. using the State attribute to keep track of a Challenge sequence is also standard behavior, so that part is normal.

another implementation uses vendor attributes (VSA-Menu-Item, and VSA-Menu-Selector as well as VSA-Third-Prompt) to pass this info around. this implementation is vendor specific, so it's a bit of a one-off 🦋

5.4. Pseudo Users 🧚

one client implementation uses your vanilla RADIUS server as a remote database server 👑 it uses some well-known, implementation specific strings for the Username and Password attributes, and then the NAS can ask the server for things like Static IP routes, Static IPX routes, or the Message of the Day.

these are called pseudo-user requests, because they use a user entry with this made-up name for purposes other than authentication. it's giving sneaky database energy 🙈

another client uses a pseudo-user technique to resolve unknown Filter-ID(11) values. it sends an Access-Request message to the RADIUS server with the Filter-ID as the Username value, the password is a known string, and the Service-Type is VSE-Authorization-Only. the response must also be of the same Service-Type, or the response will be ignored. the responding profile should contain the IP-Filter VSA attributes that define the filter you want 💅

⚠️ bestie, pay attention here: pseudo-user profiles could be a security problem if a specific or operationally invalid Service-Type isn't attached to the profile. the client should test for this returned value, so that normal dial-in users can't get access through this profile. not okay if they can 💀

6. Resource Management 🌷

authorized sessions may need extra dynamic resources to do their thing 💖 the most typical one is IP addresses. the allocation might want to be delayed until it's actually needed, or coordinated on a scale that's independent of the RADIUS server. extra messages may be used to allocate and free these resources, and the RADIUS server may proxy these requests to another server.

examples: some servers can allocate addresses local to the NAS, or use an outboard address server. other servers have an internal address pool capability, which fills in the Framed-IP-Address attribute with an assigned value based on the pool that was selected ✨

6.1. Managed Resources: 🌈

resources managed include: IP Addresses, Concurrent Logins, Dial-in Port allocation policies, Tunnel limits and load distribution 🫶

there are a few different implementation techniques:

  • Explicit request/free resource requests
  • Monitor usage with daemons watching the state
  • Explicit messages to a state daemon
  • Monitor Accounting messages for state changes

6.2. Resource Management Messages 🎀

these are the messages used for resource management 💅

  • IP Address Allocate
  • IP Address Release
  • Resource Request
  • Resource Response
  • Resource Free Request
  • Resource Free Response
  • Resource Reclaim Request
  • NAS Reboot Request/Response

these messages are used to allocate and free resources for a NAS from a centralized server. this gives the service provider better administrative control than some automated LAN services, which don't have policy inputs or controls. main character provider energy 👑

6.3. Concurrent Logins 🍓

the RADIUS protocol was designed for stateless servers 🧚 that means servers that don't know the status of the active sessions. but it's super important for lots of service providers to keep track of how many sessions a given user has open, and then disallow access when they go over. so relatable 😭

there are a few different techniques for implementing login limits in a RADIUS environment. some vendors have built NAS monitoring tools either into their RADIUS servers (directly or as auxiliary daemons), which can check the session status of the controlled NASes over SNMP or proprietary methods.

other vendors monitor the RADIUS access and accounting messages and derive state information from those requests. this is not as reliable as directly auditing the NAS, but it's also less vendor specific, and it can work with any RADIUS NAS, as long as it sends both streams to the same server 🦋

some of the approaches used:

  • SNMP commands
  • Telnet monitor daemon
  • Accounting monitor

6.4. Authorization Changes: 💜

to make active changes to a running session, like filter changes or timeout and disconnect, at least one vendor added a RADIUS "server" to their NAS 🔥 this server accepts messages sent from an application in the network, and when it matches some session information, it performs those operations.

messages sent from Server to NAS:

  • Change Filter Request
  • Change Filter Ack / Nak
  • Disconnect Request
  • Disconnect Response

filters limit the access a user has to the network by restricting which systems and protocols they can send packets to 🙈 once someone completes some registration with an authorization server, the service provider may want to remove those restrictions, or disconnect the user altogether 💅

7. Policy Services 👑

some vendors have built policy servers that use RADIUS as the control protocol 🌸 two prominent Policy Managers act as RADIUS proxy filters, and use RADIUS messages to deny access to new sessions that go over active policy limits. it's giving bouncer energy 💖

one implementation acts like a RADIUS proxy server, but with a policy process governing its forward decisions. typically, a pre-authentication message (like the new RADIUS draft Service-Type = CallCheck) is sent by the NAS when a call arrives 🧚 this message contains only the Dialed-Number information in the Username field. the server receives the Access-Request messages and processes them against its knowledge of the network state and the provisioned policies ✨

an Access-Accept gets returned to accept the call, and it can also contain dynamic policy info and Virtual POP specific default parameters 🎀 when the real PPP authentication kicks in, the proxy forwards the Access-Request to a RADIUS server, but only if the session was approved at pre-auth. it can also process Access-Requests that weren't preceded by a pre-auth exchange, and use the Username field for info about the desired realm in its policy evaluation 🦋

the other implementation does something similar. it uses VSAs in the Access-Request to tell apart the pre-authentication message types 🫶

8. Accounting Extensions 🌈

traditional Accounting only records session starts and stops, which is honestly pretty boring 🥱 extra session info can be added easily, and it gives a better picture of how things are running as they happen ✨ some event types are listed below.

8.1. Auditing/Activity 🔥

  • Call or Modem Starts, Stops
  • Tunnel Starts, Stops
  • Tunnel Link Starts & Stops
  • Admin changes

if a stateful server monitors these events, it can gather info about how the network is used on a user/session basis. knowing when a particular user entered the network is way more useful for network service management than trying to trace low level IP address flows backwards 🧠 info about port usage across a range of NASes lets the service provider quickly find problem areas or users. main character data, obviously 💅

info about call failures, successes, and quality is also deemed important by lots of service providers 😭

extending RADIUS accounting is easy, and honestly it's surprising that more implementations haven't been made in this area 🫶💜

9. Conclusions 🎀

okay so real talk, RADIUS Servers are getting SO complex now 💅 like they're basically brokering authentication and authorization over to other authorities or repositories, and honestly? Variants of the RADIUS protocol end up being used as the glue protocol for these kinds of solutions 🔥

some of these solutions are kludges, bestie 😭 and they could be cleaned up with better underlying services 🧚

so what does this mean for the implementor? 🤔 RADIUS as the RFCs describe it is becoming less relevant, ngl. Lots of additional features need matching client and server processing, so both sides have to agree on the message processing or things get messy 🙈

and without standardization of these functions, we don't get much interoperability in the field 💀 people end up spending forever reverse engineering stuff and reacting to unknown areas. it's giving chaos 😩

this memo is not a complete survey by any means, just a representative summary of the practices the author was aware of at the time of writing 🦋 the author still appreciates input from vendors or users about practices and details they know about, and especially any reference material you can pass along 🌸

10. Security Considerations 🔐

okay this part is SERIOUS, so pay attention 👑 this document documents known practices and does not propose any particular new protocols. BUT extensions to RADIUS protocols create brand new security implications, because their functions go beyond the ones considered in the RFCs. yikes 😬 some of these include:

  • The ability to change passwords via a RADIUS exchange was deliberately left out of the protocol by the working group, because of security concerns. 🙅‍♀️
  • The Pseudo-User profiles and the Call-Check operation may allow unintended access if static and well-known account names and passwords are allowed to be used by regular interactive accounts. 🚨
  • Resource Management operations must be protected from denial of service attacks. 💀
  • Client side authorization change exchanges need to be secured from attacks that could disconnect or restrict user services. 😭

11. Implementation Documents 🧚

information about the following implementations can be obtained from the respective owners. most of them are available from the manufacturer's web site ✨

11.1. Clients: 💖

  • 3Com(USR) Total Control Hub
  • Ericsson(ACC) Tigris draft-ilgun-radius-accvsa-01.txt, Dec 1998
  • Lucent(Ascend) MAX TNT
  • Lucent(Livingston) Portmaster
  • Nortel(Aptis) CVX 1800
  • Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
  • Intel(Shiva)

11.2. Servers: 🌈

  • Ericsson(ACC) Virtual Port Server Manager
  • Funk Steel-Belted RADIUS
  • Intel(Shiva) Access Manager
  • Lucent(Ascend) Access Control
  • Lucent(Ascend) NavisAccess
  • Lucent(Ascend) Modified Livingston 1.16
  • Lucent(Livingston) V2.01
  • Lucent(Livingston) ABM
  • Lucent Port Authority
  • MERIT AAA Servers
  • Nortel(Bay Networks) BaySecure Access Control
  • Nortel Preside Radius
  • Nortel CVX Policy Manager

12. References 📚

[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.

[3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.

[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.

[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.

[8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000.

[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.

[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson Datacom Access", Work in Progress.

13. Author's Address 🦋

David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821

Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com

Copyright (C) The Internet Society (2000). 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