RFC 7824

Privacy Considerations for DHCPv6

📅 published May 2016, from ietf

Privacy Considerations for DHCPv6 🎀

Bestie, this one's a whole vibe 💅 RFC 7824 is an Informational doc from the IETF, so it's a "here's what's going on" analysis and not a rulebook. It was published in May 2016 as ISSN 2070-1721. The authors are S. Krishnan (Ericsson), T. Mrugalski (ISC), and S. Jiang (Huawei Technologies Co., Ltd.). The title block doesn't list anything it obsoletes or updates. 🦋

The whole point is privacy: how the identifiers DHCPv6 passes around can leak stuff about you. 🫶

Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................4
   3. Identifiers in DHCPv6 Options and Fields ........................5
      3.1. Source IPv6 Address ........................................5
      3.2. DUID .......................................................5
      3.3. Client Identifier Option ...................................6
      3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options .....6
      3.5. Client FQDN Option .........................................6
      3.6. Client Link-Layer Address Option ...........................7
      3.7. Option Request Option ......................................7
      3.8. Vendor Class and Vendor-Specific Information Options .......7
      3.9. Civic Location Option ......................................8
      3.10. Coordinate-Based Location Option ..........................8
      3.11. Client System Architecture Type Option ....................8
      3.12. Relay Agent Options .......................................8
           3.12.1. Subscriber-ID Option ...............................9
           3.12.2. Interface ID Option ................................9
           3.12.3. Remote ID Option ...................................9
           3.12.4. Relay-ID Option ....................................9
   4. Existing Mechanisms That Affect Privacy ........................10
      4.1. Temporary Addresses .......................................10
      4.2. DNS Updates ...............................................10
      4.3. Allocation Strategies .....................................10
   5. Attacks ........................................................12
      5.1. Device Type Discovery (Fingerprinting) ....................12
      5.2. Operating System Discovery (Fingerprinting) ...............12
      5.3. Finding Location Information ..............................12
      5.4. Finding Previously Visited Networks .......................13
      5.5. Finding a Stable Identity .................................13
      5.6. Pervasive Monitoring ......................................13
      5.7. Finding a Client's IP Address or Hostname .................14
      5.8. Correlation of Activities over Time .......................14
      5.9. Location Tracking .........................................14
      5.10. Leasequery and Bulk Leasequery ...........................15
   6. Security Considerations ........................................15
   7. Privacy Considerations .........................................15
   8. References .....................................................16
      8.1. Normative References ......................................16
      8.2. Informative References ....................................16
   Acknowledgements ..................................................18
   Authors' Addresses ................................................18

Abstract

Okay so DHCPv6 is the protocol that hands IPv6 hosts their addressing and config info. This doc looks at the privacy problems that come with Internet users using DHCPv6. It's an analysis of where things stand right now, and it doesn't propose any fixes. 🔍

Status of This Memo

This document is not an Internet Standards Track specification. It's published purely for information. ✨

This document is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for more on that. 💅

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7824. 🌸

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these docs, because they spell out your rights and restrictions for this document. Code components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🫶

1. Introduction 🦋

DHCPv6 [RFC3315] is the protocol that hands IPv6 hosts their addressing and configuration info. It uses several identifiers that could be used to figure out stuff about the host. That stuff can include device type, operating system info, and the locations the device may have visited before, etc. 👀 This document goes through the identifiers DHCPv6 uses and the privacy issues they cause [RFC6973]. It also takes the problem of pervasive monitoring into account [RFC7258]. 💜

Future work might propose protocol changes to fix the privacy issues covered here. See [RFC7844] for one of those changes. Protocol changes are out of scope for this document. 🧚

The main focus here is privacy for clients, which matters for client mobility and for connecting to random networks. The privacy of DHCPv6 servers and relay agents is considered less important, since they're typically open for public services. It's also generally assumed that communication from the relay agent to the server is protected from casual snooping, because that traffic happens in the provider's backbone. Even so, relay agents and servers do get explored to some degree. Future work may want to dig further into the privacy of DHCPv6 servers and relay agents. 🌈

2. Terminology 📖

