RFC 4924

Reflections on Internet Transparency

📅 published July 2007, from ietf

RFC 4924: Reflections on Internet Transparency 🦋

Okay bestie, so this is RFC 4924, called Reflections on Internet Transparency ✨ It was published in July 2007 🌸 and it's an Informational doc, so it's giving "here's some info" rather than "here's a rule you have to follow" 🙈 It came from the Internet Architecture Board (IAB), and it was put out under the Network Working Group with B. Aboba, Ed. and E. Davies as the authors 💖 The title block doesn't list anything it obsoletes or updates, so it's a solo main character 💅

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 IETF Trust (2007).

Abstract 🌈

Okay so the abstract is basically the tea ☕ It reviews what the IAB has said before about Internet transparency, and then it talks about new transparency issues too. The vibe is that transparency has NOT become less important. Technical stuff that intentionally or accidentally blocks network transparency is still super central to the Internet's ability to support innovation and global communication 🔥 The doc gives some specific examples of those impacts, so you can see it for yourself.

Table of Contents 🗂️

1. Introduction ....................................................2
2. Additional Transparency Issues ..................................4
   2.1. Application Restriction ....................................4
   2.2. Quality of Service (QoS) ...................................6
   2.3. Application Layer Gateways (ALGs) ..........................7
   2.4. IPv6 Address Restrictions ..................................8
        2.4.1. Allocation of IPv6 Addresses by Providers ...........8
        2.4.2. IKEv2 ...............................................8
   2.5. DNS Issues .................................................9
        2.5.1. Unique Root .........................................9
        2.5.2. Namespace Mangling ..................................9
   2.6. Load Balancing and Redirection ............................10
3. Security Considerations ........................................11
4. References .....................................................11
   4.1. Informative References ....................................11
Acknowledgments ...................................................13
Appendix A - IAB Members at the Time of Approval ..................14

1. Introduction ✨

Okay so the IAB has put out a bunch of docs over the years about Internet transparency and the end-to-end principle 📚 Other IETF docs have touched on this stuff too 🫶 All of these explain the big-picture principles the Internet architecture is built on, plus the core values the community wants to protect moving forward. This doc reaffirms those principles 💖 It also describes the idea of "oblivious transport" as developed in the DARPA NewArch project [NewArch], and it covers a bunch of new transparency issues 👑

Okay here's the core idea. A network that doesn't filter or transform the data it carries can be called "transparent" or "oblivious" to the content of packets 🦋 Networks that give you oblivious transport let people deploy new services without having to change the core 🧚 That flexibility is honestly the Internet's most essential characteristic, and it's one of the biggest reasons it's been so successful. Iconic, no notes 💅

"Architectural Principles of the Internet" [RFC1958], Section 2 describes the core tenets of the Internet architecture. It says:

   However, in very general terms, the community believes that the
   goal is connectivity, the tool is the Internet Protocol, and the
   intelligence is end to end rather than hidden in the network.

   The current exponential growth of the network seems to show that
   connectivity is its own reward, and is more valuable than any
   individual application such as mail or the World-Wide Web.  This
   connectivity requires technical cooperation between service
   providers, and flourishes in the increasingly liberal and
   competitive commercial telecommunications environment.

"The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture" [RFC3724], Section 4.1.1 describes some of the good stuff that comes from this approach. It says:

   One desirable consequence of the end-to-end principle is
   protection of innovation.  Requiring modification in the network
   in order to deploy new services is still typically more difficult
   than modifying end nodes.  The counterargument - that many end
   nodes are now essentially closed boxes which are not updatable and
   that most users don't want to update them anyway - does not apply
   to all nodes and all users.  Many 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 in order to try out a new idea.  And, even for
   the closed boxes and uninvolved users, downloadable code that
   abides by the end-to-end principle can provide fast service
   innovation.  Requiring someone with a new idea for a service to
   convince a bunch of ISPs or corporate network administrators to
   modify their networks is much more difficult than simply putting
   up a Web page with some downloadable software implementing the
   service.

Yet, even though the Internet has grown a LOT in size and in the variety of applications, the amount of transparency has gone down 😭 "Internet Transparency" [RFC2775] explains some of the reasons transparency was lost and looks at how that hurt things. It covers Network Address Translators (NATs), firewalls, application level gateways (ALGs), relays, proxies, caches, split Domain Name Service (DNS), load balancers, etc. 🙈 [RFC2775] also looks at possible future directions that could bring transparency back 🔮 Section 6 sums up the conclusions:

   Although the pure IPv6 scenario is the cleanest and simplest, it
   is not straightforward to reach it.  The various scenarios without
   use of IPv6 are all messy and ultimately seem to lead to dead ends
   of one kind or another.  Partial deployment of IPv6, which is a
   required step on the road to full deployment, is also messy but
   avoids the dead ends.

Full restoration of Internet transparency through IPv6 deployment is still the goal 🎀 But the Internet's growing role in society, the increasing variety of applications, and the continued growth in security threats have shifted the balance between transparency and security 🌸 Since everyone involved wants different things, these tradeoffs are inherently complicated 🧩

Here's the tricky part. Transparency gives you a ton of flexibility, but it also makes it easier to deliver unwanted traffic as well as the wanted kind 😬 Unwanted traffic is more and more often cited as a reason to limit transparency 🚫 If you follow that argument all the way, you end up building ever more complex transparency barriers to fight increasingly sophisticated security threats 💀 Transparency is hard to get back once it's lost, so if that approach doesn't work, you end up with an Internet that's both insecure AND lacking in transparency. Not it 🙅‍♀️ The alternative is to build more and more sophisticated host-based security mechanisms. That approach might also fail to keep up with increasingly sophisticated threats, but it's less likely to sacrifice transparency along the way 🧚

Lots of the same forces that cut transparency on the IPv4 Internet might also show up on the IPv6 Internet 👀 So the transparency of the IPv6 Internet isn't guaranteed. It's an ideal, and keeping it going will take serious, ongoing effort 💪

As [NewArch] points out, the technical cooperation that once defined Internet development has increasingly turned into a tussle between subscribers, vendors, providers, and society at large 🥊 Developers who want to deploy new services may want oblivious transport 🚀 Providers may want to block unwanted traffic in the core before it hits subscribers 🛡️ Vendors and providers may want to offer "value added" services inside the network so they can stand out from each other 💼 Subscribers might agree with either side depending on their own interests 🤷‍♀️ And society at large may want to block "offensive" material and monitor traffic that shows malicious intent 👀

There's no architectural "fix" that restores oblivious transport while making everyone happy, sadly 😔 But providers CAN give subscribers information about the nature of the services being provided ✨ Subscribers need to know whether they're getting oblivious transport, and if they're not, how the service is affecting their traffic 🫶

Since the earlier IAB statements came out, new technologies have been developed and views on existing technology have changed 🔄 In some cases, these new technologies affect oblivious transport, so subscribers need to understand what that means for their service 💅

2. Additional Transparency Issues 🧚

Okay bestie, that's the intro. Section 2 is where the doc gets into the specific new transparency issues, and it keeps going from there in the next part 💜

2.1. Application Restriction 💅

Okay so, one of the best things about the Internet is how easy it is to deploy new applications 🦋. That means anything making deployment harder can seriously slow down innovation 💀, and that's a big deal, bestie.

One of those practices is filtering designed to block or restrict application usage, done without customer consent 🙈. That covers Internet, Transport, and Application layer filtering aimed at blocking or restricting traffic for one or more applications.

Provider filtering can be useful for security stuff like attacks on provider infrastructure or denial of service attacks ✨. But it's way more flexible to let the customer decide what gets filtered 🫶. Usually this happens at the edges: inside provider access routers (like outsourced firewall services), on customer premise equipment (like access firewalls), or on hosts (like host firewalls) 🌸. Filtering at the edges means customers get to pick which apps they block or restrict. Filtering in the core, though, might stop hosts from talking even when the conversation would follow the appropriate use policies of the administrative domains those hosts belong to 😭.

Here's the tea 🍓: filtering meant to block or restrict application usage is really hard to pull off without customer consent. Over time, developers will tend to re-engineer filtered protocols so they can dodge the filters. So filtering is likely to cause interoperability issues or unnecessary complexity over time 🌀. And those costs come with no real benefit, because lots of application protocols started using HTTP as a transport protocol after developers noticed that firewalls let HTTP traffic through while dropping packets for unknown protocols 👀.

On top of the architecture concerns, filtering to block or restrict application usage also brings up disclosure and end-user consent issues 💖. As pointed out in "Terminology for Describing Internet Connectivity" [RFC4084], services advertised as providing "Internet connectivity" can be wildly different in what they actually do, which causes confusion 😵‍💫. That document defines terms for Internet connectivity, including "Web connectivity", "Client connectivity only, without a public address", "Client only, public address", "Firewalled Internet Connectivity", and "Full Internet Connectivity".

For "Full Internet Connectivity" [RFC4084], Section 2 notes:

   Filtering Web proxies, interception proxies, NAT, and other
   provider-imposed restrictions on inbound or outbound ports and
   traffic are incompatible with this type of service.  Servers ...
   are typically considered normal.  The only compatible restrictions
   are bandwidth limitations and prohibitions against network abuse
   or illegal activities.

And [RFC4084], Section 4 describes disclosure obligations that apply to all forms of service limitation, whether applied on outbound or inbound traffic:

   More generally, the provider should identify any actions of the
   service to block, restrict, or alter the destination of, the
   outbound use (i.e., the use of services not supplied by the
   provider or on the provider's network) of applications services.

In essence, [RFC4084] calls for providers to declare the ways their service departs from oblivious transport 🕊️. Since losing oblivious transport inside transit networks also hurts transparency, this applies to providers over whose network the subscriber's traffic may travel too 🧚.

2.2. Quality of Service (QoS) 🎀

While [RFC4084] notes that bandwidth limitations are compatible with "Full Internet Connectivity", QoS restrictions can sometimes go beyond simple average or peak bandwidth limits 👀. When QoS is used to restrict the ability to deploy new applications, it's incompatible with "Full Internet Connectivity" as defined in [RFC4084] 🚫. The disclosure and consent obligations referred to in [RFC4084], Section 4 also apply to QoS mechanisms.

QoS does have a big impact on transparency 🌈, since the QoS a flow gets can make the Internet more or less oblivious to that flow. QoS support is super desirable so real-time services can coexist with elastic services, but it's not free. It does affect packet delivery ✨.

Specifically, QoS classes like "default" [RFC2474] or "lower effort" [RFC3662] may see higher random-loss rates than others like "assured forwarding" [RFC2597] 📉. On the flip side, bandwidth-limited QoS classes like "expedited forwarding" [RFC3246] may see systematic packet loss if they go over their assigned bandwidth 😤. And other QoS mechanisms, like load balancing, can cause side effects like packet re-ordering, which can seriously hurt perceived performance 💀.

QoS setups that reduce the ability to deploy new applications on the Internet are basically the same as other transparency barriers 🦋. Arbitrary or severe bandwidth limits can make an app totally unusable, so application-specific bandwidth limits are equivalent to application blocking or restriction from a user's standpoint 💅.

Using QoS to discriminate against traffic that doesn't match a set of services or addresses has a similar effect to deploying a highly restrictive firewall 🙅‍♀️. Requiring an authenticated RSVP reservation [RFC2747][RFC3182] for a flow to avoid severe packet loss is like deploying authenticated firewall traversal 🔐.

Now, to be fair, there can be valid uses for customer-imposed QoS restrictions 🫶. For example, a customer might want to limit the bandwidth eaten up by peer-to-peer file sharing services, so mission-critical applications aren't impacted 🎯.

2.3. Application Layer Gateways (ALGs) 🧚

The IAB has put a lot of thought into Network Address Translation (NAT) already, so there's no need to repeat all of that here 🙌. But over time it's become clear that there are problems baked into deploying Application Layer Gateways (ALGs), which are often embedded in firewalls and in devices that implement NAT 🔍.

[RFC2775], Section 3.5 says:

   If the full range of Internet applications is to be used, NATs
   have to be coupled with application level gateways (ALGs) or
   proxies.  Furthermore, the ALG or proxy must be updated whenever a
   new address-dependent application comes along.  In practice, NAT
   functionality is built into many firewall products, and all useful
   NATs have associated ALGs, so it is difficult to disentangle their
   various impacts.

With time, and with NAT traversal technologies like IKE NAT-T [RFC3947], Teredo [RFC4380], and STUN [RFC3489] showing up, it's become clear that ALGs are an extra barrier to transparency 🚧. Besides blocking deployment of new applications that ALGs don't support yet, ALGs can also cause trouble for existing applications and their updated versions 😩. For example, while developing IKE NAT-T, extra difficulties came from "IPsec Helper" ALGs embedded within NATs 🙈.

It should be stressed that these difficulties are built into the architecture of ALGs, not just a side effect of bad implementations 📢. No matter how well an ALG is implemented, transparency barriers will pop up over time, so the idea of a "transparent ALG" is a contradiction in terms 💀.

DNS ALGs are especially messy 🌀, with incompatibilities with DNSSEC that prevent deploying a secure naming infrastructure even when all the endpoints are upgraded. For details, see "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status" [RFC4966], Section 3 📚.

2.4. IPv6 Address Restrictions 🌸

[RFC2775], Section 5.1 says:

   Note that it is a basic assumption of IPv6 that no artificial
   constraints will be placed on the supply of addresses, given that
   there are so many of them.  Current practices by which some ISPs
   strongly limit the number of IPv4 addresses per client will have
   no reason to exist for IPv6.

Constraining the supply of IPv6 addresses gives people an incentive to deploy NAT with IPv6 😬. Bringing NAT to IPv6 would be a barrier to transparency, so it's something to avoid if at all possible 🚫.

2.4.1. Allocation of IPv6 Addresses by Providers 💖

To encourage IPv6 deployments that provide oblivious transport, it's important that IPv6 networks of all sizes get a prefix big enough to allocate addresses and sub-networks for all the hosts and links inside their network 🌐. Early address allocation policy suggested giving a /48 prefix to "small" sites, which should handle typical needs ✨. Any change to allocation policy should account for the transparency loss that further restriction would cause 👀. For example, if a provider only provisions a single /64 without support for prefix delegation, or (even worse) a longer prefix (which [RFC4291], Section 2.5.4 prohibits for non-000/3 unicast prefixes), that would restrict IPv6 address availability and could become a barrier to transparency 😤.

2.4.2. IKEv2 🔐

Issues with IPv6 address assignment mechanisms in IKEv2 [RFC4306] are described in [RFC4718]:

   IKEv2 also defines configuration payloads for IPv6.  However, they
   are based on the corresponding IPv4 payloads, and do not fully
   follow the "normal IPv6 way of doing things"...  In particular,
   IPv6 stateless autoconfiguration or router advertisement messages
   are not used; neither is neighbor discovery.

IKEv2 handles assigning a single IPv6 address using the INTERNAL_IP6_ADDRESS attribute 📍. If that's the only attribute supported for IPv6 address assignment, then only one IPv6 address is available 😭. The INTERNAL_IP6_SUBNET attribute lets the host figure out which sub-networks it can reach directly through the secure tunnel it created 🚇. It could potentially be used to assign one or more prefixes to the IKEv2 initiator that could then be used for address creation 🧩.

But that doesn't let the host get prefixes that can be delegated 🙅‍♀️. The INTERNAL_IP6_DHCP attribute gives the address of a DHCPv6 server, which could enable DHCPv6 prefix delegation [RFC3633] to get additional prefixes 💜. Still, for implementers to use these options in an interoperable way, clarifications to the IKEv2 specification appear to be needed 🥺.

2.5. DNS Issues 🌈

2.5.1. Unique Root

okay so the IAB wrote this whole doc called "IAB Technical Comment on the Unique DNS Root" [RFC2826] 📚, and it's where all the technical reasons for having a unique root got laid out ✨

one of the big premises in [RFC2826] is that two parties need a common namespace with common semantics applied to those names to communicate effectively 🫶 the argument is that this only works when there's one unique root and when each domain is maintained by a single owner or maintainer. very important, bestie 💅

[RFC4084] only targets IP service terms and doesn't talk about namespace issues at all, so it doesn't refer to [RFC2826] 🙈 but we're stressing it here anyway: using a unique root for the DNS namespace is essential for proper IP service 👑

2.5.2. Namespace Mangling

so since [RFC2826] came out, there have been reports of providers running recursive nameservers and/or DNS forwarders that swap out answers saying a name doesn't exist in the DNS hierarchy. instead they hand back a name and an address record pointing at a web service that's supposed to be useful for end-users 😭 it's giving unwanted plot twist

this is basically like putting a wildcard in top-level domains 🎀 wildcard labels in TLDs cause problems that are described elsewhere (like in "The Role of Wildcards in the Domain Name System" [RFC4592]), but they don't strictly violate the DNS protocol. that's not the case when the answers get modified in the middle of the path between authoritative servers and the stub resolvers that hand those answers to applications. big difference, periodt 💀

[RFC2826] section 1.3 states:

Both the design and implementations of the DNS protocol are heavily based on the assumption that there is a single owner or maintainer for every domain, and that any set of resources records associated with a domain is modified in a single-copy serializable fashion.

and then there's DNSSEC 🔐 the protocol described in "Protocol Modifications for the DNS Security Extensions" [RFC4035] was designed to verify that DNS information hasn't been modified between the moment it's published on an authoritative server and the moment validation happens. because that verification can happen at the application level, any modification by a recursive forwarder or other intermediary will cause validation failures. which means the improved security DNSSEC is meant to give you just gets disabled 😤 not it ruining the vibe

2.6. Load Balancing and Redirection

okay so to give information that's tailored to where a request comes from, or just to make things faster, people have deployed techniques that redirect packets or send them down a different path depending on where the request started 🦋 for example, requests might get spread across servers using "reverse NAT" (which changes the destination rather than the source address) ✨ DNS responses might get altered, HTTP "gets" might be re-directed, or specific packets might get diverted onto overlay networks 🌀

if these services are well-implemented, they can add real value 💖 but transparency can drop or service can get disrupted too:

[1] using "reverse NAT" to balance load among servers supporting IPv6 would adversely affect the transparency of the IPv6 Internet. not it 😩

[2] DNS re-direction is typically based on the source address of the query, which may not tell you where the host that sent the query actually is 🙃 so a host that's configured with the address of a distant DNS server could end up pointed at a server near that DNS server, rather than a server near the host. HTTP re-direction doesn't have this issue 🍓

[3] if the packet filters that divert packets onto overlay networks are misconfigured, packets can get misdirected onto the overlay and then delayed or lost if the far end can't send them back to the global Internet 🥲

[4] anycast needs to be carefully thought out so that service can be maintained in the face of routing changes 🧚

3. Security Considerations 🔐

okay this part is SERIOUS bestie 😭 several transparency issues in this doc (NATs, transparent proxies, DNS namespace mangling) weaken existing end-to-end security guarantees and get in the way of deploying protocols that would strengthen end-to-end security. literally the opposite of what we want 💀

[RFC2775], Section 7 states:

The loss of transparency at the Intranet/Internet boundary may be considered a security feature, since it provides a well defined point at which to apply restrictions. This form of security is subject to the "crunchy outside, soft inside" risk, whereby any successful penetration of the boundary exposes the entire Intranet to trivial attack. The lack of end-to-end security applied within the Intranet also ignores insider threats.

and honestly, malware has gotten so good at using the application layer as a rich and financially attractive source of security vulnerabilities 🦠 it's also a way to penetrate the Intranet/Internet boundary. this has lessened the security value of existing transparency barriers, and it's getting harder to stop malware from spreading without putting restrictions on application behavior 😤 still, just like with other approaches to application restriction (see Section 2.1), these limitations are most flexibly imposed at the edge 🌸

4. References ✨

4.1. Informative References 📚

  • [NewArch] Clark, D. et al., "New Arch: Future Generation Internet Architecture", http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf
  • [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC2474] 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.
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
  • [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
  • [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
  • [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
  • [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
  • [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
  • [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
  • [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
  • [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
  • [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005.
  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
  • [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
  • [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
  • [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
  • [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.

Acknowledgments 🫶

the authors want to give a huge shoutout to Jari Arkko, Stephane Bortzmeyer, Brian Carpenter, Spencer Dawkins, Stephen Kent, Carl Malamud, Danny McPherson, Phil Roberts and Pekka Savola for their contributions to this document 💜 literal legends

Appendix A - IAB Members at the Time of Approval 👑

  • Bernard Aboba
  • Loa Andersson
  • Brian Carpenter
  • Leslie Daigle
  • Elwyn Davies
  • Kevin Fall
  • Olaf Kolkman
  • Kurtis Lindqvist
  • David Meyer
  • David Oran
  • Eric Rescorla
  • Dave Thaler
  • Lixia Zhang

Authors' Addresses 💌

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052

EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329

Elwyn B. Davies Consultant Soham, Cambs UK

Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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. 💖

📦 where this page comes from