RFC 5007

DHCPv6 Leasequery

📅 published September 2007, from ietf

RFC 5007: DHCPv6 Leasequery 🎀

Okay bestie, so this is RFC 5007 💖 It's a Standards Track doc from the Network Working Group, dated September 2007. J. Brzozowski (from Comcast Cable) wrote it with K. Kinnear, B. Volz, and S. Zeng, all from Cisco Systems, Inc. ✨ The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Status of This Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🗣️ For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited, so share away 🦋

Abstract 🌸

This doc specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 🧚 It's how you grab lease info about DHCPv6 clients from a DHCPv6 server. It spells out what data you're allowed to retrieve, plus how both the leasequery requestor and the server are supposed to behave. And it extends DHCPv6 too 🔥

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  4
  3.1.  On-Demand Query  . . . . . . . . . . . . . . . . . . . . .  4
  3.2.  Anticipatory Query . . . . . . . . . . . . . . . . . . . .  5
  3.3.  Query Types  . . . . . . . . . . . . . . . . . . . . . . .  5
4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Message and Option Definitions . . . . . . . . . . . . . .  6
    4.1.1.  Messages . . . . . . . . . . . . . . . . . . . . . . .  6
    4.1.2.  Options  . . . . . . . . . . . . . . . . . . . . . . .  6
    4.1.3.  Status Codes . . . . . . . . . . . . . . . . . . . . . 12
    4.1.4.  Transmission and Retransmission Parameters . . . . . . 12
  4.2.  Message Validation . . . . . . . . . . . . . . . . . . . . 12
    4.2.1.  LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 12
    4.2.2.  LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 13
  4.3.  DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 13
    4.3.1.  Creation of LEASEQUERY . . . . . . . . . . . . . . . . 13
    4.3.2.  Transmission of LEASEQUERY . . . . . . . . . . . . . . 13
    4.3.3.  Receipt of LEASEQUERY-REPLY  . . . . . . . . . . . . . 14
    4.3.4.  Handling DHCPv6 Client Data from Multiple Sources  . . 15
  4.4.  DHCPv6 Leasequery Server Behavior  . . . . . . . . . . . . 16
    4.4.1.  Receipt of LEASEQUERY Messages . . . . . . . . . . . . 16
    4.4.2.  Constructing the Client's OPTION_CLIENT_DATA . . . . . 17
    4.4.3.  Transmission of LEASEQUERY-REPLY Messages  . . . . . . 17
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 20

1. Introduction ✨

So DHCPv6 [2] is the protocol that hands out IPv6 address and configuration info to IPv6 nodes 💜 IPv6 Prefix Options for DHCPv6 [4] covers the automated delegation of IPv6 prefixes and related options. Kind of like DHCPv4 [5], DHCPv6 servers keep authoritative info about their operations, including (but not limited to) lease info for IPv6 addresses and delegated prefixes 📦

Lots of IPv6 deployments, especially broadband ones, need to use DHCPv6 [2] to pull data about DHCPv6 server operations programmatically 🤖 The main thing people want is lease info for IPv6 addresses and delegated prefixes assigned via DHCPv6 [2] [4]. This is super valuable in broadband networks, where edge devices use it for access control 🛡️ Pulling lease data out of a DHCPv6 server like this is what we call leasequery 🫶

The leasequery capability in this doc is the sibling of the DHCPv4 leasequery capability documented in [3] 👯 So it shares the same basic motivations, background, design goals and constraints as [3]. The differences come from IPv4 vs IPv6 (and so DHCPv4 vs DHCPv6). For example, Neighbor Discovery [7] is used in IPv6 instead of the Address Resolution Protocol (ARP) [8] (Section 4.1 of [3]), and DOCSIS 3.0 [11] defines IPv6 support for cable modem environments 🎧

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get read exactly the way [1] describes 🧐 DHCPv6 terminology comes from [2], and the leasequery-specific terms are below:

  • access concentrator: a router or switch at the broadband access provider's edge of a public broadband access network 🌐 This doc assumes the access concentrator includes the DHCPv6 relay agent functionality.
  • client(s): the nodes that have one or more bindings with a DHCPv6 server. This doesn't refer to the node issuing the LEASEQUERY, unless that node itself has one or more bindings with a DHCPv6 server.
  • gleaning: pulling location info out of DHCPv6 messages as the DHCP relay agent function forwards them 🕵️‍♀️
  • location information: the info an access concentrator needs to forward traffic to a broadband-accessible host 📍 This 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.
  • requestor: the node that sends LEASEQUERY messages to one or more servers to get the bindings for a client 📬

3. Protocol Overview 🧭

The whole point of this doc is to extend DHCPv6 so processes and devices that want info from a DHCPv6 server can get it in a lightweight and convenient way 💅 It's especially great for processes and devices that already interpret DHCPv6 messages.

The LEASEQUERY message is a query message only 🔒 It doesn't affect the state of the IPv6 address or prefix, or the binding info associated with it.

One big motivating example is that LEASEQUERY lets access concentrators query DHCP servers for location info about broadband access network devices. This is described in Section 1 of [3] for IPv4 ✨

3.1. On-Demand Query 🎯

The on-demand leasequery capability lets you request just the info you need for an immediate need 💁‍♀️ If the requestor is an access concentrator, the immediate need is usually that it has received an IPv6 packet and needs to refresh its info about the DHCPv6 client that IPv6 address is currently leased to. In this case, the request is by address. This fits neatly into the single request/response cycle that's common to other DHCPv6 message exchanges 🔁

Ngl, this approach has limits with prefix delegation [4] 😬 No traffic may arrive, because the access concentrator can't inject the right routing info into the routing infrastructure, like after a reboot. It does work if the access concentrator is configured to inject routing info for a prefix that aggregates potentially delegated prefixes. It also works if the access concentrator and requesting router use a routing protocol, since then the requesting router can trigger the access concentrator to request info from a DHCPv6 server and inject the right routing info into the routing infrastructure 🛣️

3.2. Anticipatory Query ⏰

A second approach for requesting info from a DHCPv6 server would be to use a leasequery-like capability to rebuild an internal data store with info available from a DHCPv6 server 🗄️ The rebuild can happen as soon as possible after someone discovers it's needed (like on booting). It doesn't wait for specific packets to trigger a piecemeal database update, which is what on-demand leasequery does. This approach would also remove the prefix delegation limitation we just talked about 🙌

This anticipatory query isn't specified in this doc. It's an area of future work 🔮

3.3. Query Types 🔍

Leasequery supports these queries:

  • Query by IPv6 address: lets a requestor ask a server for the bindings for a client that's either bound to the address or has been delegated the prefix that contains the address 🏠
  • Query by Client Identifier (DUID): lets a requestor ask a server for the bindings for a specific client on a specific link, or a list of the links where that client has one or more bindings 🔗

4. Protocol Details 🛠️

4.1. Message and Option Definitions 📨

4.1.1. Messages

LEASEQUERY and LEASEQUERY-REPLY use the Client/Server message formats described in [2], Section 6 💌 Two new message codes are defined:

  • LEASEQUERY (14): a requestor sends this to any available server to get info on a client's leases 📤 The options in an OPTION_LQ_QUERY determine the query.
  • LEASEQUERY-REPLY (15): a server sends this, containing client data, in response to a LEASEQUERY message 📥

4.1.2. Options ✨

Okay, the options are coming up in the next part, so stay tuned 🌈

4.1.2.1. Query Option 🔍

