RFC 7653
DHCPv6 Active Leasequery
RFC 7653: DHCPv6 Active Leasequery 🦋
okay bestie, let's get into it 💅 this is RFC 7653, called DHCPv6 Active Leasequery, and it comes from the IETF (Internet Engineering Task Force) 🌸 it was written by D. Raghuvanshi, K. Kinnear, and D. Kukrety, all at Cisco Systems, Inc. 💖 it's dated October 2015 and it's a Standards Track document, so it's an actual Internet standard and not just a vibe 😭 its ISSN is 2070-1721. the main tea is that it updates RFC 5460 (DHCPv6 Bulk Leasequery) by adding new options 🎀
Status of This Memo 📜
this is an Internet Standards Track document 🔥
it's a product of the IETF, which means it reflects the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7653 🦋
Copyright Notice ⚖️
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📄 please read these carefully, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💀
Table of Contents 🗺️
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Interaction between Active Leasequery and Bulk Leasequery .......8
5. Extension to DHCPv6 Bulk Leasequery .............................8
6. Message and Option Definitions ..................................9
6.1. Message Framing for TCP ....................................9
6.2. Messages ...................................................9
6.2.1. ACTIVELEASEQUERY ....................................9
6.2.2. STARTTLS ...........................................10
6.2.3. Response Messages ..................................10
6.3. Options ...................................................10
6.3.1. OPTION_LQ_BASE_TIME ................................10
6.3.2. OPTION_LQ_START_TIME ...............................11
6.3.3. OPTION_LQ_END_TIME .................................12
6.4. Connection and Transmission Parameters ....................12
7. Information Communicated by Active Leasequery ..................13
8. Requestor Behavior .............................................14
8.1. General Processing ........................................14
8.2. Initiating a Connection ...................................14
8.3. Forming an Active Leasequery ..............................15
8.4. Processing Active Replies .................................16
8.4.1. Processing Replies from a Request Containing an
OPTION_LQ_START_TIME ...............................18
8.5. Processing Time Values in Leasequery Messages .............20
8.6. Examples ..................................................21
8.6.1. Query Failure ......................................21
8.6.2. Data Missing on Server .............................21
8.6.3. Successful Query ...................................21
8.7. Closing Connections .......................................22
9. Server Behavior ................................................22
9.1. Accepting Connections .....................................22
9.2. Rejecting Connections .....................................24
9.3. Replying to an Active Leasequery ..........................24
9.4. Multiple or Parallel Queries ..............................26
9.5. Closing Connections .......................................26
10. Security Considerations .......................................27
11. IANA Considerations ...........................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Acknowledgments ...................................................30
Authors' Addresses ................................................301. Introduction ✨
okay so the DHCPv6 protocol [RFC3315] is the mechanism for handing out IPv6 address and configuration info to IPv6 nodes 🧚 then IPv6 Prefix Delegation for DHCPv6 [RFC3633] is the mechanism for delegating IPv6 prefixes and related data 💅 DHCPv6 servers keep the authoritative info, including binding info for those delegated prefixes 📦
there are requirements for external entities to stay up to date on which DHCPv6 clients go with which bindings 👀 these entities need to keep up with the server's current binding activity, and that's called "active" leasequery 🔥
DHCPv6 Bulk Leasequery [RFC5460] can pull useful info out of a DHCPv6 server when some external entity starts up 🌈 that entity could be something directly involved in the client-server transactions (like a relay agent), or it could be an external process that needs info from the server's lease state database 🫶
Active Leasequery, the thing this doc is about, is built so an entity that's not directly involved in those client-server transactions can still stay current with the DHCPv6 lease state info in real time ⭐
this document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new options, as described in Section 6.2.1 🎀 for DHCPv6 servers that support Bulk Leasequery but not Active Leasequery, Section 9.2 specifies how to reject incoming Active Leasequery requests 🙅♀️
2. Terminology 📖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶
DHCPv6 terminology is defined in [RFC3315] 💜 the terms specific to DHCPv6 Active Leasequery are below:
- absolute time 🕰️ A 32-bit unsigned quantity containing the number of seconds since midnight (UTC), January 1, 2000, modulo 2^32.
- Active Leasequery 🦋 Keeping up to date in real time (or near real time) with DHCPv6 binding activity.
- Bulk Leasequery 📦 Requesting and receiving information about all or some of the existing DHCPv6 binding information in an efficient manner, as defined by [RFC5460].
- blocked TCP connection 🚧 A TCP connection is considered blocked if the underlying TCP transport will not accept new messages to be sent without blocking the thread that is attempting to send the message.
- binding change/update 🔄 Any change in the DHCPv6 binding state. This also includes expiration or deletion of the binding.
- catch-up information 🏃♀️ If a DHCPv6 Active Leasequery requestor sends an OPTION_LQ_START_TIME option in an ACTIVELEASEQUERY message, the DHCPv6 server will attempt to send the requestor the information that changed since the time specified in the OPTION_LQ_START_TIME option. The binding information sent to satisfy this request is the catch-up information.
- catch-up phase ⏳ The period while catch-up information is being sent is the catch-up phase.
- clock skew ⏱️ The difference between the absolute time on a DHCPv6 server and the absolute time on the system where a requestor of an Active or Bulk Leasequery is executing is termed the "clock skew" for that Active or Bulk Leasequery connection. It is not absolutely constant but is likely to vary only slowly. While it is easy to think that this can be calculated precisely after one message is received by a requestor from a DHCPv6 server, a more accurate value is derived from continuously examining the instantaneous value developed from each message received from a DHCPv6 server and using it to make small adjustments to the existing value held in the requestor.
- DHCPv6 binding state 🗂️ Data stored on the DHCPv6 server related to binding.
- requestor 🙋♀️ The node that sends LEASEQUERY messages to one or more servers to retrieve information on the bindings for a client.
- transaction-id 🔖 An opaque value used to match responses with queries initiated by an Active Leasequery requestor.
3. Protocol Overview ✨
okay so Active Leasequery is basically built on top of the DHCPv6 Bulk Leasequery [RFC5460] 💅 most of the differences come from the fact that the TCP [RFC7414] connection stays open for a long time 🦋 A DHCPv6 server that supports Active Leasequery MUST support Bulk Leasequery [RFC5460] as well 🫶
The requestor opens a TCP connection to a DHCPv6 server on port 547, the DHCPv6 port 🌸 That means the Leasequery requestor needs the server's IP address(es) from configuration or some other means, and it needs unicast IP reachability to the DHCPv6 server. No relaying for Active Leasequery is specified, so don't go looking for it 🙈
Once the connection is up, the requestor sends an ACTIVELEASEQUERY message over it. The server responds by sending updates back using LEASEQUERY-REPLY and LEASEQUERY-DATA messages. This is similar to the response procedure in [RFC5460], except the server sends updates whenever some activity changes a binding's state, which is exactly why the connection has to be long-lived ⭐ Also, the Active Leasequery server SHOULD provide a mechanism to control which data is allowed to be included in the OPTION_CLIENT_DATA messages sent to the requestor. See Section 9.3 for the details 🎀
Active Leasequery has features that let this external entity lose its connection, reconnect, and get the latest information about any IPv6 bindings that changed while it was disconnected. Iconic behavior, honestly 👑
These features exist so the Active Leasequery requestor can get current with the lease state database quickly after it restarts or after the machine it runs on gets reinitialized 🔥 Sure, it's easy to define a protocol that works when the requestor is always connected to the DHCPv6 server. But that's not robust enough for real life, so a lot of this document is about handling the situations where the requestor gets disconnected from the DHCPv6 server it's receiving updates from and then reconnects to that same server 💜
The central idea here: if the Active Leasequery requestor loses service, it can specify the time of its most recent update in a later Active Leasequery request. The DHCPv6 server then figures out whether any data was missed while the requestor was disconnected 🧚
The DHCPv6 server processing the Active Leasequery request MAY limit the amount of data it saves. There are methods the server can use to tell the Active Leasequery requestor that data was missed, meaning not all of the data could be saved. In that case, the Active Leasequery requestor should issue a Bulk Leasequery [RFC5460] to recover the information that isn't available through an Active Leasequery 😭
DHCPv6 servers are not required to keep any data for changes missed on an Active Leasequery connection. They will typically choose to keep data about some recent activity available for later queries from a DHCPv6 Active Leasequery requestor whose connection was temporarily interrupted. In other words, DHCPv6 servers that support catch-up are required to have some mechanism to keep or save historic information about bindings 🍓
An Active Leasequery requestor would typically use Bulk Leasequery to initialize its database with all current data when that database has no binding information. It would also use Bulk Leasequery to recover missed information if its connection with the DHCPv6 server was lost for longer than the DHCPv6 server keeps track of the specific changes to the IPv6 binding information 🌈
The messages the server sends in response to an Active Leasequery request should be identical to the messages it sends to a Bulk Leasequery request, in terms of how the data is encoded into the Active Leasequery responses. Likewise, the actions the requestor takes to interpret Active Leasequery responses should be identical to how it interprets Bulk Leasequery responses. So the handling of OPTION_CLIENT_DATA and the additional options discussed in the Bulk Leasequery specification [RFC5460] is followed when implementing Active Leasequery, with one exception: a server responding to an Active Leasequery request SHOULD be able to be configured to prevent specific data items from being included in the OPTION_CLIENT_DATA option, even if they were requested through the OPTION_ORO option 💖
4. Interaction between Active Leasequery and Bulk Leasequery 🧚♀️
Active Leasequery is an extension of the Bulk Leasequery protocol [RFC5460], so the format of the messages returned to an Active Leasequery requestor is identical to what's defined for Bulk Leasequery [RFC5460] 🫶
Applications that use Active Leasequery to keep a database up to date with the DHCPv6 server's lease state database should first use an initial Bulk Leasequery to bring their database into equivalence with the server's. After that, they use Active Leasequery to keep that database current with the server's lease state database 🔥
The two protocols do differ in a few ways. Active Leasequery defines a new message, ACTIVELEASEQUERY, for sending Active Leasequery requests to the DHCPv6 server. An Active Leasequery connection sends all available updates to the requestor, based on the OPTION_LQ_QUERY option (see Section 6.2.1) 💅
An Active Leasequery connection never really "completes" 🙈 The DHCPv6 server can still close the connection, though, for a variety of reasons tied to some sort of exception condition 💀
5. Extension to DHCPv6 Bulk Leasequery 🌸
This document extends the DHCPv6 Bulk Leasequery protocol [RFC5460] by defining new options: OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME 🎀 The DHCPv6 server sends the OPTION_LQ_BASE_TIME option in a Bulk Leasequery response if the requestor asked for it in the Bulk Leasequery request. OPTION_LQ_START_TIME and OPTION_LQ_END_TIME can be used in a Bulk Leasequery request sent to the DHCPv6 server. You can find more details about these options in Section 6.3 ✨
6. Message and Option Definitions 👑
6.1. Message Framing for TCP
Since TCP lets one or more DHCPv6 messages be sent in response to a single Active Leasequery request, the receiver needs to be able to tell how large each message is 🦋 The same message framing technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for Active Leasequery too.
The whole point of using the same format is that code which already knows how to handle a message returned from DHCPv6 Bulk Leasequery [RFC5460] will also be able to handle the message held inside the TCP framing 🫶
When using Transport Layer Security (TLS), once TLS negotiation completes, the connection is encrypted and protected from eavesdropping. Normal Active Leasequery messages are then sent and received using the TLS application data protocol services (see Section 10 of [RFC5246]) 🔐💖
6.2. Messages
6.2.1. ACTIVELEASEQUERY
The new ACTIVELEASEQUERY message type is designed to keep the requestor up to date in real time, or near real time, with DHCPv6 bindings 🔥 It asks the server to return DHCPv6 binding activity that occurs after the Active Leasequery request is received.
An ACTIVELEASEQUERY request MUST contain a transaction-id, and that transaction-id MUST be locally unique on the TCP connection on which it is sent to the DHCPv6 server 💅
When sending an ACTIVELEASEQUERY request, the requestor MAY include the OPTION_LQ_START_TIME option. If it does, the DHCPv6 server returns all the bindings changed on or after the OPTION_LQ_START_TIME 🧚
If the requestor wants every binding update from the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in the ACTIVELEASEQUERY message. But if the requestor only cares about specific binding updates, it MAY include an OPTION_LQ_QUERY option along with a query-type defined in [RFC5007] and [RFC5460] 🌈
Other DHCPv6 options used in the LEASEQUERY message (as specified in [RFC5460]) can also be used in the ACTIVELEASEQUERY message ✨
6.2.2. STARTTLS
The new STARTTLS message type is designed for establishing a TLS connection between a requestor and a DHCPv6 server 🔐 The STARTTLS message SHOULD be sent without any options. Any options received in a STARTTLS message SHOULD be ignored 🙈
More details about this message are in Section 8.2 🎀
6.2.3. Response Messages
The LEASEQUERY-REPLY message is defined in [RFC5007]. The LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in [RFC5460] 🍓
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message indicates whether a query succeeded or failed. It also carries data that doesn't change within the context of a single query and answer, like the Server-ID and Client-ID options 💜 If a query is successful, the DHCPv6 server MUST respond to it with exactly one LEASEQUERY-REPLY message. If the server is returning binding data, that LEASEQUERY-REPLY also contains the first client's binding data in an OPTION_CLIENT_DATA option. Additional binding data is returned in LEASEQUERY-DATA messages, as explained in DHCPv6 Bulk Leasequery [RFC5460] 🦋 If a query fails, a single LEASEQUERY-REPLY message is returned without any binding data 😭
6.3. Options
The new options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk Leasequery [RFC5460]. The reply messages for Active Leasequery use these options along with the options defined in [RFC3315], [RFC5007], and [RFC5460] 💖
6.3.1. OPTION_LQ_BASE_TIME
The OPTION_LQ_BASE_TIME option is the current time at which the message was created to be sent by the DHCPv6 server to the requestor of the Active or Bulk Leasequery, if the requestor asked for it in an Active or Bulk Leasequery request. This MUST be an absolute time, meaning seconds since midnight January 1, 2000 UTC 🕰️✨ All of the other time-based options in the reply message are relative to this time, including OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 server that placed this option in a message 🌸
This is an unsigned integer in network byte order 🔢
The code for this option is 100 🎀
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_BASE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_BASE_TIME (100)
option-len 4
base-time DHCPv6 Server Base Time6.3.2. OPTION_LQ_START_TIME ✨
okay so OPTION_LQ_START_TIME is how you tell the DHCPv6 server "hey, only send me the bindings that changed on or after this moment" 🕰️✨ it's giving catch-up energy. This option MAY be used in Active or Bulk Leasequery requests made to a DHCPv6 server 💖
the requestor MUST figure out the OPTION_LQ_START_TIME using lease information it has already received from the DHCPv6 server 🧠 and it MUST be an absolute time in the DHCPv6 server's context (see Section 8.5). no relative times, bestie 🙅♀️
typically (though this is not a requirement) the OPTION_LQ_START_TIME will hold the value most recently received in an OPTION_LQ_BASE_TIME option by the requestor 🎀 because that value shows the last successful communication with the DHCPv6 server. so it's basically the receipt for your last good chat 💅
this is an unsigned integer in network byte order 🔢
the code for this option is 101 🦋
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_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_START_TIME (101)
option-len 4
query-start-time DHCPv6 Server Query Start Time6.3.3. OPTION_LQ_END_TIME 🌙
the OPTION_LQ_END_TIME option is the flip side 💜 it tells the DHCPv6 server "and only send me bindings that changed on or before this time." it MAY be used in a Bulk Leasequery request, but it MUST NOT be used in an Active Leasequery request 🙅♀️ so keep it out of your live Active chats, okay?
the requestor MUST determine the OPTION_LQ_END_TIME based on lease information it has received from the DHCPv6 server 📋 and this MUST be an absolute time in the context of the DHCPv6 server ⏰
in the absence of information to the contrary, the requestor SHOULD assume that the time context of the DHCPv6 server is identical to the time context of the requestor (see Section 8.5) 🕐 so unless you've been told otherwise, assume you're both on the same clock 🫶
this is an unsigned integer in network byte order 🔢
the code for this option is 102 🌸
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_END_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-end-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_END_TIME (102)
option-len 4
query-end-time DHCPv6 Server Query End Time6.4. Connection and Transmission Parameters 🔌
Active Leasequery uses the same port configuration as DHCPv6 Bulk Leasequery [RFC5460] 🎀 it also uses the other transmission parameters (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460]. so the setup is shared, bestie 🫶
this section has a table of values that control Active Leasequery behavior, including recommended defaults 📊 implementations MAY make these values configurable 🛠️ but heads up: configuring timeout values that are too small may lead to harmful behavior, both to this application and to other traffic on the network 😬 so timeout values smaller than the default values SHOULD NOT be used 🙅♀️
+------------------------+----------+-------------------------------+
| Parameter | Default | Description |
+------------------------+----------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout |
+------------------------+----------+-------------------------------+7. Information Communicated by Active Leasequery 📡
while Bulk Leasequery [RFC5460] info comes straight from the DHCPv6 server's lease state database 🗄️ the info from an Active Leasequery is real-time 🔴 it's whatever is currently associated with a particular binding in that database right now ✨
this matters a LOT 😭 if your Active Leasequery requestor runs slowly, or it disconnects and then reconnects with an OPTION_LQ_START_TIME option (signaling a catch-up operation), you only get the most current info from the lease state database. the old stuff is gone, periodt 💀
the requestor of an Active Leasequery MUST NOT assume that every lease state change is communicated across an Active Leasequery connection 🚫 even if the requestor stays connected, the DHCPv6 server is only required to transmit information about a binding that is current when the message is created and handed off to the TCP stack to send to the requestor 📮
if the TCP connection blocks and the DHCPv6 server is waiting to send information down the connection, then when the connection becomes available to be written, the DHCPv6 server MAY create the message to send at this time 🧃 the current state of the binding gets sent, and any transition in state or other info that happened while the TCP connection was blocked will be lost 😭
so the Active Leasequery protocol does NOT let the requestor build a complete history of every activity on every lease 📚 but you can make an effective history of the important state changes if the DHCPv6 server's parameters are tuned for the needs of an Active Leasequery requestor 🛠️ for instance, the period after the expiration or release of a binding could be configured long enough (say several minutes, well more than the receive timeout) so that an Active Leasequery requestor is less likely to miss any changes in the binding 🌈 main character energy for the server config, honestly 👑
8. Requestor Behavior 🧑💻
8.1. General Processing 🚦
a requestor attempts to establish a TCP connection to a DHCPv6 server to start an Active Leasequery exchange 🔗 if the attempt fails, the requestor MAY retry. retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT 💜 see Section 6.4.
if an Active Leasequery gets terminated early by a LEASEQUERY-DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE option) of QueryTerminated, or because the connection it was submitted over fails, the requestor MAY retry the request after creating a new connection 🔄 retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT ⏳ see Section 6.4.
messages from the DHCPv6 server come as multiple responses to a single ACTIVELEASEQUERY message 📨 so each ACTIVELEASEQUERY request MUST have a transaction-id that's unique on the connection it's sent on 🆔 and all the messages that come back as a response to it contain the same transaction-id as the request 🫶
8.2. Initiating a Connection 🤝
a requestor SHOULD be able to operate in either insecure or secure mode 🔐 this MAY be a feature that's administratively controlled 🎛️
when operating in insecure mode, the requestor SHOULD proceed to send an ACTIVELEASEQUERY message after the TCP connection is established 🚀
when operating in secure mode, the requestor MUST attempt to negotiate a TLS [RFC5246] connection over the TCP connection 🔒 if that negotiation fails, the requestor MUST close the TCP connection ❌ the recommendations in [RFC7525] SHOULD be followed when negotiating this connection 📝
a requestor asks for a TLS connection by sending the STARTTLS message to the DHCPv6 server as the first message over the TCP connection 🙋♀️ this tells the DHCPv6 server that a TLS connection over this TCP connection is wanted. there are four possibilities after the requestor sends the STARTTLS message:
- no response from the DHCPv6 server 🦗
- the DHCPv6 server closes the TCP connection after it receives the STARTTLS message 💨
- the DHCPv6 server responds with a REPLY [RFC3315] message with a DHCPv6 status code of TLSConnectionRefused 🚫
- the DHCPv6 server responds with a REPLY [RFC3315] message without a DHCPv6 status code, indicating success 🎉
in any of the first three possibilities, the DHCPv6 server can be assumed to not support TLS 🥲 in this case, the requestor MUST close the TCP connection 👋
in the final possibility, where the DHCPv6 server has responded with a REPLY message without a DHCPv6 status code to the requestor's STARTTLS message, the requestor SHOULD initiate the exchange of messages involved in a TLS handshake [RFC5246] 🤝 during the TLS handshake, the requestor MUST validate the DHCPv6 server's digital certificate 🪪 no skipping this step, bestie 🙅♀️
if the handshake exchange yields a functioning TLS connection, then the requestor SHOULD transmit an ACTIVELEASEQUERY request over that TLS connection, and use that TLS connection for all further interactions it has with the DHCPv6 server over this TCP connection 🔐💖
if the handshake exchange does NOT yield a functioning TLS connection, then the requestor MUST close the TCP connection 💔
8.3. Forming an Active Leasequery ✨
okay so Active Leasequery is basically designed to set up a long-lived connection between the requestor and the DHCPv6 server handling the query 🦋 and the server SHOULD send binding info back over that connection with minimal delay once it learns about it 💅. it can learn about bindings either because it made them itself or because another server told it about one. the way that's giving "stay updated in real time" 😭
the part that's lowkey iconic is that the requestor can ask for some recent data to be sent right away, at the same time as the ongoing binding info is streaming in more or less in real time 🔥. this is how an Active Leasequery requestor catches up on anything it missed if it temporarily loses connectivity with the DHCPv6 server that handled its previous Active Leasequery. main character recovery arc 🌸
this works because each Leasequery reply sent as the result of a previous Active Leasequery comes with an OPTION_LQ_BASE_TIME option 🧚. the requestor SHOULD keep track of the highest base-time it got from a particular DHCPv6 server over an Active Leasequery connection 💜. then, if it ever needs to reestablish an Active Leasequery connection to that server (for whatever reason 🙈), it SHOULD put that highest base-time value into an OPTION_LQ_START_TIME option in the new Active Leasequery request ✨.
Heads up, bestie: until ALL of the recent data (the catch-up data) has been received, the requestor MUST NOT keep track of the base-time (OPTION_LQ_BASE_TIME) from Leasequery reply messages to use later in a subsequent Active Leasequery request. no shortcuts, periodt 💀
if the requestor doesn't want to ask for the stuff it missed while it wasn't connected, then it SHOULD NOT include the OPTION_LQ_START_TIME option in the Active Leasequery request 🍓. totally valid choice, no judgment 🫶.
and if the TCP connection gets blocked or stops being writable while the requestor is sending its query, the requestor SHOULD terminate the connection after BULK_LQ_DATA_TIMEOUT 😭. the reason this is recommended is so requestors can control how long they're willing to wait before giving up on a connection, no matter what notifications the TCP implementation they're using is sending them 💅🌈.
8.4. Processing Active Replies 🎀
the requestor tries to read a LEASEQUERY-REPLY message from the TCP connection 🦋. if the stream of replies gets blocked, the requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT, and it MAY begin retry processing if it's set up to do that 🔥.
the requestor looks at the LEASEQUERY-REPLY message and figures out what to do next 💅. the message validation rules live in DHCPv6 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] 📚. if the reply has a DHCPv6 status code (carried in an OPTION_STATUS_CODE option), the requestor should follow the recommendations in [RFC5007] 🧚.
okay, real talk: a connection from accepting an Active Leasequery request can be long-lived and might not have data flowing the whole time 🌸. so the DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds (default 60) 💖. this lets the requestor know the connection is still alive 🫶. it only does this when the connection is idle, meaning the server has no binding data to send ✨. during a normal exchange of binding data, getting a LEASEQUERY-DATA message already tells the requestor the connection is active 🎀.
the default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, which is twice the default of 60 seconds for ACTIVE_LQ_IDLE_TIMEOUT, the value that drives the DHCPv6 server to send messages 👑. so ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to delays from the DHCPv6 server when it's sending updates or LEASEQUERY-DATA messages 🥹. the vibe is "how patient am I being" 🙈.
one ACTIVELEASEQUERY can, and usually will, result in a whole bunch of replies 💅. the requestor MUST be prepared to receive more than one reply with transaction-ids matching a single ACTIVELEASEQUERY message from a single DHCPv6 server 🌈. be ready for the flood, bestie 🫶.
an Active Leasequery has two regimes: the catch-up phase (if there is one) and everything after it 🦋. if the Active Leasequery was requested with an OPTION_LQ_START_TIME option, it starts out in the catch-up phase ✨. check out Section 8.4.1 for how to process things during catch-up and how to tell when it's done 📚.
here's the tea ☕: the updates the DHCPv6 server sends during the catch-up phase are NOT in the order the lease state data was updated 😭. so the OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT be saved and used to compute the next ACTIVELEASEQUERY message's OPTION_LQ_START_TIME option 💀.
after the catch-up phase, or during the whole series of messages from an Active Leasequery request with no OPTION_LQ_START_TIME (so no catch-up phase at all), the OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved 💜. it works as a record of the most recent time data was received 🧚. that base-time (in the context of the DHCPv6 server) can then go into a later Active Leasequery message's OPTION_LQ_START_TIME after the Active Leasequery connection drops 🔥.
the LEASEQUERY-DONE message MAY unilaterally end a successful Active Leasequery request that's still in progress, in case the DHCPv6 server decides it can't keep processing the request 🙈. for example, when a server is asked to shut down, it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 status code of QueryTerminated and include the OPTION_LQ_BASE_TIME option in it 🍓. this MUST be the last message on that connection, and once it's been sent, the server MUST close the connection 😭💅.
after getting LEASEQUERY-DONE with a QueryTerminated status from a server, the requestor MAY close the TCP connection to that server 🌸✨
8.4.1. Processing Replies from a Request Containing an OPTION_LQ_START_TIME ✨
okay so if the Active Leasequery came with an OPTION_LQ_START_TIME option, the DHCPv6 server is going to try to send info about every binding that changed since that time 🕰️ this is the catch-up phase, and it's giving "let me get you up to speed bestie" 💖 The server MAY also slip real-time binding updates into that same connection 🦋 so the catch-up phase can run in parallel with the normal updates the Active Leasequery request makes. multitasking 💅
A DHCPv6 server MAY only keep a limited amount of time-ordered info around to answer an Active Leasequery request with an OPTION_LQ_START_TIME option 🙈 so the time in that option could be a time the server has no time-ordered info for. when there isn't enough saved data to satisfy the OPTION_LQ_START_TIME request, the server replies right away with a LEASEQUERY-REPLY message that has a DHCPv6 status code of DataMissing and a base-time option set to the server's current time 💀 that's the end of the catch-up phase, and the only updates you'll get on this connection from here on are the real-time ones from the Active Leasequery request. the end of an era 😭
if there IS enough saved data, then LEASEQUERY-REPLY (with an OPTION_STATUS_CODE of Success, or a reply without the OPTION_STATUS_CODE option at all) and LEASEQUERY-DATA messages start rolling in 🌸 some of those are part of the OPTION_LQ_START_TIME catch-up, and some are real-time updates of binding changes happening on the server. the tea is that in general there's no way to tell which is which 🍵
the catch-up updates do NOT come in the order the binding data was updated 🙃 so until the catch-up phase is done, the requestor can't reset its latest base-time value from the incoming messages (to use in a later Active Leasequery's query-start-time option) 🚫 why? because doing that would wreck the ability to recover lost info if the Active Leasequery ended before catch-up finished. super important, don't skip this 🫶
the requestor will know catch-up is complete when the server sends a LEASEQUERY-DATA message with the DHCPv6 status code of CatchUpComplete (or a LEASEQUERY-REPLY message with a status code of DataMissing, like we talked about above) 🎉 once that's sent, every additional LEASEQUERY-DATA message is about real-time ("new") binding changes on the server. we're in the new era now 👑
Heads up: the requestor SHOULD keep track of the latest base-time option value it received over a particular connection, so it can use it in a later Active Leasequery request, but only once the catch-up phase is complete. 🔥
Before catch-up is complete, if the connection goes away, or the requestor gets a LEASEQUERY-DONE message, then when it reconnects it MUST use the base-time value from the previous connection, NOT any base-time value from the connection that just closed 🙅♀️ no cap, this is a big deal. don't let the new connection's base-time sneak in early 💅
there's also a case where the server had enough data to START satisfying the OPTION_LQ_START_TIME request, but then partway through it realized it couldn't keep going (the aging algorithm kicks in during transmission and makes [some of] the saved data unavailable) 😱 so the server ends the catch-up phase right then by sending a LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and a base-time option set to the current time. plot twist, but it's still a clean ending 🎬
now the vibes check 🪞 the requestor MUST NOT assume that every single state change of every binding between the OPTION_LQ_START_TIME time and now is replicated in an Active Leasequery reply message. the requestor MAY assume that at least one Active Leasequery reply message exists for every binding that had one or more state changes during the period from OPTION_LQ_START_TIME to the current time. the LAST message for each binding has the state as of right now, and there can be one or more messages about a single binding during catch-up. so it's like, you get the latest outfit, not every single outfit change 👗✨
bindings can change multiple times while the requestor isn't connected (aka from the OPTION_LQ_START_TIME time until now) 🔄 the requestor will only get info about the binding's CURRENT state, not every state change that happened in that window. we stan a summary, but it's not the full diary 📖
if the requestor gets a LEASEQUERY-REPLY or LEASEQUERY-DATA message with a DataMissing status code AND it wants its database to stay up to date with the bindings on the server, then it SHOULD issue a Bulk Leasequery request to recover the info that's missing 🧩 that Bulk Leasequery request SHOULD include an OPTION_LQ_START_TIME option with the SAME value as the OPTION_LQ_START_TIME option from the earlier Active Leasequery responses, and an OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option the server returned in that DataMissing message 📅 basically you fill in the gap with a Bulk query, bestie 🧚
typically, the requestor has one connection open to the DHCPv6 server for the Active Leasequery request, and maybe one more connection open for a Bulk Leasequery request to the same server to fill in whatever data might have been missed before the Active Leasequery started 🌈 the Bulk Leasequery connection usually runs to completion and then closes, leaving ONE Active Leasequery connection open to a single DHCPv6 server. team Active Leasequery forever 💜
8.5. Processing Time Values in Leasequery Messages 🕰️
okay time zones but make it networking 🌍 Active or Bulk Leasequery requests can go to a DHCPv6 server whose absolute time isn't synced with the requestor's local time. so even the simplest Active or Bulk Leasequery response has at least TWO time contexts 👯♀️
if the requestor is saving the returned data in some form, it has to store a bunch of time values 💾 some are in the context of the requestor, and some are in the context of the DHCPv6 server. keeping them straight is a whole vibe 🎀
when the requestor gets an Active or Bulk Leasequery reply message from the DHCPv6 server, that message will contain an OPTION_LQ_BASE_TIME option 🍓 the time in that option is in the context of the DHCPv6 server. so it's the perfect time to save and reuse as input in the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME options, if the requestor ever needs to send an Active or Bulk Leasequery later with those options. these options need a time in the server's context, so yes, that's why it's perfect 💅
on top of saving OPTION_LQ_BASE_TIME for future use in OPTION_LQ_START_TIME or OPTION_LQ_END_TIME, the OPTION_LQ_BASE_TIME option is also used to convert the other times in the Leasequery message into values that make sense in the requestor's context 🔁 it's the bridge between the two clocks, iykyk 🌉
in systems whose clocks are synchronized (maybe using the Network Time Protocol (NTP)), the clock skew will usually be zero 🥰 which is not only acceptable, it's DESIRED. the dream is zero skew, babe ✨
8.6. Examples 🧁
these examples show what a series of queries and responses might look like 📸 they're only examples, though, so there's no requirement that these sequences must be followed 🙃 you do you, within the spec 💖
8.6.1. Query Failure 🚫
this example shows the message flow when the DHCPv6 server figures out it can't accept and/or process an Active Leasequery request from the requestor 😬 that could happen for a bunch of reasons (aka UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, and NotSupported).
Client Server
------ ------
ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)8.6.2. Data Missing on Server 🫥
this example shows the message flow when the DHCPv6 server realizes it doesn't have enough saved data to satisfy the request specified by the OPTION_LQ_START_TIME option 🕳️
here, the server replies right away with a LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing and a base-time option set to the server's current time. this signals the end of the catch-up phase, and the only updates you'll get on this connection are the real-time updates from the Active Leasequery request 🔚
Client Server
------ ------
ACTIVELEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 (w/error)
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 28.6.3. Successful Query 🎉
this example shows the message flow when the DHCPv6 server processes the query successfully 🥳
here, the server replies immediately with a LEASEQUERY-REPLY message (with an OPTION_STATUS_CODE of Success, or a reply without the OPTION_STATUS_CODE option), followed by binding data in LEASEQUERY-DATA messages. if the server wants to abort an in-process request and close the connection for some reason, it sends LEASEQUERY-DONE with an error code in the OPTION_STATUS_CODE option 🛑
Client Server
------ ------
ACTIVELEASEQUERY xid 3 ----->
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 (w/error)8.7. Closing Connections 👋
the requestor or DHCPv6 Leasequery server MAY close its end of the TCP connection at any time 🔌 the requestor MAY choose to keep the connection open if it plans to issue more queries. BUT (and this is important) keeping it open does NOT guarantee the connection will still be available for more queries, because the server might decide to close it based on its own configuration 🫠 so don't get too attached to the connection, babe 💔
9. Server Behavior 🖥️
a DHCPv6 server that supports Active Leasequery MUST support DHCPv6 Bulk Leasequery [RFC5460] along with the updates mentioned in this document 🦋 the server's got homework, and it's giving full support energy 👑
9.1. Accepting Connections ✨
okay so DHCPv6 servers that do Active Leasequery 🎀 are listening for incoming TCP connections 🦋. Accepting the requestor's connection works the same way as in DHCPv6 Bulk Leasequery [RFC5460], with one big twist: Active Leasequery MUST NOT be enabled by default 🙅♀️, and it MUST need an explicit configuration step before it will work at all 💅.
DHCPv6 servers SHOULD be able to run in either insecure or secure mode 🔐. This MAY be a mode the admin controls, where the server will require a TLS connection to work, or will only work without one 🌸. Either way, insecure mode MUST NOT be the default, even if secure mode isn't supported 😭. And insecure mode MUST always need its own explicit configuration step, separate from the one that turns on Active Leasequery support 🫶.
When the server is in insecure mode, it just waits for the requestor to send the Active Leasequery request once the TCP connection is up 🧚. If it gets a STARTTLS message, it MUST respond with a REPLY [RFC3315] message carrying a DHCPv6 status code of TLSConnectionRefused 💀.
When the server is in secure mode, DHCPv6 servers MUST support TLS [RFC5246] to protect the integrity and privacy of the data sent over the TCP connection 🔒. In secure mode, DHCPv6 servers MUST also be configurable about which requestors they'll talk to 👑. The certificate a requestor shows when starting the TLS connection is how the server tells acceptable requestors from unacceptable ones 🪪.
In secure mode, the DHCPv6 server MUST begin negotiating a TLS connection with any requestor who asks for one 🤝, and MUST close the TCP connections that aren't secured with TLS, or where the requestor's certificate is deemed unacceptable 🚫. When negotiating the TLS connection, the recommendations in [RFC7525] SHOULD be followed 📝.
A requestor asks for a TLS connection by sending a STARTTLS as the very first message over a brand-new TCP connection 🌈. If the DHCPv6 server supports TLS connections and hasn't been configured to refuse them on this link, it MUST answer that STARTTLS by sending a REPLY [RFC3315] message with no DHCPv6 status code back to the requestor ✨. That's the server's way of saying "yep, I'll do TLS over this same TCP connection" 💖.
If for some reason the DHCPv6 server can't support a TLS connection, or it's been configured not to, then it SHOULD send a REPLY message with a DHCPv6 status code of TLSConnectionRefused back to the requestor 🙈.
If the DHCPv6 server sends a REPLY message with no DHCPv6 status code option included (which means success 🎉), the requestor is supposed to start a TLS handshake [RFC5246] (see Section 8.2) 🤝. During the TLS handshake, the DHCPv6 server MUST validate the requestor's digital certificate 🔍. On top of that, the requestor's certificate is what decides whether this requestor is allowed to do an Active Leasequery 🛂. If that certificate is deemed unacceptable, the server MUST abort creating the TLS connection 🛑.
All TLS connections set up between a requestor and a DHCPv6 server for Active Leasequery purposes MUST be mutually authenticated 🫂.
If the TLS handshake doesn't succeed in creating a TLS connection, the server MUST close the TCP connection 🚪.
9.2. Rejecting Connections 🙅♀️
Servers that don't implement DHCPv6 Active or Bulk Leasequery SHOULD NOT listen for incoming TCP connections for these requests 🫠.
If a DHCPv6 server supports Bulk Leasequery but not Active Leasequery and gets an Active Leasequery request, it SHOULD send a LEASEQUERY-REPLY with a DHCPv6 status code of NotSupported 😤. It SHOULD close the TCP connection after signaling this error 👋.
9.3. Replying to an Active Leasequery 💌
The DHCPv6 Leasequery [RFC5007] specification describes how to initially build LEASEQUERY-REPLY messages 📖. Using LEASEQUERY-REPLY and LEASEQUERY-DATA messages to carry multiple bindings is described in DHCPv6 Bulk Leasequery [RFC5460] 🧩. Message transmission and framing for TCP is described in Section 6.1 🛤️.
If the connection gets blocked while the server is trying to send reply messages, the server SHOULD terminate the TCP connection after ACTIVE_LQ_SEND_TIMEOUT ⏰. This timeout is how long the DHCPv6 server is willing to wait for the requestor to read and process enough information to unblock the TCP connection 🥱. The default is two minutes 🕑, which means that if more than two minutes go by without the requestor reading enough to unblock the TCP connection, the DHCPv6 server SHOULD close the TCP connection 🔚.
If the DHCPv6 server hits an error during the initial processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY message containing some kind of error code in a DHCPv6 status code option 🚨. It SHOULD close the connection after signaling this error 🫡.
If the DHCPv6 server hits an error during later processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE containing some kind of error code in a DHCPv6 status code option 😬. It SHOULD close the connection after signaling this error 💅.
If the server finds any bindings that satisfy a query, it SHOULD send each binding's data in a reply message 📦. The first reply message is a LEASEQUERY-REPLY 🥇. The binding data is carried in an OPTION_CLIENT_DATA option, as specified in [RFC5007] 🎁. The server SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which can avoid redundant data (like the requestor's Client-ID) 🧠.
Every reply to an Active Leasequery request MUST contain the information specified in replies to a DHCPv6 Bulk Leasequery request [RFC5460] 📋. The exception is that a server implementing Active Leasequery SHOULD be able to be configured to stop specific data items from being sent to the requestor, even if those data items were asked for in the OPTION_ORO option 🙈🔒.
Some servers can be set up to respond to a DHCPv6 Leasequery [RFC5007] and a DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding that's reserved in such a way that it looks like the IPv6 binding is leased to the DHCP client it's reserved for 👀. These servers SHOULD also respond to an Active Leasequery request with the same information they'd give for a Bulk Leasequery request once they first figure out that the IPv6 binding is reserved to a DHCP client 🧃.
If an Active Leasequery or Bulk Leasequery request includes the OPTION_LQ_BASE_TIME option code in OPTION_ORO, the DHCPv6 server MUST include the OPTION_LQ_BASE_TIME option in every reply to that request ⏱️. The value for the base-time option is the current absolute time in the DHCPv6 server's context 🕰️.
If an Active Leasequery request contains an OPTION_LQ_START_TIME option, it means the requestor wants the DHCPv6 server to send it not only the messages about DHCPv6 binding activity that happens after the Active Leasequery request is received, but also the messages about DHCPv6 binding activity that happened before the Active Leasequery request 🕰️✨.
If the OPTION_LQ_END_TIME option shows up in an Active Leasequery request, the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a DHCPv6 status code of MalformedQuery and terminate the connection 🙅♀️💥.
To make a meaningful response to this query 🧐, the DHCPv6 server MAY keep track of binding activity and link changes to particular base-time values from the messages 📚. Then, when an Active Leasequery request containing an OPTION_LQ_START_TIME option asks for it, the DHCPv6 server can reply with everything about binding activity happening at that OPTION_LQ_START_TIME or later 🗂️.
These replies based on OPTION_LQ_START_TIME MAY be interleaved with the messages generated by current binding activity 🌀.
Once the DHCPv6 Leasequery messages tied to the OPTION_LQ_START_TIME option are all sent, a LEASEQUERY-DATA message MUST be sent with a DHCPv6 status code value of CatchUpComplete 🎉🏁.
The DHCPv6 server SHOULD, but doesn't have to, keep track of a limited amount of previous binding activity 🗃️. The DHCPv6 server MAY choose to only do this if it has received at least one Active Leasequery request in the past 🕵️♀️, since doing it will almost certainly use up some resources that would be wasted if there are no Active Leasequery requestors for this server 💸. The DHCPv6 server SHOULD make the amount of previous binding activity it keeps configurable ⚙️. The server isn't required to keep this info across a server restart (or even to keep it at all) 🫣.
Unless there's an error, or some reason to stop processing an Active Leasequery request and send a LEASEQUERY-DONE message (like a server shutdown) 🛑, there won't be a LEASEQUERY-DONE message at the end of Active Leasequery processing 🙃. That's because the processing doesn't really end 🔁. It keeps going until either the requestor or the server closes the connection 🫶.
9.4. Multiple or Parallel Queries 👯♀️
Every Active Leasequery request MUST be made on a single TCP connection where no other request is active at the time the request is made 🧵.
Usually, a requestor of an Active Leasequery wouldn't need to send a second Active Leasequery while the first is still active 🙅♀️. However, sending an Active Leasequery and a Bulk Leasequery in parallel would be possible and reasonable 💜. For parallel Active and Bulk Leasequeries, the requestor MUST use different TCP connections 🛣️🛣️.
This MAY be a feature that the admin controls 🎛️. Servers that can process queries in parallel SHOULD offer configuration that limits how many simultaneous queries are allowed from any one requestor 🚦, so resource use stays under control if there are multiple requestors asking for service 🍓.
9.5. Closing Connections 👋
The server MUST close its end of the TCP connection if it runs into an error sending data on the connection 💥. The server MUST close its end of the TCP connection if it finds that it has to abort an in-process request 🛑. A server aborting an in-process request SHOULD try to tell its requestors about it by using the QueryTerminated status code in the DHCPv6 status code option in a LEASEQUERY-DONE message 📣. If the server detects that the requestor's end has been closed, the server MUST close its end of the connection 🫗.
The server SHOULD limit the number of connections it maintains, and SHOULD close idle connections to enforce that limit 🧹✨.
10. Security Considerations 🔐✨
Okay bestie, this is the dramatic part 💀. The Security Considerations section of [RFC3315] covers the general threats to DHCPv6, so go read that one too 📖. The DHCPv6 Leasequery spec [RFC5007] gives recommendations for the Leasequery protocol, especially for relayed Leasequery messages, packet-flooding denial-of-service (DoS) attacks, keeping things restricted to trusted requestors, and using IPsec [RFC4301] 🛡️.
Using TCP adds some extra drama 😭. Attacks that try to drain the DHCPv6 server's TCP connection resources can stop legit requestors from getting service. Malicious requestors can also be sneaky: they open connections and then send invalid queries, partial queries, or no queries at all, which can eat up the server's whole pool of available connections 🫠.
When the server runs in secure mode, TLS [RFC5246] is what keeps the connection secure 🔒. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection, so don't skip them 💅.
Servers SHOULD offer configuration parameters that limit where incoming connections can come from, by checking and using the digital certificates presented to set up a TLS connection 🪪. They SHOULD also cap how many connections they accept, and cap how long an idle connection is allowed to stay open ⏳.
Data you get from an Active Leasequery is open to the same potential abuse as the data on the DHCPv6 server it came from 👀. So it SHOULD be secured with mechanisms as strong as the ones protecting that server's data 🔑. Once you've used it for its purpose, it SHOULD be deleted as soon as possible 🗑️✨.
🚫 Heads up: authentication for DHCP messages [RFC3315] MUST NOT be used to try to secure transmission of the messages described in this document. Don't do it, periodt 💀.
11. IANA Considerations 🧚
IANA has assigned new DHCPv6 option codes in the "Option Codes" registry, which lives at <http://www.iana.org/assignments/dhcpv6-parameters>:
OPTION_LQ_BASE_TIME (100)OPTION_LQ_START_TIME (101)OPTION_LQ_END_TIME (102)
IANA has also added new values to the DHCPv6 "Status Codes" registry, at the same <http://www.iana.org/assignments/dhcpv6-parameters> address 🌸:
DataMissing (12)CatchUpComplete (13)NotSupported (14)TLSConnectionRefused (15)
And finally, IANA assigned values for two new DHCPv6 message types in the "Message Types" registry, same link 🦋:
ACTIVELEASEQUERY (22)STARTTLS (23)
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009,
<http://www.rfc-editor.org/info/rfc5460>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.12.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>.Acknowledgments 🫶
Some of the concepts and content in this document are based on DHCPv4 Active Leasequery, which was originally proposed by Kim Kinnear, Bernie Volz, Mark Stapp, and Neil Russell 💜.
Useful review comments came from Scott Bradner, Francis Dupont, and Stephen Farrell 🙌. The privacy protections got a serious upgrade because of these comments and discussions, so huge thanks to them ✨.
Authors' Addresses 🌈
Dushyant Raghuvanshi
Cisco Systems, Inc.
Cessna Business Park
Varthur Hobli, Outer Ring Road
Bangalore, Karnataka 560037
India
Phone: +91 80 4426-7372
Email: draghuva@cisco.com
Kim Kinnear
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, Massachusetts 01719
United States
Phone: +1 978 936-0000
Email: kkinnear@cisco.com
Deepak Kukrety
Cisco Systems, Inc.
Cessna Business Park
Varthur Hobli, Outer Ring Road
Bangalore, Karnataka 560037
India
Phone: +91 80 4426-7346
Email: dkukrety@cisco.comThat's the whole thing, bestie! 🎀💖 You made it through the entire RFC 🌸👑
📦 where this page comes from
- ietf: rfc7653 2015-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms