19. Relay Agent Behavior
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
19. Relay Agent Behavior
The relay agent SHOULD be configured to use a list of destination
addresses that includes unicast addresses. The list of destination
addresses MAY include the All_DHCP_Servers multicast address or other
addresses selected by the network administrator. If the relay agent
has not been explicitly configured, it MUST use the All_DHCP_Servers
multicast address as the default.
If the relay agent relays messages to the All_DHCP_Servers multicast
address or other multicast addresses, it sets the Hop Limit field to
8.
If the relay agent receives a message other than Relay-forward and
Relay-reply and the relay agent does not recognize its message type,
it MUST forward the message as described in Section 19.1.1.
19.1. Relaying a Client Message or a Relay-forward Message
A relay agent relays both messages from clients and Relay-forward
messages from other relay agents. When a relay agent receives a
Relay-forward message, a recognized message type for which it is not
the intended target, or an unrecognized message type, it constructs a
new Relay-forward message. The relay agent copies the source address
from the header of the IP datagram in which the message was received
into the peer-address field of the Relay-forward message. The relay
agent copies the received DHCP message (excluding any IP or UDP
headers) into a Relay Message option (see Section 21.10) in the new
message. The relay agent adds to the Relay-forward message any other
options it is configured to include.
[RFC6221] defines a Lightweight DHCPv6 Relay Agent (LDRA) that allows
relay agent information to be inserted by an access node that
performs a link-layer bridging (i.e., non-routing) function.
19.1.1. Relaying a Message from a Client
If the relay agent received the message to be relayed from a client,
the relay agent places a globally scoped unicast address (i.e., GUA
or ULA) from a prefix assigned to the link on which the client should
be assigned leases into the link-address field. If such an address
is not available, the relay agent may set the link-address field to a
link-local address from the interface on which the original message
was received. This is not recommended, as it may require that
additional information be provided in the server configuration. See
Section 3.2 of [RFC7969] for a detailed discussion.
This address will be used by the server to determine the link from
which the client should be assigned leases and other configuration
information.
The hop-count value in the Relay-forward message is set to 0.
The relay SHOULD insert a Client Link-Layer Address option as
described in [RFC6939].
If the relay agent cannot use the address in the link-address field
to identify the interface through which the response to the client
will be relayed, the relay agent MUST include an Interface-Id option
(see Section 21.18) in the Relay-forward message. The server will
include the Interface-Id option in its Relay-reply message. The
relay agent sets the link-address field as described earlier in this
subsection, regardless of whether the relay agent includes an
Interface-Id option in the Relay-forward message.
19.1.2. Relaying a Message from a Relay Agent
If the message received by the relay agent is a Relay-forward message
and the hop-count value in the message is greater than or equal to
HOP_COUNT_LIMIT, the relay agent discards the received message.
The relay agent copies the source address from the IP datagram in
which the message was received into the peer-address field in the
Relay-forward message and sets the hop-count field to the value of
the hop-count field in the received message incremented by 1.
If the source address from the IP datagram header of the received
message is a globally scoped unicast address (i.e., GUA or ULA), the
relay agent sets the link-address field to 0; otherwise, the relay
agent sets the link-address field to a globally scoped unicast
address (i.e., GUA or ULA) assigned to the interface on which the
message was received or includes an Interface-Id option (see
Section 21.18) to identify the interface on which the message was
received.
19.1.3. Relay Agent Behavior with Prefix Delegation
A relay agent forwards messages containing prefix delegation options
in the same way as it would relay addresses (i.e., per Sections
19.1.1 and 19.1.2).
If a server communicates with a client through a relay agent about
delegated prefixes, the server may need a protocol or other out-of-
band communication to configure routing information for delegated
prefixes on any router through which the client may forward traffic.
19.2. Relaying a Relay-reply Message
The relay agent processes any options included in the Relay-reply
message in addition to the Relay Message option (see Section 21.10).
The relay agent extracts the message from the Relay Message option
and relays it to the address contained in the peer-address field of
the Relay-reply message. Relay agents MUST NOT modify the message.
If the Relay-reply message includes an Interface-Id option (see
Section 21.18), the relay agent relays the message from the server to
the client on the link identified by the Interface-Id option.
Otherwise, if the link-address field is not set to 0, the relay agent
relays the message on the link identified by the link-address field.
If the relay agent receives a Relay-reply message, it MUST process
the message as defined above, regardless of the type of message
encapsulated in the Relay Message option.
19.3. Construction of Relay-reply Messages
A server uses a Relay-reply message to (1) return a response to a
client if the original message from the client was relayed to the
server in a Relay-forward message or (2) send a Reconfigure message
to a client if the server does not have an address it can use to send
the message directly to the client.
A response to the client MUST be relayed through the same relay
agents as the original client message. The server causes this to
happen by creating a Relay-reply message that includes a Relay
Message option (see Section 21.10) containing the message for the
next relay agent in the return path to the client. The contained
Relay-reply message contains another Relay Message option to be sent
to the next relay agent, and so on. The server must record the
contents of the peer-address fields in the received message so it can
construct the appropriate Relay-reply message carrying the response
from the server.
For example, if client C sent a message that was relayed by relay
agent A to relay agent B and then to the server, the server would
send the following Relay-reply message to relay agent B:
msg-type: RELAY-REPL
hop-count: 1
link-address: 0
peer-address: A
Relay Message option containing the following:
msg-type: RELAY-REPL
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
Figure 10: Relay-reply Example
When sending a Reconfigure message to a client through a relay agent,
the server creates a Relay-reply message that includes a Relay
Message option containing the Reconfigure message for the next relay
agent in the return path to the client. The server sets the peer-
address field in the Relay-reply message header to the address of the
client and sets the link-address field as required by the relay agent
to relay the Reconfigure message to the client. The server obtains
the addresses of the client and the relay agent through prior
interaction with the client or through some external mechanism.
19.4. Interaction Between Relay Agents and Servers
Each time a message is relayed by a relay agent towards a server, a
new encapsulation level is added around the message. Each relay is
allowed to insert additional options on the encapsulation level it
added but MUST NOT change anything in the message being encapsulated.
If there are multiple relays between a client and a server, multiple
encapsulations are used. Although it makes message processing
slightly more complex, it provides the major advantage of having a
clear indication as to which relay inserted which option. The
response message is expected to travel through the same relays, but
in reverse order. Each time a response message is relayed back
towards a client, one encapsulation level is removed.
In certain cases, relays can add one or more options. These options
can be added for several reasons:
* First, relays can provide additional information about the client.
That source of information is usually more trusted by a server
administrator, as it comes from the network infrastructure rather
than the client and cannot be easily spoofed. These options can
be used by the server to determine its allocation policy.
* Second, a relay may need some information to send a response back
to the client. Relay agents are expected to be stateless (not
retain any state after a message has been processed). A relay
agent may include the Interface-Id option (see Section 21.18),
which will be echoed back in the response. It can include other
options and ask the server to echo one or more of the options back
in the response. These options can then be used by the relay
agent to send the response back to the client, or for other needs.
The client will never see these options. See [RFC4994] for
details.
* Third, sometimes a relay is the best device to provide values for
certain options. A relay can insert an option into the message
being forwarded to the server and ask the server to pass that
option back to the client. The client will receive that option.
It should be noted that the server is the ultimate authority here,
and -- depending on its configuration -- it may or may not send
the option back to the client. See [RFC6422] for details.
For various reasons, servers may need to retain the relay information
after the message processing is completed. One is a bulk leasequery
mechanism that may ask for all addresses and/or prefixes that were
assigned via a specific relay. A second is for the reconfigure
mechanism. The server may choose to not send the Reconfigure message
directly to the client but rather to send it via relays. This
particular behavior is considered an implementation detail and is out
of scope for this document.