okay so the Query option is only used in a LEASEQUERY message, and its whole job is to say which query is happening 💅. It carries the query type, a link-address (or 0::0 if you don't know it), and whatever options hold the data the query needs ✨

The format of the Query option looks like this 🎀:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        OPTION_LQ_QUERY        |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   query-type  |                                               |
       +-+-+-+-+-+-+-+-+                                               |
       |                                                               |
       |                         link-address                          |
       |                                                               |
       |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               |                                               .
       +-+-+-+-+-+-+-+-+                                               .
       .                         query-options                         .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • option-code: OPTION_LQ_QUERY (44) 🌸
  • option-len: 17 + length of query-options field. The math here is giving precision 🧮
  • link-address: a global address the server uses to figure out which link the query is about, or 0::0 if it's unspecified 🌈
  • query-type: the query being requested (more on these below) 💜
  • query-options: the options related to the query 🦋

The query-type and required query-options are:

  • QUERY_BY_ADDRESS (1): the query-options MUST contain an OPTION_IAADDR option [2]. If link-address isn't 0::0, it gives an address for the link where the client is, in case the address in the OPTION_IAADDR option has too small a scope. Only the info for the client that holds a lease on the specified address, or was delegated a prefix containing that address, gets returned (if it's available) 🔥
  • QUERY_BY_CLIENTID (2): the query-options MUST contain an OPTION_CLIENTID option [2]. If link-address isn't 0::0, it specifies an address for the link where the client is. If link-address is 0::0, the server SHOULD search all of its links for the client 👑

The query-options MAY also include an OPTION_ORO option [2] to say which options the requestor wants the server to return for each client. Heads up, this OPTION_ORO is totally separate from any OPTION_ORO that might be in the requestor's LEASEQUERY message 🙈

If a server gets an OPTION_LQ_QUERY with a query-type it doesn't support, the server SHOULD return an UnknownQueryType status-code 💀. If a server gets a supported query-type but the query-options is missing a required option, the server SHOULD return a MalformedQuery status-code 😭

4.1.2.2. Client Data Option 🧚

The Client Data option is used to wrap up the data for one client on one link, inside a LEASEQUERY-REPLY message 🎀

Here's what it looks like 💖:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       OPTION_CLIENT_DATA      |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                        client-options                         .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • option-code: OPTION_CLIENT_DATA (45) ✨
  • option-len: the length, in octets, of the encapsulated client-options field 🍓
  • client-options: the options associated with this client 🌈

The encapsulated client-options include the OPTION_CLIENTID, OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options, plus other options specific to the client that the requestor asked for in the OPTION_ORO inside the OPTION_LQ_QUERY's query-options. The server MUST return all of the client's statefully assigned addresses and delegated prefixes that have a non-zero valid lifetime, on the link 🔥

4.1.2.3. Client Last Transaction Time Option ⏰

The Client Last Transaction Time option gets encapsulated in an OPTION_CLIENT_DATA, and it tells you how long ago the server last talked to the client, in seconds 🫶

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        OPTION_CLT_TIME        |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 client-last-transaction-time                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • option-code: OPTION_CLT_TIME (46) 🦋
  • option-len: 4 🌸
  • client-last-transaction-time: the number of seconds since the server last communicated with the client (on that link) 🧚

The client-last-transaction-time is a positive value, and it reflects the number of seconds since the server last communicated with the client (on that link) ⭐

4.1.2.4. Relay Data 🛰️

The Relay Data option is used only in a LEASEQUERY-REPLY message. It hands over the relay agent information that was used the last time the client talked to the server 💜

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     OPTION_LQ_RELAY_DATA      |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  peer-address (IPv6 address)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       DHCP-relay-message                      |
       .                                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • option-code: OPTION_LQ_RELAY_DATA (47) 🎀
  • option-len: 16 + length of DHCP-relay-message 🧮
  • peer-address: the address of the relay agent that the server got the relayed message from 🌈
  • DHCP-relay-message: the last complete relayed message the server received, excluding the client's message OPTION_RELAY_MSG 🍓

This option is how the server hands back full relay agent info for a client 💖. It MUST NOT be returned if the server doesn't have that info, either because the client talked to the server directly (without a relay agent), or because the server didn't keep that info around 🙈

If it is returned, the DHCP-relay-message MUST contain a valid (perhaps multi-hop) RELAY-FORW message, as the most recent one the server received for the client. However, the (innermost) OPTION_RELAY_MSG option that holds the client's message MUST have been removed 🔥

This option SHOULD only be returned if the OPTION_ORO of the OPTION_LQ_QUERY asked for it 🫶

The Client Link option is used only in a LEASEQUERY-REPLY message. It lists the links where the client has one or more bindings. The server uses it to reply to a query when no link-address was given and the client turns out to be on more than one link 👑

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     OPTION_LQ_CLIENT_LINK     |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  link-address (IPv6 address)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  link-address (IPv6 address)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • option-code: OPTION_LQ_CLIENT_LINK (48) ✨
  • option-len: the length of the list of links in octets. It must be a multiple of 16 🧮
  • link-address: a global address the server uses to identify the link where the client is located 🌸

A server MAY respond to a query by client-id, where the 0::0 link-address was specified, with this option if the client turns out to be on multiple links 🌈. The requestor can then repeat the query once for each link-address in the returned list, specifying the returned link-address 💅. If the client is on a single link, the server SHOULD return the client's data in an OPTION_CLIENT_DATA option 🦋

4.1.3. Status Codes 🚦

Okay, these are the new status codes that got defined 🎀:

  • UnknownQueryType (7): the query-type is unknown to the server, or the server doesn't support it 💀
  • MalformedQuery (8): the query isn't valid. For example, a required query-option is missing from the OPTION_LQ_QUERY 😭
  • NotConfigured (9): the server doesn't have the target address or link in its configuration 🙈
  • NotAllowed (10): the server doesn't let the requestor issue this LEASEQUERY 🔥

4.1.4. Transmission and Retransmission Parameters ⏱️

This section has a table of values that describe how leasequery messages get transmitted 💖

   Parameter     Default  Description
   ----------------------------------
   LQ_TIMEOUT     1 sec   Initial LEASEQUERY timeout
   LQ_MAX_RT     10 secs  Max LEASEQUERY timeout value
   LQ_MAX_RC      5       Max LEASEQUERY retry attempts

4.2. Message Validation 🧚

4.2.1. LEASEQUERY ✨

okay bestie, first up is LEASEQUERY messages 💅 Requestors and clients MUST discard any received LEASEQUERY messages, and servers have their own bouncer list. Servers MUST discard any received LEASEQUERY messages that meet any of the following conditions:

  • the message does not include an OPTION_CLIENTID option.
  • the message includes an OPTION_SERVERID option but the contents of the OPTION_SERVERID option does not match the server's identifier.
  • the message does not include an OPTION_LQ_QUERY option.

4.2.2. LEASEQUERY-REPLY 💌

now the replies 🫶 Requestors MUST discard any received LEASEQUERY-REPLY messages that meet any of the following conditions:

  • the message does not include an OPTION_SERVERID option.
  • the message does not include an OPTION_CLIENTID option, or the contents of the OPTION_CLIENTID option do not match the DUID of the requestor.
  • the transaction-id field in the message does not match the value used in the original message.

Servers and Relay Agents (on the server port, 547 [2]) MUST discard any received LEASEQUERY-REPLY messages.

4.3. DHCPv6 Leasequery Requestor Behavior 🦋

this section is all about how a requestor starts pulling lease data from DHCPv6 servers. it's giving detective energy 🕵️‍♀️

4.3.1. Creation of LEASEQUERY 🎀

the requestor sets the msg-type field to LEASEQUERY and generates a transaction ID, then pops that value into the transaction-id field.

The requestor MUST include an OPTION_CLIENTID option to identify itself to the server.

The requestor MUST include an OPTION_LQ_QUERY option and set the query-type, link-address, and query-options as appropriate to the query-type (Section 4.1.2.1).

The requestor SHOULD include an OPTION_SERVERID if it is not unicasting the LEASEQUERY yet only wants a response from a specific server.

4.3.2. Transmission of LEASEQUERY 🌸

The requestor MAY be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. If the requestor has not been explicitly configured, it MAY use the All_DHCP_Servers multicast address as the default.

The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers that are known to possess authoritative information concerning the query target.

In the absence of information concerning which DHCPv6 servers might possess authoritative information on the query target, the requestor SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows about or is configured with. For example, the requestor MAY send LEASEQUERY to the All_DHCP_Servers multicast address.

The requestor transmits LEASEQUERY messages according to Section 14 of [2], using the following parameters:

    IRT    LQ_TIMEOUT
    MRT    LQ_MAX_RT
    MRC    LQ_MAX_RC
    MRD    0

If the message exchange fails, the requestor takes an action based on the requestor's local policy. Examples of actions the requestor might take include:

  • Select another server from a list of servers known to the requestor.
  • Send to multiple servers by multicasting to the All_DHCP_Servers address.
  • Terminate the request.

4.3.3. Receipt of LEASEQUERY-REPLY 🧚

a successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE option (or one with an OPTION_STATUS_CODE option carrying a success code). there are three variants, and they're all different flavours 🍓

  1. If the server had bindings for the requested client, the message includes an OPTION_CLIENT_DATA option and the requestor extracts the client data from the LEASEQUERY-REPLY and updates its binding information database. If the OPTION_CLIENT_DATA contains no OPTION_CLT_TIME, the requestor SHOULD silently discard the OPTION_CLIENT_DATA option.
  2. If the server found bindings for the client on multiple links, the message includes an OPTION_CLIENT_LINK option. The requestor will need to reissue LEASEQUERY messages using each of the returned link-addresses to obtain the client's bindings.
  3. If the server had no bindings for the client, neither the OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.

an unsuccessful LEASEQUERY-REPLY is one that has an OPTION_STATUS_CODE with an error code. depending on the status code, the requestor may try a different server (such as for NotAllowed, NotConfigured, and UnknownQueryType), try a different or corrected query (such as for UnknownQueryType and MalformedQuery), or just terminate the query. 🙅‍♀️

4.3.4. Handling DHCPv6 Client Data from Multiple Sources 💜

this part is lowkey my favourite 🥹 a requestor can get lease data on the same client from the same DHCPv6 server in response to different types of LEASEQUERY. and if a LEASEQUERY goes out to multiple servers, the requestor may hear back from several of them about the same DHCPv6 client. so this section explains how the requestor handles multiple lease data sources on the same DHCPv6 client, whether they come from the same server or different servers.

the client data from the different sources may be disjoint or overlapping. both the disjoint and overlapping relationships can happen between data from the same server or from different servers.

if client data from two sources on the same client are of different types or values, then the data are disjoint. for example, a requestor gets an IPv6 address lease from one server and a prefix lease from another server, both assigned to the same client. a different-values (but same type) example is when a requestor gets two IPv6 address leases from two different servers, both assigned to the same client, but the leases are on two different IPv6 addresses. if the requestor receives disjoint client data from different sources, it SHOULD merge them. ✨

if client data from two sources on the same client are of the same type and value, then the data are overlapping. an example of overlapping data is when a requestor receives a lease on the same IPv6 address from two different servers. overlapping client data are also called conflicting data. 💥

The requestor SHOULD use the OPTION_CLT_TIME to resolve data conflicts originated from different servers, and SHOULD accept data with most recent OPTION_CLT_TIME.

4.4. DHCPv6 Leasequery Server Behavior 🌈

a DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid LEASEQUERY messages it gets, to return the statefully assigned addresses, delegated prefixes, and other information that matches the query. server era 🖥️

4.4.1. Receipt of LEASEQUERY Messages 👑

upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates the requested client, collects data on the client, and constructs and returns a LEASEQUERY-REPLY. a LEASEQUERY message cannot be used to assign, release, or otherwise modify bindings or other configuration information. 🙅‍♀️

the server builds a LEASEQUERY-REPLY by setting the msg-type field to LEASEQUERY-REPLY, and copying the transaction ID from the LEASEQUERY message into the transaction-id field.

if the query-type in the OPTION_LQ_QUERY option is not a known or supported value, the server adds an OPTION_STATUS_CODE option with the UnknownQueryType status code and sends the LEASEQUERY-REPLY to the requestor. if the query-options do not contain the required options for the query-type, the server adds an OPTION_STATUS_CODE option with the MalformedQuery status code and sends the LEASEQUERY-REPLY to the client.

a server may also restrict LEASEQUERY messages, or query-types, to certain requestors. in this case, the server MAY discard the LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the NotAllowed status code and send the LEASEQUERY-REPLY to the requestor. 🔒

if the OPTION_LQ_QUERY specified a non-zero link-address, the server MUST use the link-address to find the appropriate link for the client. for a QUERY_BY_ADDRESS, if the 0::0 link-address was specified, the server uses the address from the OPTION_IAADDR option to find the appropriate link for the client. in either of these cases, if the server is unable to find the link, it SHOULD return an OPTION_STATUS_CODE option with the NotConfigured status and send the LEASEQUERY-REPLY to the requestor.

for a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the server MUST search all of its links for the client. if the client is only found on a single link, the server SHOULD return that client's data in an OPTION_CLIENT_DATA option. if the client is found on more than a single link, the server MUST return the list of links in the OPTION_CLIENT_LINK option; the server MUST NOT return any client data. 🔍

otherwise, the server uses the data in the OPTION_LQ_QUERY to initiate the query. the result of the query will be zero or one client. this will result in zero or one OPTION_CLIENT_DATA option being added to the LEASEQUERY-REPLY.

4.4.2. Constructing the Client's OPTION_CLIENT_DATA 🧁

An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST minimally contain the following options:

  1. OPTION_CLIENTID
  2. OPTION_IAADDR and/or OPTION_IAPREFIX
  3. OPTION_CLT_TIME

depending on the bindings the client has on a link, either OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be present.

The OPTION_CLIENT_DATA SHOULD include options requested in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message and that are acceptable to return based on the list of "sensitive options", discussed below.

DHCPv6 servers SHOULD be configurable with a list of "sensitive options" that must not be returned to the requestor when specified in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message. Any option on this list MUST NOT be returned to a requestor, even if requested by that requestor. 🛡️

4.4.3. Transmission of LEASEQUERY-REPLY Messages 🦋

the server sends the LEASEQUERY-REPLY message as described in the "Transmission of Reply Messages" section of [2].

5. Security Considerations 🔒✨

Okay bestie, access concentrators are expected to be super common leasequery requestors 💅 Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed with LEASEQUERY messages, keep accurate client/binding info ✨. That means they can forward data traffic to the right destination in the broadband access network, do IPv6 source address verification on datagrams coming from the access network, and encrypt traffic that only the intended access modem can decrypt (e.g., [12] and [13]). So leasequery gives access concentrators a seriously upgraded security glow-up 🛡️💖

The "Security Considerations" section of [2] covers the general threats to DHCPv6, and that includes LEASEQUERY messages too 🧐. The "Authentication of DHCP Messages" section of [2] talks about securing communication between relay agents and servers, and between clients and servers 🔐. If the requestor is an access concentrator, the IPsec-based [9] security described in [2] Section 21.1 SHOULD be used 🫶. Every other type of requestor is basically a DHCPv6 client, so DHCPv6 authentication (Section 21 of [2]) is an appropriate way to secure LEASEQUERY and LEASEQUERY-REPLY messages 💜. And since there are relatively few leasequery requestors and servers in an administrative domain, shared key distribution issues stay pretty minimal 🌸

After you've put all of the above in place, the DHCPv6 server should only be talking to trusted LEASEQUERY requestors, and your security needs should be met ✨

BUT (and this is a big but 🙈), not all traffic comes straight from those trusted requestors. For example, trusted relay agents can relay LEASEQUERY messages from untrusted requestors, or from somewhere else in the network. This SHOULD be prevented at least at the perimeter relay agents (or on all relay agents, unless relayed LEASEQUERY messages are required for some requestors). DHCPv6 servers MAY be configured to discard relayed LEASEQUERY messages or restrict relay chaining 🚧

Even trusted requestors can be a little chaotic, so lock down what gets shared!

