RFC 4903

Multi-Link Subnet Issues

📅 published June 2007, from ietf

Part 1 of 4, bestie 💖

Network Working Group Request for Comments: 4903 Author: D. Thaler, Internet Architecture Board Category: Informational Date: June 2007 Obsoletes / Updates: nothing listed in this RFC 🙈

So the vibe is: it's giving informational, not a standard. It's a heads-up for the internet community, not a rulebook 📖✨

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 there have been a bunch of proposals saying a subnet can stretch across multiple links connected by routers, and this memo is where we write down all the issues and potential problems people have raised about that approach 👀

Table of Contents 📚

   1. Introduction ....................................................2
   2. Issues ..........................................................3
      2.1. IP Model ...................................................3
      2.2. TTL/Hop Limit Issues .......................................4
      2.3. Link-scoped Multicast and Broadcast ........................6
      2.4. Duplicate Address Detection Issues .........................7
   3. Security Considerations .........................................8
   4. Recommendations .................................................9
      4.1. IP Link Model ..............................................9
      4.2. IPv6 Address Assignment ...................................10
      4.3. Duplicate Address Detection Optimizations .................12
   5. Normative References ...........................................12
   6. Informative References .........................................13

1. Introduction ✨

Bestie, let's start with the OG IPv4 address. It had a Network field that said which network you were in, and a Local Address field that picked out a specific host inside that network. As orgs wanted lots of links inside their network, they had three choices (per [RFC950]) 💅

  1. Get a totally separate Internet network number for each cable. Subnets aren't used at all.
  2. Use one network number for the whole organization, but assign host numbers without caring which LAN a host is on ("transparent subnets").
  3. Use one network number and split up the host address space by giving subnet numbers to the LANs ("explicit subnets").

[RFC925] was a proposal for option 2 🫶 It defined a specific kind of Address Resolution Protocol (ARP) proxy behavior, where the forwarding plane had to decrement the Time To Live (TTL) to stop loops when forwarding, not forward packets destined to 255.255.255.255, and support subnet broadcast by making the ARP-based bridge keep a list of recent broadcast packets. Honestly this approach was never standardized, although [RFC1027] later documented an implementation of a subset of [RFC925] 🙃

Instead, the IETF went with option 3 in [RFC950], where hosts were required to learn a subnet mask, and that became the IPv4 model 🎀

Over the recent past, a few newer protocols have been trying to extend the notion of a subnet so it can span multiple links, kind of like [RFC925] did 👀

Early versions of the IPv6 scoped address architecture [SCOPID] proposed a subnet scope above the link scope, to allow for multi-link subnets. The WG rejected this because of the issues discussed in this memo, so the final version [RFC4007] has no such notion 💀

There was also a proposal to define multi-link subnets [MLSR] for IPv6. The IPv6 WG abandoned that notion for the same issues discussed in this memo, and the proposal got replaced by a different mechanism that keeps the idea that a subnet spans only one link [RFC4389] ✨

However, other WGs kept the concept alive even after the IPv6 WG rejected it 🧚 Mobile IPv6 [RFC3775] lets tunnels to mobile nodes use the same subnet as a home link, with the Home Agent doing layer 3 forwarding between them.

The notion also pops up in Mobile Ad-hoc NETworks (MANETs), where people propose that an entire MANET is one subnet, with routers doing layer 3 forwarding inside it 🌈

Other working groups have considered multi-link subnets too, including NetLMM, 16ng, and Autoconf. External orgs like WiMax have looked at it as well 👑

In this memo, we document the issues raised in the IPv6 WG that motivated abandoning the multi-link subnet concept, so designers of other protocols can (and should) be aware of the issues 🫶

The key words "MUST", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119] 📖

2. Issues 🔥

2.1. IP Model 🧠

Okay so "link" usually means a topological area bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet. Link-local address prefixes are defined in both IPv4 [RFC3927] and IPv6 [RFC4291] 🦋

"Subnet" usually means a topological area that uses the same address prefix, where that prefix isn't further subdivided except into individual addresses 🌸

In December 1995 the original IP Version 6 Addressing Architecture [RFC1884] was published, and it said: "IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link." 💅

So it straight up acknowledges that the IPv4 model has been that a subnet is tied to one link, and that IPv6 isn't changing that. Also, a subnet is sometimes treated as just a subset of a link, when multiple subnets get assigned to the same link 🙈

The IPv6 addressing architecture has since been updated three times: first in July 1998 [RFC2373], then April 2003 [RFC3513], and finally in February 2006 [RFC4291]. Every update includes the language: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link." 🎀

Clearly, a multi-link subnet would be a change to the existing IP model 😭

Similarly, the Mobility Related Terminology [RFC3753] defines a Foreign subnet prefix as "a bit string that consists of some number of initial bits of an IP address which identifies a node's foreign link within the Internet topology," with a similar definition for a Home subnet prefix. Both say the subnet prefix identifies a (singular) link 👑

2.2. TTL/Hop Limit Issues 💅

Since a link is bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit, things can go sideways for applications and protocols that assume anything about how TTL/Hop Limit relates to the subnet prefix 🙃

There are two main cases. Some applications and protocols send packets with a TTL/Hop Limit of 1. Others send packets with a TTL/Hop Limit of 255 and check that the value is 255 on receipt. Both are ways of keeping communication within a single link, but their effects are pretty different. Setting TTL/Hop Limit to 1 makes sure the sent packets don't leave the link, but it doesn't stop an off-link attacker from sending a packet that can reach the link. Checking for 255 on receipt stops a receiver from accepting packets from an off-link sender, but it doesn't stop a sent packet from getting forwarded off-link 🚨

Now let's look at assumptions about TTL/Hop Limit and subnet, using some references that tons of protocol and application devs know 🤓

Stevens' "Unix Network Programming", 2nd ed. [UNP], says on page 490: "A TTL of 0 means node-local, 1 means link-local" (which is true by the definition of link, obviously). Then on page 498, about IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, it says: "If this is not specified, both default to 1, which restricts the datagram to the local subnet." So Unix programmers learn that TTL=1 packets are restricted to a subnet (instead of a link). This is typical of lots of docs that use the terms interchangeably because of the IP model we just covered 🫠

Same energy in "TCP/IP Illustrated", Volume 1 [TCPILL], which says on page 182: "By default, multicast datagrams are sent with a TTL of 1. This restricts the datagram to the same subnet." 💀

Steve Deering's original multicast README file [DEERING] said: "multicast datagrams with initial TTL 1 are restricted to the same subnet." Similar statements now show up in lots of vendor docs, including Windows (e.g., [TCPIP2K]) and Linux. [LINUX] says a TTL of 1 is "restricted to the same subnet. Won't be forwarded by a router." 🌸

The above are just some examples. Tons of places teach application devs that a subnet is confined to a single link, so we totally have to expect that arbitrary applications may embed those assumptions 👀

Some protocols today are known to embed an assumption about the relationship between TTL and subnet prefix:

  • Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit 255 checked on receipt, to resolve the link-layer address of any IP address in the subnet.
  • Older clients of Apple's Bonjour [MDNS] use messages with TTL 255 checked on receipt, and only respond to queries from addresses in the same subnet. (Note that multi-link subnets do not necessarily break this, as this behavior is to constrain communication to within a subnet, where a subnet is only a subset of a link. However, it will not work across a multi-link subnet.) 🧐

Some other protocols today are known to use a TTL 1 or 255, but don't appear to explicitly assume anything about the relationship to subnet prefixes (other than the well-known link-local prefix). These include the following:

  • Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit of 1 for TCP.
  • Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1.
  • Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 checked on receipt for Registration Requests sent to foreign agents.
  • [RFC3927] discusses the use of TTL=1 and TTL=255 within the IPv4 link-local address prefix.

It is unknown whether any implementations of such protocols exist that add assumptions about the relationship to subnet prefixes for other reasons 🔮

okay so multicast routing is NOT everywhere 😭 which means a subnet that stretches across multiple links is basically asking for trouble. 🙈 per [RFC2644], routers don't forward directed broadcast packets by default either, and they don't forward limited broadcasts (see [RFC1812], Section 4.2.2.11). the drama is real 💀

there are SO many protocols and apps that use link-scoped multicast 🦋 the ones that got their very own link-scoped multicast group address (and might also have assumptions about the TTL/Hop Limit like we talked about above) are listed here:

http://www.iana.org/assignments/multicast-addresses

http://www.iana.org/assignments/ipv6-multicast-addresses

and then there's a whole bunch of other apps that just use the all-1's broadcast address, or the all-hosts link-scoped multicast address, instead of getting their own group address 🌸 the chaos is iconic

the well-known examples of protocols using link-scoped multicast or broadcast mostly fall into these groups:

  • Routing protocols: Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075], OSPF [RFC2328], RIP [RFC2453][RFC2080], Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP], etc. these protocols swap routes to subnet prefixes 🛣️
  • Address management protocols: Neighbor Discovery, DHCPv4 [RFC2131], Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], Teredo [RFC4380], etc. this group tends to bake in assumptions about the link-and-subnet-prefix relationship 💅 for example, ND uses link-scoped multicast to resolve the link-layer address of an IP address in the same subnet prefix, and to do duplicate address detection (see Section 2.4 below) within the subnet. DHCP uses link-scoped multicast or broadcast to get an address in the subnet. Teredo says the Teredo IPv4 Discovery Address is:
"an IPv4 multicast address used to discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253"

which is a link-scoped multicast address 🧚 it also says:

"the client MUST silently discard all local discovery bubbles [...] whose IPv4 source address does not belong to the local IPv4 subnet"
  • Service discovery protocols: Simple Service Discovery Protocol (SSDP) [SSDP], Bonjour, WS-Discovery [WSDISC], etc. these usually don't define any explicit assumption about the relationship to subnet prefix ✨
  • Name resolution protocols: NetBios [RFC1001], Bonjour, LLMNR, etc. mostly these don't define any explicit assumption about the relationship to subnet prefix, BUT Bonjour only responds to queries from addresses within the same subnet prefix 👀

ngl this next bit is important 🫶 protocols like Bonjour and Teredo drop packets that don't come from an address within the subnet, and that is NOT automatically broken by multi-link subnets. the behavior is meant to keep things inside one subnet when a link is bigger than a single subnet, so it's actually doing its job 💜

BUT (and this is a big but 🙅‍♀️) no matter whether there's any assumption about the subnet prefix relationship, ALL the protocols above, plus everything on the IANA assignment lists, won't work across a multi-link subnet without protocol-specific proxying in routers. and adding proxying for an arbitrary number of protocols and apps does not scale 😭 it could also get in the way of future protocols that want to use link-scoped multicast. not it 🙃

2.4. Duplicate Address Detection Issues 🎀

Duplicate Address Detection (DAD) uses link-scoped multicast in IPv6 and link-scoped broadcast in IPv4, so it has all the issues from Section 2.3 above. the girlies are cooked 🍳

also [RFC2462] has this statement:

"Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link-local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier."

the last possibility, sometimes called Duplicate Interface Identifier Detection (DIID), has been the subject of a LOT of debate 🍿 the current work in progress [2462BIS] says:

Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address using the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization.

ok so the vibe is: that "optimization" is NOT RECOMMENDED 🙅‍♀️ and new implementations MUST NOT do it. the existing ones aren't invalidated, but still, no thanks 💅

and here's where multi-link subnets make it messy 😵‍💫 a link-local address is only valid within one link, so it only gets checked for uniqueness on that single link. if the same interface identifier is then assumed to be unique across ALL the links in a multi-link subnet, address conflicts can happen. 💔

3. Security Considerations 🔐

ok this section is serious bestie so pay attention 🚨 the idea of multi-link subnets can cause problems with any security protocol that either relies on the assumption that a subnet only spans a single link, or leaves gaps in the security solution because the protocols only work on a single link. it's giving vulnerability 💀

