RFC 4260

Mobile IPv6 Fast Handovers for 802.11 Networks

📅 published November 2005, from ietf

Mobile IPv6 Fast Handovers for 802.11 Networks 💖

Okay bestie, first the paperwork 📋. This is RFC 4260, from the Network Working Group. It was written by P. McCann at Lucent Technologies, filed as Informational (so it's sharing info, not setting a standard 🙈), and dated November 2005. The header doesn't list anything it obsoletes or updates. Now let's get into it 🦋

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract 🌸

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers that follow the 802.11 suite of specifications. It's giving "how do we make this work on wifi" energy 📶

Table of Contents 🧚

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Terminology .....................................................2
   3. Deployment Architectures for Mobile IPv6 on 802.11 ..............3
   4. 802.11 Handovers in Detail ......................................5
   5. FMIPv6 Message Exchanges ........................................7
   6. Beacon Scanning and NAR Discovery ...............................8
   7. Scenarios .......................................................9
      7.1. Scenario 1abcdef23456g .....................................9
      7.2. Scenario ab123456cdefg ....................................10
      7.3. Scenario 123456abcdefg ....................................10
   8. Security Considerations ........................................10
   9. Conclusions ....................................................12
   10. References ....................................................13
      10.1. Normative References .....................................13
      10.2. Informative References ...................................13
   11. Acknowledgements ..............................................13

1. Introduction ✨

Okay so the whole point of a Mobile IPv6 Fast Handover [2] is to make the service drop as short as possible when a mobile node switches its point of attachment to the Internet 🏃‍♀️💨 Without this, the mobile node can't send or receive packets from the moment it disconnects from one point of attachment in one subnet until it registers a new care-of address from the new point of attachment in the new subnet. That gap would be totally unacceptable for real-time stuff like Voice-over-IP 📞💀

The big idea is to use info from the link-layer technology to either predict a handover or respond to it super fast ⚡ That way IP connectivity comes back at the new point of attachment sooner than it otherwise could. By tunneling data between the old and new access routers, IP connectivity can be provided before the Mobile IP registration with the home agent or correspondent node is finished. So real-time services can get going again without waiting for that registration to complete. Mobile IP registration involves Internet round-trips, which take time, so a Mobile IPv6 fast handover can cause a smaller interruption in real-time services than an ordinary Mobile IP handover does 🫶

The link-layer info you actually get, and when you get it (before, during, or after a handover has happened), depends on which link-layer technology you're using 🤔 This document gives a set of deployment examples for Mobile IPv6 Fast Handovers on 802.11 networks. We start with a quick overview of the relevant parts of basic 802.11 [3]. Then we look at how and when handover info might become available to the IP layers that implement Fast Handover, both in the network infrastructure and on the mobile node. Finally, we trace the protocol steps for Mobile IPv6 Fast Handover in this environment 💜

1.1. Conventions Used in This Document 📝

When you see the capitalised key words in this document, like "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", they're to be read exactly as RFC 2119 [1] describes them 🙌

2. Terminology 📚

This doc borrows all of its terminology from Mobile IPv6 Fast Handovers [2], plus some extra terms from the 802.11 specification [3]. Some of the definitions are slightly tweaked for clarity 🌈

  • Access Point (AP): Any entity that has station functionality and gives access to the distribution services, through the wireless medium (WM), for associated stations 📡
  • Association: The service used to set up the access point/station (AP/STA) mapping and let an STA get access to the Distribution System 🔗
  • Basic Service Set (BSS): A group of stations run by one coordination function. That function can be centralised (like in a single AP) or distributed (like in an ad hoc network). You can think of a BSS as the coverage area of one AP 🗺️
  • Distribution System (DS): A system that connects a bunch of basic service sets (BSSs) and integrated local area networks (LANs) together to make an extended service set (ESS) 🧵
  • Extended Service Set (ESS): One or more connected BSSs and integrated LANs that look like a single BSS to the logical link control layer of any station associated with one of those BSSs. You can think of it as the coverage area of a bunch of APs all hooked up through the Distribution System. It may consist of one or more IP subnets 🌐
  • Station (STA): Any device with an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM) 📱

3. Deployment Architectures for Mobile IPv6 on 802.11 🏗️

Here we go through the two most likely setups for how Access Points (APs), Access Routers (ARs), and IP subnets can relate to each other in an 802.11 network 🫧 This doc mostly focuses on the infrastructure mode [3] of 802.11. Usually, a given STA is associated with one and only one AP at any given moment. However, implementations are possible [4] where an STA keeps multiple associations, as long as the APs are connected to disjoint DSs. An STA can only talk to an AP when the radio conditions allow it 📶 Also, just like with any layer-2 tech, handing over from one layer-2 point of attachment (AP) to another doesn't necessarily mean changing the AR or the subnet 🙈

                  AR                              AR
            AR     |    AR                   AR    |     AR
              \    |   /                       \   |    /
               Subnet 1                         Subnet 2
             /  /  |  \  \                    /  /  |  \  \
            /  /   |   \  \                  /  /   |   \  \
           /   |   |   |   \                /   |   |   |   \
        AP1  AP2  AP3  AP4  AP5          AP6  AP7  AP8  AP9  AP10

             Figure 1.  An 802.11 deployment with relay APs.

Figure 1 shows a typical 802.11 deployment with two IP subnets, each with three Access Routers and five Access Points 🥰 In this figure the APs are acting as link-layer relays, which means they carry Ethernet-layer frames between the wireless medium and the subnet. APs don't usually run any particular spanning tree algorithm, but they're smarter than simple bridges that would relay all traffic. Only traffic addressed to STAs known to be associated with a given AP gets forwarded 🧠 Each subnet sits on top of a single LAN or VLAN, and in this example we assume APs 6-10 can't reach the VLAN that Subnet 1 runs on 🚫

So a handover from AP1 to AP2 doesn't need an AR change. (Here we assume the STA will be placed on the same VLAN during the handoff.) That's because all three ARs are reachable at the link layer from an STA connected to any of AP1-5 💖 These handoffs wouldn't need IP-layer mobility management, though some IP-layer signaling may be required to figure out that connectivity to the existing AR is still available.

A handover from AP5 to AP6, though, does need an AR change 😭 AP6 can't reach the VLAN that Subnet 1 is on, so the STA would be attaching to a different subnet. An IP-layer handover mechanism would have to be invoked to give low-interruption handover between the two ARs 🚀

                                Internet
                               /    |   \
                              /     |    \
                             /      |     \
                           AR      AR      AR
                           AP1     AP2     AP3

        Figure 2. An 802.11 deployment with integrated APs/ARs.

Figure 2 shows a different 802.11 setup where each AP is integrated with exactly one AR on a disjoint VLAN 🌸 Here, every change of AP means a change of AR too, so you'd need some IP-layer handover mechanism to get low-interruption handover between the ARs. Also, the AR shares a MAC-layer identifier with its attached AP 🔥

In the next section we look at the steps involved in any 802.11 handover. The sections after that talk about how those steps could be combined with an IP-layer handover mechanism in each of the deployment scenarios above ✨

4. 802.11 Handovers in Detail ✨

okay so an 802.11 handover happens when an STA switches its association from one AP to another. that's called "re-association" 💖 and it goes like this:

  1. The STA realizes a handoff is necessary because the radio environment for the current AP is getting worse 📉
  2. The STA performs a scan to see which APs are available. The result is a list of APs together with physical layer information, like signal strength 📡
  3. The STA chooses one of the APs and performs a join to synchronize its physical and MAC-layer timing parameters with the selected AP ⏱️
  4. The STA requests authentication with the new AP. For an "Open System", that's a single round-trip message exchange with null authentication 🤝
  5. The STA requests association or re-association with the new AP. A re-association request contains the MAC-layer address of the old AP, while a plain association request does not 🙈
  6. If operating in accordance with 802.11i [6], the STA and AP execute 802.1X EAP-on-LAN procedures to authenticate the association. Step 3 would have executed in "Open System" mode 🔐
  7. The new AP sends a Layer 2 Update frame on the local LAN segment to update the learning tables of any connected Ethernet bridges 🌉

Okay so, we preface step 1 with step 0 just to make it easier to picture, but there's no standardized trigger for step 1 🫶 It can happen because the radio conditions on the current AP are decaying, or at other times that local implementation decisions pick. Some network interface cards (NICs) scan in the background, interleaving scans between data packets. That makes roaming faster if the current AP isn't doing well, but it's a lot for the AP to handle 😭 Typically the STA puts the AP into power-save mode before the scan, then goes back to the AP's channel after the scan to grab queued packets. That can lead to buffer exhaustion on the AP and packet loss. Not ideal!!

During step 2, the STA does rate adjustment, where it picks the best available transmission rate. Rate adjustment can be pretty time-consuming and unpredictable too 🐢

Note that in some existing 802.11 implementations, steps 1-4 run in firmware back to back. Even then, step 3 is sometimes done in a host driver, especially in newer implementations. This might make it impossible for the host to do anything (including sending or receiving IP packets) until the handover is done 🙃 In other 802.11 implementations, the scan (step 1) and join (step 2) can be invoked independently. That means, for example, you could do step 1 way ahead of the handover, maybe even before any real-time traffic starts 🧚 This could seriously cut the handover latency, since one study concluded that the 802.11 beacon scanning function may take several hundred milliseconds to complete [8]. During that time, sending and receiving IP packets is not possible. However, scanning too far in advance may make the info out-of-date by handover time. If radio conditions have changed so much that the target AP is no longer reachable, the joint operation fails. So a host may choose to do scanning based on, among other considerations, the age of the previously scanned info. In general, deciding on subsequent scans is a policy issue that any given implementation of FMIPv6 over 802.11 must consider carefully 🧐

Even if steps 1 and 2 run back to back, there's no guarantee that an AP found in step 1 will still be available in step 2, because radio conditions can change dramatically from moment to moment 🎢 The STA may then decide to associate with a completely different AP. Often this decision is made in firmware, and the attached host has no control over which AP gets chosen. However, tools like the host AP driver [10] give full control over when and which AP the host associates with 👑 Operation as an Independent BSS (IBSS) or "ad-hoc mode" [3] may also allow the necessary control, although in this latter case, attaching to an infrastructure AP would be impossible. Implementers can use tools like these to get the best combo of flexibility and performance 💅

The coverage area of a single AP is called a Basic Service Set (BSS). An Extended Service Set (ESS) is formed from a collection of APs that all broadcast the same ESSID 🌈 Note that an STA would send a re-association (which includes both the old and new AP addresses) only if the ESSID of the old and new APs is the same.

A change of BSS within an ESS may or may not need an IP-layer handover, depending on whether the APs can send packets to the same IP subnets. If an IP-layer handover is needed, then FMIPv6 can decrease the overall latency of the handover ⚡ The main goal of this document is to describe the most reasonable scenarios for how the events of an 802.11 handover may interleave with the message exchanges in FMIPv6. Main character energy, literally 👑

5. FMIPv6 Message Exchanges

okay so an FMIPv6 handover nominally consists of the following messages 🦋

  • a. The mobile node (MN) sends a Router Solicitation for Proxy (RtSolPr) to find out about neighboring ARs.
  • b. The MN receives a Proxy Router Advertisement (PrRtAdv) containing one or more [AP-ID, AR-Info] tuples.
  • c. The MN sends a Fast Binding Update (FBU) to the Previous Access Router (PAR).
  • d. The PAR sends a Handover Initiate (HI) message to the New Access Router (NAR).
  • e. The NAR sends a Handover Acknowledge (HAck) message to the PAR.
  • f. The PAR sends a Fast Binding Acknowledgement (FBack) message to the MS on the new link. The FBack is also optionally sent on the previous link if the FBU was sent from there 💌
  • g. The MN sends a Fast Neighbor Advertisement (FNA) to the NAR after attaching to it 🎀

The MN may connect to the NAR before sending the FBU if the handover is unanticipated 🙈 In that case, the FNA (step g) would contain the FBU (listed as step c above), and then steps d, e, and f would take place from there. Plot twist, but iykyk 😭

6. Beacon Scanning and NAR Discovery

okay the RtSolPr message is used to request info about the router(s) connected to one or more APs 🌸 The APs are specified in the New Access Point Link-Layer Address option in the RtSolPr, and the associated IP-layer info comes back in the IP Address Option of the PrRtAdv [2]. On an 802.11 link, the link-layer address is the BSSID of some AP.

Beacon scanning (step 1 from Section 4) produces a list of available APs, along with signal strength info for each one 📡 This list supplies the addresses for the New Access Point Link-Layer Address option(s) in the RtSolPr messages. To get this list, the host needs to invoke the MLME-SCAN.request primitive (see Section 10.3.2.1 of the 802.11 specification [3]). The BSSIDs returned by this primitive are the link-layer addresses of the available APs.

Because beacon scanning takes on the order of a few hundred milliseconds to complete, and because it's generally not possible to send and receive IP packets during that time, the MN needs to schedule these events with care so they don't disrupt ongoing real-time services 🫠 For example, the scan could happen when the MN attaches to the network, before any real-time traffic. However, if the gap between scanning and handover is too long, the neighbor list may be out of date. The signal strengths of neighboring APs may have changed dramatically, and a handover directed at the apparently best AP from the old list may fail 💀 If the handover runs in firmware, the STA may even pick a new target AP that's totally missing from the old list (after doing its own scan). Both cases would limit the MN's ability to choose the correct NAR for the FBU in step c during an anticipated handover. Ongoing work in the IEEE 802.11k task group may address extensions that allow interleaving beacon scanning with data transmission and reception, along with buffering at APs to minimize packet loss 🔥

Note that, aside from physical layer parameters like signal strength, it may be possible to get all the necessary info about neighboring APs by using the wildcard form of the RtSolPr message 🧠 This makes the current access router return a list of neighboring APs, and it doesn't interrupt ongoing communication with the current AP. The request could be made when the MN first attaches to the access router and periodically after that. This would let the MN cache the necessary [AP-ID, AR-Info] tuples, and it might help it react faster when a handover becomes necessary because of a changing radio environment. However, since the info doesn't include up-to-date signal strength, it wouldn't let the MN accurately predict the next AP before a handover.

Also, if the network is big enough that a given access router is attached to lots of APs, there may not be room to list all of them in the PrRtAdv 📋

The time taken to scan for beacons is significant, because it means iterating through all 802.11 channels and listening on each one for active beacons 😩 A more targeted approach would let the STA scan just one or two channels of interest, which would cause a much shorter interruption of real-time traffic. However, optimizations like that are currently outside the scope of 802.11 specifications.

7. Scenarios

okay so here we look at a few possible scenarios for using FMIPv6 in an 802.11 context 🧚 Each scenario is labeled by the sequence of events that take place. The numbered events come from Section 4, and the lettered events come from Section 5. For example, 1abcde23456fg represents step 1 from Section 4, followed by steps a-e from Section 5, followed by steps 2-6 from Section 4, followed by steps f and g from Section 5. This is the sequence where the MN performs a scan, then the MN runs the FMIPv6 messaging to get NAR info and send a binding update, then the PAR starts the HI/HAck exchange, then the 802.11 handover completes, and finally the HAck is received at the PAR and the MN sends an FNA 🎉

Each scenario comes with a brief description and discussion of its benefits and drawbacks 💜

7.1. Scenario 1abcdef23456g

okay so this is the predictive mode from the FMIPv6 spec, and it's giving planning 📅🦋. The host runs the scan way before the handover, and it can send the FBU before the handover even happens. After the handover, the only thing it sends is the FNA. 💅

This only works if the scan and join operations (steps 1 and 2) can be done separately and under host control, so that steps a-f can be slotted in between 1 and 2. Like I said earlier, some implementations give you that control [10] and some don't 😭.

Steps 1ab can happen way in advance of the handover, which takes them off the critical path ✨. That means less service interruption from beacon scanning, and at least one RtSolPr/PrRtAdv exchange gets to finish, so the host has link-layer info about some NARs 🫶. But if steps ab got delayed until the handover was basically here, there's no guarantee the RtSolPr/PrRtAdv exchange would finish, especially when the connection to the old AP is falling apart fast 💀.

Here's the catch though. If there's a long gap between the scan and the handover, the FBU (step c) gets built with out-of-date info 🙈. Nothing guarantees the MN will actually attach to the AP it wanted after sending the FBU to the oAR, because the radio conditions can shift and suddenly make the NAR unreachable. If that happens, the handover has to fall back to one of the reactive cases below 🔥.

7.2. Scenario ab123456cdefg

this one is the reactive mode from the FMIPv6 spec 🌈. It doesn't need any host intervention between steps 1 and 2.

BUT (and this is a big but) the MN does have to get the link-layer address of the NAR before the handover. That way it has a link-layer destination address for outgoing packets, which is the default router info 📮. That address then gets used to send the FNA (with the encapsulated FBU) once the MN hits the new subnet 🧚.

7.3. Scenario 123456abcdefg

in this one, the MN doesn't learn anything about the NAR before the handover. It's totally reactive 😤. It solicits a router advertisement after the handover, then sends an FNA with the encapsulated FBU right away 🚀.

This might be the move when it's hard to figure out the link-layer address of the NAR ahead of time. For example, if the host doesn't have access to the scan primitive, and the wildcard PrRtAdv form returns way too many results 📚. Sometimes you can skip the router advertisement/solicitation steps (ab) if the NAR's link-layer address can be learned some other way 🔍. In the deployment shown in Figure 2, that's exactly the new AP's MAC-layer address, and it can be learned from the link-layer handover messages 🎀. But in the case of Figure 1, that info has to come from some form of router discovery 🌸.

Also, even in the Figure 2 case, the MN somehow has to find out that it's actually on a Figure 2 network and not a Figure 1 network. Iykyk 👀.

8. Security Considerations

the security considerations for FMIPv6 are covered in the base FMIPv6 spec [2], and they are SERIOUS 🚨. The PAR has to be sure the FBU is authentic before it starts redirecting user traffic. If the association with the new AP isn't protected with mutual authentication, a rogue AP could trick the MN into sending an FBU to the PAR when that's totally not in its best interest 😱.

Heads up: step 6 from Section 4 installs layer-2 forwarding state that can redirect user traffic. If a malicious node can trigger it, that can cause a service disruption 💀.

Step 3 from Section 4 could give some security, but because of the known weaknesses in Wired Equivalent Privacy (WEP) shared key security [9], it should not be relied on 🙅‍♀️. Instead, the Robust Security Network [6] will require the STA to go through 802.1X Port-Based Network Access Control [5] before it moves on to steps 5 or 6 🔐. 802.1X is how you encapsulate Extensible Authentication Protocol (EAP) on 802 networks (EAPOL, which stands for "EAP over LANs") 🧠. With this, the client and AP do an EAP exchange, and that exchange can wrap any of the different EAP authentication methods ✨. The EAPOL exchange can output a Master Session Key (MSK) and an Extended Master Session Key (EMSK). Those can then be used to derive transient keys, and the transient keys can encrypt and/or authenticate later traffic 🗝️.

It's also possible to use 802.1X pre-authentication [6] between a STA and a target AP while the STA is still associated with another AP 🙌. That lets authentication happen before the handover, so service can resume faster after roaming 🏃‍♀️. But here's the tea: EAPOL frames only carry MAC-layer addresses, not IP-layer ones. So this is currently only specified to work inside a single VLAN, where IP-layer handover mechanisms aren't necessarily needed anyway 🤷‍♀️. In the most interesting case for FMIPv6 (roaming across subnet boundaries), the 802.1X exchange would have to happen after the handover to the new AP. That adds handover delay while the 802.1X exchange takes place, and it may also involve round-trips to RADIUS or Diameter servers 🐢. The EAP exchange could be skipped if a preexisting Pairwise Master Key (PMK) is found between the STA and the AP. That might happen if the STA has visited that AP before, or visited one that shares a common back-end infrastructure 💜.

Maybe faster cross-subnet authentication could come from pre-authentication using an IP-layer mechanism that works across subnet boundaries 🌐. As far as the authors know, nobody in the IEEE is working on this kind of thing right now 🤔. The security considerations of these new approaches would need to be studied very carefully 🔍.

9. Conclusions

the Mobile IPv6 Fast Handover spec gives us a protocol for shortening the period of service interruption during a change in link-layer point of attachment ⚡. This document shows how that protocol can be applied in 802.11 access networks 🛜.

FMIPv6 has to be implemented in the context of a particular link-layer implementation, and that link layer has to supply the triggers for the FMIPv6 message flows 🎯. For example, the host has to be notified of things like signal strength degrading or attaching to a new AP 📶.

The particular 802.11 hardware and firmware can decide how FMIPv6 is able to operate 🧩. For example, for a predictive handover, the scan request primitive has to be available to the host, and the firmware has to run join operations only under host control [10], not on its own in response to its own handover criteria 🙅‍♀️. Getting the desired PrRtAdv and sending an FBU right before the handover means messages have to be exchanged over the wireless link while the connection is degrading 😵. In some cases, the scenario in Section 7.1 might not finish successfully, or the FBU might redirect traffic to the wrong NAR 💔. But in those cases, the handover may fall back to the scenario from Section 7.2 or the scenario from Section 7.3 🫶. Ultimately, falling back to basic Mobile IPv6 operation [7] and sending a Binding Update straight to the Home Agent can be used to recover from any failure of the FMIPv6 protocol 🦸‍♀️✨.

10. References

10.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
  • [3] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition.
  • [4] Bahl, P., Bahl, P., and Chandra, R., "MultiNet: Enabling Simultaneous Connections to Multiple Wireless Networks Using a Single Radio", Microsoft Tech Report, MSR-TR-2003-46, June 2003.
  • [5] "Port-Based Network Access Control", IEEE Std 802.1X-2004, July 2004.
  • [6] "Medium Access Control (MAC) Security Enhancements", IEEE Std 802.11i-2004, July 2004.
  • [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

10.2. Informative References

  • [8] Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University of Maryland Department of Computer Science, September 2002.
  • [9] Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile Communications: The Insecurity of 802.11", Proceedings of the Seventh Annual International Conference on Mobile Computing and Networking, July 2001, pp. 180-188.
  • [10] Malinen, J., "Host AP driver for Intersil Prism2/2.5/3 and WPA Supplicant", http://hostap.epitest.fi/, July 2004.

11. Acknowledgements

big thank yous 🙏💖! Bob O'Hara explained things and gave insight on the 802.11 standards 🧠. Thanks also to James Kempf, Erik Anderlind, Rajeev Koodli, and Bernard Aboba for commenting on earlier versions 🫶.

Author's Address

Pete McCann
Lucent Technologies
Rm 9C-226R
1960 Lucent Lane
Naperville, IL  60563

Phone: +1 630 713 9359
Fax:   +1 630 713 1921
EMail: mccap@lucent.com

Copyright (C) The Internet Society (2005) 🌸.

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all of their rights 📜.

This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 ⚠️.

Intellectual Property

the IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid or in scope, or on whether any license under those rights is or isn't available. It also doesn't say it has made any independent effort to find those rights 🧐. Info about how rights work for RFC documents is in BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 💜✨.

📦 where this page comes from