idnits 2.17.1 draft-krishnan-dhc-dhcpv6-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3462 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Mrugalski 5 Expires: April 30, 2015 ISC 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 October 27, 2014 10 Privacy considerations for DHCPv6 11 draft-krishnan-dhc-dhcpv6-privacy-00 13 Abstract 15 DHCPv6 is a protocol that is used to provide addressing and 16 configuration information to IPv6 hosts. This document discusses the 17 various identifiers used by DHCPv6 and the potential privacy issues. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Identifiers in DHCPv6 . . . . . . . . . . . . . . . . . . . . 3 56 3.1. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Client ID Option . . . . . . . . . . . . . . . . . . . . 4 58 3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 4 59 3.4. Interface ID . . . . . . . . . . . . . . . . . . . . . . 5 60 3.5. Subscriber ID . . . . . . . . . . . . . . . . . . . . . . 5 61 3.6. Remote ID . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.7. Client FQDN Option . . . . . . . . . . . . . . . . . . . 6 63 3.8. Client Link-layer Address Option . . . . . . . . . . . . 6 64 3.9. Option Request Option . . . . . . . . . . . . . . . . . . 6 65 3.10. Vendor Class Option . . . . . . . . . . . . . . . . . . . 6 66 3.11. Civic Location Option . . . . . . . . . . . . . . . . . . 7 67 3.12. Coordinate-Based Location Option . . . . . . . . . . . . 7 68 3.13. Client System Architecture Type Option . . . . . . . . . 7 69 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7 70 4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 7 71 4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 8 73 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Device type discovery (fingerprinting) . . . . . . . . . 9 75 5.2. Operating system discovery (fingerprinting) . . . . . . . 10 76 5.3. Finding location information . . . . . . . . . . . . . . 10 77 5.4. Finding previously visited networks . . . . . . . . . . . 10 78 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 10 79 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 10 80 5.7. Finding client's IP address or hostname . . . . . . . . . 11 81 5.8. Correlation of activities over time . . . . . . . . . . . 11 82 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 11 83 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 11 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 10.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 DHCPv6 [RFC3315] is a protocol that is used to provide addressing and 96 configuration information to IPv6 hosts. The DHCPv6 protocol uses 97 several identifiers that could become a source for gleaning 98 additional information about the IPv6 host. This information may 99 include device type, operating system information, location(s) that 100 the device may have previously visited, etc. This document discusses 101 the various identifiers used by DHCPv6 and the potential privacy 102 issues [RFC6973]. 104 Future works may propose protocol changes to fix the privacy issues 105 that have been analyzed in this document. It is out of scope for 106 this document. 108 Editor notes: for now, the document is mainly considering the privacy 109 of DHCPv6 client. The privacy of DHCPv6 server and relay agent are 110 considered less important because they are open for public services. 111 However, this may be a subject to change if further study shows 112 opposite result. 114 2. Terminology 116 This section clarifies the terminology used throughout this document. 118 Stable identifier - any property disclosed by a DHCPv6 client that 119 does not change over time or changes very infrequently and is unique 120 for said client in a given context. Examples include MAC address, 121 client-id that does not change or a hostname. Stable identifier may 122 or may not be globally unique. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. When these 127 words are not in ALL CAPS (such as "should" or "Should"), they have 128 their usual English meanings, and are not to be interpreted as 129 [RFC2119] key words. 131 3. Identifiers in DHCPv6 133 There are several identifiers used in DHCPv6. This section provides 134 an introduction to the various options that will be used further in 135 the document. 137 3.1. DUID 139 Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID) 140 [RFC3315]. The DUID is designed to be unique across all DHCPv6 141 clients and servers, and to remain stable after it has been initially 142 generated. The DUID can be of different forms. Commonly used forms 143 are based on the link-layer address of one of the device's network 144 interfaces (with or without a timestamp), on the Universally Unique 145 IDentifier (UUID) [RFC6355]. The default type, recommended by 146 [RFC3315], is DUID-LLT that is based on link-layer address, which is 147 commonly implemented in most popular clients. 149 It is important to understand DUID lifecycle. Clients and servers 150 are expected to generate their DUID once (during first operation) and 151 store it in a non-volatile storage or use the same deterministic 152 algorithm to generate the same DUID value again. This means that 153 most implementations will use the available link-layer address during 154 its first boot. Even if the administrator enables privacy extensions 155 (see [RFC4941]) and its equivalent for link-layer address 156 randomization, it is likely that those privacy mechanisms were 157 disabled during the first device boot. Hence the original, 158 unobfuscated link-layer address will likely end up being announced as 159 client DUID, even if the link-layer address has changed (or even if 160 being changed on a periodic basis). 162 3.2. Client ID Option 164 The Client Identifier Option (OPTION_CLIENTID) [RFC3315] is used to 165 carry the DUID of a DHCPv6 client between a client and a server. 166 There is an analogous Server Identifier Option but it is not as 167 interesting in the privacy context (unless a host can be convinced to 168 start acting as a server). Client ID is an example of DUID. See 169 Section 3.1 for relevant discussion about DUIDs. 171 3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options 173 The Identity Association for Non-temporary Addresses (IA_NA) option 174 [RFC3315] is used to carry the parameters and any non-temporary 175 addresses associated with the given IA_NA. The Identity Association 176 for Temporary Addresses (IA_TA) option [RFC3315] is analogous to the 177 IA_NA option but for temporary addresses. The IA Address option 178 [RFC3315] is used to specify IPv6 addresses associated with an IA_NA 179 or an IA_TA and is encapsulated within the Options field of such an 180 IA_NA or IA_TA option. The Identity Association for Prefix 181 Delegation (IA_PD) [RFC3633] option is used to carry the prefixes 182 that are assigned to the requesting router. IA Prefix option 183 [RFC3633] is used to specify IPv6 prefixes associated with an IA_PD 184 and is encapsulated within the Options field of such an IA_PD option. 186 To differentiate between instances of the same type of IA containers, 187 each IA_NA, IA_TA and IA_PD options have an IAID field that is unique 188 for each client/option type pair. It is up to the client to pick 189 unique IAID values. At least one popular implementation uses last 190 four octets of the link-layer address. In most cases, that means 191 that merely two bytes are missing for a full link-layer address 192 reconstruction. However, the first three octets in a typical link- 193 layer address are vendor identifier. That can be determined with 194 high level of certainty using other means, thus allowing full link- 195 layer address discovery. 197 3.4. Interface ID 199 A DHCPv6 relay includes the Interface ID [RFC3315] option to identify 200 the interface on which it received the client message that is being 201 relayed. 203 Although in principle Interface ID can be arbitrarily long with 204 completely random values, it is often a text string that includes the 205 relay agent name followed by interface name. This can be used for 206 fingerprinting the relay or determining client's point of attachment. 208 3.5. Subscriber ID 210 A DHCPv6 relay includes a Subscriber ID option [RFC4580] to associate 211 some provider-specific information with clients' DHCPv6 messages that 212 is independent of the physical network configuration. 214 In many deployments, the relay agent that inserts this option is 215 configured to use client's link-layer address as Subscriber ID. 217 3.6. Remote ID 219 A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the 220 remote host end of the circuit. 222 The remote-id is vendor specific, for which the vendor is indicated 223 in the enterprise-number field. The remote-id field may encode the 224 information that identified the DHCPv6 clients: 226 o a "caller ID" telephone number for dial-up connection 228 o a "user name" prompted for by a Remote Access Server 230 o a remote caller ATM address o a "modem ID" of a cable data modem 232 o the remote IP address of a point-to-point link 233 o an interface or port identifier 235 3.7. Client FQDN Option 237 The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is 238 used by DHCPv6 clients and servers to exchange information about the 239 client's fully qualified domain name and about who has the 240 responsibility for updating the DNS with the associated AAAA and PTR 241 RRs. 243 A client can use this option to convey all or part of its domain name 244 to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most 245 case a client sends its hostname as a hint for the server. The 246 DHCPv6 server MAY be configured to modify the supplied name or to 247 substitute a different name. The server should send its notion of 248 the complete FQDN for the client in the Domain Name field. 250 3.8. Client Link-layer Address Option 252 The Client link-layer address option [RFC6939] is used by first-hop 253 DHCPv6 relays to provide the client's link-layer address towards the 254 server. 256 DHCPv6 relay agents that receive messages originating from clients 257 may include the link-layer source address of the received DHCPv6 258 message in the Client Link-Layer Address option, in relayed DHCPv6 259 Relay-Forward messages. 261 3.9. Option Request Option 263 DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6 264 messages to inform the server about options the client wants the 265 server to send to the client. 267 The content of an Option Request option are the option codes for an 268 option requested by the client. The client may additionally include 269 instances of those options that are identified in the Option Request 270 option, with data values as hints to the server about parameter 271 values the client would like to have returned. 273 3.10. Vendor Class Option 275 This Vendor Class option [RFC3315] is used by a DHCPv6 client to 276 identify the vendor that manufactured the hardware on which the 277 client is running. 279 The information contained in the data area of this option is 280 contained in one or more opaque fields that identify details of the 281 hardware configuration, for example, the version of the operating 282 system the client is running or the amount of memory installed on the 283 client. 285 3.11. Civic Location Option 287 DHCPv6 servers use the Civic Location option [RFC4776] to delivery of 288 location information (the civic and postal addresses) from the DHCPv6 289 server to the DHCPv6 clients. It may refer to three locations: the 290 location of the DHCPv6 server, the location of the network element 291 believed to be closest to the client, or the location of the client, 292 identified by the "what" element within the option. 294 3.12. Coordinate-Based Location Option 296 The GeoLoc options [RFC6225] is used by DHCPv6 server to provide the 297 coordinate- based geographic location information to the DHCPv6 298 clients. It enable a DHCPv6 client to obtain its location. 300 After the relevant DHCPv6 exchanges have taken place, the location 301 information is stored on the end device rather than somewhere else, 302 where retrieving it might be difficult in practice. 304 3.13. Client System Architecture Type Option 306 The Client System Architecture Type option [RFC5970] is used by 307 DHCPv6 client to send a list of supported architecture types to the 308 DHCPv6 server. It is used to provide configuration information for a 309 node that must be booted using the network rather than from local 310 storage. 312 4. Existing Mechanisms That Affect Privacy 314 This section describes available DHCPv6 mechanisms that one can use 315 to protect or enhance one's privacy. 317 4.1. Temporary addresses 319 [RFC3315] defines a mechanism for a client to request temporary 320 addresses. The idea behind temporary addresses is that a client can 321 request a temporary address for a specific purpose, use it, and then 322 never renew it. i.e. let it expire. 324 There are number of serious issues, both protocolar and 325 implementational, that make them nearly useless for their original 326 goal. First, [RFC3315] does not include T1 and T2 renewal timers in 327 IA_TA (a container for temporary addresses). However, it mentions 328 that temporary addresses can be renewed. Many client implementations 329 renew those addresses during a renewal procedure initiated by other 330 resources (non-temporary addresses or prefixes), thus forfeiting 331 shortliveness. Second, [RFC4704] allows servers to update DNS for 332 assigned temporary addresses. Publishing client's IPv6 address in 333 DNS that is publicly available is a major privacy breach. 335 4.2. DNS Updates 337 DNS Updates [RFC4704] defines a mechanism that allows both clients 338 and server to insert into DNS domain information about clients. Both 339 forward (AAAA) and reverse (PTR) resource records can be updated. 340 This allows other nodes to conveniently refer to a host, despite the 341 fact that its IPv6 address may be changing. 343 This mechanism exposes two important pieces of information: current 344 address (which can be mapped to current location) and client's 345 hostname. The stable hostname can then by used to correlate the 346 client across different network attachments even when its IPv6 347 address keeps changing. 349 4.3. Allocation strategies 351 A DHCPv6 server running in typical, stateful mode is given a task of 352 managing one or more pools of IPv6 resources (currently non-temporary 353 addresses, temporary addresses and/or prefixes, but more resource 354 types may be defined in the future). When a client requests a 355 resource, server must pick a resource out of configured pool. 356 Depending on the server's implementation, various allocation 357 strategies are possible. Choices in this regard may have privacy 358 implications. 360 Iterative allocation - a server may choose to allocate addresses one 361 by one. That strategy has the benefit of being very fast, thus can 362 be favored in deployments that prefer performance. However, it makes 363 the resources very predictable. Also, since the resources allocated 364 tend to be clustered at the beginning of available pool, it makes 365 scanning attacks much easier. 367 Identifier-based allocation - a server may choose to allocate an 368 address that is based on one of available identifiers, e.g. IID or 369 MAC address. This has a property of being convenient for converting 370 IP address to/from other identifiers, especially if the identifier is 371 or contains MAC address. It is also convenient, as returning client 372 is very likely to get the same address, even if the server does not 373 store previous client's address. Those properties are convenient for 374 system administrators, so DHCPv6 server implementors are sometimes 375 requested to implement it. There is at least one implementation that 376 supports it. On the other hand, the downside of such allocation is 377 that the client now discloses its identifier in its IPv6 address to 378 all services it connects to. That means that correlation of 379 activities over time, location tracking, address scanning and OS/ 380 vendor discovery apply. 382 Hash allocation - it's an extension of identifier based allocation. 383 Instead of using the identifier directly, it is being hashed first. 384 If the hash is implemented correctly, it removes the flaw of 385 disclosing the identifier, a property that eliminates susceptibility 386 to address scanning and OS/vendor discovery. If the hash is poorly 387 implemented (e.g. can be reverted), it introduces no improvement over 388 identifier-based allocation. 390 Random allocation - a server can pick a resource randomly out of 391 available pool. That strategy works well in scenarios where pool 392 utilization is small, as the likelihood of collision (resulting in 393 the server needing to repeat randomization) is small. With the pool 394 allocation increasing, the collision is disproportionally large, due 395 to birthday paradox. With high pool utilization (e.g. when 90% of 396 available resources being allocated already), the server will use 397 most computational resources to repeatedly pick a random resource, 398 which will degrade its performance. This allocation scheme 399 essentially prevents returning clients from getting the same address 400 or prefix again. On the other hand, it is beneficial from privacy 401 perspective as addresses and prefixes generated that way are not 402 susceptible to correlation attacks, OS/vendor discovery attacks or 403 identity discovery attacks. Note that even though the address or 404 prefix itself may be resilient to a given attack, the client may 405 still be susceptible if additional information is disclosed other 406 way, e.g. client's address can be randomized, but it still can leak 407 its MAC address in client-id option. 409 Other allocation strategies may be implemented. 411 5. Attacks 413 5.1. Device type discovery (fingerprinting) 415 The type of device used by the client can be guessed by the attacker 416 using the Vendor Class option, the Client Link-layer Address option, 417 and by parsing the Client ID option. All of those options may 418 contain OUI (Organizationally Unique Identifier) that represents the 419 device's vendor. That knowledge can be used for device-specific 420 vulnerability exploitation attacks. See Section 3.4 of 421 [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion 422 about this type of attack. 424 5.2. Operating system discovery (fingerprinting) 426 The operating system running on a client can be guessed using the 427 Vendor Class option, the Client System Architecture Type option, or 428 by using fingerprinting techniques on the combination of options 429 requested using the Option Request option. See Section 3.4 of 430 [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion 431 about this type of attack. 433 5.3. Finding location information 435 The location information can be obtained by the attacker by many 436 means. The most direct way to obtain this information is by looking 437 into a server initiated message that contains the Civic Location or 438 GeoLoc option. It can also be indirectly inferred using the Remote 439 ID Option (e.g. using a telephone number), the Interface ID option 440 (e.g. if an access circuit on an Access Node corresponds to a civic 441 location), or the Subscriber ID Option (if the attacker has access to 442 subscriber info). 444 5.4. Finding previously visited networks 446 When DHCPv6 clients connect to a network, they attempt to obtain the 447 same address they had used before they attached to the network. They 448 do this by putting the previously assigned address(es) in the IA 449 Address Option(s) inside the IA_NA, IA_TA. By observing these 450 addresses, an attacker can identify the network the client had 451 previously visited. 453 5.5. Finding a stable identity 455 An attacker might use a stable identity gleaned from DHCPv6 messages 456 to correlate activities of a given client on unrelated networks. The 457 Client FQDN option, the Subscriber ID Option and the Client ID 458 options can serve as long lived identifiers of DHCPv6 clients. The 459 Client FQDN option can also provide an identity that can easily be 460 correlated with web server activity logs. 462 5.6. Pervasive monitoring 464 This is an enhancement, or a combination of most aforementioned 465 mechanisms. Operator, who controls non-trivial number of access 466 points or network segments, may use obtained information about a 467 single client and observer client's habits. 469 5.7. Finding client's IP address or hostname 471 Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's 472 information (current IP address, client's hostname). Client ID is 473 also disclosed, able it in not easily accessible form (SHA-256 digest 474 of the client-id). Although SHA-256 is irreversible, so DHCPv6 475 client ID can't be converted back to client-id. However, SHA-256 476 digest can be used as a unique identifier that is accessible by any 477 host. 479 5.8. Correlation of activities over time 481 As with other identifiers, an IPv6 address can be used to correlate 482 the activities of a host for at least as long as the lifetime of the 483 address. If that address was generated from some other, stable 484 identifier and that generation scheme can be deducted by an attacker, 485 the duration of correlation attack extends to that identifier. In 486 many cases, its lifetime is equal to the lifetime of the device 487 itself. See Section 3.1 of 488 [I-D.ietf-6man-ipv6-address-generation-privacy] for detailed 489 discussion. 491 5.9. Location tracking 493 If a stable identifier is used for assigning an address and such 494 mapping is discovered by an attacker (e.g. a server that uses IEEE- 495 identifier-based IID to generate IPv6 address), all scenarios 496 discussed in Section 3.2 of 497 [I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular 498 both passive (a service that the client connects to can log client's 499 address and draw conclusions regarding its location and movement 500 patterns based on prefix it is connecting from) and active (attacker 501 can send ICMPv6 echo requests or other probe packets to networks of 502 suspected client locations). 504 5.10. Leasequery & bulk leasequery 506 Attackers may pretend as an access concentrator, either DHCPv6 relay 507 agent or DHCPv6 client, to obtain location information directly from 508 the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism. 510 Location information is information needed by the access concentrator 511 to forward traffic to a broadband-accessible host. This information 512 includes knowledge of the host hardware address, the port or virtual 513 circuit that leads to the host, and/or the hardware address of the 514 intervening subscriber modem. 516 Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460] 517 mechanism to obtain bulk information about DHCPv6 bindings, even 518 without knowing the target bindings. 520 6. Security Considerations 522 TBD 524 7. Privacy Considerations 526 This document at its entirety discusses privacy considerations in 527 DHCPv6. As such, no separate section about this is needed. 529 8. IANA Considerations 531 This draft does not request any IANA action. 533 9. Acknowledgements 535 The authors would like to thanks the valuable comments made by 536 Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian 537 Schaefer and other members of DHC WG. 539 This document was produced using the xml2rfc tool [RFC2629]. 541 10. References 543 10.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 549 and M. Carney, "Dynamic Host Configuration Protocol for 550 IPv6 (DHCPv6)", RFC 3315, July 2003. 552 10.2. Informative References 554 [I-D.ietf-6man-ipv6-address-generation-privacy] 555 Cooper, A., Gont, F., and D. Thaler, "Privacy 556 Considerations for IPv6 Address Generation Mechanisms", 557 draft-ietf-6man-ipv6-address-generation-privacy-02 (work 558 in progress), October 2014. 560 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 561 June 1999. 563 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 564 Host Configuration Protocol (DHCP) version 6", RFC 3633, 565 December 2003. 567 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 568 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 569 2006. 571 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 572 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 573 2006. 575 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 576 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 577 Option", RFC 4704, October 2006. 579 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 580 (DHCPv4 and DHCPv6) Option for Civic Addresses 581 Configuration Information", RFC 4776, November 2006. 583 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 584 Extensions for Stateless Address Autoconfiguration in 585 IPv6", RFC 4941, September 2007. 587 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 588 "DHCPv6 Leasequery", RFC 5007, September 2007. 590 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 591 2009. 593 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 594 Options for Network Boot", RFC 5970, September 2010. 596 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 597 Host Configuration Protocol Options for Coordinate-Based 598 Location Configuration Information", RFC 6225, July 2011. 600 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 601 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 602 2011. 604 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 605 Address Option in DHCPv6", RFC 6939, May 2013. 607 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 608 Morris, J., Hansen, M., and R. Smith, "Privacy 609 Considerations for Internet Protocols", RFC 6973, July 610 2013. 612 Authors' Addresses 614 Suresh Krishnan 615 Ericsson 616 8400 Decarie Blvd. 617 Town of Mount Royal, QC 618 Canada 620 Phone: +1 514 345 7900 x42871 621 Email: suresh.krishnan@ericsson.com 623 Tomek Mrugalski 624 Internet Systems Consortium, Inc. 625 950 Charter Street 626 Redwood City, CA 94063 627 USA 629 Phone: +1 650 423 1345 630 Email: tomasz.mrugalski@gmail.com 632 Sheng Jiang 633 Huawei Technologies Co., Ltd 634 Q14, Huawei Campus, No.156 BeiQing Road 635 Hai-Dian District, Beijing 100095 636 P.R. China 638 Email: jiangsheng@huawei.com