Secure Neighbor Discovery (SEND) [RFC3971] in particular is currently only defined within a single link. if a subnet spanned multiple links, SEND would not work as currently specified, because it secures Neighbor Discovery messages that include link-layer addresses, and if they're forwarded to other links, the sender's link-layer address will be different. this same problem also shows up when a subnet doesn't span multiple links but Neighbor Discovery gets proxied within a link. Section 9 of [RFC4389] talks about some possible future directions for this 🔮

and as noted above, some apps and protocols (ND, Bonjour, Mobile IPv4, etc.) help guard against off-link spoofing attempts by requiring a TTL or Hop Limit of 255 on receipt. if that restriction were removed, or if alternative protocols were used instead, off-link spoofing attempts would get way easier, and some other way to mitigate those attacks would be needed 🚫 this is not the time to be careless, babes 🙏

4. Recommendations 🌈

there are two models that DON'T have the issues pointed out in the rest of the document 🎉

the IAB recommends that protocol designers use one of these two models:

  • Multi-access link model: in this model, there can be multiple nodes on the same link, including zero or more routers. Data packets sent to the IPv4 link-local broadcast address (255.255.255.255) or to a link-local multicast address can be received by all other interested nodes on the link. Two nodes on the link can communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link. 🛜
  • Point-to-point link model: in this model, there are exactly two nodes on the same link. Data packets sent to the IPv4 link-local broadcast address or to a link-local multicast address can be received by the other node on the link. The two nodes can communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link. 🤝

there's a variant of the multi-access link model that has fewer issues (but still some) 🥹

  • Non-broadcast multi-access (NBMA) model: same as the multi-access link model, EXCEPT no broadcast or multicast packets can be sent, even between two nodes on the same link. as a result, no protocols or apps that use broadcast or multicast will work 😭

links that show up as NBMA links at layer 3 are problematic 🚩 so instead, if a link is an NBMA link at layer 2, protocol designers should define some mechanism so it appears as either the multi-access link model or the point-to-point link model at layer 3. ✨

one use of an NBMA link is when the link is meant to be a wide-area link (for example, a tunnel like 6to4 [RFC3056]) where none of the groups of functionality in Section 2.3 are needed across the wide area. admittedly, what counts as "wide-area" is kind of subjective 🌍 supporting multicast on a wide-area link would be like supporting multicast routing across a bunch of local-area links. the issues discussed in Section 2.3 will still come up, but they might be acceptable over a wide area until multicast routing is supported too 🫠

also note that whether a link is a tunnel or not is totally separate from which model you pick. there are tunnel links for every link model above 🧚

a multi-link subnet model should be avoided 🙅‍♀️ IETF working groups that use, or are thinking about using, multi-link subnets today should look into moving to one of the other models. for example, the Mobile IPv6 WG should look into having the Home Agent not decrement the Hop Limit, and forward multicast traffic 💜

when you're thinking about switching an existing multi-link subnet solution to another model, these issues should be considered:

  • Loop prevention: if physical loops can't exist within the subnet, then removing the TTL/Hop Limit decrement isn't an issue. otherwise, protocol designers can (for example) keep the decrement but use a separate prefix per link, or use some form of bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]). 🔁
  • Limiting broadcast (including all-hosts multicast): if there's no efficiency requirement to stop broadcast from reaching other on-link hosts, then flooding it within the subnet isn't an issue. otherwise, protocol designers can (for example) use a separate prefix per link, or flood broadcast other than ARP within the subnet (ARP is covered below in Section 4.3). 📢
  • Limiting the scope of other multicast (including IPv6 Neighbor Discovery): if there's no efficiency requirement to stop multicast from reaching other on-link hosts, then flooding multicast within the subnet isn't an issue. otherwise, protocol designers can (for example) use a separate prefix per link, or use Internet Group Management Protocol (IGMP)/MLD snooping [RFC4541] instead. 🍓

4.2. IPv6 Address Assignment 💖

Okay so in IPv6, the Prefix Information Option in a Router Advertisement (RA) is how a router says "this prefix lives on this link" 🎀 That means the router and the node both have an on-link route in their routing table (or an on-link Prefix List, in the conceptual host model from [RFC2461]), and any addresses from that prefix are assigned to an interface on any node attached to that link ✨

DHCPv6 Prefix Delegation (DHCP-PD) [RFC3633] is the opposite vibe 🦋 It's how a client asks for a prefix to use on a different link. Section 12.1 of RFC 3633 says:

Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.

So the upstream router has a route for that prefix that is not on-link, but it points to the client 🌈 The prefix is assigned to a link other than the one DHCP-PD ran over, and any addresses from it are assigned to interfaces on nodes attached to that other link. Main character energy for the prefix, honestly 👑

The IAB thinks the difference between these two cases (same link vs. another link) is a big deal 🔥 It also thinks the IETF protocols above are the right fit for those two scenarios. The IAB recommends that other protocol designers stay consistent with the IETF-defined scopes of these protocols. For example, don't use DHCP-PD to put a prefix on the same link, and don't use RAs to put a prefix on another link 🙅‍♀️

Now the L flag. The Prefix Information Option has an L (on-link) flag 🧚 Normally it's set, which means this prefix can be used for on-link determination. When it's not set, the advertisement says nothing about whether the prefix is on-link or off-link. The prefix might be used for address configuration, with some addresses from it on-link and others off-link. So be careful when the L flag is not set 😭

Here's the tea: some platforms let applications look up the prefix length for each address on the node. If an implementation returns the prefix length used for address configuration, applications may wrongly assume that TTL=1 is enough to communicate, and that link-scoped multicast will reach other addresses in the prefix 💀 That's why the IAB recommends that designers and maintainers of APIs that give applications a prefix length deal with this. For example, they might say that no prefix length exists when the prefix isn't on-link. If the API can't report that one doesn't exist, they might choose to report a value of 128 when the prefix is not on-link. That makes those applications think they're on separate subnets, instead of on a multi-link subnet 🍓

4.3. Duplicate Address Detection Optimizations 🌸

One reason people sometimes give for wanting a multi-link subnet model (instead of a multi-access link model) is to cut down on ARP/ND traffic between end-nodes 🙈 This is mainly a problem in IPv4, where ARP results in a broadcast that every node sees, not just the node whose IPv4 address is being resolved. Even if it's a real concern, you don't need a multi-link subnet model to fix it. The point-to-point link model is one way to avoid the issue entirely 🦋

In the multi-access link model, IPv6 ND traffic can be reduced with well-known multicast learning techniques (e.g., [RFC4541] at a layer 2 intermediate device (bridge, switch, access point, etc.). ✨

Some people have suggested that a layer 2 device could keep an ARP or ND cache and answer requests from it 🤔 But that kind of cache blocks fast mobility between layer 2 ports, and it breaks Secure Neighbor Discovery [RFC3971]. So the IAB recommends to protocol designers that they avoid this approach, and use an alternative like layer 2 learning instead 🫶 For IPv4 (where no Secure ARP exists), the IAB recommends that protocol designers avoid having a device respond from its cache when a node can legitimately move between layer 2 segments of the link without any layer 2 indication at the layer 2 intermediate device. Also, there's currently no guarantee that any device other than the end-host knows all of the end-host's addresses, so protocol designers should avoid depending on that assumption 💅 For example, when no cache entry is found for a request, protocol designers may specify that a node broadcast the request to all nodes.

5. Normative References 📚

  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
  • [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
  • [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
  • [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
  • [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
  • [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.

6. Informative References ✨

okay so this is the reading list, bestie 📚 these are the informative refs, the background stuff that gives you context for the spec.

IAB Members at the time of this writing 👑

These are the lovely IAB members who were around when this got written 💜

  • 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

Author's Address 🎀

Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052

Phone: +1 425 703 8835 EMail: dthaler@microsoft.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