RFC 7217

A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

📅 published April 2014, from ietf

RFC 7217 🎀 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

This one's by F. Gont from SI6 Networks / UTN-FRH, it's a Standards Track doc, and it dropped in April 2014 (ISSN 2070-1721). Okay, now the good stuff. 💅

Abstract ✨

okay so this doc describes a way to generate IPv6 Interface Identifiers for SLAAC 🦋 The vibe is that an address made this way stays put inside each subnet, but the Interface Identifier changes once the host moves to a different network. It's meant as the glow-up alternative to building IIDs out of hardware addresses (like IEEE LAN Media Access Control (MAC) addresses). That way you still get the perks of stable addresses without wrecking users' security and privacy 🫶 The method works for every prefix a host might be using: link-local, global, and unique-local, plus their matching addresses. 🌈

Status of This Memo 📜

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF), so it reflects IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741. 🧚

For info on this doc's current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7217. 💖

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. 🙈 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. 💀

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  Relationship to Other Standards . . . . . . . . . . . . . . .   5
4.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   6
5.  Algorithm Specification . . . . . . . . . . . . . . . . . . .   7
6.  Resolving DAD Conflicts . . . . . . . . . . . . . . . . . . .  12
7.  Specified Constants . . . . . . . . . . . . . . . . . . . . .  13
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
  10.2.  Informative References . . . . . . . . . . . . . . . . .  16
Appendix A.  Possible Sources for the Net_Iface Parameter . . . .  19
  A.1.  Interface Index . . . . . . . . . . . . . . . . . . . . .  19
  A.2.  Interface Name  . . . . . . . . . . . . . . . . . . . . .  19
  A.3.  Link-Layer Addresses  . . . . . . . . . . . . . . . . . .  19
  A.4.  Logical Network Service Identity  . . . . . . . . . . . .  20

1. Introduction 🌸

okay bestie, so [RFC4862] defines Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460]. Usually that means a host ends up with one or more "stable" addresses. Each is a network prefix from a local router plus an Interface Identifier (IID), and the IID usually embeds a hardware address (like an IEEE LAN MAC address) [RFC4291]. Then there are Cryptographically Generated Addresses (CGAs) [RFC3972], which are another way to make IIDs. CGAs tie a public signature key to an IPv6 address in the SEcure Neighbor Discovery (SEND) [RFC3971] protocol. 🔐

Traditional SLAAC addresses are generally seen as making network management easier, since they simplify Access Control Lists (ACLs) and logging. 📋 But they come with some real drawbacks: 😬

  • Because the IIDs don't change over time, they let people correlate a host's activity on the same network. That hurts user privacy (see [ADDR-GEN-PRIVACY] and [IAB-PRIVACY]). 👀
  • Because the IIDs are the same across networks, the IPv6 addresses can be used to track and correlate one host's activity across many networks. Think of a typical client hitting the public Internet from different locations. Again, privacy takes the hit. 🕵️
  • Embedding the link-layer address in the IID creates specific address patterns. Attackers can use those patterns to shrink the search space during address-scanning attacks [IPV6-RECON]. For example, all hosts made by the same vendor (within a given time frame) will likely share the same IEEE Organizationally Unique Identifier (OUI) in their IIDs. 🏭
  • Embedding the hardware address in the IID leaks device-specific info, which could be used to launch device-specific attacks. 💥
  • Embedding the link-layer address in the IID means that swapping out the interface hardware changes the IPv6 address(es) assigned to that interface. 🔄

[ADDR-GEN-PRIVACY] has more detail on how those vulnerabilities could be exploited, and how much the method in this document helps. 📚

The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] (called "temporary addresses" from here on) were built to make life harder for eavesdroppers and other information collectors. Think IPv6 addresses sitting in web server logs or email headers. 👂 They make a host's activity harder to correlate, and they basically produce temporary, random IIDs. These temporary addresses get generated alongside the traditional IPv6 addresses based on IEEE LAN MAC addresses. The temporary ones are used for "outgoing communications", and the traditional SLAAC addresses are used for "server" functions (meaning receiving incoming connections). 📤📥

