RFC 3336

RFC 3336: PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) ✨

okay bestie, welcome to RFC 3336 🦋 this one is all about running PPP over AAL2 so tiny packets (like voice) stop wasting bandwidth 🎀

Title block tea ☕:

• Network Working Group, written by B. Thompson and T. Koren from Cisco Systems, with B. Buffam from Seaway Networks
• Category: Standards Track, so this is an actual Internet standards track protocol 👑
• Date: December 2002
• Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates 🫶

---

Status of This Memo

this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌈

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract

the Point-to-Point Protocol (PPP) gives you a standard way to transport multi-protocol datagrams over point-to-point links 🔥

this doc describes using ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets ✨

Applicability

this spec is for implementations that want the PPP facilities, like the Link Control Protocol, Network-layer Control Protocols, authentication, and compression 🧚 those capabilities need a point-to-point relationship between the peers. they weren't designed for the multi-point relationships you get in ATM and other multi-access environments, so don't go there 🙈

---

1. Introduction ✨

okay so PPP over AAL5 [2] describes the encapsulation format and how PPP operates when it's used with the ATM AAL5 adaptation layer. it's giving good for carrying IP, but it's bandwidth inefficient when the payloads are small, like voice 😭 it's especially inefficient when you add RTP header compression [3].

PPP over AAL2 fixes the bandwidth efficiency problem for small packets 💅 it uses the AAL2 Common Part Sublayer (CPS) [4] to multiplex multiple PPP payloads into a set of ATM cells. main character energy 👑

2. Conventions

these capitalised keywords: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL 🎀 whenever they show up in this document, read them the way [6] describes.

3. AAL2 Layer Service Interface

the PPP layer treats the underlying ATM AAL2 layer service as a bit-synchronous point-to-point link 🦋 so the PPP link maps onto an ATM AAL2 virtual connection. the virtual connection MUST be full-duplex and point to point, and it MAY be either dedicated (i.e., permanent, set up by provisioning) or switched (set up on demand) 🌸

the PPP/AAL2 service interface boundary also MUST meet these requirements:

• Interface Format: the PPP/AAL2 layer boundary presents an octet service interface to the AAL2 layer. there's no provision for sub-octets to be supplied or accepted 🍓
• Transmission Rate: the PPP layer doesn't impose any restrictions on transmission rate, in terms of the underlying ATM layer traffic descriptor parameters ✨
• Control Signals: the AAL2 layer MUST provide control signals to the PPP layer that say when the virtual connection link has become connected or disconnected. these give the PPP layer its "Up" and "Down" events for the LCP state machine [1] 🫶

with PPP over AAL2, you can derive the state of the link from the type 3 fault management packets carried in-band within a given AAL2 CID flow 🕵️‍♀️

4. PPP Operation with AAL2 💖

PPP over AAL2 defines an encapsulation that uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR) [5] for AAL type 2 🧩 SSSAR is what segments PPP packets into frames that the AAL2 CPS can carry. it uses different AAL2 UUI code-points to say whether a segment is the last segment of a packet or not.

the encapsulation gives you a 16-bit CRC for PPP payloads. SSSAR assigns 2 UUI code points for this job: one for intermediate fragments of a packet and one for the last fragment. code point 27 marks intermediate frames of a fragmented packet, and code point 26 marks the last frame of a packet 🔥 the full encapsulation format is in section 6.2.1.

an implementation of PPP over AAL2 MAY use one or more AAL2 Channel Identifiers (CIDs) to transport the PPP packets for each PPP session 🌈 multiple CIDs could give you a multiple class real time transport service for PPP, using the AAL2 layer for link fragmentation and interleaving. a companion document [10] describes class extensions for PPP over AAL2 that use multiple AAL2 CIDs 💜

5. Comparison of PPP Over AAL2 with Existing Encapsulations

this doc proposes swapping in AAL2 transport for PPP in cases where small packets are carried over an ATM network 🦋 it matters most for voice over RTP [9] where RTP header compression [3] is in use. for voice, bandwidth efficiency and low delay are both super important 😭

this section justifies PPP over AAL2 for ATM transport by comparing it with the existing PPP encapsulation formats used over ATM. there are two to look at: PPP over AAL5 [2], and PPP with PPPMUX [8] over AAL5 👀

5.1 Comparison With PPP Over AAL5

this proposal uses ATM AAL2 [4] instead of AAL5 as the transport for PPP. SSSAR together with the AAL2 CPS creates less ATM encapsulation overhead per PPP payload 💅 the payload encapsulation is a 2 byte CRC. the AAL2 CPS header is 3 bytes, and the AAL2 Start Field (STF) is 1 byte. that's a total encapsulation overhead of 6 bytes ✨ compare that to the 8 bytes of AAL5 trailer used for PPP over AAL5 💀

the AAL2 CPS multiplexing function lets you transport PPP frames more efficiently by packing multiple PPP frames into one or more ATM cells 🎀 that gets rid of the AAL5 pad overhead when you're sending short frames. no more wasted padding, iconic 🫶

5.2 Comparison with PPPMUX over AAL5

PPP Multiplexing (PPPMUX) [8] is a newer method for multiplexing at the PPP layer 🧚 it gives you functionality similar to the CPS-based multiplexing function of AAL2. with PPP multiplexing, the stack looks like PPP/PPPMUX/AAL5.

both PPP/PPPMUX/AAL5 and PPP/AAL2 use multiplexing to cut down on the overhead of cell padding when frames go over an ATM virtual circuit 🌸 but PPP/AAL2 will typically use bandwidth better than PPP/PPPMUX/AAL5 does 💅 that's because multiplexed frames in PPP/PPPMUX/AAL5 always have to be encapsulated in an AAL5 frame before they're sent. that encapsulation adds an extra 8 bytes of AAL5 trailer to the PPPMUX encapsulation 💀 on top of those 8 bytes, PPPMUX picks up an average of 24 additional bytes of AAL5 PAD. those 2 factors drag down the effective efficiency of PPPMUX over AAL5 😭

with PPP/AAL2, the AAL2 CPS layer treats individual PPP frames as a series of CPS payloads that can be multiplexed 🦋 as long as PPP frames reach the CPS layer before the CPS TIMER_CU expires, every ATM cell coming out of the CPS layer gets filled 🔥 under those conditions, PPP/AAL2 has no PAD at all. no PAD means PPP/AAL2 is more bandwidth efficient than PPP/PPPMUX/AAL5 👑

in PPP/PPPMUX/AAL5, the AAL5 SAR and the PPP MUX/DEMUX happen in two different layers 🙈 so the PPPMUX/AAL5 receiver has to reassemble a full AAL5 frame from the ATM layer before the PPPMUX layer can pull out the PPP payloads. to get max PPP Multiplexing efficiency, lots of PPP payloads get multiplexed together, which makes the multiplexed frame span many ATM cells 🌈 if even one of those cells is lost, the whole PPPMUX packet gets discarded 💀 there can also be a big delay while the AAL5 layer waits for many cell arrival times until the full frame is assembled and passed up to the PPP Multiplexing layer, where the inverse PPP demux happens. the same issue applies to PPPMUX/AAL5 frames going down the stack too 😭

with AAL2, both the segmentation and reassembly and the multiplexing functions happen in the AAL2 CPS layer ✨ because of how the AAL2 CPS function is defined, a multiplexed payload gets extracted as soon as it's received 🧚 the CPS receiver doesn't wait for all the payloads of an AAL2 multiplexed frame to arrive before pulling payloads out of the multiplexed stream. the same benefit applies to AAL2 CPS sender implementations too 🫶 and losing an ATM cell only loses the packets that were included in that cell 🎀

the AAL2 CPS function provides multiplexing in AAL2, and it often needs to be implemented in hardware for performance reasons 🔥 so a PPP/AAL2 implementation that uses an AAL2 SAR implemented in hardware gets significant performance benefits over a PPP/PPPMUX/AAL5 implementation where PPPMUX runs in software 👑 also, the AAL2 specification has been around significantly longer than the PPP Multiplexing specification. because of that, optimized software and hardware implementations of the AAL2 CPS function are further along in development than PPP Multiplexing implementations 🌸

6. Detailed Protocol Operation Description 🧠

6.1 Background

6.1.1 AAL2 Multiplexing

ITU-T I.363.2 specifies ATM Adaptation Layer Type 2 🦋 this AAL type provides bandwidth efficient transmission of low-rate, short, and variable length packets in delay sensitive applications. more than one AAL type 2 user information stream can be supported on a single ATM connection 💖 there's only one definition for the sub-layer, because it implements the interface to the ATM layer and is shared by more than one SSCS layer 🫶

6.1.2 AAL2 Service Specific Convergence Sub-layers

ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub-layers (SSCS) that operate above the Common Part Sub-layer defined in I.363.2 🧚 this layer specifies packet formats and procedures for encoding the different information streams in bandwidth efficient transport. as the name implies, this sub-layer implements those elements of service specific transport 💅 while there's only one definition of the Common Part Sublayer for AAL2, multiple SSCS functions can be defined to run over this CPS layer. different CIDs within an AAL2 virtual circuit may run different SSCSs 🌈

6.1.3 AAL2 CPS Packet (CPS-PKT) Format

here's the CPS-PKT format over AAL2, as defined in I.363.2 👀

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           +          +         +         +                          |
|    CID    +    LI    +   UUI   +   HEC   +        CPS-INFO          |
|           +          +         +         +                          |
|           +          +         +         +                          |
|    (8)    +    (6)   +   (5)   +   (5)   +       (45/64 * 8)        |

---

part 1 done, bestie 🫶 part 2 is coming next, and it's going to be a whole vibe 🦋✨

Note: The size of the fields denote bit-width

okay so the CID (Channel ID) is basically the label that says which sub-stream inside the AAL2 connection a packet belongs to 💖 the LI (Length indication) tells you how long the CPS-INFO payload is ✨ and the UUI (User-to-User Indication) is the little note passing info between the SSCS/Application sitting above the CPS 🫶 the SSSAR sub-layer (defined in I.366.1) uses these code points:

UUI Code-point Packet Content ++++++++++++++ ++++++++++++++

0-26 Framed mode data, final packet.

27 Framed mode data, more to come.

this proposal uses two UUI code-points as follows, and yes, they're a little bit of a glow-up 🦋

UUI Code-point Packet Content ++++++++++++++ ++++++++++++++

27 non-final packet.

26 final packet.

### 6.1.4 AAL2 CPS-PDU Format

the CPS-PDU format over AAL2, as defined in I.363.2, looks like this 🌸

+-+-+-+~+~+-+-+

+-+-+-+~+~+-+-+

CPS-PKT

CPS-PKT V V V V +-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cell | | | | Header | STF | CPS-PDU Payload | PAD |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+

              Note: The size of the fields denote bitwidth

the CPS-PDU is used to carry one or more CPS-PKTs multiplexed on a single CPS-PDU, and the CPS header holds enough info to identify the CPS packets inside a CPS-PDU 🎀 if a cell gets lost, the STF field is what helps you find the first CPS-PKT in the current cell 🧚

## 6.2 PPP Over AAL2 Encapsulation

PPP encapsulation over AAL2 uses the AAL2 CPS with no change ✨

some PPP encapsulated protocols, like RTP header compression, need the link layer to provide packet error detection 👀 so PPP over AAL2 defines a 16-bit CRC that gets used along with the SSSAR sub-layer of I.366.1 to provide packet error detection. the encapsulation format is described below 💅

### 6.2.1 PPP Payload Encapsulation Over AAL2 with 16-bit CRC (CRC-16).

the payload encapsulation of PPP appends a two byte CRC to each PPP frame before the SSSAR layer sends the PPP packet as a series of AAL2 frames 🌈

the diagram below shows the format of a PPP over AAL2 packet, and it shows the payload encapsulation when the packet is **not** segmented (UUI=26). when the PPP packet *is* segmented, the PPP Protocol ID, Information field, and CRC-16 fields get split across multiple SSSAR frames. in that case the UUI field is set to 27 for all frames except the last one, and the last frame gets UUI 26 🍓

Payload Encapsulation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Note: The size of the fields denote bit-width

the algorithms for computing and verifying the CRC-16 field are identical to the ones for the Frame Check Sequence (FCS) field in Q.921 [13]. they're copied into this section so you don't have to go hunting for them 🔍

the CRC-16 field gets filled with a CRC calculation over the contents of the PPP packet, including the PPP Protocol ID and the information field. the CRC field shall contain the ones complement of the sum (modulo 2) of:

1. the remainder of `x^k (x^15 + x^14 + ... + x + 1)` divided (modulo 2) by the generator polynomial, where k is the number of bits of the information over which the CRC is calculated; and
2. the remainder of the division (modulo 2) by the generator polynomial of the product of `x^16` by the information over which the CRC is calculated.

the CRC-16 generator polynomial is:

G(x) = x^16 + x^12 + x^5 + 1

the result of the CRC calculation is placed with the least significant bit right justified in the CRC field 🫶

as a typical implementation at the transmitter, the register of the device doing the remainder division is preset to all "1"s, then modified by dividing by the generator polynomial (as described above) over the information the CRC is calculated on. the ones complement of the resulting remainder goes into the CRC field ✨

as a typical implementation at the receiver, the register of the device computing the remainder of the division is preset to all "1"s. the final remainder, after multiplying by `x^16` and then dividing (modulo 2) by the generator polynomial of the serial incoming PPP packet (including the Protocol ID, the information and the CRC fields), will be `0001110100001111` (`x^15` through `x^0`, respectively) in the absence of transmission errors 🎯

## 6.3 Use of AAL2 CPS-PKT CIDs

an implementation of PPP over AAL2 MAY use a single AAL2 Channel Identifier (CID) or multiple CIDs to transport all PPP packets 🦋 for the endpoints of a PPP session to work with AAL2, they MUST both agree on the number, SSCS mapping, and values of AAL2 CIDs that will be used for that session. the CID values for a PPP session MAY be obtained from static provisioning in the case of a dedicated AAL2 connection (PVC), or from Q.2630.2 [7] signaling in the case of an AAL2 switched virtual circuit (SPVC or SVC) 💜

with this proposal, you can still use conventional AAL2 on CIDs that aren't supporting PPP over AAL2. it allows multiple types of SSCS function to co-exist inside the same AAL2 VCC, which is honestly so iconic 👑

## 6.4 PPP over AAL2 Operation

PPP operation with AAL2 performs basic PPP encapsulation with the PPP protocol ID. a 16-bit CRC is calculated as described above and appended to the payload, and the SSSAR sub-layer of AAL2 is used for transport 🌸

applications implementing PPP over AAL2 MUST meet all the requirements of PPP [1]. no cap, that one's non-negotiable 💅

# 7. Example implementation of PPP/AAL2 ✨

okay bestie, this section is a full walkthrough of how PPP gets encapsulated over AAL2 🦋 Two application stacks are both sending IP packets into the **same** interface, and that interface is running PPP/AAL2. One app is making RTP packets and the other is making regular IP datagrams. The interface in this example runs an <lavender>RFC 2508 compliant</lavender> version of RTP header compression 💜

Here's the map of every path an application packet can take:

+---+---+---+---+--+ +

+---+---+---+---+--+ |

+---+---+---+---+--+ +---+---+---+---+---+ Application

+---+---+---+---+--+ +---+---+---+---+---+ |

+---+---+---+---+--+ +---+---+---+---+---+ +

+---------------+------------+

+---+---+---+---+---+--+ +

+---+---+---+---+---+--+ |

+---------+-----------+ |

RTP | | Non-RTP | Packets V | Packets | +---+---+---+---+---+---+ | |

+---+---+---+---+---+---+---+---+---+---+---+---+ Transport

+---+---+---+---+---+---+---+---+---+---+---+---+ |

+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |

+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ | +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |

+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |

+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +

So in the picture, **application A** is the RTP app. It gathers the RTP data and formats an RTP packet, then its lower layers slap on UDP and IP headers to make a complete IP packet 🎀 **Application B** is the IP app, and it hands datagrams straight to the IP layer. Those datagrams might not have UDP or RTP headers at all, which is totally valid 🌸

Now the flow. A protocol stack is set up to apply CRTP/PPP/AAL2 compression on an interface pointing at a destination host ✨ Every packet sent to that interface gets tested to see whether RTP header compression can work on it. As packets show up, a compression filter checks whether each one is a candidate for header compression. If it is, the packet goes to the CRTP compressor. If it isn't, the packet goes straight to the PPP layer and gets encapsulated as an IP packet inside PPP 🍓

The destination UDP port number and packet length are examples of criteria that may be used by the compression filter to select the interface. So the filter has options, which is giving flexibility 💅

In this example, packets from application A go to the CRTP compressor. The compressor then hands the compressed packet to the PPP layer, which encapsulates it as one of the compressed header types of CRTP. The PPP layer adds the right CRTP payload type for that compressed packet 🦋

Packets from application B go straight to the PPP layer and get encapsulated as an IP/PPP packet. The PPP layer adds the PPP payload type for an IP packet encapsulated in PPP 💖

After that, the PPP packets get segmented using I.366.1 segmentation with SSSAR 🔥

The resulting AAL2 frame mode PDU is passed down as a CPS SDU to the CPS Layer for multiplexing, along with the CPS-UUI and the CPS-CID. The CPS Layer multiplexes the CPS-PKT onto a CPS-PDU. Those CPS-PDUs are passed to the ATM layer as ATM SDUs, to be carried end-to-end across the ATM network 🌈

On the receiving end, the ATM SDUs arrive and get passed up to the AAL2 CPS. As the AAL2 CPS PDU builds up, complete CPS-PKTs get reassembled by the SSSAR SSCS. The reassembled packets are then checked for errors using the CRC algorithm ✨

At this point, the PPP layer on the receiving side reads the PPP payload type and delivers the packet to either the CRTP decompressor or the IP layer, depending on the value of that PPP payload type 👑

---

# 8. LCP Configuration Options 🎀

by default, PPP over AAL2 uses the 16 bit CRC encapsulation for **all** packets 🔥

The default Maximum-Receive-Unit (MRU) is 1500 bytes 📏

---

# 9. Security Considerations 💀

okay this part is super serious, so pay attention bestie 🙈 This memo defines mechanisms for PPP encapsulation over ATM. And there's always an element of trust in any encapsulation protocol: a receiver needs to be able to trust that the sender correctly identified the protocol being encapsulated, and that the sender hasn't been spoofed or compromised. A receiver should also be able to trust that the transport network between sender and receiver hasn't been compromised. That's a lot of trust, ngl 😭

A PPP session running over an ATM Virtual Circuit must follow the PPP link operation state machine described in RFC 1661 [1]. That state machine can enforce an authentication phase using the PAP/CHAP authentication protocols before any network layer packets get exchanged. So with PPP level authentication, a PPP receiver can authenticate a PPP sender 🫶

But the system's security can also be compromised by attacks on the ATM transport network itself 💀 The ATM Forum has published a security framework [11] and a security specification [12], which define procedures to guard against common threats to an ATM transport network.

> PPP level authentication does not guard against man in the middle attacks. These attacks could happen if an attacker managed to compromise the security infrastructure of an ATM switching network. Applications that need protection against threats to an ATM switching network are encouraged to use authentication headers, or encrypted payloads, and/or the ATM-layer security services described in [12]. 😱

And here's another plot twist 🌪️ When PPP over AAL2 runs on a set of CIDs in a virtual connection, there may be other non PPP encapsulated AAL2 CIDs running on that same virtual connection. Because of this, an end point **cannot** assume that the PPP session authentication and related security mechanisms also secure those non PPP encapsulated CIDs on the same virtual connection. So don't assume everything's locked down just because PPP is 🙅‍♀️

---

# 10. Acknowledgements 🫶

The authors would like to thank Rajesh Kumar, Mike Mclaughlin, Pietro Schicker, James Carlson and John O'Neil for their contributions to this proposal 💖

---

# 11. References 📚

- [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [2] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP over AAL5", STD 51, RFC 2364, July 1998.
- [3] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
- [4] International Telecommunications Union, "BISDN ATM Adaptation layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation I.363.2, September 1997.
- [5] International Telecommunications Union, "Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2", ITU-T Recommendation I.366.1, June 1998.
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [7] ITU-T, "ITU-T RECOMMENDATION Q.2630.2", December 2000.
- [8] Pazhyannur, R, Ali, I. and C. Fox, "PPP Multiplexing", RFC 3153, August 2001.
- [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:  A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [10] Thompson, B., Koren, T. and B. Buffam, "Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2", RFC 3337, December 2002.
- [11] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998.
- [12] The ATM Forum, "ATM Security Specification v1.1", af-sec-0100.002, March 2001.
- [13] International Telecommunications Union, ISDN User-Network Interface-Data Link Layer Specification, ITU-T Recommendation Q.921, March 1993.

---

# 12. Authors' Addresses 📮

Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA

Phone: +1 408 527-0446 EMail: brucet@cisco.com

Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA

Phone: +1 408 527-6169 EMail: tmima@cisco.com

Bruce Buffam Seaway Networks One Chrysalis Way, Suite 300, Ottawa, Canada K2G-6P9

Phone: +1 613 723-9161 EMail: bruce@seawaynetworks.com

---

# 13. Full Copyright Statement 🌸

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