RFC 4388

Dynamic Host Configuration Protocol (DHCP) Leasequery

📅 published February 2006, from ietf

Dynamic Host Configuration Protocol (DHCP) Leasequery 💖

okay bestie, this is RFC 4388 🎀 It's a Standards Track doc, so it's an actual spec that implementers follow, not just a vibes memo. It was written by R. Woundy (Comcast Cable) and K. Kinnear (Cisco Systems) and dated February 2006. This title block doesn't list any RFCs it obsoletes or updates, so there's nothing to track on that front 🦋

Status of This Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🗣️ For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2006).

Abstract ✨

So a Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of the IP addresses it has handed out to DHCPv4 clients 👑 Other processes and devices that already use DHCPv4 might need to get at that info too, and the leasequery protocol gives them a lightweight way to access IP address information 🧚

Table of Contents 🗂️

1. Introduction ....................................................2
2. Terminology .....................................................5
3. Background ......................................................7
4. Design Goals ....................................................7
   4.1. Broadcast ARP Is Undesirable ...............................7
   4.2. SNMP and LDAP Are Not Appropriate ..........................8
   4.3. DHCP Relay Agent Functionality Is Common ...................8
   4.4. DHCP Servers Are a Reliable Source of Location
        Information ................................................9
   4.5. Minimal Additional Configuration Is Required ...............9
5. Protocol Overview ...............................................9
6. Protocol Details ...............................................12
   6.1. Definitions Required for DHCPLEASEQUERY Processing ........12
   6.2. Sending the DHCPLEASEQUERY Message ........................14
   6.3. Receiving the DHCPLEASEQUERY Message ......................15
   6.4. Responding to the DHCPLEASEQUERY Message ..................16
   6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
        DHCPLEASEUNKNOWN Message ..................................20
   6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21
   6.7. Lease Binding Data Storage Requirements ...................22
   6.8. Using the DHCPLEASEQUERY Message with Multiple
        DHCP Servers ..............................................23
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgements ...............................................24
10. References ....................................................25
   10.1. Normative References .....................................25
   10.2. Informative References ...................................25

1. Introduction 🌈

okay so a DHCPv4 server holds a ton of authoritative info about which IP addresses it leased to DHCP clients 📚 Sometimes other devices or processes need that info too 🥺 In some cases those devices or processes can already send and receive DHCP packets, so the leasequery protocol is built to give them a low-overhead way to get at it. main character energy for efficiency 💅

Like, access concentrators that act as DHCP relay agents sometimes figure out stuff they need to run by pulling data out of the DHCP packets they forward. This is called "gleaning" 🫧 The problem is the typical access concentrator loses all that gleaned info when it gets rebooted or replaced 😭 So this memo proposes that when gleaned DHCP info isn't available, the access concentrator/relay agent can grab the location info straight from the DHCP server(s) using the DHCPLEASEQUERY message 🎀

Let's go deeper, because it's giving important 🔥 In a lot of broadband access networks, the access concentrator needs to tie an IP address lease to the right endpoint location. That includes the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the modem in between 📡 This matters even more when one or more IP subnets are shared across lots of ports, circuits, and modems. Here are the representative cable and DSL setups, Figures 1 and 2 🦋

        +--------+     +---------------+
        |  DHCP  |     |  DOCSIS CMTS  |
        | Server |-...-|  or DVB INA   |-------------------
        +--------+     | (Relay Agent) |      |          |
                       +---------------+  +------+    +------+
                                          |Modem1|    |Modem2|
                                          +------+    +------+
                                             |         |    |
                                         +-----+  +-----+ +-----+
                                         |Host1|  |Host2| |Host3|
                                         +-----+  +-----+ +-----+

            Figure 1: Cable Environment for DHCPLEASEQUERY
        +--------+     +---------------+
        |  DHCP  |     |  DSL Access   |     +-------+
        | Server |-...-| Concentrator  |-...-| DSLAM |
        +--------+     | (Relay Agent) |     +-------+
                       +---------------+      |     |
                                        +------+   +------+
                                        |Modem1|   |Modem2|
                                        +------+   +------+
                                           |        |    |
                                       +-----+  +-----+ +-----+
                                       |Host1|  |Host2| |Host3|
                                       +-----+  +-----+ +-----+

            Figure 2: DSL Environment for DHCPLEASEQUERY

Knowing this location info helps the access concentrator in a few ways 🧠

  1. Routing 🚦 The access concentrator can forward traffic to the access network using the correct access network port, down the correct virtual circuit, through the correct modem, to the correct hardware address.
  2. Source address checks 🕵️‍♀️ The access concentrator can do IP source address verification on datagrams received from the access network. The check can be based on the datagram source hardware address, the incoming access network port, the incoming virtual circuit, and/or the transmitting modem.
  3. Encryption 🔐 The access concentrator can encrypt datagrams so that only the correct modem can decrypt them, using mechanisms such as [BPI] or [BPI+].

In this example, the access concentrator mostly gets location info by "gleaning" from DHCP server responses that pass through the relay agent 💌 When gleaning doesn't give it the info, for example because the access concentrator has rebooted, it can ask the DHCP server(s) for location info using the DHCPLEASEQUERY message defined in this document 🫶

Now the DHCPLEASEQUERY message itself 💜 It's a brand new DHCP message type sent from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware relay agent sends it whenever it needs to know where an IP endpoint is located 📍 The DHCPLEASEQUERY-aware DHCP server answers with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message 🎁

The DHCPLEASEACTIVE response is the big one, because it lets the relay agent figure out the IP endpoint location and how much time is left on the IP address lease ⏳ DHCPLEASEUNASSIGNED is similar to DHCPLEASEACTIVE, except there's no currently active lease on that IP address, though this DHCP server is still the authoritative one for it 🌸 And DHCPLEASEUNKNOWN means the DHCP server has no knowledge of the info in the query, like the IP address, MAC address, or Client-identifier option 🙈

The DHCPLEASEQUERY message doesn't assume any particular use for the info it returns. It's just built to return info the DHCP server is authoritative for, to a client that asks for it. That makes it straightforward for processes and devices that already read DHCP packets to get info from the DHCP server 🍓

This doc is an extension to the DHCPv4 protocol [RFC2131] specifically. DHCPv6 [RFC3315] is a different beast, so there's no effective way to make the DHCPLEASEQUERY message interaction common between DHCPv4 and DHCPv6, even if someone wanted to 🙅‍♀️

The DHCPLEASEQUERY message came out of specific real-world implementation needs that showed up many years after DHCPv4 was already widely used 🕰️ At the time of writing, DHCPv6 hasn't been widely deployed yet either. The needs of access concentrators in DHCPv6 deployment scenarios that haven't been determined yet are hard to estimate 🤷‍♀️ If a DHCPLEASEQUERY-like function ends up being necessary in DHCPv6, a lot of this doc's ideas will probably apply, while others might not. We've been warned not to design protocol capabilities for a consumer that's only imagined, and for DHCPLEASEQUERY in DHCPv6 that's all there is right now 💀

So this document only applies to DHCPv4 🎀 For clarity, we didn't tack "DHCPv4" onto every mention of several common terms. In this doc, every reference to IP addresses should be read as IPv4 addresses, and every reference to DHCP servers and DHCP clients should be read as DHCPv4 servers and DHCPv4 clients 🫧 Part 2 is next, so stay tuned bestie ✨

2. Terminology ✨

okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read exactly as RFC 2119 [RFC2119] describes them 🎀

this doc uses these terms, so let's get into them 💅

  • "access concentrator"

an access concentrator is a router or switch at the broadband access provider's edge of a public broadband access network 🌐 this doc assumes that the access concentrator includes the DHCP relay agent functionality ✨

  • "DHCP client"

a DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address 🦋

  • "DHCP relay agent"

a DHCP relay agent is a third-party agent that transfers Bootstrap Protocol (BOOTP) and DHCP messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542] 🧚

  • "DHCP server"

a DHCP server is an Internet host that returns configuration parameters to DHCP clients 💜

  • "downstream"

downstream is the direction from the access concentrator towards the broadband subscriber ⬇️

  • "gleaning"

gleaning is the extraction of location information from DHCP messages, as the messages are forwarded by the DHCP relay agent function 🍓

  • "location information"

location information is information needed by the access concentrator to forward traffic to a broadband-accessible host 📍 this includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem 🫶

  • "MAC address"

in the context of a DHCP packet, a MAC address consists of the following fields: hardware type htype, hardware length hlen, and client hardware address chaddr 🔥

  • "stable storage"

every DHCP server is assumed to have some form of what is called "stable storage" 🏠 stable storage is used to hold information concerning IP address bindings (among other things) so that this information is not lost in the event of a server failure that requires restart of the server 😭

  • "upstream"

upstream is the direction from the broadband subscriber towards the access concentrator ⬆️

3. Background

okay so the whole point of this doc is to let processes and devices grab information from the DHCP server in a lightweight and convenient way 💖 it's especially perfect for processes and devices that already interpret DHCP packets 👑

one iconic motivating example is that the DHCPLEASEQUERY message lets access concentrators send DHCPLEASEQUERY messages to DHCP servers so they can get location information for broadband access network devices 🦋

a lot of access concentrators already have an embedded DHCP relay agent functionality built in 🌸 typical ones include DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentrators 🌈

DHCPLEASEQUERY is an extension to the DHCP protocol [RFC2131] ✨

the DHCPLEASEQUERY message is a query message only 🙈 it does not affect the state of the IP address or the binding information associated with it, so it's totally read-only energy 🫧

4. Design Goals 🎀

the goal here is to give processes or devices a lightweight mechanism for accessing information contained in the DHCP server 💅 it's built for processes and devices that already process and interpret DHCP messages, so they can get this info in a rapid and lightweight manner 🚀

some of this information might be acquired in a different way, and the next sections talk through some of those alternative approaches 👀

4.1. Broadcast ARP Is Undesirable 🙅‍♀️

the access concentrator can transmit a broadcast Address Resolution Protocol (ARP) Request [RFC826] and observe the origin and contents of the ARP Reply to reconstruct the location information 🕵️‍♀️

ngl the ARP mechanism is undesirable for three reasons 💀

  1. the burden on the access concentrator to transmit over multiple access ports and virtual circuits (assuming that IP subnets span multiple ports or virtual circuits) 😩
  2. the burden on the numerous subscriber hosts to receive and process the broadcast 📢
  3. the ease by which a malicious host can misrepresent itself as the IP endpoint 😈