Temporary addresses can be a bit of a pain, though. 😩 From a network-management angle, they make event logging, troubleshooting, enforcing access controls, and quality of service (and so on) more complicated. So some organizations turn off temporary addresses even though privacy takes a hit [BROERSMA]. Temporary addresses can also make implementation more complex, and that might not be possible or desirable on some devices (like some embedded devices). 🤖

When temporary addresses are deliberately not used (for any of the reasons above), a host is left with only the stable addresses, which have usually been generated from the underlying hardware addresses. 🫠 In that case, it's still nice to have addresses that reduce address-scanning attacks and that, at the very least, don't reveal the host's identity when it roams from one network to another. And all of that should happen without complicating how the networks run. ✨

Even with temporary addresses in place, a few issues still need fixing. Namely: 🎯

  • Since temporary addresses [RFC4941] don't get rid of fixed identifiers for server-like functions, they only partly stop host tracking and activity correlation across networks. See [ADDR-GEN-PRIVACY] for example attacks that still work with temporary addresses. 🧐
  • Since temporary addresses [RFC4941] don't replace the traditional SLAAC addresses, an attacker can still use patterns in SLAAC addresses to greatly shrink the search space for "alive" nodes [GONT-DEEPSEC2011] [CPNI-IPV6] [IPV6-RECON]. 🔍

So there's a real reason to improve "stable" addresses whether or not temporary addresses are in use. 💅

This document describes a method for generating Interface Identifiers that stay stable for each network interface within each subnet, but change when a host moves from one network to another. 🦋 That keeps the "stability" properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and stopping activity correlation as a host roams between networks. Iconic. 👑

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🌟

3. Relationship to Other Standards 🧩

The method here is orthogonal to temporary addresses [RFC4941]. It's meant to improve the security and privacy properties of the stable addresses that get used alongside those temporary addresses. 🎀 When temporary addresses are in use, implementing this mechanism (in place of stable addresses based on things like IEEE LAN MAC addresses) mitigates address-scanning attacks. It also mitigates the remaining ways to correlate host activity through the host's constant (meaning stable across networks) Interface Identifiers. 🧠 On the flip side, for hosts that currently turn off temporary addresses [RFC4941], implementing this mechanism would mitigate the host-tracking and address-scanning issues discussed in Section 1. 🛡️

This method is meant to be used with SLAAC, but that doesn't stop the algorithm from being used with other address configuration mechanisms, like DHCPv6 [RFC3315] or manual address configuration. 🍓

4. Design Goals ✨

Okay bestie, this section is all about the goals behind a method for making Interface Identifiers for IPv6 SLAAC, and they are iconic 💅

  • The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface. Basically, the algorithm makes the same Interface Identifier when it configures an address (for the same interface) that belongs to the same prefix within the same subnet 🦋
  • The resulting Interface Identifiers must change when addresses are configured for different prefixes. So if different autoconfiguration prefixes are used to configure addresses for the same network interface card, the Interface Identifiers must be (statistically) different. This means that, given two addresses made by this method, it must be difficult for an attacker to tell whether the addresses came from the same host 👀
  • It must be difficult for an outsider to predict the Interface Identifiers the algorithm will generate, even if they know the Interface Identifiers made for configuring other addresses 🔒
  • Depending on the specific implementation approach (see Section 5 and Appendix A), the resulting Interface Identifiers may be independent of the underlying hardware (for example, an IEEE LAN MAC address). So replacing a Network Interface Card (NIC) or adding links dynamically to a Link Aggregation Group (LAG) will not have the (generally undesirable) effect of changing the IPv6 addresses used for that network interface 🧚
  • This method is meant to be an alternative to producing IPv6 addresses based on hardware addresses (for example, IEEE LAN MAC addresses, as specified in [RFC2464]). To be clear, this document does not formally obsolete or deprecate any of the existing algorithms for generating Interface Identifiers. It is meant to be used for all of the stable (i.e., non-temporary) IPv6 addresses configured with SLAAC for a given interface, including global, link-local, and unique-local IPv6 addresses 💜

We note that this method is incrementally deployable, since it does not pose any interoperability implications when deployed on networks where other nodes do not implement or employ it 🌸 Also, this document does not update or modify IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] itself. It only specifies an alternative algorithm for generating Interface Identifiers. So the usual address lifetime properties (as specified in the corresponding Prefix Information Options) apply when IPv6 addresses are generated by using the algorithm in this document with SLAAC [RFC4862]. And from the point of view of renumbering, these addresses behave like the traditional IPv6 addresses (the ones that embed a hardware address) resulting from SLAAC [RFC4862] 🎀

5. Algorithm Specification ✨

Here's where it gets real. IPv6 implementations conforming to this specification MUST generate Interface Identifiers using the algorithm in this section as a replacement for any other algorithms for generating "stable" addresses with SLAAC (such as those specified in [RFC2464], [RFC2467], and [RFC2470]). However, implementations conforming to this specification MAY use the algorithm specified in [RFC4941] to generate temporary addresses in addition to the addresses generated with the algorithm in this document. The method in this document MUST be used for generating the Interface Identifiers with SLAAC for all the stable addresses, including IPv6 global, link-local, and unique-local addresses 🫶

Implementations conforming to this specification SHOULD provide the means for a system administrator to enable or disable the use of this algorithm for generating Interface Identifiers ⭐

Unless otherwise noted, all of the parameters included in the expression below MUST be included when generating an Interface Identifier 🍓

  1. Compute a random (but stable) identifier with the expression:
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

Where:

  • RID: Random (but stable) Identifier 🌈
  • F(): A pseudorandom function (PRF) that MUST NOT be computable from the outside (without knowledge of the secret key). F() MUST also be difficult to reverse, so it resists attempts to obtain the secret_key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() SHOULD produce an output of at least 64 bits. F() could be implemented as a cryptographic hash of the concatenation of each of the function parameters. SHA-1 [FIPS-SHS] and SHA-256 are two possible options for F(). Note: MD5 [RFC1321] is considered unacceptable for F() [RFC6151] 💀
  • Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message, or the link-local IPv6 unicast prefix [RFC4291] 🌸
  • Net_Iface: An implementation-dependent stable identifier associated with the network interface for which the RID is being generated. An implementation MAY provide a configuration option to select the source of the identifier used for the Net_Iface parameter. A discussion of possible sources for this value (along with the corresponding trade-offs) can be found in Appendix A 🔥
  • Network_ID: Some network-specific data that identifies the subnet this interface is attached to. For example, the IEEE 802.11 Service Set Identifier (SSID) corresponding to the network this interface is associated with. Additionally, Simple DNA [RFC6059] describes ideas that could be leveraged to generate a Network_ID parameter. This parameter is OPTIONAL ✨
  • DAD_Counter: A counter used to resolve Duplicate Address Detection (DAD) conflicts. It MUST be initialized to 0, and incremented by 1 for each new tentative address configured as a result of a DAD conflict. Implementations that record DAD_Counter in non-volatile memory for each {Prefix, Net_Iface, Network_ID} tuple MUST initialize DAD_Counter to the recorded value if such an entry exists in non-volatile memory. See Section 6 for additional details 🦋
  • secret_key: A secret key that is not known by the attacker. The secret key SHOULD be at least 128 bits long. It MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the operating system is installed or when the IPv6 protocol stack is "bootstrapped" for the first time. An implementation MAY provide the means for the system administrator to display and change the secret key 🔑
  1. The Interface Identifier is finally obtained by taking as many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit.

We note that [RFC4291] requires that the Interface IDs of all unicast addresses (except those that start with the binary value 000) be 64 bits long. However, the method in this document could be used for generating Interface IDs of any arbitrary length, though with reduced entropy when the Interface IDs are smaller than 64 bits 🧠

The resulting Interface Identifier SHOULD be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID], and against those Interface Identifiers already used in an address of the same network interface and the same network prefix. If an unacceptable identifier has been generated, this situation SHOULD be handled the same way as the case of duplicate addresses (see Section 6) 🙈

This document does not require the use of any specific PRF for the function F() above. The choice of PRF is usually a trade-off between a number of properties (processing requirements, ease of implementation, possible intellectual property rights, etc.). Also, the best possible choice for F() might be different for different types of devices (for example, embedded systems vs. regular servers) and might change over time 💅

Including the SLAAC prefix in the PRF computation causes the Interface Identifier to vary across each prefix (link-local, global, etc.) employed by the host and, consequently, also across networks. This mitigates the correlation of activities of multihomed hosts (since each of the corresponding addresses will typically use a different prefix), host-tracking (since the network prefix changes as the host moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers (such as IPv6 address-scanning attacks) 🕵️‍♀️

The Net_Iface is a value that identifies the network interface for which an IPv6 address is being generated. The following properties are required for the Net_Iface parameter:

  • It MUST be constant across system bootstrap sequences and other network events (for example, bringing another interface up or down).
  • It MUST be different for each network interface simultaneously in use.

Since the stability of the addresses generated with this method relies on the stability of all arguments of F(), it is key that the Net_Iface parameter be constant across system bootstrap sequences and other network events. The Net_Iface parameter must also uniquely identify an interface within the host, so that two interfaces connecting to the same network don't result in duplicate addresses. Different types of operating systems might benefit from different stability properties for the Net_Iface parameter. For example, a client-oriented operating system might want Net_Iface identifiers attached to the NIC, so a removable NIC always gets the same IPv6 address, no matter which system communications port it's plugged into. On the other hand, a server-oriented operating system might prefer Net_Iface identifiers attached to system slots/ports, so replacing a NIC doesn't change the IPv6 address. Appendix A goes through possible sources for the Net_Iface along with their pros and cons 🎀

Including the optional Network_ID parameter when computing the RID value causes the algorithm to produce a different Interface Identifier when connecting to different networks, even when configuring addresses in the same prefix. This means a host would use a different Interface Identifier as it moves from one network to another, even for IPv6 link-local addresses or Unique Local Addresses (ULAs) [RFC4193]. In scenarios where the Network_ID is unknown to the attacker, including this parameter might help mitigate attacks where a victim host connects to the same subnet as the attacker, and the attacker tries to learn the Interface Identifier the victim host uses for a remote network (see Section 8 for further details) 👑

The DAD_Counter parameter is the lever for getting this algorithm to spit out different IPv6 addresses even when everything else is the same, bestie 🎀. That's handy when you need to fix a DAD conflict, which we get into properly in Section 6 💅.

Okay, real talk: the output of F() is only as secure as the secret key 😭. If an attacker knows which PRF the victim is using (and we should totally expect that), and they can collect enough addresses the victim configured, they can just brute-force the entire secret-key space to find matches. 💀 So to stay safe, key lengths of at least 128 bits should be adequate 🔐. The secret key gets set to a pseudorandom number when the system is installed, so this whole mechanism can switch on and run automatically with zero user effort ✨. Now, if you give someone a way to display and change the secret_key, an admin could make a replacement system (running the same implementation) produce the exact same IPv6 addresses as the old one 🙈. Since privacy here depends on the secret_key staying secret, implementations should lock down access to it as much as they practically can (like requiring superuser privileges) 🔒. And to stop it from leaking, the secret_key should never be used for anything other than being a parameter to the scheme in this document 🫶.

We need to talk about the bits 🦋. All the bits in the resulting Interface IDs are treated as "opaque" bits [RFC7136]. For example, the universal/local bit of Modified EUI-64 format identifiers gets treated like any other bit in there 🌈. In theory, that could cause IPv6 address collisions and DAD failures that wouldn't otherwise happen 😬. BUT it's not considered a likely issue, and here's why:

  • The interface IDs of all addresses (except those starting with the binary value 000) are 64 bits long. Since this method makes random Interface IDs, the chance of DAD failures is super tiny ✨.
  • Real-world data shows MAC address reuse is way more common than people assumed [HD-MOORE] 😭. So even addresses built from supposedly unique identifiers (like IEEE LAN MAC addresses) can cause DAD failures, which means implementations should be ready to handle that gracefully 🛠️. Also, some virtualization tech already uses randomly picked hardware addresses, so those can't be guaranteed unique [IPV6-RECON] 🎲.
  • Some popular, widely deployed operating systems (like Microsoft Windows) don't embed hardware addresses in the Interface IDs of their stable addresses 🪟. So fewer deployed systems depend on those unique identifiers to avoid collisions, which takes some pressure off 💖.

Last thing, and it's kind of a vibe check 🧚: different implementations will probably use different secret_key values, might use different PRFs for F(), and might pull Net_Iface from different sources. So the addresses generated by this scheme should not be expected to stay stable across different operating-system installations 🍓. Like, a dual-boot machine, or one that gets reinstalled, might end up with different IPv6 addresses for each OS and/or installation 💅.

6. Resolving DAD Conflicts ✨

Okay, so if a host runs DAD [RFC4862] and discovers that the tentative address made by the algorithm in Section 5 is a duplicate, it SHOULD fix the conflict by trying a new tentative address like this 🔥:

  • Increment DAD_Counter by 1.
  • Generate a new Interface Identifier with the algorithm from Section 5, using the incremented DAD_Counter value.

Hosts SHOULD add a random delay between 0 and IDGEN_DELAY seconds (see Section 7) before trying a new tentative address 🎲. This stops multiple hosts from doing everything in lockstep, which would be a total mess 🙈.

This procedure can be repeated a bunch of times until the conflict is resolved 🔁. Hosts SHOULD try at least IDGEN_RETRIES (see Section 7) tentative addresses if DAD keeps failing on successive generated addresses, hoping to finally clear the conflict 🤞. Also, hosts MUST limit how many tentative addresses they try. They should NOT just keep trying new ones forever until the conflict clears 🛑.

Now, in those rare cases where duplicates get detected AND the conflicting hosts configure their addresses in a varying order (maybe they boot up in different orders), the DAD-conflict method from this section could give addresses that aren't stable within the same subnet 😬. To help with that, hosts MAY record the DAD_Counter value used for a specific {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory 💾. That way, the same DAD_Counter value gets used when configuring an address for the same Prefix and subnet at any later point in time 🕰️. Using non-volatile memory is OPTIONAL, and hosts that skip this feature still comply with this protocol specification 🫶.

If a DAD conflict can't be solved (even after trying a number of different addresses), address configuration fails 💀. In that situation, hosts MUST NOT automatically fall back to other algorithms for generating Interface Identifiers 🚫.

7. Specified Constants 🎀

This document specifies the following constants 💜:

  • IDGEN_RETRIES: defaults to 3.
  • IDGEN_DELAY: defaults to 1 second.

8. Security Considerations 🔐

Okay, security time, and I'm not gonna sugarcoat it 😤. This document specifies an algorithm for generating Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC) 🧚. It's an alternative to things like Interface Identifiers that embed hardware addresses (such as those in [RFC2464], [RFC2467], and [RFC2470]) 🔄. Compared to those, the identifiers in this document have a few big advantages 👑:

  • They prevent trivial host-tracking based on the IPv6 address 🕵️. When a host moves from one network to another, the network prefix used for autoconfiguration and/or the Network ID (e.g., IEEE 802.11 SSID) will typically change, so the resulting Interface Identifier changes too (see [ADDR-GEN-PRIVACY]) 🏃‍♀️.
  • They mitigate address-scanning techniques that rely on predictable Interface Identifiers (e.g., known Organizationally Unique Identifiers) [IPV6-RECON] 🛡️.
  • They may result in IPv6 addresses that are independent of the underlying hardware (meaning the addresses don't change if a network interface card gets replaced), as long as an appropriate source for Net_Iface (see Section 5) is used 🪄.
  • They prevent the information leakage caused by embedding hardware addresses in the Interface Identifier, which could be exploited to launch device-specific attacks 🚨.
  • Since this method gives a different Interface Identifier for each configured address, knowing or leaking the Interface Identifier used for one stable address won't negatively affect the security/privacy of other stable addresses configured for other prefixes (whether at the same time or at some other point in time) 💅.

Now, some probing techniques (like ICMPv6 Echo Request and Echo Response packets) could be mitigated by a personal firewall on the target host 🧱. But for other probing vectors, like listening to ICMPv6 "Destination Unreachable, Address Unreachable" (Type 1, Code 3) error messages that refer to the target addresses [IPV6-RECON], there's nothing a host can do 😩. A personal firewall at the target host can't mitigate that technique. So the method in this document is still valuable for hosts that use personal firewalls 🔥.

In scenarios where an attacker can connect to the same subnet as a victim host, the attacker might learn the Interface Identifier the victim uses for an arbitrary prefix by simply sending a forged Router Advertisement [RFC4861] for that prefix 🚨. Then they can learn the corresponding address the victim configures, either by listening to the Duplicate Address Detection packets or to any other traffic that uses the newly configured address 👀.

A few factors could limit an attacker's ability to pull this off successfully 🙅‍♀️:

  • First-Hop security mechanisms such as Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113] could stop the forged Router Advertisement from reaching the victim host 🛑.
  • If the victim implementation includes the (optional) Network_ID parameter for computing F() (see Section 5), and the attacker doesn't know the Network_ID the victim uses for a remote network, then the Interface Identifier the attacker learns would differ from the one the victim uses when connecting to the legitimate network 🙌.

Anyway, once this kind of attack becomes a real concern, a host should consider employing SEND [RFC3971] to prevent an attacker from illegitimately claiming authority for a network prefix 🔐.

Also, this algorithm is meant to be an alternative to Interface Identifiers like those in [RFC2464], but it is NOT meant as an alternative to temporary Interface Identifiers (such as those in [RFC4941]) 🙅‍♀️. Temporary addresses can help mitigate the correlation of a host's activities within the same network, and they can also reduce the attack exposure window, since they're short-lived compared to addresses made with the method in this document ⏳. The implementation of this specification would still benefit hosts that use temporary addresses 🫶. It would mitigate host-tracking vectors that are still present when temporary addresses are used (see [ADDR-GEN-PRIVACY]), and it would also mitigate address-scanning techniques that exploit patterns in IPv6 addresses embedding IEEE LAN MAC addresses 🦋. Finally, this method addresses some of the privacy concerns from IPv6 addresses that embed IEEE LAN MAC addresses without needing temporary addresses at all 🌸. That makes it an interesting trade-off for scenarios where temporary addresses aren't feasible ✨.

9. Acknowledgements ✨

The algorithm in this document was inspired by Steven Bellovin's work in the area of TCP sequence numbers, which is written up in [RFC1948]. 🌸

The author would like to thank (in alphabetical order) Mikael Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim Chown, Alissa Cooper, Dominik Elsbroek, Stephen Farrell, Eric Gray, Brian Haberman, Bob Hinden, Christian Huitema, Ray Hunter, Jouni Korhonen, Suresh Krishnan, Eliot Lear, Jong-Hyouk Lee, Andrew McGregor, Thomas Narten, Simon Perreault, Tom Petch, Michael Richardson, Vincent Roca, Mark Smith, Hannes Frederic Sowa, Martin Stiemerling, Dave Thaler, Ole Troan, Lloyd Wood, James Woodyatt, and He Xuan, for giving valuable comments on earlier versions of this document. 🫶💖

Hannes Frederic Sowa wrote a reference implementation of this specification for the Linux kernel. Absolute legend behaviour 👑

Finally, the author wants to thank Nelida Garcia and Guillermo Gont for their love and support. 🥹💜

10. References 📚

10.1. Normative References

These are the must-reads, bestie. 🤓

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [RFC3971] Arkko, J., 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.
  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
  • [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
  • [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
  • [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
  • [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
  • [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009.
  • [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014.

10.2. Informative References

These ones are the extra-credit reading. 🦋

  • [ADDR-GEN-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, February 2014.
  • [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>.
  • [CPNI-IPV6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request).
  • [FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.
  • [GONT-DEEPSEC2011] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, <http://www.si6networks.com/presentations/deepsec2011/fgont-deepsec2011-ipv6-security.pdf>.
  • [HD-MOORE] Moore, HD., "The Wild West", Louisville, Kentucky, U.S.A, DerbyCon 2012, September 2012, <https://speakerdeck.com/hdm/derbycon-2012-the-wild-west>.
  • [IAB-PRIVACY] IAB, "Privacy and IPv6 Addresses", July 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt>.
  • [IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <http://www.iana.org/assignments/ipv6-interface-ids>.
  • [IPV6-RECON] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, January 2014.
  • [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
  • [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
  • [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
  • [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
  • [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
  • [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
  • [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
  • [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
  • [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014.

Appendix A. Possible Sources for the Net_Iface Parameter 🧚

The subsections below cover a few possible sources for the Net_Iface parameter that the F() function uses in Section 5. Picking a source is a bit of a balancing act, and the trade-offs can be different from one implementation to another. 💅

A.1. Interface Index

The Interface Index [RFC3493] [RFC3542] of an interface uniquely identifies that interface within the node. 🔑 Still, these identifiers might or might not have the stability properties needed for the Net_Iface value in this method. For example, the Interface Index might change when a network interface is removed or installed (usually to a smaller value, when that naming scheme is used), or when network interfaces happen to get initialized in a different order. 🙈

Some implementations are known to offer configuration knobs for setting the Interface Index of a given interface. Those knobs can be used to stop the Interface Index from changing (for example, when a network interface gets removed). 🎀

A.2. Interface Name

Interface Names (like "eth0", "em0", and so on) tend to be more stable than the Interface Index, because stability is required or desired when interface names are used in network configuration (firewall rules and that sort of thing). ✨ How stable they are depends on implementation details, such as which namespace is used for Interface Names. For example, "generic" interface names like "eth0" or "wlan0" will generally stay the same when a network interface card gets replaced. 🌈 On the other hand, vendor-dependent interface names like "rtk0" or similar will generally change when a network interface card is replaced with one from a different vendor. 🍓

We should also note that Interface Names might still change when network interfaces are added or removed after the system has booted up (think USB-based network interface cards that can be plugged in or unplugged after bootstrapping). 🔌

Link-layer addresses typically act as unique identifiers for network interfaces. 🪪 For obvious reasons though, they generally change when a network interface card is replaced. In scenarios where neither Interface Indexes nor Interface Names have the stability properties that Section 5 specifies for Net_Iface, an implementation might want to use the link-layer address of the interface for the Net_Iface parameter. 🥺 The trade-off is that the corresponding IPv6 addresses then depend on the underlying network interface card, so they would typically change when that card is replaced. 😭

A.4. Logical Network Service Identity

Some host operating systems have a concept of logical network service identity that is separate from network interface identity or index. 🌟 Those systems may keep a Universally Unique Identifier (UUID) [RFC4122] or a similar identifier, with the stability properties that suit use as the Net_Iface parameter. 💜

Author's Address 🎀

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI:   http://www.si6networks.com
📦 where this page comes from