The naming conventions from [RFC3315] and other DHCPv6-related RFCs are used throughout this document. On top of that, there's one extra term:

  • Stable identifier: Any property disclosed by a DHCPv6 client that doesn't change over time, or changes very infrequently, and is unique for that client in a given context. Examples include the Media Access Control (MAC) address, the client-id, and a hostname. Some identifiers only count as stable under certain conditions. For example, one client implementation might keep its client-id in stable storage, while another generates it on the fly and uses a different one after each boot. Stable identifiers may or may not be globally unique. 🔑

3. Identifiers in DHCPv6 Options and Fields 🧩

In DHCPv6 there are a bunch of options that carry identification info, or that can be used to pull identification info about the client. This section lists those options and fields and the identifiers they carry, which can be used to disclose who the client is. The attacks those disclosures enable are detailed in Section 5. 😭

3.1. Source IPv6 Address 📍

Technically speaking, an IPv6 link-local address isn't part of DHCPv6. But it shows up in DHCPv6 transmissions, so it's mentioned here for completeness. 🙈

If the client doesn't use privacy extensions (see [RFC4941]) or similar solutions, and its IPv6 link-local address is based on a physical link-layer address, that info gets disclosed to the DHCPv6 server and to anyone who manages to intercept the transmission. 💀

IPv6 link-local addresses get used in DHCPv6 in multiple cases. Initial client transmissions always come from IPv6 link-local addresses, even when the server unicast option is enabled (see Sections 22.12 and 18 of [RFC3315] for details). If there are relay agents, they forward the client's traffic wrapped in Relay-forward, and they store the original source IPv6 address in the peer-address field. 🧃

3.2. DUID 🪪

Every DHCPv6 client and server has a DHCP Unique Identifier (DUID) [RFC3315]. The DUID is designed to be unique across all DHCPv6 clients and servers, and to stay stable once it's been generated. DUIDs can come in different forms. The commonly used ones are based on the link-layer address of one of the device's network interfaces (with or without a timestamp) [RFC3315], or on the Universally Unique IDentifier (UUID) [RFC6355]. The default type, defined in Section 9.2 of [RFC3315], is DUID-LLT, which is based on the link-layer address. Most popular clients implement it. ✨

The DUID life cycle matters here. Clients and servers are expected to generate their DUID once, during first operation, and then store it in non-volatile storage, or use the same deterministic algorithm to generate the same DUID value again. That means most implementations will use the available link-layer address during their first boot. Even if the administrator turns on link-layer address randomization, it's likely not enabled yet during that first boot. So the original, unobfuscated link-layer address will probably end up announced as the client DUID, even after the link-layer address has changed (or even if it's changed on a periodic basis). Exposing the original link-layer address in the DUID also undermines other privacy extensions, such as [RFC4941]. 😱

3.3. Client Identifier Option 🎟️

The Client Identifier option (OPTION_CLIENTID) [RFC3315] carries the DUID of a DHCPv6 client between a client and a server. There's also an analogous Server Identifier Option, but it isn't as interesting from a privacy standpoint, unless a host can be convinced to start acting as a server. For relevant discussion about DUIDs, see Section 3.2. 💖

3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options

okay so the Identity Association for Non-temporary Addresses (IA_NA) option [RFC3315] carries the parameters for an IA_NA plus any non-temporary addresses tied to it 🏠 the Identity Association for Temporary Addresses (IA_TA) option [RFC3315] is basically its cousin, just for temporary addresses 🦋 the IA Address option [RFC3315] names the IPv6 addresses inside an IA_NA or IA_TA, and it lives in the Options field of that container 📦 then there's the Identity Association for Prefix Delegation (IA_PD) option [RFC3633], which carries the prefixes handed to the requesting router 🌸 and the IA Prefix option [RFC3633] lists the IPv6 prefixes for an IA_PD, also tucked into its Options field ✨

to tell apart several IA containers of the same type for one client, each IA_NA, IA_TA, and IA_PD option has an IAID field. the value must be unique for a given IA type 🔑 the client gets to pick its own IAID values. one popular implementation uses the last four octets of the link-layer address 👀 ngl that means only two bytes are missing for a full link-layer address rebuild 😭 but the first three octets of a typical link-layer address are vendor identifiers, and those can be figured out with a high level of certainty using other means. so full link-layer address discovery becomes possible 💀

3.5. Client FQDN Option

the Client Fully Qualified Domain Name (FQDN) option [RFC4704] is how DHCPv6 clients and servers swap info about the client's FQDN and about who's responsible for updating DNS with the matching AAAA and PTR RRs 💅

a client can use this option to send all or part of its domain name to a DHCPv6 server for the IPv6-address-to-FQDN mapping. usually the client sends its hostname as a hint 🎀 the server might be set up to tweak that name or swap in a totally different one. the server should send its own idea of the complete FQDN for the client in the Domain Name field 🧚

the client link-layer address option [RFC6939] is used by first-hop DHCPv6 relays to pass the client's link-layer address along to the server 🔗

DHCPv6 relay agents that get messages from clients may put the link-layer source address of the received DHCPv6 message into the client link-layer address option, inside the relayed DHCPv6 Relay-forward messages 📨

3.7. Option Request Option

DHCPv6 clients put an Option Request option [RFC3315] in their messages to tell the server which options they'd like to get back 🙋‍♀️

the contents of an Option Request option are the option codes the client is asking for. the client may also include actual instances of those options, carrying data values as hints about the parameter values it'd love to receive 💜

3.8. Vendor Class and Vendor-Specific Information Options

the Vendor Class option, defined in Section 22.16 of [RFC3315], is how a DHCPv6 client says which vendor made the hardware it's running on 🖥️

the Vendor-specific information option, defined in Section 22.17 of [RFC3315], carries an enterprise number. that number identifies the client's vendor and often comes with extra vendor-specific parameters 🎁 it can hold basically any info the vendor thinks is useful. worth noting that this info may show up (and may be different) in both directions: client-to-server and server-to-client 🔄

the data area of this option has one or more opaque fields describing hardware details, like the version of the operating system the client runs or how much memory is installed 🧠

3.9. Civic Location Option

DHCPv6 servers use the Civic Location option [RFC4776] to send location info (civic and postal addresses) to DHCPv6 clients 🏡 it can point at three different places: the location of the DHCPv6 server, the location of the network element thought to be closest to the client, or the location of the client itself, which is identified by the "what" element inside the option 📍

3.10. Coordinate-Based Location Option

the GeoLoc options [RFC6225] let the DHCPv6 server hand out coordinate-based geographic location info to DHCPv6 clients 🌍 that's how a client can work out where it is 🗺️

3.11. Client System Architecture Type Option

the Client System Architecture Type option [RFC5970] is how the DHCPv6 client sends the server a list of architecture types it supports 🖱️ it's used by clients that have to boot over the network instead of from local storage, so the server can decide which boot file to give that client 💾

3.12. Relay Agent Options

a DHCPv6 relay agent can include a bunch of options, and those options can contain info that identifies the client 🕵️‍♀️ but they're almost exclusively swapped between the relay agent and the server, so they basically never leave the operator's network 🔒 especially, they're almost never present on the last wireless hop in WiFi networks. the one exception is the Relay-Supplied Options option [RFC6422], which is used somewhat infrequently. this means the threat-model-related relay options are a bit different ✨ sniffing traffic on the last hop and similar attacks typically don't apply. on the flip side, attacks that involve the operator's infrastructure (whether that's willing or coerced cooperation, or the infrastructure being compromised) usually do apply 😬

the subsections below describe the various options that relay agents insert 🧩

3.12.1. Subscriber-ID Option

a DHCPv6 relay may include a Subscriber-ID option [RFC4580] to attach some provider-specific info to the clients' DHCPv6 messages. this info doesn't depend on the physical network configuration 📡

in lots of deployments, the relay agent that inserts this option is set up to use the client's link-layer address as the Subscriber-ID 👀

3.12.2. Interface ID Option

a DHCPv6 relay includes the Interface ID option [RFC3315] to identify the interface where it got the client message it's relaying 🔌

the Interface ID can technically be arbitrarily long with totally random values. but it's sometimes a text string that combines the relay agent name with the interface name 😭 that can be used for fingerprinting the relay, or for figuring out a client's point of attachment 🎯

