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 [RFC7283], 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.

   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 packet is relayed by a relay agent towards a server, a
   new encapsulation level is added around the packet.  Each relay is
   allowed to insert additional options on the encapsulation level it
   added but MUST NOT change anything in the packet being encapsulated.
   If there are multiple relays between a client and a server, multiple
   encapsulations are used.  Although it makes packet processing
   slightly more complex, it provides the major advantage of having a
   clear indication as to which relay inserted which option.  The
   response packet is expected to travel through the same relays, but in
   reverse order.  Each time a response packet 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 packet 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 packet
      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 packet 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.

20.  Authentication of DHCP Messages

   This document introduces two security mechanisms for the
   authentication of DHCP messages: (1) authentication (and encryption)
   of messages sent between servers and relay agents using IPsec and
   (2) protection against misconfiguration of a client caused by a
   Reconfigure message sent by a malicious DHCP server.

   The delayed authentication protocol, defined in [RFC3315], has been
   obsoleted by this document (see Section 25).

20.1.  Security of Messages Sent between Servers and Relay Agents

   Relay agents and servers that exchange messages can use IPsec as
   detailed in [RFC8213].

20.2.  Summary of DHCP Authentication

   Authentication of DHCP messages is accomplished through the use of
   the Authentication option (see Section 21.11).  The authentication
   information carried in the Authentication option can be used to
   reliably identify the source of a DHCP message and to confirm that
   the contents of the DHCP message have not been tampered with.

   The Authentication option provides a framework for multiple
   authentication protocols.  One such protocol, RKAP, is defined in
   Section 20.4.  Other protocols defined in the future will be
   specified in separate documents.

   Any DHCP message MUST NOT include more than one Authentication
   option.

   The protocol field in the Authentication option identifies the
   specific protocol used to generate the authentication information
   carried in the option.  The algorithm field identifies a specific
   algorithm within the authentication protocol; for example, the
   algorithm field specifies the hash algorithm used to generate the
   Message Authentication Code (MAC) in the Authentication option.  The
   RDM field specifies the type of replay detection used in the replay
   detection field.

20.3.  Replay Detection

   The RDM field of the Authentication option (see Section 21.11)
   determines the type of replay detection used in the replay detection
   field.

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a strictly monotonically increasing 64-bit
   unsigned integer (modulo 2^64).  Using this technique can reduce the
   danger of replay attacks.  This method MUST be supported by all
   Authentication option protocols.  One choice might be to use the
   64-bit NTP timestamp format [RFC5905]).

   A client that receives a message with the RDM field set to 0x00 MUST
   compare its replay detection field with the previous value sent by
   that same server (based on the Server Identifier option; see
   Section 21.3) and only accept the message if the received value is
   greater and record this as the new value.  If this is the first time

   a client processes an Authentication option sent by a server, the
   client MUST record the replay detection value and skip the replay
   detection check.

   Servers that support the reconfigure mechanism MUST ensure that the
   replay detection value is retained between restarts.  Failing to do
   so may cause clients to refuse Reconfigure messages sent by the
   server, effectively rendering the reconfigure mechanism useless.

20.4.  Reconfiguration Key Authentication Protocol (RKAP)

   RKAP provides protection against misconfiguration of a client caused
   by a Reconfigure message sent by a malicious DHCP server.  In this
   protocol, a DHCP server sends a reconfigure key to the client in the
   initial exchange of DHCP messages.  The client records the
   reconfigure key for use in authenticating subsequent Reconfigure
   messages from that server.  The server then includes a Hashed Message
   Authentication Code (HMAC) computed from the reconfigure key in
   subsequent Reconfigure messages.

   Both the reconfigure key sent from the server to the client and the
   HMAC in subsequent Reconfigure messages are carried as the
   authentication information in an Authentication option (see
   Section 21.11).  The format of the authentication information is
   defined in the following section.

   RKAP is used (initiated by the server) only if the client and server
   have negotiated to use Reconfigure messages.

20.4.1.  Use of the Authentication Option in RKAP

   The following fields are set in an Authentication option (see
   Section 21.11) for RKAP:

      protocol   3

      algorithm  1

      RDM        0

   The format of the authentication information for RKAP 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)              |
      +-+-+-+-+-+-+-+-+                                               |
      .                                                               .
      .                                                               .
      .                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 11: RKAP Authentication Information

      Type             Type of data in the Value field carried in this
                       option:

                          1    Reconfigure key value (used in the Reply
                               message).

                          2    HMAC-MD5 digest of the message (used in
                               the Reconfigure message).

                       A 1-octet field.

      Value            Data as defined by the Type field.  A 16-octet
                       field.

20.4.2.  Server Considerations for RKAP

   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 transmits that
   key to the client in an Authentication option (see Section 21.11) in
   the Reply message.

   The reconfigure key is 128 bits long and MUST be a cryptographically
   strong random or pseudorandom number that cannot easily be predicted.

   To provide authentication for a Reconfigure message, the server
   selects a replay detection value according to the RDM selected by the
   server and computes an HMAC-MD5 of the Reconfigure message using the
   reconfigure key for the 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 0 for the HMAC-MD5 computation.  The server includes
   the HMAC-MD5 in the authentication information field in an
   Authentication option included in the Reconfigure message sent to the
   client.

20.4.3.  Client Considerations for RKAP

   The client will receive a reconfigure key from the server in an
   Authentication option (see Section 21.11) in the initial Reply
   message from the server.  The client records the reconfigure key for
   use in authenticating subsequent Reconfigure messages.

   To authenticate a Reconfigure message, the client computes an
   HMAC-MD5 over the Reconfigure message, with zeroes substituted for
   the HMAC-MD5 field, using the reconfigure key received from the
   server.  If this computed HMAC-MD5 matches the value in the
   Authentication option, the client accepts the Reconfigure message.