RFC 4429

Optimistic Duplicate Address Detection (DAD) for IPv6

📅 published April 2006, from ietf

Network Working Group 💌

Okay bestie, let's get the basics down first 🎀. This is RFC 4429, called Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore from Monash University CTIE wrote it, it's a Standards Track doc, and it's dated April 2006 🦋.

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006).

Abstract 🔥

Optimistic Duplicate Address Detection is an interoperable change to the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes 💖. The goal is to keep address configuration fast when things go right, keep the mess small when things go wrong, and still play nicely with unmodified hosts and routers 🧚.

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Problem Statement ..........................................3
      1.2. Definitions ................................................4
      1.3. Address Types ..............................................4
      1.4. Abbreviations ..............................................5
   2. Optimistic DAD Behaviors ........................................6
      2.1. Optimistic Addresses .......................................6
      2.2. Avoiding Disruption ........................................6
      2.3. Router Redirection .........................................7
      2.4. Contacting the Router ......................................7
   3. Modifications to RFC-Mandated Behavior ..........................8
      3.1. General ....................................................8
      3.2. Modifications to RFC 2461 Neighbor Discovery ...............8
      3.3. Modifications to RFC 2462 Stateless Address
           Autoconfiguration ..........................................9
   4. Protocol Operation .............................................10
      4.1. Simple Case ...............................................10
      4.2. Collision Case ............................................10
      4.3. Interoperation Cases ......................................11
      4.4. Pathological Cases ........................................11
   5. Security Considerations ........................................12
   Appendix A. Probability of Collision ..............................13
      A.1. The Birthday Paradox ......................................13
      A.2. Individual Moving Nodes ...................................14
   Normative References ..............................................15
   Informative References ............................................15
   Acknowledgements ..................................................16

1. Introduction ✨

Optimistic Duplicate Address Detection (DAD) is a tweak to the existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462] processes 💫. The whole point is to make address setup quicker when everything goes smoothly, and to cut down on disruption when a collision actually happens 🏃‍♀️.

Optimistic DAD is a smart optimization, lowkey, because in most cases DAD is way more likely to succeed than to fail 😌. Appendix A goes into that more. Disruption stays low by limiting how much nodes take part in Neighbor Discovery while their addresses are still Optimistic 🙈.

This memo is not trying to make DAD more secure, reliable, or robust than the existing standards already are 🛡️. It's just here to make DAD faster, nothing more, no cap 💅.

1.1. Problem Statement 🌸

The current IPv6 address configuration mechanisms do a solid job catching collisions, but only for the fixed hosts they were built for 🧸. Now there's a growing crowd of nodes that need to stay connected all the time, even while they keep changing where they attach to the network 📱. Those nodes need DAD optimizations so they can get addresses configured fast enough to keep up 🚀.

An optimized DAD method needs to:

  • provide interoperability with nodes using the current standards.
  • remove the RetransTimer delay during address configuration.
  • ensure that the probability of address collision is not increased.
  • improve the resolution mechanisms for address collisions.
  • minimize disruption in the case of a collision.

Just shrinking RetransTimer won't cut it for handovers 🙅‍♀️. If you make it long enough to reliably catch a collision, it ends up way too long and wrecks time-critical services 💀.

1.2. Definitions 🧁

Here's how requirements keywords ('MUST NOT', 'SHOULD NOT', 'MAY', 'SHOULD', 'MUST') are defined, following the IETF Best Current Practice, RFC 2119 [RFC2119] 📖.

  • Address Resolution - Process defined by [RFC2461], section 7.2.
  • Neighbor Unreachability Detection (NUD) - Process defined by [RFC2461], section 7.3.
  • Standard Node - A Standard Node is one that is compliant with [RFC2461] and [RFC2462].
  • Optimistic Node (ON) - An Optimistic Node is one that is compliant with the rules specified in this memo ✨.
  • Link - A communication facility or medium over which nodes can communicate at the link layer 🔗.
  • Neighbors - Nodes on the same link, which may therefore be competing for the same IP addresses 👀.

1.3. Address Types 🦋

  • Tentative address (as per [RFC2462]) - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A Tentative address is not considered assigned to an interface in the usual sense 🫣. An interface discards received packets addressed to a Tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the Tentative address 📦.
  • Optimistic address - an address that is assigned to an interface and available for use, subject to restrictions, while its uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions 🌈.
  • Preferred address (as per [RFC2462]) - an address assigned to an interface whose use by upper-layer protocols is unrestricted. Preferred addresses may be used as the source (or destination) address of packets sent from (or to) the interface 👑.
  • Deprecated address (as per [RFC2462]) - An address assigned to an interface whose use is discouraged, but not forbidden 🙃. A Deprecated address should no longer be used as a source address in new communications, but packets sent from or to Deprecated addresses are delivered as expected. A Deprecated address may continue to be used as a source address in communications where switching to a Preferred address causes hardship to a specific upper-layer activity (e.g., an existing TCP connection) 🥲.

1.4. Abbreviations 📚

  • DAD - Duplicate Address Detection. Technique used for SLAAC. See [RFC2462], section 5.4.
  • ICMP Redirect - See [RFC2461], section 4.5.
  • NA - Neighbor Advertisement. See [RFC2461], sections 4.4 and 7.
  • NC - Neighbor Cache. See [RFC2461], sections 5.1 and 7.3.
  • ND - Neighbor Discovery. The process described in [RFC2461].
  • NS - Neighbor Solicitation. See [RFC2461], sections 4.3 and 7.
  • RA - Router Advertisement. See [RFC2462], sections 4.2 and 6.
  • RS - Router Solicitation. See [RFC2461], sections 4.1 and 6.
  • SLAAC - StateLess Address AutoConfiguration. The process described in [RFC2462].
  • SLLAO - Source Link-Layer Address Option, an option to NS, RA, and RS messages, which gives the link-layer address of the source of the message. See [RFC2461], section 4.6.1 🫶.
  • TLLAO - Target Link-Layer Address Option, an option to ICMP Redirect messages and Neighbor Advertisements. See [RFC2461], sections 4.4, 4.5, and 4.6.1 💜.

2. Optimistic DAD Behaviors 💖

This section is non-normative, so it's more of a chill walkthrough of how Optimistic DAD behaves 🌷.

2.1. Optimistic Addresses 🎀

[RFC2462] brings in the ideas of Tentative (in 5.4) and Deprecated (in 5.5.4) addresses. Anything that's neither of those counts as Preferred 🌟. Tentative addresses can't be used for communication, and Deprecated addresses should not be used for new communications. Other standards documents can use these address states too, like Default Address Selection [RFC3484] 🧩.

This memo adds a brand-new address state called Optimistic. It marks an address that's ready to use but hasn't finished DAD yet 🦄.

Unless noted otherwise, parts of the IPv6 protocol stack should treat Optimistic addresses the same way they treat Deprecated ones. That means the address is usable, but it shouldn't get picked if another suitable address is around 🙌. For example, Default Address Selection [RFC3484] uses the address state to choose which source address goes on an outgoing packet. Implementations should treat an address in state Optimistic as if it were in state Deprecated 🫠. If address states get stored as separate flags, you can get this by also setting Deprecated whenever Optimistic is set 🧃.

Important bit: the address lifetime rules from [RFC2462] still apply, so an address can be Deprecated and Optimistic at the same time 😭. When DAD finishes without any drama, the address turns into either a Preferred or a Deprecated address, following [RFC2462] 🎉.

2.2. Avoiding Disruption 🙈

To avoid interference, an Optimistic Node must not send any messages from an Optimistic Address that would override its neighbors' Neighbor Cache (NC) entries for the address it's trying to configure. Doing that would wreck the rightful owner of the address if there's a collision 😤.

This is handled by:

  • Clearing the Override flag in Neighbor Advertisements for Optimistic Addresses, which stops neighbors from overriding their existing NC entries. The Override flag is already defined [RFC2461] and used for Proxy Neighbor Advertisement ✨.
  • Never sending Neighbor Solicitations from an Optimistic Address. NSes include a Source Link-Layer Address Option (SLLAO), which may cause Neighbor Cache disruption. NSes sent as part of DAD are sent from the unspecified address, without a SLLAO 🫢.
  • Never using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified address, may be used, or the RS may be sent without a SLLAO 🌸.

An address collision with a router may cause a neighboring router's IsRouter flags for that address to be cleared. But routers don't seem to use the IsRouter flag for anything, and the NA sent in response to the collision will set the IsRouter flag again 🔁.

2.3. Router Redirection 🦋

okay so, Neighbor Solicitations can't be sent from Optimistic Addresses 🙈, which means an ON can't directly reach a neighbor that isn't already in its Neighbor Cache. bestie, that's a whole vibe check 💀. so instead the ON forwards its packets through its default router and trusts the router to get them where they're going 🫶. per RFC 2461, the router should then send the ON an ICMP Redirect, which may include a Target Link-Layer Address Option (TLLAO) ✨. if it does, that updates the ON's NC and direct communication can begin 🔥. if it doesn't, packets keep going through the router until the ON has a non-Optimistic address it can send an NS from 🌸.

2.4. Contacting the Router 💌

generally an RA will include a SLLAO, however this "MAY be omitted to facilitate in-bound load balancing over replicated interfaces" [RFC2461]. so a node with only Optimistic Addresses can't figure out the router's Link-Layer Address 😭. it can't send an RS to request a unicast RA, and it can't send an NS to request an NA either. so the ON can't talk to the router until at least one of its addresses is no longer Optimistic 🥲.

3. Modifications to RFC-Mandated Behavior ✨

all the normative text in this memo lives in this section 📜, so this is the part to read closely 👀.

3.1. General

  • Optimistic DAD SHOULD only be used when the implementation is aware that the address is based on a most likely unique interface identifier (such as in [RFC2464]), generated randomly [RFC3041], or by a well-distributed hash function [RFC3972] or assigned by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Optimistic DAD SHOULD NOT be used for manually entered addresses 🙅‍♀️.

3.2. Modifications to RFC 2461 Neighbor Discovery

  • (modifies section 6.3.7) A node MUST NOT send a Router Solicitation with a SLLAO from an Optimistic Address. Router Solicitations SHOULD be sent from a non-Optimistic or the Unspecified Address; however, they MAY be sent from an Optimistic Address as long as the SLLAO is not included 💅.
  • (modifies section 7.2.2) A node MUST NOT use an Optimistic Address as the source address of a Neighbor Solicitation 🚫.
  • If the ON isn't told the SLLAO of the router in an RA, and it cannot determine this information without breaching the rules above, it MUST leave the address Tentative until DAD completes, even though it can't send any packets to the router 😤.
  • (modifies section 7.2.2) When a node has a unicast packet to send from an Optimistic Address to a neighbor, but does not know the neighbor's link-layer address, it MUST NOT perform Address Resolution. It SHOULD forward the packet to a default router on the link in the hope that the packet will be redirected. Otherwise, it SHOULD buffer the packet until DAD is complete 🎀.

3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration

  • (modifies section 5.5) A host MAY choose to configure a new address as an Optimistic Address. A host that does not know the SLLAO of its router SHOULD NOT configure a new address as Optimistic. A router SHOULD NOT configure an Optimistic Address 🧚.
  • (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages ⭐.
  • (modifies section 5.4) The Optimistic Address is configured and available for use on the interface immediately. The address MUST be flagged as 'Optimistic' 🏷️.
  • When DAD completes for an Optimistic Address, the address is no longer Optimistic, and it becomes Preferred or Deprecated according to the rules of RFC 2462 🦋.
  • (modifies section 5.4.3) The node MUST NOT reply to a Neighbor Solicitation for an Optimistic Address from the unspecified address. Receipt of such an NS indicates that the address is a duplicate, and it MUST be deconfigured as per the behaviour specified in RFC 2462 for Tentative addresses 💀.
  • (modifies section 5.4.3) The node MUST reply to a Neighbor Solicitation for an Optimistic Address from a unicast address, but the reply MUST have the Override flag cleared (O=0) 🌈.

4. Protocol Operation 🔮

this section is non-normative 🫶, so it's just here to clarify how Optimistic Nodes interact with each other and with Standard Nodes. every case below starts with an Optimistic Node (ON) getting a Router Advertisement with a new prefix and deciding to autoconfigure a new Optimistic Address on that prefix ✨.

the ON immediately sends out a Neighbor Solicitation to check whether its new Optimistic Address is already in use 👀.

4.1. Simple Case

in the non-collision case, the Optimistic Address being configured is unused and isn't in the Neighbor Caches of any of its neighbors 🌸. there's no response to its NS (sent from ::), and that NS won't change the state of anyone's Neighbor Caches 🙌.

the ON already has the router's link-layer address from the RA, and the router can figure out the ON's link-layer address through standard Address Resolution. communication can start as soon as the router and the ON each have the other's link-layer address 💖.

once the appropriate DAD delay is over, the address is no longer Optimistic and becomes either Preferred or Deprecated as per RFC 2462 🎉.

4.2. Collision Case

in the collision case, the Optimistic Address is already in use by another node and is in the Neighbor Caches (NCs) of neighbors who are talking to this node 😬.

the NS sent by the ON has the unspecified source address, ::, and no SLLAO. this NS won't change the NC entries of neighboring hosts 🛡️.

the ON will hopefully already know everything it needs about the router from the initial RA ✨. if it still needs more info, it can send an RS to ask for it, but it may not include a SLLAO. that forces an all-nodes multicast response from the router, but it won't disrupt other nodes' NCs 🫶.

while setting up connections, the ON might have sent NAs in response to NSes it received. since NAs sent from Optimistic Addresses have O=0, they won't have overridden existing NC entries 🙏. they might still have changed a colliding entry to state STALE, though, and that change can be recovered through standard NUD 🔄.

when an NA arrives from the collidee defending the address, the ON immediately stops using the address and deconfigures it 🚨.

in the meantime, the ON may have sent packets that identify it as the owner of its new Optimistic Address (for example, Binding Updates in Mobile IPv6 [RFC3775]). that can cost the ON some penalty, like broken connections, and it can cost the rightful owner too, since it gets (and might reply to) the misdirected packets 😵. this is exactly why Optimistic DAD should only be used where the probability of collision is very low 🍓.

4.3. Interoperation Cases

once the Optimistic Address has finished DAD, it acts exactly like a normal address. so interoperation cases only come up while the address is still Optimistic ⏳.

if an ON tries to configure an address that's currently Tentatively assigned to a Standard Node, the Standard Node sees the Neighbor Solicitation and deconfigures the address 👋.

if a node tries to configure an ON's Optimistic Address, the ON sees the NS and deconfigures the address 🙅‍♀️.

4.4. Pathological Cases

Optimistic DAD has similar problems to Standard DAD. for example, duplicates aren't guaranteed to be detected if packets get lost 😩.

these problems exist, and aren't gracefully recoverable, in Standard DAD too. their probability in both Optimistic and Standard DAD can be lowered by raising the RFC 2462 DupAddrDetectTransmits variable to greater than 1 📈.

this version of Optimistic DAD depends on the details of router behaviour. for example, it assumes the router includes SLLAOs in RAs and that the router is willing to redirect traffic for the ON 🧐. where the router doesn't behave that way, Optimistic DAD basically falls back to acting like Standard DAD 🔁.

5. Security Considerations 🔐

there are existing security concerns with Neighbor Discovery and Stateless Address Autoconfiguration, and this memo doesn't claim to fix them 🙈. but this memo doesn't significantly increase security concerns either 🫶.

Secure Neighbor Discovery (SEND) [RFC3971] protects against the threats to Neighbor Discovery described in [RFC3756]. Optimistic Duplicate Address Detection doesn't add any extra threats to Neighbor Discovery if SEND is used 🔒.

Optimistic DAD makes sure that if another node is already using an address, the proper link-layer address in existing Neighbor Cache entries isn't replaced with the link-layer address of the Optimistic Node 🛡️. however, there are still scenarios where incorrect entries may get created, even if only temporarily 😬. for example, if a router (while forwarding a packet) sends out a Neighbor Solicitation for an address, the Optimistic Node may respond first. if the router has no pre-existing link-layer address for that IP address, it will accept the response and (incorrectly) forward any queued packets to the Optimistic Node 📦. the Optimistic Node may then respond in an incorrect manner (e.g., sending a TCP RST in response to an unknown TCP connection) 💀. such transient conditions should be short-lived, in most cases ⏱️.

likewise, an Optimistic Node can still inject IP packets into the Internet that will in effect be "spoofed" packets appearing to come from the legitimate node 👻. in some cases those packets may cause errors or other operational problems, though one would expect upper-layer protocols to generally treat such packets robustly, the same way they have to treat old and other duplicate packets 🧱.

Appendix A. Probability of Collision 🎲

when you're judging whether Duplicate Address Detection is worth it, you have to think about the probability of collision 🤔. various mechanisms, like SLAAC [RFC2462] and DHCPv6 [RFC3315], try to guarantee address uniqueness. SLAAC's uniqueness depends on the manufacturing process being reliable (so duplicate L2 addresses aren't assigned) and on human factors if L2 addresses can be assigned manually 🏭. DHCPv6-assigned addresses rely on the implementation being correct so that no two nodes can be given the same address 🧑‍💻.

"Privacy Extensions to SLAAC" [RFC3041] avoids these potential error cases by picking an Interface Identifier (IID) at random from 2^62 possible 64-bit IIDs (allowing for the reserved U and G bits) 🎰. nothing is done to guarantee uniqueness, but the probability can be easily estimated, and as the following discussion shows, the probability of collision is exceedingly small 🌟✨.

A.1. The Birthday Paradox ✨

okay so when people talk about collision odds, the Birthday Paradox always pops up, bestie 🎂. The idea: if you randomly pick k values out of n possibilities, the chance that any two of them match is:

Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )

The problem is that n! is a total monster to calculate, since (2^62)! is an unwieldy number 💀. So instead we can work out an upper bound on the collision probability:

Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )

And the result is iconic 🦋: even for big networks, the chance of any two nodes colliding is tiny:

Pb(2^62,    500) <= 5.4e-14
Pb(2^62,   5000) <= 5.4e-12
Pb(2^62,  50000) <= 5.4e-10
Pb(2^62, 500000) <= 5.4e-08

The upper-bound formula comes from "Random Generation of Interface Identifiers", by M. Bagnulo, I. Soto, A. Garcia-Martinez, and A. Azcorra, and it's used with the kind permission of the authors 🫶.

A.2. Individual Nodes 🌸

When we look at collisions from the point of view of one individual node, we don't need the Birthday Paradox at all 🙈. When a node moves into a network with K existing nodes, the chance that it won't collide with any of the distinct addresses in use is just 1-K/N. If it makes M such moves, the chance it causes no collision on any of them is (1-K/N)^M. So the chance it causes at least one collision is:

Pc(n,k,m) = 1-[(1-k/n)^m]

Even with a huge number of moves (m = 600000, which is slightly more than one move per minute for one year) and pretty crowded networks (k=50000 nodes per network), the odds of collision for a given node are vanishingly small 🧚:

Pc(2^62,  5000,   600000)     = 6.66e-10
Pc(2^62, 50000,   600000)     = 6.53e-09

Each collision involves two nodes, so the chance of being affected by one is double that. Even if a node moves into 50000-node networks once per minute for 100 years, the chance it causes or suffers a collision at any point is a little over 1 in a million 😭✨.

Pc(2^62, 50000, 60000000) * 2 = 1.3e-06

Normative References

[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.

Informative References 📚

[RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
           Networks", RFC 2464, December 1998.

[RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
           Stateless Address Autoconfiguration in IPv6", RFC 3041,
           January 2001.

[RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
           C., and M. Carney, "Dynamic Host Configuration Protocol
           for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3484]  Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
           Discovery (ND) Trust Models and Threats", RFC 3756, May
           2004.

[RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
           in IPv6", RFC 3775, June 2004.

[RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
           "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
           RFC 3972, March 2005.

Acknowledgements 🫶

There's some precedent for this work in expired Internet-Drafts and in discussions on the MobileIP WG mailing list and at IETF-54. A similar concept shows up in the 'Optimistic' bit used by R. Koodli and C. Perkins in the now-expired "Fast Handovers in Mobile IPv6" 💜.

Thanks to Greg Daley, Richard Nelson, Brett Pentland and Ahmet Sekercioglu at Monash University CTIE for their feedback and encouragement. More info is here:

<http://www.ctie.monash.edu.au/ipv6/fastho/>

Thanks to all the MobileIP and IPng/IPv6 WG members who joined the debate, especially and alphabetically: Jari Arkko, Marcelo Bagnulo, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, Pekka Nikander, Erik Nordmark, Soohong 'Daniel' Park, Mohan Parthasarathy, Ed Remmel, Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei Tatuya, Dave Thaler, Pascal Thubert, Christian Vogt, Vladislav Yasevich, and Alper Yegin 👑.

This work was supported by the Australian Telecommunications Cooperative Research Centre (ATcrc):

<http://www.telecommunications.crc.org.au/>

Author's Address 🎀

Nick 'Sharkey' Moore
Centre for Telecommunications and Information Engineering
Monash University 3800
Victoria, Australia

Comments should be sent to sharkey@zoic.org and/or the IPv6 Working Group mailing list. Please include 'RFC4429' in the Subject line 💌.

Copyright (C) The Internet Society (2006).

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 on 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 on the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on how rights work for RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be obtained from the IETF's online 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 needed to implement this standard. Please send that info to the IETF at:

ietf-ipr@ietf.org

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🦋💖

📦 where this page comes from