3.12.3. Remote ID Option

a DHCPv6 relay includes a Remote ID option [RFC4649] to identify the remote host end of the circuit 🛰️

the remote-id is vendor specific, and the vendor is shown in the enterprise-number field. the remote-id field may encode the info that identified DHCPv6 clients, such as:

  • a "caller ID" telephone number for a dial-up connection
  • a "user name" prompted for by a Remote Access Server
  • a remote caller ATM address
  • a "modem ID" of a cable data modem
  • the remote IP address of a point-to-point link
  • an interface or port identifier

3.12.4. Relay-ID Option

a relay agent may include a Relay-ID option [RFC5460], which holds a unique relay agent identifier 🆔 its main job is to give the server extra info so it can answer leasequery requests later 📚 but this info can also be used to pin down a client's location within the network 📍

4. Existing Mechanisms That Affect Privacy ✨

this section covers deployed DHCPv6 mechanisms that can affect privacy 🫣

4.1. Temporary Addresses

[RFC3315] defines a way for a client to request temporary addresses 🦋 the whole idea is that a client can ask for a temporary address for one specific purpose, use it, and then never renew it (in other words, let it expire) 💨

there are a bunch of serious issues, both in the protocol and in its implementations, that make temporary addresses almost useless for their original goal 💀 first, [RFC3315] doesn't include T1 and T2 renewal timers in IA_TA (the container for temporary addresses). but Section 18.1.3 does explicitly say temporary addresses can be renewed 🙃 client implementations may accidentally renew temporary addresses if they aren't careful. that happens when they include the IA_TA with the same IAID in Renew or Rebind requests, instead of using a new IAID (see Section 22.5 of [RFC3315]), and that throws away the short liveness 😩 [RFC4704] doesn't explicitly stop servers from updating DNS for assigned temporary addresses, and some implementations can be configured to do exactly that. however, this is not advised, because publishing a client's IPv6 address in publicly available DNS is a major privacy breach 🚨

4.2. DNS Updates

the Client FQDN option [RFC4704] used together with DNS UPDATE [RFC2136] lets both clients and the server insert info about clients into the DNS domain 🌐 both forward (AAAA) and reverse (PTR) resource records can be updated. this is convenient because other nodes can refer to a host even though its IPv6 address might be changing 🔁

this mechanism exposes two important pieces of info: the current address (which can be mapped to the current location) and the client's hostname 👑 the stable hostname can then be used to correlate the client across different network attachments, even when its IPv6 address keeps changing 🕵️‍♀️💖

4.3. Allocation Strategies 🎀

okay so a DHCPv6 server doing its usual stateful thing is basically managing one or more pools of IPv6 resources. Right now that means non-temporary addresses, temporary addresses, and/or prefixes, but more resource types could show up later 👀. When a client asks for something, the server has to pick one out of the configured pool. How it picks depends on the implementation, and there are a few different strategies. Some of those choices can have privacy implications, so it matters 🫶

  • Iterative allocation: the server hands out addresses one by one. This is super fast, so it's a favorite in deployments that care most about performance. The catch is that the resources become very predictable. The allocated ones also tend to cluster at the start of an available pool, which makes scanning attacks way easier 💀
  • Identifier-based allocation: some server implementations give a specific client a fixed identifier. It seems to be taken from the client's MAC address when that's available, or from some lower bits of the client's source IPv6 address. This is really convenient for converting an IP address to and from other identifiers, especially if the identifier is or contains a MAC address. It's also convenient because a returning client will very likely get the same address again, even if the server doesn't remember the client's previous address. Sysadmins love that, so DHCPv6 server implementors are sometimes asked to build it. At least one implementation does. The downside is that the client now shows its identifier inside its IPv6 address to every service it connects to. So attacks related to correlating activity over time, location tracking, address scanning, and OS/vendor discovery all apply 😭
  • Hash allocation: this is basically an upgraded version of identifier-based allocation. Instead of using the identifier directly, the server hashes it first. If the hash is implemented correctly, the identifier doesn't get disclosed, which means no susceptibility to address scanning or OS/vendor discovery. If the hash is poorly implemented (for example, it can be reversed), it's no better than plain identifier-based allocation. Even a well-implemented hash doesn't stop the threat of correlation over time 🙈
  • Random allocation: the server can pick a resource pseudorandomly out of an available pool. This basically stops returning clients from getting the same address or prefix again. The plus side is that it's great for privacy, since addresses and prefixes generated this way aren't susceptible to correlation attacks, OS/vendor discovery attacks, or identity discovery attacks ✨. But heads up, bestie: even if the address or prefix itself is resilient to a given attack, the client can still be vulnerable if extra information leaks some other way. For example, the client's address might be randomized, but it can still leak its MAC address in the Client Identifier option 👀

Other allocation strategies may be implemented too 💅

5. Attacks 💀

5.1. Device Type Discovery (Fingerprinting) 🔍

The attacker can guess what type of device the client is using. They can do this through the Vendor Class option, the Vendor-specific information option, the client link-layer address option, and by parsing the Client Identifier option. All of these can contain an OUI (Organizationally Unique Identifier) that represents the device's vendor. And once you know the vendor, you can use that for device-specific vulnerability exploitation attacks. Yikes 😭 See Section 3.4 of [RFC7721] for a discussion of this type of attack.

5.2. Operating System Discovery (Fingerprinting) 🖥️

An attacker can guess the operating system running on a client using the Vendor Class option, the Vendor-specific information option, or the Client System Architecture Type option. They can also use fingerprinting techniques on the combination of options requested through the Option Request option. Main character detective energy 🕵️‍♀️

5.3. Finding Location Information 📍

Physical location information can be obtained by an attacker in lots of ways. The most direct one is looking at a message from the server that contains the Civic Location or GeoLoc options. The location can also be inferred indirectly from the Remote ID option, the Interface ID option (for example, if an access circuit on an Access Node corresponds to a civic location), or the Subscriber-ID option (if the attacker has access to subscriber info) 🫣

Another way to find a client's physical location is geolocation services. These services usually map IP prefixes to geographical locations. They're typically based on known locations of the subnet, so they may reveal a client's location down to the extent of the network it's connected to, if they can figure out what network that is. But they usually can't pin down the specific physical location within a network. That isn't always true, though. It depends on the quality of the a priori information in the geolocation services databases. It's also worth noting that this threat is general to the DHCPv6 mechanism. No matter what allocation strategy the DHCPv6 server implementation uses, the assigned addresses will always belong to the subnet the server is configured to manage. And using ULAs (Unique Local Addresses) assigned by the DHCPv6 server is out of scope for this document 🌸

5.4. Finding Previously Visited Networks 🗺️

When DHCPv6 clients reconnect to a network, they try to get the same address they used the last time they attached to it. They do this by putting the previously assigned address(es) in the IA Address option(s). [RFC3315] doesn't rule out IA_TA in that situation, so a client implementation might include an address from an IA_TA in its Confirm message. By watching these addresses, an attacker can figure out which networks the client has visited before 👀

5.5. Finding a Stable Identity 🪪

An attacker might take a stable identity from DHCPv6 messages and use it to link a client's activities across unrelated networks. The Client FQDN option, the Subscriber-ID option, and the Client ID option can all act as long-lived identifiers for DHCPv6 clients. The Client FQDN option can also give an identity that's easy to match up with web server activity logs 😭

In general, MAC addresses aren't actually in the DHCPv6 packets, so they can't be used directly in a reliable way. But they can end up available indirectly through other mechanisms. The client-id contains the link-local address if DUID-LL or DUID-LLT types are used. The source IPv6 address may use an EUI-64 that contains a MAC address. Some access technologies put a MAC address in dedicated options, like cable modems using MAC addresses in Data Over Cable Service Interface Specification (DOCSIS) options. Relay agents may also insert extra information to help the server identify the client. That could be the Remote-Id option, the Subscriber-ID option, the client link-layer address option, or Vendor-specific information options. Options inserted by relay agents usually only travel the relay-server path, so they typically can't be eavesdropped by intercepting the client's transmissions. This depends on the actual deployment model and the access technologies used 🧐

5.6. Pervasive Monitoring 👁️

Pervasive Monitoring (PM) is widespread (and often covert) surveillance done through intrusive gathering of protocol artifacts. That includes application content or protocol metadata such as headers. Active or passive wiretaps and traffic analysis (for example, correlation, timing, or measuring packet sizes) can be used as part of pervasive monitoring, and so can subverting the cryptographic keys used to secure protocols. PM is distinguished by being indiscriminate and very large scale. It doesn't necessarily introduce new types of technical compromise. See [RFC7258] for a discussion of PM 😱

In the DHCPv6 context, PM can be used to collect any of the identifiers discussed in Section 3. DHCPv4 and DHCPv6 are especially susceptible, because the initial message sent (SOLICIT in the case of DHCPv6) is one of the very first packets sent when visiting a network. In certain cases, this packet can also be logged even on networks that don't support IPv6. Some implementations initiate DHCPv6 even without receiving an RA with the M or O bits set. This can be an easily overlooked attack vector when an IPv6-capable device connects to an IPv4-only network, gets only IPv4 connectivity, but still leaks its stable identifiers over DHCPv6 🚨

Using the PM approach, the attacks discussed in Sections 5.1, 5.2, 5.3, 5.4, 5.5, 5.7, 5.8, and possibly 5.9 all apply 🫶

5.7. Finding a Client's IP Address or Hostname 🌐

Lots of DHCPv6 deployments use DNS Updates [RFC4704], which put a client's information (current IP address and hostname) into the DNS, where anyone interested can easily access it. The Client ID is disclosed too, though not in an easily accessible form. It's a SHA-256 digest of the client-id. SHA-256 is considered irreversible, so the DHCID can't be converted back into the client-id. Still, the SHA-256 digest can be used as a unique identifier that any host can access 🥺

5.8. Correlation of Activities over Time ⏳

Like other identifiers, an IPv6 address can be used to correlate a host's activities for at least as long as the address lives. If the address was generated from some other stable identifier, and an attacker can work out how that generation scheme works, the correlation attack lasts as long as that identifier does. In many cases, that lifetime equals the lifetime of the device itself. See Section 3.1 of [RFC7721] for a detailed discussion 💜

5.9. Location Tracking 📡

If a stable identifier is used to assign an address, and an attacker discovers that mapping (for example, a server that uses an IEEE-identifier-based IID to generate an IPv6 address), then all the scenarios discussed in Section 3.2 of [RFC7721] apply. In particular, both passive and active attacks can be used. Passively, a service the client connects to can log the client's address and draw conclusions about its location and movement patterns from the prefix it's connecting from. Actively, an attacker can send ICMPv6 echo requests or other probe packets to networks of suspected client locations 🕵️

Here's a specific example: by accessing a social portal from tomek-laptop.coffee.somecity.com.example, tomek-laptop.mycompany.com.example, and tomek-laptop.myisp.example.com, the portal administrator can draw conclusions about tomek-laptop's owner's current location and habits. Nobody is safe from the group chat 💀✨

5.10. Leasequery and Bulk Leasequery ✨

okay so bestie, this one is a whole vibe 😭🔥 attackers can pretend to be an access concentrator, either as a DHCPv6 relay agent or as a DHCPv6 client, and then just ask the DHCPv6 server(s) for location info using the DHCPv6 Leasequery [RFC5007] mechanism 🕵️‍♀️💀

And what counts as location info? It's the stuff the access concentrator needs to forward traffic to a broadband-accessible host 🗺️ That includes the host's hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem. Literally a whole map 📍

It gets worse, ngl 🙈 Attackers can also use DHCPv6 bulk leasequery [RFC5460] to pull bulk info about DHCPv6 bindings, even if they don't know which bindings they're after. Main character energy for the wrong reasons 💅

Then there's active leasequery [RFC7653] 🦋 It lets you subscribe to DHCPv6 lease update changes in near real-time. The whole point is to keep an operator's database up to date ✨ But if somebody misuses it, an attacker could get past the server's authentication mechanisms and subscribe to all the updates. And then they can keep receiving them with no need to be physically present 😱 Not it!

6. Security Considerations 🔐

In current practice, client privacy and client authentication are mutually exclusive 🙃 The client authentication procedure reveals extra client information in their certificates and identifiers 🪪 Full privacy can mean the clients are also anonymous to the server and the network, so it's a real trade-off, bestie 🫶

7. Privacy Considerations 🌸

This document in its entirety discusses privacy considerations in DHCPv6 ✨ So no dedicated discussion is needed. Everything's already covered, we're iconic 💖

8. References 📚

8.1. Normative References 💜

[RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
           C., and M. Carney, "Dynamic Host Configuration Protocol
           for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
           2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <http://www.rfc-editor.org/info/rfc6973>.

[RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
           Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
           2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
           Considerations for IPv6 Address Generation Mechanisms",
           RFC 7721, DOI 10.17487/RFC7721, March 2016,
           <http://www.rfc-editor.org/info/rfc7721>.

8.2. Informative References 🧠

[RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
           "Dynamic Updates in the Domain Name System (DNS UPDATE)",
           RFC 2136, DOI 10.17487/RFC2136, April 1997,
           <http://www.rfc-editor.org/info/rfc2136>.

[RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
           Host Configuration Protocol (DHCP) version 6", RFC 3633,
           DOI 10.17487/RFC3633, December 2003,
           <http://www.rfc-editor.org/info/rfc3633>.

[RFC4580]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
           (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
           DOI 10.17487/RFC4580, June 2006,
           <http://www.rfc-editor.org/info/rfc4580>.

[RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
           (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
           DOI 10.17487/RFC4649, August 2006,
           <http://www.rfc-editor.org/info/rfc4649>.

[RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
           IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
           Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
           <http://www.rfc-editor.org/info/rfc4704>.

[RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
           (DHCPv4 and DHCPv6) Option for Civic Addresses
           Configuration Information", RFC 4776,
           DOI 10.17487/RFC4776, November 2006,
           <http://www.rfc-editor.org/info/rfc4776>.

[RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
           Extensions for Stateless Address Autoconfiguration in
           IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
           <http://www.rfc-editor.org/info/rfc4941>.

[RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
           "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
           September 2007, <http://www.rfc-editor.org/info/rfc5007>.

[RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
           DOI 10.17487/RFC5460, February 2009,
           <http://www.rfc-editor.org/info/rfc5460>.

[RFC5970]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
           Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970,
           September 2010, <http://www.rfc-editor.org/info/rfc5970>.

[RFC6225]  Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
           "Dynamic Host Configuration Protocol Options for
           Coordinate-Based Location Configuration Information",
           RFC 6225, DOI 10.17487/RFC6225, July 2011,
           <http://www.rfc-editor.org/info/rfc6225>.

[RFC6355]  Narten, T. and J. Johnson, "Definition of the UUID-Based
           DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
           DOI 10.17487/RFC6355, August 2011,
           <http://www.rfc-editor.org/info/rfc6355>.

[RFC6422]  Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
           RFC 6422, DOI 10.17487/RFC6422, December 2011,
           <http://www.rfc-editor.org/info/rfc6422>.

[RFC6939]  Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
           Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
           May 2013, <http://www.rfc-editor.org/info/rfc6939>.

[RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
           Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
           October 2015, <http://www.rfc-editor.org/info/rfc7653>.

[RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
           Profile for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844,
           May 2016, <http://www.rfc-editor.org/info/rfc7844>.

Acknowledgements 🫶

Huge thank-yous from the authors to Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Schaefer, Jinmei Tatuya, Bernie Volz, Marcin Siodelski, Christian Huitema, Brian Haberman, Robert Sparks, Peter Yee, Ben Campbell, and other members of DHC WG for their valuable comments 💖✨ The squad really came through 👑

Authors' Addresses 🦋

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

Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com


Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA  94063
United States

Email: tomasz.mrugalski@gmail.com


Sheng Jiang
Huawei Technologies Co., Ltd.
Q14, Huawei Campus, No.156 BeiQing Road
Hai-Dian District, Beijing  100095
China

Email: jiangsheng@huawei.com
📦 where this page comes from