RFC 7819

Privacy Considerations for DHCP

📅 published April 2016, from ietf

RFC 7819: Privacy Considerations for DHCP 🎀

okay bestie, this is an IETF RFC (basically the official Internet Engineering Task Force docs that define how internet stuff works 🌸). The title block says it's RFC 7819, written by S. Jiang (Huawei Technologies Co., Ltd), S. Krishnan (Ericsson), and T. Mrugalski (ISC). It came out in April 2016 as an Informational doc, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates 💅

Abstract ✨

okay so DHCP is the protocol that hands out addresses and config info to IPv4 hosts 🧚 This doc looks at the different identifiers DHCP uses and the privacy problems they can cause 👀

Status of This Memo 📋

this one is not an Internet Standards Track spec. It's published just for info 💖

It's an IETF product with the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🫶

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7819 🌈

Copyright Notice 🔥

This doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were on the publication date. Read them carefully, because they explain your rights and restrictions for this doc 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🎀

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements Language and Terminology . . . . . . . . . . . .   3
3.  DHCP Options Carrying Identifiers . . . . . . . . . . . . . .   4
  3.1.  Client Identifier Option  . . . . . . . . . . . . . . . .   4
  3.2.  Address Fields and Options  . . . . . . . . . . . . . . .   4
  3.3.  Client FQDN Option  . . . . . . . . . . . . . . . . . . .   5
  3.4.  Parameter Request List Option . . . . . . . . . . . . . .   5
  3.5.  Vendor Class and Vendor-Identifying Vendor Class Options    5
  3.6.  Civic Location Option . . . . . . . . . . . . . . . . . .   6
  3.7.  Coordinate-Based Location Option  . . . . . . . . . . . .   6
  3.8.  Client System Architecture Type Option  . . . . . . . . .   6
  3.9.  Relay Agent Information Option and Suboptions . . . . . .   6
4.  Existing Mechanisms That Affect Privacy . . . . . . . . . . .   7
  4.1.  DNS Updates . . . . . . . . . . . . . . . . . . . . . . .   7
  4.2.  Allocation Strategies . . . . . . . . . . . . . . . . . .   7
5.  Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
  5.1.  Device Type Discovery . . . . . . . . . . . . . . . . . .   9
  5.2.  Operating System Discovery  . . . . . . . . . . . . . . .   9
  5.3.  Finding Location Information  . . . . . . . . . . . . . .   9
  5.4.  Finding Previously Visited Networks . . . . . . . . . . .   9
  5.5.  Finding a Stable Identity . . . . . . . . . . . . . . . .   9
  5.6.  Pervasive Monitoring  . . . . . . . . . . . . . . . . . .  10
  5.7.  Finding Client's IP Address or Hostname . . . . . . . . .  10
  5.8.  Correlation of Activities over Time . . . . . . . . . . .  10
  5.9.  Location Tracking . . . . . . . . . . . . . . . . . . . .  10
  5.10. Leasequery and Bulk Leasequery  . . . . . . . . . . . . .  11
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction 🦋

okay so DHCP ([RFC2131]) gives IPv4 hosts their addressing and config info. The catch is that DHCP uses a bunch of identifiers that can leak info about the host 👀 That info could include the device type, the OS, and places the device has been before, etc. This doc goes through those identifiers and the privacy issues they cause [RFC6973]. It also specifically thinks about pervasive monitoring [RFC7258] 🕵️‍♀️

future works might propose protocol changes to fix the privacy issues covered here, but those changes are out of scope for this doc 🙅‍♀️

the main focus is privacy for clients, since they're the ones doing mobility and connecting to random networks 📱 Privacy for DHCP servers and relay agents matters less, because they're usually open for public services. It's also generally assumed that relay-to-server traffic is safe from casual snooping, since it happens inside the provider's backbone 🏢 Still, the doc explores relay agents and servers to some degree. Future work may want to dig deeper into their privacy 🫶

2. Requirements Language and Terminology 📚

naming conventions from [RFC2131] and related docs are used all the way through this one 💅

on top of that, we use this term:

Stable identifier: any property a DHCP client discloses that doesn't change over time (or changes super rarely), and that is unique for that client in a given context. Examples are the MAC address, client-id, and 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. DHCP Options Carrying Identifiers 🎀

okay so DHCP has a few options that either hold identification info or can be used to pull identification info about the client. This section lists those options, the identifiers they carry, and how those identifiers can reveal who the client is 🕵️ These options are the targets of the attacks analyzed in Section 5 🎯

3.1. Client Identifier Option 🪪

the Client Identifier option [RFC2131] passes an explicit client identifier to a DHCP server 💌

the client identifier is an opaque key that must be unique to that client within the subnet it's attached to. It typically stays stable once it's been generated at first. It may contain a hardware address, identical to the contents of the chaddr field, or another kind of identifier, like a DNS name 🏷️ Section 9.2 of [RFC3315] names DUID-LLT (Link-layer plus time) as the recommended DUID (DHCP Unique Identifier) type in DHCPv6 🌸 Section 6.1 of [RFC4361] brings this concept into DHCP 💖 Both of those docs recommend that client identifiers be generated from the permanent link-layer address of the network interface the client is trying to configure 😬

[RFC4361] updates that recommendation for a Client Identifier like this: "[it] consists of a type field whose value is normally 255, followed by a four-byte IA_ID field, followed by the DUID for the client as defined in RFC 3315, section 9". This doesn't change the lifecycle of client identifiers. Clients are expected to generate their client identifiers once (during first operation) and store them in non-volatile storage, or use the same deterministic algorithm to generate the same values again 🧠

so typically an implementation uses the available link-layer address during its first boot. Even if the admin 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 being announced as the client identifier, even if the link-layer address has changed since (or even if it's being changed on a periodic basis) 🙈 Exposing that original address in the client identifier also undermines other privacy extensions, like [RFC4941] 💀

3.2. Address Fields and Options 🏠

the yiaddr field [RFC2131] in a DHCP message conveys an allocated address from the server to the client 📮

the DHCP spec [RFC2131] also gives a way to specify the client link-layer address in the DHCP message header. The header has htype and chaddr fields, which specify the client's link-layer address type and the link-layer address itself, respectively 🧾 The chaddr field is used both as a hardware address for sending reply messages and as a client identifier 🔁

the requested IP address option [RFC2131] is how a client suggests that a particular IP address be assigned 🙏

3.3. Client FQDN Option 🌐

the Client Fully Qualified Domain Name (FQDN) option [RFC4702] is how DHCP clients and servers swap info about the client's FQDN, and about who's responsible for updating the DNS with the matching A and PTR RRs 📇

a client can use this option to send all or part of its domain name to a DHCP server, for the IP-address-to-FQDN mapping. Most of the time, a client sends its hostname as a hint for the server 💬 The DHCP server might be configured to change the name it gets 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 🎯

3.4. Parameter Request List Option 📝

the Parameter Request List option [RFC2131] tells the server which options the client wants sent back to it 💁‍♀️ Its contents are the option codes of the options the client asked for 🔢

3.5. Vendor Class and Vendor-Identifying Vendor Class Options 🏭

the Vendor Class option [RFC2131], the Vendor-Identifying Vendor Class option, and the Vendor-Identifying Vendor Information option [RFC3925] are how a DHCP client identifies the vendor who made the hardware it's running on 🖥️

the info in the data area of this option sits in one or more opaque fields. Those fields identify the details of the host's hardware configuration, or industry consortium compliance. Examples are the version of the OS the client is running, or how much memory is installed on the client 🧠💾 That's a lot of detail to hand over, bestie 😭🔥

3.6. Civic Location Option

okay so the Civic Location Option is how DHCP servers hand clients location info in the form of civic and postal addresses 🏡💌 [RFC4776] is where it's defined. ngl it's giving "here's where you are, bestie" 📍 It can point to three different places: where the DHCP server lives, where the network element closest to the client is, or where the client itself is, which is the "what" element inside the option 🧚

3.7. Coordinate-Based Location Option

the GeoConf and GeoLoc options [RFC6225] are how a DHCP server gives clients coordinate-based geographic location info 🗺️✨ so the client can work out its own geographic location. literally the GPS-coded version of the civic one 💜

3.8. Client System Architecture Type Option

the Client System Architecture Type Option [RFC4578] is how a DHCP client tells 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 pick which boot file to send over. the main character of netbooting 🎀

3.9. Relay Agent Information Option and Suboptions

okay this one is a whole vibe 🌸 a DHCP relay agent adds a Relay Agent Information option [RFC3046] to figure out the remote host end of the circuit. it has a "circuit ID" suboption, which is the agent-local identifier of the circuit a client-to-server packet came in on, and a "remote ID" suboption that gives a trusted identifier for the remote high-speed modem 🦋

the circuit ID can be encoded as things like a router interface number, a switching hub port number, a remote access server port number, a frame relay Data Link Connection Identifier (DLCI), an ATM virtual circuit number, a cable data virtual circuit number, and so on 🧚

the remote ID can be encoded as things like a "caller ID" telephone number for dial-up, a "user name" a remote access server asks for, a remote caller's ATM address, a "modem ID" for a cable data modem, the remote IP address of a point-to-point link, a remote X.25 address for X.25 connections, and so on 📞

the link-selection suboption [RFC3527] is for when a relay agent wants to specify a subnet or link for a client request it's relaying, but that subnet or link needs to be different from the IP address the DHCP server uses to talk to the relay agent 🫶 it holds an IP address that can identify the client's subnet or link. and if you know the network topology, it also reveals where the client is. ngl that's a big deal 👀

a DHCP relay includes a Subscriber-ID option [RFC3993] to attach some provider-specific info to a client's DHCP messages, and that info doesn't depend on the physical network the subscriber connects through 💅 the "subscriber-id" the provider assigns is meant to stay stable as customers connect through different paths and as the network changes. it's an ASCII string that the network provider assigns and configures 🎀

Existing Mechanisms That Affect Privacy

this section is about the DHCP mechanisms that are already out there in the wild and affect privacy 🔥

4.1. DNS Updates

okay so the Client FQDN (Fully Qualified Domain Name) Option [RFC4702] works together with DNS Updates [RFC2136] 💖 and it lets both clients and servers put info about clients into the DNS domain. both forward (A) and reverse (PTR) resource records can get updated. this is super handy because other nodes can refer to a host even when its IP address keeps changing 🦋

but it exposes two big things: the current address (which can be mapped to current location) and the client's hostname 😭 that stable hostname can then be used to correlate the client across different network attachments, even when its IP addresses keep changing. not me getting tracked by my own hostname 💀

4.2. Allocation Strategies

so a DHCP server running in typical stateful mode has the job of managing one or more pools of IP addresses 🏡 when a client asks for an address, the server MUST pick one out of a configured pool. (see, the pool is the thing that matters.) depending on the server's implementation, there are various allocation strategies, and the choices can have privacy implications 🔍 the constraints in DHCP and DHCPv6 are radically different, but servers that let you configure the allocation strategy might let you configure it in both. not every strategy is equally suitable for DHCP and DHCPv6 💅

Iterative allocation

okay so the server may hand out addresses one by one 🧚 that's super fast, which is why it's favored where performance matters. BUT the addresses come out very predictable, and since they tend to cluster at the start of an available pool, scanning attacks become way easier 👀

Identifier-based allocation

some servers may allocate an address based on one of the available identifiers, like the client identifier or the MAC address 🎀 it's convenient because a returning client is very likely to get the same address back. admins love that, so DHCP server implementers are often asked to build it. the downside is that the client gets a very stable IP address 😬 that means correlating activities over time, location tracking, address scanning, and OS/vendor discovery all apply. this is definitely an issue in DHCPv6, but because the address space is so much smaller, it's almost never a problem in DHCP 🌸

Hash allocation

this is basically identifier-based allocation with a twist: the identifier gets hashed first instead of being used directly 🔮 if the hash is implemented correctly, it removes the flaw of disclosing the identifier, and that gets rid of the susceptibility to address scanning and OS/vendor discovery ✨ but if the hash is poorly implemented (say, it can be reversed), it's no improvement over identifier-based allocation at all 💀

Random allocation

the server can pick a resource randomly out of an available pool 🎲 this basically stops returning clients from getting the same address again 😭 but it's a privacy win, because addresses generated this way aren't susceptible to correlation attacks, OS/vendor discovery attacks, or identity discovery attacks 💜 still, even if the address itself holds up against an attack, the client can still be exposed if extra info leaks another way. e.g., the client's address may be randomized, but it can still leak its MAC address in the Client Identifier option 🙈

other allocation strategies may also be implemented 🌈

ngl, given how small most IPv4 public address pools are, IPv4 allocation mechanisms may not give much privacy protection or leak much useful info if they're misused 🍓

Attacks

yikes, this section is the scary part 😭

5.1. Device Type Discovery

an attacker can guess the device type the client uses from the Vendor Class Option, the 'chaddr' field, and by parsing the Client ID Option 👀 all of those can contain an Organizationally Unique Identifier (OUI) that represents the device's vendor. and that knowledge can be used for device-specific vulnerability exploitation attacks 💀

5.2. Operating System Discovery

an attacker can guess the OS running on a client from the Vendor Class option, the Client System Architecture Type option, or by fingerprinting the combination of options requested in the Parameter Request List option 🔍

5.3. Finding Location Information

an attacker can get location info in lots of ways 😬 the most direct way is by looking at a message from the server that contains the Civic Location, GeoConf, or GeoLoc options. it can also be inferred indirectly from the Relay Agent Information option, using the remote ID suboption, the circuit ID option (for example, if an access circuit on an Access Node matches a civic location), or the Subscriber ID Option (if the attacker has access to subscriber info) 🗺️

5.4. Finding Previously Visited Networks

when DHCP clients connect to a network, they try to get the same address they used before they attached to it 🔁 they do this by putting the previously assigned address in the requested IP address option. so by watching these addresses, an attacker can figure out which network the client visited before 👀

5.5. Finding a Stable Identity

an attacker might use a stable identity picked up from DHCP messages to correlate 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 DHCP clients. the Client FQDN option can also give an identity that's easy to correlate with web server activity logs 📝

5.6. Pervasive Monitoring

pervasive monitoring [RFC7258] is widespread (and often covert) surveillance through intrusive gathering of protocol artifacts, including application content or protocol metadata like headers 😱 an operator who controls a bunch of access points or network segments can use info it got about one client and watch that client's habits. even though users may not expect true privacy from their operators, the info their service operators are set up to monitor can also be gathered by an adversary who watches a wide range of networks and builds correlations from it 🥺

5.7. Finding Client's IP Address or Hostname

lots of DHCP deployments use DNS Updates [RFC4702] to put a client's info (current IP address, client's hostname) into the DNS, where anyone interested can easily get to it 🫣 the Client ID is also disclosed, just not in an easily accessible form (a SHA-256 digest of the client-id). since SHA-256 is considered irreversible, the DHCP client ID can't be converted back to the client-id. BUT the SHA-256 digest can still be used as a unique identifier that any host can access 😭

5.8. Correlation of Activities over Time

just like other identifiers, an IP address can be used to correlate a host's activities for at least as long as the address lives ⏳ if that address was generated from some other stable identifier, and an attacker can figure out that generation scheme, the correlation attack lasts as long as that identifier does. in lots of cases, that lifetime matches the lifetime of the device itself 💔

5.9. Location Tracking

if a stable identifier is used to assign an address and an attacker discovers that mapping, it can be used to track a user 📍 specifically, passive methods work (a service the client connects to can log the client's address and draw conclusions about its location and movement patterns based on the addresses it's connecting from), and active methods work too (an attacker can send ICMP echo requests or other probe packets to networks where the client is suspected to be) 🛰️ for 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 👀🫶

5.10. Leasequery and Bulk Leasequery 🕵️

okay bestie, so attackers can pretend to be an access concentrator 🎭, either as a DHCP relay agent or as a DHCP client, and then go straight to the DHCP server(s) with the DHCP leasequery [RFC4388] mechanism to grab location info. it's giving main character villain energy 😈

quick recap of what "location information" even is 📍: it's the stuff the access concentrator needs to forward traffic to a broadband-accessible host. that includes the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem 🛜.

and it gets worse 😭. attackers may use the DHCP bulk leasequery [RFC6926] mechanism to pull bulk info about DHCP bindings, even without knowing the target bindings 🫣. no target needed, just vibes and a bulk request.

then there's active leasequery [RFC7724] 🔔, which is a way to subscribe to DHCP lease update changes in near real-time ⏱️. the goal is to keep an operator's database up to date, which is iconic ✨. BUT if the mechanism gets misused, an attacker could defeat the server's authentication mechanisms and subscribe to all updates. and then they can keep receiving those updates without needing any local presence on the network 👀💀.

Warning: an attacker who gets past the server's authentication can keep watching lease updates from anywhere, no physical access required. that's not a vibe, that's a whole security problem 🚨

6. Security Considerations 🔐

okay this section is serious but still iconic 💅. in current practice, client privacy and client authentication are mutually exclusive 🙅‍♀️. the client authentication procedure reveals additional client information in the certificates and identifiers 📜. full privacy for the clients may mean the clients are also anonymous to the server and the network 🫥. choose your fighter, babe.

7. Privacy Considerations 🌸

this document in its entirety discusses privacy considerations in DHCP 💜, so no dedicated discussion is needed. the whole doc is the privacy talk, bestie ✨.

8. References 📚

8.1. Normative References

here are the normative references, copied exactly so nothing gets lost 🫶:

[RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
           RFC 2131, DOI 10.17487/RFC2131, March 1997,
           <http://www.rfc-editor.org/info/rfc2131>.

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

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

8.2. Informative References

and here are the informative ones, also copied exactly 💖:

[RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
           RFC 3046, DOI 10.17487/RFC3046, January 2001,
           <http://www.rfc-editor.org/info/rfc3046>.

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

[RFC3527]  Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
           "Link Selection sub-option for the Relay Agent Information
           Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April
           2003, <http://www.rfc-editor.org/info/rfc3527>.

[RFC3925]  Littlefield, J., "Vendor-Identifying Vendor Options for
           Dynamic Host Configuration Protocol version 4 (DHCPv4)",
           RFC 3925, DOI 10.17487/RFC3925, October 2004,
           <http://www.rfc-editor.org/info/rfc3925>.

[RFC3993]  Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
           Suboption for the Dynamic Host Configuration Protocol
           (DHCP) Relay Agent Option", RFC 3993,
           DOI 10.17487/RFC3993, March 2005,
           <http://www.rfc-editor.org/info/rfc3993>.

[RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
           Identifiers for Dynamic Host Configuration Protocol
           Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361,
           February 2006, <http://www.rfc-editor.org/info/rfc4361>.

[RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
           Protocol (DHCP) Leasequery", RFC 4388,
           DOI 10.17487/RFC4388, February 2006,
           <http://www.rfc-editor.org/info/rfc4388>.

[RFC4578]  Johnston, M. and S. Venaas, Ed., "Dynamic Host
           Configuration Protocol (DHCP) Options for the Intel
           Preboot eXecution Environment (PXE)", RFC 4578,
           DOI 10.17487/RFC4578, November 2006,
           <http://www.rfc-editor.org/info/rfc4578>.

[RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
           Configuration Protocol (DHCP) Client Fully Qualified
           Domain Name (FQDN) Option", RFC 4702,
           DOI 10.17487/RFC4702, October 2006,
           <http://www.rfc-editor.org/info/rfc4702>.

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

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

[RFC6926]  Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell,
           N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
           RFC 6926, DOI 10.17487/RFC6926, April 2013,
           <http://www.rfc-editor.org/info/rfc6926>.

[RFC7724]  Kinnear, K., Stapp, M., Volz, B., and N. Russell, "Active
           DHCPv4 Lease Query", RFC 7724, DOI 10.17487/RFC7724,
           December 2015, <http://www.rfc-editor.org/info/rfc7724>.

Acknowledgements 🙌

the authors would like to thank the valuable comments made by Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Huitema, Bernie Volz, Jinmei Tatuya, Marcin Siodelski, Christian Schaefer, Robert Sparks, Peter Yee, and other members of DHC WG 🥰. the whole squad showed up, periodt 👑.

Authors' Addresses 💌

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

Email: jiangsheng@huawei.com


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

📦 where this page comes from

ietf: rfc7819 2016-04
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms