RFC 3315
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 💖
Part 1 of 21 🎀
Okay bestie, this is the title block, and it's giving serious standards-track energy 🧚. Here's the tea:
- Number: RFC 3315 🦋
- Working group: Network Working Group
- Editor: R. Droms, Ed., from Cisco 👑
- Other authors: J. Bound (Hewlett Packard), B. Volz (Ericsson), T. Lemon (Nominum), C. Perkins (Nokia Research Center), and M. Carney (Sun Microsystems) 🫶
- Category: Standards Track ✨
- Date: July 2003 🌸
- Obsoletes and updates: The title block doesn't list anything this RFC obsoletes or updates 🙈
Six people wrote this together, which is honestly iconic 😭.
Status of this Memo 💅
Okay so this section is the official "what kind of document is this" part. This document specifies an Internet standards track protocol for the Internet community, and it's literally asking everyone to chime in with discussion and suggestions for improvements 💬. If you want the current standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with everyone you know 🌈.
Copyright Notice 🔥
Copyright (C) The Internet Society (2003). All Rights Reserved. ✨
Abstract 🧚
Okay, the main vibe: the Dynamic Host Configuration Protocol for IPv6 (DHCP) lets DHCP servers pass configuration parameters, like IPv6 network addresses, over to IPv6 nodes 💖. It's giving automatic allocation of reusable network addresses plus extra configuration flexibility 🦋, which is so useful, ngl.
It's also the stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 2462) 👑. The cute part is that you can use DHCP on its own, or run it alongside RFC 2462 to get your configuration parameters 🫶. Main character energy for sure 💜.
Table of Contents 🗺️
okay bestie, this is the map of the whole spec, so let's see where everything lives 💖 section numbers and page numbers stay exactly as they are so you can find everything 🫶
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Protocols and Addressing . . . . . . . . . . . . . . . 6
1.2. Client-server Exchanges Involving Two Messages . . . . 6
1.3. Client-server Exchanges Involving Four Messages. . . . 7
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Background. . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . 9
4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . 10
5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 13
5.2. UDP Ports. . . . . . . . . . . . . . . . . . . . . . . 13
5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . 13
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15
5.5. Transmission and Retransmission Parameters . . . . . . 16
5.6 Representation of time values and "Infinity" as a time
value. . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Client/Server Message Formats . . . . . . . . . . . . . . . . 16
7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17
7.1. Relay-forward Message. . . . . . . . . . . . . . . . . 18
7.2. Relay-reply Message. . . . . . . . . . . . . . . . . . 19
8. Representation and Use of Domain Names. . . . . . . . . . . . 19
9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19
9.1. DUID Contents. . . . . . . . . . . . . . . . . . . . . 20
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20
9.3. DUID Assigned by Vendor Based on Enterprise Number
[DUID-EN]. . . . . . . . . . . . . . . . . . . . . . . 22
9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . 22
10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23
11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24
12. Management of Temporary Addresses . . . . . . . . . . . . . . 25
13. Transmission of Messages by a Client. . . . . . . . . . . . . 25
14. Reliability of Client Initiated Message Exchanges . . . . . . 26
15. Message Validation. . . . . . . . . . . . . . . . . . . . . . 27
15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . 28
15.2. Solicit Message. . . . . . . . . . . . . . . . . . . . 28
15.3. Advertise Message. . . . . . . . . . . . . . . . . . . 28
15.4. Request Message. . . . . . . . . . . . . . . . . . . . 29
15.5. Confirm Message. . . . . . . . . . . . . . . . . . . . 29
15.6. Renew Message. . . . . . . . . . . . . . . . . . . . . 29
15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . 29
15.8. Decline Messages . . . . . . . . . . . . . . . . . . . 30
15.9. Release Message. . . . . . . . . . . . . . . . . . . . 30
15.10. Reply Message. . . . . . . . . . . . . . . . . . . . . 30
15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31
15.12. Information-request Message. . . . . . . . . . . . . . 31
15.13. Relay-forward Message. . . . . . . . . . . . . . . . . 31
15.14. Relay-reply Message. . . . . . . . . . . . . . . . . . 31
16. Client Source Address and Interface Selection . . . . . . . . 32
17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . . 32
17.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 32
17.1.1. Creation of Solicit Messages . . . . . . . . . 32
17.1.2. Transmission of Solicit Messages . . . . . . . 33
17.1.3. Receipt of Advertise Messages. . . . . . . . . 35
17.1.4. Receipt of Reply Message . . . . . . . . . . . 35
17.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 36
17.2.1. Receipt of Solicit Messages . . . . . . . . . 36
17.2.2. Creation and Transmission of Advertise Messages 36
17.2.3. Creation and Transmission of Reply Messages. . 38
18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38
18.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 39
18.1.1. Creation and Transmission of Request Messages. 39
18.1.2. Creation and Transmission of Confirm Messages. 40
18.1.3. Creation and Transmission of Renew Messages. . 41
18.1.4. Creation and Transmission of Rebind Messages . 43
18.1.5. Creation and Transmission of Information-
request Messages . . .. . . . . . . . . . . . 44
18.1.6. Creation and Transmission of Release Messages. 44
18.1.7. Creation and Transmission of Decline Messages. 46
18.1.8. Receipt of Reply Messages. . . . . . . . . . . 46
18.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 48
18.2.1. Receipt of Request Messages. . . . . . . . . . 49
18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50
18.2.3. Receipt of Renew Messages. . . . . . . . . . . 51
18.2.4. Receipt of Rebind Messages . . . . . . . . . . 51
18.2.5. Receipt of Information-request Messages. . . . 52
18.2.6. Receipt of Release Messages. . . . . . . . . . 53
18.2.7. Receipt of Decline Messages. . . . . . . . . . 53
18.2.8. Transmission of Reply Messages . . . . . . . . 54
19. DHCP Server-Initiated Configuration Exchange. . . . . . . . . 54
19.1. Server Behavior. . . . . . . . . . . . . . . . . . . . 55
19.1.1. Creation and Transmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 55
19.1.2. Time Out and Retransmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 56
19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56
19.3. Receipt of Information-request Messages. . . . . . . . 56
19.4. Client Behavior. . . . . . . . . . . . . . . . . . . . 57
19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57
19.4.2. Creation and Transmission of Renew Messages. . 58
19.4.3. Creation and Transmission of Information-
request Messages . . . . . . . . . . . . . . . 58
19.4.4. Time Out and Retransmission of Renew or
Information-request Messages . . . . . . . . . 58
19.4.5. Receipt of Reply Messages. . . . . . . . . . . 58
20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . . 58
20.1. Relaying a Client Message or a Relay-forward Message . 59
20.1.1. Relaying a Message from a Client . . . . . . . 59
20.1.2. Relaying a Message from a Relay Agent. . . . . 59
20.2. Relaying a Relay-reply Message . . . . . . . . . . . . 60
20.3. Construction of Relay-reply Messages . . . . . . . . . 60
21. Authentication of DHCP Messages . . . . . . . . . . . . . . . 61
21.1. Security of Messages Sent Between Servers and Relay
Agents . . . . . . . . . . . . . . . . . . . . . . . 61
21.2. Summary of DHCP Authentication . . . . . . . . . . . . 63
21.3. Replay Detection . . . . . . . . . . . . . . . . . . . 63
21.4. Delayed Authentication Protocol. . . . . . . . . . . . 63
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol. . . . . . . . . . . . 64
21.4.2. Message Validation . . . . . . . . . . . . . . 65
21.4.3. Key Utilization . . . . . . . . . . . . . . . 65
21.4.4. Client Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 66
21.4.5. Server Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 67
21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68
21.5.1. Use of the Authentication Option in the
Reconfigure Key Authentication Protocol. . . . 69
21.5.2. Server considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 69
21.5.3. Client considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 70
22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . 70
22.1. Format of DHCP Options . . . . . . . . . . . . . . . . 71
22.2. Client Identifier Option . . . . . . . . . . . . . . . 71
22.3. Server Identifier Option . . . . . . . . . . . . . . . 72
22.4. Identity Association for Non-temporary Addresses Option 72
22.5. Identity Association for Temporary Addresses Option. . 75
22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76
22.7. Option Request Option. . . . . . . . . . . . . . . . . 78
22.8. Preference Option. . . . . . . . . . . . . . . . . . . 79
22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79
22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80
22.11. Authentication Option. . . . . . . . . . . . . . . . . 81
22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82
22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82
22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83
22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84
22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85
22.17. Vendor-specific Information Option . . . . . . . . . . 86
22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87
22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88
22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89
23. Security Considerations . . . . . . . . . . . . . . . . . . . 89
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92
24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . 93
24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . 94
24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95
24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . 95
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96
26.1. Normative References . . . . . . . . . . . . . . . . . 96
26.2. Informative References . . . . . . . . . . . . . . . . 97
A. Appearance of Options in Message Types . . . . . . . . . . . . 98
B. Appearance of Options in the Options Field of DHCP Options . . 99
Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 1011. Introduction and Overview ✨
okay so this doc is about DHCP for IPv6 (aka DHCP 💖), a client/server protocol for managed configuration of devices 🎀
DHCP can hand a device addresses from a DHCP server, plus other config info that rides along in options 🧚 and you can extend it by defining new options for stuff this doc doesn't cover yet 🌈
DHCP is the "stateful address autoconfiguration protocol" and the "stateful autoconfiguration protocol" mentioned in "IPv6 Stateless Address Autoconfiguration" [17] 🦋
the operational models and config info for DHCPv4 [18][19] and DHCPv6 are different enough that integrating the two isn't included here 🙈 if there's enough interest and demand, someone could write a doc that extends DHCPv6 to carry IPv4 addresses and config info 👑
the rest of this intro gives you the summary: how the messages get exchanged, plus example flows 💅 the flows in sections 1.2 and 1.3 are just illustrations, not a complete list of every possible client-server interaction ✨ if you want the full detailed play-by-play for client and server, look at Sections 17, 18, and 19 🫶
1.1. Protocols and Addressing
clients and servers swap DHCP messages using UDP [15] 🌸 the client uses a link-local address (or addresses figured out some other way) to send and receive DHCP messages 🦋
DHCP servers receive messages from clients on a reserved, link-scoped multicast address 💜 most of the time the client sends to that reserved multicast address, so it doesn't need to be configured with the address(es) of any DHCP servers. iconic, honestly 👑
now, what if the server isn't on the same link as the client? 🤔 that's where a DHCP relay agent comes in. it sits on the client's link and relays messages between the client and server 🧚 the client doesn't even notice the relay agent, so the message exchanges in the rest of this section skip over the relaying part 🙈
once the client has figured out a server's address, it may, under some circumstances, send messages straight to that server using unicast 💖
1.2. Client-server Exchanges Involving Two Messages
when a DHCP client doesn't need a server to assign it IP addresses, it can still grab config info, like a list of DNS servers [20] or NTP servers [21], in one message and one reply 🍓 to do that, the client first sends an Information-Request message to the All_DHCP_Relay_Agents_and_Servers multicast address ✨ then the servers respond with a Reply message carrying the config info for the client 💅
this exchange assumes the client only needs configuration information and doesn't need any IPv6 addresses assigned 🫶
now, when a server already has IPv6 addresses and other config info committed to a client, they might be able to finish the whole thing in just two messages instead of the four we'll see in the next section 🔥 here's how it goes: the client sends a Solicit message to All_DHCP_Relay_Agents_and_Servers asking for addresses and other config info 💜 that message also says the client is willing to accept an immediate Reply 🦋 the server that's willing to commit the addresses right away responds with a Reply message 👑 and then the config info and addresses in that Reply are immediately ready for the client to use 🎀
each address given to the client has preferred and valid lifetimes set by the server 🌈 if the client wants to extend those lifetimes, it sends a Renew message to the server ⭐ the server replies with the new lifetimes, so the client keeps using the address without any interruption 💖
1.3. Client-server Exchanges Involving Four Messages
to ask for one or more IPv6 addresses, a client first has to find a DHCP server, and then request addresses and other config info from that server 🧚 the client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers address to look for available DHCP servers 🔍 any server that can meet the client's requirements answers with an Advertise message 💅 the client picks one of those servers and sends it a Request message asking for confirmed assignment of addresses and other config info 🫶 the server responds with a Reply message containing the confirmed addresses and config 🌸
like we said in the previous section, the client sends a Renew message to the server to extend the lifetimes on its addresses, so it can keep using them without interruption ✨
2. Requirements 🎀
the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be interpreted as described in [1] 💅 this is the rulebook, bestie, so pay attention to those words 😭
this document also uses internal conceptual variables to describe protocol behavior, and external variables that an implementation must let system administrators change 🧚 the specific variable names, how their values change, and how their settings influence behavior are given to demonstrate the protocol behavior 💜 an implementation doesn't have to match the exact form described here, as long as its external behavior is consistent with what this document describes 🦋
3. Background 🌈
the IPv6 Specification gives the base architecture and design of IPv6 🌸 the related IPv6 work an implementor should study includes the IPv6 Specification [3], the IPv6 Addressing Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6 Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22] 🫶 these specs let DHCP build on top of IPv6 to deliver both robust stateful autoconfiguration and autoregistration of DNS Host Names 👑
the IPv6 Addressing Architecture [5] defines the address scopes you can use in an IPv6 implementation, plus the various configuration architecture guidelines for network designers working with the IPv6 address space 💅 two IPv6 advantages: multicast support is required, and nodes can create link-local addresses during initialization ✨ because of that, a client can use its link-local address and a well-known multicast address to find and talk to DHCP servers or relay agents on its link 🦋
IPv6 Stateless Address Autoconfiguration [17] specifies how a node may autoconfigure addresses based on router advertisements [13], and how a valid lifetime supports renumbering of addresses on the Internet 🍓 it also specifies how a node's protocol interaction begins stateless or stateful autoconfiguration 🧚 DHCP is one vehicle for stateful autoconfiguration, and being compatible with stateless address autoconfiguration is a design requirement of DHCP 💖
IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6, and it replaces and enhances the functions of ARP [14] 🎀 to understand IPv6 and stateless address autoconfiguration, it is strongly recommended that implementors understand IPv6 Neighbor Discovery 🌸
Dynamic Updates to DNS [22] is a spec that supports dynamic updates of DNS records for both IPv4 and IPv6 🔥 DHCP can use those dynamic DNS updates to integrate addresses and the name space, which supports not just autoconfiguration but also autoregistration in IPv6 👑
4. Terminology 💜
this section defines the terminology specific to IPv6 and DHCP that's used in this document 💅
4.1. IPv6 Terminology 🦋
the IPv6 terms relevant to this spec, taken from the IPv6 Protocol [3], the IPv6 Addressing Architecture [5], and IPv6 Stateless Address Autoconfiguration [17], are included below 🌈
address An IP layer identifier for an interface
or a set of interfaces.
host Any node that is not a router.
IP Internet Protocol Version 6 (IPv6). The
terms IPv4 and IPv6 are used only in
contexts where it is 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, i.e., the layer immediately
below IP. Examples are Ethernet (simple
or bridged); Token Ring; PPP links,
X.25, Frame Relay, or ATM networks; and
Internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6
itself.
link-layer identifier A link-layer identifier for an
interface. Examples include IEEE 802
addresses for Ethernet or Token Ring
network interfaces, and E.164 addresses
for ISDN links.
link-local address An IPv6 address having a link-only
scope, indicated by having the prefix
(FE80::/10), that can be used to reach
neighboring nodes attached to the same
link. Every interface 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.
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 part is the DHCP glossary, and you know I love a good glossary 🤓💖 here's the DHCP-specific vocab you need, bestie:
appropriate to the link 🦋 an address is "appropriate to the link" when it's consistent with what the DHCP server knows about the network topology, prefix assignment, and address assignment policies. basically it fits the network the server actually knows about 💅
binding 🍓 a binding (aka client binding) is a group of server data records holding what the server knows about the addresses in an IA, or about configuration info that was explicitly assigned to the client. config info handed out through a policy, like what every client on the same link gets, does NOT need a binding 🙅♀️ a binding for an IA is indexed by the tuple <DUID, IA-type, IAID>, where IA-type is the kind of address in the IA (temporary, for example). a binding for plain config info is indexed by <DUID> ✨
configuration parameter ⚙️ an element of the config info set on the server and delivered to the client over DHCP. these can carry stuff a node uses to set up its network subsystem and get talking on a link or internetwork, for example 🌈
DHCP 🎀 Dynamic Host Configuration Protocol for IPv6. the terms DHCPv4 and DHCPv6 only get used where it's needed to avoid confusion 🫶
DHCP client (or client) 💜 a node that starts requests on a link to get configuration parameters from one or more DHCP servers 📬
DHCP domain 🌸 a set of links managed by DHCP and run by one administrative entity 👑
DHCP realm 🔐 a name that identifies the DHCP administrative domain a DHCP authentication key was picked from 🗝️
DHCP relay agent (or relay agent) 🧚 a node that acts as the middle-person for delivering DHCP messages between clients and servers. it's on the same link as the client 🫶
DHCP server (or server) 🌟 a node that answers requests from clients, and it may or may not be on the same link as the client(s) 🤷♀️
DUID 🪪 a DHCP Unique IDentifier for a DHCP participant. every DHCP client and server has exactly one DUID ✨ see section 9 for the details on how a DUID can be built 📖
Identity association (IA) 🧁 a collection of addresses assigned to a client. each IA has an associated IAID, and a client can have more than one IA, for example one per interface 🌈
each IA holds one type of address. for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses") 🦋 throughout this document, "IA" is used to mean an identity association without saying which type of addresses it holds 💅
Identity association identifier (IAID) 🎫 an identifier for an IA, chosen by the client. every IA gets an IAID, and it's chosen to be unique among all the IAIDs for IAs belonging to that client 🔑
Identity association for non-temporary addresses (IA_NA) 🏡 an IA that carries assigned addresses which aren't temporary addresses (see "identity association for temporary addresses") 💖
Identity association for temporary addresses (IA_TA) 🫧 an IA that carries temporary addresses (see RFC 3041 [12]) 🙈
message 💌 a unit of data carried as the payload of a UDP datagram, exchanged among DHCP servers, relay agents, and clients 📦
Reconfigure key 🗝️ a key a server gives to a client, used to provide security for Reconfigure messages 🔥
relaying 📨 a DHCP relay agent relays DHCP messages between DHCP participants. that's the whole job, and it's iconic 👑
transaction ID 🪄 an opaque value used to match responses with replies, whether they were started by a client or a server 🎀
5. DHCP Constants ✨
this section covers the program and networking constants DHCP uses 🧮💜
5.1. Multicast Addresses 📡
DHCP uses the following multicast addresses:
All_DHCP_Relay_Agents_and_Servers (FF02::1:2) 🌐 a link-scoped multicast address clients use to talk to neighboring (aka on-link) relay agents and servers. all servers and relay agents are members of this group 🫶
All_DHCP_Servers (FF05::1:3) 🏘️ a site-scoped multicast address relay agents use to talk to servers. they do this either because they want to send messages to all servers, or because they don't know the servers' unicast addresses 🤷♀️ heads up: for a relay agent to use this address, it has to have an address with enough scope to be reachable by the servers ⚠️ all servers within the site are members of this group 💅
5.2. UDP Ports 🔌
clients listen for DHCP messages on UDP port 546 🎧 servers and relay agents listen for DHCP messages on UDP port 547 🎧✨
5.3. DHCP Message Types ✨
DHCP has a bunch of message types, and you'll want to know them all 💅 More detail on each one lives in sections 6 and 7. Any message type that isn't on this list is reserved for future use 🔮 The number in parentheses is the numeric encoding for each type.
SOLICIT (1): A client sends a Solicit message to find servers 🔍ADVERTISE (2): A server sends an Advertise message to say it's open for DHCP business, as a reply to a Solicit from a client 📣REQUEST (3): A client sends a Request message to ask a specific server for configuration parameters, including IP addresses 🙋♀️CONFIRM (4): A client sends a Confirm message to any available server to check whether the addresses it got are still right for the link it's connected to 🧐RENEW (5): A client sends a Renew message to the server that originally gave it its addresses and configuration parameters. This extends the lifetimes on those addresses and updates other parameters 🔁REBIND (6): A client sends a Rebind message to any available server to extend the lifetimes on its addresses and update other parameters. This one goes out after the client gets no response to a Renew message 😬REPLY (7): A server sends a Reply message in a few different situations. It can carry assigned addresses and configuration parameters, answering a Solicit, Request, Renew, or Rebind from a client. It can carry configuration parameters only, answering an Information-request. It can confirm or deny that a client's addresses still suit its link, answering a Confirm. And it can acknowledge a Release or Decline 🎀RELEASE (8): A client sends a Release message to the server that assigned its addresses, saying it's done using 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 of the server's addresses are already in use on the link it's connected to 🚫RECONFIGURE (10): A server sends a Reconfigure message to a client to say it has new or updated configuration parameters. The client then starts a Renew/Reply or Information-request/Reply exchange with the server to grab the updated info 🔔INFORMATION-REQUEST (11): A client sends an Information-request message to a server to ask for configuration parameters, without getting any IP addresses 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 message it received, whether that's a client message or a Relay-forward from another relay agent, gets wrapped up as an option inside the Relay-forward 🎁RELAY-REPL (13): A server sends a Relay-reply message to a relay agent, carrying a message the relay agent hands off to a client. The Relay-reply can be passed along by other relay agents until it reaches the destination relay agent 🔄
The server wraps the client message up as an option inside the Relay-reply, and the relay agent unwraps it and forwards it to the client 🫶
5.4. Status Codes 🚦
DHCPv6 uses status codes to say whether the operations clients and servers asked for worked out, and to explain exactly why something failed. The specific status codes are defined in section 24.4 📖
5.5. Transmission and Retransmission Parameters ⏱️
This section has a table of values that describe how clients and servers handle sending and resending their messages. Here it is, exactly as written:
Parameter Default Description
-------------------------------------
SOL_MAX_DELAY 1 sec Max delay of first Solicit
SOL_TIMEOUT 1 sec Initial Solicit timeout
SOL_MAX_RT 120 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 120 secs Max Information-request timeout value
REL_TIMEOUT 1 sec Initial Release timeout
REL_MAX_RC 5 MAX Release attempts
DEC_TIMEOUT 1 sec Initial Decline timeout
DEC_MAX_RC 5 Max Decline attempts
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message5.6 Representation of time values and "Infinity" as a time value ⏳
All time values for lifetimes, T1, and T2 are unsigned integers 🔢 The value 0xffffffff means "infinity" when it's used as a lifetime (as in RFC2461 [17]) or as a value for T1 or T2 🌈
6. Client/Server Message Formats 💌
Every DHCP message sent between clients and servers has the same fixed-format header, followed by 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 any other way, like on 2 or 4 byte boundaries 🧩
Here's the diagram of the format of 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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 👇
msg-type: Identifies the DHCP message type. The available message types are listed in section 5.3.transaction-id: The transaction ID for this message exchange.options: The options carried in this message. Options are described in section 22.
7. Relay Agent/Server Message Formats 🦋
Relay agents talk to servers to pass messages between clients and servers that aren't on the same link 🌉
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 any other way, like on 2 or 4 byte boundaries 🧩
There are two relay agent messages, and they share the following 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) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The following sections describe how to use the Relay Agent message header 📚
7.1. Relay-forward Message 💫
The table below defines how the message fields get used in a Relay-forward message 🎯
msg-type RELAY-FORW
hop-count Number of relay agents that have relayed this
message.
link-address A global or site-local address that will be used by
the server to identify the link on which the client
is located.
peer-address The address of the client or relay agent from which
the message to be relayed was received.
options MUST include a "Relay Message option" (see
section 22.10); MAY include other options added by
the relay agent.7.2. Relay-reply Message 💌
okay so the Relay-reply is the message that heads back out, and this table is basically the cheat sheet for what each field has to say 💅
msg-type RELAY-REPL
hop-count Copied from the Relay-forward message
link-address Copied from the Relay-forward message
peer-address Copied from the Relay-forward message
options MUST include a "Relay Message option"; see
section 22.10; MAY include other options8. Representation and Use of Domain Names 🌸
so domain names need to be encoded the same way everywhere, bestie 🧚. a domain name, or a whole list of them, gets encoded with the technique from section 3.1 of RFC 1035 [10]. and here's the big one: a domain name, or list of domain names, in DHCP MUST NOT be stored in compressed form, the way section 4.1.4 of RFC 1035 describes. no compression allowed, periodt 🙅♀️
9. DHCP Unique Identifier (DUID) 🦋
every DHCP client and server has a DUID, and it's literally their main character identifier 👑. servers use DUIDs to figure out who's who when picking configuration parameters and linking IAs to clients. clients use DUIDs to identify a server whenever a server needs to be pointed out. check out sections 22.2 and 22.3 to see how a DUID shows up inside a DHCP message 📨.
okay, the rules are strict here 😤. clients and servers MUST treat DUIDs as opaque values, and they MUST only compare DUIDs for equality. they MUST NOT in any other way interpret DUIDs. and clients and servers MUST NOT restrict DUIDs to the types defined in this document, because additional DUID types may be defined in the future 🔮
the DUID gets carried in an option because it may be variable length, and because it isn't required in every DHCP message. the goal is a DUID that's 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 should not change just because its network hardware changed 🫶
the reason there's more than one type of DUID is that the DUID has to be globally unique and also easy to generate. the kind of globally-unique identifier that's easy to make can look wildly different from device to device 🌈. plus, some devices have no persistent storage at all. they can't keep a generated DUID around, so the DUID scheme has to work for those devices too 💜
9.1. DUID Contents 🎀
a DUID is a two-octet type code in network byte order, followed by a variable number of octets that make up the actual identifier. a DUID can be no more than 128 octets long, not counting the type code. these are the types that are currently defined:
1 Link-layer address plus time
2 Vendor-assigned unique ID based on Enterprise Number
3 Link-layer addressthe format of the variable field for each of the types above is shown below 👇
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] ⏰
this type of DUID is the time-based one, and it's giving very structured 🍓. it starts with a two octet type field containing the value 1, then a two octet hardware type code, then four 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 moment 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 the IANA, as described in RFC 826 [14]. both the time and the hardware type are stored in network byte order, and the link-layer address is stored in canonical form, as described in RFC 2464 [2].
here's the diagram for a DUID-LLT 📐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+you can pick whichever network interface you want, totally arbitrary 🙌, as long as that interface gives a globally unique link-layer address for its link type. and the same DUID-LLT SHOULD be used when configuring all network interfaces connected to the device, no matter which interface's link-layer address was used to generate the DUID-LLT ✨
now the storage drama 😭. clients and servers using this type of DUID MUST store the DUID-LLT in stable storage, and they 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. no exceptions, bestie 💀
clients and servers that use this DUID SHOULD attempt to configure the time before generating the DUID, if that's possible. and they MUST use some sort of time source (a real-time clock, for example) 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 when the network interface is moved from one client to another client that then uses the same interface. even if the clocks weren't configured before generating the DUID, a collision between two DUID-LLTs is very unlikely 🥰
this way of generating a DUID is recommended for all general purpose computing devices, like desktop computers and laptop computers, and also for devices like printers, routers, and so on, that contain some form of writable non-volatile storage 🖨️
despite our best efforts 🥲, it's possible that this algorithm could still result in a client identifier collision. so a DHCP client that generates a DUID-LLT using this mechanism MUST provide an administrative interface that replaces the existing DUID with a newly-generated DUID-LLT. that's the safety net 🧯
9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN] 🏭
this one is assigned by the vendor to the device, so it's basically their signature 🖊️. it's made up of the vendor's registered Private Enterprise Number, as maintained by IANA [6], followed by a unique identifier the vendor assigns. here's the structure at a glance:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the vendor decides where the identifier comes from, but each identifier part of each DUID-EN MUST be unique to the device using it. it MUST also be assigned to the device when it's manufactured and stored in some form of non-volatile storage. the generated DUID SHOULD be recorded in non-erasable storage 🔒. the enterprise-number is that vendor's registered Private Enterprise Number, as maintained by IANA [6], and it's stored as an unsigned 32 bit number 🔢
here's an example DUID of this type 👀
+---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 | 0 | 9| 12|192|
+---+---+---+---+---+---+---+---+
|132|221| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+so this example has the two-octet type of 2, the Enterprise Number (9), and then eight octets of identifier data (0x0CC084D303000912). the vibes are immaculate 🌟
9.4. DUID Based on Link-layer Address [DUID-LL] 🔗
this type of DUID is two octets containing the DUID type 3, then a two octet network hardware type code, followed by the link-layer address of any one network interface that's permanently connected to the client or server device. for example, a host 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 the IANA, as described in RFC 826 [14]. the hardware type is stored in network byte order, and the link-layer address is stored in canonical form, as described in RFC 2464 [2]. here's the diagram for 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the network interface choice is completely arbitrary, as long as that interface provides a unique link-layer address and is permanently attached to the device where the DUID-LL is being generated. and the same DUID-LL SHOULD be used when configuring all network interfaces connected to the device, no matter which interface's link-layer address was used to generate the DUID 💖
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 🌷. and DUID-LL MUST NOT be used by DHCP clients or servers that can't tell whether or not a network interface is permanently attached to the device the DHCP client is running on 🙅♀️
10. Identity Association ✨
okay so bestie, an "identity-association" (IA) 🎀 is basically a little construct that lets a server and a client identify, group, and manage a whole set of related IPv6 addresses together 🦋. Each IA is made of an IAID plus its configuration info, and honestly it's giving organised binder energy 💅.
A client MUST associate at least one distinct IA with each of its network interfaces that it wants IPv6 addresses for from a DHCP server 🌸. The client then uses the IAs tied to an interface to grab configuration info from a server for that interface. Each IA MUST be associated with exactly one interface, no exceptions bestie 👑.
The IAID uniquely identifies the IA and has to be unique among the IAIDs on the client 🔥. The client picks the IAID itself. For any given use of an IA, the IAID for that IA MUST stay consistent across restarts of the DHCP client 💖. The client can keep it consistent either by saving the IAID in non-volatile storage, or by using an algorithm that reliably spits out the same IAID as long as the client's configuration hasn't changed 🧚. Lowkey, there may be no way for a client to keep its IAIDs consistent if it has no non-volatile storage AND its hardware configuration changes 💀.
The configuration info in an IA is one or more IPv6 addresses along with the times T1 and T2 for that IA ⭐. See section 22.4 for how an IA shows up in a DHCP message 🫶.
Each address in an IA has a preferred lifetime and a valid lifetime, as defined in RFC 2462 [17] 🌈. The server sends these lifetimes to the client in the IA option, and they apply to how IPv6 addresses get used, as described in section 5.5.4 of RFC 2462 ✨.
11. Selecting Addresses for Assignment to an IA 🦋
ngl this section is where the server gets to be a detective 🕵️♀️. A server picks addresses for an IA based on the address assignment policies its administrator set, plus whatever it figures out about the client from some combo 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 🎀.
- If the server gets the message directly from the client AND the source address in the IP datagram is NOT a link-local address, then the client is on the link identified by that source address 👀. (Btw this can only happen if the server has enabled unicast message delivery for the client AND the client sent a message where unicast delivery is allowed 🙈.)
- The DUID supplied by the client. 💜
- Other info in options supplied by the client. 🍓
- Other info in options supplied by the relay agent. 🧚
Any address a server assigns that's based on an EUI-64 identifier MUST include an interface identifier with the "u" (universal/local) and "g" (individual/group) bits set appropriately, as indicated in section 2.5.1 of RFC 2373 [5] 💅.
A server MUST NOT assign an address that's reserved for some other purpose 🚫. For example, a server MUST NOT assign reserved anycast addresses, as defined in RFC 2526, from any subnet 💀.
12. Management of Temporary Addresses 🌈
A client MAY request temporary addresses (see RFC 3041 [12] for the definition of temporary addresses) 🦋. DHCPv6 handles address assignment the same way for temporary addresses, no difference at all ✨. DHCPv6 says nothing about the details of temporary addresses, like lifetimes, how clients use them, or the rules for generating successive temporary addresses, etc 🙃.
Clients ask for temporary addresses and servers assign them 🎀. Temporary addresses are carried in the Identity Association for Temporary Addresses (IA_TA) option (see section 22.5) 💖. Each IA_TA option contains at most one temporary address for each of the prefixes on the link the client is attached to 🌸.
The IAID number space for the IA_TA option is separate from the IA_NA option IAID number space 🧚.
The server MAY update the DNS for a temporary address, as described in section 4 of RFC 3041 👑.
13. Transmission of Messages by a Client 📬
Unless this document says otherwise, or a document describing how IPv6 is carried over a specific link type says otherwise (for link types that don't support multicast), a client sends DHCP messages to the All_DHCP_Relay_Agents_and_Servers 🌍.
A client uses multicast to reach all servers or one individual server 🦋. An individual server gets targeted by putting that server's DUID in a Server Identifier option (see section 22.3) in the client's message 🎯. All servers will receive that message, but only the indicated server will respond 👑. If the option isn't supplied, that means all servers 🫶.
A client MAY send some messages directly to a server using unicast, as described in section 22.12 💌.
14. Reliability of Client Initiated Message Exchanges 🔁
DHCP clients are responsible for reliable delivery of messages in the client-initiated message exchanges described in sections 17 and 18 🫶. If a DHCP client doesn't get an expected response from a server, the client MUST retransmit its message 😭. This section explains the retransmission strategy clients use in client-initiated message exchanges 💅.
Quick heads up: the procedure here is slightly modified when used with the Solicit message 👀. The modified version is in section 17.1.2 ✨.
The client starts the message exchange by sending a message to the server 🚀. The exchange ends when either the client successfully gets the appropriate response(s) from a server or servers, OR when the exchange is considered to have failed under the retransmission mechanism below 🦋.
The client's retransmission behaviour is controlled by these variables 🎀:
RT Retransmission timeout
IRT Initial retransmission time
MRC Maximum retransmission count
MRT Maximum retransmission time
MRD Maximum retransmission duration
RAND Randomization factor
With each message transmission or retransmission, the client sets RT according to the rules below 🧮. If RT expires before the 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 minimise synchronisation of messages sent by DHCP clients 🌈.
The algorithm for choosing a random number does NOT need to be cryptographically sound 🙈. The algorithm 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*IRT
RT for each subsequent message transmission is based on the previous value of RT ✨:
RT = 2*RTprev + RAND*RTprev
MRT sets an upper bound on the value of RT (ignoring the randomization added by RAND) 💅. If MRT has a value of 0, there's no upper limit on RT. Otherwise 👇:
if (RT > MRT) RT = MRT + RAND*MRT
MRC sets an upper bound on how many times a client can 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 can 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 conditions in the previous two paragraphs is met 🙅♀️.
If both MRC and MRD are zero, the client keeps transmitting the message until it receives a response 🥹.
15. Message Validation 🔍
Clients and servers SHOULD discard any messages containing options that aren't allowed to appear in the received message 🗑️. For example, an IA option isn't allowed in an Information-request message 🙅♀️. Clients and servers MAY choose to extract information from such a message if the information is useful to the recipient 🎁.
A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address 🚫.
Message validation based on DHCP authentication is discussed in section 21.4.2 🔐.
If a server receives a message that has options it shouldn't contain (like an Information-request message with an IA option), is missing options it should contain, or is otherwise not valid, it MAY send a Reply (or Advertise, as appropriate) 📨. That response can include a Server Identifier option, a Client Identifier option if one was in the message, and a Status Code option with status UnSpecFail 🫠.
15.1. Use of Transaction IDs 🆔
The "transaction-id" field holds a value that clients and servers use to synchronise 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 🎲. Lowkey, if a client generates easily predictable transaction IDs, it may become more vulnerable to certain attacks from off-path intruders 😱. A client MUST leave the transaction ID unchanged in retransmissions of a message 🔒.
15.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 🗑️.
15.3. Advertise Message 📣
Clients MUST discard any received Advertise messages that meet any of the following conditions 👇:
- the message does not include a Server Identifier option.
- the message does not include a Client Identifier option.
- 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 🚫.
15.4. Request Message 🙋♀️
Clients MUST discard any received Request messages 🗑️.
Servers MUST discard any received Request messages that meet any of the following conditions 👇:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option do not match the server's DUID.
- the message does not include a Client Identifier option.
15.5. Confirm Message 🧐
Clients MUST discard any received Confirm messages 🙅♀️.
Servers MUST discard any received Confirm messages that do not include a Client Identifier option, or that DO include a Server Identifier option 🫶.
15.6. Renew Message 💖
Okay bestie, clients MUST discard any Renew messages they receive. No exceptions 💅
Servers have a checklist too. A server MUST discard any received Renew message that meets any of these conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option.
15.7. Rebind Message 🦋
Clients MUST discard any received Rebind messages. Servers MUST discard any received Rebind messages that do not include a Client Identifier option or that do include a Server Identifier option. Yikes for anyone who gets it wrong 😭
15.8. Decline Messages 🌸
Clients MUST discard any received Decline messages, periodt ✨
Servers MUST discard any received Decline message that meets any of the following conditions:
- the message does not include a Server Identifier option.
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option.
15.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.
- the contents of the Server Identifier option do not match the server's identifier.
- the message does not include a Client Identifier option.
15.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.
- the
transaction-idfield in the message does not match the value used in the original message.
This one is lowkey picky. If the client included a Client Identifier option in the original message, the Reply message MUST include a Client Identifier option, and the contents of that option MUST match the DUID of the client. OR, 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 🙈
15.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.
- the message does not include a Client Identifier option that contains the client's DUID.
- the message does not contain a Reconfigure Message option and the msg-type must be a valid value.
- the message includes any IA options and the msg-type in the Reconfigure Message option is INFORMATION-REQUEST.
- the message does not include DHCP authentication:
- the message does not contain an authentication option.
- the message does not pass the authentication validation performed by the client.
15.12. Information-request Message 🧚
Clients MUST discard any received Information-request messages. Servers MUST discard any received Information-request message that meets any of the following conditions:
- The message includes a Server Identifier option and the DUID in the option does not match the server's DUID.
- The message includes an IA option.
15.13. Relay-forward Message 🍓
Clients MUST discard any received Relay-forward messages. Bye-bye, relay-forward 👋
15.14. Relay-reply Message 💜
Clients and servers MUST discard any received Relay-reply messages.
16. Client Source Address and Interface Selection 🌈
When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message through the interface for which configuration information is being requested. However, the client MAY send the message through another interface attached to the same link, if and only if the client is certain the two interfaces are attached to the same link. The client MUST use a link-local address assigned to the interface for which it is requesting configuration information as the source address in the header of the IP datagram ✨
When a client sends a DHCP message directly to a server using unicast (after receiving the Server Unicast option from that server), the source address in the header of the IP datagram MUST be an address assigned to the interface for which the client is interested in obtaining configuration, and which is suitable for use by the server in responding to the client. Main character energy for that address 👑
17. DHCP Server Solicitation 🧚
This section is all about how a client finds the servers that will assign addresses to IAs belonging to the client 🔍
The client is the one in charge of creating IAs and asking a server to assign IPv6 addresses to them. It first creates an IA and gives it an IAID. Then it sends a Solicit message with an IA option describing that IA. Servers that can assign addresses to the IA reply with an Advertise message, and then the client starts a configuration exchange as described in section 18.
If the client will accept a Reply message with committed address assignments and other resources in response to the Solicit message, it includes a Rapid Commit option (see section 22.14) in the Solicit message. Speedrun mode activated 🏃♀️💨
17.1. Client Behavior 💅
A client uses the Solicit message to discover DHCP servers that are configured to assign addresses or return other configuration parameters on the link it is attached to.
17.1.1. Creation of Solicit Messages 🎀
The client sets the msg-type field to SOLICIT. It generates a transaction ID and puts that value in the transaction-id field.
The client MUST include a Client Identifier option to identify itself to the server. It includes IA options for any IAs it wants the server to assign addresses to. The client MAY include addresses in the IAs as a hint to the server about addresses it has a preference for. The client MUST NOT include any other options in the Solicit message, except where a specific option's definition says it's allowed 🙅♀️
The client uses IA_NA options to request assignment of non-temporary addresses, and IA_TA options to request assignment of temporary addresses. Either IA_NA or IA_TA options, or a combination of both, can be included in DHCP messages.
The client SHOULD include an Option Request option (see section 22.7) to say which options it's interested in getting back. The client MAY also include instances of those options that are listed in the Option Request option, with data values as hints about the parameter values it would like returned. 🧠
The client includes a Reconfigure Accept option (see section 22.20) if it's willing to accept Reconfigure messages from the server.
17.1.2. Transmission of Solicit Messages 🦋
The first Solicit message from the client on the interface MUST be delayed by a random amount of time between 0 and SOL_MAX_DELAY. When DHCP is initiated by IPv6 Neighbor Discovery, that delay is the amount of time to wait after IPv6 Neighbor Discovery causes the client to invoke the stateful address autoconfiguration protocol (see section 5.5.3 of RFC 2462). This random delay keeps clients that start at the same time (for example, after a power outage) from all showing up in sync 😭
The client transmits the message according to section 14, using these parameters:
IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0If the client included a Rapid Commit option in its Solicit message, it ends the waiting process as soon as a Reply message with a Rapid Commit option is received ⚡
If the client is waiting for an Advertise message, the mechanism in section 14 gets a little tweak for Solicit messages. Receiving an Advertise doesn't end the exchange before the first RT has elapsed. Instead, the client collects Advertise messages until the first RT has passed. Also, the first RT MUST be selected to be strictly greater than IRT, by choosing RAND to be strictly greater than 0 🫶
A client MUST collect Advertise messages for the first RT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 22.8). Any Advertise that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message that includes a Preference option with a preference value of 255, it immediately begins a client-initiated message exchange (as described in section 18) by sending a Request message to the server the Advertise came from. If the client receives an Advertise message that does not include a Preference option with a preference value of 255, it keeps waiting until the first RT elapses. If the first RT elapses and the client has received an Advertise message, the client SHOULD continue with a client-initiated message exchange by sending a Request message 🎯
If the client doesn't receive any Advertise messages before the first RT has elapsed, it begins the retransmission mechanism described in section 14. The client ends the retransmission process as soon as it receives any Advertise message, and it acts on that Advertise message without waiting for any more Advertise messages 🏁
A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, a system restart, or when the client is attached to a new link 🔄
Reminder: MRC and MRD defaults are the move. Anything else and the client has to give up on that interface if the exchange fails.
17.1.3. Receipt of Advertise Messages 💌
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail. The one exception: the client MAY display the associated status message to the user 🙈
Once one or more valid Advertise messages come in, the client picks one or more of them based on these criteria:
- Advertise messages with the highest server preference value are preferred over all other Advertise messages.
- 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. For example, the client may choose a server that returned an advertisement with configuration options it cares about.
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs.
Once a client has selected Advertise message(s), it will typically store info about each server, like the server preference value, the addresses advertised, when the advertisement was received, and so on 🗂️
If the client needs to pick an alternate server because the chosen one doesn't respond, the client chooses the next server according to the criteria above 🔁
17.1.4. Receipt of Reply Message ✨
okay so if the client put a Rapid Commit option in its Solicit message, it's expecting a Reply message that has a Rapid Commit option back 👀 any Reply that comes in without one gets tossed in the bin 🗑️. if a valid Reply with a Rapid Commit option shows up, the client handles it the way section 18.1.8 says 💅. but if no Reply like that arrives and a valid Advertise message does, the client handles the Advertise the way section 17.1.3 describes 🫶
and then, if a valid Reply with a Rapid Commit option comes in later, the client does one of these:
- it processes that Reply as described in section 18.1.8, and throws out any Reply messages that came back for the Request message 💀, or
- it processes any Reply messages that came back for the Request message, and throws out the Reply that has the Rapid Commit option 🙈
17.2. Server Behavior 🌸
a server sends an Advertise message in response to valid Solicit messages it gets, just to say "hey, I'm here and available" 🦋
17.2.1. Receipt of Solicit Messages 🧚
the server figures out info about the client and where it is, as described in section 11 🗺️, and checks its admin policy about whether it's even allowed to answer this client. if the server isn't permitted to respond, it discards the Solicit message 🙅♀️. for example, say the server's admin policy is that it only answers clients who are cool with getting a Reconfigure message. if the client says, using a Reconfigure Accept option in the Solicit message, that it won't accept a Reconfigure message, then the servers discard the Solicit message. no vibes, no response 💀
if the client put a Rapid Commit option in the Solicit message, and the server is set up to respond with committed address assignments and other resources, then the server responds to the Solicit with a Reply message as described in section 17.2.3 ⭐ otherwise, the server ignores the Rapid Commit option and handles the rest of the message like it was never there 🤷♀️
17.2.2. Creation and Transmission of Advertise Messages 💌
the server sets the msg-type field to ADVERTISE and copies the transaction-id field from the Solicit message it got from the client into the Advertise message 💖 the server also puts its server identifier in a Server Identifier option, and copies the Client Identifier from the Solicit message into the Advertise message 🎀
the server MAY add a Preference option to carry the preference value for the Advertise message 🌈 the server implementation SHOULD let the admin set a server preference value 🔧 and the server preference value MUST default to zero, unless the server admin configures something else 🔢
the server includes a Reconfigure Accept option if it wants to require that the client accept Reconfigure messages 👑
the server includes options that it'll send back to the client in a later Reply message 📦 the info in these options might be used by the client to pick a server if it gets more than one Advertise message ⚖️ if the client put an Option Request option in the Solicit message, the server includes options in the Advertise message with configuration parameters for all of the options named in that Option Request option, as long as the server is set up to return them to the client 🍓 the server MAY also return additional options to the client, if it's been configured to do that ✨ and the server must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460 📏
if the Solicit message from the client had one or more IA options, the server MUST include IA options in the Advertise message with any addresses that would be assigned to the IAs in the client's Solicit message 🏠 if the client put addresses in the IAs in its Solicit message, the server uses those addresses as hints about what the client would like to get 🫶
if the server won't assign any addresses to any IAs in a later Request from the client, the server MUST send the client an Advertise message that only includes a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID 💀 basically "sorry bestie, no addresses for you" 😭
if the Solicit message got to the server directly, the server unicasts the Advertise message straight to the client, using the address in the source address field of the IP datagram that carried the Solicit 🎯 the Advertise message MUST be unicast on the link the Solicit came in on 🛤️
if the Solicit message came in a Relay-forward message, the server builds a Relay-reply message and puts the Advertise message in the payload of a relay-message option 📬 if the Relay-forward message had an Interface-id option, the server copies that option into the Relay-reply message too 🔁 then the server unicasts the Relay-reply message to the relay agent, using the address in the source address field of the IP datagram that carried the Relay-forward message 🚀
17.2.3. Creation and Transmission of Reply Messages 🦄
the server MUST commit the assignment of any addresses or other configuration information message before it sends a Reply message to a client in response to a Solicit message 🔒
DISCUSSION: when you're using the Solicit-Reply message exchange, the server commits the assignment of any addresses before it sends the Reply message 💖 the client can just assume it got the addresses listed in the Reply, so it doesn't need to send a Request message for them 🙌 usually, servers using the Solicit-Reply exchange are set up so that only one server answers a Solicit message 🧚 if more than one server responds, the client only uses addresses from one of them, and the addresses from the other servers stay committed to the client without ever getting used 😭
the server includes a Rapid Commit option in the Reply message to show that the Reply is answering a Solicit message ⚡
the server includes a Reconfigure Accept option if it wants to require that the client accept Reconfigure messages 👑
the server builds the Reply message as if it had received a Request message, as described in section 18.2.1 🏗️ then it transmits the Reply message as described in section 18.2.8 📤
18. DHCP Client-Initiated Configuration Exchange 💜
a client starts a message exchange with a server (or servers) to get or update the configuration info it cares about 🎀 the client can kick this off as part of the operating system configuration process 🖥️, when the application layer asks it to 📱, when Stateless Address Autoconfiguration needs it 🌐, or to extend the lifetime of an address (Renew and Rebind messages) ⏳
18.1. Client Behavior 🌸
a client uses Request, Renew, Rebind, Release and Decline messages during the normal life cycle of addresses 🔄 it uses Confirm to validate addresses when it may have moved to a new link 🚚 and it uses Information-Request messages when it needs configuration info but no addresses 📋
if the client has a source address with enough scope that the server can use it as a return address, and the client has received a Server Unicast option (section 22.12) from the server, the client SHOULD unicast any Request, Renew, Release and Decline messages to the server 🎯
DISCUSSION: unicast can avoid delays caused by relay agents passing messages along 🐢, and it also avoids extra overhead and duplicate responses from servers that happen when client messages get delivered to multiple servers 🙅♀️ requiring the client to send all DHCP messages through a relay agent means relay agent options can be included in every message the client sends 🎁 the server should only turn on unicast when relay agent options won't be used 🔧
18.1.1. Creation and Transmission of Request Messages 💅
the client uses a Request message to fill up its IAs with addresses and to get other configuration info 🏡 the client includes one or more IA options in the Request message 📦 then the server sends addresses and info about the IAs back to the client in IA options in a Reply message 💌
the client makes up a transaction ID and puts it in the transaction-id field 🆔
the client puts the identifier of the destination server in a Server Identifier option 🎯
the client MUST include a Client Identifier option to identify itself to the server 🪪 the client adds any other appropriate options, including one or more IA options (if the client is asking the server to assign it some network addresses) 🧩
the client MUST include an Option Request option (see section 22.7) to say which options it's interested in getting 🛍️ the client MAY include options with data values as hints to the server about parameter values it would love to get back 💭
the client includes a Reconfigure Accept option (see section 22.20) to say whether or not it's willing to accept Reconfigure messages from the server 🙋♀️
the client transmits the message according to section 14, with these parameters:
IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
MRD 0if the message exchange fails, the client takes an action based on its local policy 📜 some actions the client might take include:
- selecting another server from a list of servers the client knows about, like servers that sent an Advertise message 🔁
- starting the server discovery process described in section 17 🔍
- terminating the configuration process and reporting failure 💀
18.1.2. Creation and Transmission of Confirm Messages ✨
okay so whenever a client might have moved to a new link 🧳, the prefixes on the addresses attached to its interfaces might not fit the new link anymore 😬. Times when that can happen include:
- The client reboots. 🔄
- The client is physically connected to a wired connection. 🔌
- The client returns from sleep mode. 😴
- The client using a wireless technology changes access points. 📶
Any time a client might have moved to a new link, it MUST initiate a Confirm/Reply message exchange 💅. It puts any IAs assigned to the interface that may have moved, along with the addresses tied to those IAs, into its Confirm message. Responding servers then say whether those addresses fit the link the client is on, using the status in the Reply message they send back 🫶.
The client sets the msg-type field to CONFIRM 🎀. It generates a transaction ID and puts that value in the transaction-id field 🆔.
The client MUST include a Client Identifier option so the server knows who it is 🪪. It includes IA options for all of the IAs on the interface the Confirm message is for. Those IA options carry every address the client currently has for those IAs 📦. The client SHOULD set the T1 and T2 fields in any IA_NA options to 0, and also set the preferred-lifetime and valid-lifetime fields in the IA Address options to 0, since the server ignores 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 the message according to section 14, using these parameters:
IRT CNF_TIMEOUT
MRT CNF_MAX_RT
MRC 0
MRD CNF_MAX_RDIf the client gets no responses before the transmission process ends (see section 14), it SHOULD keep using its IP addresses with the last known lifetimes, and SHOULD keep using any other configuration parameters it got before 🌸. Not gonna lie, that's a very chill backup plan 😌.
18.1.3. Creation and Transmission of Renew Messages 🔁
To extend the valid and preferred lifetimes for the addresses in an IA, the client sends a Renew message to the server it got those addresses from 💌. The Renew message has an IA option for that IA, and inside it are IA Address options for the addresses tied to the IA 📬. The server decides the new lifetimes according to its own administrative configuration 🧑💼. The server may also add new addresses to the IA, and it may remove addresses from the IA by setting their preferred and valid lifetimes to zero 🗑️.
The server is the one controlling when the client checks in to extend lifetimes, through the T1 and T2 parameters on an IA 🕰️.
At time T1 for an IA, the client starts a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA 🚀. The Renew message includes an IA option with every address currently assigned to the IA 💯.
If the server sets T1 or T2 to 0 (for an IA_NA), or there are no T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind message, respectively, whenever it feels like it 🤷♀️.
The client sets the msg-type field to RENEW 🎀. It generates a transaction ID and puts it in the transaction-id field 🆔.
The client puts the identifier of the destination server in a Server Identifier option 📍.
The client MUST include a Client Identifier option to identify itself to the server 🪪. It adds any other appropriate options, including one or more IA options 🧩. The client MUST include the list of addresses it currently has associated with the IAs in the Renew message 📋.
The client MUST include an Option Request option (see section 22.7) to say which options it wants back 🙋♀️. The client MAY include options with data values as hints about parameter values it would love to get returned 💫.
The client sends the message according to section 14, using these parameters:
IRT REN_TIMEOUT
MRT REN_MAX_RT
MRC 0
MRD Remaining time until T2The message exchange wraps up when T2 is reached (see section 18.1.4), and at that point the client begins a Rebind message exchange 🦋.
18.1.4. Creation and Transmission of Rebind Messages 🌈
At time T2 for an IA (which only happens if the server the Renew message went to at time T1 never responded 😶), the client starts a Rebind/Reply message exchange with any available server 📡. The Rebind message includes an IA option with every address currently assigned to the IA 🎁.
The client sets the msg-type field to REBIND 🎀. It generates a transaction ID and puts it in the transaction-id field 🆔.
The client MUST include a Client Identifier option to identify itself to the server 🪪. It adds any other appropriate options, including one or more IA options 🧩. The client MUST include the list of addresses it currently has associated with the IAs in the Rebind message 📋.
The client MUST include an Option Request option (see section 22.7) to say which options it wants back 🙋♀️. The client MAY include options with data values as hints about parameter values it would love to get returned 💫.
The client sends the message according to section 14, using these parameters:
IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Remaining time until valid lifetimes of all addresses have
expiredThe message exchange ends when the valid lifetimes of every address assigned to the IA run out (see section 10). At that point the client has a few options to pick from, for example:
- The client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server. 🔍
- The client may have addresses in other IAs, so it may choose to throw out the expired IA and use the addresses in the other IAs. 🗂️
18.1.5. Creation and Transmission of Information-request Messages 📚
The client uses an Information-request message to get configuration information without having any addresses assigned to it 🧾.
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 so it can identify itself to the server 🪪. If it doesn't, the server won't be able to return any client-specific options to the client, or the server may choose not to respond to the message at all 💀. The client MUST include a Client Identifier option if the Information-Request message is going to be authenticated 🔐.
The client MUST include an Option Request option (see section 22.7) to say which options it wants back 🙋♀️. The client MAY include options with data values as hints about parameter values it would love to get returned 💫.
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 14, using these parameters:
IRT INF_TIMEOUT
MRT INF_MAX_RT
MRC 0
MRD 018.1.6. Creation and Transmission of Release Messages 👋
To release one or more addresses, a client sends a Release message to the server 💨.
The client sets the msg-type field to RELEASE 🎀. It generates a transaction ID and places it in the transaction-id field 🆔.
The client places the identifier of the server that gave out the address(es) in a Server Identifier option 📍.
The client MUST include a Client Identifier option to identify itself to the server 🪪. The client includes options containing the IAs for the addresses it's releasing in the options field 📦. The addresses being released MUST be included in the IAs 🎯. Any addresses for the IAs that the client wants to keep using MUST NOT be added to the IAs 🚫.
The client MUST NOT use any of the addresses it is releasing as the source address in the Release message or in any message sent after it 🙅♀️.
Because Release messages can get lost, the client should retransmit the Release if no Reply is received 🔁. But sometimes the client doesn't want to wait out the normal retransmission timeout before giving up (for example, when it's powering down) 🔌. Implementations SHOULD retransmit one or more times, but MAY choose to end the retransmission procedure early 🫠.
The client sends the message according to section 14, using these parameters:
IRT REL_TIMEOUT
MRT 0
MRC REL_MAX_RC
MRD 0The client MUST stop using all of the addresses being released as soon as it starts the Release message exchange process 🛑. If the addresses get released but the Reply from a DHCP server is lost, the client retransmits the Release message, and the server may respond with a Reply showing a status of NoBinding 🫣. So the client doesn't treat a Reply with a status of NoBinding in a Release message exchange as an error ✅.
Note that if the client fails to release the addresses, the server will reclaim each address assigned to the IA when that address's valid lifetime expires ⏰.
18.1.7. Creation and Transmission of Decline Messages 🙅♀️
If a client detects that one or more addresses the server gave it are already being used by another node, it sends a Decline message to the server to say that the address is suspect 🚨.
The client sets the msg-type field to DECLINE 🎀. It generates a transaction ID and places it in the transaction-id field 🆔.
The client places the identifier of the server that gave out the address(es) in a Server Identifier option 📍.
The client MUST include a Client Identifier option to identify itself to the server 🪪. The client includes options containing the IAs for the addresses it's declining in the options field 📦. The addresses being declined MUST be included in the IAs 🎯. Any addresses for the IAs that the client wants 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 message sent after it 🚫.
The client sends the message according to section 14, using these parameters:
IRT DEC_TIMEOUT
MRT 0
MRC DEC_MAX_RC
MRD 0If the addresses get declined but the Reply from a DHCP server is lost, the client retransmits the Decline message, and the server may respond with a Reply showing a status of NoBinding 🥺. So the client doesn't treat a Reply with a status of NoBinding in a Decline message exchange as an error 💖.
18.1.8. Receipt of Reply Messages 🎀
okay so bestie, when a valid Reply lands 📬 in response to a Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind or Information-request, the client digs out the configuration info inside it 💅. The client MAY choose to report any status code or message from the Status Code option in the Reply. Totally your call, bestie 💖.
The client SHOULD perform duplicate address detection [17] on each address in any IAs it gets in the Reply before actually using that address for traffic 🔍. If any of them are already in use on the link, the client sends a Decline message to the server, as described in section 18.1.7 🙅♀️.
If the Reply was received 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 📝:
- Record T1 and T2 times. ⏰
- Add any new addresses in the IA option to the IA as recorded by the client. ➕
- Update lifetimes for any addresses in the IA option that the client already has recorded in the IA. 🔄
- Discard any addresses from the IA, as recorded by the client, that have a valid lifetime of 0 in the IA Address option. 🗑️
- Leave unchanged any information about addresses the client has recorded in the IA but that were not included in the IA from the server. 🧊
Management of the specific configuration information is detailed in the definition of each option in section 22 📚🌸.
If the client receives a Reply message with a Status Code containing UnspecFail, the server is basically saying "I couldn't process that because of an unspecified failure" 😬. If the client retransmits the original message to the same server to retry the 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. Pace yourself, bestie 🛑⏳.
When the client receives a Reply message with a Status Code option with the value UseMulticast, the client records the receipt of the message and sends subsequent messages to the server through the interface the message came in on, using multicast 📡. It also resends the original message using multicast 🦋.
When the client gets a NotOnLink status from the server in response to a Confirm message, the client performs DHCP server solicitation, as described in section 17, and client-initiated configuration as described in section 18 🔎. If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status 🫶.
When the client receives a NotOnLink status from the server in response to a Request, the client can either re-issue the Request without specifying any addresses, or restart the DHCP server discovery process (see section 17) 🔁.
The client examines the status code in each IA individually 🔬. If the status code is NoAddrsAvail, the client has received no usable addresses in that IA and may choose to try obtaining addresses for the IA from another server. The client uses addresses and other information from any IAs that do not contain a Status Code option with the NoAddrsAvail code ✨. If the client receives no addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only 💁♀️.
When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently 👀. For each IA in the original Renew or Rebind message, the client:
- sends a Request message if the IA contained a Status Code option with the
NoBindingstatus (and does not send any additional Renew/Rebind messages) - sends a Renew/Rebind if the IA is not in the Reply message
- otherwise accepts the information in the IA
When the client receives a valid Reply message in response to a Release message, the client considers the Release event completed, regardless of the Status Code option(s) returned by the server 🏁.
When the client receives a valid Reply message in response to a Decline message, the client considers the Decline event completed, regardless of the Status Code option(s) returned by the server 💜.
18.2. Server Behavior 🏠
For this discussion, the server is assumed to have been configured in an implementation specific manner with configuration of interest to clients ⚙️.
In most instances, the server will send a Reply in response to a client message. This Reply message MUST always contain the Server Identifier option containing the server's DUID, and the Client Identifier option from the client message if one was present 🪪.
In most Reply messages, the server includes options containing configuration information for the client 🎁. The server must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460 📏. If the client included an Option Request option in its message, the server includes options in the Reply 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 ✨.
18.2.1. Receipt of Request Messages 📥
When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options 📢.
When the server receives a valid Request message, the server creates the bindings for that client according to the server's policy and configuration information, and records the IAs and other information requested by the client 📝💖.
The server constructs 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 a Server Identifier option containing the server's DUID and the Client Identifier option from the Request message in the Reply message 🪪.
If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink 🚫🔗.
If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA, and a Status Code option in the IA containing the status code NoAddrsAvail 😢.
For any IAs to which the server can assign addresses, the server includes the IA with addresses and other configuration parameters, and records the IA as a new client binding 🎉.
The server includes a Reconfigure Accept option if the server wants to require that the client accept Reconfigure messages 🔐.
The server includes other options containing configuration information to be returned to the client, as described in section 18.2 🎀.
If the server finds that the client has included an IA in the Request message for which the server already has a binding that associates the IA with the client, the client has resent a Request message for which it did not receive a Reply message. The server either resends a previously cached Reply message or sends a new Reply message 🔁💅.
18.2.2. Receipt of Confirm Messages 🔍
When the server receives a Confirm message, the server determines whether the addresses in the Confirm message are appropriate for the link to which the client is attached 🧐. If all of the addresses in the Confirm message pass this test, the server returns a status of Success ✅. If any of the addresses do not pass this test, the server returns a status of NotOnLink 🙅♀️. If the server is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected), or there were no addresses in any of the IAs sent by the client, the server MUST NOT send a reply to the client 🤐.
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 🙈.
The server constructs 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 a Server Identifier option containing the server's DUID and the Client Identifier option from the Confirm message in the Reply message 🪪. The server includes a Status Code option indicating the status of the Confirm message 💌.
18.2.3. Receipt of Renew Messages 🔄
When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options 📢.
When the server receives a Renew message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client 🕵️♀️.
If the server cannot find a client entry for the IA, the server returns the IA containing no addresses, with a Status Code option set to NoBinding, in the Reply message 🫥.
If the server finds that any of the addresses are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0 🧊.
If the server finds the addresses in the IA for the client, then the server sends back the IA to the client with new lifetimes and T1/T2 times ⏰. The server may choose to change the list of addresses, and the lifetimes of addresses, in IAs that are returned to the client 🦋.
The server constructs 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 a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message 🪪.
The server includes other options containing configuration information to be returned to the client, as described in section 18.2 🌸💜.
18.2.4. Receipt of Rebind Messages 🦋
okay bestie, when the server gets a Rebind message with an IA option from a client, it hunts down that client's binding and checks that the info in the client's IA matches what the server has stored for them 🔍
If the server can't find a client entry for the IA, and it decides the addresses in the IA aren't appropriate for the link the client's interface is attached to (going by its explicit configuration info), the server MAY send a Reply to the client with the client's IA in it, and the lifetimes for those addresses set to zero. This Reply is basically an explicit "heads up, these addresses are no longer valid" 💅 In this situation, if the server doesn't send a Reply, it silently discards the Rebind message 🙈
If the server finds that any of the addresses are no longer appropriate for the link the client is attached to, it returns that address to the client with lifetimes of 0 💀
If the server finds the addresses in the IA for the client, then the server SHOULD send back the IA to the client with new lifetimes and T1/T2 times ✨
The server constructs a Reply message 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 containing the server's DUID, plus the Client Identifier option from the Rebind message, in the Reply message. no skipping this one, it's giving required 👑
The server includes other options with configuration info to return to the client, as described in section 18.2. 🫶
18.2.5. Receipt of Information-request Messages 🧚
So when the server receives an Information-request message, the client is asking for configuration info that does NOT include any address assignments. The server figures out every configuration parameter that fits this client, based on the server configuration policies it knows about 🍓
The server constructs a Reply message 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 containing the server's DUID in the Reply message. If the client included a Client Identification option in the Information-request message, the server copies that option over to the Reply message too 🌸
The server includes options with configuration info to return to the client, as described in section 18.2. ✨
If the Information-request message from the client did NOT include a Client Identifier option, the server SHOULD respond with a Reply message 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 forever (indefinitely) 😭
18.2.6. Receipt of Release Messages 💅
When the server gets a Release message via unicast from a client it hasn't sent a unicast option to, the server discards the Release and responds with a Reply message. That Reply has a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client's message, and NO other options 🚫
Once a valid Release 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 those IAs were assigned by the server to those IAs, the server deletes the addresses from the IAs and makes them available for assignment to other clients 🦋 It ignores addresses that weren't assigned to the IA, though it may choose to log an error 🙈
After all the addresses have been processed, the server generates a Reply message that includes a Status Code option with the value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Release message that the server has NO binding information for, the server adds an IA option using the IAID from the Release message, and includes a Status Code option with the value NoBinding in that IA option. No other options go in the IA option 🎀
A server may choose to keep a record of assigned addresses and IAs even after the lifetimes on those addresses have expired, so it can reassign those previously assigned addresses to a client later 🔁
18.2.7. Receipt of Decline Messages 🔥
When the server gets a Decline message via unicast from a client it hasn't sent a unicast option to, the server discards the Decline message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options 🚫
Upon receiving a valid Decline message, 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 those IAs were assigned by the server to those IAs, the server deletes the addresses from the IAs. The server ignores addresses that weren't assigned to the IA (though it may choose to log an error if it finds one) 🧐
Here's the tea: the client has found the addresses in the Decline messages are already in use on its link. So the server SHOULD mark the declined addresses so they don't get assigned to other clients, and it MAY choose to send a notification that addresses were declined 📣 Local policy on the server decides when the addresses identified in a Decline message can be made available for assignment again 🌈
After all the addresses have been processed, the server generates a Reply message that includes a Status Code option with the value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Decline message that the server has NO binding information for, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in that IA option. No other options go in the IA option 💜
18.2.8. Transmission of Reply Messages 🚀
If the original message was received directly by the server, the server unicasts the Reply message straight to the client, using the address in the source address field from the IP datagram the original message came in on. The Reply message MUST be unicast through the interface the original message was received on 🎯
If the original message was received in 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 22.10). If the Relay-forward message included an Interface-id option, the server copies that option into the Relay-reply message. The server unicasts the Relay-reply message directly to the relay agent, using the address in the source address field from the IP datagram the Relay-forward message was received in 🧚
19. DHCP Server-Initiated Configuration Exchange 🌈
sometimes the server starts the convo itself!! A server initiates a configuration exchange to make DHCP clients obtain new addresses and other configuration info. For example, an administrator might use a server-initiated configuration exchange when links in the DHCP domain are getting renumbered 🔢 Other examples include changes in the location of directory servers, adding new services like printing, and new software being available 🖨️💾
19.1. Server Behavior 🎀
A server sends a Reconfigure message to make a client immediately start a Renew/Reply or Information-request/Reply message exchange with the server ⚡
19.1.1. Creation and Transmission of Reconfigure Messages 💖
The server sets the msg-type field to RECONFIGURE. The server sets the transaction-id field to 0. The server includes a Server Identifier option containing its DUID, and a Client Identifier option containing the client's DUID, in the Reconfigure message 🫶
The server MAY include an Option Request option to tell the client what info has changed or what new info has been added. Specifically, the server puts the IA option in the Option Request option if it wants the client to obtain new address info. If the server identifies the IA option in the Option Request option, the server MUST include an IA option that contains no other sub-options, to identify each IA that is to be reconfigured on the client 📋
Heads up, because of the risk of denial of service attacks against DHCP clients, a security mechanism is mandated in Reconfigure messages. The server MUST use DHCP authentication in the Reconfigure message 🛡️💀
The server MUST include a Reconfigure Message option (defined in section 22.19) to select whether the client responds with a Renew message or an Information-Request message 🔀
The server MUST NOT include any other options in the Reconfigure message, except as specifically allowed in the definition of individual options 🚫
The server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope that belongs to that DHCP client 📮 If the server doesn't have an address it can send the Reconfigure message to directly, it uses a Relay-reply message (as described in section 20.3) to send the Reconfigure message to a relay agent that will relay it to the client 🔁 The server may get the client's address (and the right relay agent, if needed) from info it has about clients that have been in contact with it, or through some external agent 🕵️
To reconfigure more than one client, the server unicasts a separate message to each client. The server may start reconfiguring multiple clients at the same time. For example, a server may send a Reconfigure message to more clients while earlier reconfiguration message exchanges are still in progress 🏃♀️💨
The Reconfigure message makes the client start a Renew/Reply or Information-request/Reply message exchange with the server. The server counts the receipt of a Renew or Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request ✅
19.1.2. Time Out and Retransmission of Reconfigure Messages ⏰
If the server doesn't receive a Renew or Information-request message from the client within REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value, and waits again. The server keeps doing this until REC_MAX_RC unsuccessful attempts have been made, and then the server SHOULD abort the reconfigure process for that client 🛑
Default and initial values for REC_TIMEOUT and REC_MAX_RC are documented in section 5.5. 📖
19.2. Receipt of Renew Messages 🔁
The server generates and sends a Reply message to the client as described in sections 18.2.3 and 18.2.8, including options for configuration parameters 💌
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 weren't requested in the Renew message from the client 🎁
19.3. Receipt of Information-request Messages ✨
okay so when the server gets an Information-request, it builds a Reply and sends it back to the client, just like in sections 18.2.5 and 18.2.8 🎀 The Reply carries options for configuration parameters.
The server MAY also throw in new values for other configuration parameters in that Reply, even if the client never asked for them in the Information-request 🎁
19.4. Client Behavior 🦋
clients receive Reconfigure messages sent to UDP port 546 on any interface where they already got configuration info through DHCP 📡 These can show up at any time, no warning 😭 Since a reconfiguration can change stuff that application layer programs rely on, the client SHOULD log these events, and it MAY tell those programs about the change through an implementation-specific interface 💜
19.4.1. Receipt of Reconfigure Messages 🔥
when a valid Reconfigure message arrives, the client replies with either a Renew message or an Information-request message, whichever the Reconfigure Message option says to use (that option is in section 22.19) 💅 The client ignores the transaction-id field in the Reconfigure message it got. While a transaction is already in progress, the client quietly drops any Reconfigure messages that show up 🤫
DISCUSSION:
the Reconfigure message is basically a trigger that tells the client to finish a successful message exchange ✨ Once the client gets a Reconfigure, it runs the exchange (resending its Renew or Information-request if it has to), and it ignores extra Reconfigure messages until that exchange is done. Later Reconfigure messages make it start a brand new exchange 🔄
so what about duplicate or retransmitted Reconfigure messages? 🤔 Duplicates just get ignored, because the client starts the exchange when the first one arrives. Retransmissions either kick off the exchange (if the first one never reached the client) or get ignored. The server can stop resending Reconfigure messages once it gets the Renew or Information-request from the client 🙌
could a duplicate or retransmitted Reconfigure be delayed enough, and show up out of order, after the exchange it started is already finished? 😳 Yeah, it's possible. In that case the client would start a redundant exchange. But the odds of delayed, out-of-order delivery are small enough to ignore 🌸 And the result is just inefficiency, not wrong behavior, so no drama 💖
19.4.2. Creation and Transmission of Renew Messages 💌
when the client is responding to a Reconfigure, it builds and sends the Renew message exactly the way section 18.1.3 describes, with one twist: it copies the Option Request option and any IA options from the Reconfigure message into the Renew 🧚
19.4.3. Creation and Transmission of Information-request Messages 🍓
same deal here. When responding to a Reconfigure, the client builds and sends the Information-request exactly like section 18.1.5 says, except it includes a Server Identifier option carrying the identifier from the Reconfigure it's answering 🫶
19.4.4. Time Out and Retransmission of Renew or Information-request Messages ⏰
the client uses the same variables and retransmission algorithm it uses for Renew or Information-request messages from a client-initiated exchange. Check sections 18.1.3 and 18.1.5 for the details 📚 If the client still hasn't heard back from the server once the retransmissions run out, it ignores and discards the Reconfigure message 🗑️
19.4.5. Receipt of Reply Messages 🎉
when a valid Reply message arrives, the client processes the options and sets (or resets) configuration parameters as needed ✨ It also records and updates the lifetimes for any addresses listed in IAs in the Reply 💜
20. Relay Agent Behavior 🌈
the relay agent MAY be configured with a list of destination addresses. That list MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses the network administrator picks 🗺️ If the relay agent was never explicitly configured, it MUST use the All_DHCP_Servers multicast address as its default. No skipping this one, bestie 🚨
If the relay agent relays messages to the All_DHCP_Servers multicast address or to other multicast addresses, it sets the Hop Limit field to 32 🔢
20.1. Relaying a Client Message or a Relay-forward Message 🦋
relay agents relay both messages from clients and Relay-forward messages from other relay agents 🔁 When a relay agent gets a valid message to relay, it builds a brand new Relay-forward message. It copies the source address from the IP datagram header the message came in on into the peer-address field of the Relay-forward 📮 Then it copies the received DHCP message (minus any IP or UDP headers) into a Relay Message option in the new message. Finally, it adds any other options it's configured to include 💅
20.1.1. Relaying a Message from a Client 💻
if the relay agent got the message from a client, it puts a global or site-scoped address with a prefix assigned to the link where the client should get its address into the link-address field 🌍 The server uses this address to figure out which link the client should be assigned an address and other config info from. The hop-count in the Relay-forward is set to 0 🎯
if the relay agent can't use the link-address field to identify the interface the response will be relayed through, it MUST include an Interface-id option (see section 22.18) in the Relay-forward message 🧩 The server will copy that Interface-id option into its Relay-reply message. The relay agent fills in the link-address field the way we just described, whether or not it includes an Interface-id option in the Relay-forward, so no matter what it always gets filled in ✨
20.1.2. Relaying a Message from a Relay Agent 🪆
if the message the relay agent got is a Relay-forward message and its hop-count is greater than or equal to HOP_COUNT_LIMIT, the relay agent throws it away 🙅♀️
otherwise, the relay agent copies the source address from the IP datagram it came in on (from the client) into the peer-address field of the Relay-forward, and sets the hop-count field to whatever the received hop-count was plus 1 ➕
if the source address in the IP datagram header of the received message is a global or site-local address (and the device running the relay agent belongs to only one site), the relay agent sets the link-address field to 0. If not, the relay agent sets the link-address field to a global or site-local address assigned to the interface the message came in on, or it includes an Interface-ID option to identify that interface 🫧
20.2. Relaying a Relay-reply Message 💌
the relay agent processes any options in the Relay-reply message along with the Relay Message option, and then it discards those options 🗑️
the relay agent pulls the message out of the Relay Message option and relays it to the address in the peer-address field of the Relay-reply 🚀
if the Relay-reply has an Interface-id option, the relay agent relays the message from the server to the client on the link that the Interface-id option names. Otherwise, if the link-address field isn't set to zero, the relay agent relays the message on the link named by the link-address field 🧭
20.3. Construction of Relay-reply Messages 🪄
a server uses a Relay-reply message in two situations: to send a response back to a client when the original client message got relayed to the server in a Relay-forward message, or to send 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 includes a Relay Message option holding the message for the next relay agent on the way back to the client. That contained Relay-reply has its own Relay Message option for the next relay agent, 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 carrying the server's response 📝
for example, if client C sent a message that relay agent A relayed to relay agent B, and then B relayed it to the server, the server would send this Relay-reply message to relay agent B 👇
msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>when the server sends a Reconfigure message to a client through a relay agent, it builds a Relay-reply that includes a Relay Message option holding the Reconfigure message for the next relay agent 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 sets the link-address field however the relay agent needs it set to relay the Reconfigure to the client 🧸 The server gets the addresses of the client and the relay agent through earlier interaction with the client, or through some external mechanism 🔍
21. Authentication of DHCP Messages 🔒
some network administrators may want to authenticate where DHCP messages came from and what's inside them 🕵️♀️ For example, clients can get hit with denial of service attacks from bogus DHCP servers, or they might just get misconfigured by DHCP servers that were started by accident 😱 Admins may also want to limit address allocation to authorized hosts, to dodge denial of service attacks in "hostile" environments where the network medium isn't physically secured, like wireless networks or college residence halls 🏫💀
The DHCP authentication mechanism is based on the design of authentication for DHCPv4 [4] 💜
21.1. Security of Messages Sent Between Servers and Relay Agents
Okay so, relay agents and servers that want to swap messages securely use the IPsec mechanisms for IPv6 [7] 🔐✨ If a client message gets relayed through multiple relay agents, each of those relay agents MUST have its own independent, pairwise trust relationship 🫶 Like, if client C's messages go from relay agent A to relay agent B and then on to the server, then relay agents A and B must be set up to use IPsec for the messages they trade, and relay agent B and the server must be set up to use IPsec for theirs 💅
Relay agents and servers that support secure relay-agent-to-server or relay-agent-to-relay-agent communication use IPsec under the following conditions:
- Selectors: Relay agents are manually configured with the addresses of the relay agent or server that DHCP messages get forwarded to 🧚 Every relay agent and server that's using IPsec to protect DHCP messages also needs a list of the relay agents that messages will be sent back to. The selectors are the pairs of addresses for the relay agents and servers that swap DHCP messages on the DHCPv6 UDP ports 546 and 547 🦋
- Mode: Relay agents and servers use transport mode and ESP. Honestly, the info inside DHCP messages isn't usually considered confidential, so encryption doesn't have to be used (so NULL encryption can be used) 🙈
- Key management: The relay agents and servers live inside one organization, so public key schemes aren't necessary 💜 Since they have to be configured by hand, manually configured key management may suffice, BUT it doesn't protect against replayed messages 💀 So IKE with preshared secrets SHOULD be supported 🔥 IKE with public keys MAY be supported 🌈
- Security policy: DHCP messages between relay agents and servers should only be accepted from DHCP peers that are identified in the local configuration 🎀
- Authentication: Shared keys, indexed to the source IP address of the received DHCP message, are adequate for this application 🌸
- Availability: Proper IPsec implementations are likely to be around for servers and for relay agents in the more featureful devices used in enterprise and core ISP networks 👑 IPsec is less likely to be available for relay agents in the low-end devices mostly used in home or small office markets 🥺
21.2. Summary of DHCP Authentication
Authentication of DHCP messages happens through the Authentication option (see section 22.11) ✨ The authentication info carried in that option can be used to reliably figure out who sent a DHCP message and to confirm that the contents haven't been tampered with 🕵️♀️💖
The Authentication option gives you a framework for multiple authentication protocols 🧩 Two of them are defined here. Any other protocols defined in the future will get their own separate documents 📄
Any DHCP message MUST NOT include more than one Authentication option. Not one extra, bestie 🙅♀️
The protocol field in the Authentication option tells you which specific protocol made the authentication info carried in the option 🔑 The algorithm field picks a specific algorithm inside that protocol. For example, it says which hash algorithm was used to generate the message authentication code (MAC) in the option 🧮 The replay detection method (RDM) field says what type of replay detection is used in the replay detection field 🔁
21.3. Replay Detection
The Replay Detection Method (RDM) field decides what kind of replay detection gets used in the Replay Detection field 🦋
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter 🔢 Using a counter value, like the current time of day (for example, an NTP-format timestamp [9]), can reduce the danger of replay attacks 🫣 This method MUST be supported by all protocols 💅
21.4. Delayed Authentication Protocol
If the protocol field is 2, the message is using the "delayed authentication" mechanism ⏳ Here's how it goes: the client asks for authentication in its Solicit message, and then the server replies with an Advertise message that includes authentication info 📬 That info has a nonce value that the source generates as a message authentication code (MAC), which gives you both message authentication and entity authentication 🔐💫
The specific technique here is based on the HMAC protocol [8], using the MD5 hash [16] ✨
21.4.1. Use of the Authentication Option in the Delayed Authentication Protocol
In a Solicit message, the client fills in the protocol, algorithm and RDM fields in the Authentication option with its own preferences 🎀 The client sets the replay detection field to zero and leaves out the authentication information field 🙈 It sets the option-len field to 11 💖
In every other message, the protocol and algorithm fields tell you the method used to build the contents of the authentication information field 🧠 The RDM field tells you the method used to build the contents of the replay detection field 🔁
The format of the Authentication information looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP realm |
| (variable length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-MD5 |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- DHCP realm: The DHCP realm that identifies the key used to generate the HMAC-MD5 value 🗺️
- key ID: The key identifier that identified the key used to generate the HMAC-MD5 value 🪪
- HMAC-MD5: The message authentication code generated by applying MD5 to the DHCP message using the key identified by the DHCP realm, client DUID, and key ID 🧁
The sender computes the MAC using the HMAC generation algorithm [8] and the MD5 hash function [16] 🧮 The entire DHCP message gets used as input to the HMAC-MD5 computation, with the MAC field of the authentication option set to zero 🫧 That includes the DHCP message header and the options field too 📦
DISCUSSION: Algorithm 1 specifies the use of HMAC-MD5 💜 Using a different technique, like HMAC-SHA, will be specified as a separate protocol 🌈 The DHCP realm used to identify authentication keys is chosen to be unique among administrative domains 🌍 Using the DHCP realm lets DHCP admins avoid conflicts in key identifiers, and it lets a host using DHCP keep using authenticated DHCP while roaming between DHCP administrative domains ✈️✨
21.4.2. Message Validation
Any DHCP message that includes more than one authentication option MUST be discarded 🗑️ No exceptions, no cap 🙅♀️
To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method named by the RDM field 🔍 Next, the receiver computes the MAC as described in [8] 🧮 The entire DHCP message (with the MAC field of the authentication option set to 0) gets used as input to the HMAC-MD5 computation function 🫧 If the MAC the receiver computes doesn't match the MAC in the authentication option, the receiver MUST discard the DHCP message 💀
21.4.3. Key Utilization
Each DHCP client has a set of keys 🗝️ Each key is identified by <DHCP realm, client DUID, key id> and each key also has a lifetime ⏰ A key may not be used past the end of its lifetime, so don't even try 🙅♀️ The client's keys get handed to it initially through some out-of-band mechanism 📮 The lifetime for each key is distributed along with the key 💌 How keys get distributed and how lifetimes get specified is beyond the scope of this document 🤷♀️
The client and server use one of the client's keys to authenticate DHCP messages during a session (until the next Solicit message sent by the client) 🤝✨
21.4.4. Client Considerations for Delayed Authentication Protocol
The client announces that it wants to use DHCP authentication by including an Authentication option in its Solicit message 📣 The server picks a key for the client based on the client's DUID 🔑 The client and server use that key to authenticate all the DHCP messages exchanged during the session 🫶
21.4.4.1. Sending Solicit Messages
When the client sends a Solicit message and wants to use authentication, it includes an Authentication option with the desired protocol, algorithm and RDM, as described in section 21.4 🎀 The client doesn't include any replay detection or authentication information in the Authentication option 🙈
21.4.4.2. Receiving Advertise Messages ✨
Okay so the client checks every Advertise message that has an Authentication option saying it's using the delayed authentication protocol, using the validation test from section 21.4.2. 🔍
Now, what if no Advertise messages include auth info, or none of them pass the test? Bestie, that's up to the client's local policy 🤷♀️ According to client policy, the client MAY choose to respond to an Advertise message that hasn't been authenticated. 🫣
Setting local policy to accept unauthenticated messages should be done with care 🙈 Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks 💀 And if the local users aren't explicitly told that the client accepted an unauthenticated Advertise message, they might wrongly assume the client got an authenticated address and is totally safe from DHCP attacks through unauthenticated messages. That's a whole mess, so please be transparent with your users 🫶
A client MUST be configurable to discard unauthenticated messages, and SHOULD be configured by default to discard them if the client has been set up with an authentication key or other authentication information. 🔐 A client MAY choose to tell apart Advertise messages with no authentication information from Advertise messages that don't pass the validation test. For example, it might accept the former and discard the latter. 👀 If a client does accept an unauthenticated message, it SHOULD inform any local users and SHOULD log the event. 📝
21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release Messages 💌
If the client authenticated the Advertise message it used to pick the server, the client MUST generate authentication information for the later Request, Confirm, Renew, Rebind or Release messages it sends to that server, as described in section 21.4. 💅 And when it sends one of those subsequent messages, it MUST use the same key the server used to generate the authentication information. 🔑 No switching keys mid-convo, periodt 🙅♀️
21.4.4.4. Sending Information-request Messages 🧚
If the server has selected a key for the client in a previous message exchange (see section 21.4.5.1), the client MUST use that same key to generate the authentication information throughout the session. 🗝️ Consistency is everything, no cap ✨
21.4.4.5. Receiving Reply Messages 💬
If the client authenticated the Advertise it accepted, the client MUST validate the matching Reply message from the server. 🧐 The client MUST discard the Reply if it fails the validation test, and it MAY log the validation failure. 📓 If the Reply fails the validation test, the client MUST restart the DHCP configuration process by sending a Solicit message. 🔄 Start over, girl, we move 💖
If the client accepted an Advertise message that either didn't include authentication information or didn't pass the validation test, the client MAY accept an unauthenticated Reply message from the server. 🤷♀️
21.4.4.6. Receiving Reconfigure Messages 🚨
The client MUST discard the Reconfigure if it fails the validation test, and it MAY log the validation failure. 🗑️ Not the vibe, not the message 💅
21.4.5. Server Considerations for Delayed Authentication Protocol 🖥️
After the server gets a Solicit message that contains an Authentication option, it selects a key for the client. The server picks that key based on the client's DUID and on the key selection policies the server has been configured with. 🧠 The server then identifies the selected key in the Advertise message, and uses that key to validate later messages between the client and the server. 🔐 Main character server energy 👑
21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages 📨
The server selects a key for the client and includes authentication information in the Advertise message it sends back, as specified in section 21.4. The server MUST record the identifier of the key it selected for the client, and MUST use that same key to validate later messages with that client. 📌 Consistency, bestie 🫶
21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages and Sending Reply Messages 📬
The server uses the key identified in the message and validates the message as specified in section 21.4.2. If the message fails the validation test, or the server doesn't know the key identified by the 'key ID' field, the server MUST discard the message. It MAY choose to log the validation failure. 🗑️📓
If the message passes the validation test, the server responds to that specific message as described in section 18.2. ✅ The server MUST include authentication information generated using the key identified in the received message, as specified in section 21.4. 🔐 Every reply gets dressed up in the right key 💅
21.5. Reconfigure Key Authentication Protocol 🎀
The Reconfigure key authentication protocol protects a client from misconfiguration caused by a Reconfigure message sent by a malicious DHCP server. 😈🚫 Here's how it goes: a DHCP server sends a Reconfigure Key to the client during the initial exchange of DHCP messages. The client records that Reconfigure Key so it can authenticate later Reconfigure messages from that server. After that, the server includes an HMAC computed from the Reconfigure Key in its subsequent Reconfigure messages. 🔁
Both the Reconfigure Key sent from the server to the client, and the HMAC in later Reconfigure messages, are carried as the Authentication information in an Authentication option. The format of that Authentication information is defined in the next section. 📦
The Reconfigure Key protocol is initiated by the server, and it's only used if the client and server aren't using any other authentication protocol and have negotiated to use Reconfigure messages. 🤝 Only when it's the right setup, no cap ✨
21.5.1. Use of the Authentication Option in the Reconfigure Key Authentication Protocol 🧾
The following fields are set in an Authentication option for the Reconfigure Key Authentication Protocol:
protocol 3
algorithm 1
RDM 0The format of the Authentication information for the Reconfigure Key Authentication Protocol 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type of data in Value field carried in this option:
1 Reconfigure Key value (used in Reply message).
2 HMAC-MD5 digest of the message (used in Reconfigure
message).
Value Data as defined by field.21.5.2. Server considerations for Reconfigure Key protocol 🖥️
The server selects a Reconfigure Key for a client during the Request/Reply, Solicit/Reply or Information-request/Reply message exchange. 🔑 The server records the Reconfigure Key and sends that key to the client in an Authentication option in the Reply message. 📬
The Reconfigure Key is 128 bits long, and it MUST be a cryptographically strong random or pseudo-random number that cannot easily be predicted. 🎲🔒 No guessable keys, please and thank you 🙅♀️
To provide authentication for a Reconfigure message, the server selects a replay detection value according to the RDM it selected, and computes an HMAC-MD5 of the Reconfigure message using the Reconfigure Key for that client. 🧮 The server computes the HMAC-MD5 over the entire DHCP Reconfigure message, including the Authentication option. The HMAC-MD5 field in the Authentication option is set to zero for that computation. 0️⃣ Then the server includes the HMAC-MD5 in the authentication information field of an Authentication option in the Reconfigure message it sends to the client. ✨
21.5.3. Client considerations for Reconfigure Key protocol 🧚
The client gets a Reconfigure Key from the server in the initial Reply message. 📩 The client records that Reconfigure Key so it can authenticate later Reconfigure messages. 📓
To authenticate a Reconfigure message, the client computes an HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key it received from the server. 🧮 If the computed HMAC-MD5 matches the value in the Authentication option, the client accepts the Reconfigure message. ✅ Match? Accept. No match? Yeeted 💀
22. DHCP Options 🌈
Options carry additional information and parameters in DHCP messages. 🎁 Every option shares a common base format, as described in section 22.1. All values in options are represented in network byte order. 🔢
This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in separate documents. 🔮
Unless otherwise noted, each option MAY appear only in the options area of a DHCP message, and MAY appear only once. Hmm, wait, let me say it properly: 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. 🚫🧩 No mashing options together, bestie 🙅♀️
22.1. Format of DHCP Options 🧱
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option
type carried in this option.
option-len An unsigned integer giving the length of the
option-data field in this option in octets.
option-data The data for the option; the format of this data
depends on the definition of the option.DHCPv6 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 22.4 and 22.6. 📚
22.2. Client Identifier Option 🪪
The Client Identifier option carries a DUID (see section 9) that identifies a client between a client and a server. 🆔 The format of the Client Identifier 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_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CLIENTID (1).
option-len Length of DUID in octets.
DUID The DUID for the client.22.3. Server Identifier Option ✨
okay so the Server Identifier option is how a client and a server pass a DUID (see section 9) back and forth to say "this is the server I mean" 💖 here's the layout:
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) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code: it'sOPTION_SERVERID (2)🎀option-len: the length of the DUID in octets 📏DUID: the DUID for the server 🧚
22.4. Identity Association for Non-temporary Addresses Option ✨
the Identity Association for Non-temporary Addresses option (IA_NA option) is the one that carries an IA_NA, its parameters, and the non-temporary addresses tied to it 🌸
the addresses inside an IA_NA option are not temporary addresses (see section 22.5), so no mixing them up, bestie 🙈
here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_NA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields, lowkey the important part:
option-code:OPTION_IA_NA (3)🦋option-len:12 + length of IA_NA-options field📏IAID: the unique identifier for this IA_NA. it has to be unique among all of this client's IA_NAs. the number space for IA_NA IAIDs is separate from the number space for IA_TA IAIDs, so they don't clash 💅T1: the time when the client goes back to the server that gave out the addresses to extend their lifetimes. it's a duration in seconds, counted from now ⏰T2: the time when the client goes to any available server to extend the lifetimes. also a duration in seconds from now 🫶IA_NA-options: options that belong to this IA_NA specifically. like, all the IA Address Options carrying this IA_NA's addresses live in here 🌈
an IA_NA option may only appear in the options area of a DHCP message. a DHCP message can have multiple IA_NA options 🍓
the status of anything happening with this IA_NA shows up in a Status Code option inside the IA_NA-options field ✨
ngl this part is important: an IA_NA has no lifetime or lease length of its own 💀 when all the valid lifetimes of its addresses have run out, the IA_NA can be considered expired. T1 and T2 are just there so servers get explicit say over when a client checks back in about a specific IA_NA 👑
in a message from client to server, the T1 and T2 fields show the client's preference for those values. if the client has no preference, it sets T1 and T2 to 0 🌸
in a message from server to client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless those fields are 0. the values are the number of seconds until T1 and T2 🫶
the server picks T1 and T2 so the client can extend the lifetimes of any addresses in the IA_NA before they expire, even if the server is down for a bit. the recommended values are .5 and .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 ♾️ and if the server wants the client to decide when to renew, it sets T1 and T2 to 0 💅
now the invalid-values drama 😭
- if a server gets an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid T1 and T2 values and processes the IA_NA as though the client had set T1 and T2 to 0 🙈
- if a client gets 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 never included that invalid IA_NA option 🗑️
careful with 0xffffffff ("infinity") for T1 or T2 ⚠️ 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 try to use a Rebind message to find a different server to extend the lifetimes of any addresses in an IA with T2 set to 0xffffffff. so think before you set it, bestie 🥺
22.5. Identity Association for Temporary Addresses Option ✨
the Identity Association for the Temporary Addresses (IA_TA) option carries an IA_TA, its parameters, and the addresses tied to it. the client uses every address in this option as a temporary address, as defined in RFC 3041 [12] 🦋 here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_TA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_IA_TA (4)🎀option-len:4 + length of IA_TA-options field📏IAID: the unique identifier for this IA_TA. it has to be unique among all of this client's IA_TAs. the IA_TA IAID number space is separate from the IA_NA one 🧚IA_TA-options: options that belong to this IA_TA specifically. all the IA Address Options carrying this IA_TA's addresses go here 🌈
an IA_TA option may only appear in the options area of a DHCP message, and a DHCP message can have multiple IA_TA options 🍓 the status of any operations on this IA_TA is in a Status Code option in the IA_TA-options field 💅
an IA_TA has no lifetime of its own either. when all the valid lifetimes of the addresses in an IA_TA have expired, the IA can be considered expired ⏳
an IA_TA option doesn't include T1 and T2 values, but a client MAY ask for the lifetimes on its temporary addresses to be extended by putting those addresses in an IA_TA option sent in a Renew or Rebind message to a server. for example, a client might ask for an extension so an app can keep using an established TCP connection 🫶
each IA_TA carries one "set" of temporary addresses, meaning at most one address from each prefix assigned to the link the client is attached to 🌸
to get new temporary addresses, the client sends an IA_TA option with a new IAID to a server. asking the server for new ones is the same as generating new temporary addresses as described in RFC 3041 🦋 the server will generate new temporary addresses and send them back. the client should ask for new ones before the lifetimes on the old addresses run out ⏰
the big rule: a server MUST return the same set of temporary addresses for the same IA_TA (as identified by the IAID) for as long as those addresses are still valid 🔒 once the lifetimes of the addresses in an IA_TA have expired, the IAID may be reused to identify a new IA_TA with new temporary addresses 🔁
this option MAY appear in a Confirm message if the lifetimes on the temporary addresses in the associated IA have not expired ✨
22.6. IA Address Option 🏡
okay so the IA Address option is how you attach specific IPv6 addresses to an IA_NA or an IA_TA 💖 it has to live inside the Options field of one of those, and that Options field holds the stuff that's specific to this one address ✨
here's the layout 👀
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields, bestie 🫶
option-codeisOPTION_IAADDR (5).option-lenis24 + length of IAaddr-options field.IPv6 addressis the IPv6 address itself 🌸preferred-lifetimeis the preferred lifetime for that address, in seconds.valid-lifetimeis the valid lifetime for that address, in seconds.IAaddr-optionsis the options that belong to this address.
ok the lifetime stuff is where it gets spicy 🌶️ when a client is sending this to a server, the lifetime values are just the client saying what it prefers 💅 and it's allowed to send 0 if it doesn't care at all. but when a server sends it back to a client, the client MUST use those preferred and valid lifetime values for real 🔥 and they're the number of seconds still left on each lifetime, not the original numbers.
a client throws out any address where the preferred lifetime is bigger than the valid lifetime 🗑️ and a server just ignores the client's lifetimes if the preferred one is bigger than the valid one 🙈 it also ignores the client's T1 and T2 values if those are bigger than the preferred lifetime. no drama, just vibes 🧚
careful with 0xffffffff ("infinity") for the valid lifetime 💀 that's basically saying "this address is permanently yours," so think twice before you hit that.
an IA Address option can only show up inside an IA_NA option or an IA_TA option 💜 and you can have more than one IA Address option in there, no cap 🌈
finally, if anything's going wrong with operations on this IA Address, the status shows up in a Status Code option sitting in the IAaddr-options field 🚨
22.7. Option Request Option 🎀
the Option Request option is basically the client's wishlist 🎁 it's a list of option codes, so both sides know which options are being asked for. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-codeisOPTION_ORO (6).option-lenis2 * number of requested options.requested-option-code-nis the option code for each option the client is asking for.
a client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to tell the server which options it wants sent back 💌 and a server MAY include one in a Reconfigure option to say which options the client should go request from it 🔁
22.8. Preference Option 👑
the Preference option is a server's way of flexing on clients 💅 it's sent by a server to a client to influence which server the client picks. the layout:
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 |
+-+-+-+-+-+-+-+-+option-codeisOPTION_PREFERENCE (7).option-lenis1.pref-valueis the preference value this server is putting out in this message.
a server MAY include a Preference option in an Advertise message to steer which server the client selects 🦋 check section 17.1.3 for how the client uses it and how to read that pref-value 🧐
22.9. Elapsed Time Option ⏱️
this one is all about the clock ⏰ it tells the server how long the client has been trying to finish its current DHCP transaction. here's how it looks:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-codeisOPTION_ELAPSED_TIME (8).option-lenis2.elapsed-timeis the time since the client started its current DHCP transaction, in hundredths of a second (10^-2 seconds).
a client MUST include an Elapsed Time option in its messages 🚨 the clock starts when the client sends the first message in the exchange, and that first message has elapsed-time set to 0 🥹 servers and Relay Agents use this number as input to their policy on how to respond. for example, it lets a secondary DHCP server jump in and answer when the primary has been ghosting for too long 👻
the elapsed-time value is an unsigned, 16 bit integer 🔢 and if the time is bigger than the biggest value it can hold, the client uses 0xffff to say "it's been forever" 💀
22.10. Relay Message Option 📬
the Relay Message option is the envelope 💌 it carries a DHCP message inside a Relay-forward or Relay-reply message. the layout:
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 .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-codeisOPTION_RELAY_MSG (9)option-lenis the length ofDHCP-relay-message.DHCP-relay-messagedepends on which message it's riding in 📦 in a Relay-forward message, it's the message that was received, passed along verbatim to the next relay agent or server. in a Relay-reply message, it's the message that gets copied and relayed on to the relay agent or client whose address is in thepeer-addressfield of that Relay-reply.
22.11. Authentication Option 🔐
the Authentication option carries the authentication info that proves who sent a DHCP message and that its contents haven't been messed with 🕵️♀️ section 21 explains how it's used. here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | auth-info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-codeisOPTION_AUTH (11).option-lenis11 + length of authentication information field.protocolis the authentication protocol used in this option 🧾algorithmis the algorithm used within that protocol 🧮RDMis the replay detection method used in this option 🔁replay detectionis the replay detection info for whichever RDM is in play 🕰️authentication informationis the auth data, shaped by the protocol and algorithm being used here ✨
and that's the vibe for this part, bestie 🦋
22.12. Server Unicast Option 🦋
okay so this one is giving "server, you're allowed to DM the client directly" 💌 The server sends this option to a client to say it's allowed to unicast messages to the server. Here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_UNICAST(12).option-len: 16.server-address: the IP address the client should send unicast messages to.
The server puts the IPv6 address the client should use in the server-address field. When a client gets this option, where permissible and appropriate, it sends messages straight to the server at that address 🎀
When the server sends a Unicast option to the client, some messages from the client won't be relayed by Relay Agents, and they won't include Relay Agent options from those agents. So a server should only send a Unicast option when Relay Agents aren't sending Relay Agent options 🙈 A DHCP server rejects any messages sent inappropriately using unicast, which makes sure messages still get relayed by Relay Agents whenever Relay Agent options are in use. Super important, bestie 💅
Details about when the client may send messages to the server using unicast are in section 18.
22.13. Status Code Option ✨
This option returns a status indication related to the DHCP message or option it appears in. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_STATUS_CODE(13).option-len: 2 + length ofstatus-message.status-code: the numeric code for the status in this option. The status codes are defined in section 24.4.status-message: a UTF-8 encoded text string meant for end users to read. It MUST NOT be null-terminated 🍓
A Status Code option may show up in the options field of a DHCP message, and/or in the options field of another option 🧚 If the Status Code option doesn't appear in a message where it could, the message's status is assumed to be Success.
22.14. Rapid Commit Option 🔥
The Rapid Commit option signals the use of the two message exchange for address assignment. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_RAPID_COMMIT(14).option-len: 0.
A client MAY include this option in a Solicit message if it's prepared to do the Solicit-Reply message exchange described in section 17.1.1 🌈
A server MUST include this option in a Reply message sent in response to a Solicit message when it's completing the Solicit-Reply message exchange 💜
DISCUSSION: Each server that responds with a Reply to a Solicit that includes a Rapid Commit option commits the assigned addresses in that Reply to the client, and it won't get any confirmation that the client actually received the Reply. So if more than one server responds to a Solicit with a Rapid Commit option, some servers will commit addresses that the client never ends up using 😭 The unused address problem can be minimized, for example, by designing the DHCP service so that only one server responds to the Solicit, or by using relatively short lifetimes for assigned addresses.
22.15. User Class Option 🌸
The User Class option is how a client identifies the type or category of user or applications it represents. Format:
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_USER_CLASS(15).option-len: length of the user class data field.user-class-data: the user classes the client carries.
The data in this option is made of one or more opaque fields, each representing a user class the client belongs to 👑 The server picks configuration information for the client based on those classes. For example, the User Class option can be used so that clients of people in the accounting department get a different printer than clients of people in the marketing department 🖨️ The user class information 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. Each instance is formatted like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+user-class-len is two octets long and specifies the length of the opaque user class data, in network byte order 🦋
A server interprets the classes in this option according to its configuration, so it can pick the right config for the client. A server may use only the user classes it's configured to interpret when selecting configuration information for a client, and ignore any other user classes 🙈 In response to a message containing a User Class option, the server includes a User Class option listing the classes it successfully interpreted, so the client knows which ones the server understood.
22.16. Vendor Class Option 💜
This option is how a client identifies the vendor that made the hardware it's running on. The info in the data area is made of one or more opaque fields that describe the hardware configuration 🧚 Format:
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 .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_VENDOR_CLASS(16).option-len: 4 + length of the vendor class data field.enterprise-number: the vendor's registered Enterprise Number, as registered with IANA [6].vendor-class-data: the hardware configuration of the host the client is running on.
The vendor-class-data is made of a bunch of separate items, and each one describes some characteristic of the client's hardware configuration ✨ Examples could be the version of the operating system the client is running, or how much memory is installed on the client 💻
Each instance of vendor-class-data is formatted like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+vendor-class-len is two octets long and specifies the length of the opaque vendor class data, in network byte order 🎀
22.17. Vendor-specific Information Option ✨
okay so this option is how clients and servers swap vendor-specific information 💅 it's basically a little bonus lane where a vendor can add their own fancy features 🦋
The format of the Vendor-specific Information option is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code: OPTION_VENDOR_OPTS (17)
option-len: 4 + length of option-data field
enterprise-number: The vendor's registered Enterprise Number as registered with IANA [6].
option-data: An opaque object of option-len octets, interpreted by vendor-specific code on the clients and servers
The information inside this option is totally vendor-defined. The vendor is named in the enterprise-number field 🏷️ Using vendor-specific info unlocks enhanced operation and extra features in a vendor's DHCP implementation 🚀 And here's the best part: a DHCP client that doesn't get the vendor-specific info it asked for will still set up the host's IPv6 stack so it works 🫶
The encapsulated vendor-specific options field MUST be encoded as a sequence of code/length/value fields of identical format to the DHCP options field. The option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each encapsulated option is formatted like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+opt-code: The code for the encapsulated option.
option-len: An unsigned integer giving the length of the option-data field in this encapsulated option in octets.
option-data: The data area for the encapsulated option.
Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option 💜
22.18. Interface-Id Option 🧚
okay this one is for relay agents 🌸 a relay agent MAY send the Interface-id option so the server knows which interface the client message came in on 💖 and if a relay agent gets a Relay-reply message carrying an Interface-id option, it relays the message 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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code: OPTION_INTERFACE_ID (18).
option-len: Length of interface-id field.
interface-id: An opaque value of arbitrary length generated by the relay agent to identify one of the relay agent's interfaces.
The server MUST copy the Interface-Id option from the Relay-Forward message into the Relay-Reply message it sends back to the relay agent in response to that Relay-Forward message. This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. Strict rules, bestie, no exceptions 🙅♀️
Servers MAY use the Interface-ID for parameter assignment policies. The Interface-ID SHOULD be considered an opaque value 🔐 Policies should be based on exact match only, which means the Interface-ID 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 changes, a server will not be able to use it reliably in parameter assignment policies. 😭
22.19. Reconfigure Message Option 🦋
A server includes a Reconfigure Message option in a Reconfigure message to tell the client whether to respond with a Renew message or an Information-request message 🔁 The format of this 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 |
+-+-+-+-+-+-+-+-+option-code: OPTION_RECONF_MSG (19).
option-len: 1.
msg-type: 5 for Renew message, 11 for Information-request message.
The Reconfigure Message option can only appear in a Reconfigure message. Keep it in its lane 💅
22.20. Reconfigure Accept Option 💜
this one is a yes-or-no vibe check 🫧 A client uses the Reconfigure Accept option to announce whether it's willing to accept Reconfigure messages, and a server uses it to tell the client whether or not to accept them 💬 If the option is missing, the default is no for both: the client is unwilling to accept Reconfigure messages, and the server is instructing the client not to accept them 🙅♀️ 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_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code: OPTION_RECONF_ACCEPT (20).
option-len: 0.
23. Security Considerations ✨
okay bestie, this section is SERIOUS 😭🔒 but I'm gonna explain it in my own words so it's easier to vibe with. DHCP's main threat is basically an insider threat 👀 (assuming the network is set up properly and DHCPv6 ports are blocked at the perimeter gateways of the enterprise 🧱). Even so, the gateway setup doesn't change the fact that attacks from insiders and outsiders are the same 💅.
Using manually configured preshared keys for IPsec between relay agents and servers does NOT protect against replayed DHCP messages 🙈. Replays can cause a DOS attack by eating up processing resources 🔥, but they can't cause misconfiguration or use up other stuff like assignable addresses 💀.
One attack that's specific to a DHCP client is a malicious server showing up with the goal of giving the client wrong configuration info 😈. The reason could be a "man in the middle" attack, so the client talks to a bad server instead of a legit one for something like DNS or NTP 🫣. The malicious server could also cause a denial of service by messing up the client's config so ALL its network communication fails 😭.
Then there's the threat to clients from DHCP servers that are mistakenly or accidentally misconfigured 🤦♀️. They answer client requests with wrong config parameters by accident, which is still rough 💔.
A client can also get attacked through a Reconfigure message from a malicious server 🚨. The client sends its response (Renew or Information-request) through a relay agent, so that response only reaches the servers the DHCP messages get relayed to 🛤️. BUT a malicious server could send a Reconfigure message to the client, then (after an appropriate delay ⏳) send a Reply that the client would accept 😱. So a malicious server that's NOT on the network path between the client and the server can still pull off a Reconfigure attack 👀. Using transaction IDs that are cryptographically sound and hard to predict also helps lower the chances that this attack works 🔐✨.
The threat specific to a DHCP server is an invalid client pretending to be a valid one 🎭. The motive could be stealing service or dodging auditing for all kinds of shady reasons 🕵️♀️.
The threat for BOTH the client and the server is the resource "denial of service" (DoS) attack 🌋. These usually involve running out of available addresses, or running out of CPU or network bandwidth 📉. They show up anytime there's a shared resource 🫠.
If relay agents add extra options to Relay Forward messages, the messages between relay agents and servers could be used to mount a "man in the middle" or denial of service attack 🚫.
The threat model here doesn't treat the privacy of DHCP message contents as important 🙅♀️. DHCP isn't used to swap authentication or config info that has to stay secret from other network nodes 🤐.
DHCP authentication lets clients and servers verify each other's identity, and protects the integrity of messages sent between them 🪪💜. It does NOT give any privacy for the contents of DHCP messages 👁️.
The Delayed Authentication protocol in section 21.4 uses a secret key shared between a client and a server 🗝️. A "DHCP realm" in the shared key lets a client figure out which administrative domain it's in, so it can pick the right key or keys when roaming between domains 🧭. BUT the Delayed Authentication protocol doesn't define any way to share keys, so a client might need a separate key for every administrative domain it runs into 😩. Shared keys may not scale well, and they don't offer a way to repudiate compromised keys ❌. This protocol is focused on the intradomain problem, where swapping a shared key out-of-band is feasible 🤝🌸.
Because of the attack risk through the Reconfigure message, a DHCP client MUST discard any Reconfigure message that does not include authentication, or that doesn't pass the validation process for the authentication protocol 🚫🛑. This is non-negotiable, periodt 💅.
The Reconfigure Key protocol in section 21.5 protects against a malicious DHCP server using a Reconfigure message to pull off a denial of service or man-in-the-middle attack on a client 🛡️. BUT this protocol can be broken by an attacker who can intercept the initial message where the DHCP server sends the key to the client 😬.
Communication between a server and a relay agent, and between relay agents, can be secured with IPsec, as described in section 21.1 🔒. Manual configuration and installation of static keys are acceptable here, because relay agents and the server belong to the same administrative domain 🏠, and the relay agents need other specific config anyway (like the DHCP server address) plus the IPsec config 🧩.
24. IANA Considerations 🎀
okay so this section is about the new name spaces DHCPv6 and its options need 🌈. The ones defined here are:
- Message types
- Status codes
- DUID
- Option codes
IANA set up a registry of values for each of these, which I'll walk through below 📋. IANA manages these name spaces, and they're all managed separately from the DHCPv4 name spaces 🙌.
New multicast addresses, message types, status codes, and DUID types are assigned via Standards Action [11] 🏛️.
New DHCP option codes are tentatively assigned once the spec for the option, published as an Internet Draft, has gotten expert review from a designated expert [11] 🧐. The final assignment of DHCP option codes happens through Standards Action, as defined in RFC 2434 [11] 🎯.
This document also references three name spaces in section 21 that go with the Authentication Option (section 22.11) 🔑. Those name spaces are defined by the authentication mechanism for DHCPv4 in RFC 3118 [4] 📜.
The authentication name spaces IANA has registered so far will apply to both DHCPv6 and DHCPv4 ✨. Going forward, specs that define new Protocol, Algorithm and RDM mechanisms will explicitly say whether those mechanisms are used with DHCPv4, DHCPv6, or both 💖.
24.1. Multicast Addresses
Section 5.1 defines the following multicast addresses, which IANA assigned for DHCPv6 use 📡:
All_DHCP_Relay_Agents_and_Servers address: FF02::1:2
All_DHCP_Servers address: FF05::1:324.2. DHCP Message Types
IANA recorded the following message types (defined in section 5.3) 💌. IANA will maintain the registry of DHCP message types 🗂️.
SOLICIT 1
ADVERTISE 2
REQUEST 3
CONFIRM 4
RENEW 5
REBIND 6
REPLY 7
RELEASE 8
DECLINE 9
RECONFIGURE 10
INFORMATION-REQUEST 11
RELAY-FORW 12
RELAY-REPL 1324.3. DHCP Options
IANA recorded the following option-codes (as defined in section 22) 🍓. IANA will maintain the registry of DHCP option codes 📒.
OPTION_CLIENTID 1
OPTION_SERVERID 2
OPTION_IA_NA 3
OPTION_IA_TA 4
OPTION_IAADDR 5
OPTION_ORO 6
OPTION_PREFERENCE 7
OPTION_ELAPSED_TIME 8
OPTION_RELAY_MSG 9
OPTION_AUTH 11
OPTION_UNICAST 12
OPTION_STATUS_CODE 13
OPTION_RAPID_COMMIT 14
OPTION_USER_CLASS 15
OPTION_VENDOR_CLASS 16
OPTION_VENDOR_OPTS 17
OPTION_INTERFACE_ID 18
OPTION_RECONF_MSG 19
OPTION_RECONF_ACCEPT 2024.4. Status Codes
IANA recorded the status codes in the table below 🧾. IANA will manage the definition of additional status codes in the future 🔮.
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
NoAddrsAvail 2 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
address.24.5. DUID
IANA recorded the following DUID types (as defined in section 9.1) 🪪. IANA will manage the definition of additional DUID types in the future 🌙.
DUID-LLT 1
DUID-EN 2
DUID-LL 325. Acknowledgments 🫶
Thanks to the DHC Working Group and the members of the IETF for their time and input into the specification 💜. Extra thanks for the consistent input, ideas, and review from (in alphabetical order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin, A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont, Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp, Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells 🌸✨.
Thanks to Steve Deering and Bob Hinden, who have consistently taken the time to discuss the more complex parts of the IPv6 specifications 🧠💖.
And thanks to Steve Deering for pointing out at IETF 51 in London that the DHCPv6 specification has the highest revision number of any Internet Draft 😂🏆.
26. References 📚
26.1. Normative References ✨
okay so the normative references are the docs this RFC needs you to have read, bestie 📚
[1]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[2]Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.[3]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[4]Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.[5]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.[6]IANA. Private Enterprise Numbers.http://www.iana.org/assignments/enterprise-numbers.html.[7]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[8]Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[9]Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.[10]Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.[11]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.[12]Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.[13]Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.[14]Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.[15]Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.[16]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.[17]Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
26.2. Informative References 🦋
these ones are the helpful extras. good to know, not strictly required 💜
[18]Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.[19]Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[20]R. Droms, Ed. DNS Configuration options for DHCPv6. April 2002. Work in Progress.[21]A. K. Vijayabhaskar. Time Configuration Options for DHCPv6. May 2002. Work in Progress.[22]Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
A. Appearance of Options in Message Types 💅
this appendix is the cheat sheet for which options are allowed in each DHCP message type. a * means yes, allowed 🫶
The following table indicates with a "*" the options are allowed in
each DHCP message type:
Client Server IA_NA Option Pref Time Relay Auth. Server
ID ID IA_TA Request Msg. Unica.
Solicit * * * * *
Advert. * * * * *
Request * * * * * *
Confirm * * * * *
Renew * * * * * *
Rebind * * * * *
Decline * * * * * *
Release * * * * * *
Reply * * * * * *
Reconf. * * * *
Inform. * (see note) * * *
R-forw. * *
R-repl. * *
NOTE:
Only included in Information-Request messages that are sent
in response to a Reconfigure (see section 19.4.3).
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
Solicit * * * * *
Advert. * * * * *
Request * * * *
Confirm * * *
Renew * * * *
Rebind * * * *
Decline * * *
Release * * *
Reply * * * * * *
Reconf. *
Inform. * * * *
R-forw. * * * *
R-repl. * * * *B. Appearance of Options in the Options Field of DHCP Options 🌈
and this one is the matching cheat sheet for where options can sit inside the options field of other options. it's options all the way down, iykyk 🪆
The following table indicates with a "*" where options can appear in
the options field of other options:
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
IA_NA/IA_TA *
IAADDR *
ORO *
Preference *
Elapsed Time *
Relay Message * *
Authentic. *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.Chair's Address 🎀
the working group can be reached through the current chair, Ralph Droms 🧚
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
Phone: (978) 936-1674
EMail: rdroms@cisco.comAuthors' Addresses 💖
the people who wrote this thing, with their contact details exactly as published 💅
Jim Bound
Hewlett Packard Corporation
ZK3-3/W20
110 Spit Brook Road
Nashua, NH 03062-2698
USA
Phone: +1 603 884 0062
EMail: Jim.Bound@hp.com
Bernie Volz
116 Hawkins Pond Road
Center Harbor, NH 03226-3103
USA
Phone: +1-508-259-3734
EMail: volz@metrocast.net
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: Ted.Lemon@nominum.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Mike Carney
Sun Microsystems, Inc
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1-650-786-4171
EMail: michael.carney@sun.comFull Copyright Statement ⭐
the legal bit. it stays word for word, no edits, because it's the actual license terms 🔒
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society, and that's the end of the RFC, bestie 🎉🦋👑
📦 where this page comes from
- ietf: rfc3315 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms