RFC 4941

Privacy Extensions for Stateless Address Autoconfiguration in IPv6

📅 published September 2007, from ietf

RFC 4941 🎀 Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Okay bestie, this is RFC 4941 💅 It's a Standards Track doc from September 2007, written by T. Narten (IBM Corporation), R. Draves (Microsoft Research), and S. Krishnan (Ericsson Research). It obsoletes RFC 3041, so this one is the replacement 🦋 There's no Updates line in the header, so it doesn't update anything else.

Status of This Memo ✨

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

Abstract 🌸

Nodes use IPv6 stateless address autoconfiguration to make their addresses from a mix of local info and info that routers advertise. Addresses are built by sticking a network prefix together with an interface identifier. On an interface with an embedded IEEE Identifier, the interface identifier is usually derived from it. On other interface types, the interface identifier is made some other way, like random number generation. This doc describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier comes from an IEEE identifier. Using the extension makes nodes generate global scope addresses from interface identifiers that change over time, even when the interface has an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses made from it) over time makes it harder for eavesdroppers and other info collectors to figure out when different addresses used in different transactions actually belong to the same node 🕵️‍♀️🚫

Table of Contents 🧚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
     1.2.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  4
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Extended Use of the Same Identifier  . . . . . . . . . . .  5
     2.2.  Address Usage in IPv4 Today  . . . . . . . . . . . . . . .  6
     2.3.  The Concern with IPv6 Addresses  . . . . . . . . . . . . .  7
     2.4.  Possible Approaches  . . . . . . . . . . . . . . . . . . .  8
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Generation of Randomized Interface Identifiers . . . . . . 10
       3.2.1.  When Stable Storage Is Present . . . . . . . . . . . . 11
       3.2.2.  In The Absence of Stable Storage . . . . . . . . . . . 12
       3.2.3.  Alternate Approaches . . . . . . . . . . . . . . . . . 12
     3.3.  Generating Temporary Addresses . . . . . . . . . . . . . . 13
     3.4.  Expiration of Temporary Addresses  . . . . . . . . . . . . 14
     3.5.  Regeneration of Randomized Interface Identifiers . . . . . 15
     3.6.  Deployment Considerations  . . . . . . . . . . . . . . . . 16
   4.  Implications of Changing Interface Identifiers . . . . . . . . 17
   5.  Defined Constants  . . . . . . . . . . . . . . . . . . . . . . 18
   6.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Significant Changes from RFC 3041  . . . . . . . . . . . . . . 19
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20

1. Introduction ✨

Okay so, stateless address autoconfiguration [ADDRCONF] is how an IPv6 node makes its addresses without needing a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server 🙌 Some network interfaces come with an embedded IEEE Identifier (aka a link-layer MAC address), and when that happens, stateless autoconfiguration uses the IEEE identifier to make a 64-bit interface identifier [ADDRARCH]. By design, an interface identifier made this way is likely to be globally unique. That interface identifier gets appended to a prefix to form a 128-bit IPv6 address. Also, an IPv6 identifier doesn't have to be 64 bits, but the algorithm in this doc is aimed at 64-bit interface identifiers 🍓

All nodes combine interface identifiers (whether they come from an IEEE identifier or from some other technique) with the reserved link-local prefix to make link-local addresses for their attached interfaces. More addresses can then be made by combining prefixes advertised in Router Advertisements via Neighbor Discovery [DISCOVERY] with the interface identifier 💅

Not every node and interface has an IEEE identifier. In those cases, the interface identifier is made some other way (like at random), and it might not be globally unique and might change over time. This doc focuses on addresses derived from IEEE identifiers, because tracking individual devices (the concern we're fixing here) is only possible when the interface identifier is globally unique and doesn't change. The rest of this doc assumes IEEE identifiers are being used, but the techniques can also apply to interfaces with other kinds of globally unique and/or persistent identifiers 🦋

This doc talks about the problems with embedding non-changing interface identifiers inside IPv6 addresses, and describes extensions to stateless address autoconfiguration that can help with those problems, both for individual users and in environments where the concerns are serious 🔥 Section 2 gives background on the issue. Section 3 describes a procedure for generating alternate interface identifiers and global scope addresses. Section 4 discusses the implications of changing interface identifiers. The term "global scope addresses" is used here to collectively mean "Global unicast addresses" as defined in [ADDRARCH] and "Unique local addresses" as defined in [ULA] 🌈

1.1. Conventions Used in This Document 🎀

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]. 🙈

1.2. Problem Statement 💖

Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, and that identifier stays constant over time. Anytime a fixed identifier gets used in multiple contexts, it becomes possible to correlate activity that looks totally unrelated, using that identifier 👀

The correlation can be done by:

  • An attacker who is in the path between the node in question and the peer(s) it's communicating with, and who can view the IPv6 addresses present in the datagrams.
  • An attacker who can access the communication logs of the peers with which the node has communicated.

Since the identifier is embedded in the IPv6 address, which is a fundamental requirement of communication, it can't be easily hidden 😭 This doc proposes a fix for this by generating interface identifiers that vary over time 🦋

Also, note that an on-path attacker may be able to do significant correlation based on:

  • The payload contents of the packets on the wire
  • The characteristics of the packets, such as packet size and timing

Using temporary addresses will not prevent that payload-based correlation 💀

2. Background 🌸

This section gets into the problem in more detail, gives context for judging how much the concerns matter in specific environments, and compares things to existing practices 📚

2.1. Extended Use of the Same Identifier 🧚

Using a non-changing interface identifier to form addresses is a specific instance of a bigger pattern: a constant identifier that gets reused over a long period of time and across multiple independent activities. Anytime the same identifier shows up in multiple contexts, it becomes possible to use it to correlate activity that seems unrelated 🕵️‍♀️ For example, a network sniffer placed strategically on a link that all traffic to/from a particular host crosses could keep track of which destinations a node talked to, and when. In some cases that info can be used to infer things like what hours an employee was active, or when someone is at home, etc. 😳 You might think changing an address regularly in these environments would help privacy, and it would be nice, but note that the network prefix part of an address also works as a constant identifier. All nodes at, say, a home would have the same network prefix, which identifies the topological location of those nodes. That has privacy implications too, just not at the same granularity as the concern this doc addresses. Specifically, all nodes within a home could be grouped together for information collection. And if the network has a very small number of nodes, say just one, changing only the interface identifier won't enhance privacy at all, since the prefix still works as a constant identifier 🙃

One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that's recognizable over time within different contexts. IP addresses are one obvious example, but there are more. Lots of nodes also have DNS names associated with their addresses, and in that case the DNS name works as a similar identifier 📛 Getting the DNS name tied to an address takes more work (it may require a DNS query), but the info is often easy to find anyway. In those cases, changing the address on a machine over time would do little to address the concerns raised in this doc, unless the DNS name is changed as well (see Section 4) 🙈

Web browsers and servers typically swap "cookies" with each other [COOKIES]. Cookies let Web servers connect a current activity to a previous activity. A common use is sending back targeted advertising to a user, by using the cookie the browser supplied to figure out what earlier queries had been made (for example, what type of information they wanted). Based on those earlier queries, ads can be targeted to match the (assumed) interests of the end user 🛍️

The use of a constant identifier within an address is a special concern because addresses are a fundamental requirement of communication, and they can't easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, the addresses in packet headers show up in the clear 😤 So if a mobile host (e.g., a laptop) accessed the network from several different locations, an eavesdropper might be able to track that mobile host as it moved from place to place, even if the upper layer payloads were encrypted 🚶‍♀️💨

2.2. Address Usage in IPv4 Today ✨

okay so addresses on today's Internet are often basically non-changing for super long stretches 🫶 more and more sites are giving addresses out statically, and those addresses change pretty rarely. over the last few years, sites have been moving from static to dynamic allocation through DHCP [DHCP]. in theory the address a client gets from DHCP can change over time, but in practice servers often hand the same address back to the same client 🌸 (unless addresses are so scarce that a different node grabs them the second they're freed). so even in DHCP sites, clients frequently keep the same address for weeks to months at a time 💅

home users on dial-up are a whole different situation 🎀 they don't have permanent connections, and they're often given a temporary address every time they connect to their ISP. so those addresses change constantly and get shared between a bunch of different users. bottom line: an address does not reliably identify a particular device over time spans of more than a few minutes 😭

