idnits 2.17.1 draft-ietf-ipngwg-temp-addresses-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC3041]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC3041, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 514 has weird spacing: '... should be ex...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 2002) is 7879 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2526' is mentioned on line 787, but not defined == Unused Reference: 'RESERVED-ANYCAST' is defined on line 869, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2965 (ref. 'COOKIES') (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) == Outdated reference: A later version (-05) exists of draft-ietf-ipngwg-esd-analysis-04 -- Possible downref: Normative reference to a draft: ref. 'GSE' == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2002 (ref. 'MOBILEIP') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'ONION' ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) -- Possible downref: Normative reference to a draft: ref. 'SERIALNUM' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 Richard Draves 5 Microsoft Research 6 September 23, 2002 8 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Nodes use IPv6 stateless address autoconfiguration to generate 35 addresses without the necessity of a Dynamic Host Configuration 36 Protocol (DHCP) server. Addresses are formed by combining network 37 prefixes with an interface identifier. On interfaces that contain 38 embedded IEEE Identifiers, the interface identifier is typically 39 derived from it. On other interface types, the interface identifier 40 is generated through other means, for example, via random number 41 generation. This document describes an extension to IPv6 stateless 42 address autoconfiguration for interfaces whose interface identifier 43 is derived from an IEEE identifier. Use of the extension causes nodes 44 to generate global-scope addresses from interface identifiers that 45 change over time, even in cases where the interface contains an 46 embedded IEEE identifier. Changing the interface identifier (and the 47 global-scope addresses generated from it) over time makes it more 48 difficult for eavesdroppers and other information collectors to 49 identify when different addresses used in different transactions 50 actually correspond to the same node. 52 This document updates and replaces RFC 3041 [RFC3041]. 54 Contents 56 Status of this Memo.......................................... 1 58 1. Introduction............................................. 3 60 2. Background............................................... 4 61 2.1. Extended Use of the Same Identifier................. 4 62 2.2. Address Usage in IPv4 Today......................... 5 63 2.3. The Concern With IPv6 Addresses..................... 6 64 2.4. Possible Approaches................................. 7 66 3. Protocol Description..................................... 8 67 3.1. Assumptions......................................... 9 68 3.2. Generation Of Randomized Interface Identifiers...... 9 69 3.2.1. When Stable Storage Is Present................. 9 70 3.2.2. In The Absence of Stable Storage............... 11 71 3.3. Generating Temporary Addresses...................... 11 72 3.4. Expiration of Temporary Addresses................... 13 73 3.5. Regeneration of Randomized Interface Identifiers.... 13 74 3.6. Configuration Switch................................ 15 75 3.7. Default Setting..................................... 15 77 4. Implications of Changing Interface Identifiers........... 15 79 5. Defined Constants........................................ 16 81 6. Future Work.............................................. 16 83 7. Open Issues.............................................. 17 85 8. Significant Changes from RFC 3041........................ 17 87 9. Security Considerations.................................. 18 89 10. Acknowledgments......................................... 18 91 11. References.............................................. 18 93 1. Introduction 95 [Note: this ID was resubmitted September, 2002, in order to make it 96 available, but its contents are identical (other than the submission 97 date) to the ID originally submitted July, 2001.] 99 Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 100 node generates addresses without the need for a DHCP server. Some 101 types of network interfaces come with an embedded IEEE Identifier 102 (i.e., a link-layer MAC address), and in those cases stateless 103 address autoconfiguration uses the IEEE identifier to generate a 104 64-bit interface identifier [ADDRARCH]. By design, the interface 105 identifier is likely to be globally unique when generated in this 106 fashion. The interface identifier is in turn appended to a prefix to 107 form a 128-bit IPv6 address. 109 All nodes combine interface identifiers (whether derived from an IEEE 110 identifier or generated through some other technique) with the 111 reserved link-local prefix to generate link-local addresses for their 112 attached interfaces. Additional addresses, including site-local and 113 global-scope addresses, are then created by combining prefixes 114 advertised in Router Advertisements via Neighbor Discovery 115 [DISCOVERY] with the interface identifier. 117 Not all nodes and interfaces contain IEEE identifiers. In such cases, 118 an interface identifier is generated through some other means (e.g., 119 at random), and the resultant interface identifier is not globally 120 unique and may also change over time. The focus of this document is 121 on addresses derived from IEEE identifiers, as the concern being 122 addressed exists only in those cases where the interface identifier 123 is globally unique and non-changing. The rest of this document 124 assumes that IEEE identifiers are being used, but the techniques 125 described may also apply to interfaces with other types of globally 126 unique and/or persistent identifiers. 128 This document discusses concerns associated with the embedding of 129 non-changing interface identifiers within IPv6 addresses and 130 describes extensions to stateless address autoconfiguration that can 131 help mitigate those concerns for individual users and in environments 132 where such concerns are significant. Section 2 provides background 133 information on the issue. Section 3 describes a procedure for 134 generating alternate interface identifiers and global-scope 135 addresses. Section 4 discusses implications of changing interface 136 identifiers. 138 2. Background 140 This section discusses the problem in more detail, provides context 141 for evaluating the significance of the concerns in specific 142 environments and makes comparisons with existing practices. 144 2.1. Extended Use of the Same Identifier 146 The use of a non-changing interface identifier to form addresses is a 147 specific instance of the more general case where a constant 148 identifier is reused over an extended period of time and in multiple 149 independent activities. Anytime the same identifier is used in 150 multiple contexts, it becomes possible for that identifier to be used 151 to correlate seemingly unrelated activity. For example, a network 152 sniffer placed strategically on a link across which all traffic 153 to/from a particular host crosses could keep track of which 154 destinations a node communicated with and at what times. Such 155 information can in some cases be used to infer things, such as what 156 hours an employee was active, when someone is at home, etc. 158 One of the requirements for correlating seemingly unrelated 159 activities is the use (and reuse) of an identifier that is 160 recognizable over time within different contexts. IP addresses 161 provide one obvious example, but there are more. Many nodes also have 162 DNS names associated with their addresses, in which case the DNS name 163 serves as a similar identifier. Although the DNS name associated with 164 an address is more work to obtain (it may require a DNS query) the 165 information is often readily available. In such cases, changing the 166 address on a machine over time would do little to address the 167 concerns raised in this document, unless the DNS name is changed as 168 well (see Section 4). 170 Web browsers and servers typically exchange "cookies" with each other 171 [COOKIES]. Cookies allow web servers to correlate a current activity 172 with a previous activity. One common usage is to send back targeted 173 advertising to a user by using the cookie supplied by the browser to 174 identify what earlier queries had been made (e.g., for what type of 175 information). Based on the earlier queries, advertisements can be 176 targeted to match the (assumed) interests of the end-user. 178 The use of a constant identifier within an address is of special 179 concern because addresses are a fundamental requirement of 180 communication and cannot easily be hidden from eavesdroppers and 181 other parties. Even when higher layers encrypt their payloads, 182 addresses in packet headers appear in the clear. Consequently, if a 183 mobile host (e.g., laptop) accessed the network from several 184 different locations, an eavesdropper might be able to track the 185 movement of that mobile host from place to place, even if the upper 186 layer payloads were encrypted [SERIALNUM]. 188 2.2. Address Usage in IPv4 Today 190 Addresses used in today's Internet are often non-changing in practice 191 for extended periods of time, especially in non-home environments 192 (e.g., corporations, campuses, etc.). In such sites, addresses are 193 assigned statically and typically change infrequently. Over the last 194 few years, sites have begun moving away from static allocation to 195 dynamic allocation via DHCP [DHCP]. In theory, the address a client 196 gets via DHCP can change over time, but in practice servers often 197 return the same address to the same client (unless addresses are in 198 such short supply that they are reused immediately by a different 199 node when they become free). Thus, even within sites using DHCP, 200 clients frequently end up using the same address for weeks to months 201 at a time. 203 For home users accessing the Internet over dialup lines, the 204 situation is generally different. Such users do not have permanent 205 connections and are often assigned temporary addresses each time they 206 connect to their ISP (e.g., AOL). Consequently, the addresses they 207 use change frequently over time and are shared among a number of 208 different users. Thus, an address does not reliably identify a 209 particular device over time spans of more than a few minutes. 211 A more interesting case concerns always-on connections (e.g., cable 212 modems, ISDN, DSL, etc.) that result in a home site using the same 213 address for extended periods of time. This is a scenario that is just 214 starting to become common in IPv4 and promises to become more of a 215 concern as always-on internet connectivity becomes widely available. 216 Although it might appear that changing an address regularly in such 217 environments would be desirable to lessen privacy concerns, it should 218 be noted that the network prefix portion of an address also serves as 219 a constant identifier. All nodes at (say) a home, would have the same 220 network prefix, which identifies the topological location of those 221 nodes. This has implications for privacy, though not at the same 222 granularity as the concern that this document addresses. 223 Specifically, all nodes within a home would be grouped together for 224 the purposes of collecting information. This issue is difficult to 225 address, because the routing prefix part of an address contains 226 topology information and cannot contain arbitrary values. 228 Finally, it should be noted that nodes that need a (non-changing) DNS 229 name generally have static addresses assigned to them to simplify the 230 configuration of DNS servers. Although Dynamic DNS [DDNS] can be used 231 to update the DNS dynamically, it is not yet widely deployed. In 232 addition, changing an address but keeping the same DNS name does not 233 really address the underlying concern, since the DNS name becomes a 234 non-changing identifier. Servers generally require a DNS name (so 235 clients can connect to them), and clients often do as well (e.g., 236 some servers refuse to speak to a client whose address cannot be 237 mapped into a DNS name that also maps back into the same address). 238 Section 4 describes one approach to this issue. 240 2.3. The Concern With IPv6 Addresses 242 The division of IPv6 addresses into distinct topology and interface 243 identifier portions raises an issue new to IPv6 in that a fixed 244 portion of an IPv6 address (i.e., the interface identifier) can 245 contain an identifier that remains constant even when the topology 246 portion of an address changes (e.g., as the result of connecting to a 247 different part of the Internet). In IPv4, when an address changes, 248 the entire address (including the local part of the address) usually 249 changes. It is this new issue that this document addresses. 251 If addresses are generated from an interface identifier, a home 252 user's address could contain an interface identifier that remains the 253 same from one dialup session to the next, even if the rest of the 254 address changes. The way PPP is used today, however, PPP servers 255 typically unilaterally inform the client what address they are to use 256 (i.e., the client doesn't generate one on its own). This practice, if 257 continued in IPv6, would avoid the concerns that are the focus of 258 this document. 260 A more troubling case concerns mobile devices (e.g., laptops, PDAs, 261 etc.) that move topologically within the Internet. Whenever they move 262 (in the absence of technology such as mobile IP [MOBILEIP]), they 263 form new addresses for their current topological point of attachment. 264 This is typified today by the "road warrior" who has Internet 265 connectivity both at home and at the office. While the node's address 266 changes as it moves, however, the interface identifier contained 267 within the address remains the same (when derived from an IEEE 268 Identifier). In such cases, the interface identifier can be used to 269 track the movement and usage of a particular machine [SERIALNUM]. For 270 example, a server that logs usage information together with a source 271 addresses, is also recording the interface identifier since it is 272 embedded within an address. Consequently, any data-mining technique 273 that correlates activity based on addresses could easily be extended 274 to do the same using the interface identifier. This is of particular 275 concern with the expected proliferation of next-generation network- 276 connected devices (e.g., PDAs, cell phones, etc.) in which large 277 numbers of devices are in practice associated with individual users 278 (i.e., not shared). Thus, the interface identifier embedded within an 279 address could be used to track activities of an individual, even as 280 they move topologically within the internet. 282 In summary, IPv6 addresses on a given interface generated via 283 Stateless Autoconfiguration contain the same interface identifier, 284 regardless of where within the Internet the device connects. This 285 facilitates the tracking of individual devices (and thus potentially 286 users). The purpose of this document is to define mechanisms that 287 eliminate this issue, in those situations where it is a concern. 289 2.4. Possible Approaches 291 One way to avoid some of the problems discussed above is to use DHCP 292 for obtaining addresses. With DHCP, the DHCP server could arrange to 293 hand out addresses that change over time. 295 Another approach, compatible with the stateless address 296 autoconfiguration architecture, would be to change the interface id 297 portion of an address over time and generate new addresses from the 298 interface identifier for some address scopes. Changing the interface 299 identifier can make it more difficult to look at the IP addresses in 300 independent transactions and identify which ones actually correspond 301 to the same node, both in the case where the routing prefix portion 302 of an address changes and when it does not. 304 Many machines function as both clients and servers. In such cases, 305 the machine would need a DNS name for its use as a server. Whether 306 the address stays fixed or changes has little privacy implication 307 since the DNS name remains constant and serves as a constant 308 identifier. When acting as a client (e.g., initiating communication), 309 however, such a machine may want to vary the addresses it uses. In 310 such environments, one may need multiple addresses: a "public" (i.e., 311 non-secret) server address, registered in the DNS, that is used to 312 accept incoming connection requests from other machines, and a 313 "temporary" address used to shield the identity of the client when it 314 initiates communication. These two cases are roughly analogous to 315 telephone numbers and caller ID, where a user may list their 316 telephone number in the public phone book, but disable the display of 317 its number via caller ID when initiating calls. 319 To make it difficult to make educated guesses as to whether two 320 different interface identifiers belong to the same node, the 321 algorithm for generating alternate identifiers must include input 322 that has an unpredictable component from the perspective of the 323 outside entities that are collecting information. Picking identifiers 324 from a pseudo-random sequence suffices, so long as the specific 325 sequence cannot be determined by an outsider examining information 326 that is readily available or easily determinable (e.g., by examining 327 packet contents). This document proposes the generation of a pseudo- 328 random sequence of interface identifiers via an MD5 hash. 329 Periodically, the next interface identifier in the sequence is 330 generated, a new set of temporary addresses is created, and the 331 previous temporary addresses are deprecated to discourage their 332 further use. The precise pseudo-random sequence depends on both a 333 random component and the globally unique interface identifier (when 334 available), to increase the likelihood that different nodes generate 335 different sequences. 337 3. Protocol Description 339 The goal of this section is to define procedures that: 341 1) Do not result in any changes to the basic behavior of addresses 342 generated via stateless address autoconfiguration [ADDRCONF]. 344 2) Create additional global-scope addresses based on a random 345 interface identifier for use with global scope addresses. Such 346 addresses would be used to initiate outgoing sessions. These 347 "random" or temporary addresses would be used for a short period 348 of time (hours to days) and would then be deprecated. Deprecated 349 address can continue to be used for already established 350 connections, but are not used to initiate new connections. New 351 temporary addresses are generated periodically to replace 352 temporary addresses that expire, with the exact time between 353 address generation a matter of local policy. 355 3) Produce a sequence of temporary global-scope addresses from a 356 sequence of interface identifiers that appear to be random in the 357 sense that it is difficult for an outside observer to predict a 358 future address (or identifier) based on a current one and it is 359 difficult to determine previous addresses (or identifiers) knowing 360 only the present one. 362 4) Generate a set of addresses from the same (randomized) interface 363 identifier, one address for each prefix for which a global address 364 has been generated via stateless address autoconfiguration. Using 365 the same interface identifier to generate a set of temporary 366 addresses reduces the number of IP multicast groups a host must 367 join. Nodes join the solicited-node multicast address for each 368 unicast address they support, and solicited-node addresses are 369 dependent only on the low-order bits of the corresponding address. 370 This decision was made to address the concern that a node that 371 joins a large number of multicast groups may be required to put 372 its interface into promiscuous mode, resulting in possible reduced 373 performance. 375 3.1. Assumptions 377 The following algorithm assumes that each interface maintains an 378 associated randomized interface identifier. When temporary addresses 379 are generated, the current value of the associated randomized 380 interface identifier is used. The actual value of the identifier 381 changes over time as described below, but the same identifier can be 382 used to generate more than one temporary address. 384 The algorithm also assumes that for a given temporary address, an 385 implementation can determine the corresponding public address from 386 which it was generated. When a temporary address is deprecated, a new 387 temporary address is generated. The specific valid and preferred 388 lifetimes for the new address are dependent on the corresponding 389 lifetime values in the public address. 391 Finally, this document assumes that when a node initiates outgoing 392 communication, temporary addresses can be given preference over 393 public addresses, when the device is configured to do so (see Section 394 3.6). This is consistent with on-going work that addresses the topic 395 of source-address selection in the more general case [ADDR_SELECT] 396 and also means that all connections initiated by the node can use 397 temporary addresses without requiring application-specific 398 enablement. This document also assumes that an API will exist that 399 allows individual applications to indicate whether they prefer to use 400 temporary or public addresses and override the system defaults. 402 3.2. Generation Of Randomized Interface Identifiers. 404 We describe two approaches for the maintenance of the randomized 405 interface identifier. The first assumes the presence of stable 406 storage that can be used to record state history for use as input 407 into the next iteration of the algorithm across system restarts. A 408 second approach addresses the case where stable storage is 409 unavailable and there is a need to generate randomized interface 410 identifiers without previous state. 412 3.2.1. When Stable Storage Is Present 414 The following algorithm assumes the presence of a 64-bit "history 415 value" that is used as input in generating a randomized interface 416 identifier. The very first time the system boots (i.e., out-of-the- 417 box), a random value should be generated using techniques that help 418 ensure the initial value is hard to guess [RANDOM]. Whenever a new 419 interface identifier is generated, a value generated by the 420 computation is saved in the history value for the next iteration of 421 the algorithm. 423 A randomized interface identifier is created as follows: 425 1) Take the history value from the previous iteration of this 426 algorithm (or a random value if there is no previous value) and 427 append to it the interface identifier generated as described in 428 [ADDRARCH]. 429 2) Compute the MD5 message digest [MD5] over the quantity created in 430 the previous step. 431 3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the 432 left-most bit is numbered 0) to zero. This creates an interface 433 identifier with the universal/local bit indicating local 434 significance only. 435 4) Compare the generated identifier against a list of known values 436 that should not be used. Inappropriate values include those used 437 in reserved anycast addresses [RFC 2526], those used by ISATAP 438 [ISATAP], the value 0, and those already assigned to an address on 439 the local device. In the event that an unacceptable identifier has 440 been generated, restart the process at step 1 above, using the 441 right-most 64 bits of the MD5 digest obtained in step 2 in place 442 of the history value in step 1. 443 5) Save the generated identifier as the associated randomized 444 interface identifier. 445 6) Take the rightmost 64-bits of the MD5 digest computed in step 2) 446 and save them in stable storage as the history value to be used in 447 the next iteration of the algorithm. 449 MD5 was chosen for convenience, and because its particular properties 450 were adequate to produce the desired level of randomization. IPv6 451 nodes are already required to implement MD5 as part of IPsec [IPSEC], 452 thus the code will already be present on IPv6 machines. 454 In theory, generating successive randomized interface identifiers 455 using a history scheme as above has no advantages over generating 456 them at random. In practice, however, generating truly random numbers 457 can be tricky. Use of a history value is intended to avoid the 458 particular scenario where two nodes generate the same randomized 459 interface identifier, both detect the situation via DAD, but then 460 proceed to generate identical randomized interface identifiers via 461 the same (flawed) random number generation algorithm. The above 462 algorithm avoids this problem by having the interface identifier 463 (which will often be globally unique) used in the calculation that 464 generates subsequent randomized interface identifiers. Thus, if two 465 nodes happen to generate the same randomized interface identifier, 466 they should generate different ones on the followup attempt. 468 3.2.2. In The Absence of Stable Storage 470 In the absence of stable storage, no history value will be available 471 across system restarts to generate a pseudo-random sequence of 472 interface identifiers. Consequently, the initial history value used 473 above will need to be generated at random. A number of techniques 474 might be appropriate. Consult [RANDOM] for suggestions on good 475 sources for obtaining random numbers. Note that even though machines 476 may not have stable storage for storing a history value, they will in 477 many cases have configuration information that differs from one 478 machine to another (e.g., user identity, security keys, serial 479 numbers, etc.). One approach to generating a random initial history 480 value in such cases is to use the configuration information to 481 generate some data bits (which may remain constant for the life of 482 the machine, but will vary from one machine to another), append some 483 random data and compute the MD5 digest as before. 485 3.3. Generating Temporary Addresses 487 [ADDRCONF] describes the steps for generating a link-local address 488 when an interface becomes enabled as well as the steps for generating 489 addresses for other scopes. This document extends [ADDRCONF] as 490 follows. When processing a Router Advertisement with a Prefix 491 Information option carrying a global-scope prefix for the purposes of 492 address autoconfiguration (i.e., the A bit is set), perform the 493 following steps: 495 1) Process the Prefix Information Option as defined in [ADDRCONF], 496 either creating a public address or adjusting the lifetimes of 497 existing addresses, both public and temporary. When adjusting the 498 lifetime of an existing temporary address, there are two cases to 499 consider: 501 a) In some cases, the lifetimes in a received option will be 502 shorter than the lifetimes of an existing temporary addresses 503 derived from the prefix given in the option. This corresponds 504 to the case where the lifetimes have been reconfigured by a 505 system administrator to have a shorter lifetime. In such cases, 506 the lifetime of existing temporary addresses should be reduced 507 so as not to exceed the lifetime in the received option. That 508 is, the lifetimes of temporary addresses should never be longer 509 than the lifetime of the corresponding public address. 510 b) In many cases, the lifetime in a received option will extend 511 the lifetime of a public address. For example, a site might 512 advertise short lifetimes (on the order of hours or minutes) 513 that are effectively extended with each new RA. In such cases, 514 the lifetimes of temporary addresses should be extended, 515 subject to the overall constraint that no temporary addresses 516 should ever remain "valid" or "preferred" for a time longer 517 than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or 518 (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The 519 configuration variables TEMP_VALID_LIFETIME and 520 TEMP_PREFERRED_LIFETIME correspond to approximate target 521 lifetimes for temporary addresses. 523 One way an implementation can satisfy the above constraints is to 524 associate with each temporary address a creation time (called 525 CREATION_TIME) that indicates the time at which the address was 526 created. When updating the preferred lifetime of an existing 527 temporary address, it would be set to expire at whichever time is 528 earlier: the time indicated by the received lifetime or 529 (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A 530 similar approach can be used with the valid lifetime. 531 2) When a new public address is created as described in [ADDRCONF] 532 (because the prefix advertised does not match the prefix of any 533 address already assigned to the interface, and the Valid Lifetime 534 in the option is not zero), also create a new temporary address. 535 3) When creating a temporary address, the lifetime values are derived 536 from the corresponding public address as follows: 538 - Its Valid Lifetime is the lower of the Valid Lifetime of the 539 public address or TEMP_VALID_LIFETIME. 540 - Its Preferred Lifetime is the lower of the Preferred Lifetime 541 of the public address or TEMP_PREFERRED_LIFETIME - 542 DESYNC_FACTOR. 544 A temporary address is created only if this calculated Preferred 545 Lifetime is greater than REGEN_ADVANCE time units. In particular, 546 an implementation must not create a temporary address with a zero 547 Preferred Lifetime. 548 4) New temporary addresses are created by appending the interface's 549 current randomized interface identifier to the prefix that was 550 used to generate the corresponding public address. 551 5) Perform duplicate address detection (DAD) on the generated 552 temporary address. If DAD indicates the address is already in use, 553 generate a new randomized interface identifier as described in 554 Section 3.2 above, and repeat the previous steps as appropriate up 555 to 5 times. If after 5 consecutive attempts no non-unique address 556 was generated, log a system error and give up attempting to 557 generate temporary addresses for that interface. 559 Note: although multiple temporary addresses are generated from the 560 same associated randomized interface identifier, DAD should still 561 be run on every temporary address. Otherwise, it is possible that 562 two nodes will select the same interface identifier but not detect 563 the collision if they run DAD on addresses generated from 564 different prefixes. 566 3.4. Expiration of Temporary Addresses 568 When a temporary address becomes deprecated, a new one should be 569 generated. This is done by repeating the actions described in Section 570 3.3, starting at step 3). Note that, except for the transient period 571 when a temporary address is being regenerated, in normal operation at 572 most one temporary address corresponding to a public address should 573 be in a non-deprecated state at any given time. Note that if a 574 temporary address becomes deprecated as result of processing a Prefix 575 Information Option with a zero Preferred Lifetime, then a new 576 temporary address must not be generated. The Prefix Information 577 Option will also deprecate the corresponding public address. 579 To insure that a preferred temporary address is always available, a 580 new temporary address should be regenerated slightly before its 581 predecessor is deprecated. This is to allow sufficient time to avoid 582 race conditions in the case where generating a new temporary address 583 is not instantaneous, such as when duplicate address detection must 584 be run. It is recommended that an implementation start the address 585 regeneration process REGEN_ADVANCE time units before a temporary 586 address would actually be deprecated. 588 As an optional optimization, an implementation may wish to remove a 589 deprecated temporary address that is not in use by applications or 590 upper-layers. For TCP connections, such information is available in 591 control blocks. For UDP-based applications, it may be the case that 592 only the applications have knowledge about what addresses are 593 actually in use. Consequently, one may need to use heuristics in 594 deciding when an address is no longer in use (e.g., the default 595 TEMP_VALID_LIFETIME suggested above). 597 3.5. Regeneration of Randomized Interface Identifiers 599 The frequency at which temporary addresses should change depends on 600 how a device is being used (e.g., how frequently it initiates new 601 communication) and the concerns of the end user. The most egregious 602 privacy concerns appear to involve addresses used for long periods of 603 time (weeks to months to years). The more frequently an address 604 changes, the less feasible collecting or coordinating information 605 keyed on interface identifiers becomes. Moreover, the cost of 606 collecting information and attempting to correlate it based on 607 interface identifiers will only be justified if enough addresses 608 contain non-changing identifiers to make it worthwhile. Thus, having 609 large numbers of clients change their address on a daily or weekly 610 basis is likely to be sufficient to alleviate most privacy concerns. 612 There are also client costs associated with having a large number of 613 addresses associated with a node (e.g., in doing address lookups, the 614 need to join many multicast groups, etc.). Thus, changing addresses 615 frequently (e.g., every few minutes) may have performance 616 implications. 618 This document recommends that implementations generate new temporary 619 addresses on a periodic basis. This can be achieved automatically by 620 generating a new randomized interface identifier at least once every 621 (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. 622 As described above, generating a new temporary address REGEN_ADVANCE 623 time units before a temporary address becomes deprecated produces 624 addresses with a preferred lifetime no larger than 625 TEMP_PREFERRED_LIFETIME. The value DESYNC_FACTOR is a random value 626 (different for each client) that ensures that clients don't 627 synchronize with each other and generate new addresses at exactly the 628 same time. When the preferred lifetime expires, a new temporary 629 address is generated using the new randomized interface identifier. 631 Because the precise frequency at which it is appropriate to generate 632 new addresses varies from one environment to another, implementations 633 should provide end users with the ability to change the frequency at 634 which addresses are regenerated. The default value is given in 635 TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time 636 at which to invalidate a temporary address depends on how 637 applications are used by end users. Thus the default value given of 638 one week (TEMP_VALID_LIFETIME) may not be appropriate in all 639 environments. Implementations should provide end users with the 640 ability to override both of these default values. 642 Finally, when an interface connects to a new link, a new randomized 643 interface identifier should be generated immediately together with a 644 new set of temporary addresses. If a device moves from one ethernet 645 to another, generating a new set of temporary addresses from a 646 different randomized interface identifier ensures that the device 647 uses different randomized interface identifiers for the temporary 648 addresses associated with the two links, making it more difficult to 649 correlate addresses from the two different links as being from the 650 same node. 652 3.6. Configuration Switch 654 Devices implementing this specification must provide a way for the 655 end user to explicitely enable or disable the use of temporary 656 addresses. In addition, it may be a site's policy to disable the use 657 of temporary addresses in order to simply network debugging and 658 operations. Conseqently, implementations should provide a way for 659 trusted system administrators to enable or disable the use of 660 temporary addresses. 662 3.7. Default Setting 664 The use of temporary addresses may cause unexpected difficulties with 665 some applications. As described below, some servers refuse to accept 666 communications from clients for which they cannot map the IP address 667 into an DNS name. In addition, some applications may not behave 668 robustly if temporary addresses are used and an address expires 669 before the application has terminated, or if it opens multiple 670 sessions, but expects them to all use the same addresses. 671 Conseqently, this document recommends that the use of temporary 672 addresses be disabled by default in order to minimize potential 673 disruptions. Individual applications, which may have specific 674 knowledge about the normal duration of connections, may override this 675 as appropriate. 677 4. Implications of Changing Interface Identifiers 679 The IPv6 addressing architecture goes to some lengths to ensure that 680 interface identifiers are likely to be globally unique where easy to 681 do so. During the IPng discussions of the GSE proposal [GSE], it was 682 felt that keeping interface identifiers globally unique in practice 683 might prove useful to future transport protocols. The widespread use 684 of temporary addresses may result in a significant fraction of 685 Internet traffic not using addresses in which the interface id 686 portion is globally unique. Consequently, usage of the algorithms in 687 this document may complicate providing such a future flexibility, if 688 global uniqueness is necessary. 690 The desires of protecting individual privacy vs. the desire to 691 effectively maintain and debug a network can conflict with each 692 other. Having clients use addresses that change over time will make 693 it more difficult to track down and isolate operational problems. For 694 example, when looking at packet traces, it could become more 695 difficult to determine whether one is seeing behavior caused by a 696 single errant machine, or by a number of them. 698 Some servers refuse to grant access to clients for which no DNS name 699 exists. That is, they perform a DNS PTR query to determine the DNS 700 name, and may then also perform an A query on the returned name to 701 verify that the returned DNS name maps back into the address being 702 used. Consequently, clients not properly registered in the DNS may be 703 unable to access some services. As noted earlier, however, a node's 704 DNS name (if non-changing) serves as a constant identifier. The wide 705 deployment of the extension described in this document could 706 challenge the practice of inverse-DNS-based "authentication," which 707 has little validity, though it is widely implemented. In order to 708 meet server challenges, nodes could register temporary addresses in 709 the DNS using random names (for example a string version of the 710 random address itself). 712 Use of the extensions defined in this document may complicate 713 debugging and other operational troubleshooting activities. 714 Consequently, it may be site policy that temporary addresses should 715 not be used. Consequently, implementations must provide a method for 716 the end user or trusted administrator to override the use of 717 temporary addresses. 719 5. Defined Constants 721 Constants defined in this document include: 723 TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able to 724 override the default value. 725 TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able 726 to override the default value. 727 REGEN_ADVANCE -- 5 seconds 728 MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. 729 DESYNC_FACTOR -- A random value within the range 0 - 730 MAX_DESYNC_FACTOR. It is computed once at system start 731 (rather than each time it is used) and must never be 732 greater than (TEMP_VALID_LIFTIME - REGEN_ADVANCE). 734 6. Future Work 736 An implementation might want to keep track of which addresses are 737 being used by upper layers so as to be able to remove a deprecated 738 temporary address from internal data structures once no upper layer 739 protocols are using it (but not before). This is in contrast to 740 current approaches where addresses are removed from an interface when 741 they become invalid [ADDRCONF], independent of whether or not upper 742 layer protocols are still using them. For TCP connections, such 743 information is available in control blocks. For UDP-based 744 applications, it may be the case that only the applications have 745 knowledge about what addresses are actually in use. Consequently, an 746 implementation generally will need to use heuristics in deciding when 747 an address is no longer in use (e.g., as is suggested in Section 748 3.4). 750 The determination as to whether to use public vs. temporary addresses 751 can in some cases only be made by an application. For example, some 752 applications may always want to use temporary addresses, while others 753 may want to use them only in some circumstances or not at all. 754 Suitable API extensions will likely need to be developed to enable 755 individual applications to indicate with sufficient granularity their 756 needs with regards to the use of temporary addresses. 758 Recommendations on DNS practices to avoid the problem described in 759 Section 5 when reverse DNS lookups fail may be needed. 761 While this document discusses ways of obscuring a user's permanent IP 762 address, the method described is believed to be ineffective against 763 sophisticated forms of traffic analysis. To increase effectiveness, 764 one may need to consider use of more advanced techniques, such as 765 Onion Routing [ONION]. 767 7. Open Issues 769 1) Implementations should allow system administrators to configure 770 the use of temporary addresses. We've considered the possibility 771 of using Router Advertisements to configure a host's use of 772 temporary addresses, but that has a major drawback: in some 773 situations (for example a home user receiving RAs from an ISP's 774 router), the administrator of the host and the administrator of 775 the router may have different opinions about the use of temporary 776 addresses. Any configuration mechanism that disables the use of 777 temporary addresses without input from the user must ensure that 778 the host's administrator has authorized the disabling. 780 8. Significant Changes from RFC 3041 782 This section summarizes the changes in this document relative to RFC 783 3041 that an implementer of RFC 3041 should be aware of. 785 1) Added wording to exclude certain interface indentifiers from the 786 range of acceptable interface identifiers. Interface IDs such as 787 0, those for reserved anycast addresses [RFC 2526], etc. 789 2) Added a configuration knob that provides the end user with a way 790 to enable or disable the use of temporary addresses. 792 3) Under RFC 3041, RAs with short lifetimes (e.g., 1 hour) that 793 always send the same lifetime for long periods of time (e.g., days 794 to weeks) resulted in temporary addresses being created with 795 lifetimes of only 1 hour. Additional rules were added to increase 796 the Lifetime of temporary addresses when the advertised lifetimes 797 were short. 799 4) DAD is now run on all temporary addresses, not just the first one 800 generated from an interface identifier. 802 5) Changed the default setting for usage of temporary addresses to be 803 disabled. 805 9. Security Considerations 807 The motivation for this document stems from privacy concerns for 808 individuals. This document does not appear to add any security issues 809 beyond those already associated with stateless address 810 autoconfiguration [ADDRCONF]. 812 10. Acknowledgments 814 The authors would like to acknowledge the contributions of the IPNGWG 815 working group and, in particular, Ran Atkinson, Matt Crawford, Steve 816 Deering and Allison Mankin for their detailed comments. 818 11. References 820 [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 821 Architecture", RFC 2373, July 1998. 823 [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address 824 Autoconfiguration", RFC 2462, December 1998. 826 [ADDR_SELECT] Draves, R. "Default Address Selection for IPv6", draft- 827 ietf-ipngwg-default-addr-select-00.txt. 829 [COOKIES] Kristol, D. and L. Montulli, "HTTP State Management 830 Mechanism", RFC 2965, October 2000. 832 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 833 March 1997. 835 [DDNS] Vixie, R., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 836 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 837 April 1997. 839 [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 840 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 842 [GSE] Crawford et. al., "Separating Identifiers and Locators in 843 Addresses: An Analysis of the GSE Proposal for IPv6 ", draft- 844 ietf-ipngwg-esd-analysis-04.txt. 846 [ISATAP] "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", 847 draft-ietf-ngtrans-isatap-01.txt 849 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the 850 Internet Protocol", RFC 2401, November 1998. 852 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 853 1992. 855 [MOBILEIP] Perkins, C., "IP Mobility Support", RFC 2002, October 856 1996. 858 [ONION] Reed, Michael G., Paul F. Syverson and David M. Goldschlag. 859 "Proxies for Anonymous Routing", Proceedings of the 12th 860 Annual Computer Security Applications Conference, San Diego, 861 CA, December 1996. 863 [RANDOM] "Randomness Recommendations for Security", Eastlake 3rd, D., 864 Crocker S., Schiller, J., RFC 1750, December 1994. 866 [RFC3041] Privacy Extensions for Stateless Address Autoconfiguration 867 in IPv6. T. Narten, R. Draves. January 2001, RFC 3041. 869 [RESERVED-ANYCAST] Johnson, D., Deering, S., "Reserved IPv6 Subnet 870 Anycast Addresses", RFC 2526, March 1999. 872 [SERIALNUM] Moore, K., "Privacy Considerations for the Use of 873 Hardware Serial Numbers in End-to-End Network Protocols", 874 draft-iesg-serno-privacy-00.txt. 876 12. 877 Authors' Addresses 879 Thomas Narten 880 IBM Corporation 881 P.O. Box 12195 882 Research Triangle Park, NC 27709-2195 883 USA 885 Phone: +1 919 254 7798 886 EMail: narten@raleigh.ibm.com 887 Richard Draves 888 Microsoft Research 889 One Microsoft Way 890 Redmond, WA 98052 892 Phone: +1 425 936 2268 893 Email: richdr@microsoft.com