4.2. SNMP and LDAP Are Not Appropriate 🙅

access concentrator implementations typically don't have Simple Network Management Protocol (SNMP) management client interfaces nor Lightweight Directory Access Protocol (LDAP) client interfaces (although they typically do include SNMP management agents) 🧐 this is one reason this doc doesn't leverage the proposed DHCP Server MIB [DHCPMIB] 📉

the DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering and troubleshooting activities at large DHCP installations, and is primarily intended as a method of gathering performance statistics about the load presented to servers 📊

even though the proposed DHCPv4 server MIB has objects that report configuration and status information, the MIB is intended to provide more generic, server-wide aggregated or summarized data 🗂️ DHCPLEASEQUERY is meant for detailed, specific info about individual leases, at a level that would be difficult or impossible to shoehorn into a MIB 🎯

from an implementation standpoint, the DHCPLEASEQUERY message is not required to be supported by all DHCPv4 servers 🤷‍♀️ since it appears that defining optional MIB objects and objects for optional features in a MIB is discouraged, trying to support DHCPLEASEQUERY functionality optionally through a MIB would be similarly discouraged from an SNMP MIB standpoint 🙃

4.3. DHCP Relay Agent Functionality Is Common 🔁

access concentrators commonly act as DHCP relay agents 💁‍♀️ furthermore, many access concentrators already glean location information from DHCP server responses as part of the relay agent function 🍯

the gleaning mechanism is preferred for figuring out the IP addresses valid for a particular downstream link over other mechanisms (ARP, SNMP, LDAP) because there's no extra network traffic 🙌 but sometimes gleaning info can be incomplete 😬 the access concentrator usually can't glean information from any DHCP unicast (i.e., non-relayed) messages because of performance reasons 🐢 and the DHCP-gleaned location information often doesn't persist across access concentrator reboots (due to lack of stable storage), and almost never persists across concentrator replacements 💔

4.4. DHCP Servers Are a Reliable Source of Location Information 🏆

DHCP servers are the most reliable source of location information for access concentrators 👑 this is especially true when the location information is dynamic and not reproducible by algorithmic means (e.g., when a single IP subnet extends behind many broadband modems) 🧠 DHCP servers take part in all IP lease transactions (and therefore all location information updates) with DHCP clients, whereas access concentrators sometimes miss some important lease transactions 📵

an access concentrator can be configured with the IP addresses of multiple different DHCP servers, so that no one DHCP server is a single point of failure 🛟

4.5. Minimal Additional Configuration Is Required 🌷

access concentrators can usually query the same set of DHCP servers used for forwarding by the relay agent, which keeps configuration requirements minimal 🥰 low-key the easiest kind of setup ever 💅

5. Protocol Overview 🎀

okay bestie, let's walk through how this whole thing flows 💖 For the DHCPLEASEQUERY message, we're going to say the client is an access concentrator 🦋. It's not the only thing that's allowed (or required) to use the info from DHCPLEASEQUERY, but it's a super clear example of how the message could get used ✨

The access concentrator is always the one who starts every DHCPLEASEQUERY conversation 💅 This doc assumes it picks up location info while it's doing its DHCP relay agent thing 🌸 The problem is that this info is usually gone after the access concentrator reboots or gets swapped out 😭

Picture this. The access concentrator is a router 🧚 and it gets an IP datagram that needs to head downstream to the public broadband access network. If the location info for that downstream next hop is missing, it sends one or more DHCPLEASEQUERY messages, each one carrying the next hop's IP address in the "ciaddr" field 🎀

The answer comes back with whatever info was current when this client's lease was last granted or renewed, which means the access concentrator can finally forward that datagram 🚀✨

There's also a second way to ask. You can send a DHCPLEASEQUERY with the "ciaddr" field empty, and fill in the MAC address (the "htype", "hlen", and "chaddr" fields) with a valid MAC address, or put a Client-identifier option (option 61) in the options area 🌈 In this case, the DHCP server must return an IP address in the ciaddr if it has any record of the client described by the Client-identifier or MAC address. Unless there's specific configuration telling it otherwise (see Section 6.4), it SHOULD be the IP address with the latest client-last-transaction-time associated with the client described by the MAC address or Client-identifier option 💜

Every DHCP server that implements this protocol always sends back a response to the DHCPLEASEQUERY message. It's one of DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN 🫶 The reasons each of these pops up are explained in the specific query regimes below 👀

Servers that don't implement the DHCPLEASEQUERY message SHOULD simply not respond 🙈

The DHCPLEASEQUERY message can support three query regimes 👑 A server that implements the DHCPLEASEQUERY message must implement all three of them. No skipping! 💅

  • Query by IP address:

For this one, the requester only gives an IP address in the DHCPLEASEQUERY message. The DHCP server returns any info it has on the most recent client to have been assigned that IP address. 🦋

The DHCP server replies with a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY message matches an IP address the server has definitive information about (meaning it's authorized to lease that IP address). It replies with a DHCPLEASEUNKNOWN message if it doesn't have definitive information about the address in the DHCPLEASEQUERY message 🌸

  • Query by MAC address:

For this one, the requester only gives a MAC address in the DHCPLEASEQUERY message. The DHCP server returns any info it has on the IP address most recently accessed by a client with that MAC address 🧚 It may also supply additional IP addresses that have been associated with that MAC address in different subnets. You can then look up info on those bindings using the Query by IP Address, described above 💖

The DHCP server replies with a DHCPLEASEACTIVE message if the MAC address in the DHCPLEASEQUERY message matches a MAC address with an active lease on an IP address in this server. It replies with a DHCPLEASEUNKNOWN message if the server doesn't currently have an active lease by a client with this MAC address in this DHCP server 😭

  • Query by Client-identifier option:

For this one, the requester only gives a Client-identifier option in the DHCPLEASEQUERY message. The DHCP server returns any info it has on the IP address most recently accessed by a client with that Client-identifier 🎀 It may also supply additional IP addresses that have been associated with that Client-identifier in different subnets. Info on those bindings can then be found using the Query by IP Address, described above ✨

The DHCP server replies with a DHCPLEASEACTIVE message if the Client-identifier in the DHCPLEASEQUERY message currently has an active lease on an IP address in this DHCP server. It replies with a DHCPLEASEUNKNOWN message if the server doesn't have an active lease by a client with this Client-identifier 🙈

For many DHCP servers, the query by IP address is probably going to be the most efficient form of leasequery 🔥 This is the form of DHCPLEASEQUERY that SHOULD be used if possible 💅

The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE reply must always contain the IP address in the "ciaddr" field 🫶 The DHCPLEASEACTIVE message SHOULD contain the physical address of the IP address lease owner in the "htype", "hlen", and "chaddr" fields 🦋 The Parameter Request List (option 55) can be used to ask for specific options to be returned about the IP address in the ciaddr 🌈 The reply often has the time until the lease expires, plus the original contents of the Relay Agent Information option [RFC3046]. The access concentrator uses the "chaddr" field and the Relay Agent Information option to build location info, which it can cache until the lease expires 🧁

Any DHCP server that supports the DHCPLEASEQUERY message SHOULD save the info from the most recent Relay Agent Information option (option 82) [RFC3046] associated with every IP address that it serves 💜 It's assumed that most clients sending a DHCPLEASEQUERY will ask for the Relay Agent Information option (option 82) in the Parameter Request List (option 55). So supporting DHCPLEASEQUERY without keeping that option around to return to the client is likely to be less than helpful 😬

A server that implements DHCPLEASEQUERY SHOULD also save the info on the most recent Vendor class identifier (option 60) associated with each IP address, since clients sending the DHCPLEASEQUERY message are also likely to ask for this option 🌸✨

6. Protocol Details 🌈

6.1. Definitions Required for DHCPLEASEQUERY Processing 💅

Making DHCPLEASEQUERY work needs some new and extended values for the DHCP packet, on top of the ones defined by [RFC2131] and [RFC2132] 🎀 See also Section 8, IANA Considerations, for the rest of the details 🦋

  1. Message types. The message type option (option 53) from [RFC2132] gets four new values: one for the DHCPLEASEQUERY message itself, and one for each of its three possible responses (DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN) 💖 Here's the table, shown as an extension of the table from section 9.6 of [RFC2132] 👑
Value   Message Type
-----   ------------
  10    DHCPLEASEQUERY
  11    DHCPLEASEUNASSIGNED
  12    DHCPLEASEUNKNOWN
  13    DHCPLEASEACTIVE
  1. client-last-transaction-time. This is a brand new option 🧚 It lets the receiver figure out when the client was last accessed. It's especially handy when DHCPLEASEACTIVE messages from two different DHCP servers need to be compared, though it can help in other situations too ✨ The value is a duration in seconds, counted from the current time backwards to the moment this IP address was most recently the subject of communication between the client and the DHCP server 🕰️

This MUST NOT be an absolute time. It also MUST NOT be an absolute number of seconds since Jan. 1, 1970 😭 Instead, this MUST be an integer number of seconds in the past, counted from when the DHCPLEASEACTIVE message gets sent, to when the client last dealt with this server about this IP address 🫶 Just like the IP Address Lease Time option (option 51) encodes a lease time as a number of seconds into the future from when the message was sent, this option encodes a number of seconds into the past from when the message was sent 🔥

The code for this option is 91, and its length is 4 octets 💜 Here's how it looks:

    Code   Len      Seconds in the past
   +-----+-----+-----+-----+-----+-----+
   |  91 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+
  1. associated-ip. This is a second new option 🦋 It's used to return all of the IP addresses associated with the DHCP client specified in a particular DHCPLEASEQUERY message 🌸

The code for this option is 92. The minimum length is 4 octets, and the length MUST always be a multiple of 4 🌈 Here's the layout:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  92 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

6.2. Sending the DHCPLEASEQUERY Message

Okay bestie, so the DHCPLEASEQUERY message is usually sent by an access concentrator 🦋. It uses the DHCP message format from [RFC2131] and has message number 10 in the DHCP Message Type option (option 53) ✨. Here's what's inside it:

  • The giaddr MUST be set to the IP address of the requester (i.e., the access concentrator). The giaddr is independent of the ciaddr field being searched 💅. It's basically just the return address for the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message from the DHCP server.

Note that this use of the giaddr is consistent with the definition in [RFC2131], where the giaddr is always the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is the "key" used to access the right address pool. DHCPLEASEQUERY is one of those cases where the giaddr MUST NOT be used as such a "key" 🙈.

  • The Parameter Request List option (option 55) SHOULD be set to the options the requester is interested in 🎀. The interesting ones are likely to include the IP Address Lease Time option (option 51), the Relay Agent Information option (option 82), and possibly the Vendor class identifier option (option 60). If there's no Parameter Request List option, the server SHOULD return the same options it would return for a DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message. That includes the ones mandated by Section 4.3.1 of [RFC2131], plus any options the server was configured to always return to a client.

Okay, now the extra deets on each query type 👑:

  • Query by IP address:
    • The values of htype, hlen, and chaddr MUST be set to zero.
    • The ciaddr field MUST be set to the IP address of the lease to be queried.
    • The Client-identifier option (option 61) MUST NOT appear in the packet.
  • Query by MAC address:
    • The values of htype, hlen, and chaddr MUST be set to the value of the MAC address to search for.
    • The ciaddr field MUST be set to zero.
    • The Client-identifier option (option 61) MUST NOT appear in the packet.
  • Query by Client-identifier option:
    • There MUST be a Client-identifier option (option 61) in the DHCPLEASEQUERY message.
    • The ciaddr field MUST be set to zero.
    • The values of htype, hlen, and chaddr MUST be set to zero.

The DHCPLEASEQUERY message SHOULD be sent to a DHCP server that's known to have authoritative info about the IP address 🧚. It MAY be sent to more than one DHCP server. If you don't know which DHCP server might have authoritative info about the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known) 🌸.

Any device planning to use a DHCPLEASEQUERY message SHOULD make sure the Relay Agent Info option it uses contains information that unambiguously identifies the device 🫶.

6.3. Receiving the DHCPLEASEQUERY Message

A server that implements the DHCPLEASEQUERY message MUST implement all three query regimes: query by IP address, query by MAC address, and query by Client-identifier. No skipping, periodt 💅.

A DHCPLEASEQUERY message MUST have a non-zero giaddr. It MUST also have exactly one of the following: a non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier option 🌈.

The DHCP server that receives a DHCPLEASEQUERY message MUST base its response on the particular data item used in the query 🎯.

The giaddr is only used for the destination address of any generated response. It's required, but it isn't otherwise used when generating the response to the DHCPLEASEQUERY message. It MUST NOT be used to restrict the processing of the query in any way, and it MUST NOT be used to locate a subnet that the ciaddr (if any) must belong to 🙅‍♀️.

Note that this use of the giaddr is consistent with the definition of giaddr in [RFC2131], where the giaddr is always used as the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is used as the "key" to access the appropriate address pool. DHCPLEASEQUERY is one of those cases where the giaddr MUST NOT be used as such a "key" 💜.

6.4. Responding to the DHCPLEASEQUERY Message

There are three possible responses to a DHCPLEASEQUERY message 🍓:

  • DHCPLEASEUNASSIGNED
    • The server MUST respond with a DHCPLEASEUNASSIGNED message if this server has information about the IP address, but there's no active lease for it. DHCPLEASEUNASSIGNED is only returned for a query by IP address. It basically says "I manage this IP address, but nobody currently has an active lease on it" 🌷.
  • DHCPLEASEUNKNOWN
    • The DHCPLEASEUNKNOWN message means the server does not manage the IP address, or the client named in the DHCPLEASEQUERY message doesn't currently have a lease on any IP address 🙈.
    • When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST NOT include other DHCP options in the response.
  • DHCPLEASEACTIVE
    • The DHCPLEASEACTIVE message means the server not only knows about the IP address and client named in the query, but also knows there's an active lease by that client for that IP address ⭐.
    • The server MUST respond with a DHCPLEASEACTIVE message when the IP address returned in the ciaddr field is currently leased.

6.4.1. Determining the IP address about Which to Respond

This part is a big deal 🔥. A response to a DHCPLEASEQUERY request can only contain full information about one IP address, the one in the ciaddr field. So figuring out which IP address to respond about is a key issue 👑. Of course, the values of any additional IP addresses the client has a lease on must also be returned in the associated-ip option (Section 6.1, #3). That's the only info returned that isn't directly tied to the IP address in the ciaddr field 🦋.

If an IP address shows up in the ciaddr field of a DHCPLEASEQUERY message, and that IP address is one the DHCP server manages, then that IP address MUST be set in the ciaddr field of a DHCPLEASEUNASSIGNED message 🎀.

If the IP address is not managed by the DHCP server, then a DHCPLEASEUNKNOWN message must be returned 🌸.

If the ciaddr field of the DHCPLEASEQUERY is zero, then the DHCPLEASEQUERY message is a query by Client-identifier or MAC address. In that case, the client's identity is any client that has offered an identical Client-identifier option (if the Client-identifier option appears in the DHCPLEASEQUERY message), or an identical MAC address (if the MAC address fields in the DHCPLEASEQUERY message are non-zero). For the purposes of this section, this client matching approach will be called "Client-identifier or MAC address" 🫶.

If the ciaddr field is zero in a DHCPLEASEQUERY message, then the IP address placed in the ciaddr field of a DHCPLEASEACTIVE message MUST be an IP address for which the client that most recently used it matches the Client-identifier or MAC address specified in the DHCPLEASEQUERY message 🧚.

If there's only one IP address that fulfills this criteria, then it MUST be placed in the ciaddr field of the DHCPLEASEACTIVE message ✨.

If more than one IP address has been accessed by the client specified by the MAC address or Client-identifier option, then the DHCP server MUST return the IP address that was returned to the client in the most recent transaction with the client. The exception is when the server administrator has configured the DHCP server to use some other preference mechanism 💖.

If, after all of the above processing, no value is set in the ciaddr field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, then a DHCPLEASEUNKNOWN message MUST be returned instead 💀.

6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE Message Once the "ciaddr" Field Is Set ✨

Okay so once the ciaddr field is set on a DHCPLEASEUNASSIGNED message, bestie, that's literally it. ✨ Processing for DHCPLEASEUNASSIGNED is done, and no other options get returned for it. 💅

For DHCPLEASEACTIVE, the rest of the work is mostly about returning info on the IP address sitting in ciaddr. 🦋

The IP address in ciaddr on a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message MUST be one this server is responsible for. (If it isn't, a DHCPLEASEUNKNOWN would've already been sent way earlier in the process from the last section, no cap. 🙈)

The MAC address of the DHCPLEASEACTIVE message MUST be set to the values that identify the client tied to the ciaddr IP from the DHCPLEASEUNASSIGNED message. 🫶

If the Client-identifier option (option 61) is in the Parameter Request List option (option 55), then the Client-identifier (if there is one) of the client tied to the ciaddr IP SHOULD be returned in the DHCPLEASEACTIVE message. 🌸

Now, if more than one IP address has been part of a DHCP message exchange with the client identified by the MAC address and/or Client-identifier option, the whole list of IP addresses MUST be returned in the associated-ip option. This happens whether or not that option was actually requested in the Parameter Request List option. Iconic behaviour, honestly. 👑

If the IP Address Lease Time option (option 51) is in the Parameter Request List and there's a currently valid lease for the IP address in ciaddr, then the DHCP server MUST return this option in the DHCPLEASEACTIVE message. Its value has to be the time remaining until the lease expires. ⏳ But if there's no valid lease for that IP address, the server MUST NOT return the IP Address Lease Time option (option 51). 🙅‍♀️

A request for the Renewal (T1) Time Value option or the Rebinding (T2) Time Value option in the Parameter Request List of the DHCPLEASEQUERY message MUST be handled the same way as the IP Address Lease Time option. If there's a valid lease and these times aren't in the past yet, the DHCP server SHOULD return these options (when requested) with the remaining time until renewal or rebinding, respectively. If these times are already in the past, or there's currently no valid lease for this IP address, the DHCP server MUST NOT return these options. 💀

If the Relay Agent Information (option 82) is in the Parameter Request List, then the info from the most recent Relay Agent Information option received from the relay agent tied to this IP address MUST be included in the DHCPLEASEACTIVE message. 🧚

The DHCPLEASEACTIVE message SHOULD also include the values of every other option that was requested in the Parameter Request List of the DHCPLEASEQUERY message and that isn't specifically covered above. The catch is it has to be acceptable to return based on the "non-sensitive options" list, which we'll get into below. 🎀

DHCP servers SHOULD be configurable with a list of "non-sensitive options" that can be sent back to the client when they're in the Parameter Request List of the DHCPLEASEQUERY message. Any option NOT on that list SHOULD NOT be returned to a client, even if that client asked for it. Not on the list? Not happening, periodt. 🔒

The DHCP server uses info from its lease binding database to supply the DHCPLEASEACTIVE option values. The values of the options that were returned to the DHCP client would generally be preferred. If those aren't available, options that were sent in DHCP client requests would be acceptable. 🌈

Sometimes the Relay Agent Information option in an incoming DHCPREQUEST packet helps decide which options get returned to the DHCP client that sent the DHCPREQUEST. So when the DHCP server responds to a DHCPLEASEQUERY message, it MUST use the saved Relay Agent Information option, exactly like it did when responding to the DHCP client, to work out the values of any options the DHCPLEASEQUERY asked for. The goal is for the DHCPLEASEQUERY to get the same option values that went back to the DHCPDISCOVER or DHCPREQUEST from the client (unless something above says otherwise). ✨

Here's a fun one: two servers can cooperate to provide a high-availability DHCP server, as supported by [RFC2131]. In that setup they'd have to share some info about IP address bindings with each other. To properly support the DHCPLEASEQUERY message, these servers MUST ensure they communicate the Relay Agent Information option info to each other, on top of any other IP address binding info. Teamwork makes the dream work, bestie. 🫶

6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message 📮

The server expects a giaddr in the DHCPLEASEQUERY message, and it unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message to that giaddr. But if the giaddr field is zero, then the DHCP server MUST NOT reply to the DHCPLEASEQUERY message. No giaddr, no reply, that's the rule. 🙅‍♀️

6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message 📬

When a DHCPLEASEACTIVE message comes back in response to the DHCPLEASEQUERY message, it means there's a currently active lease for this IP address on this DHCP server. The access concentrator SHOULD use the info in the htype, hlen, and chaddr fields of the DHCPLEASEACTIVE, plus any Relay Agent Information option info in the packet, to refresh its location info for this IP address. 🔄

When a DHCPLEASEUNASSIGNED message comes back in response to the DHCPLEASEQUERY message, it means there's no currently active lease for the IP address on the DHCP server, but this server does manage that IP address. In this case the access concentrator SHOULD cache this info so it doesn't put unacceptable load on itself and the DHCP server when a malicious or seriously compromised device downstream of the access concentrator goes wild. 😭 Caching could be as simple as setting a bit that says a response came back from a server that knew about this IP address but there was no current lease. Of course, that bit would need to be cleared when the access concentrator next "gleaned" that a lease for this IP address came into existence. 🧹

Either way, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message comes back in response to a DHCPLEASEQUERY message, it means the DHCP server that responded is one that manages the IP address in the ciaddr. The Relay Agent SHOULD cache this info for later use. 🦋

When an access concentrator that sent out a DHCPLEASEQUERY message gets a DHCPLEASEUNKNOWN message, it means the DHCP server contacted supports the DHCPLEASEQUERY message, but doesn't have definitive info about the IP address in the ciaddr field of the DHCPLEASEQUERY message. If there's no IP address in the ciaddr field of the DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means the DHCP server doesn't have definitive info about the DHCP client identified by the hlen, htype, and chaddr fields, or the Client-identifier option, of the DHCPLEASEQUERY message. 🤷‍♀️

The access concentrator SHOULD cache this info, but only for a relatively short lifetime, about 5 minutes. ⏱️

Having cached it, the access concentrator SHOULD only infrequently direct a DHCPLEASEQUERY message to a DHCP server that answered a DHCPLEASEQUERY for a particular ciaddr field with a DHCPLEASEUNKNOWN. Don't spam the same server, bestie. 🙈

6.6. Receiving No Response to the DHCPLEASEQUERY Message 🕳️

When an access concentrator gets no response to a DHCPLEASEQUERY message, there are a few possible reasons:

  • The DHCPLEASEQUERY, or the matching DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN, got lost during transmission. Or the DHCPLEASEQUERY reached the DHCP server but got dropped because the server was too busy.
  • The DHCP server doesn't support DHCPLEASEQUERY.

In the first case, retransmitting the DHCPLEASEQUERY is appropriate. In the second case, retransmitting would NOT be appropriate. There's no way to tell these two cases apart, other than maybe by checking how the DHCP server responds to other DHCPLEASEQUERY messages, which would show whether it does or doesn't support the DHCPLEASEQUERY message. 🕵️‍♀️

An access concentrator that uses the DHCPLEASEQUERY message SHOULD attempt to resend DHCPLEASEQUERY messages to servers that don't respond to them. It should use a backoff algorithm for the retry time that roughly approximates an exponential backoff. The access concentrator SHOULD adjust that backoff so DHCPLEASEQUERY messages don't reach a server that isn't otherwise known to support DHCPLEASEQUERY at a rate higher than about one packet every 10 seconds. But if the access concentrator needs to send DHCPLEASEQUERY messages, it should still send at least one DHCPLEASEQUERY every 70 seconds. That's the sweet spot, babe. 🎯

In practice, this would probably be handled best by a per-server timer that restarts whenever a response to a DHCPLEASEQUERY message comes in and expires after one minute. The per-server timer starts out expired, and while it's expired, only one DHCPLEASEQUERY message gets queued for the associated server. ⏲️

All DHCPLEASEQUERY messages SHOULD use the exponential backoff algorithm specified in Section 4.1 of [RFC2131]. ✨

So, in the initial state, the per-server timer is expired and a single DHCPLEASEQUERY message is queued for each server. After the first response to a DHCPLEASEQUERY message, the per-server timer starts. At that point, multiple DHCPLEASEQUERY messages can go out in parallel to the DHCP server, though the total number SHOULD be limited to 100 or 200 so the DHCP server doesn't get swamped. Each of these messages uses the exponential backoff algorithm from [RFC2131]. Every time a response to any of these messages comes in, the per-server timer resets and starts counting up to one minute again. If the per-server timer goes off, then all outstanding messages SHOULD be dropped except for a single DHCPLEASEQUERY message. That one gets used to poll the server at about 64-second intervals until another response (or the first one) to the DHCPLEASEQUERY comes in. 🧚‍♀️

If there's no DHCPLEASEQUERY traffic for one minute, the per-server timer will expire. After that, only one DHCPLEASEQUERY message is allowed to be outstanding to that server until a response to that message is received. Calm, controlled, very main character. 👑

6.7. Lease Binding Data Storage Requirements ✨

Okay bestie, DHCP servers that do the DHCPLEASEQUERY thing MUST save the most recent Relay Agent Information option from the most recent DHCPREQUEST packet, and there are two reasons 💅. First, it is almost certain to be requested in the dhcp-parameter-request-list option in any DHCPLEASEQUERY request. Second, the saved Relay Agent Information option may be necessary to figure out the value of other options given to the DHCP client, if those are requested in the dhcp-parameter-request list in the DHCPLEASEQUERY request. 🧚

Here's the info you need to store so you can implement this successfully 🎀

  • relay-agent-info option from the client packet: MUST store with the binding.
  • client-last-transaction-time of the last client interaction: MUST store with the binding.
  • vendor-class-id: SHOULD store with the binding.

Honestly these storage requirements are only a little bit bigger than what you need for normal DHCP operation, which is what [RFC2131] asks for anyway. Not too bad, right? 🌸

6.8. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 🦋

So imagine you're using DHCPLEASEQUERY in an environment where multiple DHCP servers may have authoritative info about the same IP address. This happens when two DHCP servers team up to give you a high-availability DHCP service. In that case you can end up with multiple, possibly conflicting, responses. Chaos, but make it cute 😭

Here's the move: some info in the response packet SHOULD be used to decide which response wins 👑. The client-last-transaction-time (if it's available) can tell you which server has the more recent info about the IP address returned in the ciaddr field. Iconic behavior, ngl 💖

7. Security Considerations 🔐

Okay, this section is kind of the main character of the whole doc, so buckle up 😤. Access concentrators that use DHCP gleaning and keep themselves fresh with DHCPLEASEQUERY messages will maintain accurate location information. And accurate location info is a huge deal, because it lets the access concentrator forward data traffic to the right spot in the broadband access network. It can also do IP source address verification on datagrams coming from the access network, and it can encrypt traffic that only the intended access modem can decrypt (for example, [BPI] and [BPI+]) 🎀.

Because of all that, the access concentrator doesn't have to depend on ARP broadcasts across the access network. Those are super sketchy because malicious hosts can pretend to be the intended IP endpoints 🙈. So yeah, DHCPLEASEQUERY gives an access concentrator a seriously upgraded level of security. Slay 💅

DHCP servers SHOULD prevent exposure of location information. This matters a lot, especially the mapping of hardware address to IP address lease, because that can be a real invasion of broadband subscriber privacy 🫶. To do this, they can use the techniques in [RFC3118], "Authentication for DHCP Messages".

This RFC explains how a DHCP client interacts with a DHCP server. Access concentrators that send the DHCPLEASEQUERY message are basically DHCP clients for the purposes of that message, even though they also do the job of a DHCP relay agent. So [RFC3118] is an appropriate mechanism for DHCPLEASEQUERY messages 🍓.

Now here's the tricky part. [RFC3118] talks about the normal DHCP client interaction, which is DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK. So we have to transpose the operations from [RFC3118] into the DHCPLEASEQUERY world. The operations [RFC3118] describes for DHCPDISCOVER get performed for DHCPLEASEQUERY. The operations described for DHCPOFFER get performed for DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages. Big brain energy 🧠✨

Access concentrators SHOULD minimize potential denial of service attacks on the DHCP servers. The way to do that is by minimizing how many DHCPLEASEQUERY messages they generate 🛡️. Specifically, the access concentrator SHOULD employ negative caching, which means caching DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages. It should also do ciaddr restriction, which means not sending a DHCPLEASEQUERY message with a ciaddr outside the range of the attached broadband access networks. Together these mechanisms limit the access concentrator to transmitting one DHCPLEASEQUERY message (not counting retries) per legitimate broadband access network IP address after a reboot event. Efficient and iconic 💅

DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure they can't be successfully attacked by getting flooded with huge quantities of DHCPLEASEQUERY messages in a short time 🌊.

In some environments, it may be appropriate to configure a DHCP server with the IP addresses of the relay agents it may respond to for DHCPLEASEQUERY messages. This means it only responds to requests from a handful of relay agents. Now, this doesn't provide any true security 🙃, but it might be useful for stopping unsophisticated attacks of various sorts. Not a full fortress, but a little speed bump 🚧

8. IANA Considerations 🎀

IANA has assigned six values for this document, so check Section 6.1 for the details 💖. There are four new message types, and they're the values of the message type option (option 53) from [RFC2132]. DHCPLEASEQUERY is 10, DHCPLEASEUNASSIGNED is 11, DHCPLEASEUNKNOWN is 12, and DHCPLEASEACTIVE is 13. Finally, there are two new DHCP options: the client-last-transaction-time option (option code 91) and the associated-ip option (option code 92). Two options, four message types, six values total. Iykyk 🧚

9. Acknowledgements 🫶

Huge shoutout to Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp, who contributed hugely to the first creation of the DHCPLEASEQUERY message 👑.

Patrick Guelat suggested several improvements to support static IP addressing 🌈. Thomas Narten made tons of suggestions for improvements 💜. Russ Housley pushed hard for more security capabilities, and Ted Hardie suggested ways to cut down on undesired information leakage 🔥. Bert Wijnen suggested the team clarify its focus on DHCPv4 and distinguish the approach from the DHCP MIB 🦋. R. Barr Hibbs, one of the authors of the DHCP MIB, shared info that made it easy to tell that effort apart from DHCPLEASEQUERY ✨.

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
  • [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

10.2. Informative References

  • [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
  • [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
  • [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
  • [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
  • [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, available at http://www.scte.org/standards/.
  • [BPI+] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, available at http://www.cablemodem.com/.
  • [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", Work in Progress, February 2004.
  • [DOCSIS] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, available at http://www.scte.org/standards/.
  • [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem for digital bi-directional communications via cable networks", Version 1.0, May 1999.

Authors' Addresses 🧑‍💻

Rich Woundy
Comcast Cable
27 Industrial Ave.
Chelmsford, MA  01824

Phone: (978) 244-4010
EMail: richard_woundy@cable.comcast.com


Kim Kinnear
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719

Phone: (978) 936-0000
EMail: kkinnear@cisco.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌷

📦 where this page comes from