RFC 7721
Security and Privacy Considerations for IPv6 Address Generation Mechanisms
RFC 7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms 🎀
Written by A. Cooper (Cisco), F. Gont (Huawei Technologies), and D. Thaler (Microsoft). It's Informational (published for information, not a standards-track spec 💅), dated March 2016, with ISSN 2070-1721. The original title block doesn't list any RFCs it obsoletes or updates.
Internet Engineering Task Force (IETF) A. Cooper
Request for Comments: 7721 Cisco
Category: Informational F. Gont
ISSN: 2070-1721 Huawei Technologies
D. Thaler
Microsoft
March 2016Abstract ✨
okay so this doc is all about the privacy and security stuff behind the ways IPv6 addresses get made 🔥 It covers a bunch of address generation mechanisms, both the official standardized ones and the ones that just exist out in the wild. It looks at which threats each mechanism actually helps with, and the trade-offs that implementors, developers, and users have to juggle when they pick an address or a generation method. It's giving real talk 💀
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸
This document is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧚
Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7721 ✨
Copyright Notice ✨
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions with respect to this document. Code Components pulled out of this document have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜
Table of Contents ✨
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Weaknesses in IEEE-Identifier-Based IIDs . . . . . . . . . . 5
3.1. Correlation of Activities over Time . . . . . . . . . . . 5
3.2. Location Tracking . . . . . . . . . . . . . . . . . . . . 6
3.3. Address Scanning . . . . . . . . . . . . . . . . . . . . 7
3.4. Device-Specific Vulnerability Exploitation . . . . . . . 7
4. Privacy and Security Properties of Address Generation
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IEEE-Identifier-Based IIDs . . . . . . . . . . . . . . . 10
4.2. Static, Manually Configured IIDs . . . . . . . . . . . . 10
4.3. Constant, Semantically Opaque IIDs . . . . . . . . . . . 10
4.4. Cryptographically Generated IIDs . . . . . . . . . . . . 10
4.5. Stable, Semantically Opaque IIDs . . . . . . . . . . . . 11
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 Generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition and Coexistence Technologies . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 Addressing . . . . . . . . . . 13
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
IPv6 was designed to level up IPv4 in a bunch of ways, and address assignment was one of the big areas to improve 🦋 Besides static assignment and DHCP, stateless autoconfiguration showed up as a lighter, fate-shared way to assign addresses. With stateless autoconfiguration, routers advertise on-link prefixes and hosts make up their own Interface Identifiers (IIDs) to finish their addresses. [RFC7136] clarifies that the IID should be treated as an opaque value, and [RFC7421] digs into the 64-bit boundary in IPv6 addressing (think how the IID length affects security and privacy) 🫧 Over the years, a lot of IID generation techniques have been defined, both standardized and not:
- Manual configuration [RFC7707]
- IPv4 address
- Service port
- Wordy
- Low-byte
- Stateless Address Autoconfiguration (SLAAC)
- IEEE 802 48-bit Media Access Control (MAC) or IEEE 64-bit Extended Unique Identifier (EUI-64) [RFC2464]
- Cryptographically generated [RFC3972]
- Temporary (also known as "privacy addresses") [RFC4941]
- Constant, semantically opaque (also known as "random") [Microsoft]
- Stable, semantically opaque [RFC7217]
- DHCPv6 based [RFC3315]
- Specified by transition/co-existence technologies
Deriving the IID from a globally unique IEEE identifier [RFC2464] [RFC4862] was one of the earliest mechanisms, first specified in [RFC1971] and [RFC1972] 🍓 After standardization, a bunch of privacy and security issues with IEEE-identifier-derived IIDs came to light, and many of the later mechanisms were built to fix some or all of those weaknesses. This document calls out four types of attacks against IEEE-identifier-based IIDs and looks at whether other existing IID generation techniques help with them 🔍
2. Terminology ✨
This section explains the terminology used throughout this document 📖
Public address: An address that has been published in a directory or other public location, such as the DNS, a SIP proxy [RFC3261], an application-specific Distributed Hash Table (DHT), or a publicly available URI. A host's public addresses are meant to be discoverable by third parties 🌐
Stable address: An address that does not vary over time within the same IPv6 link. Note that [RFC4941] calls these "public" addresses, but "stable" is used here for reasons explained in Section 4 🧸
Temporary address: An address that varies over time within the same IPv6 link 🦋
Constant IID: An IPv6 interface identifier that is globally stable. That is, the Interface ID stays constant even if the node moves from one IPv6 link to another 💎
Stable IID: An IPv6 interface identifier that is stable within some specified context. For example, an Interface ID can be globally stable (constant), or it can be stable per IPv6 link, meaning it stays unchanged as long as the node stays on the same IPv6 link but may change when the node moves to a different one 🌸
Temporary IID: An IPv6 interface identifier that varies over time 🫧
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words only take their normative meanings when they're written in ALL UPPERCASE 📜
3. Weaknesses in IEEE-Identifier-Based IIDs ✨
There are a bunch of privacy and security implications for hosts that use IEEE-identifier-based IIDs 😭 This section covers four generic attack types: correlation of activities over time, location tracking, address scanning, and device-specific vulnerability exploitation. The first three rely on the attacker first learning the target host's IID. An attacker could get that from a few different places: the operator of a server the host connects to, like a web server or a peer-to-peer server; an entity on the same IPv6 link as the target (like a conference network or any public network); a passive observer of traffic the host broadcasts; or an entity on path to the destinations the host talks to, like a network operator 👀
3.1. Correlation of Activities over Time 💖
okay bestie, just like any other identifier, an IPv6 address can be used to correlate a host's activities for at least as long as the address sticks around 🦋. The correlation that IEEE-identifier-based IIDs make possible is the scary one 😭, because they basically last for the whole life of a device's network interface, so we're talking correlation on the order of years 💀.
As [RFC4941] puts it:
[t]he use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. ... The use of a constant identifier within an address is of special concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear.
IP addresses are just one way to link someone's activities over time 🌸. DNS names, cookies [RFC6265], browser fingerprints [Panopticlick], and application-layer usernames can all connect a host's activities together too. IEEE-identifier-based IIDs will usually last as long as these other identifiers, or even longer 🍓. IIDs generated in other ways might live shorter or longer than these identifiers, depending on how they're generated ✨. So how much of a host's activity can be correlated really depends on whether the host uses multiple identifiers together, and on how long each one of them lasts 🧚. Frequently refreshing an IPv6 address may not stop correlation if an attacker has access to other longer-lived identifiers for that host, so keep that caveat in mind through the whole correlation discussion in this document 🙈. For more on correlation, see Section 5.2.1 of [RFC6973].
As noted in [RFC4941], correlation can be just as doable for a host using an IPv4 address as for a host whose IPv6 address has an IEEE-based IID 🫶. Hosts that use static IPv4 addressing, or that keep getting the same address from DHCPv4, can be tracked the same way as described above. BUT the widespread use of both NAT and DHCPv4 implementations that hand the same host a different address when its lease expires makes that threat smaller in IPv4 than it is in the IEEE identifier case in IPv6 👑.
3.2. Location Tracking 🗺️
Because the IPv6 address structure is split between a topological portion and an interface identifier portion, an interface identifier that stays constant when a host connects to different IPv6 links (which is exactly what an IEEE-identifier-based IID does) gives observers a way to track that host's movements 👀. In a passive attack on a mobile host, a server that keeps receiving connections from the same host over time could work out where that host is moving as its prefix changes 🚶♀️.
Active attacks are also possible 😈. An attacker could first learn the host's interface identifier by being connected to the same IPv6 link, by running a server that the host connects to, or by being on path to the host's communications. After that, they could probe other networks for the same interface identifier by sending a probe packet (for example an ICMPv6 Echo Request, or any other probe packet) 🕵️♀️. Even if the host doesn't respond, the first-hop router will usually answer with an ICMP Destination Unreachable/Address Unreachable (type 1, code 3) when the host isn't present, and stay silent when the host is present 🎯.
Location tracking based on IP address is generally not possible in IPv4, since hosts get assigned wholly new addresses when they change networks 🌈.
3.3. Address Scanning 🔍
The structure of IEEE-based identifiers used for address generation can be leveraged by an attacker to shrink the target search space [RFC7707] 📉. The 24-bit Organizationally Unique Identifier (OUI) of MAC addresses, together with the fixed value (0xff, 0xfe) used to form a Modified EUI-64 interface identifier, really helps shrink the search space. That makes it much easier for an attacker to scan for individual addresses using widely known popular OUIs 💅. This erases a lot of the protection against address scanning that the bigger IPv6 address space could otherwise offer compared to IPv4 😤.
3.4. Device-Specific Vulnerability Exploitation 🐛
IPv6 addresses that embed IEEE identifiers leak information about the device, like the Network Interface Card vendor or even the Operating System and/or software type 🎁. An attacker who knows about device- or software-specific vulnerabilities could use that to quickly find possible targets 🎯. Attackers can exploit vulnerabilities in hosts whose IIDs they've already obtained, or scan an address space to find potential targets 💀.
4. Privacy and Security Properties of Address Generation Mechanisms ✨
okay so, whether a host is protected against the attacks from Section 3 totally depends on how each of its addresses gets generated and used 🧐 Sometimes a host sets up one global address and uses it for everything. Other times it sets up several addresses with different mechanisms and can use any or all of them 🦋
[RFC3041] (later obsoleted by [RFC4941]) tried to fix some of the Section 3 problems by introducing "temporary addresses" for outbound connections 🌸 These are meant to supplement the other addresses a device has, not replace them. Their IIDs are randomly generated and change daily by default. The vibe was: use temporary addresses for outgoing stuff like web browsing, but keep a stable address around for when you need stability, like IPv6 addresses published in the DNS 💖
[RFC3484] originally said stable addresses should be used for outbound connections unless an application explicitly prefers temporary ones 💅 The stable-by-default choice was made so apps wouldn't break because of a temporary address's short lifetime, or a reverse look-up failing or erroring out. But [RFC3484] also allowed that "implementations for which privacy considerations outweigh these application-compatibility concerns MAY reverse the sense of this rule" and prefer temporary addresses by default instead 🙈 And honestly? Most implementations (Windows especially) went with temporary addresses for outbound connections, because privacy felt more important, and not many apps supported IPv6 back then, so compatibility wasn't a big worry 😭 Then [RFC6724] obsoleted [RFC3484] and updated the default to match what implementations were actually doing 🎀
Heads up, bestie: the relationship [RFC3484] imagined between an address being stable and it being used in "public" can seriously mislead you when you're doing a privacy analysis 💀 Stability and how linkable an address is to some other public identifier are totally independent of each other. Nothing stops a host from publishing a temporary address somewhere public, like the DNS 👀 And if you publish both a stable address and a temporary address in the DNS, or anywhere else they can be tied together by a public identifier, then everything the host does with either address can be correlated 🔥
Also, because temporary addresses were designed to supplement the host's other addresses, a host can still configure a more stable address even if it only ever uses temporary addresses as source addresses for off-link destinations 🧚 An attacker can still probe for that stable address even if it's never used as a source address or advertised outside the link, like in DNS or SIP 😬
This section compares the privacy and security properties of a bunch of IID generation mechanisms and the usage scenarios they fit, including setups where one mechanism generates all of a host's IIDs and setups where temporary addresses are used alongside addresses from a different IID generation mechanism 🌈 The correlation analysis for each IID type assumes that IPv6 prefixes are shared by a reasonably large number of nodes. As [RFC4941] points out, if a very small number of nodes (say, only one) use a particular prefix for a long time, the prefix alone can be used to correlate the host's activities, no matter how the IID was generated 🫶 For example, [RFC3314] recommends that prefixes be uniquely assigned to mobile handsets where IPv6 is used within General Packet Radio Service (GPRS). If that advice is followed and the prefixes stick around for ages (or get handed back to the same handsets whenever they reconnect to the same network router), a host's activities could be correlatable for much longer than the analysis below suggests ⏳
Here's the big summary table! A "No" entry means the attack is prevented on the basis of the IID, but the host might still be vulnerable depending on how it uses other protocols 📊
+--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits |
+--------------+-------------+----------+-------------+-------------+
| IEEE | For device | For | Possible | Possible |
| identifier | lifetime | device | | |
| | | lifetime | | |
| | | | | |
| Static | For address | For | Depends on | Depends on |
| manual | lifetime | address | generation | generation |
| | | lifetime | mechanism | mechanism |
| | | | | |
| Constant, | For address | For | No | No |
| semantically | lifetime | address | | |
| opaque | | lifetime | | |
| | | | | |
| CGA | For | No | No | No |
| | lifetime of | | | |
| | (modifier | | | |
| | block + | | | |
| | public key) | | | |
| | | | | |
| Stable, | Within | No | No | No |
| semantically | single IPv6 | | | |
| opaque | link | | | |
| | | | | |
| Temporary | For temp | No | No | No |
| | address | | | |
| | lifetime | | | |
| | | | | |
| DHCPv6 | For lease | No | Depends on | No |
| | lifetime | | generation | |
| | | | mechanism | |
+--------------+-------------+----------+-------------+-------------+Table 1: Privacy and Security Properties of IID Generation Mechanisms
4.1. IEEE-Identifier-Based IIDs 🪪
As we covered in Section 3, addresses whose IIDs are based on IEEE identifiers are vulnerable to all four attacks 😭 They allow correlation and location tracking for the whole lifetime of the device, since IEEE identifiers last that long, and their structure makes address scanning and device exploits possible 💀
4.2. Static, Manually Configured IIDs 🛠️
Static, manually configured IIDs are stable, so both correlation and location tracking are possible for the life of the address 🎀
How successful location tracking can be depends, to some extent, on how unique the IID is ✨ For example, you'd expect "low byte" IIDs to be reused way more than IIDs where all 64 bits follow some pattern unique to a specific organization 🌸 Widely reused IIDs will typically lead to false positives when doing location tracking 🙃
Whether manually configured addresses are vulnerable to address scanning and device exploits depends on the specifics of how the IIDs are generated 🧐
4.3. Constant, Semantically Opaque IIDs 🦄
Even though nobody has standardized a mechanism for generating a constant, semantically opaque IID, it's been in wide use for many years on at least one platform: Windows 🪟 Windows uses the random generation mechanism described in [RFC4941] instead of generating an IEEE-identifier-based IID 💅 This mitigates the device-specific exploitation and address-scanning attacks, but it still allows correlation and location tracking, because the IID stays constant across IPv6 links and over time 😬
4.4. Cryptographically Generated IIDs 🔐
Cryptographically Generated Addresses (CGAs) [RFC3972] bind a hash of the host's public key to an IPv6 address in the SEcure Neighbor Discovery (SEND) protocol [RFC3971] 🫶 CGAs may be regenerated for each subnet prefix, but that isn't required, since they're computationally expensive to generate 💜 A host using a CGA can be correlated for as long as the combination of its public key and chosen modifier block lasts, because it's possible to rotate modifier blocks without generating new public keys 🔄 Since the hash of the host's public key takes the subnet prefix as an input, even if the host doesn't generate a new public key or modifier block when it moves to a different IPv6 link, its location can't be tracked via the IID 🗺️ And CGAs don't allow device-specific exploitation or address-scanning attacks 👑
4.5. Stable, Semantically Opaque IIDs 🌟
[RFC7217] specifies an algorithm that generates, for each network interface, a unique random IID per IPv6 link 🍓 That algorithm is used not only for global unicast addresses, but also for unique local unicast addresses and link-local unicast addresses, since these addresses may leak out through application protocols (e.g., IPv6 addresses embedded in email headers) 📧
So a host that stays connected to the same IPv6 link could be tracked for a long time, while a mobile host's activities could only be correlated for the duration of each network connection 🏃♀️ Location tracking isn't possible with these addresses, and they also don't allow device-specific exploitation or address-scanning attacks 🦋
4.6. Temporary IIDs 🦋
Okay bestie, a host that uses only a temporary address mitigates all four threats 🧚 Its activities can only be linked together for the lifetime of a single temporary address 🎀
But if a host sets up an IEEE-identifier-based IID and temporary addresses, it's giving the same vulnerabilities as if temporary addresses weren't even in use 💀 The viability of some attacks does depend on how the host uses each address, though. An attacker can link all the activities where the host uses its IEEE-identifier-based IID. Once the attacker has that IID, location tracking works on other IPv6 links too, even if the host only uses temporary addresses there, because the attacker can actively probe those links for the IID 👀 Device-specific vulnerabilities can still be exploited, and address scanning is still possible because the IEEE-identifier-based address can be probed.
Now, if the host instead generates a constant, semantically opaque IID for a stable address used for server-like connections, plus temporary addresses for outbound connections (which is the default in Windows), things get better 💖 The address-scanning and device-specific exploitation attacks are no longer possible, because the OUI is no longer embedded in any of the host's addresses. However, correlation of some activities across time and location tracking are both still possible, because the semantically opaque IID is constant. And once an attacker has the host's semantically opaque IID, location tracking is possible on any network by probing for that IID, even if the host only uses temporary addresses on those networks. Still, if the host generates but never uses a constant, semantically opaque IID, it mitigates all four threats ✨
When used together with temporary addresses, the stable, semantically opaque IID generation mechanism [RFC7217] improves on the previous scenario 🌈 Correlation is limited to the lifetime of the stable address (which may still be lengthy for hosts that are not mobile), and location tracking is eliminated, since a different IID is generated for each subnet prefix. As in the previous scenario, a host that configures but does not use a stable, semantically opaque address mitigates all four threats 🫶
4.7. DHCPv6 Generation of IIDs 🎀
The security and privacy implications of DHCPv6-based addresses will typically depend on whether the client requests an IA_NA (Identity Association for Non-temporary Addresses) or an IA_TA (Identity Association for Temporary Addresses) [RFC3315], plus the specific DHCPv6 server software being used 💅
DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). The properties of DHCPv6 non-temporary addresses, on the other hand, typically depend on the specific DHCPv6 server software. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time to IPv4, so these addresses can be considered "stable, semantically opaque" 🦋 [DHCPv6-IID] specifies an algorithm that DHCPv6 servers can use to generate "stable, semantically opaque" addresses 🧚
Some DHCPv6 software leases sequential addresses (typically low-byte addresses) 🙈 These can be considered stable addresses. The drawback compared to "stable, semantically opaque" addresses is that, since they follow specific patterns, they enable IPv6 address scans 💀
4.8. Transition and Coexistence Technologies 🌸
Addresses specified by transition or coexistence technologies that embed an IPv4 address within an IPv6 address are not included in Table 1, because their privacy and security properties are inherited from the embedded address. For example, Teredo [RFC4380] specifies a way to generate an IPv6 address from the underlying IPv4 address and port, leaving many other bits set to zero. This makes it relatively easy for an attacker to scan for IPv6 addresses by guessing the Teredo client's IPv4 address and port (which, for many NATs, is not randomized) 😭 For this reason, popular implementations (e.g., Windows) started deviating from the standard by including 12 random bits in place of zero bits. This modification was later standardized in [RFC5991] 🫶
Some other transition technologies (e.g., [RFC5214], [RFC6052]) specify ways to generate an IPv6 address from an underlying IPv4 address without a port. Those mechanisms make it much easier for an attacker to conduct an address scan than mechanisms that require finding a port number as well 👀
Finally, still other mechanisms (e.g., [RFC7596], [RFC7597], [RFC7599]) sit somewhere in between, using an IPv4 address and a port set ID (which, for many NATs, is not randomized). In general, these are typically as easy to scan as the Teredo example above without the 12-bit mitigation 🍓
5. Miscellaneous Issues with IPv6 Addressing 🌈
5.1. Network Operation 🧚
It's generally agreed that IPv6 addresses which vary over time on a specific IPv6 link tend to make event logging, trouble-shooting, enforcement of access controls and quality of service, etc. more complicated 😵💫 As a result, some organizations disable temporary addresses [RFC4941] even at the expense of reduced privacy [Broersma].
5.2. Compliance 💅
Some IPv6 compliance testing suites required (and might still require) implementations to support IEEE-identifier-based IIDs in order to be approved as compliant. This document recommends that compliance testing suites be relaxed to allow other forms of address generation that are more amenable to privacy 🫶
5.3. Intellectual Property Rights (IPRs) ⭐
Some IPv6 addressing techniques might be covered by Intellectual Property rights, which might limit their implementation in different operating systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on CGAs 👑
6. Security Considerations 💀
This whole document concerns the privacy and security properties of different IPv6 address generation mechanisms. Bestie, this is the entire vibe, and it's serious business 😭🔥
7. References 📚
7.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
Security Updates", RFC 5991, DOI 10.17487/RFC5991,
September 2010, <http://www.rfc-editor.org/info/rfc5991>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.7.2. Informative References 📚
Okay bestie, these are the extra reads that back up the story. They're not required to implement anything, but they're the receipts 🧾✨
[Broersma] Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6-enabled environment", Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010, http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf.
[CGA-IPR] IETF, "IPR Details: Microsoft's Statement about IPR claimed in RFC 3972", November 2005, https://datatracker.ietf.org/ipr/676/.
[DHCPv6-IID] Gont, F. and W. Liu, "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress, draft-ietf-dhc-stable-privacy-addresses-02, April 2015.
[KAME-CGA] The KAME Project, "The KAME IPR policy and concerns of some technologies which have IPR claims", November 2005, http://www.kame.net/newsletter/20040525/.
[Microsoft] Microsoft, "IPv6 interface identifiers", 2013, http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true.
[Panopticlick] Electronic Frontier Foundation, "Panopticlick", 2011, http://panopticlick.eff.org.
[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August 1996, http://www.rfc-editor.org/info/rfc1971.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, DOI 10.17487/RFC1972, August 1996, http://www.rfc-editor.org/info/rfc1972.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, DOI 10.17487/RFC3041, January 2001, http://www.rfc-editor.org/info/rfc3041.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, http://www.rfc-editor.org/info/rfc3261.
[RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, DOI 10.17487/RFC3314, September 2002, http://www.rfc-editor.org/info/rfc3314.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, February 2003, http://www.rfc-editor.org/info/rfc3484.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, http://www.rfc-editor.org/info/rfc5214.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, http://www.rfc-editor.org/info/rfc6052.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, http://www.rfc-editor.org/info/rfc6265.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, http://www.rfc-editor.org/info/rfc6973.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, http://www.rfc-editor.org/info/rfc7421.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, http://www.rfc-editor.org/info/rfc7596.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, http://www.rfc-editor.org/info/rfc7597.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, http://www.rfc-editor.org/info/rfc7599.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, http://www.rfc-editor.org/info/rfc7707.
Acknowledgements 💜
The authors want to give a huge thank you 🫶 to Bernard Aboba, Brian Carpenter, Tim Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz, Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt. They gave super valuable comments on earlier draft versions of this document, and we are so grateful 🌸
Authors' Addresses 🎀
Alissa Cooper
Cisco
707 Tasman Drive
Milpitas, CA 95035
United States
Phone: +1-408-902-3950
Email: alcoop@cisco.com
URI: https://www.cisco.com/Fernando Gont
Huawei Technologies
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.comDave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
United States
Phone: +1 425 703 8835
Email: dthaler@microsoft.comThat's the whole spec, bestie! 🌈👑 Go build something iconic 💅✨
📦 where this page comes from
- ietf: rfc7721 2016-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms