RFC 9915
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 9915 ๐ Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
okay bestie, this is RFC 9915, the big DHCPv6 spec ๐ It was written by T. Mrugalski (ISC), B. Volz (an individual contributor), M. Richardson (SSW), S. Jiang (BUPT), and T. Winters (QA Cafe). It's a Standards Track document, which is the IETF's "this is the real deal" category ๐ฅ It's published as STD 102 with ISSN 2070-1721, dated January 2026. It's also a full replacement for RFC 8415, so it obsoletes that one ๐ It doesn't list any documents it updates.
Abstract โจ
so DHCPv6 is an extensible way to hand nodes their network settings, IP addresses, and prefixes ๐ง The settings can come statelessly, or stateful assignment can come along for the ride with one or more IPv6 addresses and/or IPv6 prefixes. It can run instead of stateless address autoconfiguration (SLAAC), or alongside it ๐
this doc also obsoletes RFC 8415 and bakes in the verified errata ๐ธ It officially drops two things: the temporary address assignment (the IA_TA option), and the server unicast capability (the Server Unicast option and the UseMulticast status code). bye bye ๐
Status of This Memo
this is an Internet Standards Track document โจ
it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community ๐ซถ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 ๐
for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9915 ๐ฆ
Copyright Notice
ยฉ 2026 the IETF Trust and the people listed as document authors. all rights reserved ๐
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stand on the date of publication. please actually read those, bestie, because they spell out your rights and restrictions ๐ Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes.
this doc may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC, or translating it into languages other than English ๐
Table of Contents
1. Introduction
1.1. Relationship to Previous DHCPv6 Standards
1.2. Topics Out of Scope
2. Requirements
3. Background
4. Terminology
4.1. IPv6 Terminology
4.2. DHCP Terminology
5. Client/Server Exchanges
5.1. Client/Server Exchanges Involving Two Messages
5.2. Client/Server Exchanges Involving Four Messages
5.3. Server/Client Exchanges
6. Operational Models
6.1. Stateless DHCP
6.2. DHCP for Non-Temporary Address Assignment
6.3. DHCP for Prefix Delegation
6.4. DHCP for Customer Edge Routers
6.5. Multiple Addresses and Prefixes
6.6. Registering Self-Generated Addresses
7. DHCP Constants
7.1. Multicast Addresses
7.2. UDP Ports
7.3. DHCP Message Types
7.4. DHCP Option Codes
7.5. Status Codes
7.6. Transmission and Retransmission Parameters
7.7. Representation of Time Values and "Infinity" as a Time
Value
8. Client/Server Message Formats
9. Relay Agent/Server Message Formats
9.1. Relay-forward Message
9.2. Relay-reply Message
10. Representation and Use of Domain Names
11. DHCP Unique Identifier (DUID)
11.1. DUID Contents
11.2. DUID Based on Link-Layer Address Plus Time (DUID-LLT)
11.3. DUID Assigned by Vendor Based on Enterprise Number
(DUID-EN)
11.4. DUID Based on Link-Layer Address (DUID-LL)
11.5. DUID Based on Universally Unique Identifier (DUID-UUID)
12. Identity Association
12.1. Identity Associations for Address Assignment
12.2. Identity Associations for Prefix Delegation
13. Assignment to an IA
13.1. Selecting Addresses for Assignment to an IA_NA
13.2. Assignment of Prefixes for IA_PD
14. Transmission of Messages by a Client
14.1. Rate Limiting
14.2. Client Behavior when T1 and/or T2 Are 0
15. Reliability of Client-Initiated Message Exchanges
16. Message Validation
16.1. Use of Transaction IDs
16.2. Solicit Message
16.3. Advertise Message
16.4. Request Message
16.5. Confirm Message
16.6. Renew Message
16.7. Rebind Message
16.8. Decline Message
16.9. Release Message
16.10. Reply Message
16.11. Reconfigure Message
16.12. Information-request Message
16.13. Relay-forward Message
16.14. Relay-reply Message
17. Client Source Address and Interface Selection
17.1. Source Address and Interface Selection for Address
Assignment
17.2. Source Address and Interface Selection for Prefix
Delegation
18. DHCP Configuration Exchanges
18.1. A Single Exchange for Multiple IA Options
18.2. Client Behavior
18.2.1. Creation and Transmission of Solicit Messages
18.2.2. Creation and Transmission of Request Messages
18.2.3. Creation and Transmission of Confirm Messages
18.2.4. Creation and Transmission of Renew Messages
18.2.5. Creation and Transmission of Rebind Messages
18.2.6. Creation and Transmission of Information-request
Messages
18.2.7. Creation and Transmission of Release Messages
18.2.8. Creation and Transmission of Decline Messages
18.2.9. Receipt of Advertise Messages
18.2.10. Receipt of Reply Messages
18.2.10.1. Reply for Solicit (with Rapid Commit), Request,
Renew, or Rebind
18.2.10.2. Reply for Release and Decline
18.2.10.3. Reply for Confirm
18.2.10.4. Reply for Information-request
18.2.10.5. Revoking Previously Provided Options
18.2.11. Receipt of Reconfigure Messages
18.2.12. Refreshing Configuration Information
18.2.13. Restarting Server Discovery Process
18.3. Server Behavior
18.3.1. Receipt of Solicit Messages
18.3.2. Receipt of Request Messages
18.3.3. Receipt of Confirm Messages
18.3.4. Receipt of Renew Messages
18.3.5. Receipt of Rebind Messages
18.3.6. Receipt of Information-request Messages
18.3.7. Receipt of Release Messages
18.3.8. Receipt of Decline Messages
18.3.9. Creation of Advertise Messages
18.3.10. Transmission of Advertise and Reply Messages
18.3.11. Creation and Transmission of Reconfigure Messages
19. Relay Agent Behavior
19.1. Relaying a Client Message or a Relay-forward Message
19.1.1. Relaying a Message from a Client
19.1.2. Relaying a Message from a Relay Agent
19.1.3. Relay Agent Behavior with Prefix Delegation
19.2. Relaying a Relay-reply Message
19.3. Construction of Relay-reply Messages
19.4. Interaction Between Relay Agents and Servers
20. Authentication of DHCP Messages
20.1. Security of Messages Sent Between Servers and Relay Agents
20.2. Summary of DHCP Authentication
20.3. Replay Detection
20.4. Reconfiguration Key Authentication Protocol (RKAP)
20.4.1. Use of the Authentication Option in RKAP
20.4.2. Server Considerations for RKAP
20.4.3. Client Considerations for RKAP
21. DHCP Options
21.1. Format of DHCP Options
21.2. Client Identifier Option
21.3. Server Identifier Option
21.4. Identity Association for Non-Temporary Addresses Option
21.5. Identity Association for Temporary Addresses Option
21.6. IA Address Option
21.7. Option Request Option
21.8. Preference Option
21.9. Elapsed Time Option
21.10. Relay Message Option
21.11. Authentication Option
21.12. Server Unicast Option
21.13. Status Code Option
21.14. Rapid Commit Option
21.15. User Class Option
21.16. Vendor Class Option
21.17. Vendor-Specific Information Option
21.18. Interface-Id Option
21.19. Reconfigure Message Option
21.20. Reconfigure Accept Option
21.21. Identity Association for Prefix Delegation Option
21.22. IA Prefix Option
21.23. Information Refresh Time Option
21.24. SOL_MAX_RT Option
21.25. INF_MAX_RT Option
22. Security Considerations
22.1. Client Security Considerations
22.2. Server Security Considerations
22.3. Reconfigure Security Considerations
22.4. Mitigation Considerations
23. Privacy Considerations
24. IANA Considerations
25. References
25.1. Normative References
25.2. Informative References
Appendix A. Summary of Changes from RFC 8415
Appendix B. Appearance of Options in Message Types
Appendix C. Appearance of Options in the "options" Field of DHCP
Options
Acknowledgments
Authors' Addresses1. Introduction ๐ฆ
this doc specifies DHCP for IPv6 (DHCPv6), a client/server protocol for managed configuration of devices ๐ The basic operation gives configuration to clients on the same link as the server. Relay agent functionality is defined too, so clients and servers that are not on the same link can still talk to each other ๐ธ
DHCPv6 can hand a device addresses from a DHCPv6 server, plus other configuration info. That info rides along in options, and DHCPv6 can be extended by defining new options for stuff this doc doesn't cover ๐ง
DHCPv6 also has a mechanism for automated delegation of IPv6 prefixes, where a server can delegate prefixes to clients โจ Using it is specified as part of [RFC7084] and by [TR-187]. Those docs say "requesting router" and "delegating router" where this doc says "client" and "server", respectively, so don't get confused, bestie ๐
DHCP can also be used just to hand out other configuration options, with no addresses or prefixes at all ๐ Since the server doesn't have to track any state, this mode is called "stateless DHCPv6". Stateless DHCPv6 needs way simpler mechanisms than stateful DHCPv6, and honestly that's giving clean and low-key iconic ๐
1.1. Relationship to Previous DHCPv6 Standards ๐
okay so [RFC8415] gave DHCPv6 a whole glow-up ๐ It unified and cleaned up the entire spec, and it covered all the applicable errata filed against older RFCs when it was written. It also obsoleted a small number of mechanisms: delayed authentication, lifetime, and timer hints sent by a client. bye bye ๐
This document obsoletes [RFC8415]. It applies verified errata reports and obsoletes two features that never really caught on ๐ฌ The first is assigning temporary addresses using the IA_TA option. The second is letting clients unicast some messages straight to the server when the server sent the Server Unicast option to a client in an early exchange. It also clarifies the UDP ports used by clients, servers, and relay agents (Section 7.2). See Appendix A for a list of differences from [RFC8415]. ๐ฆ
1.2. Topics Out of Scope ๐ง
This document is all about DHCPv6 behavior ๐ง Server policy is not part of the deal, so things like which options to hand to which clients, which subnets or pools of resources to use, which clients' requests should be denied, etc. are out of scope here.
Server configuration, operation, and management are also out of scope ๐ โโ๏ธ If you want an approach for managing DHCPv6 relays and servers, that's specified in [RFC9243].
Merging DHCPv4 [RFC2131] and DHCPv6 configuration is also out of scope for this document. [RFC4477] talks about some of the issues and possible strategies for running DHCPv4 and DHCPv6 services together. It's a bit dated, but it gives a really good overview of the issues at hand ๐ The IETF consensus at the time of writing is that DHCPv4 should be used rather than DHCPv6 when conveying IPv4 configuration information to nodes. For IPv6-only networks, [RFC7341] describes a transport mechanism that carries DHCPv4 messages using DHCPv6 for the dynamic provisioning of IPv4 address and configuration information. โจ
2. Requirements ๐
Okay, the BCP 14 key words are the fine print that tells you how strict a rule is ๐ Here's how they work in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This document also uses internal conceptual variables to describe protocol behavior ๐งช It also has external variables that an implementation has to let system administrators change. The specific variable names, how their values change, and how their settings influence protocol behavior are given to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, as long as its external behavior is consistent with what this document describes. ๐
3. Background ๐ฟ
In [RFC8415], the "Background" section held background on IPv6 specifications relevant to DHCPv6. That text has been removed from this document, but this section has been kept so the major section numbering stays consistent with [RFC8415] ๐ข If you're curious, go read [RFC8415] itself for more on the topic.
4. Terminology ๐งฉ
This section defines the IPv6 and DHCP terminology used in this document. Let's go! ๐
4.1. IPv6 Terminology ๐
IPv6 terminology from [RFC8200], [RFC4291], and [RFC4862] that's relevant to this specification is included below ๐ฆ
- address: An IP-layer identifier for an interface or a set of interfaces.
- GUA: Global unicast address (see [RFC4291]).
- host: Any node that is not a router.
- IP: Internet Protocol Version 6 (IPv6). The terms "IPv4" and "IPv6" are only used where it's necessary to avoid ambiguity ๐
- interface: A node's attachment to a link.
- link: A communication facility or medium over which nodes can communicate at the link layer, which is the layer right below IP. Examples are Ethernet (simple or bridged), Point-to-Point Protocol (PPP) and PPP over Ethernet (PPPoE) links, and Internet-layer (or higher) "tunnels", like tunnels over IPv4 or IPv6 itself ๐
- link-layer identifier: A link-layer identifier for an interface, like IEEE 802 addresses for Ethernet or Token Ring network interfaces.
- link-local address: An IPv6 address with link-only scope, indicated by the prefix
fe80::/10. It can be used to reach neighboring nodes attached to the same link. Every IPv6 interface on which DHCPv6 can reasonably be useful has a link-local address ๐ซถ - multicast address: An identifier for a set of interfaces, typically belonging to different nodes. A packet sent to a multicast address is delivered to all interfaces identified by that address ๐ฃ
- neighbor: A node attached to the same link ๐ฏ
- node: A device that implements IP.
- packet: An IP header plus payload ๐ฆ
- prefix: The initial bits of an address, or a set of IP addresses that share the same initial bits.
- prefix length: The number of bits in a prefix.
- router: A node that forwards IP packets not explicitly addressed to itself ๐ฆ
- ULA: Unique local address (see [RFC4193]).
- unicast address: An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address ๐ฏ
4.2. DHCP Terminology ๐
okay so this is the DHCP glossary, bestie ๐โจ these are the words the whole spec leans on, so let's get them right ๐ซถ
appropriate to the link ๐ฆ
An address is "appropriate to the link" when it fits with what the DHCP server knows about the network topology, prefix assignment, and address assignment policies. That's the whole vibe ๐
binding ๐
A binding (also called a client binding) is a bundle of server data records holding everything the server knows about the addresses or delegated prefixes in an Identity Association (IA), or about configuration information explicitly assigned to the client. Config that goes out to a bunch of clients through a policy, like the stuff every client on the same link gets, does not need a binding, so no cap it's lighter than you'd think ๐ธ A binding for an IA is indexed by the tuple <DUID, IA-type, IAID>, where IA-type is the type of lease in the IA (for example, address or delegated prefix). A binding for configuration info about a client is indexed by <DUID>. DUID, IA, and IAID get their own definitions below, so keep scrolling ๐
configuration parameter โจ
A configuration parameter is an element of the configuration information set on the server and delivered to the client using DHCP. These parameters can carry info the node uses to set up its network subsystem and get talking on a link or internetwork, for example ๐ง
container option ๐
A container option is an option that wraps other options. For example, the IA_NA option (see Section 21.4) may contain IA Address options (see Section 21.6). it's giving Russian nesting doll energy ๐ช๐
DHCP ๐
DHCP stands for Dynamic Host Configuration Protocol for IPv6. The terms "DHCPv4" and "DHCPv6" are only used where it's needed to avoid confusion ๐
DHCP client ๐
Also called "client". A node that starts requests on a link to get configuration parameters from one or more DHCP servers. main character behavior, honestly ๐
DHCP domain ๐ธ
A set of links managed by DHCP and run by a single administrative entity. one boss, many links, very organized ๐
DHCP relay agent ๐ฆ
Also called "relay agent". A node that acts as a middle-person to deliver DHCP messages between clients and servers. In some setups there can be more than one relay agent between a client and a server, so a relay agent may send DHCP messages to another relay agent. yes it's relay-ception ๐๐ญ
DHCP server ๐
This document shortens this term to "server". A node that responds to requests from clients. It may or may not be on the same link as the client(s). no pressure on where it lives ๐ซถ
DUID โจ
A DHCP Unique Identifier for a DHCP participant. Each DHCP client and server has exactly one DUID. For the ways a DUID can be built, see Section 11. it's the ID card, periodt ๐ชช๐
encapsulated option ๐
A DHCP option that is usually only found inside another option. For example, the IA Address option is contained in IA_NA options (see Section 21.6 and Section 21.4, respectively). For a more complete definition, see Section 9 of [RFC7227]. nested but make it cute ๐ช๐ธ
IA ๐
Identity Association: a collection of leases assigned to a client. Each IA has an associated IAID (see below). A client may have more than one IA assigned to it, for example one for each of its interfaces. Each IA holds one type of lease. For example, an identity association for non-temporary addresses (IA_NA) holds addresses, and an identity association for prefix delegation (IA_PD) holds delegated prefixes. Throughout this document, "IA" is used to mean an identity association without naming the type of lease inside it. This document defines three IA types: IA_NA, IA_TA (obsoleted), and IA_PD. Another IA type (IA_LL) was defined in [RFC8947] and more may be defined. so many types, so little time ๐ฅน
IA option(s) ๐
In this document, one or more IA_NA, IA_TA (obsoleted), and/or IA_PD options. Another IA type (IA_LL) was defined in [RFC8947] and more may be defined. the whole squad of IA options ๐ซถ
IAID ๐
Identity Association Identifier: an identifier for an IA, chosen by the client. Each IA has an IAID, and it's picked to be unique among the IAIDs for IAs of a specific type that belong to that client. unique within your own type, no copying allowed โจ
IA_NA ๐
Identity Association for Non-temporary Addresses: an IA that carries assigned addresses. See Section 21.4 for details on the IA_NA option. the address-holding IA, obviously ๐
IA_PD ๐ง
Identity Association for Prefix Delegation: an IA that carries delegated prefixes. See Section 21.21 for details on the IA_PD option. the prefix-passing IA ๐ฆ
IA_TA ๐ฅ
Identity Association for Temporary Addresses: an IA that carries temporary addresses (see [RFC8981]). This option is obsoleted by this document. See [RFC8415] for details. ngl this one's retired now ๐ซ
lease ๐
A contract where the server grants the client the use of an address or delegated prefix for a specified period of time. it's a timed loan with a receipt ๐งพ
message ๐ธ
A unit of data carried as the payload of a UDP datagram, exchanged among DHCP servers, relay agents, and clients. the little envelopes of the whole protocol ๐
Reconfigure key โญ
A key supplied to a client by a server. It's used to provide security for Reconfigure messages (see Section 20.4 for use cases for the Reconfigure key). the secret handshake ๐คซ๐
relaying ๐ฆ
A DHCP relay agent relays DHCP messages between DHCP participants. the whole job in one line ๐
retransmission ๐
Another attempt to send the same DHCP message by a client or server, because no valid response came back to the previously sent messages. The retransmitted message is typically modified before sending, as the DHCP specifications require. In particular, the client updates the value of the Elapsed Time option in the retransmitted message. the "hello? are you there?" resend, with a fresh timer ๐ฐ๏ธ๐
RKAP ๐
The Reconfiguration Key Authentication Protocol (see Section 20.4). acronym of the moment ๐ฃ
singleton option โจ
An option that is only allowed to appear once, either as a top-level option or at any encapsulation level. Most options are singletons. one and done, bestie 1๏ธโฃ
T1 ๐
The time interval after which the client is expected to contact the server that did the assignment, to extend (renew) the lifetimes of the addresses assigned (via IA_NA option(s)) and/or prefixes delegated (via IA_PD option(s)) to the client. T1 is expressed as an absolute value in messages (in seconds), is carried within IA containers (currently the IA_NA and IA_PD options), and is interpreted as a time interval since the message was received. The value stored in the T1 field in IA options is called the T1 value. The actual time when the timer expires is called the T1 time. the "time to check in with the original server" timer โฐ๐ซถ
T2 ๐
The time interval after which the client is expected to contact any available server, to extend (rebind) the lifetimes of the addresses assigned (via IA_NA option(s)) and/or prefixes delegated (via IA_PD option(s)) to the client. T2 is expressed as an absolute value in messages (in seconds), is carried within IA containers (currently the IA_NA and IA_PD options), and is interpreted as a time interval since the message was received. The value stored in the T2 field in IA options is called the T2 value. The actual time when the timer expires is called the T2 time. the "okay anyone at all, please help" timer ๐๐
top-level option ๐
An option conveyed in a DHCP message directly, meaning it isn't encapsulated in any other option, as described in Section 9 of [RFC7227]. the outermost layer, no wrapping ๐
transaction ID ๐
An opaque value used to match responses with replies initiated by either a client or a server. it's the matching-socks code of DHCP ๐งฆโจ
5. Client/Server Exchanges ๐ฆ
Clients and servers exchange DHCP messages using UDP (see [RFC0768] and [BCP145]). The client uses a link-local source address, or addresses determined through other mechanisms, for transmitting and receiving DHCP messages. we're starting the actual conversations now, bestie ๐๐
A DHCP client sends all messages to a reserved, link-scoped multicast destination address (All_DHCP_Relay_Agents_and_Servers - ff02::1:2), so the client doesn't need to be configured with the address or addresses of DHCP servers. no hardcoding servers, just shout into the group chat ๐ฃ๐ธ
To let a DHCP client send a message to a DHCP server that isn't attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. The relay agent works transparently to the client. The rest of the message exchanges in this section will skip the relay agent's relaying of messages. the relay is the unseen hype person ๐ง๐
5.1. Client/Server Exchanges Involving Two Messages ๐ธ
When a DHCP client doesn't need a DHCP server to assign IP addresses or delegated prefixes to it, the client can get other configuration information, like a list of available DNS servers [RFC3646] or NTP servers [RFC5908], through a single message and reply exchange with a DHCP server. To get other configuration information, the client first sends an Information-request message to the All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond with a Reply message containing the other configuration information for the client. quick, efficient, no drama ๐ฌโจ
A client may also ask the server to expedite address assignment and/or prefix delegation by using a two-message exchange instead of the normal four-message exchange discussed in the next section. The client can request expedited assignment, and servers may or may not honor the request (see Sections 18.3.1 and 21.14 for more details and why servers may not honor this request). Clients may request this expedited service in environments where it's likely that only one server is available on a link and no one expects a second server to show up, or when finishing the configuration as quickly as possible is the priority. speed run mode activated ๐๏ธ๐จ
To request the expedited two-message exchange, the client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast address, requesting the assignment of addresses and/or delegated prefixes and other configuration information. This message includes an indication (the Rapid Commit option; see Section 21.14) that the client is willing to accept an immediate Reply message from the server. A server that is willing to commit the assignment of addresses and/or delegated prefixes to the client right away responds with a Reply message. The configuration information and the addresses and/or delegated prefixes in the Reply message are then immediately available for the client to use. no waiting around, it's all ready ๐๐
Each address or delegated prefix assigned to the client has associated preferred and valid lifetimes specified by the server. To ask for an extension of the lifetimes assigned to an address or delegated prefix, the client sends a Renew message to the server. The server sends a Reply message to the client with the new lifetimes, so the client can keep using the address or delegated prefix without interruption. If the server can't extend the lifetime of an address or delegated prefix, it says so by returning that address or delegated prefix with lifetimes of 0. At the same time, the server may assign other addresses or delegated prefixes. lifetimes getting renewed like a good subscription ๐๐
See Section 18 for descriptions of additional two-message exchanges between the client and server. ๐ฆ๐
5.2. Client/Server Exchanges Involving Four Messages โจ
Okay so, if a client wants addresses and/or delegated prefixes, it first has to find a DHCP server ๐ and then ask that server for the addresses and/or delegated prefixes and other configuration info. The client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast address to find available DHCP servers. Any server that can meet the client's requirements responds with an Advertise message. Then the client picks one of the servers and sends a Request message, asking for the lease of addresses and/or delegated prefixes and other configuration information. The server responds with a Reply message that contains the leased addresses, delegated prefixes, and configuration. Bestie, that's the whole four-step glow-up ๐
As we covered in the previous section, the client can also ask for an extension of the lifetimes on its addresses or delegated prefixes. That's a two-message exchange, so it's a lot quicker ๐ฆ
5.3. Server/Client Exchanges ๐ธ
A server that has already talked to a client, and has negotiated for the client to listen for Reconfigure messages, may send the client a Reconfigure message. This tells the client to update its configuration by sending an Information-request, Renew, or Rebind message. Reconfigure messages are authenticated as per Section 20.4. After that, the client does the two-message exchange we went over earlier. This is super useful for speeding up configuration changes on a client, like when a network needs to be renumbered (see [RFC6879] and [RFC9096]) ๐ง
6. Operational Models ๐
This section walks through some of the most common DHCP operational models right now. The models described here aren't mutually exclusive, and they're sometimes used together. For example, a device may start in stateful mode to get an address and then, later on when an application starts, ask for additional parameters using stateless mode. Mix and match, it's giving flexible ๐
This document assumes that the DHCP servers and the client, communicating with the servers via a specific interface, belong to a single provisioning domain ๐ซถ
DHCP may be extended to support additional stateful services that may interact with one or more of the models described below. Any interaction like that should be considered and documented as part of any future protocol extension. Future-me is already thinking about this ๐ฎ
6.1. Stateless DHCP ๐
Stateless DHCP can be used at any time. It's typically used when a node is missing some configuration info, or its info has expired, and that info is available via DHCP.
This is the simplest, most basic DHCP operation. A client (and a server) only has to support two messages: Information-request and Reply. Honestly the easiest vibe ever ๐ Note that DHCP servers and relay agents typically also need to support the Relay-forward and Relay-reply messages, so things still work when clients and servers aren't on the same link.
6.2. DHCP for Non-Temporary Address Assignment ๐
This model is the original reason DHCP exists, no cap ๐ญ It's the right move when stateless address autoconfiguration alone is insufficient or impractical. That could be because of network policy, extra needs like dynamic updates to the DNS, or client-specific requirements.
Here's how non-temporary address assignment works:
- The server is given prefixes it can assign addresses from, plus any related network topology info about which prefixes are present on which links.
- A client asks the server to assign it a non-temporary address. The server allocates an address or addresses that fit the link the client is connected to.
- The server sends the allocated address or addresses back to the client.
Every address has associated preferred and valid lifetimes (see Section 12.1). Together they form an agreement about how long the client is allowed to use the address. A client can ask for an extension of the lifetimes on an address, and it is required to stop using an address once the address's valid lifetime expires. Important stuff, babe โฐ
Usually, clients also request other configuration parameters, like DNS name server addresses and domain search lists, at the same time they ask for addresses ๐ฎ
Clients can also request more than one address or set of addresses (see Sections 6.5 and 12) โจ
6.3. DHCP for Prefix Delegation ๐
Prefix delegation is another stateful mode. It was originally meant for simple delegation of prefixes from a DHCP server to DHCP clients, which are typically routers. It's a good fit when the client (1) doesn't know the topology of the networks it's attached to and (2) doesn't need other info to pick a prefix for delegation. This mechanism is used by an ISP to delegate a prefix to a subscriber, and that delegated prefix could get subnetted and assigned to links inside the subscriber's network. [RFC7084] and [RFC7368] describe this kind of use in detail ๐
The design of this prefix delegation mechanism meets the requirements for prefix delegation in [RFC3769].
DHCP prefix delegation itself does not require the client to forward IP packets that aren't addressed to itself. So it also doesn't require the client (or the server) to be a router as defined in [RFC8200]. Also, in lots of cases (like tethering or hosting virtual machines), hosts are already forwarding IP packets, which means they're operating as routers as defined in [RFC8200] ๐ป
The model of operation for prefix delegation goes like this:
- The server is provisioned with prefixes to delegate to clients.
- A client requests prefix(es) from the server, as described in Section 18.
- The server chooses prefix(es) for delegation and responds to the client with them.
- After that, the client is responsible for the delegated prefix(es). For example, the client might assign a subnet from a delegated prefix to one of its interfaces and start sending Router Advertisements for that prefix on that link ๐ก
Each prefix has an associated preferred lifetime and valid lifetime (see Section 12.2). Together they form an agreement about how long the client is allowed to use the prefix. A client can ask for an extension of the lifetimes on a delegated prefix, and it is required to stop using a delegated prefix once the prefix's valid lifetime expires.
Figure 1 shows a network architecture where prefix delegation could be used ๐บ๏ธ
______________________ \
/ \ \
| ISP core network | \
\__________ ___________/ |
| |
+-------+-------+ |
| Aggregation | | ISP
| device | | network
+-------+-------+ |
| /
|Network link to /
|subscriber premises /
|
+------+--------+ \
| CPE | \
| (DHCP client) | \
+----+---+------+ |
| | | Subscriber
---+-------------+-----+ +-----+------ | network
| | | |
+----+-----+ +-----+----+ +----+-----+ |
|Subscriber| |Subscriber| |Subscriber| /
| PC | | PC | | PC | /
+----------+ +----------+ +----------+ /Figure 1: Prefix Delegation Network
In this example, the server (sitting in the ISP core network or built into the aggregation device) is configured with a set of prefixes. Those prefixes get assigned to customers the first time each customer connects to the ISP service. The prefix delegation process starts when the client (or Customer Premises Equipment (CPE)) asks for configuration info through DHCP. The DHCP messages from the client reach the server through the aggregation device. When the server gets the request, it picks an available prefix or prefixes to delegate to the client, then sends them back ๐ง
The client subnets the delegated prefix and assigns the longer prefixes to links in the subscriber's network. In a typical scenario based on the network in Figure 1, the client subnets one delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each link in the subscriber network ๐งฉ
The prefix delegation options can be used together with other DHCP options that carry other configuration info to the client. The client may, in turn, provide DHCP service to nodes attached to the internal network. For example, the client may get the addresses of DNS and NTP servers from the ISP server, then pass that config along to the subscriber hosts through a DHCP server running in the client ๐ซง
If the client uses a delegated prefix to configure addresses on its own interfaces or on other nodes behind it, the preferred and valid lifetimes of those addresses MUST be no longer than the remaining preferred and valid lifetimes, respectively, for the delegated prefix at any time. Especially, if the delegated prefix or a prefix derived from it is advertised for stateless address autoconfiguration [RFC4862], the advertised preferred and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix. Don't let your kids outlive their parent ๐
A client that has delegated any of the address space it got through DHCP Prefix Delegation MUST NOT issue a DHCP Release on the relevant delegated prefix while any of that address space is still outstanding. That includes addresses leased out by DHCPv6 (IA_NA), prefixes delegated via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router Advertisements. Requirement WPD-9 in [RFC9096] makes this the best current practice ๐
[RFC9096], Section 3.3 has more guidance on coordinating lifetimes between the WAN side (DHCPv6-PD client) and the LAN side (DHCPv6-PD server) ๐ค
Several problems related to Prefix Delegation and Relay Agents, plus a set of requirements to address them, are defined in [RFC8987]. Lowkey a whole rabbit hole, iykyk ๐
6.4. DHCP for Customer Edge Routers ๐ฆ
The DHCP requirements and network architecture for Customer Edge Routers are described in [RFC7084], with improvements for renumbering described in [RFC9096]. This model of operation combines address assignment (see Section 6.2) with prefix delegation (see Section 6.3). In general, this model assumes that a single set of transactions between the client and server will assign or extend the client's non-temporary addresses and delegated prefixes. One and done, it's so efficient ๐
6.5. Multiple Addresses and Prefixes ๐
okay so DHCP lets a client get multiple addresses ๐ซถ usually a client sends one IA_NA option and the server hands out at most one address from each prefix assigned to the link the client is attached to. the server can also be set up to serve addresses from multiple prefixes on the same link, which is useful when a network renumbering event is happening ๐ฆ in a typical deployment, the server will grant one address for each IA_NA option (see Section 21.4) โจ
to meet the recommendations of [RFC7934], a client can explicitly ask for multiple addresses by sending multiple IA_NA options ๐
it can put them in its initial transmissions, or it can send an extra Request message with new IA_NA options (or include them in a Renew message) ๐ธ
the same idea works for prefix delegation ๐ in principle, DHCP lets a client ask for new prefixes to be delegated by sending additional IA_PD options (see Section 21.21). but a typical operator usually prefers to delegate one bigger prefix, so in most deployments it is recommended that the client request the larger prefix in its initial transmissions instead of asking for more later ๐
whether the server actually grants extra addresses and prefixes is up to the server policy, and that's out of scope for this document ๐
for more on how the server tells apart different IA option instances, see Section 12 ๐ง
6.6. Registering Self-Generated Addresses ๐
[RFC9686] adds a way for devices to register their self-generated or statically configured addresses with DHCPv6 servers ๐ the vibe is that devices tell the server which addresses they're using, so the server can log or record them as local policy requires โจ
the big difference here is that the device picks the address itself, not the DHCP server ๐ฆ the rest of the lifecycle is basically the same: the server creates a lease, the device does periodic actions to get the lease renewed, and eventually the lease can expire. this mechanism just uses different message types (ADDR-REG-INFORM and ADDR-REG-REPLY) and has different source address requirements, as defined in [RFC9686] ๐
7. DHCP Constants ๐
this section covers the program and networking constants that DHCP uses ๐ธ
7.1. Multicast Addresses ๐
these are the multicast addresses DHCPv6 uses ๐ซถ
All_DHCP_Relay_Agents_and_Servers (ff02::1:2): a link-scoped multicast address that a client uses to talk to neighboring (aka on-link) relay agents and servers. every server and relay agent is a member of this group ๐ฆAll_DHCP_Servers (ff05::1:3): a site-scoped multicast address that a relay agent uses to talk to servers, either because it wants to message all the servers or because it doesn't know their unicast addresses ๐ง heads up: for a relay agent to use this address, it must have an address with enough scope to be reachable by the servers. all servers within the site are members of this group on the interfaces inside the site ๐
7.2. UDP Ports ๐
okay this part is important so listen up ๐
Clients MUST listen for DHCP messages on UDP port 546. Servers and relay agents MUST listen for DHCP messages on UDP port 547.
so clients MUST send DHCP messages to UDP destination port 547. Servers MUST send Relay-reply messages to UDP destination port 547 and client messages to UDP destination port 546. Relay agents MUST send Relay-forward and Relay-reply messages to UDP destination port 547 and client messages to UDP destination port 546. ๐
it is RECOMMENDED for clients to send from UDP source port 546, and for servers and relay agents to send from UDP source port 547. but clients, servers, and relay agents MAY send DHCP messages from any UDP source port they're allowed to use โจ
pls note that the Relay Source Port Option [RFC8357] changes some of these rules for servers and relay agents ๐
7.3. DHCP Message Types ๐
DHCP defines the following message types ๐ their formats are in Sections 8 and 9. more message types have been defined and may be defined later; check <https://www.iana.org/assignments/dhcpv6-parameters> for the latest. the numeric encoding for each type is in parentheses ๐ข
SOLICIT (1): a client sends a Solicit message to locate servers ๐ADVERTISE (2): a server sends an Advertise message to say it's available for DHCP service, in response to a Solicit message from a client ๐ฃREQUEST (3): a client sends a Request message to ask a specific server for configuration parameters, including addresses and/or delegated prefixes ๐โโ๏ธCONFIRM (4): a client sends a Confirm message to any available server to check whether the addresses it was assigned still fit the link it's connected to ๐RENEW (5): a client sends a Renew message to the server that originally gave it its leases and configuration parameters, to extend the lease lifetimes and update other configuration parameters ๐REBIND (6): a client sends a Rebind message to any available server to extend the lease lifetimes and update other configuration parameters. this is sent after a client gets no response to a Renew message ๐ญREPLY (7): a server sends a Reply message with assigned leases and configuration parameters in response to a Solicit, Request, Renew, or Rebind message. a server also sends a Reply with configuration parameters in response to an Information-request message, and with a confirm or deny about whether the client's addresses fit the link in response to a Confirm message. and it sends a Reply to acknowledge a Release or Decline message ๐RELEASE (8): a client sends a Release message to the server that assigned its leases, to say it will no longer use one or more of them ๐DECLINE (9): a client sends a Decline message to a server to say it has found that one or more addresses the server assigned are already in use on the client's link ๐ซRECONFIGURE (10): a server sends a Reconfigure message to a client to say the server has new or updated configuration parameters, and that the client should start a Renew/Reply, Rebind/Reply, or Information-request/Reply exchange with the server to get the updated info ๐ฌINFORMATION-REQUEST (11): a client sends an Information-request message to a server to ask for configuration parameters without getting any leases assigned ๐๏ธRELAY-FORW (12): a relay agent sends a Relay-forward message to pass messages along to servers, either directly or through another relay agent. the received message (either a client message or a Relay-forward message from another relay agent) gets wrapped in an option inside the Relay-forward message ๐RELAY-REPL (13): a server sends a Relay-reply message to a relay agent with a message the relay agent delivers to a client. the Relay-reply message may be relayed by other relay agents on its way to the destination relay agent ๐
the server wraps the client message as an option in the Relay-reply message, and the relay agent unwraps it and relays it to the client ๐ท
7.4. DHCP Option Codes ๐ท๏ธ
DHCP uses options in messages a LOT ๐ some are defined later on, in Section 21. other options are defined in other documents or may be defined in the future (see [RFC7227] for guidance on defining new options) โจ
7.5. Status Codes ๐ฆ
DHCP uses status codes to show whether operations requested in messages from clients and servers succeeded or failed, and to give more detail on the specific cause of a failure. the specific status codes are defined in Section 21.13 ๐
if the Status Code option (see Section 21.13) doesn't show up in a message where it could appear, the message's status is assumed to be Success โ
7.6. Transmission and Retransmission Parameters โฑ๏ธ
okay so this table is basically the cheat sheet for how clients and servers handle sending messages again and again ๐ Some of these values get nudged by a randomization factor and backoffs (check Section 15 for that drama ๐). Transmissions can also get affected by rate limiting, so peep Section 14.1 too ๐ฆ
+=================+============+============================+
| Parameter | Default | Description |
+=================+============+============================+
| SOL_MAX_DELAY | 1 sec | Max delay of first Solicit |
+-----------------+------------+----------------------------+
| SOL_TIMEOUT | 1 sec | Initial Solicit timeout |
+-----------------+------------+----------------------------+
| SOL_MAX_RT | 3600 secs | Max Solicit timeout value |
+-----------------+------------+----------------------------+
| REQ_TIMEOUT | 1 sec | Initial Request timeout |
+-----------------+------------+----------------------------+
| REQ_MAX_RT | 30 secs | Max Request timeout value |
+-----------------+------------+----------------------------+
| REQ_MAX_RC | 10 | Max Request retry attempts |
+-----------------+------------+----------------------------+
| CNF_MAX_DELAY | 1 sec | Max delay of first Confirm |
+-----------------+------------+----------------------------+
| CNF_TIMEOUT | 1 sec | Initial Confirm timeout |
+-----------------+------------+----------------------------+
| CNF_MAX_RT | 4 secs | Max Confirm timeout |
+-----------------+------------+----------------------------+
| CNF_MAX_RD | 10 secs | Max Confirm duration |
+-----------------+------------+----------------------------+
| REN_TIMEOUT | 10 secs | Initial Renew timeout |
+-----------------+------------+----------------------------+
| REN_MAX_RT | 600 secs | Max Renew timeout value |
+-----------------+------------+----------------------------+
| REB_TIMEOUT | 10 secs | Initial Rebind timeout |
+-----------------+------------+----------------------------+
| REB_MAX_RT | 600 secs | Max Rebind timeout value |
+-----------------+------------+----------------------------+
| INF_MAX_DELAY | 1 sec | Max delay of first |
| | | Information-request |
+-----------------+------------+----------------------------+
| INF_TIMEOUT | 1 sec | Initial Information- |
| | | request timeout |
+-----------------+------------+----------------------------+
| INF_MAX_RT | 3600 secs | Max Information-request |
| | | timeout value |
+-----------------+------------+----------------------------+
| REL_TIMEOUT | 1 sec | Initial Release timeout |
+-----------------+------------+----------------------------+
| REL_MAX_RC | 4 | Max Release retry attempts |
+-----------------+------------+----------------------------+
| DEC_TIMEOUT | 1 sec | Initial Decline timeout |
+-----------------+------------+----------------------------+
| DEC_MAX_RC | 4 | Max Decline retry attempts |
+-----------------+------------+----------------------------+
| REC_TIMEOUT | 2 secs | Initial Reconfigure |
| | | timeout |
+-----------------+------------+----------------------------+
| REC_MAX_RC | 8 | Max Reconfigure attempts |
+-----------------+------------+----------------------------+
| HOP_COUNT_LIMIT | 8 | Max hop count in a Relay- |
| | | forward message |
+-----------------+------------+----------------------------+
| IRT_DEFAULT | 86400 secs | Default information |
| | (24 hours) | refresh time |
+-----------------+------------+----------------------------+
| IRT_MINIMUM | 600 secs | Min information refresh |
| | | time |
+-----------------+------------+----------------------------+
| MAX_WAIT_TIME | 60 secs | Max required time to wait |
| | | for a response |
+-----------------+------------+----------------------------+Table 1: Transmission and Retransmission Parameters
7.7. Representation of Time Values and "Infinity" as a Time Value โพ๏ธ
okay time values are giving pure simplicity ๐ฐ๏ธ Every time value for lifetimes, T1, and T2 is an unsigned 32-bit integer measured in seconds. When 0xffffffff shows up as a lifetime (like in [RFC4861]) or as a value for T1 or T2, it means "infinity" ๐
Setting the valid lifetime of an address or a delegated prefix to 0xffffffff ("infinity") basically means a permanent assignment of that address or delegation to a client ๐ So this should only be used when permanent assignments are actually what you want, bestie ๐ซถ
Care should be taken when setting T1 or T2 to 0xffffffff ("infinity") ๐ฌ A client will never try to extend the lifetimes of any addresses in an IA with T1 set to 0xffffffff. And a client will never use a Rebind message to hunt down a different server just to extend the lifetimes of any addresses in an IA with T2 set to 0xffffffff ๐
โโ๏ธ
8. Client/Server Message Formats ๐จ
all DHCP messages between clients and servers share the same fixed-format header, plus a variable-format area for options ๐
All values in the message header and in options are in network byte order ๐ข
Options are stored one after another in the "options" field, with no padding between them โจ They're byte-aligned, but they aren't aligned in any other way (so no lining up on 2-byte or 4-byte boundaries, sorry not sorry) ๐
Here's the vibe check for DHCP messages sent between clients and servers ๐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable number and length) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Client/Server Message Format
msg-type: tells you which DHCP message type this is. The available types are listed in Section 7.3. It's a 1-octet field ๐ท๏ธtransaction-id: the transaction ID for this message exchange. It's a 3-octet field ๐ชชoptions: the options carried in this message. They're described in Section 21. It's a variable-length field (4 octets less than the size of the message) ๐งฉ
9. Relay Agent/Server Message Formats ๐ฐ๏ธ
okay relay agents are the ultimate middle friends ๐ซ They pass messages back and forth between other relay agents and servers so that clients and servers who aren't on the same link can still talk ๐
All values in the message header and in options are in network byte order ๐ข
Options are stored one after another in the "options" field, with no padding between them โจ They're byte-aligned, but they aren't aligned in any other way (on 2-byte or 4-byte boundaries, no thanks) ๐
There are two relay agent messages, Relay-forward and Relay-reply, and they both share this format ๐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| peer-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Relay Agent/Server Message Format
The following sections describe how to use the relay agent message header ๐ง
9.1. Relay-forward Message ๐ฌ
This list spells out how each message field is used in a Relay-forward message ๐
msg-type:RELAY-FORW(12). It's a 1-octet field ๐hop-count: the number of relay agents that have already relayed this message. It's a 1-octet field ๐ขlink-address: an address that the server can use to identify the link where the client is located. This is typically a globally scoped unicast address (i.e., GUA or ULA), but check out the discussion in Section 19.1.1 for the deets ๐ It's a 16-octet field.peer-address: the address of the client or relay agent that the message to be relayed came from. It's a 16-octet field ๐options: this MUST include a Relay Message option (see Section 21.10). It MAY include other options, like the Interface-Id option (see Section 21.18), which gets added by the relay agent ๐ It's a variable-length field (34 octets less than the size of the message).
Want to know how link-address gets used? Look at Section 13.1 ๐
9.2. Relay-reply Message ๐ซ
Same energy as before: this list defines how message fields get used in a Relay-reply message ๐
msg-type:RELAY-REPL(13). It's a 1-octet field ๐hop-count: copied from the Relay-forward message. It's a 1-octet field ๐ขlink-address: copied from the Relay-forward message. It's a 16-octet field ๐peer-address: copied from the Relay-forward message. It's a 16-octet field ๐options: this MUST include a Relay Message option (see Section 21.10). It MAY include other options, like the Interface-Id option (see Section 21.18) ๐ It's a variable-length field (34 octets less than the size of the message).
10. Representation and Use of Domain Names ๐
Okay so domain names need to be encoded the same way everywhere ๐ That's why a domain name, or a list of domain names, gets encoded using the technique described in Section 3.1 of [RFC1035]. The message compression scheme in Section 4.1.4 of [RFC1035] MUST NOT be used ๐ โโ๏ธ No compression for you, no matter how tempting it looks ๐
11. DHCP Unique Identifier (DUID) โจ
Okay bestie, every DHCP client and server has a DUID ๐๐. Servers use DUIDs to figure out which client is which, so they can pick the right configuration parameters and link IAs to the right client ๐. Clients use DUIDs to point at a server when they need to name one ๐ซถ. For how a DUID shows up inside a DHCP message, see Sections 21.2 and 21.3 ๐.
Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. They SHOULD NOT interpret DUIDs in any other way ๐ โโ๏ธ. They MUST NOT restrict DUIDs to the types defined in this document, because additional DUID types may be defined in the future ๐ฎ.
Also, trying to parse a DUID to pull out a client's link-layer address is unreliable, and it's not something to lean on ๐. There's no guarantee the client is still using the same link-layer address it had when it made its DUID. And it's only getting worse as more clients use privacy measures like the ones in [RFC7844] ๐ต๏ธโโ๏ธ. If you really need that capability, the recommended move is to use the Client Link-Layer Address option instead [RFC6939] ๐ .
The DUID lives inside an option because it can be variable in length, and because it isn't required in every DHCP message ๐ฆ. It's designed to be unique across all DHCP clients and servers, and stable for any specific client or server ๐. So the DUID used by a client or server SHOULD NOT change over time if at all possible. For example, a device's DUID shouldn't change just because its network hardware changed, or because virtual interfaces changed (like logical PPP over Ethernet interfaces that come and go in Customer Premises Equipment routers) ๐. A client may still change its DUID as specified in [RFC7844] ๐ฆ.
Why have more than one type of DUID at all? Because a DUID has to be globally unique and also easy to generate ๐งฉ. The kind of globally unique identifier that's easy to make can vary a LOT from device to device. Plus, some devices have no persistent storage at all, so they can't keep a generated DUID around. The DUID scheme has to work for those devices too ๐ฅบ.
11.1. DUID Contents
A DUID is a 2-octet type code in network byte order, followed by a variable number of octets that make up the actual identifier ๐ข. The length of the DUID (not counting the type code) is at least 1 octet and at most 128 octets ๐. These are the types defined right now:
+======+======================================================+
| Type | Description |
+======+======================================================+
| 1 | Link-layer address plus time |
+------+------------------------------------------------------+
| 2 | Vendor-assigned unique ID based on Enterprise Number |
+------+------------------------------------------------------+
| 3 | Link-layer address |
+------+------------------------------------------------------+
| 4 | Universally Unique Identifier (UUID) [RFC6355] |
+------+------------------------------------------------------+
Table 2: DUID TypesThe formats for the variable field of the first three types are shown below ๐. The fourth one, DUID-UUID [RFC6355], is for situations where there's a UUID stored in a device's firmware settings ๐.
11.2. DUID Based on Link-Layer Address Plus Time (DUID-LLT)
This DUID type starts with a 2-octet type field set to 1, then a 2-octet hardware type code, then 4 octets holding a time value ๐ฐ๏ธ. After that comes the link-layer address of any one network interface that's connected to the DHCP device when the DUID gets generated. The time value is the time the DUID was generated, counted in seconds since midnight (UTC), January 1, 2000, modulo 2^32 โณ. The hardware type MUST be a valid hardware type assigned by IANA; see [IANA-HARDWARE-TYPES] ๐. Both the time and the hardware type are stored in network byte order. For Ethernet hardware types, the link-layer address is stored in canonical form, as described in [RFC2464] ๐งพ.
Here's what a DUID-LLT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (1) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DUID-LLT FormatYou can pick whichever network interface you want, as long as it gives you a globally unique link-layer address for its link type ๐. The same DUID-LLT SHOULD be used when configuring all the network interfaces connected to the device, no matter which interface's link-layer address was used to generate it โจ.
Clients and servers using this DUID type MUST store the DUID-LLT in stable storage, and MUST continue to use this DUID-LLT even if the network interface used to generate it gets removed ๐พ. Clients and servers without any stable storage MUST NOT use this type of DUID ๐ซ.
Clients and servers that use this DUID SHOULD try to set the time before generating the DUID, if that's possible ๐. They MUST use some sort of time source (like a real-time clock) when generating the DUID, even if that time source couldn't be configured beforehand โฐ. Using a time source makes it unlikely that two identical DUID-LLTs get generated, say if the network interface is moved to another client that then uses the same interface to generate a DUID-LLT ๐ค. Even if the clocks weren't configured beforehand, a collision between two DUID-LLTs is still very unlikely ๐ฅฐ.
This way of generating a DUID is recommended for all general-purpose computing devices, like desktops and laptops, and for devices like printers and routers that have some form of writable non-volatile storage ๐จ๏ธ๐ป.
Okay, real talk: this algorithm could result in a client identifier collision ๐ฌ. So a DHCP client that generates a DUID-LLT this way MUST provide an administrative interface that replaces the existing DUID with a newly generated DUID-LLT ๐ ๏ธ.
11.3. DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)
The vendor assigns this DUID type to the device ๐ญ. It's made of the vendor's registered 4-octet Private Enterprise Number, as maintained by IANA [IANA-PEN], followed by a unique identifier the vendor assigns ๐ง. Here's the structure of a DUID-EN:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (2) | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DUID-EN FormatThe vendor gets to decide where the identifier comes from ๐คทโโ๏ธ. But every identifier part of each DUID-EN MUST be unique to the device using it, and MUST be assigned to the device no later than its first use, then stored in some form of non-volatile storage ๐. This usually happens during manufacturing for physical devices, or for virtual machines when the image is created or booted for the first time ๐ฅ๏ธ. The generated DUID SHOULD be recorded in non-erasable storage ๐. The enterprise-number is the vendor's registered Private Enterprise Number as maintained by IANA [IANA-PEN], stored as an unsigned 32-bit number ๐ข.
Here's an example DUID of this type ๐ฏ:
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 |126|217| 12|192|
+---+---+---+---+---+---+---+---+
|132|211| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+
Figure 6: DUID-EN ExampleThis example has the 2-octet type of 2 and the Enterprise Number (32473) (from [RFC5612]), followed by 8 octets of identifier data (0x0CC084D303000912) ๐.
11.4. DUID Based on Link-Layer Address (DUID-LL)
This DUID type is 2 octets holding a DUID type of 3, plus a 2-octet network hardware type code. After that comes the link-layer address of any one network interface that's permanently connected to the client or server device ๐. For example, a node with a network interface built into a chip that's unlikely to get removed and used somewhere else could use a DUID-LL ๐ง . The hardware type MUST be a valid hardware type assigned by IANA; see [IANA-HARDWARE-TYPES] ๐. It's stored in network byte order, and the link-layer address is stored in canonical form, as described in [RFC2464] ๐ . Here's the format of a DUID-LL:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (3) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DUID-LL FormatThe choice of network interface can be totally arbitrary, as long as that interface has a unique link-layer address and is permanently attached to the device where the DUID-LL is being generated ๐งฉ. The same DUID-LL SHOULD be used when configuring all the network interfaces connected to the device, no matter which interface's link-layer address was used to generate the DUID ๐ธ.
A DUID-LL is recommended for devices that have a permanently connected network interface with a link-layer address and don't have nonvolatile, writable stable storage ๐. A DUID-LL SHOULD NOT be used by DHCP clients or servers that can't tell whether a network interface is permanently attached to the device they're running on ๐ โโ๏ธ. Know your device, bestie! ๐
11.5. DUID Based on Universally Unique Identifier (DUID-UUID) ๐ฆ
okay so this DUID type is giving "sixteen octets of pure UUID energy" ๐ It's 16 octets containing a 128-bit UUID, and [RFC6355] is the doc that spills the tea on when you should pick this type and how to choose a good source for the UUID โจ Go read it, bestie ๐ค
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Figure 8: DUID-UUID Format ๐
12. Identity Association ๐ธ
okay so an Identity Association (IA) is basically the client and server's little friendship bracelet ๐ It's how they identify, group, and manage a set of related IPv6 addresses or delegated prefixes. Each IA has an IAID plus its configuration info ๐ง
12.1. Identity Associations for Address Assignment โจ
Each IA needs to have a distinct IA for each network interface where the client wants IPv6 addresses from a DHCP server, and the client uses those IAs to grab config info from the server for that interface ๐ Every IA gets matched up with exactly one interface, no sharing ๐ซถ
Hmm, let me be precise, because this is the sort of thing you get wrong and then your whole network is in shambles ๐ญ Here's the real version:
A client MUST associate at least one distinct IA with each of its network interfaces for which it is to request the assignment of IPv6 addresses from a DHCP server. The client uses the IAs assigned to an interface to obtain configuration information from a server for that interface. Each such IA MUST be associated with exactly one interface.
The configuration info in an IA_NA option is one or more IPv6 addresses plus the T1 and T2 values for the IA ๐ Check Section 21.4 for how an IA_NA shows up in a DHCP message.
Each address in an IA has a preferred lifetime and a valid lifetime, as defined in [RFC4862] โจ The server sends those lifetimes to the client in the IA Address option (see Section 21.6). The lifetimes apply to how addresses get used, so see Section 5.5.4 of [RFC4862] ๐
12.2. Identity Associations for Prefix Delegation ๐ฆ
An IA_PD is a little different, bestie ๐ It doesn't have to be tied to exactly one interface, because one IA_PD can be associated with the client, a set of interfaces, or exactly one interface. A client that's configured to request delegated prefixes MUST create at least one distinct IA_PD. It MAY associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to get a prefix for that interface from the server ๐
The config info in an IA_PD option is one or more prefixes plus the T1 and T2 values for the IA_PD. See Section 21.21 for how an IA_PD shows up in a DHCP message ๐ง
Each delegated prefix in an IA has a preferred lifetime and a valid lifetime, as defined in [RFC4862] ๐ The server sends those lifetimes to the client in the IA Prefix option (see Section 21.22). The lifetimes apply to how delegated prefixes get used, so see Section 5.5.4 of [RFC4862] ๐ซถ
13. Assignment to an IA ๐
13.1. Selecting Addresses for Assignment to an IA_NA โจ
A server picks addresses to assign to an IA_NA based on the address assignment policies set by the server administrator, plus whatever it figures out about the client from some mix of these sources:
- The link the client is attached to. The server figures out the link like this:
- If the server gets the message directly from the client and the source address in the IP datagram is a link-local address, then the client is on the same link as the interface the message came in on.
- If the server gets the message from a forwarding relay agent, then the client is on the same link as the one the interface identified by the link-address field in the relay agent's message is attached to. According to [RFC6221], the server MUST ignore any link-address field whose value is zero. The link-address in this case may come from any of the Relay-forward messages encapsulated in the received Relay-forward, and in general the most encapsulated one (the Relay-forward closest to the client) has the most useful value ๐ฅ
- The DUID the client supplied ๐
- Other info in options the client supplied, e.g., IA Address options (see Section 21.6) that include the client's requests for specific addresses ๐ธ
- Other info in options the relay agent supplied ๐ง
By default, DHCP server implementations SHOULD NOT generate predictable addresses (see Section 4.7 of [RFC7721]). Server implementers are encouraged to check out [RFC8981], [RFC7824], [RFC7707], and [RFC7943] for considerations on how to generate addresses ๐
A server MUST NOT assign an address that's reserved for some other purpose ๐ For example, a server MUST NOT assign addresses that use a reserved IPv6 Interface Identifier [RFC5453] [RFC7136] [IANA-RESERVED-IID].
See [RFC7969] for a more detailed discussion on how servers figure out a client's location on the network ๐ฆ
13.2. Assignment of Prefixes for IA_PD ๐
This document doesn't specify how the server picks prefix(es) for delegation ๐ Some examples of how a server might choose prefix(es) for a client are static assignment based on an ISP subscription, dynamic assignment from a pool of available prefixes, and selection based on an external authority like a RADIUS server using the Framed-IPv6-Prefix option described in [RFC3162] ๐
14. Transmission of Messages by a Client ๐
Unless this document or a document describing how IPv6 is carried over a specific type of link says otherwise (for link types that don't support multicast), a client sends DHCP messages to the All_DHCP_Relay_Agents_and_Servers multicast address โจ
DHCP servers SHOULD NOT check whether the Layer 2 address used was multicast or not, as long as the Layer 3 address was correct ๐
A client uses multicast to reach all servers or one individual server. To target an individual server, the client specifies that server's DUID in a Server Identifier option (see Section 21.3) in its message. (All servers will receive this message, but only the indicated server will respond ๐ซถ) If this option isn't supplied, all servers are indicated ๐ง
14.1. Rate Limiting ๐ฅ
A DHCPv6 client MUST limit the rate of DHCP messages it transmits or retransmits. This minimizes the impact of prolonged message bursts or loops, for example when a client rejects a server's response, repeats the request, and gets the same server response, which then gets rejected by the client again ๐ญ
This loop can repeat infinitely if there's no quit/stop mechanism, so a client MUST NOT initiate transmissions too frequently ๐
A recommended method for implementing the rate-limiting function is a token bucket (see Appendix A of [RFC3290]), which limits the average rate of transmission to a certain number in a certain time interval. This way of bounding burstiness also guarantees that the long-term transmission rate won't be exceeded ๐ธ
A transmission rate limit SHOULD be configurable. A possible default could be 20 messages in 20 seconds ๐
For a device with multiple interfaces, the limit MUST be enforced on a per-interface basis ๐
Rate limiting of forwarded DHCP messages and server-side messages is out of scope for this specification ๐ฆ
14.2. Client Behavior when T1 and/or T2 Are 0 ๐
In certain cases, T1 and/or T2 values may be set to 0. Currently there are two such cases:
- a client received an IA_NA option (see Section 21.4) with a zero value
- a client received an IA_PD option (see Section 21.21) with a zero value
This is a signal that the renew and rebind times are left up to the client's discretion ๐ They aren't completely discretionary, though ๐
When T1 and/or T2 values are set to 0, the client MUST choose a time to avoid message storms. In particular, it MUST NOT transmit immediately. If the client received multiple IA options, it SHOULD pick renew and/or rebind transmission times so all IA options are handled in one exchange, if possible ๐ The client MUST choose renew and rebind times that don't violate the rate-limiting restrictions defined in Section 14.1 โจ
15. Reliability of Client-Initiated Message Exchanges โจ
okay so DHCP clients are the ones in charge of making sure their messages actually arrive ๐ฌ for the client-initiated exchanges in Section 18. If a client doesn't get the response it was waiting for from a server, it must retransmit its message using the strategy below. ๐
Note that this procedure is slightly modified when it's used with the Solicit message ๐. The modified version is described in Section 18.2.1.
The client kicks things off by sending a message to the server ๐. The exchange wraps up when either (1) the client successfully gets the right response or responses from a server or servers, or (2) the retransmission mechanism below decides it has failed ๐ญ.
The client MUST update an "elapsed-time" value within an Elapsed Time option (see Section 21.9) in the retransmitted message. Sometimes the client may also need to modify values in IA Address options (see Section 21.6) or IA Prefix options (see Section 21.22) if a valid lifetime for any of the client's leases expires before retransmission ๐ง. So whenever this document says "retransmission," it means both tweaking the original message AND sending this new instance to the server. Main character energy ๐
The client's retransmission behavior is controlled by the following variables ๐ฆ:
RT: Retransmission timeout
IRT: Initial retransmission time
MRC: Maximum retransmission count
MRT: Maximum retransmission time
MRD: Maximum retransmission duration
RAND: Randomization factorSpecific values for each of these parameters, for the different messages, are listed in the subsections of Section 18.2, using the values defined in Table 1 in Section 7.6 ๐ธ. The algorithm for RAND is the same across all message transmissions.
With every message transmission or retransmission, the client sets RT using the rules below. If RT expires before the message exchange ends, the client recomputes RT and retransmits the message ๐.
Every new RT computation includes a randomization factor (RAND), a random number picked with a uniform distribution between -0.1 and +0.1. It's there to keep DHCP clients from all sending their messages in sync ๐.
The algorithm for choosing a random number doesn't need to be cryptographically sound ๐คท. It SHOULD produce a different sequence of random numbers from each invocation of the DHCP client.
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRTRT for each later transmission is based on the previous value of RT:
RT = 2*RTprev + RAND*RTprevMRT sets an upper bound on the value of RT (ignoring the randomization added by RAND) โญ. If MRT is 0, RT has no upper limit. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRTMRC sets an upper bound on how many times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times ๐.
MRD sets an upper bound on how long a client may keep retransmitting a message. Unless MRD is zero, the message exchange fails once MRD seconds have passed since the client first sent the message โฐ.
If both MRC and MRD are non-zero, the exchange fails whenever either of the two conditions above is met ๐.
If both MRC and MRD are zero, the client keeps transmitting the message until it gets a response ๐ซถ.
A client isn't expected to listen for a response the whole time RT is running ๐ด. It can turn off its listening capabilities after waiting at least the shorter of RT and MAX_WAIT_TIME, for power saving or other reasons ๐. Of course, a client MUST listen for a Reconfigure if it has negotiated its use with the server ๐.
16. Message Validation ๐
This section describes which options are valid in which kinds of message types, and explains what to do when a client or server gets a message containing known options that are invalid for that message. For example, an IA option isn't allowed to show up in an Information-request message ๐ โโ๏ธ.
Clients and servers MAY choose to either (1) pull information out of such a message if it's useful to the recipient, or (2) ignore the message completely and just discard it ๐๏ธ.
If a server gets a message it considers invalid, it MAY send a Reply message (or an Advertise message, as appropriate). That reply can carry a Server Identifier option (see Section 21.3), a Client Identifier option (see Section 21.2) if one was included in the message, and a Status Code option (see Section 21.13) with the status UnspecFail ๐.
Clients, relay agents, and servers MUST NOT discard messages that contain unknown options (or instances of vendor options with unknown enterprise-number values) ๐. Those options should be ignored as if they weren't there. This is critical for making room for future extensions of DHCP, so it's a big deal ๐ฎ.
A client or server MUST discard any received DHCP message with an unknown message type ๐ซ.
Clients SHOULD NOT accept multicast messages ๐ฃ.
Servers SHOULD NOT accept unicast traffic from clients. The Server Unicast option (see Section 21.12) and the UseMulticast status code (see Section 21.13) have been obsoleted, so clients should no longer send messages to a server's unicast address or receive the UseMulticast status code ๐. However, a server that used to support the Server Unicast option and has been upgraded so it no longer does MAY keep receiving unicast messages, but only if it previously sent the client the Server Unicast option. This causes no harm, and the client will eventually switch back to sending multicast messages (such as after the lease's rebinding time is reached or the client is rebooted) ๐.
Relay agents SHOULD NOT accept unicast messages from clients ๐ช.
Note: The multicast/unicast rules above apply to the DHCP messages within this document. Messages defined in other and future documents may have different rules. ๐
16.1. Use of Transaction IDs ๐ชช
The "transaction-id" field holds a value that clients and servers use to match server responses to client messages ๐งฉ. A client SHOULD generate a random number that can't easily be guessed or predicted to use as the transaction ID for each new message it sends. If a client generates easily predictable transaction identifiers, it may become more vulnerable to certain kinds of attacks from off-path intruders ๐ฑ. A client MUST leave the transaction ID unchanged in retransmissions of a message ๐.
16.2. Solicit Message ๐จ
Clients MUST discard any received Solicit messages ๐ .
Servers MUST discard any Solicit messages that don't include a Client Identifier option, or that do include a Server Identifier option โ๏ธ.
16.3. Advertise Message ๐ข
Clients MUST discard any received Advertise message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the message does not include a Client Identifier option (see Section 21.2).
- the contents of the Client Identifier option do not match the client's DUID.
- the "transaction-id" field value does not match the value the client used in its Solicit message.
Servers and relay agents MUST discard any received Advertise messages ๐๏ธ.
16.4. Request Message ๐
Clients MUST discard any received Request messages ๐ซ.
Servers MUST discard any received Request message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the contents of the Server Identifier option do not match the server's DUID.
- the message does not include a Client Identifier option (see Section 21.2).
16.5. Confirm Message โ
Clients MUST discard any received Confirm messages ๐ โโ๏ธ.
Servers MUST discard any received Confirm messages that don't include a Client Identifier option (see Section 21.2), or that do include a Server Identifier option (see Section 21.3) ๐ซ .
16.6. Renew Message ๐
Clients MUST discard any received Renew messages ๐ซ.
Servers MUST discard any received Renew message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option (see Section 21.2).
16.7. Rebind Message ๐
Clients MUST discard any received Rebind messages ๐ .
Servers MUST discard any received Rebind messages that don't include a Client Identifier option (see Section 21.2), or that do include a Server Identifier option (see Section 21.3) ๐ .
16.8. Decline Message ๐
Clients MUST discard any received Decline messages ๐ซ.
Servers MUST discard any received Decline message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option (see Section 21.2).
16.9. Release Message ๐
Clients MUST discard any received Release messages ๐ซ.
Servers MUST discard any received Release message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option (see Section 21.2).
16.10. Reply Message ๐
Clients MUST discard any received Reply message that meets any of the following conditions:
- the message does not include a Server Identifier option (see Section 21.3).
- the "transaction-id" field in the message does not match the value used in the original message.
If the client included a Client Identifier option (see Section 21.2) in the original message, the Reply message MUST include a Client Identifier option, and the contents of the Client Identifier option MUST match the DUID of the client ๐ช. If the client did not include a Client Identifier option in the original message, the Reply message MUST NOT include a Client Identifier option ๐ โโ๏ธ.
Servers and relay agents MUST discard any received Reply messages ๐๏ธ.
16.11. Reconfigure Message โก
Servers and relay agents MUST discard any received Reconfigure messages ๐ซ.
Clients MUST discard any Reconfigure message that meets any of the following conditions:
- the message was not unicast to the client.
- the message does not include a Server Identifier option (see Section 21.3).
- the message does not include a Client Identifier option (see Section 21.2) that contains the client's DUID.
- the message does not include a Reconfigure Message option (see Section 21.19).
- the Reconfigure Message option msg-type is not a valid value.
- the message does not include authentication (such as RKAP; see Section 20.4) or fails authentication validation ๐.
16.12. Information-request Message โจ
okay bestie, Information-request messages have their own bouncer rules ๐ Clients MUST discard any received Information-request messages. no client gets to read these, period ๐
Servers have a little more to check ๐ A server MUST discard any received Information-request message that meets any of the following conditions:
- the message includes a Server Identifier option (see Section 21.3), and the DUID in the option does not match the server's DUID. ๐
- the message includes an IA option. ๐ โโ๏ธ
16.13. Relay-forward Message ๐ฆ
Clients MUST discard any received Relay-forward messages. nope, not for them ๐ โโ๏ธ
16.14. Relay-reply Message ๐ธ
Clients and servers MUST discard any received Relay-reply messages. this one is a total no-go for everybody ๐
17. Client Source Address and Interface Selection ๐
the client's interface-picking behavior is different depending on what the configuration is for โจ it's giving "it depends" energy and honestly it's iconic ๐
17.1. Source Address and Interface Selection for Address Assignment ๐ง
When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send the message through the interface for which configuration information (including the addresses) is being requested. ๐ However, the client MAY send the message through another interface if the interface for which configuration is being requested is a logical interface without direct link attachment, or if the client is certain that two interfaces are attached to the same link. ๐ซถ
17.2. Source Address and Interface Selection for Prefix Delegation ๐
okay so delegated prefixes don't belong to an interface the way addresses do for address assignment (like we just said in Section 17.1 above) ๐
When a client sends a DHCP message for the purpose of prefix delegation, it SHOULD be sent on the interface associated with the upstream router (typically, connected to an ISP network); see [RFC7084]. โจ The upstream interface is typically determined by configuration. This rule applies even in the case where a separate IA_PD is used for each downstream interface. main character rule, no exceptions ๐
18. DHCP Configuration Exchanges ๐
A client starts a message exchange with a server or servers to get or update the configuration info it cares about โจ clients have lots of reasons to kick things off. Some of the most common ones are:
- as part of the operating system configuration/bootstrap process,
- when requested to do so by the application layer (through an operating-system-specific API),
- when a Router Advertisement indicates that DHCPv6 is available for address configuration (see Section 4.2 of [RFC4861]),
- as required to extend the lifetime of address(es) and/or delegated prefix(es), using Renew and Rebind messages, or
- upon the receipt of a Reconfigure message, when requested to do so by a server.
The client is responsible for making IAs and asking a server to assign addresses and/or delegated prefixes to them ๐ it creates the IAs first and gives them IAIDs, then sends a Solicit message with the IA options that describe them. The client MUST NOT be using any of the addresses or delegated prefixes it's trying to get bindings for by sending that Solicit message ๐ โโ๏ธ and if the client already had valid bindings and decided to start server discovery to get those same bindings from a different server, it MUST stop using the addresses and delegated prefixes it got from the previous server for the bindings it's now chasing from a new server (see Section 18.2.7 for more details on what "stop using" means here) ๐ซ
A DHCP client that doesn't need a server to assign it IP addresses or delegated prefixes can still grab configuration info, like a list of DNS servers [RFC3646] or NTP servers [RFC5908], in one single message and reply exchange with a DHCP server โก to do that, the client first sends an Information-request message (see Section 18.2.6) to the All_DHCP_Relay_Agents_and_Servers multicast address, and servers respond with a Reply message holding the configuration info for that client (see Section 18.3.6) ๐ธ
If a client wants one or more addresses or delegated prefixes, it first finds a DHCP server and then asks that server for the addresses/prefixes plus any other configuration info ๐
it does this by sending a Solicit message (see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers multicast address and collecting Advertise messages from the servers that answer. then the client picks one server to get its configuration from. this whole process is called server discovery ๐ once the client has picked a server, it sends a Request message to that server as described in Section 18.2.2 ๐ฆ
A client that's willing to do the Solicit/Reply exchange from Section 18.2.1 includes a Rapid Commit option (see Section 21.14) in its Solicit message โก
Servers that can assign addresses or delegated prefixes to the IAs answer the client with an Advertise message or a Reply message, as long as the client included a Rapid Commit option and the server is configured to accept it ๐
If the server answers with an Advertise message, the client starts a configuration exchange as described in Section 18.2.2 ๐ง
A server may start a message exchange with a client by sending a Reconfigure message ๐ this tells the client to send a Renew, Rebind, or Information-request message so it can refresh its configuration info as soon as the Reconfigure message shows up ๐ซถ
Figure 9 is a timeline of the messages a client and two servers swap over the typical lifecycle of one or more leases ๐ it kicks off with the four-message Solicit/Advertise/Request/Reply exchange to get the lease(s), moves on to a two-message Renew/Reply exchange to extend the lifetime on the lease(s), and wraps up with a two-message Release/Reply exchange where the client stops using the lease(s) ๐
Server Server
(not selected) Client (selected)
v v v
| | |
| Begins initialization |
| | |
start of | _____________/|\_____________ |
4-message |/ Solicit | Solicit \|
exchange | | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/|
| \________ | /Advertise |
| Advertise\ |/ |
| \ | |
| Collects Advertises |
| \ | |
| Selects configuration |
| | |
| _____________/|\_____________ |
|/ Request | Request \|
| | |
| | Commits configuration
| | |
end of | | _____________/|
4-message | |/ Reply |
exchange | | |
| Initialization complete |
| | |
. . .
. . .
| T1 (renewal) timer expires |
| | |
2-message | _____________/|\_____________ |
exchange |/ Renew | Renew \|
| | |
| | Commits extended lease(s)
| | |
| | _____________/|
| |/ Reply |
. . .
. . .
| | |
| Graceful shutdown |
| | |
2-message | _____________/|\_____________ |
exchange |/ Release | Release \|
| | |
| | Discards lease(s)
| | |
| | _____________/|
| |/ Reply |
| | |
v v v
Figure 9: Timeline Diagram of the Messages Exchanged Between a
Client and Two Servers for the Typical Lifecycle of One or More
Leases18.1. A Single Exchange for Multiple IA Options ๐
this doc assumes a client SHOULD use one single transaction for all of the IA options it needs on an interface ๐ง it keeps the client implementation simple and cuts down on how many transactions it needs. to make that work, servers MUST return the same T1/T2 values for all IA options in a Reply (see Sections 18.3.2, 18.3.4, and 18.3.5), so the client makes just one transaction when it renews or rebinds its leases โจ but since some servers might not match this requirement yet, a client MUST be prepared to pick appropriate T1/T2 times as described in Section 18.2.4 ๐ซถ
18.2. Client Behavior โจ
okay so the client is the one doing all the asking ๐ A client uses the Solicit message to find DHCP servers that are set up to hand out leases or return other configuration parameters on the link it's plugged into ๐
Then the client uses Request, Renew, Rebind, Release, and Decline messages through the normal lifecycle of addresses and delegated prefixes ๐ If a client notices it might have moved to a new link, it sends Confirm if it only has addresses, or Rebind if it has delegated prefixes (and addresses too) ๐ฆ And if it needs configuration info but has no addresses and no prefixes, it uses Information-request messages ๐ธ
Here's the tea ๐ต When a client asks for multiple IA option types, or multiple instances of the same IA type, in a Solicit, Request, Renew, or Rebind, the server(s) might only be set up to offer some of them. When possible, the client SHOULD use the best configuration it's been given and keep asking for the rest in later messages ๐ This way the client keeps one single session and one state machine, which is so clean ๐ง In practice, especially when handling IA_NA and IA_PD requests [RFC7084], this should be rare or caused by a temporary operational error โจ So the client is more likely to get everything if it keeps asking, in every later exchange, for all the configuration it's programmed to try to get, including any stateful configuration options that didn't return results in earlier exchanges ๐ซถ
When the server sends a Reconfigure message, the client responds with a Renew, Rebind, or Information-request message, whichever one the Reconfigure Message option says to use (see Section 21.19) ๐ฃ Okay but be a little suspicious, bestie ๐ The client SHOULD be suspicious of Reconfigure messages because they might be faked, and it MUST NOT abandon any resources it might already have obtained ๐ญ The client SHOULD also treat the Reconfigure message as if its T1 timer had expired ๐ After that, the client expects the server to send IAs and/or other configuration information in a Reply message ๐
18.2.1. Creation and Transmission of Solicit Messages ๐ฆ
The client sets the msg-type field to SOLICIT ๐ It makes a transaction ID and puts it in the transaction-id field ๐
The client MUST include a Client Identifier option (see Section 21.2) so the server knows who it is ๐ชช It also includes IA options for any IAs it wants the server to assign leases to โจ
The client MUST include an Elapsed Time option (see Section 21.9) to show how long it's been trying to finish the current DHCP message exchange โณ
The client uses IA_NA options (see Section 21.4) to ask for non-temporary addresses, and IA_PD options (see Section 21.21) to ask for prefix delegation ๐ธ You can put IA_NA or IA_PD options in a DHCP message, or both together, and you can also include several instances of any IA option type ๐
The client MAY put addresses in IA Address options (see Section 21.6), which are nested inside an IA_NA option, as hints to the server about the addresses it prefers ๐
The client MAY put values in IA Prefix options (see Section 21.22), which are nested inside IA_PD options, as hints for the delegated prefix and/or prefix length it prefers ๐ท For more on prefix-length hints, check out Section 18.2.4 ๐
The client MUST include an Option Request option (ORO) (see Section 21.7) to ask for the SOL_MAX_RT option (see Section 21.24) and any other options it's interested in getting ๐ The client MAY also include instances of those options that are listed in the Option Request option, with data values as hints about parameter values it would love to get back ๐
If the client is willing to accept Reconfigure messages from the server, it includes a Reconfigure Accept option (see Section 21.20) ๐
The client MUST NOT include any other options in the Solicit message, except where the definition of an individual option specifically allows it ๐ซ
The first Solicit message from the client on the interface SHOULD be delayed by a random amount of time between 0 and SOL_MAX_DELAY ๐ฒ This random delay helps stop clients that start a DHCP session at the same time from all rushing in together, like after recovering from a power failure, or after a router outage when they see that DHCP is available in Router Advertisement messages (see Section 4.2 of [RFC4861]) ๐ซ
The client sends the message according to Section 15, using these parameters ๐
- IRT:
SOL_TIMEOUT - MRT:
SOL_MAX_RT - MRC:
0 - MRD:
0
A client that wants to use the Rapid Commit two-message exchange includes a Rapid Commit option (see Section 21.14) in its Solicit message โก It might get a bunch of different replies from different servers, and it'll make note of any valid Advertise messages it gets ๐๏ธ It will throw out any Reply messages that don't have the Rapid Commit option ๐๏ธ
When the client gets a valid Reply with the Rapid Commit option, it processes the message as described in Section 18.2.10 ๐
At the end of the first RT period, if there are no suitable Reply messages but the client has valid Advertise messages, the client processes the Advertise as described in Section 18.2.9 ๐ซ
If the client later gets a valid Reply message that includes a Rapid Commit option, it does one of the following ๐
- processes the Reply message as described in Section 18.2.10 and discards any Reply messages received in response to the Request message
- processes any Reply messages received in response to the Request message and discards the Reply message that includes the Rapid Commit option
If the client is waiting for an Advertise message, the Section 15 mechanism gets a glow-up for sending Solicit messages ๐ The exchange doesn't end just because an Advertise shows up before the first RT has elapsed ๐ โโ๏ธ Instead, the client collects valid Advertise messages until the first RT has passed ๐ฅ Also, the first RT MUST be picked to be strictly greater than IRT, by choosing RAND to be strictly greater than 0 ๐ฒ
A client MUST collect valid Advertise messages for the first RT seconds, unless it gets a valid Advertise message with a preference value of 255 โฑ๏ธ The preference value lives in the Preference option (see Section 21.8) ๐ท๏ธ Any valid Advertise without a Preference option counts as having a preference value of 0 ๐คทโโ๏ธ If the client gets a valid Advertise with a Preference option set to 255, it immediately starts a client-initiated message exchange (as described in Section 18.2.2) by sending a Request message to the server that sent that Advertise ๐ If the client gets a valid Advertise that doesn't have a preference value of 255, it keeps waiting until the first RT elapses ๐ฐ๏ธ If the first RT elapses and the client has a valid Advertise, the client SHOULD continue with a client-initiated message exchange by sending a Request message ๐
If the client doesn't get any valid Advertise messages before the first RT has elapsed, it then uses the retransmission mechanism from Section 15 ๐ The client stops the retransmission process as soon as it gets any valid Advertise message, and acts on that Advertise without waiting for more ๐โโ๏ธ
A DHCP client SHOULD choose MRC and MRD values of 0. If the DHCP client is configured with either MRC or MRD set to something other than 0, it MUST stop trying to configure the interface if the message exchange fails. After it stops, it SHOULD restart the reconfiguration process after some external event, like user input, a system restart, or when the client is attached to a new link. ๐จ
18.2.2. Creation and Transmission of Request Messages ๐
The client uses a Request message to fill up IAs with leases and to get other configuration information ๐ฐ It puts one or more IA options in the Request message, and the server sends the leases and other info about those IAs back in IA options in a Reply message ๐
The client sets the msg-type field to REQUEST ๐ It makes a transaction ID and puts it in the transaction-id field ๐ธ
The client MUST include the identifier of the destination server in a Server Identifier option (see Section 21.3) ๐ฏ
The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server ๐ชช It adds any other appropriate options, including one or more IA options โจ
The client MUST include an Elapsed Time option (see Section 21.9) to show how long it's been trying to finish the current DHCP message exchange โณ
The client MUST include an Option Request option (see Section 21.7) to ask for the SOL_MAX_RT option (see Section 21.24) and any other options it's interested in receiving ๐ It MAY also include instances of those options that are listed in the Option Request option, with data values as hints to the server about parameter values it would like returned ๐ง
If the client is willing to accept Reconfigure messages from the server, it includes a Reconfigure Accept option (see Section 21.20) ๐
The client sends the message according to Section 15, using these parameters ๐
- IRT:
REQ_TIMEOUT - MRT:
REQ_MAX_RT - MRC:
REQ_MAX_RC - MRD:
0
If the message exchange fails, the client takes an action based on its local policy ๐โโ๏ธ Some actions the client might take include the following ๐
- Select another server from a list of servers known to the client -- for example, servers that responded with an Advertise message.
- Initiate the server discovery process described in Section 18.
- Terminate the configuration process and report failure.
18.2.3. Creation and Transmission of Confirm Messages ๐ฆ
okay so the client sends a Confirm message when it only has addresses (no delegated prefixes) that a DHCP server gave it ๐ . It uses this to check whether it's still on the same link when it notices network info has changed, as described in Section 18.2.12. โจ
The client sets the msg-type field to CONFIRM. It makes up a transaction ID and drops it into the transaction-id field ๐.
The client MUST include a Client Identifier option (see Section 21.2) so the server knows exactly who it's talking to ๐ซถ
The client MUST include an Elapsed Time option (see Section 21.9) to show how long it's been trying to finish the current DHCP message exchange โณ
The client includes IA options for all the IAs assigned to the interface the Confirm is being sent on ๐. Those IA options carry every address the client currently has tied to those IAs. The client SHOULD set the T1 and T2 fields in any IA_NA options (see Section 21.4), and the preferred-lifetime and valid-lifetime fields in the IA Address options (see Section 21.6), to 0, since the server is going to ignore those fields anyway ๐
The first Confirm message from the client on the interface MUST be delayed by a random amount of time between 0 and CNF_MAX_DELAY. The client sends it according to Section 15, using these parameters:
- IRT:
CNF_TIMEOUT - MRT:
CNF_MAX_RT - MRC:
0 - MRD:
CNF_MAX_RD
If the client gets no responses before the transmission process ends (as described in Section 15), it SHOULD keep using any leases, with the last known lifetimes for those leases, and SHOULD keep using any other configuration parameters it previously got ๐ธ. It's giving stability, bestie ๐.
18.2.4. Creation and Transmission of Renew Messages ๐
so to extend the preferred and valid lifetimes on the leases assigned to the IAs, and to get new addresses or delegated prefixes for IAs, the client sends a Renew message to the server the leases came from ๐ง. The Renew message includes IA options for the IAs whose lease lifetimes need extending. The client puts IA Address options (see Section 21.6) inside IA_NA options (see Section 21.4) for the addresses assigned to the IAs, and IA Prefix options (see Section 21.22) inside IA_PD options (see Section 21.21) for the delegated prefixes assigned to the IAs ๐.
The server is the one in charge of when the client should check back in to extend its leases, through the T1 and T2 values assigned to an IA ๐. But since the client SHOULD renew/rebind all IAs from the server at the same time, the client MUST select T1 and T2 times from all IA options that guarantee it starts sending Renew/Rebind messages no later than the T1/T2 times for any of its bindings (earliest T1/T2). Main character energy for timing ๐ญ.
At time T1, the client starts a Renew/Reply message exchange to extend the lifetimes on any leases in the IA โจ.
A client MUST also start a Renew/Reply message exchange before time T1 if the link-local address it used in earlier conversations with the server is no longer valid and it's willing to receive Reconfigure messages ๐ฆ. This updates the server's info so it can keep talking to the client, either directly or through Relay-reply messages.
If the server set T1 or T2 to 0 (for an IA_NA or IA_PD) in an earlier Reply, the client may, at its discretion, send a Renew or Rebind message, respectively. The client MUST follow the rules defined in Section 14.2 ๐ .
The client sets the msg-type field to RENEW. It generates a transaction ID and puts it in the transaction-id field ๐.
The client MUST include a Server Identifier option (see Section 21.3) in the Renew message, naming the server it most recently talked to ๐ซถ.
The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server. It adds any other appropriate options, including one or more IA options ๐.
The client MUST include an Elapsed Time option (see Section 21.9) to show how long it's been trying to finish the current DHCP message exchange โณ.
For IAs that have leases assigned, the client includes a matching IA option with an IA Address option for each address assigned to the IA, and an IA Prefix option for each prefix assigned to the IA ๐ธ. The client MUST NOT include addresses and prefixes in any IA option that it didn't get from the server, or that are no longer valid (the ones with a valid lifetime of 0). Not me putting expired stuff in there ๐ โโ๏ธ.
The client MAY include an IA option for each binding it wants but hasn't been able to get. In that case, if the client includes the IA_PD option to ask for prefix delegation, it MAY include the IA Prefix option inside the IA_PD option, with the "IPv6-prefix" field set to 0 and the "prefix-length" field set to the length of prefix it'd like delegated ๐ง. The server MAY use that value as a hint for the prefix length. The client SHOULD NOT include an IA Prefix option with the "IPv6-prefix" field set to 0 unless it's giving a hint for the prefix length ๐.
The client includes an Option Request option (see Section 21.7) to ask for the SOL_MAX_RT option (see Section 21.24) and any other options it's interested in getting back. The client MAY include options with data values as hints to the server about the parameter values it would like returned ๐.
The client sends the message according to Section 15, using these parameters:
- IRT:
REN_TIMEOUT - MRT:
REN_MAX_RT - MRC:
0 - MRD: Remaining time until earliest T2
The message exchange ends when the earliest time T2 is reached. While the client is responding to a Reconfigure, it ignores and discards any extra Reconfigure messages it might get ๐. The message exchange ends when the earliest time T2 is reached, and then the client starts the Rebind message exchange (see Section 18.2.5) ๐ฆ.
18.2.5. Creation and Transmission of Rebind Messages โจ
at time T2 (which only happens if the server the Renew message went to, starting at time T1, hasn't responded), the client starts a Rebind/Reply message exchange with any available server ๐.
A Rebind is also used to verify delegated prefix bindings, just with different retransmission parameters, as described in Section 18.2.3 ๐.
The client builds the Rebind message the way Section 18.2.4 describes, with these differences:
- The client sets the
msg-typefield toREBIND. - The client does not include the Server Identifier option (see Section 21.3) in the Rebind message.
The client sends the message according to Section 15, using these parameters:
- IRT:
REB_TIMEOUT - MRT:
REB_MAX_RT - MRC:
0 - MRD: Remaining time until valid lifetimes of all leases in all IAs have expired
If all leases for an IA have expired, the client may choose to include that IA in later Rebind messages to show it's still interested in getting leases assigned to that IA ๐ง.
The message exchange ends when the valid lifetimes of all leases across all IAs have expired. At that point, the client uses the Solicit message to find a new DHCP server and sends a Request for the expired IAs to the new server ๐. If the Rebind exchange that just ended was started because the client got a Reconfigure message, the client ends the reconfigure process and carries on as if that Reconfigure message never arrived ๐ซถ.
18.2.6. Creation and Transmission of Information-request Messages ๐ง
the client uses an Information-request message to get configuration information without asking for any addresses and/or delegated prefixes to be assigned ๐ .
The client sets the msg-type field to INFORMATION-REQUEST. It generates a transaction ID and puts it in the transaction-id field ๐.
The client SHOULD include a Client Identifier option (see Section 21.2) to identify itself to the server. (Hmm, there can be reasons a client doesn't want this option, so see Section 4.3.1 of [RFC7844] ๐.) If the client doesn't include a Client Identifier option, the server won't be able to send back any client-specific options, or it may choose not to respond to the message at all ๐ญ.
The client MUST include an Elapsed Time option (see Section 21.9) to show how long it's been trying to finish the current DHCP message exchange โณ.
The client MUST include an Option Request option (see Section 21.7) to ask for the INF_MAX_RT option (see Section 21.25), the Information Refresh Time option (see Section 21.23), and any other options it's interested in getting. The client MAY include options with data values as hints to the server about the parameter values it would like returned ๐.
When responding to a Reconfigure, the client MUST include a Server Identifier option (see Section 21.3) carrying the identifier from the Reconfigure message it's responding to ๐.
The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. The client sends the message according to Section 15, using these parameters:
- IRT:
INF_TIMEOUT - MRT:
INF_MAX_RT - MRC:
0 - MRD:
0
18.2.7. Creation and Transmission of Release Messages ๐ฆ
Okay so, when a client wants to give back one or more leases, it sends a Release message to the server ๐. The client sets the msg-type field to RELEASE. It generates a transaction ID and drops that value into the transaction-id field ๐.
The client MUST include a Server Identifier option (see Section 21.3) in the Renew message, identifying the server that allocated the lease(s).
The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server ๐ซถ.
The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange โฑ๏ธ.
The client puts options containing the IAs for the leases it is releasing into the options field. The leases to be released MUST be included in the IAs. Any leases for the IAs the client wishes to keep using MUST NOT be added to the IAs ๐ซ.
The client MUST stop using all of the leases being released before it begins the Release message exchange process. For an address, this means the address MUST have been removed from the interface. For a delegated prefix, this means the prefix MUST have been advertised with a Preferred Lifetime and a Valid Lifetime of 0 in a Router Advertisement message as described in part (e) of Section 5.5.3 of [RFC4862]; also see requirement L-13 in Section 4.3 of [RFC7084] ๐.
The client MUST NOT use any of the addresses it is releasing as the source address in the Release message or in any subsequently transmitted message. Main character energy means letting go fully ๐ .
Because Release messages may get lost, the client should retransmit the Release if no Reply is received. However, there are scenarios where the client may not want to wait for the normal retransmission timeout before giving up (for example, on power down) ๐. Implementations SHOULD retransmit one or more times but MAY choose to terminate the retransmission procedure early.
The client transmits the message according to Section 15, using the following parameters:
- IRT:
REL_TIMEOUT - MRT:
0 - MRC:
REL_MAX_RC - MRD:
0
If leases are released but the Reply from a DHCP server is lost, the client will retransmit the Release message, and the server may respond with a Reply indicating a status of NoBinding. Therefore, the client does not treat a Reply message with a status of NoBinding in a Release message exchange as if it indicates an error ๐.
Note that if the client fails to release the lease, each lease assigned to the IA will be reclaimed by the server when the valid lifetime of that lease expires โณ.
18.2.8. Creation and Transmission of Decline Messages ๐ฉ
If a client detects that one or more addresses assigned to it by a server are already in use by another node, the client sends a Decline message to the server to say that the address is suspect ๐.
The Decline message is not used in prefix delegation, so the client MUST NOT include IA_PD options (see Section 21.21) in the Decline message. Not me putting PD in a Decline ๐ โโ๏ธ.
The client sets the msg-type field to DECLINE. It generates a transaction ID and places this value in the transaction-id field ๐ธ.
The client MUST include a Server Identifier option (see Section 21.3) in the Decline message, identifying the server that allocated the lease(s).
The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server.
The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange.
The client puts options containing the IAs for the addresses it is declining into the options field. The addresses to be declined MUST be included in the IAs. Any addresses for the IAs the client wishes to keep using should not be added to the IAs.
The client MUST NOT use any of the addresses it is declining as the source address in the Decline message or in any subsequently transmitted message ๐ซ.
The client transmits the message according to Section 15, using the following parameters:
- IRT:
DEC_TIMEOUT - MRT:
0 - MRC:
DEC_MAX_RC - MRD:
0
If addresses are declined but the Reply from a DHCP server is lost, the client will retransmit the Decline message, and the server may respond with a Reply indicating a status of NoBinding. Therefore, the client does not treat a Reply message with a status of NoBinding in a Decline message exchange as if it indicates an error ๐.
The client SHOULD NOT send a Release message for other bindings it may have received just because it sent a Decline message. The client SHOULD retain the non-conflicting bindings. The client SHOULD treat the failure to acquire a binding (due to the conflict) as equivalent to not having received the binding, insofar as how it behaves when sending Renew and Rebind messages ๐ง.
18.2.9. Receipt of Advertise Messages ๐จ
Upon receipt of one or more valid Advertise messages, the client selects one or more Advertise messages based on the following criteria โจ.
- Those Advertise messages with the highest server preference value SHOULD be preferred over all other Advertise messages. The client MAY choose a less preferred server if that server has a better set of advertised parameters, such as the available set of IAs, as well as the set of other configuration options advertised ๐.
- Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client.
Once a client has selected Advertise message(s), it will typically store information about each server, such as the server preference value, the addresses advertised, when the advertisement was received, and so on ๐๏ธ.
In practice, this means that the client will maintain independent per-IA state machines for each selected server ๐ฆพ.
If the client needs to select an alternate server because a chosen server does not respond, the client chooses the next server according to the criteria given above ๐.
The client MUST process any SOL_MAX_RT option (see Section 21.24) and INF_MAX_RT option (see Section 21.25) present in an Advertise message, even if the message contains a Status Code option (see Section 21.13) indicating a failure, and the Advertise message will be discarded by the client. A client SHOULD only update its SOL_MAX_RT and INF_MAX_RT values if all received Advertise messages that contained the corresponding option specified the same value; otherwise, it should use the default value (see Section 7.6) ๐ฏ.
The client MUST ignore any Advertise message that contains no addresses (IA Address options (see Section 21.6) encapsulated in IA_NA options (see Section 21.4)) and no delegated prefixes (IA Prefix options (see Section 21.22) encapsulated in IA_PD options (see Section 21.21)), with the exception that the client:
- MUST process an included SOL_MAX_RT option and
- MUST process an included INF_MAX_RT option.
A client can record any associated status message(s) in an activity log or display them to the user ๐.
The client ignoring an Advertise message MUST NOT restart the Solicit retransmission timer โธ๏ธ.
18.2.10. Receipt of Reply Messages ๐
Upon the receipt of a valid Reply message in response to a Solicit with a Rapid Commit option (see Section 21.14), Request, Confirm, Renew, Rebind, or Information-request message, the client extracts the top-level Status Code option (see Section 21.13) if present ๐.
The client MUST process any SOL_MAX_RT option (see Section 21.24) and INF_MAX_RT option (see Section 21.25) present in a Reply message, even if the message contains a Status Code option indicating a failure ๐.
If the client receives a Reply message with a status code of UnspecFail, the server is saying that it could not process the client's message because of an unspecified failure condition ๐ญ. If the client retransmits the original message to the same server to retry the desired operation, the client MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message (see Section 14.1). Slow down, bestie ๐ข.
Otherwise (no status code or another status code), the client processes the Reply as described below, based on the original message for which the Reply was received ๐งฉ.
The client MAY choose to report any status code or message from the Status Code option in the Reply message ๐ฃ.
The topic of revoking previously assigned options is discussed in Section 18.2.10.5 ๐ฎ.
When a client receives a requested option that has an updated value from what was previously received, the client SHOULD make use of that updated value as soon as possible for its configuration information โจ๐.
18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind โจ
okay bestie, if the client gets a NotOnLink status from the server after sending a Solicit (with a Rapid Commit option, see Section 21.14) or a Request, it has two options ๐
. It can reissue the message without naming any addresses, or it can restart the DHCP server discovery process (see Section 18 or Section 18.2.13).
If the Reply came back in response to a Solicit (with a Rapid Commit option), Request, Renew, or Rebind message, the client updates what it has recorded about IAs using the IA options in the Reply ๐:
- Calculate T1 and T2 times (based on the T1 and T2 values sent in the message and the message reception time), if that's appropriate for the IA type.
- Add any new leases in the IA option to the IA as the client has recorded it.
- Update lifetimes for any leases in the IA option that the client already has recorded in the IA.
- Discard any leases from the IA, as the client has recorded it, that have a valid lifetime of 0 in the IA Address or IA Prefix option.
- Leave unchanged any information about leases the client has recorded in the IA but that weren't included in the IA from the server.
If the client can operate with the addresses and/or prefixes it got from the server ๐ฆ:
- The client uses the addresses, delegated prefixes, and other information from any IAs that don't contain a Status Code option with the
NoAddrsAvailorNoPrefixAvailstatus code. The client MAY include the IAs that gotNoAddrsAvailorNoPrefixAvail, with no addresses or prefixes, in later Renew and Rebind messages sent to the server, so it can retry getting addresses or prefixes for those IAs. - The client MUST perform duplicate address detection as per Section 5.4 of [RFC4862], which does list some exceptions, on each of the received addresses in any IAs where it hasn't already performed duplicate address detection while processing a previous Reply from the server. The client does this duplicate address detection before using the received addresses for any traffic. If any of the addresses are found to be in use on the link, the client sends a Decline message to the server for those addresses, as described in Section 18.2.8.
- For each assigned address that doesn't have any associated reachability information (see the definition of "on-link" in Section 2.1 of [RFC4861]), the client MUST NOT assume that any addresses are reachable on-link just because it received an IA Address option (see Section 21.6). This is to avoid the problems described in [RFC4943]. Addresses obtained from an IA Address option MUST NOT be used to form an implicit prefix with a length other than 128.
- For each delegated prefix, the client assigns a subnet to each of the links that the associated interfaces are attached to.
When a client subnets a delegated prefix, it has to add extra bits to the prefix to make unique, longer prefixes ๐ธ. For example, if the client in Figure 1 were delegated 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2001:db8:0:2::/64 for assignment to the two links in the subscriber network. If the client were delegated 2001:db8:0::/48 and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 2001:db8:5:2::/64 to the other link.
If the client uses a delegated prefix to configure addresses on interfaces on itself or on other nodes behind it, the preferred and valid lifetimes of those addresses MUST be no longer than the remaining preferred and valid lifetimes, respectively, for the delegated prefix at any time. In particular, if the delegated prefix or a prefix derived from it is advertised for stateless address autoconfiguration [RFC4862], the advertised preferred and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix. ๐ซถ
Management of the specific configuration information is detailed in the definition of each option in Section 21.
If the Reply message contains any IAs but the client finds no usable addresses and/or delegated prefixes in any of them, the client may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to get other configuration information only ๐ง.
When the client receives a Reply message in response to a Renew or Rebind message, the client:
- Sends a Request message to the server that responded if any of the IAs in the Reply message contain the
NoBindingstatus code. The client puts IA options in this message for all IAs. The client keeps using other bindings for which the server didn't return an error. - Sends a Renew/Rebind if any of the IAs aren't in the Reply message. But this likely means the responding server doesn't support that IA type, so sending right away is unlikely to get a different result. Therefore, the client MUST rate-limit its transmissions (see Section 14.1) and MAY just wait for the normal retransmission time (as if the Reply message had never been received). The client keeps using other bindings for which the server did return information.
- Otherwise accepts the information in the IA.
18.2.10.2. Reply for Release and Decline
When the client receives a valid Reply message in response to a Release message, the client considers the Release event completed, no matter what Status Code option (see Section 21.13) the server returned ๐.
When the client receives a valid Reply message in response to a Decline message, the client considers the Decline event completed, no matter what Status Code option(s) the server returned.
18.2.10.3. Reply for Confirm
If the client receives any Reply messages that indicate a status of Success (explicit or implicit), the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status. When the client only receives one or more Reply messages with the NotOnLink status in response to a Confirm message, the client performs DHCP server discovery as described in Section 18.
18.2.10.4. Reply for Information-request
Refer to Section 21.23 for details on how the Information Refresh Time option (whether or not it's present in the Reply) should be handled by the client ๐.
18.2.10.5. Revoking Previously Provided Options
When a client receives a Reply for a Renew, Rebind, or Information-Request that doesn't include a requested configuration option it previously received in a Reply, the client SHOULD stop using the previously received configuration information. In other words, the client should act as if it never got this configuration option, and go back to the relevant default state. If there's no viable way to stop using the received configuration information, the values received or configured from the option MAY persist if there are no other sources for that data and they have no external impact. For example, a client that previously received a Client FQDN option (see [RFC4704]) and used it to set up its hostname is allowed to keep using it if there's no reasonable way for a node to unset its hostname and it has no external impact. As a counterexample, a client that previously received an NTP server address from the DHCP server and no longer receives it MUST stop using the configured NTP server address ๐. The client SHOULD be open to other sources of the same configuration information. This behavior does not apply to any IA options; their processing is described in Section 18.2.10.1.
18.2.11. Receipt of Reconfigure Messages
A client receives Reconfigure messages sent to UDP port 546 on interfaces for which it has acquired configuration information through DHCP. These messages may be sent at any time. Since the results of a reconfiguration event may affect application-layer programs, the client SHOULD log these events and MAY notify those programs of the change through an implementation-specific interface ๐.
The message MUST be dropped if it doesn't pass the validation explained in Section 16.11, especially in cases where the authentication is missing or fails ๐.
When a valid Reconfigure message arrives, the client responds with a Renew message, a Rebind message, or an Information-request message, as indicated by the Reconfigure Message option (see Section 21.19). The client ignores the "transaction-id" field in the received Reconfigure message. While the transaction is in progress, the client discards any Reconfigure messages it receives.
The Reconfigure message is basically a trigger that tells the client to finish a successful message exchange. Once the client has received a Reconfigure, it goes ahead with the message exchange (retransmitting the Renew, Rebind, or Information-request message if necessary). The client MUST ignore any additional Reconfigure messages until the exchange is complete ๐ฅ.
Duplicate messages get ignored, because the client starts the exchange after receiving the first Reconfigure. Retransmitted messages will either (1) trigger the exchange (if the client never received the first Reconfigure) or (2) be ignored. The server MAY stop retransmitting Reconfigure messages to the client once the server receives the Renew, Rebind, or Information-request message from the client.
It's possible that a duplicate or retransmitted Reconfigure gets delayed enough (and delivered out of order) that it reaches the client after the exchange started by the original Reconfigure is already done. In that case, the client would start a redundant exchange. The chance of delayed and out-of-order delivery is small enough to ignore. The result of the redundant exchange is inefficiency rather than incorrect operation ๐ง.
18.2.12. Refreshing Configuration Information โจ
okay so whenever a client might have moved to a new link, the prefixes and addresses on its interfaces might not fit anymore ๐ญ it's like wearing last season's outfit to a totally different party. Examples of times a client may have moved to a new link:
- The client reboots (and has stable storage and persistent DHCP state).
- The client is reconnected to a link on which it has obtained leases.
- The client returns from sleep mode.
- The client changes access points (e.g., if using Wi-Fi technology).
- The client's network interface indicates a disconnection event followed by a connection event.
Specific algorithms for detecting network attachment changes are out of scope for this document ๐ (not our problem here, bestie). Two possible mechanisms for detecting situations where refreshing configuration information may be needed are defined in [RFC6059] and [RFC4957].
When the client detects that it may have moved to a new link and it has obtained addresses and no delegated prefixes from a server, the client SHOULD initiate a Confirm/Reply message exchange. The client MUST include any IAs assigned to the interface that may have moved to a new link, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate whether those addresses are appropriate for the link to which the client is attached with the status in the Reply message it returns to the client. ๐ซถ
If the client has any valid delegated prefixes obtained from the DHCP server, the client MUST initiate a Rebind/Reply message exchange as described in Section 18.2.5, with the exception that the retransmission parameters should be set as for the Confirm message (see Section 18.2.3). The client includes IA_NAs and IA_PDs, along with the associated leases, in its Rebind message. ๐
If the client has only obtained network information using Information-request/Reply message exchanges, the client MUST initiate an Information-request/Reply message exchange as described in Section 18.2.6.
If the client has not detected having moved to a new link but has detected a significant change regarding the prefixes available on the link, the client SHOULD initiate one of the Renew/Reply, Confirm/Reply, or Information-request/Reply exchanges. A change is considered significant when one or more on-link prefixes are added and/or one or more existing on-link prefixes are deprecated. The reason for this is that such a significant change may indicate a configuration change at the server. However, a client MUST rate-limit such initiation attempts to avoid flooding a server with requests when there are link issues (for example, only doing one of these at most every 30 seconds). Main character energy, but make it responsible ๐ง
The above selection of an exchange to initiate depends on the client's current state:
- If the client has any valid delegated prefixes obtained from the server, it sends Renew (as if the T1 time expired) as described in Section 18.2.4.
- Else, if the client obtained an address(es) from the server, it sends Confirm as described in Section 18.2.3.
- Else, if only network information was obtained from the server, it sends an Information-request as described in Section 18.2.6.
18.2.13. Restarting Server Discovery Process ๐ธ
Whenever a client restarts the DHCP server discovery process or selects an alternate server as described in Section 18.2.9, the client SHOULD stop using any addresses and delegated prefixes for which it has bindings (see Section 18.2.7) and, if possible, any other configuration information it previously received. The client SHOULD also try to obtain new bindings and other configuration information from a new server for the same interface. This facilitates the client using a single state machine for all bindings. It's giving clean slate, iykyk ๐งผ
18.3. Server Behavior โจ
For this discussion, the server is assumed to have been configured in an implementation-specific manner with configurations of interest to clients. Think of the server as the one who's been prepped for the party ๐
A server sends an Advertise message in response to each valid Solicit message it receives to announce the availability of the server to the client. Basically the server going "hi, I'm here, I'm available" ๐
In most cases, the server will send a Reply in response to Request, Confirm, Renew, Rebind, Decline, Release, and Information-request messages sent by a client. The server will also send a Reply in response to a Solicit with a Rapid Commit option (see Section 21.14) when the server is configured to respond with committed lease assignments. โจ
These Advertise and Reply messages MUST always contain the Server Identifier option (see Section 21.3) containing the server's DUID and the Client Identifier option (see Section 21.2) from the client message if one was present. No skipping this one, periodt ๐
In most response messages, the server includes options containing configuration information for the client. The server must be aware of the recommendations on message sizes and the use of fragmentation as discussed in Section 5 of [RFC8200]. If the client included an Option Request option (see Section 21.7) in its message, the server includes options in the response message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. ๐
Any message sent from a client may arrive at the server encapsulated in one or more Relay-forward messages. The server MUST use the received message to construct the proper Relay-reply message to allow the response to the received message to be relayed through the same relay agents (in reverse order) as the original client message; see Section 19.3 for more details. The server may also need to record this information with each client in case it is needed to send a Reconfigure message at a later time, unless the server has been configured with addresses that can be used to send Reconfigure messages directly to the client (see Section 18.3.11). Note that servers that support leasequery [RFC5007] also need to record this information. Relay agents are the middle people here, and the server has to remember the route ๐ฆ
By sending Reconfigure messages, the server MAY initiate a configuration exchange to cause DHCP clients to obtain new addresses, prefixes, and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered or when other configuration options are updated, perhaps because servers are moved, added, or removed. Server going "surprise, new outfit!" ๐
When a client receives a Reconfigure message from the server, the client initiates sending a Renew, Rebind, or Information-request message as indicated by msg-type in the Reconfigure Message option (see Section 21.19). The server sends IAs and/or other configuration information to the client in a Reply message. The server MAY include options containing the IAs and new values for other configuration parameters in the Reply message, even if those IAs and parameters were not requested in the client's message. Extra helpful, not even asked ๐
18.3.1. Receipt of Solicit Messages ๐
The server determines the information about the client and its location as described in Section 13 and checks its administrative policy about responding to the client. If the server is not permitted to respond to the client, the server discards the Solicit message. For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see Section 21.20) in the Solicit message, the server discards the Solicit message. Bouncer energy, not on the list, not coming in ๐ซ
If (1) the server is permitted to respond to the client, (2) the client has not included a Rapid Commit option (see Section 21.14) in the Solicit message, or (3) the server has not been configured to respond with committed assignments of leases and other resources, the server sends an Advertise message to the client as described in Section 18.3.9.
If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond with committed assignments of leases and other resources, the server responds to the Solicit with a Reply message. The server produces the Reply message as though it had received a Request message as described in Section 18.3.2. The server transmits the Reply message as described in Section 18.3.10. The server MUST commit the assignment of any addresses and delegated prefixes or other configuration information before sending a Reply message to a client. In this case, the server includes a Rapid Commit option in the Reply message to indicate that the Reply is in response to a Solicit message. Skip the waiting room, straight to the VIP section ๐
DISCUSSION: - When using the Solicit/Reply message exchange, the server commits the assignment of any leases before sending the Reply message. The client can assume that it has been assigned the leases in the Reply message and does not need to send a Request message for those leases. Commitment is the whole vibe here ๐ฅ - Typically, servers that are configured to use the Solicit/Reply message exchange will be deployed so that only one server will respond to a Solicit message. If more than one server responds, the client will only use the leases from one of the servers, while the leases from the other servers will be committed to the client but not used by the client. Two servers replying is a whole group chat mess ๐
18.3.2. Receipt of Request Messages โจ
Okay so when the server gets a valid Request message, it creates the bindings for that client based on its policy and configuration info, and it records the IAs and other info the client asked for ๐
The server builds a Reply message by setting the msg-type field to REPLY and copying the transaction ID from the Request message into the transaction-id field ๐
The server MUST include in the Reply message a Server Identifier option (see Section 21.3) containing the server's DUID, plus the Client Identifier option (see Section 21.2) from the Request message. Non-negotiable, bestie ๐
Next, the server checks out all the IAs in the message from the client ๐
For each IA_NA option (see Section 21.4) in the Request message, the server checks whether the prefixes of the included addresses are appropriate for the link the client is connected to. If any of those prefixes are not appropriate, the server MUST return the IA to the client with a Status Code option (see Section 21.13) holding the value NotOnLink ๐ If the server doesn't send the NotOnLink status code but still can't assign any IP addresses to an IA, the server MUST return the IA option in the Reply message with no addresses in the IA, and a Status Code option containing the status code NoAddrsAvail in the IA ๐
For any IA_PD option (see Section 21.21) in the Request message that the server can't give any delegated prefixes to, the server MUST return the IA_PD option in the Reply message with no prefixes in the IA_PD, and a Status Code option containing the status code NoPrefixAvail in the IA_PD ๐ธ
The server MAY assign different addresses and/or delegated prefixes to an IA than the ones included in the IA of the client's Request message. Plot twist, it's allowed ๐ฆ
For all the IAs the server CAN assign addresses or delegated prefixes to, the server includes the IAs with addresses (for IA_NAs), prefixes (for IA_PDs), and other configuration parameters, and records the IA as a new client binding โจ The server MUST NOT include any addresses or delegated prefixes in the IA that it doesn't assign to the client. No sneaky extras, periodt ๐
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. Why? Because this lets the client renew all of its bindings at the same time, and that's so iconic ๐
The server SHOULD include a Reconfigure Accept option (see Section 21.20) if the server policy enables the reconfigure mechanism and the client supports it. Lowkey, sending this option in a Reply is technically redundant right now, because using the reconfiguration mechanism requires authentication. At present, the only defined mechanism is RKAP (see Section 20.4), and the presence of the reconfigure key is what signals support for accepting Reconfigure messages. But there may be better security mechanisms defined in the future that would make RKAP not be used anymore ๐๐ง
The server includes other options holding configuration information to be returned to the client, as described in Section 18.3 ๐
If the server finds that the client included an IA in the Request message for which the server already has a binding that links that IA to the client, the server sends a Reply message with the existing bindings, possibly with updated lifetimes. The server MAY update the bindings according to its local policies, but the server SHOULD generate the response again instead of simply retransmitting previously sent information, even if the transaction-id field value matches a previous transmission. The server MUST NOT cache its responses. Not even a little bit ๐
โโ๏ธ
DISCUSSION:
- Cached replies are bad because lifetimes need to be updated, either by decreasing the timers by the amount of time that passed since the original transmission, or by keeping the lifetime values and updating the lease information in the server's database. Also, if the message uses any security protection (such as the Replay Detection Method (RDM), as described in Section 20.3), its value must be updated. Additionally, any digests must be updated. Given all of the above, caching replies is way more complex than just sending the same buffer as before, and it's super easy to miss some of those steps ๐๐
18.3.3. Receipt of Confirm Messages ๐
When the server receives a Confirm message, it figures out whether the addresses in the Confirm message are appropriate for the link the client is attached to. If all of the addresses pass this test, the server returns a status of Success ๐ If any of the addresses don't pass, the server returns a status of NotOnLink ๐ If the server can't perform this test (for example, it doesn't have info about the prefixes on the client's link), or there were no addresses in any of the IAs the client sent, the server MUST NOT send a Reply to the client. Radio silence, bestie ๐คซ
The server ignores the T1 and T2 fields in the IA options, and the preferred-lifetime and valid-lifetime fields in the IA Address options (see Section 21.6). Not its problem rn ๐
The server builds a Reply message by setting the msg-type field to REPLY and copying the transaction ID from the Confirm message into the transaction-id field ๐
The server MUST include in the Reply message a Server Identifier option (see Section 21.3) containing the server's DUID, plus the Client Identifier option (see Section 21.2) from the Confirm message. The server includes a Status Code option (see Section 21.13) that indicates the status of the Confirm message โจ
18.3.4. Receipt of Renew Messages ๐
For each IA in the Renew message from a client, the server locates the client's binding and verifies that the info in the IA from the client matches the info stored for that client ๐ต๏ธโโ๏ธ
If the server finds the client entry for the IA, it sends the IA back to the client with new lifetimes and, if applicable, T1/T2 times. If the server can't extend the lifetimes of an address or delegated prefix in the IA, the server MAY choose not to include the IA Address option (see Section 21.6) for that address, or the IA Prefix option (see Section 21.22) for that delegated prefix. If the server does choose to include the IA Address or IA Prefix option for such an address or delegated prefix, the server SHOULD set the T1 and T2 values to the valid lifetime for the IA option, unless the server also includes other addresses or delegated prefixes that it is able to extend for the IA. Setting T1 and T2 equal to the valid lifetime tells the client that the leases for that IA won't be extended, so there's no point in trying ๐ It also avoids generating unnecessary traffic as the remaining lifetime approaches 0 ๐ซถ
The server may choose to change the list of addresses or delegated prefixes, and the lifetimes, in the IAs returned to the client ๐ฆ
If the server finds that any of the addresses in the IA are not appropriate for the link the client is attached to, the server returns that address to the client with lifetimes of 0 ๐
If the server finds that any of the delegated prefixes in the IA are not appropriate for the link the client is attached to, the server returns that delegated prefix to the client with lifetimes of 0 ๐
For each IA the server can't find a client entry for, the server has the following choices, depending on its policy and configuration info:
- If the server is configured to create new bindings as a result of processing Renew messages, the server SHOULD create a binding and return the IA with assigned addresses or delegated prefixes, with lifetimes and, if applicable, T1/T2 times and other info the client requested. If the client included the IA Prefix option within the IA_PD option (see Section 21.21) with a zero value in the
IPv6-prefixfield and a non-zero value in theprefix-lengthfield, the server MAY use theprefix-lengthvalue as a hint for the length of the prefixes to be assigned (see [RFC8168] for further details on prefix-length hints) ๐ - If the server is configured to create new bindings as a result of processing Renew messages, but the server won't assign any leases to an IA, the server returns the IA option containing a Status Code option (see Section 21.13) with the
NoAddrsAvailorNoPrefixAvailstatus code, plus a status message for a user ๐ฅบ - If the server doesn't support creating new bindings for the client sending a Renew message, or if this behavior is disabled according to the server's policy or configuration info, the server returns the IA option containing a Status Code option with the
NoBindingstatus code, plus a status message for a user ๐ โโ๏ธ
The server builds a Reply message by setting the msg-type field to REPLY and copying the transaction ID from the Renew message into the transaction-id field ๐
The server MUST include in the Reply message a Server Identifier option (see Section 21.3) containing the server's DUID, plus the Client Identifier option (see Section 21.2) from the Renew message ๐
The server includes other options holding configuration information to be returned to the client, as described in Section 18.3 ๐ธ
The server MAY include options containing the IAs and values for other configuration parameters, even if those parameters weren't requested in the Renew message. Extra love, no cap ๐
The T1/T2 values set in each applicable IA option for a Reply MUST be the same across all IAs. The server MUST determine the T1/T2 values across all of the applicable client's bindings in the Reply. This helps the client renew all of its bindings at the same time, which is honestly the main character move ๐ฆโจ
18.3.5. Receipt of Rebind Messages ๐
okay so, the server gets a Rebind message with an IA option from a client, and the first thing it does is hunt down that client's binding and check that the IA info matches what it has stored for them. bestie, this is the vibe check ๐
If the server finds the client entry for the IA and decides the addresses or delegated prefixes are still appropriate for the client's link according to its explicit configuration, the server SHOULD send the IA back with new lifetimes and, if applicable, T1/T2 values ๐ฆ If the server can't extend the lifetime of an address in the IA, it MAY choose not to include the IA Address option (see Section 21.6) for that address. And if it can't extend a delegated prefix's lifetime, it MAY skip the IA Prefix option (see Section 21.22) for that prefix. ๐ธ
If the server finds that the client entry for the IA and any of the addresses or delegated prefixes are no longer appropriate for the link, the server returns those addresses or delegated prefixes with lifetimes of 0. ๐ That's giving "you're out, bestie" energy ๐
If the server can't find a client entry for the IA, it checks whether the IA contains addresses (for IA_NAs) or delegated prefixes (for IA_PDs) โจ It then checks whether those addresses and delegated prefixes are appropriate for the client's link according to its explicit configuration. For any address that isn't appropriate, the server MAY include the IA Address option with lifetimes of 0. For any delegated prefix that isn't appropriate, the server MAY include the IA Prefix option with lifetimes of 0. ๐ง A Reply with lifetimes of 0 is an explicit notification to the client that those specific addresses and delegated prefixes are no longer valid, so the client MUST NOT use them ๐ซ If the server decides to leave out every IA containing IA Address or IA Prefix options with lifetimes of 0, and it doesn't include any other IAs with leases and/or status codes, the server does not send a Reply message. In that case it just discards the Rebind message ๐
Otherwise, for each IA where the server can't find a client entry, the server has the following options, depending on its policy and configuration information ๐
* If the server is configured to create new bindings when it processes Rebind messages (also see the note below about the Rapid Commit option (Section 21.14)), the server SHOULD create a binding and return the IA with allocated leases, lifetimes, and, if applicable, T1/T2 values, plus any other info the client asked for. The server MUST NOT return any addresses or delegated prefixes in the IA that it didn't assign to the client. ๐
* If the server is configured to create new bindings when it processes Rebind messages but won't assign any leases to an IA, the server returns the IA option with a Status Code option (see Section 21.13) that has the NoAddrsAvail or NoPrefixAvail status code, along with a status message for a user. ๐
* If the server doesn't support creating new bindings for the client sending the Rebind message, or this behavior is turned off by policy or configuration, the server returns the IA option with a Status Code option containing the NoBinding status code and a status message for a user. ๐
When the server creates new bindings for the IA, other servers might also create bindings from the same Rebind message. Check the "DISCUSSION" text in Section 21.14 for the deets ๐ So the server SHOULD only create new bindings while processing a Rebind message if it's configured to respond with a Reply message to a Solicit message containing the Rapid Commit option โจ
The server builds the Reply by setting the "msg-type" field to REPLY and copying the transaction ID from the Rebind message into the "transaction-id" field ๐
The server MUST include a Server Identifier option (see Section 21.3) holding the server's DUID in the Reply, along with the Client Identifier option (see Section 21.2) from the Rebind message ๐ซถ
The server includes other options with configuration info to send back to the client, as described in Section 18.3 ๐ธ
The server MAY include options with the IAs and values for other configuration parameters, even if the client didn't ask for them in the Rebind message ๐ฆ
The T1 or T2 values set in each applicable IA option for a Reply MUST be the same across all IAs. The server MUST work out the T1 or T2 values across all of the client's applicable bindings in the Reply. That way the client can renew all of its bindings at the same time ๐ฅ
18.3.6. Receipt of Information-request Messages ๐ง
so when the server gets an Information-request message, the client just wants configuration info, no lease assignments involved ๐ The server figures out every configuration parameter that fits this client, based on the server configuration policies it knows about ๐
The server builds the Reply by setting the "msg-type" field to REPLY and copying the transaction ID from the Information-request message into the "transaction-id" field ๐
The server MUST include a Server Identifier option (see Section 21.3) with the server's DUID in the Reply. If the client put a Client Identifier option (see Section 21.2) in the Information-request message, the server copies that option into the Reply too ๐ซถ
The server includes options with configuration info to send back to the client, as described in Section 18.3. The server MAY include extra options the client didn't ask for in the Information-request message โจ
If the Information-request message from the client didn't include a Client Identifier option, the server SHOULD respond with a Reply containing any configuration parameters that aren't determined by the client's identity. If the server decides not to respond, the client MAY keep retransmitting the Information-request message indefinitely ๐
18.3.7. Receipt of Release Messages ๐ฆ
The server builds the Reply by setting the "msg-type" field to REPLY and copying the transaction ID from the Release message into the "transaction-id" field ๐
When a valid Release message comes in, the server checks the IAs and the leases in them for validity. If the IAs in the message are in a binding for the client, and the leases in the IAs were assigned by the server to those IAs, the server deletes the leases from the IAs and makes them available for other clients to get ๐ The server ignores leases that weren't assigned to the IAs, though it MAY choose to log an error ๐
After all the leases have been processed, the server generates a Reply that includes a Status Code option (see Section 21.13) with the value Success, a Server Identifier option (see Section 21.3) with the server's DUID, and a Client Identifier option (see Section 21.2) with the client's DUID ๐ For each IA in the Release message that the server has no binding info for, the server adds an IA option using the IAID from the Release message and puts a Status Code option with the value NoBinding in that IA option. No other options go in the IA option ๐
A server MAY keep a record of assigned leases and IAs after their lifetimes have expired, so it can reassign those leases to a client later ๐ธ
18.3.8. Receipt of Decline Messages ๐
When a valid Decline message comes in, the server checks the IAs and the addresses in them for validity. If the IAs in the message are in a binding for the client, and the addresses in the IAs were assigned by the server to those IAs, the server deletes those addresses from the IAs. The server ignores addresses that weren't assigned to the IAs (though it MAY choose to log an error if it finds such addresses) ๐
The client found that the addresses in the Decline messages are already in use on its link. So the server SHOULD mark the declined addresses so they aren't assigned to other clients, and it MAY choose to send a notification that the addresses were declined ๐จ Local policy on the server decides when the addresses in a Decline message can be made available for assignment again โจ
After all the addresses have been processed, the server generates a Reply by setting the "msg-type" field to REPLY and copying the transaction ID from the Decline message into the "transaction-id" field ๐ง It includes a Status Code option (see Section 21.13) with the value Success, a Server Identifier option (see Section 21.3) with the server's DUID, and a Client Identifier option (see Section 21.2) with the client's DUID ๐ For each IA in the Decline message that the server has no binding info for, the server adds an IA option using the IAID from the Decline message and puts a Status Code option with the value NoBinding in that IA option. No other options go in the IA option ๐
18.3.9. Creation of Advertise Messages โจ
okay so this is the part where the server builds its Advertise reply, and bestie, it's giving main character energy ๐
๐ฆ The server sets the msg-type field to ADVERTISE and copies the transaction-id from the Solicit message the client sent. Then it adds its own server identifier in a Server Identifier option (see Section 21.3) and copies the Client Identifier option (see Section 21.2) from the Solicit into the Advertise. Iconic, right? ๐
The server MAY add a Preference option (see Section 21.8) to carry its preference value. The server implementation SHOULD allow the administrator to set that preference value, and the preference value MUST default to 0 unless the server administrator configures something else. ๐ธ
If the server wants to say "hey, I support the Reconfigure mechanism," it includes a Reconfigure Accept option (see Section 21.20). The client might use that when it's picking a server ๐
The server also includes the options it will hand back to the client in a later Reply message. The client can use these options to choose between servers if it gets more than one Advertise. The server MUST include options in the Advertise message with configuration parameters for every option listed in the Option Request option (see Section 21.7) of the Solicit, as long as the server has been set up to return them. If the Option Request option includes a container option, the server MUST include all the options that are allowed to be encapsulated in that container. The Option Request option MAY be used to signal support for a feature even when that option is encapsulated, like with the Prefix Exclude option [RFC6603], and in that case the server needs special processing. The server MAY also return additional options if it's been configured to do so. โจ
Now the IA stuff, which is lowkey the spicy bit ๐ฅ The server MUST include IA options in the Advertise message for any addresses and/or delegated prefixes that would be assigned to the IAs in the Solicit. If the client put addresses in the IA Address options (see Section 21.6) of the Solicit, the server MAY use those as hints about what the client wants. If the client included IA Prefix options (see Section 21.22), the server MAY use the prefix in the IPv6-prefix field and/or the length in the prefix-length field as hints too. But if the server is NOT going to assign an address or delegated prefix that came in as a hint, the server MUST NOT include it in the Advertise message. No sneaky hints allowed ๐
โโ๏ธ๐
If the server won't assign any addresses to an IA_NA in later Request messages, it MUST still include the IA option in the Advertise, with no addresses in it and a Status Code option (see Section 21.13) inside the IA option containing status code NoAddrsAvail. ๐ฅบ
Same vibe for IA_PD: if the server won't assign any prefixes to it in later Request messages, the server MUST include the IA_PD option (see Section 21.21) in the Advertise with no prefixes in it, and a Status Code option inside the IA_PD containing status code NoPrefixAvail. ๐ง
Transmission of Advertise messages is described in the next section, so stay tuned ๐
18.3.10. Transmission of Advertise and Reply Messages ๐ฆ
okay so sending the reply back depends on how the message got to the server ๐ง
If the server got the original message directly, it unicasts the Advertise or Reply straight back to the client, using the source address from the IP datagram the original message came in on. The Advertise or Reply message MUST be unicast through the same interface the original message was received on. Very specific, very important, no cap ๐
If the original message came inside a Relay-forward message, the server builds a Relay-reply message with the Reply message in the payload of a Relay Message option (see Section 21.10). If the Relay-forward message had an Interface-Id option (see Section 21.18), the server copies that option into the Relay-reply too ๐ Then it unicasts the Relay-reply directly to the relay agent, using the source address from the IP datagram the Relay-forward arrived in. For more on building Relay-reply messages, check out Section 19.3 โจ
18.3.11. Creation and Transmission of Reconfigure Messages ๐ฅ
Okay this is the part where the server gets to shake the client awake and say "update your stuff, bestie" ๐
The server sets the msg-type field to RECONFIGURE and sets the transaction-id field to 0. It includes a Server Identifier option (see Section 21.3) with its DUID, and a Client Identifier option (see Section 21.2) with the client's DUID, in the Reconfigure message. ๐
Because DoS attacks against DHCP clients are a real risk, a security mechanism is mandated for Reconfigure messages ๐ญ The server MUST use DHCP authentication in the Reconfigure message (see Section 20.4). No skipping this one, periodt ๐
The server MUST include a Reconfigure Message option (see Section 21.19) to pick whether the client answers with a Renew message, a Rebind message, or an Information-request message. ๐
The server MUST NOT include any other options in the Reconfigure message, except where the definition of a specific option says it's allowed. Strict guest list, honestly iconic ๐
The server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope that belongs to that client. If the server doesn't have an address it can send to directly, it uses a Relay-reply message (as described in Section 19.3) to send the Reconfigure to a relay agent, which will pass it along to the client ๐ฆ The server can figure out the client's address (and the right relay agent, if needed) from what it knows about clients that have contacted it (see Section 18.3), or through some external agent โจ
To reconfigure more than one client, the server unicasts a separate message to each one ๐ธ The server may start reconfiguring multiple clients at the same time. For example, it may send a Reconfigure to more clients while earlier reconfiguration exchanges are still going on ๐ง
The Reconfigure message makes the client start a Renew/Reply, Rebind/Reply, or Information-request/Reply exchange with the server. The server counts receiving a Renew, Rebind, or Information-request message (whichever one the original Reconfigure asked for) from that client as satisfying the Reconfigure request. Mission accomplished ๐
When sending the Reconfigure, the server sets the retransmission time (RT) to REC_TIMEOUT. If the server doesn't get a Renew, Rebind, or Information-request from the client before RT runs out, it retransmits the Reconfigure, doubles the RT value, and waits again. It keeps doing this until REC_MAX_RC unsuccessful attempts have been made, and at that point the server SHOULD abort the reconfigure process for that client. Patience has limits, bestie ๐ญโณ
Default and initial values for REC_TIMEOUT and REC_MAX_RC are documented in Section 7.6. ๐
19. Relay Agent Behavior ๐
The relay agent SHOULD be configured to use a list of destination addresses that includes unicast addresses. The list of destination addresses MAY include the All_DHCP_Servers multicast address or other addresses picked by the network administrator. If the relay agent hasn't been explicitly configured, it MUST use the All_DHCP_Servers multicast address as the default. ๐ซถ
If the relay agent relays messages to the All_DHCP_Servers multicast address or other multicast addresses, it sets the Hop Limit field to 8. ๐ฅ
If the relay agent receives a message other than Relay-forward and Relay-reply, and it doesn't recognize that message type, it MUST forward the message as described in Section 19.1.1. Unknown vibes get forwarded anyway ๐
19.1. Relaying a Client Message or a Relay-forward Message ๐
A relay agent relays both messages from clients and Relay-forward messages from other relay agents. When a relay agent gets a Relay-forward message, a recognized message type it isn't the intended target for, or an unrecognized message type, it builds a new Relay-forward message. It copies the source address from the header of the IP datagram the message came in on into the peer-address field of the new Relay-forward. Then it copies the received DHCP message (minus any IP or UDP headers) into a Relay Message option (see Section 21.10) in the new message. The relay agent also adds any other options it's been configured to include โจ
[RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that lets an access node doing link-layer bridging (so, non-routing) insert relay agent information ๐ฆ
19.1.1. Relaying a Message from a Client ๐
If the relay agent got the message to relay from a client, it puts a globally scoped unicast address (GUA or ULA) from a prefix assigned to the link where the client should get its leases into the link-address field. If it can't get one of those, the relay agent may set the link-address field to a link-local address from the interface the original message arrived on. This is NOT RECOMMENDED, though, because it may mean extra info has to be given in the server configuration. See Section 3.2 of [RFC7969] for a detailed discussion ๐
The server uses this address to figure out which link the client should get leases and other config info from. ๐ธ
The hop-count value in the Relay-forward message is set to 0. ๐ง
The relay SHOULD insert a Client Link-Layer Address option as described in [RFC6939]. ๐
If the relay agent can't use the address in the link-address field to identify the interface where the response to the client will go out, the relay agent MUST include an Interface-Id option (see Section 21.18) in the Relay-forward message. The server will include that Interface-Id option in its Relay-reply message. The relay agent sets the link-address field as described above whether or not it includes an Interface-Id option in the Relay-forward message ๐
19.1.2. Relaying a Message from a Relay Agent โจ
okay so bestie, this one is about what a relay agent does when a Relay-forward message shows up. first check: if the hop-count is already at or past HOP_COUNT_LIMIT, the relay agent has to toss the message ๐๏ธ๐
no exceptions.
if it survives that, the relay agent copies the source address from the IP datagram into the peer-address field, and bumps the hop-count up by 1 ๐ฆ it's like keeping a receipt of every stop the message made.
now the link-address part is kind of the main character moment ๐. if the source address is a globally scoped unicast address (GUA or ULA), the relay agent sets link-address to 0. otherwise, it puts a GUA or ULA that's assigned to the interface where the message came in, OR it includes an Interface-Id option (see Section 21.18) to say which interface it was. either way the server knows where the message came from ๐ง
19.1.3. Relay Agent Behavior with Prefix Delegation ๐ธ
a relay agent handles messages with prefix delegation options the exact same way it handles address stuff. so per Sections 19.1.1 and 19.1.2, no special treatment, no drama ๐
ngl this part is kind of a plot twist ๐ญ if a server talks to a client through a relay about delegated prefixes, the server might need some protocol or other out-of-band communication to set up routing info for those delegated prefixes on any router the client might send traffic through. the relay isn't going to do that for you, babe ๐
19.2. Relaying a Relay-reply Message ๐
the relay agent processes any options in the Relay-reply message, along with the Relay Message option (see Section 21.10) ๐
then it pulls the message out of the Relay Message option and relays it to whatever address is in the peer-address field of the Relay-reply message. relay agents MUST NOT modify the message ๐ซถ hands off, no edits, no glow-ups allowed.
if the Relay-reply has an Interface-Id option (see Section 21.18), the relay agent sends the message from the server to the client on the link that Interface-Id names. otherwise, if link-address isn't 0, the relay agent sends it on the link named by link-address โจ
one last thing ๐ if the relay agent gets a Relay-reply, it MUST process the message as described above, no matter what kind of message is inside the Relay Message option.
19.3. Construction of Relay-reply Messages ๐ฆ
okay this is the server's job. a server uses a Relay-reply message for two things: (1) sending a response back to a client when the original message got relayed to the server in a Relay-forward message, or (2) sending a Reconfigure message to a client when the server doesn't have an address it can use to reach the client directly ๐
a response to the client MUST be relayed through the same relay agents as the original client message. the server makes that happen by building a Relay-reply that has a Relay Message option holding the message for the next relay agent on the way back to the client. that inner Relay-reply has its own Relay Message option for the next relay, and so on, like nesting dolls ๐ช the server must record the contents of the peer-address fields in the received message so it can build the right Relay-reply with the server's response.
here's an example. say client C sends a message, relay agent A relays it to relay agent B, and then it hits the server. the server would send this Relay-reply to relay agent B:
msg-type: RELAY-REPL
hop-count: 1
link-address: 0
peer-address: A
Relay Message option containing the following:
msg-type: RELAY-REPL
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>Figure 10: Relay-reply Example ๐
when the server sends a Reconfigure message to a client through a relay agent, it builds a Relay-reply with a Relay Message option that contains the Reconfigure message for the next relay on the way back to the client. the server sets the peer-address field in the Relay-reply header to the client's address, and it sets link-address however the relay agent needs in order to pass the Reconfigure along to the client. the server gets the addresses of the client and the relay agent through earlier interaction with the client, or through some outside mechanism ๐ฅ
19.4. Interaction Between Relay Agents and Servers ๐
every time a relay agent passes a message toward a server, it wraps the message in a new encapsulation level. each relay can add extra options to the encapsulation level it created, but relays MUST NOT change anything inside the message they're wrapping ๐ โโ๏ธ if there are multiple relays between the client and the server, you get multiple encapsulations. yes it's a little more work to process, BUT the huge win is that you can see clearly which relay added which option ๐ the response is expected to take the same relays, just backwards, and every time it goes back toward the client, one encapsulation level comes off ๐ง
relays can add one or more options in some situations, for a few reasons:
- First, relays can give extra info about the client ๐ต๏ธ that info usually comes from the network infrastructure instead of the client, so a server admin tends to trust it more, since the client can't easily fake it. the server can use these options when it decides what to allocate.
- Second, a relay might need some info to send the response back to the client. relay agents are expected to be stateless (they don't keep any state after processing a message) ๐ซ a relay can include the Interface-Id option (see Section 21.18), and the server echoes it back in the response. it can also add other options and ask the server to echo some of them back too. the relay uses those to deliver the response to the client, or for other stuff. the client never sees these options. see [RFC4994] for details.
- Third, sometimes the relay is the best place to supply values for certain options. a relay can insert an option into the message it forwards to the server and ask the server to send that option back to the client, and then the client will get it. just know the server is the ultimate authority here, and depending on its configuration, it may or may not send that option back to the client ๐ see [RFC6422] for details.
servers sometimes need to keep the relay info even after they're done processing the message. one reason is a bulk leasequery mechanism, which can ask for every address and/or prefix that was assigned through a specific relay. another is the reconfigure mechanism: the server might decide to send a Reconfigure message through relays instead of straight to the client. that behavior counts as an implementation detail and is out of scope for this document ๐ธ
20. Authentication of DHCP Messages ๐
this doc defines two security mechanisms for authenticating DHCP messages: (1) authentication (and encryption) of messages between servers and relay agents using IPsec, and (2) protection against a client getting misconfigured by a Reconfigure message sent from a malicious DHCP server. this part is seriously important, so pay attention ๐จ
20.1. Security of Messages Sent Between Servers and Relay Agents ๐ก๏ธ
relay agents and servers that exchange messages can use IPsec, as detailed in [RFC8213] ๐
20.2. Summary of DHCP Authentication ๐
authentication of DHCP messages happens through the Authentication option (see Section 21.11). the info carried in that option can reliably identify where a DHCP message came from, and confirm that its contents weren't tampered with ๐ต๏ธโโ๏ธ
the Authentication option is a framework for multiple authentication protocols. one of them, RKAP, is defined in Section 20.4. other protocols will be defined in separate documents later ๐ฆ
any DHCP message MUST NOT include more than one Authentication option. one message, one Authentication option, period ๐
the protocol field in the Authentication option tells you which protocol made the authentication info in that option. the algorithm field names a specific algorithm within that protocol. for example, it can say which hash algorithm was used to make the Message Authentication Code (MAC) in the Authentication option. the RDM field says what type of replay detection is used in the replay detection field ๐
20.3. Replay Detection ๐
the RDM field of the Authentication option (see Section 21.11) decides what type of replay detection goes in the replay detection field.
if the RDM field is 0x00, the replay detection field MUST be set to a strictly monotonically increasing 64-bit unsigned integer (modulo 2^64). this technique can help reduce the danger of replay attacks ๐ญ this method MUST be supported by all Authentication option protocols. one option could be the 64-bit NTP timestamp format [RFC5905]).
a client that gets a message with RDM set to 0x00 MUST compare the replay detection field with the previous value sent by that same server (matched by the Server Identifier option; see Section 21.3). it should only accept the message if the new value is greater, and then record it as the new value ๐ if it's the first time a client has processed an Authentication option from a server, the client MUST record the replay detection value and skip the replay detection check.
servers that support the reconfigure mechanism MUST ensure that the replay detection value is kept between restarts. if they don't, clients may refuse Reconfigure messages from the server, which basically makes the reconfigure mechanism useless ๐ so don't skip this one, bestie!!
20.4. Reconfiguration Key Authentication Protocol (RKAP) ๐๏ธ
RKAP protects against a client getting misconfigured by a Reconfigure message sent from a malicious DHCP server. here's how it works: the DHCP server sends the client a reconfigure key during the initial exchange of DHCP messages. the client records that key so it can check later Reconfigure messages from that server. then the server includes a Hashed Message Authentication Code (HMAC), computed from the reconfigure key, in its later Reconfigure messages ๐
both the reconfigure key (sent from server to client) and the HMAC (in later Reconfigure messages) are carried as the authentication info in an Authentication option (see Section 21.11). the format of that info is defined in the next section ๐
RKAP is used (started by the server) only if the client and server have agreed to use Reconfigure messages โจ
20.4.1. Use of the Authentication Option in RKAP ๐
okay so for RKAP, the Authentication option (see Section 21.11) gets these fields set ๐
protocol: 3algorithm: 1RDM: 0
and the authentication information looks like this bestie ๐ฆ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: RKAP Authentication Information ๐ธ
Type: the type of data in the Value field carried in this option ๐
1: Reconfigure key value (used in the Reply message).2: HMAC-MD5 digest of the message (used in the Reconfigure message).
It's a 1-octet field.
Value: the data, as defined by the Type field. It's a 16-octet field. โจ
20.4.2. Server Considerations for RKAP ๐ฅ๏ธ
okay so the server picks a reconfigure key for a client during the Request/Reply, Solicit/Reply, or Information-request/Reply message exchange. Then it records that key and sends it to the client in an Authentication option (see Section 21.11) in the Reply message. ๐
The reconfigure key is 128 bits long and it MUST be a cryptographically strong random or pseudorandom number that cannot easily be predicted. This part is seriously important, no cap ๐ญ๐ฅ
To provide authentication for a Reconfigure message, the server selects a replay detection value according to the RDM selected by the server, then computes an HMAC-MD5 of the Reconfigure message using the reconfigure key for the client. The HMAC-MD5 is computed over the entire DHCP Reconfigure message, including the Authentication option. For that computation, the HMAC-MD5 field in the Authentication option is set to 0. Finally, the server puts the HMAC-MD5 in the authentication information field of an Authentication option, and that option goes in the Reconfigure message sent to the client. ๐ง
20.4.3. Client Considerations for RKAP ๐ฑ
okay so the client gets its reconfigure key from the server in an Authentication option (see Section 21.11) in the initial Reply message. The client records that key so it can authenticate later Reconfigure messages. ๐
To authenticate a Reconfigure message, the client computes an HMAC-MD5 over the Reconfigure message, with zeroes substituted for the HMAC-MD5 field, using the reconfigure key it got from the server. If the computed HMAC-MD5 matches the value in the Authentication option, the client accepts the Reconfigure message. Main character energy โจ๐ซถ
21. DHCP Options ๐
okay so options carry extra information and parameters in DHCP messages. Every option shares a common base format (see Section 21.1), and all values in options are represented in network byte order. ๐
This document specifies the DHCP options that are part of the base DHCP specification. Other options have been or may be defined in the future in separate documents. For guidelines on defining new options, see [RFC7227]. For more about the DHCPv6 "Option Codes" registry that IANA maintains, see Section 24. ๐
Unless otherwise noted, each option may appear only in the options area of a DHCP message, and may appear only once. If an option does appear multiple times, each instance is considered separate, and the data areas of the options MUST NOT be concatenated or otherwise combined. Lowkey the most important rule in this whole section ๐
Options that are only allowed to appear once are called "singleton options". The only non-singleton options defined in this document are the IA_NA (see Section 21.4), Vendor Class (see Section 21.16), Vendor-specific Information (see Section 21.17), and IA_PD (see Section 21.21) options. Also, IA Address (see Section 21.6) and IA Prefix (see Section 21.22) may appear more than once inside their respective IA options. ๐
21.1. Format of DHCP Options ๐งฉ
okay so the format of DHCP options is:
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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Option Format ๐ธ
option-code: an unsigned integer that identifies the specific option type carried in this option. It's a 2-octet field.
option-len: an unsigned integer giving the length of the option-data field in this option, in octets. It's a 2-octet field.
option-data: the data for the option. Its format depends on the definition of the option. It's a variable-length field, and its length in octets is specified by option-len. ๐
DHCP options are scoped by using encapsulation. Some options apply generally to the client, some are specific to an IA, and some are specific to the addresses within an IA. Those last two cases are discussed in Sections 21.4 and 21.6. โจ
21.2. Client Identifier Option ๐ชช
the Client Identifier option carries a DUID (see Section 11) that identifies the client. The format is:
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_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Client Identifier Option Format ๐
option-code: OPTION_CLIENTID (1).
option-len: the length of the DUID, in octets.
DUID: the DUID for the client. ๐ฆ
21.3. Server Identifier Option ๐ฅ๏ธ
the Server Identifier option carries a DUID (see Section 11) that identifies the server. The format is:
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_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: Server Identifier Option Format ๐
option-code: OPTION_SERVERID (2).
option-len: the length of the DUID, in octets.
DUID: the DUID for the server. ๐
21.4. Identity Association for Non-Temporary Addresses Option โจ
okay bestie, this is the IA_NA option ๐ It carries an IA_NA, the parameters that go with it, and the non-temporary addresses that belong to it ๐
A client that needs a short-term / special-purpose address can use a new IA_NA binding to request one, then release it when it's done ๐ฆ
Note: Addresses appearing in an IA_NA option are not temporary addresses (see Section 21.5). Not temporary, hear me out ๐
The format of the IA_NA option is:
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_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Identity Association for Non-Temporary Addresses
Option Format- option-code:
OPTION_IA_NA (3). ๐ - option-len: 12 + length of IA_NA-options field. ๐
- IAID: The unique identifier for this IA_NA. The IAID must be unique among the identifiers for all of this client's IA_NAs. The number space for IA_NA IAIDs is separate from the number space for other IA option types (i.e., IA_PD). It's a 4-octet field containing an unsigned integer. ๐ง
- T1: The time interval after which the client should contact the server from which the addresses in the IA_NA were obtained to extend the lifetimes of the addresses assigned to the IA_NA. T1 is a time duration relative to the current time, expressed in units of seconds. It's a 4-octet field containing an unsigned integer. โฐ
- T2: The time interval after which the client should contact any available server to extend the lifetimes of the addresses assigned to the IA_NA. T2 is a time duration relative to the current time, expressed in units of seconds. It's a 4-octet field containing an unsigned integer. โฐ
- IA_NA-options: Options associated with this IA_NA. It's a variable-length field (12 octets less than the value in the option-len field). ๐
The IA_NA-options field holds the options that are specific to this IA_NA. For example, all of the IA Address options (see Section 21.6) carrying the addresses associated with this IA_NA live in the IA_NA-options field ๐ซถ
Each IA_NA carries one "set" of non-temporary addresses. It's up to the server policy to decide how many addresses get assigned, but typically at most one address is assigned from each prefix assigned to the link the client is attached to ๐
An IA_NA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_NA options, though each one must have a unique IAID ๐
The status of any operations involving this IA_NA is indicated in a Status Code option (see Section 21.13) in the IA_NA-options field. โ
Here's the tea: an IA_NA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_NA have expired, the IA_NA can be considered expired. T1 and T2 are there so servers get explicit control over when a client recontacts the server about a specific IA_NA ๐
In a message sent by a client to a server, the T1 and T2 fields SHOULD be set to 0. The server MUST ignore any values in these fields in messages received from a client. ๐ โโ๏ธ
In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 times, unless the values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2, and they're calculated since reception of the message. โณ
As per Section 7.7, the value 0xffffffff is taken to mean "infinity" and should be used carefully. Be careful with that one, it's a lot ๐
The server picks the T1 and T2 values so the client can extend the lifetimes of any addresses in the IA_NA before they expire, even if the server is unavailable for a short period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively. If the "shortest" preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_NA are to be renewed is left to the client's discretion, the server sets the T1 and T2 values to 0. The client MUST follow the rules defined in Section 14.2. ๐
If a client receives an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_NA option and processes the rest of the message as though the server had not included the invalid IA_NA option. Invalid option, invalid vibes ๐
21.5. Identity Association for Temporary Addresses Option
The Identity Association for Temporary Addresses (IA_TA) option is obsoleted. Please refer to [RFC8415] for historical information on this option. ๐ฅ
The client SHOULD NOT send this option. The server SHOULD NOT send this option. When the server receives an IA_TA option, the option SHOULD be ignored and message processing should continue as usual. ๐ซ
As this option was never popular among server or client implementations before being deprecated, any implementations that still attempt to send it are unlikely to have the option processed. It never really caught on, sadly ๐ญ
21.6. IA Address Option ๐ฆ
The IA Address option is used to specify an address. In this document, it's only specified to be encapsulated within an IA_NA. DHCPv6 Leasequery [RFC5007] makes use of the IA Address option without encapsulating it in IA_NA. The IAaddr-options field holds the options that are specific to this address. ๐
The format of the IA Address option is:
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_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IAaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IA Address Option Format- option-code:
OPTION_IAADDR (5). ๐ - option-len: 24 + length of IAaddr-options field. ๐
- IPv6-address: An IPv6 address. A client MUST NOT form an implicit prefix with a length other than 128 for this address. It's a 16-octet field. ๐ธ
- preferred-lifetime: The preferred lifetime for the address in the option, expressed in units of seconds. It's a 4-octet field containing an unsigned integer. โฐ
- valid-lifetime: The valid lifetime for the address in the option, expressed in units of seconds. It's a 4-octet field containing an unsigned integer. โฐ
- IAaddr-options: Options associated with this address. It's a variable-length field (24 octets less than the value in the option-len field). ๐
In a message sent by a client to a server, the preferred-lifetime and valid-lifetime fields SHOULD be set to 0. The server MUST ignore any received values. ๐ โโ๏ธ
The client SHOULD NOT send the IA Address option with an unspecified address (::). Not the vibe ๐ซ
In a message sent by a server to a client, the client MUST use the values in the preferred-lifetime and valid-lifetime fields for the preferred and valid lifetimes. The values in these fields are the number of seconds remaining in each lifetime. โณ
The client MUST discard any addresses for which the preferred lifetime is greater than the valid lifetime. No cap, that's a hard rule ๐
As per Section 7.7, if the valid lifetime of an address is 0xffffffff, it's taken to mean "infinity" and should be used carefully. ๐
More than one IA Address option can appear in an IA_NA option. ๐
21.7. Option Request Option ๐
Okay bestie, the Option Request option is how a client says "hey, these are the options I want you to send me" ๐. It's a list of option codes that the client puts in a message to the server. Here's the shape:
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_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 17: Option Request Option Format
option-code: OPTION_ORO (6).
option-len: 2 * number of requested options.
requested-option-code-n: The option code for an option requested by the client. Each option code is a 2-octet field containing an unsigned integer.
A client MUST include an Option Request option in a Solicit, Request, Renew, Rebind, or Information-request message to inform the server about options the client wants the server to send to the client. ๐ซถ
The Option Request option MUST NOT include the following option codes, no exceptions, periodt ๐ โโ๏ธ:
- Client Identifier (see Section 21.2)
- Server Identifier (see Section 21.3)
IA_NA(see Section 21.4)IA_TA(option obsoleted, see Section 21.5)IA_PD(see Section 21.21)- IA Address (see Section 21.6)
- IA Prefix (see Section 21.22)
- Option Request (this section)
- Elapsed Time (see Section 21.9)
- Preference (see Section 21.8)
- Relay Message (see Section 21.10)
- Authentication (see Section 21.11)
- Server Unicast (option obsoleted, see Section 21.12)
- Status Code (see Section 21.13)
- Rapid Commit (see Section 21.14)
- User Class (see Section 21.15)
- Vendor Class (see Section 21.16)
- Interface-Id (see Section 21.18)
- Reconfigure Message (see Section 21.19)
- Reconfigure Accept (see Section 21.20)
Other top-level option codes MUST appear in the Option Request option or they will not be sent by the server. Only top-level option codes MAY appear in the Option Request option. Option codes encapsulated in a container option SHOULD NOT appear in an Option Request option, ngl. See [RFC7598] for an example of container options. However, options MAY be defined that specify exceptions to this restriction on including encapsulated option codes in an Option Request option. For example, the Option Request option MAY be used to signal support for a feature even when that option is encapsulated, as in the case of the Prefix Exclude option [RFC6603]. See [IANA-OPTION-DETAILS].
See [IANA-OPTION-DETAILS] for the authoritative list of which option codes are required, permitted, or forbidden. The registry is the source of truth, iykyk ๐โจ
21.8. Preference Option ๐ธ
The Preference option is sent by a server to a client to control the selection of a server by the client. It's basically the server going "pick me, pick me" with a number attached ๐
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_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+Figure 18: Preference Option Format
option-code: OPTION_PREFERENCE (7).
option-len: 1.
pref-value: The preference value for the server in this message. Allowed values are from 0 (least) to 255 (most preferred). Absence of option means preference 0. A 1-octet unsigned integer.
A server MAY include a Preference option in an Advertise message to control the selection of a server by the client. See Section 18.2.9 for information regarding the use of the Preference option by the client and the interpretation of the Preference option data value. Main character energy for the server, honestly ๐
21.9. Elapsed Time Option โฐ
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_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 19: Elapsed Time Option Format
option-code: OPTION_ELAPSED_TIME (8).
option-len: 2.
elapsed-time: The amount of time since the client began its current DHCP transaction. This time is expressed in hundredths of a second (10^-2 seconds). A 2-octet field containing an unsigned integer.
A client MUST include an Elapsed Time option in messages to indicate how long the client has been trying to complete a DHCP message exchange. The elapsed time is measured from the time at which the client sent the first message in the message exchange, and the elapsed-time field is set to 0 in the first message in the message exchange. Servers and relay agents use the data value in this option as input to policy that controls how a server responds to a client message. For example, the Elapsed Time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. The elapsed-time value is a 16-bit (2-octet) unsigned integer. The client uses the value 0xffff to represent any elapsed-time values greater than the largest time value that can be represented in the Elapsed Time option.
It's giving "I've been waiting forever" energy, and the timer keeps running until the exchange is done ๐ญโณ
21.10. Relay Message Option ๐ฆ
The Relay Message option carries a DHCP message in a Relay-forward or Relay-reply message. Think of it as a little envelope that the relay agent passes along, sealed with a kiss ๐
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_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: Relay Message Option Format
option-code: OPTION_RELAY_MSG (9).
option-len: Length of DHCP-relay-message field.
DHCP-relay-message: In a Relay-forward message, the received message, relayed verbatim to the next relay agent or server; in a Relay-reply message, the message to be copied and relayed to the relay agent or client whose address is in the peer-address field of the Relay-reply message. The length, in octets, is specified by option-len.
21.11. Authentication Option ๐
The Authentication option carries authentication information to authenticate the identity and contents of DHCP messages. It's the bodyguard of the whole operation ๐ก๏ธ The use of the Authentication option is described in Section 20. The format of the Authentication option is:
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_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: Authentication Option Format
option-code: OPTION_AUTH (11).
option-len: 11 + length of authentication information field.
protocol: The authentication protocol used in this Authentication option. A 1-octet unsigned integer.
algorithm: The algorithm used in the authentication protocol. A 1-octet unsigned integer.
RDM: The replay detection method used in this Authentication option. A 1-octet unsigned integer.
replay detection: The replay detection information for the RDM. A 64-bit (8-octet) field.
authentication information: The authentication information, as specified by the protocol and algorithm used in this Authentication option. A variable-length field (11 octets less than the value in the option-len field).
IANA maintains a registry for the protocol, algorithm, and RDM values at <https://www.iana.org/assignments/auth-namespaces>. Go check it out, the registry is where all the good stuff lives ๐๐
21.12. Server Unicast Option ๐
The Server Unicast option is obsolete. Please refer to [RFC8415] for historical information on this option. It's retired, bestie, like a legend that's finally gone off to the beach ๐๏ธ
The server MUST NOT send this option. When any entity receives the Server Unicast option, the option SHOULD be ignored and the message processing should continue as usual. So if you spot it, just scroll past and keep the vibes going โจ๐
21.13. Status Code Option โจ
Okay so this option is the bestie that tells you how a DHCP message or option went, like a little report card ๐๐ . It shows up in the "options" field of a DHCP message and/or in the "options" field of another option. Here's the vibe:
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_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Status Code Option Formatoption-code: OPTION_STATUS_CODE (13). ๐
option-len: 2 + length of status-message field. ๐ธ
status-code: The numeric code for the status encoded in this option. It's a 2-octet field holding an unsigned integer. ๐ข
status-message: A UTF-8 encoded [RFC3629] text string that's suitable for display to an end user. It MUST NOT be NUL-terminated. ๐ซ It's a variable-length field, 2 octets less than the value in the option-len field. ๐ฆ
A Status Code option may appear in the "options" field of a DHCP message and/or in the "options" field of another option. If the Status Code option does not appear in a message where the option could appear, the status of the message is assumed to be Success. โ Literally main character energy when nothing is wrong ๐ .
The status-code values are:
+===============+======+===================================+
| Name | Code | Description |
+===============+======+===================================+
| Success | 0 | Success. |
+---------------+------+-----------------------------------+
| UnspecFail | 1 | Failure, reason unspecified; this |
| | | status code is sent by a server |
| | | to indicate a failure not |
| | | explicitly specified in this |
| | | document. |
+---------------+------+-----------------------------------+
| NoAddrsAvail | 2 | The server has no addresses |
| | | available to assign to the IA(s). |
+---------------+------+-----------------------------------+
| NoBinding | 3 | Client record (binding) |
| | | unavailable. |
+---------------+------+-----------------------------------+
| NotOnLink | 4 | The prefix for the address is not |
| | | appropriate for the link to which |
| | | the client is attached. |
+---------------+------+-----------------------------------+
| UseMulticast | 5 | Sent by a server to a client to |
| | | force the client to send messages |
| | | to the server using the |
| | | All_DHCP_Relay_Agents_and_Servers |
| | | multicast address. Obsoleted; no |
| | | longer used. |
+---------------+------+-----------------------------------+
| NoPrefixAvail | 6 | The server has no prefixes |
| | | available to assign to the |
| | | IA_PD(s). |
+---------------+------+-----------------------------------+
Table 3: Status Code DefinitionsSee the "Status Codes" registry at https://www.iana.org/assignments/dhcpv6-parameters for the current list of status codes. ๐
21.14. Rapid Commit Option โก
Rapid Commit is the option that signals you want the two-message exchange for address assignment. It's giving speed ๐๏ธ๐จ.
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_RAPID_COMMIT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Rapid Commit Option Formatoption-code: OPTION_RAPID_COMMIT (14). ๐
option-len: 0.
A client MAY include this option in a Solicit message if the client is prepared to perform the Solicit/Reply message exchange described in Section 18.2.1. ๐โโ๏ธ
A server MUST include this option in a Reply message sent in response to a Solicit message when completing the Solicit/Reply message exchange. ๐ซถ
DISCUSSION: ๐ฃ๏ธ
- Each server that responds with a Reply to a Solicit that includes a Rapid Commit option will commit the leases in the Reply message to the client, but it won't receive any confirmation that the client got the Reply. ๐ฌ So if more than one server responds to a Solicit that includes a Rapid Commit option, all but one server will commit leases that aren't actually used by the client. Ngl that could give incorrect address information in DNS if the DHCP servers update DNS [RFC4704], and responses to leasequery requests [RFC5007] may include information on leases not in use by the client. ๐
- The problem of unused leases can be minimized by designing the DHCP service so that only one server responds to the Solicit, or by using relatively short lifetimes for newly assigned leases. ๐ง
21.15. User Class Option ๐ฆ
The User Class option is used by a client to identify the type or category of users or applications it represents. It's like the client's little club card ๐ชช๐.
The format of the User Class option is:
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_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: User Class Option Formatoption-code: OPTION_USER_CLASS (15). ๐
option-len: Length of user-class-data field. ๐
user-class-data: The user classes carried by the client. The length, in octets, is specified by option-len. ๐
The information in the data area of this option is held in one or more opaque fields that represent the user class or classes the client belongs to. A server picks configuration information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. ๐จ๏ธโจ The user class information carried in this option MUST be configurable on the client. โ๏ธ
The data area of the User Class option MUST contain one or more instances of user-class-data information. Each instance of user-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 25: Format of user-class-data FieldThe user-class-len field is 2 octets long and specifies the length of the opaque user-class-data in network byte order. ๐ข
A server interprets the classes identified in this option according to its configuration to pick the right configuration information for the client. A server MAY use only those user classes that it is configured to interpret in selecting configuration information for a client, and ignore any other user classes. ๐ In response to a message containing a User Class option, a server MAY include a User Class option containing those classes that were successfully interpreted by the server, so the client can be told which classes the server understood. ๐ซถ
21.16. Vendor Class Option ๐ญ
This option is used by a client to identify the vendor that manufactured the hardware the client is running on. The information in the data area of this option is held in one or more opaque fields that identify details of the hardware configuration. ๐ฅ๏ธ๐ The format of the Vendor Class option is:
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_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Vendor Class Option Formatoption-code: OPTION_VENDOR_CLASS (16). ๐
option-len: 4 + length of vendor-class-data field. ๐
enterprise-number: The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. It's a 4-octet field holding an unsigned integer. ๐ข
vendor-class-data: The hardware configuration of the node the client is running on. It's a variable-length field, 4 octets less than the value in the option-len field. ๐งฉ
The vendor-class-data field is made up of a series of separate items, and each one describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client. ๐ง ๐พ
Each instance of vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 27: Format of vendor-class-data FieldThe vendor-class-len field is 2 octets long and specifies the length of the opaque vendor-class-data in network byte order. ๐ข
Servers and clients MUST NOT include more than one instance of OPTION_VENDOR_CLASS with the same Enterprise Number. ๐ซ Each instance of OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances. ๐
21.17. Vendor-Specific Information Option โจ
okay so this option is how clients and servers swap vendor-specific info ๐ each vendor gets its own little corner to say whatever it wants ๐ฆ
The format of the Vendor-specific Information option is:
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_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 28: Vendor-Specific Information Option Format
option-code:OPTION_VENDOR_OPTS(17).option-len: 4 + length ofvendor-option-datafield.enterprise-number: The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer.vendor-option-data: Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in theoption-lenfield).
The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. A DHCP client that does not receive requested vendor-specific information will still configure the node's IPv6 stack to be functional. ๐ซถ
The vendor-option-data field MUST be encoded as a sequence of code/length/value fields of format identical to the DHCP options (see Section 21.1). The suboption codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the suboptions is formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-code | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. suboption-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29: Vendor-Specific Options Format
suboption-code: The code for the suboption. A 2-octet field.suboption-len: An unsigned integer giving the length of thesuboption-datafield in this suboption in octets. A 2-octet field.suboption-data: The data area for the suboption. The length, in octets, is specified bysuboption-len.
Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific Information option MAY contain multiple suboptions.
A client that is interested in receiving a Vendor-specific Information option:
- MUST specify the Vendor-specific Information option in an Option Request option.
- MAY specify an associated Vendor Class option (see Section 21.16).
- MAY specify the Vendor-specific Information option with appropriate data.
Servers only return the Vendor-specific Information options if specified in Option Request options from clients and:
- MAY use the Enterprise Numbers in the associated Vendor Class options to restrict the set of Enterprise Numbers in the Vendor-specific Information options returned.
- MAY return all configured Vendor-specific Information options.
- MAY use other information in the message or in its configuration to determine which set of Enterprise Numbers in the Vendor-specific Information options to return.
21.18. Interface-Id Option ๐ธ
the relay agent MAY send this one to say which interface the client message came in on ๐ and if a relay agent gets a Relay-reply with an Interface-Id option, it relays the message back to the client through the interface named in that option ๐ง
The format of the Interface-Id option is:
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_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 30: Interface-Id Option Format
option-code:OPTION_INTERFACE_ID(18).option-len: Length ofinterface-idfield.interface-id: An opaque value of arbitrary length generated by the relay agent to identify one of the relay agent's interfaces. The length, in octets, is specified byoption-len.
The server MUST copy the Interface-Id option from the Relay-forward message into the Relay-reply message the server sends to the relay agent in response to the Relay-forward message. This option MUST NOT appear in any message except a Relay-forward or Relay-reply message.
Servers MAY use the interface-id field for parameter assignment policies. The interface-id value SHOULD be considered an opaque value, with policies based on exact match only; that is, the interface-id field SHOULD NOT be internally parsed by the server. The interface-id value for an interface SHOULD be stable and remain unchanged -- for example, after the relay agent is restarted; if the interface-id value changes, a server will not be able to use it reliably in parameter assignment policies. ๐
21.19. Reconfigure Message Option ๐ฆ
A server includes a Reconfigure Message option in a Reconfigure message to indicate to the client whether the client responds with a Renew message, a Rebind message, or an Information-request message. The format of the Reconfigure Message option is:
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_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+Figure 31: Reconfigure Message Option Format
option-code:OPTION_RECONF_MSG(19).option-len: 1.msg-type: 5 for Renew message, 6 for Rebind message, 11 for Information-request message. A 1-octet unsigned integer.
The Reconfigure Message option can only appear in a Reconfigure message. ๐
21.20. Reconfigure Accept Option ๐
A client uses the Reconfigure Accept option to announce to the server whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages. In the absence of this option, the default behavior is that the client is unwilling to accept Reconfigure messages. The format of the Reconfigure Accept option is:
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_RECONF_ACCEPT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 32: Reconfigure Accept Option Format
option-code:OPTION_RECONF_ACCEPT(20).option-len: 0.
21.21. Identity Association for Prefix Delegation Option โจ
okay so this one is the IA_PD option, and it's giving "carry a whole bundle of prefix stuff for me" ๐ It carries a prefix delegation identity association, the parameters tied to that IA_PD, and the prefixes that belong to it. Here's the layout, bestie ๐ :
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_IA_PD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_PD-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 33: Identity Association for Prefix Delegation Option Format ๐ธ
option-code: OPTION_IA_PD (25). Slay, the code is 25 ๐
option-len: 12 + length of IA_PD-options field. The fixed part is 12 octets, and then you add however long the options inside are.
IAID: the unique identifier for this IA_PD. It MUST be unique among the identifiers for all of this client's IA_PDs. The number space for IA_PD IAIDs is separate from the number space for other IA option types (i.e., IA_NA). It's a 4-octet unsigned integer. Main character energy, no duplicates allowed ๐
T1: the time interval after which the client should contact the server the prefixes were obtained from, so it can extend the lifetimes of the prefixes delegated to the IA_PD. T1 is a duration relative to when the message was received, in seconds. Also a 4-octet unsigned integer ๐ฆ
T2: the time interval after which the client should contact any available server to extend the lifetimes of the prefixes assigned to the IA_PD. Same deal: relative to message reception, in seconds, 4 octets, unsigned ๐ง
IA_PD-options: options associated with this IA_PD. It's variable-length, 12 octets less than the option-len value. ๐
The IA_PD-options field is where the options specific to this IA_PD live. For example, all of the IA Prefix options (see Section 21.22) carrying the prefixes for this IA_PD go in here ๐
An IA_PD option may only appear in the options area of a DHCP message. A DHCP message can hold multiple IA_PD options, but each one MUST have a unique IAID. ๐ซถ
The status of any operation involving this IA_PD is shown in a Status Code option (see Section 21.13) inside the IA_PD-options field โจ
Note that an IA_PD has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the prefixes in an IA_PD have expired, the IA_PD can be considered expired. The T1 and T2 fields exist so the server has explicit control over when a client should check in about a specific IA_PD. ๐
In a message sent by a client to a server, the T1 and T2 fields SHOULD be set to 0. The server MUST ignore any values in these fields in messages received from a client. ๐
In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for its T1 and T2 timers, unless those values are 0. The values in T1 and T2 are the number of seconds until T1 and T2. โฐ
The server picks the T1 and T2 times so the client can extend the lifetimes of any prefixes in the IA_PD before they expire, even if the server is unavailable for a short while. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the prefixes in the IA_PD that the server is willing to extend, respectively. If the server wants the client to decide when to renew the prefixes, it sets T1 and T2 to 0. The client MUST follow the rules defined in Section 14.2. ๐
If a client receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_PD option and processes the rest of the message as though the server had not included the IA_PD option. Not me discarding it ๐
21.22. IA Prefix Option ๐ฆ
The IA Prefix option specifies a prefix associated with an IA_PD. It MUST be encapsulated in the IA_PD-options field of an IA_PD option (see Section 21.21). ๐
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_IAPREFIX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6-prefix |
| (16 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. IAprefix-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 34: IA Prefix Option Format ๐ธ
option-code: OPTION_IAPREFIX (26). ๐
option-len: 25 + length of IAprefix-options field. ๐
preferred-lifetime: the preferred lifetime for the prefix in the option, in seconds. A value of 0xffffffff means "infinity" (see Section 7.7). It's a 4-octet unsigned integer ๐ง
valid-lifetime: the valid lifetime for the prefix in the option, in seconds. A value of 0xffffffff means "infinity". It's a 4-octet unsigned integer ๐ฆ
prefix-length: the length of this prefix in bits. A 1-octet unsigned integer ๐
IPv6-prefix: an IPv6 prefix. It's a 16-octet field ๐
IAprefix-options: options associated with this prefix. It's variable-length, 25 octets less than the option-len value. ๐ซถ
In a message sent by a client to a server, the preferred-lifetime and valid-lifetime fields SHOULD be set to 0. The server MUST ignore any received values in these lifetime fields. ๐
The client SHOULD NOT send an IA Prefix option with 0 in the "prefix-length" field (and an unspecified value (::) in the "IPv6-prefix" field). A client MAY send a non-zero value in the "prefix-length" field along with the unspecified value (::) in the "IPv6-prefix" field to indicate a preference for the size of the prefix to be delegated. See [RFC8168] for further details on prefix-length hints. โจ
The client MUST discard any prefixes for which the preferred lifetime is greater than the valid lifetime. ๐
The values in the preferred-lifetime and valid-lifetime fields are the number of seconds remaining in each lifetime. See Section 18.2.10.1 for more details on how these values are used for delegated prefixes. ๐
As per Section 7.7, the value 0xffffffff for the preferred lifetime or the valid lifetime is taken to mean "infinity" and should be used carefully. โญ
An IA Prefix option MAY appear only in an IA_PD option. More than one IA Prefix option can appear in a single IA_PD option. ๐
The status of any operation involving this IA Prefix option is shown in a Status Code option (see Section 21.13) in the IAprefix-options field. ๐
21.23. Information Refresh Time Option ๐ฆ
okay so this one is how a server says "hey, don't wait forever before checking in again" ๐ Clients ask for it, and servers send back an upper bound on how long a client should wait before refreshing info it got from a DHCP server. It only shows up in Reply messages answering Information-request messages, bc every other message already has stuff that tells the client when to call back (like T1/T2 times and lifetimes) ๐ซถ It's super useful when config params change or during a renumbering event, because stateless-mode clients can actually update their config then. iconic ๐ญ
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_INFORMATION_REFRESH_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 35: Information Refresh Time Option Format
- option-code:
OPTION_INFORMATION_REFRESH_TIME(32). - option-len: 4.
- information-refresh-time: a time duration relative to the current time, in seconds. It's a 4-octet unsigned integer ๐ฅ
A DHCP client MUST request this option in the Option Request option (see Section 21.7) when sending Information-request messages. A client MUST NOT request this option in the Option Request option in any other messages. โจ
A server sending a Reply to an Information-request message SHOULD include this option if it was requested in the Option Request option of the Information-request. The option value MUST NOT be smaller than IRT_MINIMUM. This option MUST only appear in the top-level options area of Reply messages. ๐ธ
If the Reply to an Information-request message doesn't contain this option, the client MUST behave as if the option with the value IRT_DEFAULT was provided. ๐
A client MUST use the refresh time IRT_MINIMUM if it receives the option with a value less than IRT_MINIMUM. ๐
As per Section 7.7, the value 0xffffffff means "infinity" ๐ง It implies that the client should not refresh its configuration data without some other trigger, like detecting movement to a new link.
If a client contacts the server to get new data or refresh existing data before the refresh time expires, then it SHOULD also refresh all data covered by this option. ๐ซถ
When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information-request as specified in Section 18.2.6. The one twist is that the client MUST delay sending the first Information-request by a random amount of time between 0 and INF_MAX_DELAY. Main character energy, no cap ๐ฆ
A client MAY have a maximum value for the refresh time. If it does, that value is used whenever the client receives this option with a value higher than the maximum, and that also covers when the received value is "infinity". A maximum value might make the client less vulnerable to attacks based on forged DHCP messages. Without one, a client may be made to use wrong information for a possibly infinite period of time ๐ญ There may, however, be reasons for a very long refresh time, so it may be useful for this maximum value to be configurable. ๐
21.24. SOL_MAX_RT Option ๐
okay this one lets a DHCP server override the default SOL_MAX_RT, which is what the client uses for its Solicit retransmissions. The value in the option replaces the default from Section 7.6. A big use case is bumping SOL_MAX_RT up, which means a client that isn't getting answers to its Solicit messages sends less Solicit traffic. it's giving calm down and rest ๐
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_SOL_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOL_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 36: SOL_MAX_RT Option Format
- option-code:
OPTION_SOL_MAX_RT(82). - option-len: 4.
- SOL_MAX_RT value: the overriding value for SOL_MAX_RT in seconds. It MUST be in this range:
60 <= "value" <= 86400(1 day). It's a 4-octet unsigned integer ๐
A DHCP client MUST include the SOL_MAX_RT option code in any Option Request option (see Section 21.7) it sends in a Solicit message. ๐ธ
The DHCP server MAY include the SOL_MAX_RT option in any response it sends to a client that included the SOL_MAX_RT option code in an Option Request option. The SOL_MAX_RT option is sent as a top-level option in the message to the client. โจ
A DHCP client MUST ignore any SOL_MAX_RT option values that are less than 60 or more than 86400. ๐
If a DHCP client receives a message containing a SOL_MAX_RT option with a valid value for SOL_MAX_RT, the client MUST set its internal SOL_MAX_RT parameter to the value in that option. The retransmission mechanism defined in Sections 15 and 18.2.1 then uses this value of SOL_MAX_RT. ๐ฅ
The whole point is to give network admins a way to avoid excessive DHCP traffic if all DHCP servers go down. Therefore, this value is expected to be kept for as long as practically possible. ๐ง
An updated SOL_MAX_RT value only applies to the network interface on which the client received the SOL_MAX_RT option. ๐
21.25. INF_MAX_RT Option ๐
this is basically SOL_MAX_RT's twin, but for Information-request traffic ๐ A DHCP server sends the INF_MAX_RT option to a client to override the default INF_MAX_RT. The value in the option replaces the default from Section 7.6. Setting a higher value cuts down the Information-request traffic from a client that hasn't gotten a response to its Information-request messages. slay, honestly ๐
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_INF_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INF_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 37: INF_MAX_RT Option Format
- option-code:
OPTION_INF_MAX_RT(83). - option-len: 4.
- INF_MAX_RT value: the overriding value for INF_MAX_RT in seconds. It MUST be in this range:
60 <= "value" <= 86400(1 day). It's a 4-octet unsigned integer ๐ฆ
A DHCP client MUST include the INF_MAX_RT option code in any Option Request option (see Section 21.7) it sends in an Information-request message. ๐ธ
The DHCP server MAY include the INF_MAX_RT option in any response it sends to a client that included the INF_MAX_RT option code in an Option Request option. The INF_MAX_RT option is a top-level option in the message to the client. โจ
A DHCP client MUST ignore any INF_MAX_RT option values that are less than 60 or more than 86400. ๐
If a DHCP client receives a message containing an INF_MAX_RT option with a valid value for INF_MAX_RT, the client MUST set its internal INF_MAX_RT parameter to the value in that option. The retransmission mechanism defined in Sections 15 and 18.2.6 then uses this value of INF_MAX_RT. ๐
An updated INF_MAX_RT value only applies to the network interface on which the client received the INF_MAX_RT option. ๐
22. Security Considerations ๐ฅ
this section covers the security stuff that's not about privacy. Privacy has its own dedicated section, which is Section 23 ๐
The threat to DHCP is basically an insider threat, assuming a properly configured network where DHCP ports are blocked on the enterprise's perimeter gateways. Regardless of the gateway config, though, the potential attacks by insiders and outsiders are the same. ๐
DHCP has no end-to-end encryption between clients and servers, so hijacking, tampering, and eavesdropping attacks are all possible as a result. Some network environments (discussed below) can be secured in various ways to minimize these attacks ๐ญ
The threat shared by both the client and the server is the "resource-exhaustion" DoS attack. These usually involve running out of assignable addresses or delegatable prefixes, or running out of CPU or network bandwidth. They show up any time there's a shared resource. Some forms of these exhaustion attacks can be partially mitigated by good server policy, like limiting the maximum number of leases any one client can get, limiting the number of leases one client can decline, and limiting the number of messages a single client can send in a period of time. ๐ก๏ธโจ
22.1. Client Security Considerations ๐ง
one attack that's specific to a DHCP client is setting up a malicious server to hand it wrong config info. The motive might be a "man-in-the-middle" attack that gets the client talking to a fake server instead of a real one for some service (like DNS or NTP). A malicious server may also DoS the client by misconfiguring it, which would make all of the client's network communication fail. ๐
A malicious DHCP server might make a client set its SOL_MAX_RT and INF_MAX_RT parameters to an unreasonably high value using the SOL_MAX_RT option (see Section 21.24) and the INF_MAX_RT option (see Section 21.25). This could cause an undue delay in the client finishing its DHCP protocol transaction when no other valid response comes in. But if the client also gets a response from a valid DHCP server, those large SOL_MAX_RT and INF_MAX_RT values won't have any effect ๐
Another threat to DHCP clients comes from DHCP servers that are misconfigured by mistake or by accident and answer client requests with incorrect config params on purpose-less autopilot ๐ yikes
If a client implementation supports the reconfigure mechanism, see Section 22.3. ๐ซถ
22.2. Server Security Considerations ๐ก๏ธ
okay bestie, the big scary threat for a DHCP server is an invalid client pretending to be a valid one ๐ why? usually to steal service or dodge auditing, iykyk ๐
the messages zooming between relay agents and servers can be used to pull off a man-in-the-middle or DoS attack ๐ญ good news tho: server<->relay and relay<->relay talk can be authenticated and encrypted with IPsec, as described in [RFC8213] โจ
BUT (and this is a big but ๐) using manually configured pre-shared keys for IPsec between relays and servers does NOT protect you from replayed DHCP messages. ๐ โโ๏ธ replays can cause a DoS by eating up processing resources, but they can't mess with stuff like assignable addresses and delegatable prefixes, and they aren't about misconfiguration either ๐
and if a server supports the reconfigure mechanism, go check out Section 22.3 ๐
22.3. Reconfigure Security Considerations ๐จ
okay this one is seriously dramatic ๐ญ๐ฅ RKAP, described in Section 20.4, is what protects against a rogue DHCP server using a Reconfigure message to DoS or man-in-the-middle a client ๐ but here's the tea: an attacker who can intercept the very first message, where the server sends the key as plain text, can totally compromise it ๐
so because a Reconfigure message is a juicy target, a DHCP client MUST discard any Reconfigure message that doesn't include authentication, or that fails the validation process for the authentication protocol. no exceptions, periodt ๐
a client can also get attacked by a malicious server that sends a Reconfigure message to make it grab wrong configuration info ๐ฌ quick note: even though a client sends its response (Renew, Rebind, or Information-request message) through a relay agent, so only servers the messages get relayed to will see it, a malicious server doesn't have to be on the network path. it could send a Reconfigure message, wait an appropriate delay, and then send a Reply that the client accepts ๐ฑ so yeah, an off-path malicious server can still pull off a Reconfigure attack ๐ซฃ
using transaction IDs that are cryptographically sound and hard to predict will also lower the chance this attack works ๐ฆ
22.4. Mitigation Considerations ๐
a bunch of network environments give you extra security if you deploy them the way described below โจ
- in enterprise and factory networks, authentication per [IEEE8802.1x] can stop unknown or untrusted clients from joining the network. but ngl, that doesn't guarantee the connected client will be a good DHCP or network actor ๐
- on wired networks, where clients usually plug into a switch port, snooping DHCP multicast (or unicast) traffic gets hard because switches limit what gets delivered to each port ๐ the client's DHCP messages (multicast to All_DHCP_Relay_Agents_and_Servers) are only forwarded to the DHCP server's (or relay's) switch port, not all ports. and the server's (or relay's) unicast replies only go to the target client's port, not every port ๐
- in public networks (like Wi-Fi at a coffee shop or airport), anyone in radio range can snoop DHCP and other traffic ๐ but there's very little you can learn from the DHCP traffic itself (client to server or server to client) if you follow the privacy considerations in Section 23 ๐ even devices that don't follow them don't leak much more than you'd get from later communications anyway, like the device's Media Access Control (MAC) address ๐ also, since all clients usually get similar configuration details, a bad actor who starts a DHCP request themselves can learn most of that info too ๐ซ as mentioned above, one threat is that the RKAP key for a client can be learned (if the initial Solicit/Advertise/Request/Reply exchange is monitored) and trigger a premature reconfiguration. but this is pretty easy to prevent by disallowing direct client-to-client communication on these networks, or by using [RFC7610] and [RFC7513] ๐ฆ
many of the attacks by rogue servers can be mitigated by using the mechanisms described in [RFC7610] and [RFC7513] ๐
23. Privacy Considerations ๐ซฃ
okay for the extended privacy tea on the client, check out [RFC7824] ๐
- Section 3 of [RFC7824] talks about the different identifiers that could be misused to track the client ๐
- Section 4 of [RFC7824] covers existing mechanisms that might affect a client's privacy ๐ธ
- and Section 5 of [RFC7824] goes over potential attack vectors ๐ญ
for recommendations on how to address or mitigate all that, see [RFC7844] โจ
this spec doesn't define any allocation strategies for servers ๐ โโ๏ธ implementers are expected to write their own algorithm for the server to pick a resource out of the available pool ๐ a few possible strategies are mentioned in Section 4.3 of [RFC7824], but keep in mind that list isn't exhaustive, there are definitely other options ๐ง readers are also encouraged to read [RFC7707], especially Section 4.1.2 of [RFC7707], which talks about the problems with certain allocation strategies ๐
24. IANA Considerations ๐ท
this document doesn't define any new DHCP name spaces or definitions โจ
publishing this document doesn't change the assignment rules for new values for message types, option codes, DUID types, or status codes ๐
the list of assigned values used in DHCPv6 lives at https://www.iana.org/assignments/dhcpv6-parameters ๐
IANA has updated all references to [RFC8415] to point to this document at https://www.iana.org/assignments/dhcpv6-parameters ๐
IANA also added a new column "Status" to all registries on the DHCPv6 parameters page at https://www.iana.org/assignments/dhcpv6-parameters and left every entry blank except the ones below ๐ซถ
- in the "Option Codes" registry, the "Status" value has been set to "Obsolete" for the IA_TA (option code 4) and UNICAST (option code 12) rows ๐
- in the "Status Codes" registry, the "Status" value has been set to "Obsolete" for the UseMulticast (status code 5) row ๐
IANA has updated other references to [RFC8415] with references to this document at:
https://www.iana.org/assignments/auth-namespaces(four entries) ๐https://www.iana.org/assignments/bootp-dhcp-parameters(two entries) โญhttps://www.iana.org/assignments/ipv6-multicast-addresses(two entries) ๐ฆhttps://www.iana.org/assignments/service-names-port-numbers(two entries; UDP ports 546 and 547) ๐ธ
25. References ๐
25.1. Normative References ๐
[BCP145] Best Current Practice 145, https://www.rfc-editor.org/info/bcp145. At the time of writing, this BCP comprises the following:
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, https://www.rfc-editor.org/info/rfc8085.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc768.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, https://www.rfc-editor.org/info/rfc1035.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, https://www.rfc-editor.org/info/rfc4291.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, https://www.rfc-editor.org/info/rfc4861.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, https://www.rfc-editor.org/info/rfc4862.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, https://www.rfc-editor.org/info/rfc6221.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, https://www.rfc-editor.org/info/rfc6355.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, https://www.rfc-editor.org/info/rfc7227.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, https://www.rfc-editor.org/info/rfc7934.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged between Servers and Relay Agents", RFC 8213, DOI 10.17487/RFC8213, August 2017, https://www.rfc-editor.org/info/rfc8213.
25.2. Informative References ๐ซง
[Err6159] RFC Errata, Erratum ID 6159, RFC 8415, https://www.rfc-editor.org/errata/eid1912.
[Err6183] RFC Errata, Erratum ID 6183, RFC 8415, https://www.rfc-editor.org/errata/eid1912.
[Err6269] RFC Errata, Erratum ID 6269, RFC 8415, https://www.rfc-editor.org/errata/eid1912.
[IANA-HARDWARE-TYPES] IANA, "Hardware Types", https://www.iana.org/assignments/arp-parameters.
[IANA-OPTION-DETAILS] IANA, "Option Codes", https://www.iana.org/assignments/dhcpv6-parameters.
[IANA-PEN] IANA, "Private Enterprise Numbers", https://www.iana.org/assignments/enterprise-numbers.
[IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", https://www.iana.org/assignments/ipv6-interface-ids.
Bestie, the receipts keep coming ๐โจ Every single reference is here, exactly as written.
[IEEE8802.1x] IEEE/ISO/IEC, "IEEE/ISO/IEC International Standard-Telecommunications and exchange between information technology systems--Requirements for local and metropolitan area networks--Part 1X:Port-based network access control", ISO/IEC/IEEE 8802-1X:2021, DOI 10.1109/IEEESTD.2021.9650828, 2021, <https://ieeexplore.ieee.org/document/9650828>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001, <https://www.rfc-editor.org/info/rfc3162>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, DOI 10.17487/RFC3290, May 2002, <https://www.rfc-editor.org/info/rfc3290>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, <https://www.rfc-editor.org/info/rfc3769>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, DOI 10.17487/RFC4477, May 2006, <https://www.rfc-editor.org/info/rfc4477>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>.
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, DOI 10.17487/RFC4943, September 2007, <https://www.rfc-editor.org/info/rfc4943>.
[RFC4957] Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli, S., and A. Yegin, Ed., "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, DOI 10.17487/RFC4957, August 2007, <https://www.rfc-editor.org/info/rfc4957>.
[RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, "DHCPv6 Relay Agent Echo Request Option", RFC 4994, DOI 10.17487/RFC4994, September 2007, <https://www.rfc-editor.org/info/rfc4994>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <https://www.rfc-editor.org/info/rfc5007>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <https://www.rfc-editor.org/info/rfc5453>.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", RFC 5908, DOI 10.17487/RFC5908, June 2010, <https://www.rfc-editor.org/info/rfc5908>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <https://www.rfc-editor.org/info/rfc6059>.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, DOI 10.17487/RFC6422, December 2011, <https://www.rfc-editor.org/info/rfc6422>.
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, <https://www.rfc-editor.org/info/rfc6603>.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, <https://www.rfc-editor.org/info/rfc6879>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <https://www.rfc-editor.org/info/rfc7598>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7943] Gont, F. and W. Liu, "A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 7943, DOI 10.17487/RFC7943, September 2016, <https://www.rfc-editor.org/info/rfc7943>.
[RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP Configuration on the Basis of Network Topology", RFC 7969, DOI 10.17487/RFC7969, October 2016, <https://www.rfc-editor.org/info/rfc7969>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, <https://www.rfc-editor.org/info/rfc8168>.
[RFC8357] Shen, N. and E. Chen, "Generalized UDP Source Port for DHCP Relay", RFC 8357, DOI 10.17487/RFC8357, March 2018, <https://www.rfc-editor.org/info/rfc8357>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, "Link-Layer Address Assignment Mechanism for DHCPv6", RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, DOI 10.17487/RFC8987, February 2021, <https://www.rfc-editor.org/info/rfc8987>.
[RFC9096] Gont, F., ลฝorลพ, J., Patterson, R., and B. Volz, "Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events", BCP 234, RFC 9096, DOI 10.17487/RFC9096, August 2021, <https://www.rfc-editor.org/info/rfc9096>.
[RFC9243] Farrer, I., Ed., "A YANG Data Model for DHCPv6 Configuration", RFC 9243, DOI 10.17487/RFC9243, June 2022, <https://www.rfc-editor.org/info/rfc9243>.
[RFC9686] Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova, J., and S. Jiang, "Registering Self-Generated IPv6 Addresses Using DHCPv6", RFC 9686, DOI 10.17487/RFC9686, December 2024, <https://www.rfc-editor.org/info/rfc9686>.
[TR-187] Broadband Forum, "IPv6 for PPP Broadband Access", TR-187, Issue: 2, February 2013, <https://www.broadband-forum.org/pdfs/tr-187-2-0-0.pdf>.
Appendix A. Summary of Changes from RFC 8415 ๐
This appendix is the tea โ on everything that's different between this document and [RFC8415]:
- Obsoleted mechanisms. Okay so these got obsoleted because they weren't widely deployed, but they were adding a ton of complexity to client and server implementations ๐ญ. Legacy implementations MAY support them, but implementations conformant to this document MUST NOT rely on them. Dropping them doesn't cause interop drama when you mix updated and non-updated clients, relay agents, and servers, because they were "optional" all along ๐ซถ.
- IA_TA option. The Identity Association for Temporary Addresses option is obsoleted. If a client needs a short-term / special purpose address, it can use a new IA_NA binding to request one and release it when it's finished with it ๐ฆ.
- UNICAST option. The Server Unicast option is obsoleted. Honestly it was rarely practical, since relay agents between the client and server usually need to glean information from the communication and can't be bypassed ๐.
- UseMulticast status code. Also obsoleted. Clients will always multicast messages (since the Server Unicast option is gone), and servers will no longer check for unicast traffic ๐.
- Errata fixes. The following errata reports for [RFC8415] were incorporated: [Err6159], [Err6269], and [Err6183]. Note that EID 6269 was no longer applicable after the Server Unicast Option was obsoleted. Note that EID 6159 was also no longer applicable, since temporary addresses have been obsoleted. Indeed, the text that EID 6159 corrects has been deleted ๐.
- A missing reference. A reference to [RFC7943] was added to Section 13.1. It documents a method that might be used to generate addresses, and it got inadvertently missed when [RFC8415] was compiled ๐ง.
- Clearer ports. Clarified the UDP ports used by clients, servers, and relay agents (Section 7.2) โจ.
- Extra references and polish. Several additional RFCs have been referenced, and editorial and reviews comments were incorporated ๐.
Appendix B. Appearance of Options in Message Types ๐
The following tables indicate with a "*" the options that are allowed in each DHCP message type. Think of them as the cheat sheet for who's allowed where ๐.
These tables are informational. If they conflict with text earlier in this document, that text should be considered authoritative. So if the tables and the main text ever disagree, the main text wins, periodt ๐.
+=========+========+========+=====+=====+===+====+=====+=====+=====+
| | Client | Server |IA_NA|IA_PD|ORO|Pref|Elap.|Relay|Auth.|
| | ID | ID | | | | |Time |Msg. | |
+=========+========+========+=====+=====+===+====+=====+=====+=====+
| Solicit | * | | * | * | * | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Advert. | * | * | * | * | | * | | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Request | * | * | * | * | * | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Confirm | * | | * | | | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Renew | * | * | * | * | * | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Rebind | * | | * | * | * | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Decline | * | * | * | * | | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Release | * | * | * | * | | | * | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Reply | * | * | * | * | | | | | * |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Reconf | * | * | | | | | | | * |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| Inform. | * | (see | | | * | | * | | |
| | | note) | | | | | | | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| R-forw. | | | | | | | | * | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
| R-repl. | | | | | | | | * | |
+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
Table 4: Appearance of Options in Message Types (Part 1 of 3)NOTE: The Server Identifier option (see Section 21.3) is only included in Information-request messages that are sent in response to a Reconfigure (see Section 18.2.6). Pay attention to this one bestie, it's a sneaky little detail ๐.
+=======+======+=====+=====+======+======+======+======+======+=====+
| |Status|Rap. |User |Vendor|Vendor|Inter.|Recon.|Recon.|Info |
| |Code |Comm.|Class|Class |Spec. |ID |Msg. |Accept|Refr.|
| | | | | | | | | |Time |
+=======+======+=====+=====+======+======+======+======+======+=====+
|Solicit| | * | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Advert.| * | | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Request| | | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Confirm| | | * | * | * | | | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Renew | | | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Rebind | | | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Decline| | | * | * | * | | | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Release| | | * | * | * | | | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Reply | * | * | * | * | * | | | * | * |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Reconf.| | | | | | | * | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|Inform.| | | * | * | * | | | * | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|R-forw.| | | | | * | * | | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
|R-repl.| | | | | * | * | | | |
+=======+------+-----+-----+------+------+------+------+------+-----+
Table 5: Appearance of Options in Message Types (Part 2 of 3) +=========+============+============+
| | SOL_MAX_RT | INF_MAX_RT |
+=========+============+============+
| Solicit | | |
+=========+------------+------------+
| Advert. | * | |
+=========+------------+------------+
| Request | | |
+=========+------------+------------+
| Confirm | | |
+=========+------------+------------+
| Renew | | |
+=========+------------+------------+
| Rebind | | |
+=========+------------+------------+
| Decline | | |
+=========+------------+------------+
| Release | | |
+=========+------------+------------+
| Reply | * | * |
+=========+------------+------------+
| Reconf. | | |
+=========+------------+------------+
| Inform. | | |
+=========+------------+------------+
| R-forw. | | |
+=========+------------+------------+
| R-repl. | | |
+=========+------------+------------+
Table 6: Appearance of Options in
Message Types (Part 3 of 3)Appendix C. Appearance of Options in the "options" Field of DHCP Options ๐
okay so this table is basically your cheat sheet ๐ง It uses a "*" to show where each option from this document can show up as a top-level option, or get tucked inside another option. Other RFCs can add their own situations where options from this doc get wrapped up inside other options, so this isn't the whole story ๐
Also, the table is just informational. If it ever clashes with the text earlier in the document, that text wins, no debate ๐
+============+=====+=====+======+=====+==========+========+========+
| |Top- |IA_NA|IAADDR|IA_PD| IAPREFIX | RELAY- | RELAY- |
| |Level| | | | | FORW | REPL |
+============+=====+=====+======+=====+==========+========+========+
| Client ID | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Server ID | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| IA_NA | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| IAADDR | | * | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| IA_PD | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| IAPREFIX | | | | * | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| ORO | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Preference | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Elapsed | * | | | | | | |
| Time | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Relay | | | | | | * | * |
| Message | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Authentic. | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Status | * | * | | * | | | |
| Code | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Rapid | * | | | | | | |
| Comm. | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| User Class | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Vendor | * | | | | | | |
| Class | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Vendor | * | | | | | * | * |
| Info. | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Interf. | | | | | | * | * |
| ID | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Reconf. | * | | | | | | |
| MSG. | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Reconf. | * | | | | | | |
| Accept | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| Info | * | | | | | | |
| Refresh | | | | | | | |
| Time | | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| SOL_MAX_RT | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
| INF_MAX_RT | * | | | | | | |
+============+-----+-----+------+-----+----------+--------+--------+
Table 7: Appearance of OptionsNotes time ๐ Asterisked options in the Top-Level column show up in the options field of client messages (check out Section 8 for the details). Asterisked options in the RELAY-FORW and RELAY-REPL columns show up in the options field of the Relay-forward and Relay-reply messages (see Section 9) ๐ฆ
Acknowledgments ๐
Honestly this whole document is just a glow-up of earlier work, as described in [RFC8415] ๐ซถ
A bunch of people helped spot issues with [RFC8415] and deserve a huge shoutout: Fernando Gont, Felix Hamme, Rene Engel, Esko Dijk, Jen Linkova, Tomoyuki Sahara, and Ted Lemon ๐ธ
Thank you to the thorough, thoughtful reviewers from the IETF process, especially Mohamed Boucadair, Tim Chown, Roman Danyliw, Tatuya Jinmei, Jim Read, Ketan Talaulikar, รric Vyncke, and Dave Worley. Thanks also to the DHC WG members for reviewing this updated doc ๐
And a massive special thank you to Suresh Krishnan for shepherding this document through the IETF process ๐
Authors' Addresses ๐
Here are the authors' details, copied exactly so you can reach out ๐
Tomek Mrugalski
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America
Email: tomasz.mrugalski@gmail.com
Bernie Volz
Individual Contributor
116 Hawkins Pond Road
Center Harbor, NH 03226
United States of America
Email: bevolz@gmail.com
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa ON K1Z 5V7
Canada
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/
Sheng Jiang
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Haidian District, Beijing
China
Email: shengjiang@bupt.edu.cn
Timothy Winters
QA Cafe
100 Main Street, Suite #212
Dover, NH 03820
United States of America
Email: tim@qacafe.com๐ฆ where this page comes from
- ietf: rfc9915 2026-01
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms