RFC 3724

RFC 3724: The Rise of the Middle and the Future of End-to-End 🎀

okay bestie, let's start with the header facts so you know exactly what we're looking at 💅. This is RFC 3724, and the title is The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture ✨. The authors are J. Kempf, Ed. and R. Austein, Ed., and the IAB is listed in the header too 🧚. The category is Informational, and the date is March 2004 🦋. There are no Obsoletes or Updates entries in the header, so this one doesn't replace or update anything 🌸.

Status of This Memo ✨

This memo provides information for the Internet community 🫶. It does not specify an Internet standard of any kind, so it's not a spec you have to implement 💅. Distribution of this memo is unlimited 🌈.

Copyright Notice 🌸

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 💖

The end-to-end principle is the core architectural guideline of the Internet, and this doc takes a look at how it has been applied over the years 🧚. We talk about where things are heading for the Internet architecture in relation to end-to-end, and we try to draw some conclusions about how the principle itself might evolve given those current trends 🔥.

Table of Contents 📜

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  A Brief History of the End-to-End Principle. . . . . . . . . .  2
   3.  Trends Opposed to the End-to-End Principle . . . . . . . . . .  5
   4.  Whither the End-to-End Principle?. . . . . . . . . . . . . . .  8
   5.  Internet Standards as an Arena for Conflict. . . . . . . . . . 10
   6.  Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

1. Introduction 🌈

okay so one of the big architectural guidelines of the Internet is the end-to-end principle, as laid out in the papers by Saltzer, Reed, and Clark [1][2] 💅. It was originally framed as a question of where it's best not to put functions in a communication system 🙈. But over the years it grew to cover things like keeping the Internet open, making it more reliable and robust, and protecting user choice and the ability to build new services easily 💖. Blumenthal and Clark discuss this in [3], and none of those concerns were part of the original version of the principle ✨.

in this doc we look at how the interpretation of end-to-end has changed over time and where it stands now 🦋. We check out the trends that have pushed for services to be defined inside the network, which the IAB already gave some attention to in RFC 3238 [5] 🧚. Then we share some thoughts on how end-to-end might evolve because of those trends 🔥.

2. A Brief History of the End-to-End Principle 🍓

2.1. In the Beginning... 🌸

The original idea was about where to best put functions in a communication system, and it went like this 💅:

The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) [1].

a specific example of this is delivery guarantees [1] 👑. The original ARPANET sent back a message "Request for Next Message" every time it delivered a packet 🫶. That was actually useful inside the network as a form of congestion control, because the ARPANET wouldn't accept another message for the same destination until the previous acknowledgment came back 🌈. But it was never really useful as proof of guaranteed delivery 💀. The sending host's stack usually doesn't just want to know the network delivered a packet 🙈. It wants to know that the receiving host's stack actually processed the packet properly 🔥. In modern IP stack terms, a reliable transport layer needs a signal that transport processing finished successfully, like TCP's ACK message [4], and not just a signal from the IP layer that the packet arrived ✨. An application protocol might also need an application-specific acknowledgment with a status code that says what happened to the request 🦋.

the examples in [1] and other sources from that time [2] are mostly about sending data packets: data integrity, delivery guarantees, duplicate message suppression, per-packet encryption, and transaction management 💖. Looking at today's Internet architecture, most of those would be transport layer functions (data integrity, delivery guarantees, duplicate message suppression, and maybe transaction management) 🧚. Others, like packet encryption, would be network layer functions with help from other layers where needed 🌸. None of them are really application layer functions 💅.

2.2. ...In the Middle... 🦋

as the Internet grew, the end-to-end principle slowly expanded to cover where to put the state tied to applications: in the network or at the end nodes 🌈. The clearest description of this is in RFC 1958 [6] 💖:

This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes.

so the original idea was that the endpoint's knowledge and help is essential, and that you can't properly build a function in the network without it 🔥. That took a while to sink into the engineering community, and by this point it had become a big statement about what belongs in the network and what doesn't ✨. RFC 1958 uses "application" to mean the whole network stack on the end node, including the network, transport, and application layers 🙈. That's different from the earlier version, which was about the communication system itself 👑. "Fate-sharing" makes this really clear 🫶. The fate of a conversation between two applications is only shared between those two applications 💅. It doesn't depend on anything in the network, except on the network's ability to get packets from one application to the other 🌈.

the RFC 1958 version of end-to-end is specifically about what kind of state gets kept where 🧚:

To perform its services, the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like. This state must be self-healing; adaptive procedures or protocols must exist to derive and maintain that state, and change it when the topology or activity of the network changes. The volume of this state must be minimized, and the loss of the state must not result in more than a temporary denial of service given that connectivity exists. Manually configured state must be kept to an absolute minimum.[6]

so in this version, the state needed to get packets from one end of the network to the other lives in the network 🦋. This is "soft state," meaning it can be dropped quickly and rebuilt (or even required to be renewed regularly) whenever the topology changes because routers and switches go on or offline 🍓. "Hard state," the state the application's proper functioning depends on, is only kept in the end nodes 💖. This is a big shift from the original version, where end node participation was required for pretty much any function to work properly 😭.

all in all, awareness of the principle itself, and of what it means for how unavoidable state gets handled, grew over time until it became (if not the) foundation principle of the Internet architecture 👑✨.

2.3. ...And Now. ✨

Okay so this one is such a good example of how the end-to-end principle is still shaping the convo in the Internet community 💅 It's IP mobility, bestie 📱 The current Internet routing setup really limits how close IP mobility can get to the end-to-end principle without making some seriously fundamental changes 😭

Mobile IPv6, which is described in the Mobile IPv6 specification by Johnson, Perkins, and Arkko [7], needs a routing proxy in the mobile node's home network (the Home Agent) 🏠 That proxy keeps track of the mapping between the mobile node's routing locator, which is the care of address, and the mobile node's node identifier, which is the home address 🗺️ Now, the local subnet routing proxy (the Foreign Agent) was a feature of the older Mobile IPv4 design [8], and it compromised end-to-end routing 💀 Mobile IPv6 got rid of it, so the end node now handles its own care of address. Iconic glow-up 🦋

Mobile IPv6 also has secure mechanisms for optimizing routing, so the mobile end node and the correspondent node can do end-to-end routing directly 🫶 That means no need to route through the global routing proxy at the home agent. These features are all based on end to end considerations 💖

BUT, ngl, the need for the global routing proxy in the Home Agent is still there in Mobile IPv6 🥲 That's because the global node identifier is aliased with the routing identifier in the Internet routing architecture. An IAB workshop talked about this topic and reported it in RFC 2956 [9], and it hasn't changed in IPv6 🌸

Despite this constraint, the vision coming out of the IETF working groups that develop standards for mobile networking is a largely autonomous mobile node with multiple wireless link options 📶 The mobile node picks and chooses among them, which is giving independent main character energy ✨ The end node is therefore responsible for maintaining the integrity of the communication, just like the end-to-end principle says 🔥 This kind of innovative application of the end-to-end principle comes from the same basic considerations of reliability and robustness that motivated the original end-to-end principle 🌈 Think wireless link integrity, changes in connectivity and service availability as you move around, etc. 🚶‍♀️

Here's the tea: wired links, routing, and switching equipment have gotten way more reliable since the end-to-end principle was formalized 15 years ago 📈 But wireless links? Their reliability (or unreliability 🙈) is governed much more strongly by the basic physics of the medium and the instantaneous radio propagation conditions. Physics is not it, bestie 😭⚡

---

3. Trends Opposed to the End-to-End Principle 🚧

Okay so the end-to-end principle still gives us a solid foundation for a lot of IETF design work 💜 But the specific application of it described in RFC 1958 has been getting questioned from all kinds of directions 👀 The IAB has been worried about trends opposing the end-to-end principle for a while now, see RFC 2956 [9] and RFC 2775 [12] 📚 The main concern in those docs is the loss of transparency from NATs and other address translation mechanisms, plus the effects on the end-to-end principle of different scenarios where IPv6 is fully, partially, or not deployed 🌍 More recently the worry has shifted to what happens when services get deployed inside the network 🛠️ The IAB opinion on Open Pluggable Edge Services (OPES) in RFC 3238 [5] is about assessing whether it's architecturally desirable to define services in the network, and it raises questions about how those services could compromise privacy, security, and end-to-end data integrity 😬 Clark, et al. in [10] and Carpenter in RFC 3234 [11] also dig into service definition in the network 🤓

Perhaps the best review of the forces working against the end-to-end principle is by Blumenthal and Clark in [3] 📖 Their big point is that the Internet first developed among a community of like-minded technical professionals who trusted each other, and it was run by academic and government institutions that enforced a policy of no commercial use 🎓 The major stakeholders today are totally different 🤯 So, new requirements have evolved over the last decade 🌱 We'll go through examples of those in the following subsections 💅 You can also check out other discussions about pressures on the end-to-end principle in today's Internet, like Reed's discussion [13] and Moors' paper at the 2002 IEEE International Communications Conference [14] 🎀

3.1. Need for Authentication 🔐

Perhaps the single most important change from the Internet of 15 years ago is the lack of trust between users 💔 Back then the end users were few, and they mostly used the Internet as a tool for academic research and sharing research results (explicit commercial use was forbidden when the US government ran it 🏛️). So trust between end users, and therefore authentication of the end nodes they use, plus trust between network operators and their users, just wasn't really an issue in general 🌷 Today, the motivations of some people using the Internet aren't always entirely ethical 😒 And even when they are, the assumption that end nodes will always cooperate to reach some mutually beneficial action, which is what the end-to-end principle implies, isn't always accurate 🙃 On top of that, the growing number of users who aren't technologically sophisticated enough, or who just aren't interested in maintaining their own security, has forced network operators to get way more proactive about stopping naive or uninterested users from accidentally or on purpose causing security problems 🚨

While the end-to-end principle doesn't require users to implicitly trust each other, the lack of trust on the Internet today means application and system designers have to make a choice about how to handle authentication 🧐 That choice was rarely visible 15 years ago. One of the most common examples of network elements sitting between end hosts is the security stuff: firewalls, VPN tunnel endpoints, certificate servers, etc. 🛡️ These intermediaries are built either to protect the network from unchecked attacks, or to let two end nodes whose users have no inherent reason to trust each other reach some level of authentication 🤝

BUT, these measures act as impediments to end-to-end communications 🚧 Third party trust intermediaries aren't a requirement for security, since end-to-end security mechanisms like S/MIME [15] can be used instead 🔒 And where third party measures like PKI infrastructure or keys in DNS are used to exchange keying material, they don't necessarily get in the way of end-to-end traffic once authentication has been achieved ✅ Even when third parties are involved, it's ultimately up to the endpoints and their users to decide which third parties they trust 👑

3.2. New Service Models 🎬

New service models inspired by new applications require reaching the proper performance level as a fundamental part of the service you actually get 📶 These service models are a big change from the original best effort service model 🔄 Email, file transfer, and even Web access don't get labeled as failing if performance degrades, though the user may get pretty frustrated by how long the transaction takes 😤 But for streaming audio and video, not to mention real time bidirectional voice and video, reaching the proper performance level is part of delivering the service itself 🎥 Whatever that means for an acceptable user experience, a customer who signs up for the service has a right to expect the performance level they paid for 💸 For example, content distributors sometimes release content through content distribution servers spread around the Internet at various locations, to avoid delays when the server is topologically far away from the client 🌍 Retail broadband and multimedia services are a brand new service model for lots of service providers 🚀

3.3. Rise of the Third Party 🕴️

Academic and government institutions ran the Internet of 15 years ago 🏫 They didn't expect to make a profit from investing in networking technology 🙅‍♀️ In contrast, the network operator most Internet users deal with today is the commercial ISP 💼 Commercial ISPs run their networks as a business, and their investors rightly expect that business to turn a profit 💰 This change in business model has put some pressure on ISPs to boost their prospects by deploying new services 📈

Especially the standard retail dialup bit pipe account with email and shell access 📞 That's become a commodity service, so profit margins are low 😩 Plenty of ISPs are happy with this model and can survive on it, but others want to deploy different service models with higher profit potential and more or different services for the customer 🤑 An example is retail broadband bit pipe access over cable or DSL, paired with streaming multimedia 📺 Some ISPs that offer broadband also deploy content distribution networks to boost streaming media performance 🚀 These services are typically deployed so they're only accessible inside the ISP's network, so they don't contribute to open, end-to-end service 🚫 From an ISP's point of view though, offering that service is an incentive for customers to buy the ISP's service 🛍️

ISPs aren't the only third party intermediary that has shown up in the last 10 years 👀 Unlike the earlier involvement of corporations and governments in running the Internet, corporate network administrators and government officials have been getting more and more demanding about opportunities to interpose between two parties in an end-to-end conversation 🙋‍♀️ A benign reason for this is to mitigate the lack of trust, so the third party acts as a trust anchor or enforcer of good behavior between the two ends 🤍 A less benign reason is for third parties to insert policy for their own reasons, maybe taxation or even censorship 😶 The requirements of third parties often have little or nothing to do with technical concerns, and instead come from particular social and legal considerations 🏛️

---

4. Whither the End-to-End Principle? 🌅

Given the pressures on the end-to-end principle we just talked about in the previous section, a question comes up about its future 🔮 Does the end-to-end principle even have a future in the Internet architecture or not? And if it does, how should it be applied? 🤔 Clearly, an unproductive approach to answering this is to insist on the end-to-end principle as a fundamentalist principle that allows no compromise 🙅‍♀️ The pressures described above are real and powerful 💪 If the current Internet technical community decides to ignore them, the likely result is a market opportunity for a new technical community that doesn't ignore these pressures, but that may not understand the implications of its design choices 😬 A more productive approach is to go back to first principles and re-examine what the end-to-end principle is trying to accomplish, and then update our definition and explanation of it for the complexities of today's Internet 🧠✨

4.1. Consequences of the End-to-End Principle 🎀

okay so in this section we're looking at the two biggest consequences of the end-to-end principle: protection of innovation, and reliability and robustness 💅

4.1.1. Protection of Innovation ✨

one of the best things about the end-to-end principle is that it protects innovation 🦋 needing changes inside the network before you can deploy a new service is still typically harder than just modifying end nodes. the counterargument is that lots of end nodes are basically closed boxes that can't be updated, and that most users don't want to update them anyway. but that doesn't apply to all nodes and all users 🙈 plenty of end nodes are still user configurable, and a sizable percentage of users are "early adopters," who are willing to put up with a certain amount of technological grief to try out a new idea 💖 and even for the closed boxes and the uninvolved users, downloadable code that abides by the end-to-end principle can provide fast service innovation 🚀 honestly, having to convince a bunch of ISPs or corporate network administrators to modify their networks is so much harder than just putting up a Web page with some downloadable software that implements the service. main character energy for the people with the ideas 👑

4.1.2. Reliability and Trust 🔥

okay but here's the part that's giving me anxiety 😭 the decrease in reliability and robustness caused by deliberate, active attacks on the network infrastructure and end nodes is a growing concern. the original developers of the Internet were worried about large-scale system failures, but attacks with the subtlety and variety the Internet sees today weren't a problem back when it was being developed 💀 by and large, the end-to-end principle wasn't written to address the loss of reliability from attacks deliberately engineered to take advantage of subtle flaws in software. these attacks are part of the bigger trust breakdown we talked about in Section 3.1. so the trust breakdown can be considered another forcing function on the Internet architecture 🌈

the immediate reaction to this trust breakdown has been to try to back fit security into existing protocols. bestie, that effort is necessary, but it is not sufficient 🫶 trust needs to become as firm an architectural principle in protocol design for the future as the end-to-end principle is today. trust isn't just a matter of adding some cryptographic protection to a protocol after it's designed. instead, before designing the protocol, the trust relationships between the network elements involved in the protocol must be defined, and boundaries must be drawn between the network elements that share a trust relationship. the trust boundaries should be used to determine what type of communication occurs between the network elements involved in the protocol, and which network elements signal each other. when communication occurs across a trust boundary, cryptographic or other security protection of some sort may be necessary. additional measures may be necessary to secure the protocol when communicating network elements do not share a trust relationship. for example, a protocol might need to minimize state in the recipient before establishing the validity of the credentials from the sender, in order to avoid a memory depletion DoS attack 😭🔥

4.2. The End-to-End Principle in Applications Design 🧚

the end-to-end principle is just as relevant to applications design 💜 two key points when you're designing application protocols are making sure they don't have any dependencies that would break the end-to-end principle, and making sure they can identify end points in a consistent fashion. an example of the first one is layer violations, which means creating dependencies that would make it impossible for the transport layer, for example, to do its work appropriately 🙅‍♀️ another issue is the desire to insert more applications infrastructure into the network. the architectural considerations around this are discussed in RFC 3238 [5]. this desire doesn't have to violate the end-to-end principle, as long as the partitioning of functioning is done so that services provided in the network operate with the explicit knowledge and involvement of endpoints, whenever that knowledge and involvement is necessary for the service to work properly 🎀 the result becomes a distributed application, where the end-to-end principle applies to each connection involved in implementing the application ✨

5. Internet Standards as an Arena for Conflict 🥊

Internet standards have increasingly become an arena for conflict [10]. ISPs have certain concerns, businesses and government have others, and vendors of networking hardware and software have still others 💅 these concerns often conflict, and sometimes they conflict with the concerns of the end users. for example, ISPs are reluctant to deploy interdomain QoS services because, among other reasons, every known instance creates a significant and easily exploited DoS/DDoS vulnerability 🙃 however, some end users would like end-to-end, Diffserv or Intserv-style QoS available to improve support for voice and video multimedia applications between end nodes in different domains, as discussed by Huston in RFC 2990 [16]. in this case, the security, robustness, and reliability concerns of the ISP conflict with the users' desire for a different type of service 😤

these conflicts will inevitably be reflected in the Internet architecture going forward 🔮 some of them are impossible to resolve on a technical level, and wouldn't even be desirable, because they involve social and legal choices that the IETF is not empowered to make (for a counter argument in the area of privacy, see Goldberg, et al. [17]). but for the conflicts that do involve technical choices, the important properties of user choice and empowerment, reliability and integrity of end-to-end service, supporting trust and "good network citizen behavior," and fostering innovation in services should be the basis on which resolution is made. the conflict will then play out on the field of the resulting architecture 🏟️✨

6. Conclusions 👑

the end-to-end principle keeps guiding technical development of Internet standards, and it's still as important for the Internet architecture today as it was in the past 🌸 in many cases, unbundling the end-to-end principle into its consequences leads to a distributed approach, where the end-to-end principle applies to interactions between the individual pieces of the application, while the unbundled consequences (protection of innovation, reliability, and robustness) apply to the entire application 🧩 the end-to-end principle started out as a focused argument about needing the knowledge and assistance of end nodes to properly implement functions in a communication system. but the second order properties the Internet developed as a result of the end-to-end principle have come to be recognized as being just as important as the principle itself, if not more so 😭💖

end user choice and empowerment, integrity of service, support for trust, and "good network citizen behavior" are all properties that developed as a consequence of the end-to-end principle 🫶 recognizing these properties in a particular proposal for modifications to the Internet has become more important than before, because the pressures to incorporate services into the network have increased 📈 any proposal to incorporate services in the network should be weighed against these properties before it proceeds 🚦

7. Acknowledgements 🌷

many of the ideas presented here originally appeared in the works of Dave Clark, John Wroclawski, Bob Braden, Karen Sollins, Marjory Blumenthal, and Dave Reed on the forces currently influencing the evolution of the Internet 🙌 the authors would particularly like to single out the work of Dave Clark, who was the original articulator of the end-to-end principle and who continues to inspire and guide the evolution of the Internet architecture 👏 they also want to thank John Wroclawski, with whom conversations during the development of this paper helped clarify issues involving tussle and the Internet 🦋

8. Security Considerations 🔐

this document doesn't propose any new protocols, so it doesn't involve any security considerations in that sense 🙂 however, throughout this document there are discussions of the privacy and integrity issues, and the architectural requirements created by those issues. take those seriously, because they're the whole game now 🚨😭

9. Informative References 📚

[1] Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.

[2] Clark, D., "The Design Philosophy of the DARPA Internet Protocols," Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114.

[3] Blumenthal, M., Clark, D.D., "Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world", ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109.

[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

[6] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.

[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Work in Progress.

[8] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.

[9] Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC 2956, October 2000.

[10] Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of Sigcomm 2002.

[11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February, 2002.

[12] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

[13] Reed, D., "The End of the End-to-End Argument?", http://www.reed.com/dprframeweb/dprframe.asp?section=paper&fn=endofendtoend.html, April 2000.

[14] Moors, T., "A Critical Review of End-to-end Arguments in System Design," Proc. 2000 IEEE International Conference on Communications, pp. 1214-1219, April, 2002.

[15] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.

[17] Goldberg, I., Wagner, D., and Brewer, E., "Privacy-enhancing technologies for the Internet," Proceedings of IEEE COMPCON 97, pp. 103-109, 1997.

10. Author Information 🧑‍💻

Internet Architecture Board EMail: iab@iab.org

IAB Membership at time this document was completed:

• Bernard Aboba
• Harald Alvestrand
• Rob Austein
• Leslie Daigle
• Patrik Faltstrom
• Sally Floyd
• Jun-ichiro Itojun Hagino
• Mark Handley
• Geoff Huston
• Charlie Kaufman
• James Kempf
• Eric Rescorla
• Mike St. Johns

11. Full Copyright Statement ✨

Okay so, the legal bit, but make it cute 🎀. Copyright (C) The Internet Society (2004). 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; nor does it 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. 🫶

---

That's the whole doc, bestie! 🧚 Thanks for hanging out with RFC 3724 today. 💜