a more interesting case is always-on connections (e.g., cable modems, ISDN, DSL, etc.) 🦋 these let a home site use the same address for extended periods. it's just starting to become common in IPv4, and it's going to be more of a concern as always-on Internet connectivity becomes widely available 👑

last thing: nodes that need a (non-changing) DNS name usually get static addresses, because that makes DNS servers easier to configure 🧚 dynamic DNS [DDNS] can update DNS on the fly, but it may not always be available depending on administrative policy. and changing an address while keeping the same DNS name doesn't really fix the underlying concern, since the DNS name itself becomes the non-changing identifier 🙈 servers generally need a DNS name so clients can connect to them, and clients often need one too. (some servers refuse to talk to a client whose address can't be mapped to a DNS name that also maps back to that same address, which is so extra 💀) Section 4 describes one approach to this issue 💜

2.3. The Concern with IPv6 Addresses 🦋

okay this one is new to IPv6 and it's giving main character energy 💅 IPv6 addresses are split into a topology portion and an interface identifier portion. that means a fixed part of the address (the interface identifier) can hold an identifier that stays constant even when the topology portion changes, like when you connect to a different part of the Internet 🌈 in IPv4, when an address changes, the whole thing changes, including the local part. this new issue is exactly what this document is here to address ✨

if addresses are generated from an interface identifier, a home user's address could carry an interface identifier that stays the same from one dial-up session to the next, even while the rest of the address changes 🫶 the way PPP is used today, though, PPP servers usually tell the client exactly what address to use (the client doesn't generate one on its own). if that practice carried over into IPv6, it would avoid the concerns this document is focused on 🌸

a more troubling case is mobile devices (e.g., laptops, PDAs, etc.) that move around the Internet topologically 😭 every time they move, they form new addresses for their current point of attachment. this is typified by the "road warrior" who has Internet connectivity both at home and at the office 💼 the address changes as the node moves, but the interface identifier inside it stays the same (when it's derived from an IEEE Identifier). so the interface identifier can be used to track the movement and usage of a particular machine 👀 for example, a server that logs usage information along with source addresses is also recording the interface identifier, since it's embedded in the address. that means any data-mining technique that correlates activity by address could easily be extended to do the same using the interface identifier 🔥 this is a big deal with the expected flood of next-generation network-connected devices (e.g., PDAs, cell phones, etc.), where large numbers of devices are, in practice, tied to individual users (i.e., not shared) 📱 so the interface identifier inside an address could be used to track an individual's activities, even as they move around the Internet 🧚

in summary: IPv6 addresses on a given interface generated via Stateless Autoconfiguration contain the same interface identifier, no matter where in the Internet the device connects 🎀 that makes it easy to track individual devices (and, potentially, users) 😬 the purpose of this document is to define mechanisms that eliminate this issue in the situations where it's a concern 💖

2.4. Possible Approaches 🌈

one way to avoid having a static, non-changing address is to use DHCPv6 [DHCPV6] to obtain addresses 💅 Section 12 of [DHCPV6] talks about using DHCPv6 to assign and manage "temporary addresses", which are never renewed and give the same temporary-address property this document describes when it comes to the privacy concern 🫶

another approach, compatible with the stateless address autoconfiguration architecture, would be to change the interface identifier portion of an address over time and generate new addresses from that interface identifier for some address scopes 🦋 changing the interface identifier makes it harder to look at IP addresses from independent transactions and figure out which ones actually belong to the same node, both when the routing prefix portion of an address changes and when it doesn't 👀

many machines act as both clients and servers 🎀 in that case, the machine would need a DNS name for its server role. whether the address stays fixed or changes has little privacy impact, since the DNS name stays constant and works as a constant identifier 💜 when acting as a client (e.g., initiating communication), though, such a machine may want to vary the addresses it uses 🌸 so in these environments, one may need multiple addresses: a "public" (i.e., non-secret) server address, registered in the DNS and used to accept incoming connection requests from other machines, and a "temporary" address used to shield the identity of the client when it starts communicating 🔐 it's kind of like telephone numbers and caller ID 📞 a user might list their number in the public phone book, but turn off the display of their number on caller ID when they make calls 💅

to make it hard to make educated guesses about whether two different interface identifiers belong to the same node, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities collecting information 🔥 picking identifiers from a pseudo-random sequence is enough, as long as an outsider examining information that's readily available or easily determinable (e.g., by examining packet contents) can't work out the specific sequence 🕵️ this document proposes generating a pseudo-random sequence of interface identifiers via an MD5 hash 🍓 periodically, the next interface identifier in the sequence is generated, a new set of temporary addresses is created, and the previous temporary addresses are deprecated to discourage their further use 🌈 the precise pseudo-random sequence depends on both a random component and the globally unique interface identifier (when available), which makes it more likely that different nodes generate different sequences ✨

3. Protocol Description ✨

okay the goal of this section is to define procedures that:

  1. Do not result in any changes to the basic behavior of addresses generated via stateless address autoconfiguration [ADDRCONF] 💖
  2. Create additional addresses based on a random interface identifier for the purpose of initiating outgoing sessions 🦋 these "random" or temporary addresses would be used for a short period of time (hours to days) and would then be deprecated. deprecated addresses can keep being used for already established connections, but they aren't used to initiate new connections 🙅‍♀️ new temporary addresses are generated periodically to replace temporary addresses that expire, and the exact time between address generations is a matter of local policy ⏰
  3. Produce a sequence of temporary global scope addresses from a sequence of interface identifiers that look random, in the sense that it's hard for an outside observer to predict a future address (or identifier) from a current one, and hard to figure out previous addresses (or identifiers) knowing only the present one 🔮
  4. By default, generate a set of addresses from the same (randomized) interface identifier, one address for each prefix for which a global address has been generated via stateless address autoconfiguration 🧚 using the same interface identifier to generate a set of temporary addresses reduces the number of IP multicast groups a host must join 🌸 nodes join the solicited-node multicast address for each unicast address they support, and solicited-node addresses depend only on the low-order bits of the corresponding address. this default behavior was designed to address the concern that a node joining a large number of multicast groups might be required to put its interface into promiscuous mode, which could reduce performance 📉

a node highly concerned about privacy MAY use different interface identifiers on different prefixes, which results in a set of global addresses that can't be easily tied to each other 🫣 for example, a node MAY create different interface identifiers I1, I2, and I3 for use with different prefixes P1, P2, and P3 on the same interface 💜

3.1. Assumptions ✨

Okay so this algorithm assumes every interface has its own randomized interface identifier hanging around 🦋. When it's time to make temporary addresses, it grabs whatever the current value is. One identifier can be used to make more than one temporary address, but the value SHOULD change over time, as described in Section 3.5 💜.

The algorithm also assumes that, for any given temporary address, the implementation can tell which prefix it was generated from 🧚. When a temporary address gets deprecated, a new one is made, and its lifetimes depend on the lifetime values set for that original prefix 🌸.

Finally, this document assumes that when a node starts outgoing communication, temporary addresses can get priority over public addresses if the device is set up to do that 💅. [ADDR_SELECT] basically requires implementations to offer a way for an application to choose whether it prefers temporary addresses or public ones. It also lets an implementation prefer temporary addresses by default, so connections the node starts can use them without any app-specific setup ✨. This document also assumes there will be an API that lets individual applications say whether they want temporary or public addresses, overriding the system defaults 🎀.

3.2. Generation of Randomized Interface Identifiers

Two approaches are covered here for generating and maintaining the randomized interface identifier 🦋. The first one assumes there's stable storage that can record state history, so the history can feed into the next run of the algorithm even across system restarts. The second one is for when stable storage isn't available and you still need to generate randomized interface identifiers without any previous state 🌈.

The random interface identifier generation algorithm in this document uses MD5 as its hash algorithm 🔥. The node MAY use another algorithm instead of MD5 to produce the random interface identifier ✨.

3.2.1. When Stable Storage Is Present

This algorithm assumes there's a 64-bit "history value" that goes into making a randomized interface identifier 💖. The very first time the system boots (out-of-the-box, basically), a random value SHOULD be generated using techniques that make the initial value hard to guess [RANDOM] 🔐. Whenever a new interface identifier is generated, the value produced by the computation gets saved as the history value for the next run 🍓.

Here's how a randomized interface identifier gets created:

  1. Take the history value from the previous run of this algorithm (or a random value if there isn't a previous one) and tack on the interface identifier generated as described in [ADDRARCH] 🧩.
  2. Compute the MD5 message digest [MD5] over what you made in the previous step 🔥.
  3. Take the leftmost 64 bits of the MD5 digest and set bit 6 to zero (the leftmost bit is numbered 0) 💅. This makes an interface identifier that only has local significance, thanks to the universal/local bit 🌸.
  4. Compare the generated identifier against a list of reserved interface identifiers, and also against any already assigned to an address on the local device 👀. If the identifier you made isn't acceptable, the node MUST restart the process at step 1 above, but this time it uses the rightmost 64 bits of the MD5 digest from step 2 in place of the history value 😭.
  5. Save the generated identifier as the associated randomized interface identifier 💜.
  6. Take the rightmost 64 bits of the MD5 digest computed in step 2) and save them in stable storage as the history value for the next run of the algorithm 🦋.

MD5 was picked for convenience, and because its properties were good enough to get the level of randomization we wanted 💅. The node MAY use another algorithm instead of MD5 to produce the random interface identifier.

In theory, making successive randomized interface identifiers with a history scheme like this has no advantage over just generating them at random 🤔. In practice though, generating truly random numbers can be tricky 🙈. The history value is there to avoid one particular disaster: two nodes generate the same randomized interface identifier, both detect it via DAD, and then they both go on to generate identical identifiers through the same flawed random number generator 💀. This algorithm dodges that by having the interface identifier (which is often globally unique) feed into the calculation that makes the next ones 🫶. So if two nodes happen to generate the same randomized interface identifier, they should generate different ones on the follow-up attempt ✨.

3.2.2. In The Absence of Stable Storage

Without stable storage, there's no history value to carry across system restarts for building a pseudo-random sequence of interface identifiers 🥺. So the initial history value used above SHOULD be generated at random 🎲. There are a bunch of techniques that could work, and [RANDOM] has suggestions for good sources of random numbers 📚.

Here's the thing though: even if machines don't have stable storage for a history value, they usually have configuration information that differs from one machine to the next, like user identity, security keys, serial numbers, and so on 🧸. One way to make a random initial history value in that situation is to use the configuration information to generate some data bits (these might stay constant for the life of the machine, but they'll vary from one machine to another), add some random data, and then compute the MD5 digest like before 🌈.

3.2.3. Alternate Approaches

There are other ways to generate random interface identifiers too, just with different goals and where they fit 🦋. One of them is Cryptographically Generated Addresses (CGAs) [CGA], which make a random interface identifier based on the node's public key 🔑. CGAs are about proving you own an address and stopping people from spoofing or stealing existing IPv6 addresses 🛡️. They're used for securing neighbor discovery with [SEND] 🫶. But the CGA random interface identifier generation algorithm might not be a good fit for privacy addresses, because of these properties:

  • It requires the node to have a public key. That means the node can still be identified by its public key 👀.
  • The random interface identifier process is computationally intensive, so it discourages frequent regeneration 🐢.

3.3. Generating Temporary Addresses

[ADDRCONF] explains the steps for generating a link-local address when an interface gets enabled, plus the steps for generating addresses for other scopes 📖. This document extends [ADDRCONF] like so 💅. When a Router Advertisement comes in with a Prefix Information option carrying a global scope prefix for address autoconfiguration (aka the A bit is set), the node MUST do the following steps ✨:

  1. Process the Prefix Information Option as defined in [ADDRCONF] 📬. Either you create a new public address or you adjust the lifetimes of existing addresses, public and temporary both. If a received option will extend the lifetime of a public address, the lifetimes of temporary addresses should be extended too, as long as no temporary address ever stays "valid" or "preferred" for longer than (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively 🕰️. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME are approximate target lifetimes for temporary addresses 🎯.
  2. One way an implementation can meet those constraints is to give each temporary address a creation time (called CREATION_TIME) that records when the address was made 📅. When updating the preferred lifetime of an existing temporary address, it gets set to expire at whichever is earlier: the time from the received lifetime, or (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) ⏳. A similar approach can work for the valid lifetime too 💖.
  3. When a new public address is created as described in [ADDRCONF], the node SHOULD also create a new temporary address 🦋.
  4. When creating a temporary address, the lifetime values MUST be derived from the corresponding prefix, like this 🧮:
    • Its Valid Lifetime is the lower of the Valid Lifetime of the public address or TEMP_VALID_LIFETIME.
    • Its Preferred Lifetime is the lower of the Preferred Lifetime of the public address or TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.
  5. A temporary address is only created if this calculated Preferred Lifetime is greater than REGEN_ADVANCE time units 🙌. In particular, an implementation MUST NOT create a temporary address with a zero Preferred Lifetime 🚫.
  6. New temporary addresses MUST be created by appending the interface's current randomized interface identifier to the prefix that was received 🧩.
  7. The node MUST perform duplicate address detection (DAD) on the generated temporary address 🔍. If DAD says the address is already in use, the node MUST generate a new randomized interface identifier as described in Section 3.2 above, then repeat the earlier steps as appropriate, up to TEMP_IDGEN_RETRIES times 🔁. If after TEMP_IDGEN_RETRIES consecutive attempts no non-unique address was generated, the node MUST log a system error and MUST NOT attempt to generate temporary addresses for that interface 😭. Note that DAD MUST be performed on every unicast address generated from this randomized interface identifier 💅.

3.4. Expiration of Temporary Addresses

When a temporary address becomes deprecated, a new one MUST be generated 🦋. To do that, you repeat the actions from Section 3.3, starting at step 3) 🔁. Except for the brief moment when a temporary address is being regenerated, in normal operation at most one temporary address per prefix should be in a non-deprecated state at any given time on a given interface ✨.

Note that if a temporary address gets deprecated because of processing a Prefix Information Option with a zero Preferred Lifetime, then a new temporary address MUST NOT be generated 🚫. To make sure a preferred temporary address is always around, a new temporary address SHOULD be regenerated slightly before its predecessor is deprecated 💖. This gives enough time to avoid race conditions when making a new temporary address isn't instant, like when duplicate address detection has to run 🏃. The node SHOULD start the address regeneration process REGEN_ADVANCE time units before a temporary address would actually be deprecated ⏰.

As an optional optimization, an implementation MAY remove a deprecated temporary address that isn't in use by applications or upper layers, as detailed in Section 6 🧹.

3.5. Regeneration of Randomized Interface Identifiers 🦋

okay so how often should a temp address change? 🤔 it depends on how the device gets used (like how often it starts new conversations) and what the end user is worried about. the most egregious privacy concerns are for addresses that stick around for weeks, months, or even years 😭. the more often an address changes, the harder it gets to collect and link info keyed on interface identifiers. and that collecting and correlating is only worth the effort if enough addresses have identifiers that don't change. so having lots of clients switch addresses daily or weekly is probably enough to fix most privacy issues 💅

there are client costs too, though 🥲 a node with a bunch of addresses has more address lookups to do and needs to join lots of multicast groups, and stuff like that. so changing addresses super frequently (like every few minutes) might mess with performance.

okay now the important part 👑 nodes following this specification SHOULD generate new temporary addresses on a periodic basis. this can happen automatically by generating a new randomized interface identifier at least once every (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. generating a new temp address REGEN_ADVANCE time units before a temp address becomes deprecated gives addresses with a preferred lifetime no larger than TEMP_PREFERRED_LIFETIME ✨. DESYNC_FACTOR is a random value (different for each client) so clients don't all regenerate at exactly the same time. when the preferred lifetime expires, a new temp address MUST be generated using the new randomized interface identifier 🔥

since the right frequency is different in every environment, implementations SHOULD give end users a way to change how often addresses get regenerated. the default is TEMP_PREFERRED_LIFETIME, which is one day. also, the exact time to invalidate a temp address depends on how end users actually use their apps, so the suggested default of one week (TEMP_VALID_LIFETIME) might not be right everywhere 🙈 implementations SHOULD let end users override both of these defaults.

last one: when an interface connects to a new link, a new randomized interface identifier SHOULD be generated right away, along with a new set of temp addresses 🧚 if a device moves from one ethernet to another, generating the new set from a different randomized identifier means the device uses different identifiers for the temp addresses on the two links. that makes it way harder to correlate addresses from the two links as coming from the same node 🕵️‍♀️ the node MAY follow any process available to it to figure out that the link changed. one such process is described by Detecting Network Attachment [DNA].

3.6. Deployment Considerations 🎀

devices implementing this specification MUST provide a way for the end user to explicitly enable or disable temp addresses. also, a site might want to turn temp addresses off to make network debugging and operations easier. so implementations SHOULD provide a way for trusted system administrators to enable or disable temp addresses 🫶

sites might also want to turn temp addresses on or off for only some prefixes 🌈 for example, a site might disable temp address generation for "Unique local" [ULA] prefixes while still generating them for all other global prefixes. another site might enable temp addresses only for the prefixes 2001::/16 and 2002::/16, and turn them off for every other prefix. to support this, implementations SHOULD provide a way to enable and disable temp address generation for specific prefix subranges. this per-prefix setting SHOULD override the global settings on the node for those prefix subranges. also, the per-prefix setting can be applied at any granularity, not necessarily on a per-subnet basis 🍓

temp addresses can cause weird problems with some apps 😬 as described below, some servers refuse to accept communications from clients whose IP address they can't map to a DNS name. some apps also might not behave well if a temp address expires before the app is done, or if an app opens multiple sessions but expects them all to use the same address. so the use of temp addresses SHOULD be disabled by default to keep disruptions to a minimum. individual applications that know how long their connections normally last MAY override this as appropriate 💅

one more thing 👀 if only a very small number of nodes (like, just one) use a given prefix for a long time, changing the interface identifier might not be enough for privacy, because the prefix itself acts as a constant identifier. the procedures in this document work best when the prefix is reasonably non-static or used by a fairly large number of nodes 🦋

4. Implications of Changing Interface Identifiers ✨

the IPv6 addressing architecture goes to a lot of effort to make interface identifiers globally unique wherever that's easy to do 🌸 the widespread use of temp addresses might mean a big chunk of Internet traffic isn't using addresses whose interface identifier portion is globally unique. so using the algorithms in this document may complicate providing that kind of future flexibility, if global uniqueness turns out to be necessary 🤔

privacy and keeping a network running smoothly can clash 😤 having clients use addresses that change over time makes it harder to track down and isolate operational problems. for example, when you're looking at packet traces, it can get harder to tell whether you're seeing behaviour caused by one errant machine or by a bunch of them 🙃

some servers won't grant access to clients that have no DNS name. they do a DNS PTR query to find the name, and may then also do an AAAA query on that name to check that it maps back to the address being used. so clients that aren't properly registered in the DNS might be unable to reach some services 💀 as noted earlier, a node's DNS name (if it doesn't change) works as a constant identifier too. widespread use of the extension in this document could challenge the practice of inverse-DNS-based "authentication," which has little validity even though it's widely implemented 🙄 to meet server challenges, nodes could register temp addresses in the DNS using random names (for example, a string version of the random address itself) 🧩

using the extensions in this document may complicate debugging and other operational troubleshooting. so it may be site policy that temp addresses shouldn't be used at all. because of that, implementations MUST provide a method for the end user or a trusted administrator to override the use of temp addresses 🫶

5. Defined Constants 💜

here are the constants defined in this document, bestie 📋

  • TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able to override the default value.
  • TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able to override the default value.
  • REGEN_ADVANCE -- 5 seconds
  • MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
  • DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR. It is computed once at system start (rather than each time it is used) and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
  • TEMP_IDGEN_RETRIES -- Default value: 3

6. Future Work 🔮

an implementation might want to keep track of which addresses upper layers are using, so it can remove a deprecated temp address from its internal data structures once no upper layer protocols are using it (but not before) ✨ that's different from current approaches, where addresses get removed from an interface when they become invalid [ADDRCONF], no matter whether upper layer protocols are still using them. for TCP connections, that info is available in control blocks. for UDP-based apps, maybe only the apps know which addresses are actually in use. so an implementation will generally need to use heuristics to decide when an address is no longer in use 🧠

sometimes only an application can decide whether to use a public or a temp address 💅 for example, some apps may always want temp addresses, while others want them only in some situations or not at all. suitable API extensions will likely need to be developed so individual apps can say what they need around temp addresses with enough granularity 🙌 recommendations on DNS practices to avoid the problem described in Section 4 when reverse DNS lookups fail may be needed too. [DNSOP] has a more detailed discussion of the DNS-related issues 📚

while this document talks about ways to hide a user's permanent IP address, the method described is believed to be ineffective against sophisticated forms of traffic analysis 😬 to level up the effectiveness, one may need to look at more advanced techniques, like Onion Routing [ONION] 🧅

7. Security Considerations 🚨

ingress filtering has been deployed, and is still being deployed, to stop spoofed source addresses from being used in Distributed Denial of Service (DDoS) attacks 🛡️ in a network with a large number of nodes, new temp addresses get created at a pretty high rate. this could make it hard for ingress filtering mechanisms to tell apart legit changing temp addresses from spoofed source addresses that are "in-prefix" (using a topologically correct prefix with a non-existent interface ID) 😱 this can be handled by using access control on a per-address basis at the network egress point 🔒

8. Significant Changes from RFC 3041 📝✨

okay bestie, this is the changelog 🧾 if you implemented RFC 3041, these are the things you NEED to know about:

  1. Excluded certain interface identifiers from the range of acceptable interface identifiers. Interface IDs such as those for reserved anycast addresses [RFC2526], etc. 🚫
  2. Added a configuration knob that lets the end user turn temporary addresses on or off on a per-prefix basis. 🎛️
  3. Added a check for denial of service attacks that use low valid lifetimes in router advertisements. 🛡️
  4. DAD is now run on all temporary addresses, not just the first one generated from an interface identifier. 🔍
  5. Changed the default setting for temporary addresses so they're disabled. 🙅‍♀️
  6. The node is now allowed to generate different interface identifiers for different prefixes, if it so desires. 🧩
  7. The algorithm used for generating random interface identifiers is no longer restricted to just MD5. 🎲
  8. Reduced the default number of retries to 3 and added a configuration variable for it. 🔁
  9. Router advertisement (RA) processing algorithm is no longer included in the document, and is replaced by a reference to [ADDRCONF]. 📎

9. Acknowledgments 🫶

Rich Draves and Thomas Narten were the authors of RFC 3041, and they wanted to shoutout the ipv6 working group, especially Ran Atkinson, Matt Crawford, Steve Deering, Allison Mankin, and Peter Bieringer. 🌸

Suresh Krishnan was the sole author of this version of the document. He wanted to thank the ipv6 working group too, especially Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their super detailed comments. 💜 the people who read every single word are the real MVPs 👑

10. References 📚

10.1. Normative References 💖

[ADDRARCH]     Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.

[ADDRCONF]     Thomson, S., Narten, T., and T. Jinmei, "IPv6
               Stateless Address Autoconfiguration", RFC 4862,
               September 2007.

[DISCOVERY]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
               "Neighbor Discovery for IP version 6 (IPv6)",
               RFC 4861, September 2007.

[MD5]          Rivest, R., "The MD5 Message-Digest Algorithm",
               RFC 1321, April 1992.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.

10.2. Informative References 🦋

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

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

[COOKIES]      Kristol, D. and L. Montulli, "HTTP State Management
               Mechanism", RFC 2965, October 2000.

[DDNS]         Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS
               UPDATE)", RFC 2136, April 1997.

[DHCP]         Droms, R., "Dynamic Host Configuration Protocol",
               RFC 2131, March 1997.

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

[DNA]          Choi, JH. and G. Daley, "Goals of Detecting Network
               Attachment in IPv6", RFC 4135, August 2005.

[DNSOP]        Durand, A., Ihren, J., and P. Savola, "Operational
               Considerations and Issues with IPv6 DNS", RFC 4472,
               April 2006.

[ONION]        Reed, MGR., Syverson, PFS., and DMG. Goldschlag,
               "Proxies for Anonymous Routing",  Proceedings of the
               12th Annual Computer Security Applications Conference,
               San Diego, CA, December 1996.

[RANDOM]       Eastlake, D., Schiller, J., and S. Crocker,
               "Randomness Requirements for Security", BCP 106,
               RFC 4086, June 2005.

[RFC2526]      Johnson, D. and S. Deering, "Reserved IPv6 Subnet
               Anycast Addresses", RFC 2526, March 1999.

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

[ULA]          Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC 4193, October 2005.

Authors' Addresses 🏡

Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC
USA

EMail: narten@us.ibm.com


Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA
USA

EMail: richdr@microsoft.com


Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada

EMail: suresh.krishnan@ericsson.com

Copyright (C) The IETF Trust (2007). 💌

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

The document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💅

📦 where this page comes from