DHCPv6 servers SHOULD also be able to restrict the information returned for a client in a LEASEQUERY-REPLY, even when the requestor is trusted, as described in Section 4.4.2 🍓

Trusted access concentrators can still generate LEASEQUERY requests because of activity happening outside the access concentrator, so they SHOULD minimize denial-of-service attacks on the DHCPv6 servers by keeping the number of LEASEQUERY messages they generate low 🧚 In particular, the access concentrator SHOULD use negative caching (meaning it caches the fact that a particular recent query failed to return client data) and address restrictions where possible (meaning it doesn't send a LEASEQUERY message for addresses outside the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to sending one LEASEQUERY message (not counting retries) per legitimate broadband access network address after a reboot event 🎀

Packet-flooding denial-of-service attacks can exhaust processing resources, which stops the server from serving legitimate, regular DHCPv6 clients and legitimate DHCPv6 LEASEQUERY requestors 😭. That means configurations get denied to legitimate DHCPv6 clients, and lease information gets denied to legitimate DHCPv6 LEASEQUERY requestors. These attacks are unlikely when you're only talking to trusted LEASEQUERY requestors, but the possibility always exists that the trust is misplaced, the security techniques get compromised, or even trusted requestors have bugs in them 💀. So defending against packet-flooding denial of service is always a good idea 🔥. That includes good perimeter security (as mentioned earlier) and rate limiting DHCPv6 traffic at relay agents, other network elements, or the server itself.

One way to attack an access concentrator (as opposed to a DHCPv6 server) acting as a LEASEQUERY requestor is to set up a malicious server that gives the access concentrator incorrect lease or route information 👀. That thwarts source IPv6 address verification and stops correct routing from happening. This type of attack can be minimized by using IPsec as described in Section 21.1 of [2] 🛡️✨

6. IANA Considerations 📋

IANA has assigned the following new DHCPv6 Message types in the registry maintained at http://www.iana.org/assignments/dhcpv6-parameters:

LEASEQUERY
LEASEQUERY-REPLY

IANA has assigned the following new DHCPv6 Option Codes in the registry maintained at http://www.iana.org/assignments/dhcpv6-parameters:

OPTION_LQ_QUERY
OPTION_CLIENT_DATA
OPTION_CLT_TIME
OPTION_LQ_RELAY_DATA
OPTION_LQ_CLIENT_LINK

IANA has assigned the following new DHCPv6 Status Codes in the registry maintained at http://www.iana.org/assignments/dhcpv6-parameters:

UnknownQueryType
MalformedQuery
NotConfigured
NotAllowed

IANA has also created a brand new registry for the OPTION_LQ_QUERY option query-type codes, maintained at http://www.iana.org/assignments/dhcpv6-parameters, with these initial assignments 🍭:

QUERY_BY_ADDRESS       1
QUERY_BY_CLIENTID      2

New OPTION_LQ_QUERY option query-type codes are assigned through Standards Action, as defined in [6] 📜

7. Acknowledgements 🫶

Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their input, ideas, and review during the production of this document 💖 The real MVPs 👑

8. References 📚

8.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
  • [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

8.2. Informative References

  • [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [8] 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.
  • [9] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [10] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Work in Progress, November 2006.
  • [11] CableLabs, "Data-Over-Cable Service Interface Specifications: DOCSIS 3.0, MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available at http://www.cablemodem.com/.
  • [12] 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/.
  • [13] 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/.

Authors' Addresses 🖊️

John Jason Brzozowski
Comcast Cable
1800 Bishops Gate Boulevard
Mt. Laurel, NJ  08054
USA

Phone: +1 856 324 2671
EMail: john_brzozowski@cable.comcast.com


Kim Kinnear
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: +1 978 936 0000
EMail: kkinnear@cisco.com


Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: +1 978 936 0000
EMail: volz@cisco.com


Shengyou Zeng
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: +1 978 936 0000
EMail: szeng@cisco.com

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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. that's a wrap, bestie 🌈💜🫶

📦 where this page comes from