RFC 4831

Goals for Network-Based Localized Mobility Management (NETLMM)

📅 published April 2007, from ietf

Title Block 🎀

Okay bestie, this one is Goals for Network-Based Localized Mobility Management (NETLMM) 💖 It's RFC 4831, from the Network Working Group, dated April 2007. J. Kempf, Ed. wrote it (that "Ed." just means editor 🧚), and the authors are from DoCoMo USA Labs. It's Informational, so it's information and advice, not a standard you're required to follow 🌸 The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo 📜

This memo gives information to the Internet community 💅 It does not specify an Internet standard of any kind, and it can be distributed without limits 🦋

The copyright line reads Copyright (C) The IETF Trust (2007). 🎀

Abstract 🌙

This doc talks about the design goals for a network-based localized mobility management (NETLMM) protocol 🫶

Table of Contents 📑

1. Introduction ....................................................2
   1.1. Terminology ................................................2
2. NETLMM Functional Architecture ..................................3
3. Goals for the NETLMM Protocol ...................................3
   3.1. Goal 1: Handover Performance Improvement ...................4
   3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
   3.3. Goal 3: Location Privacy ...................................6
   3.4. Goal 4: Limit Overhead in the Network ......................7
   3.5. Goal 5: Simplify Mobile Node Mobility Management
        Security by Deriving from IP Network Access and/or IP
        Movement Detection Security ................................7
   3.6. Goal 6: Link Technology Agnostic ...........................8
   3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
   3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
   3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
   3.10. Goal 10: Localized Mobility Management
         Independent of Global Mobility Management ................10
   3.11. Goal 11: Configurable Data Plane Forwarding
         between Local Mobility Anchor and Mobile Access Gateway ..11
4. Security Considerations ........................................11
5. Acknowledgements ...............................................11
6. Normative References ...........................................12
7. Informative References .........................................12
8. Contributors ...................................................13

1. Introduction ✨

Okay so, the intro starts with [1], which explains the basic problems that pop up when a global mobility protocol gets used to manage local mobility 🙈 It also looks at two approaches people use today for localized mobility management: the host-based approach that most IETF protocols use, and the proprietary Wireless LAN (WLAN) switch approach, which is used between WLAN switches in different subnets 💜

The big takeaway from the problem statement doc is that neither approach fully solves the problem 💀 The WLAN switch approach is super convenient for network operators and users, because the mobile node doesn't need any software except the standard WiFi drivers 😭 BUT it's proprietary, so interoperability suffers, and it's limited to a single last-hop link type and a wired backhaul link type, which holds back scalability 🙅‍♀️

The IETF host-based protocols are a different mess. They need changes to the host software stack, and those changes may not work with every global mobility protocol 💅 They also need specialized, complicated security transactions with the network, and that can make them hard to deploy 🥲

So the conclusion is that a network-based localized mobility management protocol, one that needs no software on the host for localized mobility management, is what we want ✨🔥

This document comes up with a brief functional architecture and detailed goals for a network-based localized mobility management protocol (NETLMM) 🧚 Section 2 describes the NETLMM functional architecture, and Section 3 lists the goals that are desirable for the NETLMM protocol 🌸 Section 4 gives a quick overview of Security Considerations, and if you want the deep dive, check out the threat analysis document [2] 🔐

1.1. Terminology 📖

Mobility terminology in this doc follows RFC 3753 [10] and [1] 💖 On top of that, the terms below relate to the functional architecture in Section 2:

Localized Mobility Management Domain 🌍

An Access Network (in the sense defined in [1]) where mobility is handled by the NETLMM protocol 🫶

Mobile Access Gateway 🚪

A Mobile Access Gateway (MAG) is a functional network element that terminates a specific edge link and tracks mobile node IP-level mobility between edge links, through NETLMM signaling with the Localized Mobility Anchor 🦋 The MAG also terminates host routed data traffic from the Localized Mobility Anchor for mobile nodes currently located within the edge link under the MAG's control, and forwards data traffic from mobile nodes on the edge link under its control to the Localized Mobility Anchor 🔁

Local Mobility Anchor ⚓

A Local Mobility Anchor (LMA) is a router that maintains a collection of host routes and associated forwarding information for mobile nodes within a localized mobility management domain under its control 👑 Together with the MAGs associated with it, the LMA uses the NETLMM protocol to manage IP node mobility within the localized mobility management domain 🌈 Routing of mobile node data traffic is anchored at the LMA as the mobile node moves around within the localized mobility management domain 🧚

2. NETLMM Functional Architecture 🏗️

Here's the NETLMM setup 💅 Localized Mobility Anchors (LMAs) sit within the backbone network and keep a collection of routes for individual mobile nodes inside the localized mobility management domain 🦋 Those routes point to the Mobile Access Gateways (MAGs) that manage the links where the mobile nodes currently are 🌸 Packets for a mobile node get routed to and from it through tunnels between the LMA and the MAG 🫧

When a mobile node moves from one link to another, the MAG sends a route update to the LMA 🚀 Some mobile node involvement is necessary and expected for generic mobility functions, like movement detection and telling the MAG the mobile node moved 📍 But no specific mobile-node-to-network protocol will be required for localized mobility management itself 🙌 So host stack involvement in mobility management stays limited to generic mobility functions at the IP layer, and no specialized localized mobility management software is required 💖

3. Goals for the NETLMM Protocol 🎯

Section 2 of [1] describes three problems with using a global mobility management protocol for localized mobility management 😭 Any localized mobility management protocol has to naturally address these three problems 💜 On top of that, the side effects of putting such a solution into the network need to be limited 🫶 So this section covers the NETLMM goals: solving the basic problems (Goals 1, 2, and 3), and limiting the side effects (Goals 4+) ✨

Some basic goals of all IETF protocols aren't discussed in detail here, but any solution is expected to satisfy them 🌷 Those are fault tolerance, robustness, interoperability, scalability, and minimal specialized network equipment 💅 You can find a good discussion of how these apply to IETF protocols in [4] 📚

Out of scope for the initial goals discussion are Quality of Service (QoS) and dormant mode/paging 🙅‍♀️ They're important for mobile nodes, but they aren't part of the base localized mobility management problem 🥹 Also, mobility between localized mobility management domains isn't covered here. It's assumed that the global mobility management protocols take care of that 🌍

3.1. Goal 1: Handover Performance Improvement 🚀

Okay so handover packet loss happens because there's usually latency between when the link handover starts and when the IP subnet configuration and global mobility management signaling finishes 😭 During that gap, the mobile node is unreachable at its former topological location on the old link, which is where correspondents are still sending packets 💀 Those misrouted packets get dropped 🥲

This handover performance problem has gotten a LOT of attention, both in other Standards Development Organizations (SDOs) and in the IETF, all to cut down the latency in IP handover 🔥 Lots of solutions have been proposed at the link layer and at the IP layer 🧚

One part of this goal for localized mobility management is that the processing delay for changing the forwarding after handover should get as close as possible to the sum of two things: the delay tied to link-layer handover, and the delay needed for active IP-layer movement detection 🦋 That's how you avoid excessive packet loss 🫧 Ideally, if network-side link-layer support is available for movement detection before link handover or as part of the link handover process, the routing update should finish within the time needed for link handover 🌈

This delay is hard to pin down, but for voice traffic, the entire handover delay (Layer 2 handover time plus IP handover time) should be between 40-70 ms so call quality doesn't take a hit 📞💖 And of course, if the link-layer handover latency is too high, you can't match up sufficient IP-layer handover performance for good real-time service 😭

So the NETLMM protocol goal is this: in networks where the link-layer handover latency allows it, reduce the IP handover latency so the combined IP-layer and link-layer handover latency is less than 70 ms 👑✨

okay bestie, let's talk about signaling overload 😭🫶 Assuming [9] Mobile IPv6 is the global mobility protocol (other mobility protocols need about the same or a bit less 💅), if a mobile node using address autoconfiguration has to reconfigure on every move between links, here's everything it has to do:

  1. Link-layer signaling for handover and reauthentication. For example, in 802.11 [7], that's the Reassociate message plus 802.1x [8] reauthentication using EAP 🦋
  2. Active IP-level movement detection, including router reachability. The Detecting Network Attachment (DNA) protocol [5] uses Router Solicitation/Router Advertisement for this 🌸 Also, if SEcure Neighbor Discovery (SEND) [3] is in use and the mobile node doesn't have a certificate cached for the router, the mobile node must use Certification Path Solicitation/Certification Path Advertisement to get a certification path 🔐
  3. Two Multicast Listener Discovery (MLD) [14] REPORT messages, one for each solicited node multicast address matching the link local address and the global address 📣
  4. Two Neighbor Solicitation (NS) messages for duplicate address detection, one for the link local address and one for the global address. If the addresses are unique, no response is coming back 🙈
  5. Two NS messages from the router for address resolution of the link local and global addresses, plus two Neighbor Advertisement messages in response from the mobile node 🍓
  6. Binding Update/Binding Acknowledgement between the mobile node and home agent to update the care of address binding 💜
  7. Return routability signaling between the correspondent node and mobile node to set up the binding key, made up of one Home Test Init/Home Test and Care of Test Init/Care of Test 🧚
  8. Binding Update/Binding Acknowledgement between the correspondent node and mobile node for route optimization 👑

Some notes, because these details matter 📝 Steps 1-2 may be necessary even for intra-link mobility, if the last-hop link protocol doesn't help much with IP handover. Steps 3-5 change if stateful address configuration is used, since extra messages are needed to get the address. Steps 6-8 only happen when Mobile IPv6 is used. The total comes out to approximately 18 messages at the IP level, and the exact number depends on factors like whether the mobile node has a router certificate cached before it can be ensured that it's established on a link and has full IP connectivity. And on top of handover signaling, if the mobile node does Mobile IPv6 route optimization, it may need to renew its return routability key periodically (on the order of every 7 minutes) even when it isn't moving, which means even more signaling 😩

This signaling really hurts handover performance, which is the Goal 1 problem 💀 Even more of a big deal is the total impact across lots of mobile nodes on expensive shared links (like wireless, where capacity can't easily be expanded). That can shrink the last-hop link capacity left for actual data traffic 🥺 And on links where the end user gets charged for IP traffic, IP signaling isn't free either 💸

So the goal is this: handover signaling volume from the mobile node to the network should be no more than what the mobile node needs to do secure IP-level movement detection, in cases where no link-layer support exists. NETLMM also shouldn't add any extra signaling during handover beyond what IP-level movement detection requires. If link-layer support exists for IP-level movement detection, the mobile node may not need to do any additional IP-level signaling after link-layer handover ✨🎀

3.3. Goal 3: Location Privacy 🕵️‍♀️

Okay, so in any IP network there's a risk that an attacker can figure out where a network node physically is based on its topological location 👀 It depends on how an operator deploys the network. An operator might tie subnet coverage pretty tightly to geography on some timescale, or it might assign subnets in ways that make it harder to find a node physically from its IP address. Letting the L2 attachment and the L3 address be less tightly bound is one tool for lowering this location privacy risk 🦋

Mobility adds another layer of threat 😱 An attacker can track a mobile node's geographic location in real time if the victim has to change its IP address while moving from one subnet to another across the covered area. If the mapping between IP subnets and geographic areas is fine-grained for the link type in use, the attacker can potentially gather enough info to find the victim in real time 🚨

To reduce the risk of location privacy compromises from IP address changes, the NETLMM goal is to remove the need to change IP address as a mobile node moves across links in an access network 💖 Keeping the IP address fixed over a large geographic region blurs the mapping between IP subnets and geographic area, no matter how small the natural deployment granularity is. That makes it less likely an attacker can work out the mobile node's precise location 🌈

3.4. Goal 4: Limit Overhead in the Network 🧱

Access networks, both the wired and wireless parts, usually have somewhat tighter bandwidth and router processing constraints than the backbone 😤 On the wired side, those constraints come from the cost of laying fiber or wiring to wireless access points spread across a wide geographic area. On the wireless side, they come from the limit on bits per Hertz that the physical layer protocol imposes 📡 So any solution for localized mobility management should minimize overhead within the access network 💅

3.5. Goal 5: Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection Security 🔒

Localized mobility management protocols that involve the host may need an extra security association between the mobile node and the mobility anchor. Setting that up may need extra signaling between the mobile node and the mobility anchor (see [13] for an example) 🥲 That extra security association means extra signaling, which means extra time to negotiate. So simplifying mobile-node-to-network security for localized mobility management can cut deployment barriers and improve responsiveness ⚡ Obviously, that simplification must not come at the cost of strong security guarantees for both the network and the mobile node 🛡️

In NETLMM, the network (specifically, the MAG) figures out that a mobility event happened. It can tell from link-layer handover signaling, or from IP-layer movement detection signaling sent by the mobile node, that a routing update is needed for that mobile node 🧠 That info is then used to update routing for the mobile node at the LMA. The handover signaling, or movement detection signaling, must give the network proper authentication and authorization, so the network can definitively identify the mobile node and determine what it's allowed to do 🪪 The authorization may happen at the IP level (for example, using something like SEND [3] to secure IP movement detection signaling) or at the link level. Proper authentication and authorization must be implemented on link-layer handover signaling and/or IP-level movement detection signaling so the MAG can securely deduce mobile node movement events 🔐 Security threats to the NETLMM protocol are discussed in [2] 📖

The goal is that security for NETLMM mobile node mobility management should come from IP network access and/or IP movement detection security, such as SEND or network access authentication. It should not require any additional security associations or any additional signaling between the mobile node and the network 💜✨

The number of wireless link technologies keeps growing, and it doesn't look like it's slowing down anytime soon 📈 Standardizing a wireless link's physical and medium access control layers takes a long time, so it's necessary to cut down the work needed to hook a particular wireless link technology up to an IP network 🫠 When the last-hop link is wireless, a localized mobility management solution should ideally need minimal work to interface with a new wireless link technology 🧚

Also, an edge mobility solution should support multiple wireless link technologies 🌸 The localized mobility management solution is not required to support handover from one wireless link technology to another without changing the IP address. But that possibility should not be ruled out 🦋

The goal is that the localized mobility management protocol should not use any wireless-link-specific information for basic routing management. It may still use that information for other purposes, such as securely identifying a mobile node 🫶 That's it for this part, and the rest of the goals are next, babe 💅👑

3.7. Goal 7: Support for Unmodified Mobile Nodes

Okay bestie, in the WLAN switching market nobody has to touch the software on the mobile node to get localized mobility management going 🫶 Zero modifications, literally. It's giving maximum reach, because a service provider can serve as many customers as possible, and the only real rule is that the customer is authorized for network access 💅

Another perk of keeping mobile node software minimal for localized mobility management is that multiple global mobility management protocols can be supported 🦋 There are a bunch of global protocols that might need support, including proprietary or link technology-specific ones that need backward compatibility. On the Internet, Host Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming (MOBIKE) [6] are both likely to need support, alongside Mobile IPv6 [9]. Mobile IPv4 [12] support may also be necessary ✨

Note that this goal does NOT mean the mobile node has zero software tied to mobility 🙈 The mobile node must have some kind of global mobility protocol if it wants to move from one domain of edge mobility support to another and keep session continuity. However, no global mobility protocol is required if the mobile node only moves within the coverage area of the localized mobility management protocol, or if no session continuity is needed during global movement.

Also, if the last-hop link is a wireless link, every wireless link protocol requires handover support on the mobile node in the physical and medium access control layers, typically in the wireless interface driver. Information passed from the medium access control layer up to the IP layer on the mobile node may be necessary to trigger IP signaling for IP handover. Movement detection support at the IP level may be required to figure out whether the mobile node's default router is still reachable after a move to a new access point has happened at the medium access control layer. Whether that support is needed depends on whether the medium access control layer can completely hide link movement from the IP layer. For cellular type wireless link protocols, the mobile node and network go through an extensive negotiation at the medium access control layer prior to handover, so it may be possible to trigger a routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11 [7], where the decision for handover is entirely in the hands of the mobile node, IP-layer movement detection signaling from the mobile node may be required to trigger a routing update 📡

The goal is that the localized mobility management solution should be able to support any mobile node that joins the link and has an interface that can communicate with the network, without requiring localized mobility management software on the mobile node. Main character energy for every device 🧚

3.8. Goal 8: Support for IPv4 and IPv6

While most of this document is written with IPv6 in mind, localized mobility management is a problem in IPv4 networks too 🌈 A solution for localized mobility that works for both versions of IP is desirable. The actual protocol may be slightly different, though, because of the technical details of how each IP version works. From Goal 7 (Section 3.7), minimizing mobile node support for localized mobility means that ideally no IP version-specific changes should be required on the mobile node for localized mobility, and that global mobility protocols for both IPv4 and IPv6 should be supported. Any IP version-specific features should be confined to the network protocol 🎀

3.9. Goal 9: Reuse of Existing Protocols Where Sensible

Okay so many existing protocols are already Internet Standards that the NETLMM protocol can be built on ✨ The design should have a goal of reusing existing protocols where it makes architectural and engineering sense to do so. But it should not try to reuse existing protocols where there's no real architectural or engineering reason. For example, the suite of Internet Standards has several good candidate transport layer protocols, so there's no real need to develop a new transport protocol specifically for NETLMM. Reuse is clearly the right move here, since backward compatibility with existing protocol stacks is important 💖

On the other hand, the network-based, localized mobility management functionality that NETLMM introduces is a brand new piece of functionality. So any decision about whether to reuse an existing global mobility management protocol should carefully consider whether that protocol really meets the needs of the functional architecture for network-based localized mobility management. The case for reuse is not so clear in this case, since there's no compelling backward compatibility argument 🤔

3.10. Goal 10: Localized Mobility Management Independent of Global Mobility Management

Localized mobility management should be implementable and deployable independently of any global mobility management protocol 💜 This lets the choice of local and global mobility management be made independently of the particular protocols that are implemented and deployed to solve the two different sorts of mobility management problems. The operator can choose a localized mobility management protocol based on the specific features of their access network. It can then upgrade that protocol on its own, without even informing the mobile nodes 🤫 Similarly, the mobile nodes can use whichever global mobility management protocol best suits their requirements, or skip one entirely. Also, a mobile node can move into a new access network without having to check that it understands the localized mobility management protocol being used there.

The goal is that the implementation and deployment of the localized mobility management protocol should not restrict, or be restricted by, the choice of global mobility management protocol. Independence is the whole vibe 👑

3.11. Goal 11: Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access Gateway

Different network operators may need different types of forwarding options between the LMA and the MAGs for mobile node data plane traffic. An obvious forwarding option that past IETF localized mobility management protocols have used is IP-IP encapsulation for bidirectional tunneling. The tunnel endpoints are the LMA and the MAGs. But other options are possible. Some network deployments may prefer routing-based solutions. Others may require security tunnels using IPsec Encapsulating Security Payload (ESP) encapsulation, if part of the localized mobility management domain runs over a public access network and the network operator wants to protect the traffic 🔐

A goal of the NETLMM protocol is to allow the forwarding between the LMA and MAGs to be configurable depending on the particulars of the network deployment. Configurability is not expected to be dynamic, as in controlled by the arrival of a mobile node. Instead, configuration is expected to be similar in timescale to configuration for routing 🛠️ The NETLMM protocol may designate a default forwarding mechanism. It's also possible that additional work may be required to specify the interaction between a particular forwarding mechanism and the NETLMM protocol, but this work is not in scope of the NETLMM base protocol 🌸

4. Security Considerations 🚨

Okay this part is seriously important, so listen up 👀 There are two kinds of security issues involved in network-based localized mobility management. The first is security between the mobile node and the network. The second is security between the network elements that participate in the NETLMM protocol. The security-related goals in this document, described in Section 3.3 and 3.5, focus on the former, because those are unique to network-based mobility management. The threat analysis document [2] contains a more detailed discussion of both kinds of threats, which the protocol design must address ⚠️

5. Acknowledgements 🫶

The authors would like to acknowledge the following people for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin. Huge thank-yous to these legends 🌟

6. Normative References

  • [1] Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
  • [2] Vogt, C., and Kempf, J., "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.

7. Informative References

  • [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [4] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005.
  • [6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
  • [7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.
  • [8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 2001.
  • [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
  • [11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
  • [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
  • [14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

8. Contributors 🌷

Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com

Phil Roberts
Motorola Labs
Schaumberg, IL
USA
EMail: phil.roberts@motorola.com

Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
EMail: nishidak@nttdocomo.co.jp

Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 Torino
Italy
Phone: +39 011 2286904
EMail: gerardo.giaretta@tilab.com

Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221-90511-46
EMail: marco.liebsch@ccrle.nec.de

Editor's Address 🧚

James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com

okay so the copyright bit 💅 Copyright (C) The IETF Trust (2007). ✨ this doc is covered by the rights, licenses and restrictions in BCP 78, and except for what BCP 78 says, the authors keep all their rights 🦋

the doc and all the info in it are given "AS IS" 🫶 and the contributor, the org they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all say NO to every warranty, express or implied 😭 that includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 💀 yikes but also very clear

Intellectual Property

the IETF doesn't take a side on whether any IPR or other rights people claim about the tech in this doc are valid or how far they reach 🙈 it also doesn't say it looked into whether any such rights exist 🧚 if you want the rules on rights in RFC docs, check BCP 78 and BCP 79 💜

copies of IPR disclosures sent to the IETF Secretariat 🎀 plus any promises of licenses, or the result of trying to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🌸

and the IETF is literally inviting anyone interested 🫶 to bring up any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🔥 send that info to the IETF at ietf-ipr@ietf.org 💖

Acknowledgement

the RFC Editor function is funded right now by the Internet Society 🌈 thank you, Internet Society 👑✨

📦 where this page comes from