How does a DHCPv6 relay agent carry a client's Solicit to a server on another subnet, and how does the server tell which link the client is on?

## Why DHCPv6 needs relays A DHCPv6 client sends every message to `ff02::1:2` (`All_DHCP_Relay_Agents_and_Servers`). The `ff02::` prefix means **link-local scope**, so no router forwards the packet off the client's link. A server elsewhere in the network hears the client only if a **relay agent**, usually the client's first-hop router, picks the message up and forwards it. RFC 9915 §19 defines how, using two messages that exist only between relays and servers: **Relay-forward** (`RELAY-FORW`, type 12) and **Relay-reply** (`RELAY-REPL`, type 13). ## The Relay-forward header | Field | Size | Set by the first relay to | |---|---|---| | `msg-type` | 1 octet | 12 (`RELAY-FORW`) | | `hop-count` | 1 octet | 0 | | `link-address` | 16 octets | a global (GUA or ULA) address from a prefix on the client's link | | `peer-address` | 16 octets | the source address of the client's packet, usually link-local | | options | variable | a **Relay Message** option (9) with the client's message, plus any options the relay adds | ## One Solicit, end to end 1. The client multicasts a `Solicit` to `ff02::1:2`, UDP port 547. 2. The relay on that link receives it and builds a `Relay-forward`. The client's DHCPv6 message, without its IP and UDP headers, goes **byte for byte** into the Relay Message option. 3. The relay may add an **Interface-Id** option (18). It MUST do so if `link-address` alone will not tell it which interface the reply belongs on. It SHOULD add a **Client Link-Layer Address** option (79, RFC 6939) with the client's MAC. 4. It sends the `Relay-forward` to UDP port 547 at the server addresses it was configured with. RFC 9915 says the list SHOULD include unicast addresses. If the relay has no list, it uses the site-scoped group `ff05::1:3` (`All_DHCP_Servers`). 5. The server works out the client's link from `link-address`, ignoring any field whose value is zero (RFC 6221). It then chooses addresses appropriate to that link and the client's DUID. 6. The server answers with a `Relay-reply` that copies `hop-count`, `link-address` and `peer-address`. Its Relay Message option holds the server's `Reply` (or `Advertise`), and it echoes the Interface-Id option if one was sent. 7. The relay extracts the inner message and sends it, **unmodified**, to `peer-address` on UDP port 546. It uses the link that Interface-Id names, or else the one `link-address` identifies. A plain relay keeps no per-client state: everything it needs to deliver the answer comes back inside the Relay-reply. A relay that also routes delegated prefixes is the exception, because it must remember each delegation. ## Chains of relays When the next hop toward the server is another relay, the second relay wraps the whole `Relay-forward` in a new one: - it copies the packet's source address into `peer-address` and sets `hop-count` to the received value plus 1; - if that source is a global or ULA address, it sets `link-address` to 0; otherwise it uses one of its own global addresses or adds an Interface-Id option; - it discards a `Relay-forward` whose `hop-count` has already reached `HOP_COUNT_LIMIT`, 8 by default. Each relay may add options only at its own level and MUST NOT change anything inside the layer it wraps. The server therefore sees exactly which relay inserted which option. The server answers with Relay-reply layers nested in the same order, and each relay strips one layer on the way back. The innermost `link-address`, the one closest to the client, is normally the useful one. ## Lightweight relays Access nodes that bridge rather than route can run a **Lightweight DHCPv6 Relay Agent** (LDRA, RFC 6221). An LDRA has no address on the client's subnet, so it sets `link-address` to `::` and always includes an Interface-Id option. A routing relay further up wraps the message again and supplies an address the server can use to identify the link. ## The contrast with DHCPv4 relaying A DHCPv4 relay writes its own address into the `giaddr` field of the client's message and forwards that same, edited message. A DHCPv6 relay never edits the client's message. It wraps it, and the wrapper carries the link information. That keeps the client's message intact for the server and lets relays stack without overwriting one another. ## What RFC 9915 changed RFC 8415 had a Server Unicast option that let clients bypass relays and unicast to a server. RFC 9915 obsoletes it. Appendix A notes that it was "rarely practical as typically relay agents between the client and server need to glean information from the communication and cannot be bypassed". Clients now always multicast, so relays always see the traffic.