RFC 4222

Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance

📅 published October 2005, from ietf

RFC 4222 title block, bestie 🎀

  • Network Working Group
  • RFC: 4222
  • BCP: 112
  • Category: Best Current Practice
  • Author: G. Choudhury, Ed., AT&T
  • Date: October 2005
  • Obsoletes: none listed
  • Updates: none listed

Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance 💖

Status of This Memo 🌸

okay so this doc is an Internet Best Current Practice for the Internet Community, and it's literally asking for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited, so share it with your whole group chat 💅

Copyright (C) The Internet Society (2005).

Abstract ✨

this doc recommends methods that are meant to make big networks using Open Shortest Path First (OSPF) Version 2 more scalable and more stable 🔥 the main moves are processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority than other OSPF packets, plus some other congestion avoidance procedures. it's giving protecting the VIPs of the network 👑

Table of Contents 🧚

   1. Introduction...................................................2
   2. Recommendations................................................3
   3. Security Considerations........................................6
   4. Acknowledgments................................................6
   5. Normative References...........................................6
   6. Informative References.........................................7
   Appendix A. LSA Storm: Causes and Impact..........................8
   Appendix B. List of Variables and Values.........................10
   Appendix C. Other Recommendations and Suggestions................11

1. Introduction 🦋

okay, first things first: in this doc, OSPF means OSPFv2 [Ref1] 💅 the scalability and stability techniques described here might also work for OSPFv3 [Ref2], but that's giving "needs more research and real-world experience" 🔬

so picture this: a big network running OSPF can sometimes get hit with a bunch of LSAs getting updated at the same time, or at least really close together 😭 this is extra true if the OSPF traffic engineering extension [Ref3] is in use, because that can seriously ramp up how many LSAs are floating around. we call this event an LSA storm 🌪️ it can be kicked off by an unscheduled failure or a scheduled maintenance event, and the failure can be hardware, software, or procedural in nature. no cap, any of those can be the villain 💀

here's the drama. an LSA storm makes the router's CPU and memory usage go super high, so incoming packets get delayed or dropped 🙈 delayed acknowledgments (beyond the retransmission timer value) lead to retransmissions, and delayed Hello packets (beyond the router-dead interval) make neighbor adjacencies get declared down 💔 then the retransmissions and extra LSA originations pile on even more CPU and memory usage, which is basically a positive feedback loop. in the extreme case, that loop may push the whole network into an unstable state 😵‍💫

the default retransmission timer is 5 seconds, and the default router-dead interval is 40 seconds ⏱️ BUT recently everyone's been obsessed with making OSPF convergence way faster 🚀 as part of that plan, much shorter (sub-second) Hello and router-dead intervals have been proposed [Ref4]. in that setup, Hello packets are more likely to get delayed past the router-dead interval during the congestion an LSA storm causes. ngl, that's a big yikes 😬

so to make networks more scalable and stable, this doc recommends steps for prioritizing critical OSPF packets and avoiding congestion ✨ the details live in Section 2. a simulation study in [Ref13] quantifies the congestion phenomenon and its impact 📊 it also tests several of the recommendations and shows that they really do improve the scalability and stability of networks running OSPF 🎀 [Ref13] is available on request if you contact the editor or one of the authors, so slide into their DMs 💌

Appendix A digs deeper into LSA storm scenarios and their impact, and it points out a few real-life examples of control-message storms 🍓 Appendix B has a list of the variables used in the recommendations, along with their example values 🧮 and Appendix C has some extra recommendations and suggestions with similar goals 🌈

2. Recommendations 🎀

okay so these recommendations are all about making big OSPF networks scale better and stay stable 🧚 💖 when things get congested. during congestion they cut down on retransmissions, stop an adjacency from getting declared down just because Hello packets showed up late past the RouterDeadInterval, and take other congestion avoidance steps. the recs aren't in any set order, except that Recommendation 2 is only for when Recommendation 1 isn't implemented. so keep that in mind, bestie 💅

(1) Classify all OSPF packets in two classes. Sort everything into a "high priority" class (OSPF Hello packets and Link State Acknowledgement packets) and a "low priority" class (literally everything else) ✨. You figure out which is which by looking at the OSPF packet header. When you're receiving from a neighbor and when you're transmitting to one, try to process a "high priority" packet before a "low priority" one. main character energy 👑

Here's the catch though 🙈. Prioritized processing while transmitting can make OSPF packets from a neighbor show up out of sequence. If Cryptographic Authentication (AuType = 2) is in use (as specified in [Ref1]), then successive valid OSPF packets from a neighbor need a non-decreasing "Cryptographic sequence number". So to keep that working, we recommend that when Cryptographic Authentication (AuType = 2) is used [Ref1], prioritized processing is NOT done at the transmitter. That way packets don't arrive at the receiver out of sequence 🫶 Once security processing at the receiver is finished (sequence number checking included), the packets can go into a "high priority" queue or a "low priority" queue based on their class and get processed from there.

The payoff is clearly bigger without Cryptographic Authentication, since then you can prioritize on both the transmitter and the receiver 🔥 But even WITH Cryptographic Authentication, it's still worth prioritizing at the receiver (after security processing). ngl that's a whole vibe 🌸

(2) If Recommendation 1 cannot be implemented, reset the inactivity timer differently. Instead of only resetting the inactivity timer when a Hello packet arrives, reset it whenever any OSPF unicast packet, or any OSPF packet sent to AllSPFRouters over a point-to-point link, is received over that adjacency 🦋 That way OSPF only declares the adjacency down if no OSPF unicast packets, and no OSPF packets sent to AllSPFRouters over a point-to-point link, come in over that adjacency for a period equaling or exceeding the RouterDeadInterval. We don't recommend this one alongside Recommendation 1 to avoid potential undesirable side effects 🙈 One of those side effects is a delay in noticing that an adjacency is down. This happens when no high priority Hello packets are coming in but the inactivity timer keeps getting reset by stale packets sitting in the low priority queue. yikes, not me getting stuck like that 💀

(3) Use an exponential backoff algorithm for the LSA retransmission interval (RxmtInterval). Let R(i) be the RxmtInterval value used during the i-th retransmission of an LSA. Use this algorithm to compute R(i) 🍓

                R(1) = Rmin
                R(i+1) = Min(KR(i),Rmax)  for i>=1

K, Rmin, and Rmax are constants, and Min(.,.) gives you the minimum of its two arguments. Example values are 2 for K, 5 for Rmin, and 40 seconds for Rmax 💜 Also, the example value for Rmin (the initial retransmission interval) is the same as the sample value of RxmtInterval in [Ref1], so it lines up nicely.

This one is motivated by a super real observation: during a congestion event caused by control messages, a big reason the congestion keeps going is repeated LSA retransmissions 😭 Using exponential backoff for the LSA retransmission interval cuts the rate of LSA retransmissions while the network is congested (which is exactly when multiple retransmissions of the same LSA are most likely to happen). That helps the network actually get out of the congested state. iconic behavior 👑

(4) Implicit Congestion Detection and Action Based on That. If a router has control message congestion, its neighbors don't know about it explicitly 🫣 But they can detect it implicitly based on the number of unacknowledged LSAs sent to that router. If that number goes above a certain "high-water mark", the rate at which LSAs are sent to the router should be reduced progressively using exponential backoff, but never below a certain minimum rate 🌈 Later on, if the number of unacknowledged LSAs to that router drops below a certain "low-water mark", the rate of sending LSAs should be increased progressively, again with exponential backoff, but never above a certain maximum rate ✨ Here's the full algorithm. This algorithm gets applied independently to each neighbor, and only for unicast LSAs sent to a neighbor or LSAs sent to AllSPFRouters over a point-to-point link 🧚

Let,

U(t) = Number of unacknowledged LSAs to neighbor at time t.
H = A high-water mark (in units of number of unacknowledged
    LSAs).
L = A low-water mark (in units of number of unacknowledged LSAs).
G(t) = Gap between sending successive LSAs to neighbor at time t.
F = The factor by which the above gap is to be increased during
    congestion and decreased after coming out of congestion.
T = Minimum time that has to elapse before the existing gap
    is considered for change.
Gmin = Minimum allowed value of gap.
Gmax = Maximum allowed value of gap.

Here's how the gap changes after a time T has passed since the last change 🍓

          _
         |
         | Min(FG(t),Gmax) if U(t+T) > H
G(t+T) = | G(t) if H >= U(t+T) >= L
         | Max(G(t)/F,Gmin) if U(t+T) < L
         |_

Min(.,.) and Max(.,.) give you the minimum and maximum values of their two arguments, respectively 💅

Example values for the parameters are H = 20, L = 10, F = 2, T = 1 second, Gmin = 20 ms, and Gmax = 1 second 🌸

Okay, Recommendations 3 and 4 both slow down LSAs to congested neighbors by implicitly detecting congestion, but they're different. Recommendation 3 slows down successive retransmissions of the same LSA over and over 🔁 Recommendation 4 slows down ALL LSAs (new ones or retransmissions) headed to a congested neighbor 🫶

(5) Throttling Adjacencies to Be Brought Up Simultaneously. If a router tries to bring up a huge number of adjacencies to its neighbors all at the same time, that can cause severe congestion from database synchronization and LSA flooding activities 😵‍💫 So during a situation like that, we recommend that no more than "n" adjacencies should be brought up simultaneously. Once a subset of adjacencies has come up successfully, newer adjacencies may be brought up, as long as the number of adjacencies being brought up at once doesn't go over "n" 🎀 The right value of "n" depends on the router's processing power, the total bandwidth available for control plane traffic, and propagation delay. And "n" should be configurable 🦋

With throttling, the order in which adjacencies get formed is a big deal. We recommend a First Come First Served (FCFS) policy based on the order that adjacency formation requests arrive 🏃‍♀️ Requests can come from neighbors or be self-generated. For the self-generated ones, a priority list may be used to decide the order they get made in. Once an adjacency formation process starts, though, it should not be preempted, except for unusual circumstances like errors or time-outs 🙈

In some of the recommendations above, we talk about point-to-point links. Those references should also cover cases where a broadcast network is treated as a point-to-point connection from the standpoint of IP routing [Ref5] 🌈

3. Security Considerations 🔐

This memo does not create any new security issues for the OSPF protocol 🫶 phew, no new security drama here ✨

4. Acknowledgments 💖

We'd like to thank the support and helpful comments from OSPF WG chairs Rohit Dube, Acee Lindem, and John Moy; Routing Area directors Alex Zinin and Bill Fenner; and the IESG reviewers 👑 We also thank Vivek Dube, Mitchell Erblich, Mike Fox, Tony Przygienda, and Krishna Rao for their comments on previous versions of the document 🧚 And we acknowledge Margaret Chiosi, Elie Francis, Jeff Han, Beth Munson, Roshan Rao, Moshe Segal, Mike Wardlow, and Pat Wirth for their collaboration and encouragement in our scalability improvement efforts for Link State Protocol-based networks 💜

5. Normative References 📚

[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[Ref2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.

6. Informative References 🔖

[Ref3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Millisecond IGP Convergence", Work in Progress.

[Ref5] N. Shen, A. Lindem, J. Yuan, A. Zinin, R. White and S. Previdi, "Point-to-point operation over LAN in link-state routing protocols", Work in Progress.

[Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net outage", Network World, February 26, 2001.

[Ref7] "AT&T announces cause of frame-relay network outage," AT&T Press Release, April 22, 1998.

[Ref8] Cholewka, K., "MCI Outage Has Domino Effect", Inter@ctive Week, August 20, 1999.

[Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat", Light Reading, April 6, 2001.

[Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State Routing Protocols", Work in Progress.

[Ref11] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in Stable Topologies", RFC 4136, July 2005.

[Ref12] G. Ash, G. Choudhury, V. Sapozhnikova, M. Sherif, A. Maunder, V. Manral, "Congestion Avoidance & Control for OSPF Networks", Work in Progress.

[Ref13] G. Choudhury, G. Ash, V. Manral, A. Maunder and V. Sapozhnikova, "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance: Algorithms and Simulations", AT&T Technical Report, August 2003.

[Ref14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

Appendix A. LSA Storm: Causes and Impact 🌪️

okay so an LSA storm can kick off for a bunch of reasons, bestie 💅 here are some examples:

  • (a) one or more link failures due to fiber cuts,
  • (b) one or more router failures for some reason, e.g., software crash or some type of disaster (including power outage) in an office complex hosting many routers,
  • (c) link/router flapping,
  • (d) requirement of taking down and later bringing back many routers during a software/hardware upgrade,
  • (e) near synchronization of the periodic 1800-second LSA refreshes of a subset of LSAs,
  • (f) refresh of all LSAs in the system during a change in software version,
  • (g) injecting a large number of external routes to OSPF due to a procedural error,
  • (h) Router ID changes causing a large number of LSA re-originations (possibly LSA purges as well depending on the implementation).

ngl the first few are the usual suspects 🙈 but there can be other indirect LSAs too, not just the ones from the original link or router failure. one MPLS example is traffic engineering LSAs [Ref3] that get originated at other links because the reserved bandwidth changed a lot. that happens because the Label Switched Paths (LSPs) that were on the broken link or router get rerouted 🦋

here's the drama 😭 the LSA storm eats up CPU and memory on the router processor, so incoming packets get delayed or dropped. delayed acknowledgments (beyond the retransmission timer value) lead to retransmissions, and delayed Hello packets (beyond the Router-Dead interval) get links declared down. a trunk-down event makes its end-point routers originate router LSAs. if traffic engineering LSAs are used for each link, the end-point routers would originate those too, and maybe other routers as well, because the failure and reroute of LSPs that were using the failed trunk changed reserved bandwidths at other links. then when the link comes back, that triggers even more router LSAs and traffic engineering LSAs. it's a whole cycle 🌀

and the cycle is the scary part 🫣 the retransmissions and extra LSA originations use even more CPU and memory, which is basically a positive feedback loop. we define the LSA storm size as the number of LSAs in the original storm, not counting the extra LSAs from that feedback loop. if the storm is too big, the feedback loop can be strong enough to keep CPU and memory use high at lots of routers indefinitely, and that pushes the whole network into an unstable state 💀 IP and ATM networks running link-state protocols like OSPF, Intermediate System to Intermediate System (IS-IS), Private Network-Network Interface (PNNI), or some proprietary variants have reported outages before. see for example [Ref6-Ref9]. in a lot of those, big floods of LSAs or other similar control messages (whether natural or triggered by a bug or a bad procedure) were partly or fully responsible for the instability and outage.

[Ref13] uses a simulation model to show there's a certain LSA storm size threshold. go above it and the network can act unstable because of lots of retransmissions, links failing due to missed Hello packets, and then links recovering, over and over 🎢 the sim also shows the storm size that causes instability can go way up if you give Hello and LSA Acknowledgment packets prioritized treatment and use an exponential backoff algorithm to decide the LSA retransmission interval. if you can't prioritize Hello packets, resetting the inactivity timer on receiving any valid OSPF packets gives the same benefit. ✨ even better, if you prioritize Hello packets, the network can run a bit above the stability threshold and links still aren't declared down due to missed Hellos. so even with control plane congestion from all the retransmissions, the data plane stays up and no new LSAs get originated (besides the ones in the original storm and the refreshes). these results back up the first three recommendations in Section 2. the authors also ran simulations to check that the other recommendations in Section 2 help avoid congestion and allow a graceful exit from a congested state 🫶

some people say the scalability problem of big networks should just be solved by splitting the network hierarchically into multiple areas, so LSA flooding stays local to each area. ngl that's valid, but it makes network management and design more complicated and can give less optimal routing between areas 🙃 also, Autonomous System External (ASE) LSAs get flooded through the whole AS, which is a problem if there are tons of them. and a lot of summary LSAs might need to be flooded across areas, and that number goes way up if multiple Area Border Routers are used for reliability. so it's important to let the network grow as large as possible under a single area 👑

the recommendations here fit with a wider set of scalability and stability improvement proposals too 🌈 [Ref10] proposes reducing flooding overhead when more than one interface goes to the same neighbor. [Ref11] proposes a mechanism that greatly reduces LSA refreshes in stable topologies. and [Ref12] proposes a wide range of congestion control and failure recovery mechanisms. some of those ideas are covered in this document, but [Ref12] has other ideas that aren't covered here 🍓

Appendix B. List of Variables and Values 🧮

okay here's the cheat sheet 🎀 these are the variables and their values, copied exactly so nothing gets lost:

F    = The factor by which the gap between sending successive LSAs to
       a neighbor is to be increased during congestion and decreased
       after coming out of congestion (used in Recommendation 4).
       Example value is 2.

G(t) = Gap between sending successive LSAs to a neighbor at time t
       (used in Recommendation 4).

Gmax = Maximum allowed value of gap between sending successive LSAs
       to a neighbor (used in Recommendation 4).  Example value is 1
       second.

Gmin = Minimum allowed value of gap between sending successive LSAs
       to a neighbor (used in Recommendation 4).  Example value is 20
       ms.

H    = A high-water mark (in units of number of unacknowledged LSAs).
       Exceeding this mark would trigger a potential increase in the
       gap between sending successive LSAs to a neighbor.  (used in
       Recommendation 4).  Example value is 20.

K    = A multiplicative constant used in increasing the RxmtInterval
       value used during successive retransmissions of the same LSA
       (used in Recommendation 3).  Example value is 2.

L    = A low-water mark (in units of number of unacknowledged LSAs)
       Dropping below this mark would trigger a potential decrease in
       the gap between sending successive LSAs to a neighbor.  (used
       in Recommendation 4).  Example value is 10.

n    = Upper limit on the number of adjacencies to be brought up
       simultaneously (used in Recommendation 5).

R(i) = RxmtInterval value used during the i-th retransmission of an
       LSA (used in Recommendation 3).

Rmax = The maximum allowed value of RxmtInterval (used in
       Recommendation 3).  Example value is 40 seconds.

Rmin = The minimum allowed value of RxmtInterval (used in
       Recommendation 3).  Example value is 5 seconds.

T    = Minimum time that has to elapse before the existing gap
       between sending successive LSAs to a neighbor is considered
       for change (used in Recommendation 4).  Example value is 1
       second.

U(t) = Number of unacknowledged LSAs to a neighbor at time t (used in
       Recommendation 4).

Appendix C. Other Recommendations and Suggestions ✨

Okay, bestie, this is the bonus round 🎀 Three extra tips for OSPF packets and LSAs, and the first one is a whole vibe 💅

(1) Explicit Marking: Back in Section 2, we said OSPF packets should be sorted into "high" and "low" priority classes by checking the OSPF packet header. Honestly, that check can be computationally costly, especially on the receiver side 🙈 So here's a cleaner trick: use different TOS/Precedence field settings for the two classes. [Ref1] sets the TOS field to 0 and the Precedence field to 6 for all OSPF packets. We recommend keeping that same setting for "low" priority OSPF packets, and using a different setting for "high" priority ones. That way you can tell them apart without ever digging into the OSPF header 🦋 Two examples:

Example 1: For "low" priority packets, set TOS field to 0 and
           Precedence field to 6, and for "high" priority packets
           set TOS field to 4 and Precedence field to 6.

Example 2: For "low" priority packets, set TOS field to 0 and
           Precedence field to 6, and for "high" priority packets
           set TOS field to 0 and Precedence field to 7.
Quick heads up: the TOS/Precedence bits were redefined by Diffserv (RFC 2474, [Ref14]), so keep that in mind. Also, these settings only need to be agreed on among the systems on the link 🫶 And if examining the OSPF packet header is already easy for you, you can skip this whole recommendation and separate "high" and "low" priority packets that way instead 💖

(2) Further Prioritization of OSPF Packets: Besides the "high" priority packets from Recommendation 1 of Section 2, there might be a need to split up the "low" priority OSPF packets even more 🌈 We recommend three priority classes: "high", "medium" and "low". When receiving a packet from a neighbor, and when transmitting one to a neighbor, try to process a "high priority" packet before "medium" and "low" ones, and a "medium" priority packet before "low priority" ones. The "high" priority packets are the ones defined in Recommendation 1 of Section 2. Below are two candidate examples for "medium" priority packets. Anything not marked "high" or "medium" is "low" priority ✨

If Cryptographic Authentication (AuType = 2) is in use (as specified in [Ref1]), then prioritized treatment should only happen at the receiver and after security processing. Don't do it at the transmitter, because that may cause packets to arrive out of sequence and violate the requirements of "Autype = 2" 😭

Example of a "medium" priority packet number one: the Database Description (DBD) packet from a slave (during the database synchronization process) that is used as an acknowledgment 🍓

Example number two: an LSA carrying intra-area topology change information. This one may trigger an SPF calculation and the rerouting of Label Switched Paths, so processing it fast may improve OSPF/Label Distribution Protocol (LDP) convergence times 🚀 That said, if identifying and separately queueing the LSA costs too much processing, the implementer may decide to skip it 🫠

(3) Processing a Large Number of LSA Purges: Sometimes, events in the network, like router ID changes, can cause a huge pile of LSA re-originations and LSA purges 💀 In that situation, you could think about processing LSAs in a different order, like handling LSA purges before LSA originations. We, however, do not recommend out-of-order LSA processing, and there are a few reasons. First, figuring out the LSA type before queueing may be computationally expensive. Second, out-of-order processing may cause subtle bugs 🐛 We also don't want to make a major change to the LSA processing paradigm for a relatively rare event like a router ID change. Instead, a router with a changing ID can flush its old LSAs gradually, and that won't cause a storm 🧚

Contributing Authors and Their Addresses 🎀

In addition to the editor, several people helped write this document. Here are the names and contact details of all the authors:

Anurag S. Maunder
Erlang Technology
2880 Scott Boulevard
Santa Clara, CA 95052
USA

Phone: (408) 420-7617
EMail: anuragm@erlangtech.com


Gerald R. Ash
AT&T
Room D5-2A01
200 Laurel Avenue
Middletown, NJ, 07748
USA

Phone: (732) 420-4578
EMail: gash@att.com


Vishwas Manral
Sinett Corp,
2/1 Embassy Icon Annex,
Infantry Road,
Bangalore 560 001
India

Phone: +91-(805)-137-7023
EMail: vishwas@sinett.com


Vera D. Sapozhnikova
AT&T
Room C5-2C29
200 Laurel Avenue
Middletown, NJ, 07748
USA

Phone: (732) 420-2653
EMail: sapozhnikova@att.com

Editor's Address 🦋

Gagan L. Choudhury
AT&T
Room D5-3C21
200 Laurel Avenue
Middletown, NJ, 07748
USA

Phone: (732) 420-3721
EMail: gchoudhury@att.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and 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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information 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