RFC 3041

Privacy Extensions for Stateless Address Autoconfiguration in IPv6 🎀

okay bestie, this is RFC 3041 💖 It's a Standards Track doc, which means it's an actual Internet standards track protocol 🫶 It came out in January 2001 ✨ The authors are T. Narten from IBM and R. Draves from Microsoft Research 💅 It doesn't list anything it obsoletes or updates, so it's giving independent main character energy 🦋

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited 🌸

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒

Abstract

Okay so nodes use IPv6 stateless address autoconfiguration to generate addresses without needing a Dynamic Host Configuration Protocol (DHCP) server 🧚 Addresses get made by combining network prefixes with an interface identifier ✨ On interfaces that have embedded IEEE Identifiers, the interface identifier is usually derived from that IEEE Identifier. On other interface types, the interface identifier is generated some other way, like through random number generation 🎲

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived 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 way harder for eavesdroppers and other information collectors to figure out when different addresses used in different transactions actually belong to the same node 🕵️‍♀️💅

Table of Contents

1.  Introduction.............................................    2
   2.  Background...............................................    3
      2.1.  Extended Use of the Same Identifier.................    3
      2.2.  Address Usage in IPv4 Today.........................    4
      2.3.  The Concern With IPv6 Addresses.....................    5
      2.4.  Possible Approaches.................................    6
   3.  Protocol Description.....................................    7
      3.1.  Assumptions.........................................    8
      3.2.  Generation Of Randomized Interface Identifiers......    9
      3.3.  Generating Temporary Addresses......................   10
      3.4.  Expiration of Temporary Addresses...................   11
      3.5.  Regeneration of Randomized Interface Identifiers....   12
   4.  Implications of Changing Interface Identifiers...........   13
   5.  Defined Constants........................................   14
   6.  Future Work..............................................   14
   7.  Security Considerations..................................   15
   8.  Acknowledgments..........................................   15
   9.  References...............................................   15
   10. Authors' Addresses.......................................   16
   11. Full Copyright Statement.................................   17

1. Introduction ✨

Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 node generates addresses without needing a DHCP server 🎀 Some network interfaces come with an embedded IEEE Identifier (aka a link-layer MAC address), and in those cases stateless address autoconfiguration uses the IEEE identifier to generate a 64-bit interface identifier [ADDRARCH]. By design, an interface identifier made this way is likely to be globally unique 🌈 That interface identifier then gets appended to a prefix to form a 128-bit IPv6 address.

All nodes combine interface identifiers (whether they came from an IEEE identifier or from some other technique) with the reserved link-local prefix to generate link-local addresses for their attached interfaces 🔗 Then additional addresses, including site-local and global-scope addresses, get created by combining prefixes advertised in Router Advertisements via Neighbor Discovery [DISCOVERY] with the interface identifier 💖

Not all nodes and interfaces have IEEE identifiers 🙃 In those cases, the interface identifier is generated some other way (for example, at random), and the result is not globally unique and may also change over time. This document focuses on addresses derived from IEEE identifiers, because the concern being addressed only exists when the interface identifier is globally unique and non-changing 🧐 The rest of this document assumes IEEE identifiers are being used, but the techniques described may also apply to interfaces with other types of globally unique and/or persistent identifiers 🦋

This document talks about the concerns that come with embedding non-changing interface identifiers in IPv6 addresses. It also describes extensions to stateless address autoconfiguration that can help reduce those concerns for individual users, and in environments where the concerns are significant 🫶 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 💅

2. Background 📚

This section goes deeper into the problem, gives context for judging how much these concerns matter in specific environments, and compares everything with existing practices 🔍

2.1. Extended Use of the Same Identifier 🧩

Using a non-changing interface identifier to form addresses is one specific case 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 that identifier to connect seemingly unrelated activity. For example, a network sniffer placed on a link that all traffic to and from a particular host crosses could keep track of which destinations a node talked to, and when 👀 In some cases, that information can be used to infer things like what hours an employee was active, or when someone is at home, etc. 🏠

One requirement for connecting seemingly unrelated activities is using (and reusing) an identifier that stays recognizable over time, across 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 a DNS name takes more work (it may need a DNS query), but the information is often easy to find. So changing the address on a machine over time would do very little to address the concerns raised in this document, unless the DNS name also changes (see Section 4) 🙄

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

Using a constant identifier inside an address is especially concerning, because addresses are a fundamental requirement of communication and can't easily be hidden from eavesdroppers and other parties 😳 Even when higher layers encrypt their payloads, the addresses in packet headers appear 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 [SERIALNUM] 💻🕵️‍♀️

2.2. Address Usage in IPv4 Today 🌐

Addresses used on today's Internet often don't change in practice for long stretches of time, especially in non-home environments (e.g., corporations, campuses, etc.) 🏢 In those sites, addresses are assigned statically and usually change infrequently. Over the last few years, sites have started moving from static allocation to dynamic allocation via DHCP [DHCP] 📈 In theory, the address a client gets via DHCP can change over time, but in practice servers often hand the same address back to the same client (unless addresses are in such short supply that they get reused right away by a different node once they're freed). So even on sites using DHCP, clients frequently end up using the same address for weeks to months at a time 🗓️

For home users accessing the Internet over dialup lines, the situation is usually different 📞 These users don't have permanent connections, and they're often assigned temporary addresses every time they connect to their ISP (e.g., AOL). So the addresses they use change frequently over time and get shared among a bunch of different users. That means an address doesn't reliably identify a particular device over time spans longer than a few minutes ⏱️

A more interesting case is always-on connections (e.g., cable modems, ISDN, DSL, etc.), which result in a home site using the same address for long periods of time 🏡 This scenario is 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 📡 You might think changing the address regularly in these environments would be good for privacy, but the network prefix portion 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 document addresses 🙃 Specifically, all nodes within a home would get grouped together for the purposes of collecting information. This issue is hard to address, because the routing prefix part of an address contains topology information and can't contain arbitrary values 🧱

Finally, nodes that need a (non-changing) DNS name usually have static addresses assigned to simplify the configuration of DNS servers 🧾 Dynamic DNS [DDNS] can be used to update DNS dynamically, but it isn't yet widely deployed. Also, changing an address while keeping the same DNS name doesn't really address the underlying concern, since the DNS name becomes a non-changing identifier 😬 Servers generally need a DNS name (so clients can connect to them), and clients often need one too (e.g., some servers refuse to speak to a client whose address can't be mapped into a DNS name that also maps back into the same address) 🚫 Section 4 describes one approach to this issue 💜

2.3. The Concern With IPv6 Addresses

okay so this is the bit where IPv6 gets a little tricky 👀. An IPv6 address is split into a topology part and an interface identifier part, and that split creates something IPv6 has never had to deal with before 💅. The interface identifier, which is the fixed bit at the end, can stay the same even when the topology part changes, like when you plug into a totally different part of the Internet 🦋. With IPv4, when the address changes, the whole thing usually changes, including the local bit. This new issue is what this document is here to handle 🫶.

Picture a home user whose address is built from an interface identifier. That identifier could stay the same from one dial-up session to the next even if everything else changes 🧚. The thing is, PPP is usually used so that the PPP server tells the client which address to use, and the client doesn't pick one itself 🙈. If IPv6 keeps doing it that way, the privacy problems this document is worried about wouldn't really come up 💖.

The bigger worry is mobile devices like laptops, PDAs, and so on, which move around the Internet 💀. Every time they move (unless something like mobile IP [MOBILEIP] is in play), they form new addresses for wherever they've landed. Think of the classic "road warrior" who has Internet access both at home and at the office 👑. The address keeps changing as the device moves, but the interface identifier stays put (when it's derived from an IEEE Identifier) 😭. That means the interface identifier can be used to track where a particular machine goes and what it's up to [SERIALNUM]. For example, a server that logs usage along with source addresses is also recording the interface identifier, since it's sitting right inside the address 📝. So any data-mining technique that links activity by address could easily be stretched to do the same thing with the interface identifier 🔥. This is extra serious because lots of next-generation network-connected devices (PDAs, cell phones, and so on) are expected to show up in huge numbers, and in practice they're tied to individual users and not shared 🌈. So the interface identifier inside an address could be used to follow one person's activity even as they move around the internet ✨.

To sum it up, IPv6 addresses on a given interface that are generated through Stateless Autoconfiguration all contain the same interface identifier, no matter where the device connects 🍓. That makes it easier to track individual devices, and possibly the people using them 😬. The purpose of this document is to define mechanisms that get rid of this problem in the situations where it actually matters 🎀.

2.4. Possible Approaches

Okay, so one way to dodge some of these problems is to get addresses from DHCP 🌸. With DHCP, the DHCP server could hand out addresses that change over time 🦋.

Another option, which still fits the stateless address autoconfiguration setup, is to change the interface identifier portion of an address over time and generate new addresses from it for some address scopes 💜. Changing the interface identifier makes it harder to look at IP addresses from separate transactions and figure out which ones belong to the same node 🕵️‍♀️. That's true whether or not the routing prefix portion of the address changes too 💅.

A lot of machines act as both clients and servers 🫶. In that case, the machine would need a DNS name so it can work as a server 🌈. Whether its address stays fixed or changes doesn't matter all that much for privacy, because the DNS name stays the same and works as a constant identifier 💀. When the machine is acting as a client, though (like when it starts a connection), it might want to switch up the addresses it uses ✨. In that kind of setup, you may need more than one address: a "public" (meaning non-secret) server address, registered in the DNS, that takes incoming connection requests from other machines, plus a "temporary" address that hides who the client is when it starts talking to someone else 🎀. It's kinda like phone numbers and caller ID: you can list your number in the public phone book, but turn off the display of your number through caller ID when you call someone 📞💖.

To make it hard to guess whether two different interface identifiers belong to the same node, the algorithm that generates alternate identifiers has to include an input with a part that's unpredictable to the outside entities collecting information 🔮. Picking identifiers from a pseudo-random sequence is enough, as long as an outsider who looks at information that's easy to get or figure out (like by checking packet contents) can't work out the exact sequence 🙈. This document suggests generating a pseudo-random sequence of interface identifiers with an MD5 hash 🧁. Every so often, the next interface identifier in the sequence is generated, a new set of temporary addresses is made, and the old temporary addresses are deprecated so people stop using them 🍂. The exact pseudo-random sequence depends on both a random component and the globally unique interface identifier (when there is one), which makes it more likely that different nodes end up with different sequences 🌟.

3. Protocol Description

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 global-scope addresses based on a random interface identifier for use with global scope addresses. Such addresses would be used to initiate 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 address can continue to be used for already established connections, but are not used to initiate new connections. New temporary addresses are generated periodically to replace temporary addresses that expire, with the exact time between address generation a matter of local policy. 🌷
3. Produce a sequence of temporary global-scope addresses from a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future address (or identifier) based on a current one and it is difficult to determine previous addresses (or identifiers) knowing only the present one. 🔐
4. 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 are dependent only on the low-order bits of the corresponding address. This decision was made to address the concern that a node that joins a large number of multicast groups may be required to put its interface into promiscuous mode, resulting in possible reduced performance. 🎶

3.1. Assumptions

The following algorithm assumes that each interface maintains an associated randomized interface identifier 🎲. When temporary addresses are generated, the current value of that associated randomized interface identifier is used. The actual value of the identifier changes over time as described below, but the same identifier can be used to generate more than one temporary address 🔄.

The algorithm also assumes that, for a given temporary address, an implementation can work out the public address it was generated from 🗝️. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address depend on the matching lifetime values in the public address ⏳.

Finally, this document assumes that when a node starts outgoing communication, temporary addresses can be given preference over public addresses 💅. That can mean all connections the node starts use temporary addresses by default, or applications can each indicate whether they'd rather use temporary or public addresses 🌸. Preferring temporary addresses fits with ongoing work on source-address selection in the more general case [ADDR_SELECT] 🧩. An implementation may make it a policy not to select a public address when no temporary address is available (for example, if generating a usable temporary address fails) 🙃.

3.2. Generation Of Randomized Interface Identifiers.

Okay, so we describe two ways to keep the randomized interface identifier going 🌈. The first one assumes there's stable storage that can record state history, so the algorithm's next run can use that history as input even after a system restart 💾. The second approach is for when stable storage isn't available, and you still need to generate randomized interface identifiers without any previous state 🫧.

3.2.1. When Stable Storage Is Present ✨

okay so this algorithm assumes you've got a 64-bit "history value" 🧠 that gets fed in when you cook up a randomized interface identifier. The very first time the system boots (aka out-of-the-box 📦), a random value should be generated using techniques that help ensure the initial value is hard to guess [RANDOM]. Every time a new interface identifier gets generated, a value from the computation is saved as the history value for the next iteration of the algorithm 💅

so here's how a randomized interface identifier gets made 🫶

1. Take the history value from the previous iteration of this algorithm (or a random value if there is no previous value) and append to it the interface identifier generated as described in [ADDRARCH].
2. Compute the MD5 message digest [MD5] over the quantity created in the previous step.
3. Take the left-most 64-bits of the MD5 digest and set bit 6 (the left-most bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only. Save the generated identifier as the associated randomized interface identifier.
4. Take the rightmost 64-bits of the MD5 digest computed in step 2) and save them in stable storage as the history value to be used in the next iteration of the algorithm.

MD5 was picked for convenience 🍓 and because its particular properties were adequate to produce the level of randomization we wanted. IPv6 nodes are already required to implement MD5 as part of IPsec [IPSEC], so the code is already sitting on IPv6 machines. no extra homework needed 🧚

ngl this part is so clever 😭 In theory, generating successive randomized interface identifiers with a history scheme has no advantages over just generating them at random. In practice though, generating truly random numbers can be tricky 🙈 The history value exists to avoid this specific nightmare: two nodes generate the same randomized interface identifier, both detect it via DAD, and then they proceed to generate identical ones again because they're using the same flawed random number generation algorithm. The algorithm above dodges this by having the interface identifier (which will often be globally unique) used in the calculation that generates the next randomized interface identifiers. So if two nodes happen to generate the same randomized interface identifier, they should generate different ones on the followup attempt 💜

3.2.2. In The Absence of Stable Storage 🌸

so what if there's no stable storage? 👀 Then no history value survives across system restarts to generate a pseudo-random sequence of interface identifiers. Which means the initial history value has to be generated at random. There are a bunch of techniques that might be appropriate, and you can consult [RANDOM] for suggestions on good sources of random numbers 🎀

Also, even if machines don't have stable storage for a history value, they will in many cases have configuration information that differs from one machine to another (e.g., user identity, security keys, serial numbers, etc.) 🦋 One approach for generating a random initial history value in that situation is to use the configuration information to generate some data bits (these may stay constant for the life of the machine, but will vary from one machine to another), append some random data, and compute the MD5 digest as before. big brain move, honestly 🧠✨

3.3. Generating Temporary Addresses 🎀

okay so [ADDRCONF] describes the steps for generating a link-local address when an interface becomes enabled, plus the steps for generating addresses for other scopes. This document extends [ADDRCONF] like this 💅 When processing a Router Advertisement with a Prefix Information option carrying a global-scope prefix for address autoconfiguration (i.e., the A bit is set), do the following:

1. Process the Prefix Information Option as defined in [ADDRCONF], either creating a public address or adjusting the lifetimes of existing addresses, both public and temporary. When adjusting the lifetimes of an existing temporary address, only lower the lifetimes. Implementations must not increase the lifetimes of an existing temporary address when processing a Prefix Information Option. 🙅‍♀️
2. When a new public address is created as described in [ADDRCONF] (because the advertised prefix doesn't match the prefix of any address already assigned to the interface, and the Valid Lifetime in the option is not zero), also create a new temporary address. ✨
3. When creating a temporary address, derive the lifetime values from the corresponding public address 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.

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

4. New temporary addresses are made by appending the interface's current randomized interface identifier to the prefix that was used to generate the corresponding public address. If by chance the new temporary address is the same as an address already assigned to the interface, generate a new randomized interface identifier and repeat this step. 🔁
5. Perform duplicate address detection (DAD) on the generated temporary address. If DAD indicates the address is already in use, generate a new randomized interface identifier as described in Section 3.2 above, and repeat the previous steps as appropriate, up to 5 times. If after 5 consecutive attempts no non-unique address was generated, log a system error and give up on generating temporary addresses for that interface. 😭

Note: because multiple temporary addresses are generated from the same associated randomized interface identifier, there's little benefit in running DAD on every temporary address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier. big brain energy, no cap 🧠💖

3.4. Expiration of Temporary Addresses 🦋

when a temporary address becomes deprecated, a new one should be generated. You do this by repeating the actions in Section 3.3, starting at step 3). Except for the transient period when a temporary address is being regenerated, in normal operation at most one temporary address corresponding to a public address should be in a non-deprecated state at any given time. And if a temporary address becomes deprecated because of processing a Prefix Information Option with a zero Preferred Lifetime, then a new temporary address must not be generated. The Prefix Information Option will also deprecate the corresponding public address. 🙈

To insure that a preferred temporary address is always available, a new temporary address should be regenerated slightly before its predecessor is deprecated 🫶 This gives enough time to avoid race conditions in case generating a new temporary address isn't instantaneous, like when duplicate address detection has to run. It is recommended that an implementation start the address regeneration process REGEN_ADVANCE time units before a temporary address would actually be deprecated. 🌈

As an optional optimization, an implementation may wish to remove a deprecated temporary address that isn't in use by applications or upper layers. For TCP connections, that info is available in control blocks. For UDP-based applications, it may be that only the applications know which addresses are actually in use, so you may need heuristics to decide when an address is no longer in use (e.g., the default TEMP_VALID_LIFETIME suggested above). detective work, iykyk 🕵️‍♀️

3.5. Regeneration of Randomized Interface Identifiers 💜

how often temporary addresses should change depends on how a device is used (e.g., how frequently it starts new communication) and what the end user cares about 💅 The most egregious privacy concerns seem to involve addresses used for long periods of time (weeks to months to years) 😭 The more often an address changes, the less feasible it becomes to collect or coordinate information keyed on interface identifiers. Plus, the cost of collecting and correlating that info is only worth it if enough addresses contain non-changing identifiers to make it worthwhile. So having large numbers of clients change their address on a daily or weekly basis is likely to be enough to alleviate most privacy concerns 🌸

there are also client costs to having a large number of addresses on one node (e.g., doing address lookups, needing to join lots of multicast groups, etc.). So changing addresses super frequently (e.g., every few minutes) may have performance implications 🙃

This document recommends that implementations generate new temporary addresses on a periodic basis. This can be done automatically by generating a new randomized interface identifier at least once every (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. As described above, generating a new temporary address REGEN_ADVANCE time units before a temporary address becomes deprecated produces addresses with a preferred lifetime no larger than TEMP_PREFERRED_LIFETIME. The value DESYNC_FACTOR is a random value (different for each client) that makes sure clients don't sync up and generate new addresses at exactly the same time 🎀 When the preferred lifetime expires, a new temporary address is generated using the new randomized interface identifier.

Because the right frequency for generating new addresses varies from one environment to another, implementations should give end users the ability to change how often addresses get regenerated. The default value is given in TEMP_PREFERRED_LIFETIME and is one day ☀️ On top of that, the exact time to invalidate a temporary address depends on how end users actually use applications. So the default of one week (TEMP_VALID_LIFETIME) may not be appropriate in all environments. Implementations should give end users the ability to override both of these default values. user control is everything 👑

Finally, when an interface connects to a new link, a new randomized interface identifier should be generated immediately, together with a new set of temporary addresses. If a device moves from one ethernet to another, generating a new set of temporary addresses from a different randomized interface identifier means the device uses different randomized interface identifiers for the temporary addresses on the two links. That makes it harder to correlate addresses from the two different links as coming from the same node 🦋🕵️‍♀️ main character privacy energy, periodt ✨

4. Implications of Changing Interface Identifiers ✨

Okay so the IPv6 addressing architecture goes to some lengths to make interface identifiers globally unique whenever that's easy to do 🌸 During the IPng discussions of the GSE proposal [GSE], people felt that keeping interface identifiers globally unique in practice might be useful to future transport protocols 🦋 Using the algorithms in this document may make that future flexibility harder to provide, so ngl that's a real tradeoff 🙈

Protecting individual privacy and effectively maintaining and debugging a network can totally clash 💅 Having clients use addresses that change over time makes operational problems harder to track down and isolate. Like, when you're staring at packet traces, it gets way harder to tell whether you're seeing behavior from one errant machine or from a bunch of them 😭

Some servers refuse to let in clients that have no DNS name 🚫 They do a DNS PTR query to find the name, and may then also do an A query on the returned name to check that it maps back into the address being used 👀 So clients not properly registered in the DNS may be locked out of some services. As noted earlier, though, a node's DNS name (if non-changing) works as a constant identifier 💜 Widespread use of the extension described here 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 temporary addresses in the DNS using random names (for example, a string version of the random address itself) 🧚

Using the extensions defined here may complicate debugging and other operational troubleshooting 🛠️ So it may be site policy that temporary addresses should not be used 🙅 Implementations may provide a method for a trusted administrator to override the use of temporary addresses 🔑

---

5. Defined Constants 🎀

Okay, 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).

6. Future Work 🔮

An implementation might want to keep track of which addresses are being used by upper layers, so it can remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before) 🧹 This is different from current approaches, where addresses get removed from an interface when they become invalid [ADDRCONF], whether or not upper layer protocols are still using them. For TCP connections, that info lives in control blocks 📦 For UDP-based applications, it may be that only the applications know which addresses are actually in use 🤷 So an implementation generally will need to use heuristics to decide when an address is no longer in use (e.g., as is suggested in Section 3.4) ✨

The choice between public and temporary addresses can, in some cases, only be made by an application 🫣 For example, some applications may always want temporary addresses, while others may want them only in some circumstances or not at all. Suitable API extensions will likely need to be developed so individual applications can indicate, with sufficient granularity, what they need regarding the use of temporary addresses 💖

7. Security Considerations 🚨

This is the serious part, so listen up 👑 The motivation for this document stems from privacy concerns for individuals. This document does not appear to add any security issues beyond those already associated with stateless address autoconfiguration [ADDRCONF].

8. Acknowledgments 🫶

The authors would like to acknowledge the contributions of the IPNGWG working group and, in particular, Matt Crawford, Steve Deering and Allison Mankin for their detailed comments. Iconic behavior from the squad 💜

9. References 📚

[ADDRARCH]    Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

[ADDRCONF]    Thomson, S. and T. Narten, "IPv6 Address
              Autoconfiguration", RFC 2462, December 1998.

[ADDR_SELECT] Draves, R. "Default Address Selection for IPv6", Work
              in Progress.

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

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

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

[DISCOVERY]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

[GSE]         Crawford, et al., "Separating Identifiers and Locators
              in Addresses: An Analysis of the GSE Proposal for
              IPv6", Work in Progress.

[IPSEC]       Kent, S., Atkinson, R., "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

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

[MOBILEIP]    Perkins, C., "IP Mobility Support", RFC 2002, October
              1996.

[RANDOM]      Eastlake 3rd, D., Crocker S. and J. Schiller,
              "Randomness Recommendations for Security", RFC 1750,
              December 1994.

[SERIALNUM]   Moore, K., "Privacy Considerations for the Use of
              Hardware Serial Numbers in End-to-End Network
              Protocols", Work in Progress.

10. Authors' Addresses ✍️

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

Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.com


Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 936 2268
EMail: richdr@microsoft.com

11. Full Copyright Statement ⚖️

Here's the legal stuff, kept complete and exactly as written 📜

Copyright (C) The Internet Society (2001).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈 That's a wrap, bestie! 🦋✨