DHC C. Porfiri Internet-Draft J. Arkko Intended status: Standards Track M. Kühlewind Expires: 24 April 2024 Ericsson 22 October 2023 DHCPv4 Relay Agent Information Option Passing Extensions draft-porfiri-dhc-dhcpv4-raio-nesting-latest Abstract This document describes a general mechanism whereby DHCP relay agents can encapsulate DHCP packets that they are forwarding in the direction of DHCP servers, and decapsulate packets that they they are forwarding toward DHCP clients, so that more than one relay agent can insert relay agent suboptions into the forwarding chain. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Porfiri, et al. Expires 24 April 2024 [Page 1] Internet-Draft DHCPv4 RAIO Nesting October 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 5 2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . 6 2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . 6 2.3. Layer Two Address suboption . . . . . . . . . . . . . . . 6 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. The fixed-length header . . . . . . . . . . . . . . . . . 8 3.2. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Encapsulation Segment . . . . . . . . . . . . . . . . . . 9 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 10 4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packets traveling toward DHCP servers . . . . . . . . 11 4.1.2. Packets traveling toward DHCP clients . . . . . . . . 11 4.1.3. Anti-spoofing . . . . . . . . . . . . . . . . . . . . 11 4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . 12 4.2.1. Initializing the fixed-length header . . . . . . . . 12 4.2.2. Initializing the relay segment . . . . . . . . . . . 12 4.2.3. Fixed header settings for RELAYFORWARD messages . . . 13 4.2.4. Fixed header settings for BOOTREQUEST messages . . . 13 4.2.5. Initializing the encapsulation segment . . . . . . . 13 4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 14 4.3.1. Processing relay agent suboptions . . . . . . . . . . 14 4.3.2. Constructing the decapsulated message . . . . . . . . 14 4.4. Retransmitting modified messages . . . . . . . . . . . . 14 4.5. Layer two relay agents . . . . . . . . . . . . . . . . . 14 4.5.1. Constructing the headers . . . . . . . . . . . . . . 15 4.5.2. Forwarding the modified packet . . . . . . . . . . . 15 4.6. Layer Three Relay Agents . . . . . . . . . . . . . . . . 16 4.6.1. Transmitting a decapsulated RELAYREPLY message . . . 16 4.6.2. Transmitting a decapsulated BOOTREPLY message . . . . 16 4.6.3. Transmitting other messages . . . . . . . . . . . . . 16 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 16 5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 16 5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Processing of decapsulated suboptions . . . . . . . . 17 5.1.3. Address allocation . . . . . . . . . . . . . . . . . 18 5.1.4. Default link selection algorithm . . . . . . . . . . 18 5.1.5. Other link selection algorithms . . . . . . . . . . . 19 5.2. Responding to RELAYFORWARD messages . . . . . . . . . . . 19 5.2.1. Constructing a RELAYREPLY encapsulation . . . . . . . 19 5.2.2. Transmission of RELAYREPLY messages . . . . . . . . . 20 5.3. Responding to messages other than RELAYFORWARD . . . . . 21 6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . 21 7. Layer 2 Relay Agent Information . . . . . . . . . . . . . . . 21 7.1. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . 21 Porfiri, et al. Expires 24 April 2024 [Page 2] Internet-Draft DHCPv4 RAIO Nesting October 2023 7.2. Layer 2 Relay Agent in various network scenarios . . . . 22 7.2.1. DHCP server and client on same subnet . . . . . . . . 22 7.2.2. Multiple DHCP server and Client on same subnet . . . 25 7.2.3. DHCP server on another subnet with one Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.4. DHCP server on another subnet with multiple Layer 3 Relay Agents . . . . . . . . . . . . . . . . . . . . 29 8. Conventions and Definitions . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction In some networking environments, it is useful to be able to configure relay agents in a hierarchy, so that information from a relay agent close to the client can be combined with information from one or more relay agents closer to the server, particularly in cases where the relay agents may be in separate administrative domains. The current Relay Agent Information Option (RAIO) specification (Patrick, M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046] specifies that when a relay agent receives a packet containing an RAIO, it must not add an RAIO. This prevents chaining of RAIOs, and hence prohibits the hierarchical use case. DHCP version 6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," July 2003.) [RFC3315] provides a much cleaner technique for providing RAIO suboptions to the DHCP server. Rather than appending an information option to the DHCP client's message, the relay agent encapsulates the DHCP client message in a new DHCP message which it sends to the DHCP server along with any options it chooses to add to provide information to the DHCP server. This document specifies a mechanism for providing the same functionality in DHCPv4. it is a republication and fine-tuning of ideas discussed earlier in the IETF which did not lead to a standard specification, see [I-D.ietf-dhc-dhcpv4-relay-encapsulation] [I-D.ietf-dhc-l2ra]. The topic is brought up now due to new situations where this kind of functionality is needed (see {Need_of_L2RA}). Porfiri, et al. Expires 24 April 2024 [Page 3] Internet-Draft DHCPv4 RAIO Nesting October 2023 1.1. Terminology The following terms and acronyms are used in this document: * BOOTREPLY message Any DHCP or BOOTP message in which the 'op' field is set to BOOTREPLY. * BOOTREQUEST message Any DHCP or BOOTP message in which the 'op' field is set to BOOTREQUEST. * DHCP Dynamic Host Configuration Protocol Version 4 [RFC2131] (Droms, R., "Dynamic Host Configuration Protocol," March 1997.) * decapsulate The act of de-encapsulating DHCP packets being relayed from DHCP servers or relay agents in the direction of DHCP clients, according to this specification. * encapsulate The act of encapsulating DHCP packets that are being relayed from DHCP clients or relay agents toward DHCP servers, according to the method described in this specification. * encapsulating relay agent A relay agent that implements this specification and is configured to encapsulate. * L2RA Layer 2 Relay Agent -- a relay agent that doesn't have an IP address reachable by the DHCP server. * L3RA Layer 3 Relay Agent -- a relay agent that has an IP address reachable by the DHCP server. * option buffer Porfiri, et al. Expires 24 April 2024 [Page 4] Internet-Draft DHCPv4 RAIO Nesting October 2023 The portion of the DHCP packet following the magic cookie in the 'vend' field of the DHCP Packet. * RAIO Relay Agent Information Option (Patrick, M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046]. Also commonly referred to as "Option 82." * RAIO suboption A DHCP suboption that has been defined for encapsulation in the Relay Agent Information Option * relay message A RELAYFORWARD or RELAYREPLY message. * RELAYFORWARD message: Any DHCP or BOOTP message in which the 'op' field is set to RELAYFORWARD. * RELAYREPLY message: Any DHCP or BOOTP message in which the 'op' field is set to RELAYREPLY. * silently discard: In many places in this specification, the implementation is required to silently discard erroneous messages. What is meant by 'silently discard' is that the implementation MUST NOT send any ICMP message indicating that the delivery was in error. It may be desirable for the implementation to keep a count of messages that have been discarded, either by message type or by reason for discarding, or some combination. Nothing in this specification should be construed to forbid such data collection. 2. Protocol Summary This document specifies two new BOOTP message types: the RELAYFORWARD message, and the RELAYREPLY message. These messages are analogous to the Relay Forward and Relay Reply messages in DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," July 2003.) [RFC3315]. Porfiri, et al. Expires 24 April 2024 [Page 5] Internet-Draft DHCPv4 RAIO Nesting October 2023 Although this specification is generally aimed at DHCP implementations, it is not specifically restricted to DHCP, and is applicable to BOOTP in cases where the BOOTP server is a DHCP server that implements this specification, or the less likely case that the BOOTP server only supports the BOOTP protocol, but still implements this specification. In general, when the term "DHCP" appears in this specification, the reader should not read this as intending to exclude BOOTP. 2.1. RELAYFORWARD Message Conforming relay agents encapsulate messages being sent toward DHCP servers in RELAYFORWARD messages. 2.2. RELAYREPLY Message A conforming DHCP server encapsulates any message being sent toward a DHCP client in a RELAYREPLY message, if the message being responded to was encapsulated. A conforming relay agent, when it receives a RELAYREPLY message, decapsulates the message contained in the RELAYREPLY message and sends it to the next relay or to the client. 2.3. Layer Two Address suboption In cases where the closest relay agent to the client is an L2RA, but where there is an L3RA on the path to the client, the DHCP server will encode the link layer address that would normally go in the chaddr field of the DHCP packet into a Layer Two Address suboption. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUBOPT_L2AS | length | htype | chaddr ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Layer 2 Address Suboption The Layer Two Address suboption has four fields: * SUBOPT_L2AS One octet - suboption code for the Layer Two Address suboption (TBD). * length Porfiri, et al. Expires 24 April 2024 [Page 6] Internet-Draft DHCPv4 RAIO Nesting October 2023 One octet - length of the Layer Two Address suboption. * htype One octet - type of the Layer Two Address suboption -- corresponds to the 'htype' field in a non-relay DHCP or BOOTP message. * chaddr One or more octets - layer two address of the client, from the 'chaddr' field of the DHCP or BOOTP message. 3. Encoding RELAYFORWARD and RELAYREPLY messages are distinguished through the use of the 'op' field of the DHCP packet. In non-relay DHCP packets, the 'op' field either contains BOOTREQUEST, for any DHCP message from the client to the server, or BOOTREPLY, for any DHCP message from the server to the client. This document defines two additional codes, RELAYFORWARD and RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST support these two new values for the 'op' field. DHCP clients should never see either value. |-----:|:--------------| | code | meaning | |-----:|:--------------| | 1 | BOOTREQUEST | | 2 | BOOTREPLY | | 3 | RELAYFORWARD | | 4 | RELAYREPLY | |-----:|:--------------| Figure 2 RELAYFORWARD and RELAYREPLY messages share only the 'op' field in common with other DHCP and BOOTP messages. The remainder of the message consists of a series of fixed-length fields followed by two variable-length fields: the relay segment, and the encapsulated message. Porfiri, et al. Expires 24 April 2024 [Page 7] Internet-Draft DHCPv4 RAIO Nesting October 2023 +-----+-----+-----+-----+ | op | ep | padlen | +-----+-----+-----+-----+ | rslen | caplen | +-----+-----+-----+-----+ | aiaddr | +-----+-----+-----+-----+ . . . relay segment . . . +-----------------------+ . . . encapsulated message . . . +-----------------------+ Figure 3: Structure of RELAYFORWARD and RELAYREPLY messages 3.1. The fixed-length header The fixed-length header of the relay message contains a series of fields that perform two purposes: to provide enough information that the DHCP server can reconstruct the original packet sent by the DHCP client, and to establish the lengths of the two variable-length segments. To satisfy the first of these requirements, two fields in the fixed- length header report the amount of padding stripped from the client message, if any, and whether or not an end option was stripped from the client message. Except for a relay message that immediately encapsulates a message from a DHCP client, these fields are always zero. Using these two fields, the DHCP server can reconstruct the client packet exactly, and this allows the DHCP server to validate any signature (Droms, R. and W. Arbaugh, "Authentication for DHCP Messages," June 2001.) [RFC3118] that may be present. The fixed-length header consists of five fields: * op The BOOTP 'op' field, which, for a relay message, MUST contain the RELAYFORWARD or RELAYREPLY code. * ep If an End option was present in the option buffer prior to encapsulation, this field is set to 1; otherwise, it is set to 0. This field is a single byte. Porfiri, et al. Expires 24 April 2024 [Page 8] Internet-Draft DHCPv4 RAIO Nesting October 2023 * padlen The length of any padding that was removed from the option buffer prior to encapsulation: two bytes in network byte order. * rslen The length of the relay segment: two byte in network byte order. * caplen The length of the encapsulation segment: two byte in network byte order. * aiaddr Relay agent IP address. 3.2. Relay Segment The relay segment contains any RAIO suboptions that the encapsulating agent (the relay agent or the DHCP server) wishes to send. End and Pad options MUST NOT appear within the relay segment. 3.3. Encapsulation Segment The encapsulation segment contains the entire DHCP message being encapsulated, with four exceptions: * The encapsulating agent MUST omit the IP and UDP headers, as well as any layer two header, from the encapsulated message. * The encapsulating agent MUST omit any options following the first End option in the option buffer. These options are assumed to be garbage, and are not covered by any signature (Droms, R. and W. Arbaugh, "Authentication for DHCP Messages," June 2001.) [RFC3118]. * The encapsulating MUST omit any Pad options present either at the end of the option buffer, or prior to the first End packet, that are followed only by other Pad options or a single End option. The encapsulating agent MUST record number of Pad options that were omitted in the 'padlen' field of the message header. * The encapsulating agent MUST omit the End option, if present. The encapsulating agent MUST set the 'ep' field in the message header to 1 if an End option was present in the option buffer, and to zero if no End option was present. Porfiri, et al. Expires 24 April 2024 [Page 9] Internet-Draft DHCPv4 RAIO Nesting October 2023 These exceptions apply only to the option buffer. The encapsulating agent MUST NOT modify the contents of the 'file' and 'sname' fields. The encapsulating agent MUST NOT count End or Pad options that appear in these fields. 4. DHCP Relay Agent Behavior DHCP Relay agents implementing this specification MUST have a configuration parameter controlling relay encapsulation. By default, relay encapsulation MUST be disabled. Relay agents with encapsulation disabled MUST NOT encapsulate. Relay agents with encapsulation disabled MUST NOT decapsulate. In any case where a relay agent implementing this specification does not encapsulate or decapsulate, it MUST behave exactly as a relay agent would that did not implement this specification at all. DHCP relay agents that are configured with encapsulation enabled, but which have no agent-specific options to send to the DHCP server, MUST encapsulate. Relay agents that are configured with encapsulation enabled MUST decapsulate. Layer two relay agents MUST silently discard any messages that contains an IPsec authentication header (Kent, S., "IP Authentication Header," December 2005.) [RFC4302]. This is because they cannot modify such packets, but also cannot detect that a message from the DHCP server is in response such a message, since it might not contain an IPsec authentication header. 4.1. Packet processing Relay agents implementing this specification may receive packets directed toward DHCP servers with a source port of 67 (BOOTPS). Therefore, the source port cannot be used to determine whether the packet is traveling toward a DHCP server or toward a DHCP client. In order to determine whether a message is traveling toward a DHCP client or toward a DHCP server, the relay agent must check the 'op' field of the DHCP message. If the 'op' field is set to BOOTREQUEST or RELAYFORWARD, the message is traveling toward a DHCP server. If the 'op' field is set to BOOTREPLY or RELAYREPLY, the message is traveling toward a DHCP client. At the time of the writing of this specification, no other value is meaningful in the 'op' field. Relay agents implementing this specification MUST NOT encapsulate or decapsulate messages with other values in the 'op' field. It is assumed that if meanings are defined for additional values, the Porfiri, et al. Expires 24 April 2024 [Page 10] Internet-Draft DHCPv4 RAIO Nesting October 2023 document that specifies the meaning of those values will update this document; in the absence of such an update, the behavior specified here will remain in effect. Relay agents implementing this specification MAY differentiate between DHCP and BOOTP messages. Under normal circumstances, BOOTP and DHCP messages are forwarded to the same server, which should be able to successfully decapsulate both DHCP and BOOTP messages. However, some relay agents may send BOOTP and DHCP packets to different servers; this document should not be construed to require that such a relay agent should encapsulate all messages regardless of protocol. 4.1.1. Packets traveling toward DHCP servers Any DHCP or BOOTP packet with an 'op' value of BOOTREQUEST or RELAYFORWARD is traveling toward a DHCP server. When a DHCP relay agent that is configured to encapsulate receives such a packet, the relay agent MUST encapsulate that packet into a RELAYFORWARD message and send it to the address or addresses with which it is configured to forward messages intended for DHCP servers. 4.1.2. Packets traveling toward DHCP clients Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY or RELAYREPLY is traveling toward a DHCP client. When a DHCP relay agent that is configured to encapsulate recieves a RELAYREPLY message that is traveling toward a DHCP or BOOTP client, the relay agent MUST decapsulate that message and forward the decapsulated message toward the client. 4.1.3. Anti-spoofing Because this specification allows for chaining of relay agent- supplied information, it is now possible for a relay agent outside of the trusted portion of a network to communicate relay agent information to the DHCP server without preventing the legitimate relay from communicating return path information to the DHCP server, as is the case with RFC3046. In order to prevent this sort of spoofing, relay agents implementing this specification MUST be configurable to discard all RELAYFORWARD messages that they receive. Administrators relying on a trusted network architecture to control the flow of information to the DHCP server SHOULD configure relay agents on the edge of their networks to discard RELAYFORWARD messages. Porfiri, et al. Expires 24 April 2024 [Page 11] Internet-Draft DHCPv4 RAIO Nesting October 2023 4.2. Constructing RELAYFORWARD messages 4.2.1. Initializing the fixed-length header The relay agent constructs the RELAYFORWARD message by constructing the fixed-length header as specified in the earlier section titled 'Encoding'. The relay agent MUST set the 'op' field to a value of RELAYFORWARD. If the relay agent is not a layer two relay agent [I-D.ietf-dhc-l2ra] (see Section 7), it MUST store one of its own IP addresses in the 'aiaddr' field. This address MUST be a valid IP address that is reachable by the next hop relay(s) or DHCP server(s) to which the relay agent is configured to forward. DHCP servers normally use the relay agent IP address to determine on what link the DHCP client's IP address should be allocated. In some cases, the value stored in the 'aiaddr' field will not be a valid IP address on the link on which the source message was received. In this case, the relay agent MUST include a link selection suboption (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4," April 2003.) [RFC3527] that identifies that link in the relay segment. If the relay agent is a layer two relay agent, it MAY include a link selection suboption in the relay segment. If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy the value of the 'aiaddr' field in the RELAYFORWARD message being encapsulated into the 'aiaddr' field of the RELAYFORWARD message that it generates. The 'rslen' field depends on the length of the relay segment. The 'caplen', 'padlen' and 'ep' values in the fixed header are initialized differently depending on whether the message being encapsulated is a BOOTREQUEST or a RELAYFORWARD message. 4.2.2. Initializing the relay segment Following the fixed header, the relay agent MUST append any RAIO suboptions it wishes to send to the DHCP server; this is the 'relay segment'. It MUST store the length of the relay segment in the 'rslen' field of the fixed header. Porfiri, et al. Expires 24 April 2024 [Page 12] Internet-Draft DHCPv4 RAIO Nesting October 2023 The relay agent SHOULD include a Relay Agent ID suboption (Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption," July 2009.) [RFC6925] in the relay segment to identify itself to the DHCP server. 4.2.3. Fixed header settings for RELAYFORWARD messages If the message being encapsulated is a RELAYFORWARD message, the relay agent MUST initialize the 'caplen' field of the fixed header to the length of the source message, excluding any layer 2, IP and UDP headers. It MUST append the contents of the message, again excluding any layer 2, IP or UDP headers, to the new message. It MUST initialize the 'ep' and 'padlen' fields in the fixed header of the new message to zero. 4.2.4. Fixed header settings for BOOTREQUEST messages If the message being encapsulated is a BOOTREQUEST message, the relay agent determines the length of the encapsulation segment by scanning forward across the option buffer of the source message, beginning with the first option in the option buffer, until an End option is reached, or the end of the buffer is reached. The difference between the offset of this location in the message and the offset of the first location following the UDP header of the message is the length of the message to be relayed. If an End option terminated the scan, the relay agent MUST set the value of the 'ep' field in the fixed header to one. Otherwise, the relay agent MUST set the value of the 'ep' field to zero. The relay agent MUST count all of the Pad options that follow the last option in the option buffer that is neither a Pad nor an End option. The relay agent MUST store this count in the 'padlen' field of the fixed header. The relay agent MUST store the difference between the value stored in 'padlen' and the length of the message to be relayed in the 'caplen' field of the fixed header. 4.2.5. Initializing the encapsulation segment The relay agent MUST copy the portion of the message being encapsulated that immediately follows the UDP header into the RELAYFORWARD message being generated. The length of the data being copied is the value that was stored in 'caplen'. Porfiri, et al. Expires 24 April 2024 [Page 13] Internet-Draft DHCPv4 RAIO Nesting October 2023 4.3. Decapsulating RELAYREPLY messages To decapsulate a RELAYREPLY message, the relay agent creates a decapsulated message, processes any RAIO suboptions it recognizes in the relay segment, and forwards the decapsulated message to its destination. 4.3.1. Processing relay agent suboptions The suboptions parsed from the relay segment are processed by the relay agent as specified in the Relay Agent Information Option specification (Patrick, M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046], as well as in any documents that define suboptions to the Relay Agent Information Option. A current list of DHCP Relay Agent suboptions and the documents that define them can be located in the IANA protocol registry for Bootp and DHCP parameters, in the section titled "DHCP Relay Agent Sub-Option Codes." 4.3.2. Constructing the decapsulated message To construct a decapsulated message, the relay agent copies the portion of the RELAYREPLY message following the relay segment, with a length specified in the 'caplen' field of the fixed-length header, into the new message. 4.4. Retransmitting modified messages If the relay agent did not modify the message either by encapsulating or decapsulating it, it retransmits the message according to existing practice. Otherwise, how the modified message is transmitted to its next destination depends on two factors. First, is the relay agent that modified the message a layer two (Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information," April 2009.) [I-D.ietf-dhc-l2ra] relay agent (see Section 4.5) or a layer three (Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol," October 1993.) [RFC1542] relay agent (see Section 4.6)? Second, is the modified message a BOOTREPLY message, a RELAYREPLY message, or some other message? 4.5. Layer two relay agents There are two special aspects to the handling of relayed packets in Layer Two Relay Agents (L2RAs). The first is the construction of the layer two, IP and UDP headers on the packet. The second is how the L2RA makes the forwarding decision. Porfiri, et al. Expires 24 April 2024 [Page 14] Internet-Draft DHCPv4 RAIO Nesting October 2023 4.5.1. Constructing the headers The L2RA constructs the headers on the relayed packet by copying and, as necessary, modifying the headers from the original packet. If there is a layer two header, the L2RA MUST copy this header in accordance with the needs of the particular layer two implementation it is using. If the header contains a packet length field, the L2RA MUST adjust the value in the packet length field. If the header contains a non-secure integrity check such as a CRC or checksum that covers the entire packet, the L2RA MUST recompute this value. L2RA encapsulation in cases where the layer two contains a secure integrity check must either construct a new integrity signature, or else remove the integrity signature. If neither of these is possible, the L2RA MUST silently discard the packet. If the IP header contains any sort of secure integrity check on the packet, the L2RA MUST silently discard the packet. The L2RA MUST adjust Total Length field in the IP header. In other respects, L2RA MUST copy the IP header without modification. The L2RA MUST copy the UDP header and adjust the 'Length' field carried within it (Postel, J., "User Datagram Protocol," August 1980.) [RFC0768]. If the contents of the 'Checksum' field are not zero, the L2RA MUST compute a new checksum according to the algorithm specified in User Datagram Protocol. (Postel, J., "User Datagram Protocol," August 1980.) [RFC0768] 4.5.2. Forwarding the modified packet Ordinarily when a layer two device forwards a packet, it simply copies that packet from the interface on which it was received and transmits it, unchanged, on one or more interfaces other than that interface. The mechanism used to choose which interfaces it forwards the packet to is beyond the scope of this document. Once a DHCP packet has been modified by the L2RA either as an encapsulation or a decapsulation, the L2RA must forward it either toward the DHCP server or the DHCP client. The implementation has two options: transmit the packet as it would transmit any other packet, or use its configuration and/or information in the relay header to direct the packet out a particular interface. The details of ordinary packet forwarding in devices that implement L2RA is beyond the scope of this document. Porfiri, et al. Expires 24 April 2024 [Page 15] Internet-Draft DHCPv4 RAIO Nesting October 2023 When processing a RELAYREPLY message, the L2RA MAY use information in the relay segment of the RELAYREPLY to determine on which network interface the RELAYREPLY should be forwarded. When processing any other message, the L2RA MAY use configuration information to direct the packet out a specific port or ports that have been marked as reaching DHCP servers. The L2RA MUST NOT forward any packet on the interface on which it was received, even if that interface is so marked. 4.6. Layer Three Relay Agents 4.6.1. Transmitting a decapsulated RELAYREPLY message When the decapsulated message is itself a RELAYREPLY message, the relay agent MUST forward the decapsulated message to the IP address specified in the 'aiaddr' field of the fixed-length header. If the relay segment of the packet that was decapsulated contains a Link Layer Address suboption, the relay agent MUST transmit the packet to that link layer address without attempting to use Address Resolution Protocol (ARP) to translate the address contained in 'aiaddr' to a layer two address. 4.6.2. Transmitting a decapsulated BOOTREPLY message When transmitting a decapsulated BOOTREPLY message, the relay agent transmits the message as specified in Bootstrap Protocol, Section 4 (Croft, B. and J. Gilmore, "Bootstrap Protocol," September 1985.) [RFC0951]. 4.6.3. Transmitting other messages When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay agent simply sends the message to the IP address or addresses configured as DHCP servers for that relay agent. 5. DHCP Server Behavior A DHCP server which receives a RELAYREPLY message MUST silently discard that message. 5.1. Receiving RELAYFORWARD messages DHCP servers that implement this specification MUST decapsulate RELAYFORWARD messages. Porfiri, et al. Expires 24 April 2024 [Page 16] Internet-Draft DHCPv4 RAIO Nesting October 2023 5.1.1. Decapsulation By design, this specification supports multiple layers of encapsulation. The DHCP server implementation therefore MUST decapsulate each layer and retain the information in that layer, organized so that the ordering of the encapsulation is available both during packet processing, and when constructing the reply. Aside from the necessity of handling an RAIO differently than an encapsulation when constructing a RELAYREPLY message, DHCP servers MUST NOT, by default, treat relay suboptions received in an RAIO any differently than relay suboptions received in an encapsulation. It is not the goal of this specification to define a particular implementation strategy or data structure for representing the encapsulation, so long as the ability to process the options and suboptions as required below is preserved. Implementations MAY provide means for addressing the contents of relay segments and of the inner encapsulation segment in any convenient form, as long as it conforms generally to the requirements of this document. 5.1.2. Processing of decapsulated suboptions This section specifies requirements for the processing of decapsulated relay suboptions in the default case, where no custom processing has been specified. This should not be construed to forbid implementations for providing mechanisms for customizing the processing of these suboptions. This document does not specify special handling for DHCP options. Only the inner encapsulation - the encapsulation of the original message sent from the client, which is done by the first encapsulating relay - can ever contain DHCP Options; hence, whatever normal mechanisms a DHCP server provides for processing these options should suffice. Some relay agent suboptions, such as the Relay Agent Subnet Selection suboption (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4," April 2003.) [RFC3527], are intended to be processed by DHCP servers. Others, like the Circuit ID and Remote ID (Patrick, M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046] suboptions, were not intended to be processed by the DHCP server, but are often used by the DHCP server for identification purposes. Porfiri, et al. Expires 24 April 2024 [Page 17] Internet-Draft DHCPv4 RAIO Nesting October 2023 In cases where more than one relay agent sends the same suboption, the DHCP server must either factor all such suboptions into its processing, or choose one such suboption and use that exclusively for processing. By default, DHCP servers MUST use the outermost suboption (the one added by the relay agent closest to the DHCP server) for every suboption that was sent by more than one relay agent. 5.1.3. Address allocation During normal processing, DHCP servers use a variety of data to determine where the DHCP client is in the network topology. These data are provided by relay agents. In the absence of any relay- agent-provided topology data, the DHCP server assumes that the client is connected to the link on which the message was received. One datum used by DHCP servers in locating the client is the value of the 'giaddr' field of the BOOTP header. This specification eliminates the use of giaddr; hence, it cannot be used in the address allocation decision. The functionality provided by giaddr is replaced in this specification by the 'aiaddr' field in the fixed-length relay header. 5.1.4. Default link selection algorithm DHCP servers MUST implement a default algorithm for determining the link to which the client is attached. This algorithm is to first search the client message for a subnet selection option (Waters, G., "The IPv4 Subnet Selection Option for DHCP," November 2000.) [RFC3011]. The server next searches for link-identifying data in each RELAYFORWARD encapsulation, starting from the inner most and ending at the outermost, until a RELAYFORWARD is found that identifies the client's location. A RELAYFORWARD encapsulation contains link-identifying data if the value of the 'aiaddr' field of the fixed-length header is not zero, or if the relay segment contains a Link Selection suboption (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub- option for the Relay Agent Information Option for DHCPv4," April 2003.) [RFC3527]. Porfiri, et al. Expires 24 April 2024 [Page 18] Internet-Draft DHCPv4 RAIO Nesting October 2023 If a Link Selection suboption is present in the innermost RELAYFORWARD message containing link-identifying data, the DHCP server MUST use the contents of that option to identify the link to which the client is connected. Otherwise, if a Subnet Selection option was found in the client message, the DHCP server MUST use the contents of that option to identify the link to which the client is connected. Otherwise, the DHCP server MUST use the contents of the 'aiaddr' field in the RELAYFORWARD encapsulation that was identified as being the innermost RELAYFORWARD containing link-identifying data. 5.1.5. Other link selection algorithms DHCP servers implementing this specification MAY implement link selection algorithms other than the one described in the preceding section. DHCP servers MUST NOT use any link selection algorithm other than the one described in the preceding section unless specially configured to do so. 5.2. Responding to RELAYFORWARD messages Once the DHCP server has processed the encapsulated message from the DHCP client and constructed a response to the DHCP client, it constructs a RELAYREPLY message and sends it to the next hop on the way to the client. 5.2.1. Constructing a RELAYREPLY encapsulation The server MUST encapsulate any response to a client message contained in one or more RELAYFORWARD encapsulations in a set of corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested in the same way that the corresponding RELAYFORWARD was nested, so that the innermost RELAYREPLY corresponds to the innermost RELAYFORWARD, and the outermost RELAYREPLY corresponds to the outermost RELAYFORWARD. 5.2.1.1. Constructing the relay segments The server MUST copy every suboption that appeared in the relay segment of the RELAYFORWARD encapsulation into corresponding outgoing RELAYREPLY encapsulation's relay segment. The server SHOULD NOT preserve the order of options from the incoming relay segment to the outgoing relay segment. Porfiri, et al. Expires 24 April 2024 [Page 19] Internet-Draft DHCPv4 RAIO Nesting October 2023 If the message encapsulated by a particular RELAYREPLY encapsulation is not a RELAYREPLY, or if the message encapsulated by that RELAYREPLY is a RELAYREPLY, but the 'aiaddr' field of the fixed- length header of the inner RELAYREPLY has a value of zero, the DHCP server MUST include a Layer Two Address suboption in the relay segment. The DHCP server MUST set the 'htype' field of the Layer Two Address suboption to the value of 'htype' in the client message. The DHCP server MUST set the 'chaddr' field in the Layer Two Address suboption to the value of the 'chaddr' field in the client message. 5.2.1.2. Constructing the fixed-length header The server MUST set the values of 'ep' and 'padlen' in the fixed- length header to zero. The server MUST set the value of 'caplen' to the length of the message encapsulated in the RELAYREPLY encapsulation being constructed. The server MUST set the value of 'rslen' to the length of the relay segment of the RELAYREPLY encapsulation being constructed. If the message encapsulated in the RELAYREPLY being constructed is a RELAYREPLY, and the 'aiaddr' field of the RELAYFORWARD encapsulation corresponding to the inner RELAYREPLY is not zero, the DHCP server MUST copy the value from that 'aiaddr' field to the 'aiaddr' field of the RELAYREPLY being constructed. Otherwise, if the BROADCAST bit in the 'flags' field of the inner message is set to 1, or 'ciaddr' is zero and 'yiaddr' is also zero, the DHCP server MUST set the value of 'aiaddr' to 255.255.255.255. If 'ciaddr' is not zero, the DHCP server must copy that value to 'aiaddr'. If 'ciaddr' is zero and 'yiaddr' is not, the DHCP server MUST copy the value of 'yiaddr' to 'aiaddr'. 5.2.2. Transmission of RELAYREPLY messages If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation to which the RELAYREPLY is a response is nonzero, the DHCP server MUST transmit the RELAYREPLY to that IP address. Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST bit in the 'flags' field is set to 1, or the DHCP server implementation is not able to perform the ARP-cache preloading trick described in Bootstrap Protocol, Section 4 (Croft, B. and J. Gilmore, "Bootstrap Protocol," September 1985.) [RFC0951], the DHCP server MUST broadcast the RELAYREPLY message to the 255.255.255.255 broadcast address. Porfiri, et al. Expires 24 April 2024 [Page 20] Internet-Draft DHCPv4 RAIO Nesting October 2023 Otherwise, the DHCP server MUST use the value of 'ciaddr', if nonzero, or 'yiaddr', otherwise, as the destination address for the message, and MUST preload its ARP cache (or otherwise arrange to transmit the message without using ARP) to the layer two address provided by the client in 'htype' and 'chaddr' and 'hlen'. 5.3. Responding to messages other than RELAYFORWARD When a DHCP server constructs a response to a DHCP client message that did not arrive encapsulated in a RELAYFORWARD message, the DHCP server MUST NOT encapsulate the response in a RELAYREPLY message. DHCP server implementors should be careful that their servers do not respond to an incoming RAIO from a non-conforming relay agent with a RELAYREPLY message. 6. DHCP Client Behavior A DHCP client that receives either a RELAYFORWARD message or a RELAYREPLY message MUST silently discard that message. 7. Layer 2 Relay Agent Information In some network configurations, there is a need for Layer 2 devices to append the Relay Agent Information option as they are closer to the end hosts. These Layer 2 devices are typically operating only as bridges for the network and may not have an IPv4 address on the network in question. Lacking a valid IPv4 source address, they cannot relay packets directly to a DHCP server located on another network. These Layer 2 devices append the Relay Agent Information option and broadcast the DHCP message. A Layer 3 Relay Agent relays it to the DHCP server. This section provides information about where a Layer 2 Relay Agent fits in and how it is used. This section also looks at various network scenarios with Layer 2 Relay Agents and discusses various issues caused by the introduction of Layer 2 Relay Agents. 7.1. Need of Layer 2 Relay Agent A Layer 2 device intercepts DHCP messages for the following reasons: 1. In some network deployments like xDSL, the subscriber aggregation devices (also known as Access Concentrator or a DSLAM in case of DSL) are configured to act as bridges. As these devices are closest to the subscriber, they are in the best position to provide a unique Relay Agent Information option to enforce policies in the DHCP server. Porfiri, et al. Expires 24 April 2024 [Page 21] Internet-Draft DHCPv4 RAIO Nesting October 2023 2. In some network deployments, a Layer 2 device can append Relay Agent Information in DHCP messages so that it can use this information to forward the DHCP Replies to the specific port on which the request was received. 3. In some networks, the Layer 2 Switch which is closest to the end users, snoops the DHCP messages. These switches extract DHCP Lease Information and use this information to install packet filters. This helps in preventing Layer 2 and Layer 3 spoofing attempts by the subscribers. A point to note here is that in cases where switches maintain the Lease Information, they have to intercept unicast DHCP messages as well to keep this information up to date. 4. In some network deployments like Fronthaul in mobile networks, the aggregation of Radio Unit devices (also known as Switched Fronthaul) hides the relationship between the Radio Unit themselves and the physical ports where they are connected (see Section 7.2.4). In order to properly setup the Switched Fronthaul network aggregation, the DHCP server must know the network topology. This is accomplished by implementing in each and all the Layer 2 switches a L2RA functionality. 7.2. Layer 2 Relay Agent in various network scenarios This section describes the various network scenarios where a Layer 2 Relay Agent fits in. It also describes how it handles different DHCP messages. 7.2.1. DHCP server and client on same subnet In certain network configurations, a DHCP server may reside on the same subnet as the DHCP clients. A Layer 2 aggregation device resides between the DHCP clients and DHCP server. The following points describe how this Layer 2 device handles various DHCP messages if it acts as a Layer 2 Relay Agent. Figure 4 shows a typical network setup. Porfiri, et al. Expires 24 April 2024 [Page 22] Internet-Draft DHCPv4 RAIO Nesting October 2023 +--------+ | End | +--------+ | | Host#1 +-----------| | | +-----------+ +--------+ | Layer +-----| | | | 2 | +-----| DHCP | +--------+ | device | | | Server#1 | | End +-----------| #1 | | +-----------+ | Host#2 | +--------+ | +--------+ | | +--------+ | | End | +--------+ | | Host#3 +-----------| | | +--------+ | Layer +-----| | 2 | | +--------+ | device | | | End +-----------| #2 | | Host#n | +--------+ +--------+ Figure 4: DHCP server and client on same subnet 7.2.1.1. Client-server interaction The following summary of protocol message exchanges between clients and DHCP servers describes how they are handled in a Layer 2 Relay Agent. 1. The client (End Host #1) broadcasts a DHCPDISCOVER message on its local physical subnet. Layer 2 Relay Agent #1 intercepts this message, appends the Relay Agent Information option and broadcasts it to all the ports except the one on which it was received. The Relay Agent Information option could be created as suggested in [RFC3046]. The Layer 2 Relay Agent does not set the 'giaddr' field. 2. Layer 2 device #2 would also receive this DHCPDISCOVER message from Layer 2 device #1. If it is configured as Layer 2 Relay Agent, it intercepts this message but does not append another Relay Agent Information option to the message. It may discard this message if it is coming from an untrusted entity. Otherwise, it will broadcast this on all the ports except the one on which the message was received. 3. The DHCP server responds with a DHCPOFFER message after applying its local policies. It echoes back the Relay Agent Information option in the DHCPOFFER message. The DHCP server can either unicast the reply to the MAC address of End Host #1 or broadcast Porfiri, et al. Expires 24 April 2024 [Page 23] Internet-Draft DHCPv4 RAIO Nesting October 2023 the reply. If the reply is broadcast, the Layer 2 Relay Agent intercepts this message and removes the Relay Agent Information option. It identifies the outgoing port using the Relay Agent Information option and forwards the message to the identified interface. A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages. In such a case, the Layer 2 Relay Agent intercepts unicast DHCP messages and handles them similar to broadcast messages. 4. The same DHCPOFFER message will be received by Layer 2 Device #2. If it is configured as Layer 2 Relay Agent, it broadcasts this message normally without removing the Relay Agent option since it had not added the same. A Layer 2 Relay Agent uses the Relay Agent Information option to find out if it had appended it to the request message. 5. The client receives this DHCPOFFER message and it broadcasts a DHCPREQUEST message. Layer 2 Relay Agent #1 handles this message similar to how it handles a DHCPDISCOVER message. 6. The server receives the DHCPREQUEST message from the client and responds with a DHCPACK/DHCPNAK message. If DHCP server broadcasts the DHCPACK message, Layer 2 Relay Agent processes it similar to a DHCPOFFER message. If DHCP server unicasts the DHCPACK message to the client, Layer 2 Relay agent intercepts the same and processes the message similar to the broadcasted DHCPACK message. 7. The Layer 2 Relay Agent processes a DHCPNAK messages similar to a DHCPACK message. 8. The Layer 2 Relay Agent processes a DHCPDECLINE message similar to a DHCPDISCOVER message. 9. The DHCP client can unicast some of the DHCP messages. The Layer 2 Relay Agent may or may not intercept these messages based on internal configuration. If Layer 2 Relay Agents intercept these messages, they append a Relay Agent Information option and forward the message towards the DHCP server. They also intercept the reply messages and remove the Relay Agent Information option before forwarding them. Porfiri, et al. Expires 24 April 2024 [Page 24] Internet-Draft DHCPv4 RAIO Nesting October 2023 7.2.1.2. Issues due to introduction of Layer 2 Relay Agent 1. A DHCP server should be able to handle a DHCP message that contains the Relay Agent Information option without 'giaddr' field set in the message. Some existing DHCP server implementations do not echo back the Relay Agent Information option if giaddr is not set. This may lead to issues at Layer 2 Relay Agents as they will not be able to identify the outgoing port correctly and would broadcast it to all ports. Some Layer 2 Relay Agents discard the reply messages if they do not find a Relay Agent Information option in a DHCP reply. 2. There is a case when the DHCP client receives a unicast reply message like DHCPACK with a Relay Agent Information option. This can happen only when the DHCP server unicasts the DHCPACK message and the Layer 2 Relay Agent is not configured to intercept unicast messages. Most of the Layer 2 Relay Agents, that are deployed today, are configured to intercept the unicast DHCP messages and hence this behaviour may not be seen in the real world deployments. 3. A DHCP server should be able to handle a unicast DHCP message containing a Relay Agent Information option. Some existing DHCP server implementations do not echo back the Relay Agent Information option in responses to unicast messages. 7.2.2. Multiple DHCP server and Client on same subnet In certain network scenarios, there could be multiple DHCP servers on the same subnet. Figure 5 shows a typical network setup. Porfiri, et al. Expires 24 April 2024 [Page 25] Internet-Draft DHCPv4 RAIO Nesting October 2023 +--------+ | End | +--------+ | | Host#1 +-----------| | | +-----------+ +--------+ | Layer +-----| | | | 2 | +-----| DHCP | +--------+ | device | | | Server#1 | | End +-----------| #1 | | +-----------+ | Host#2 | +--------+ | +--------+ | | +-----------+ +--------+ | | DHCP | | End | +--------+ |-----| Server #2 | | Host#3 +-----------| | | | | +--------+ | Layer +-----| +-----------+ | 2 | | +--------+ | device | | End +-----------| #2 | | Host#n | +--------+ +--------+ Figure 5: Multiple DHCP server and client on same subnet 7.2.2.1. Client-server interaction The message exchanges are the same as explained in Section 7.2.1.1 However, due to the introduction of multiple DHCP servers the below additional message exchange may happen. 1. When Host #1 sends DHCPDISCOVER, it will be received by both DHCP Servers connected to Layer 2 Relay Agent #1 and both servers will respond with a DHCPOFFER. So instead of one DHCPOFFER message, the Layer 2 Relay Agent would receive two messages. The processing of DHCP messages in the Layer 2 Relay Agents remains the same. 7.2.2.2. Issues due to introduction of Layer 2 Relay Agent 1. Layer 2 relay agents which maintain persistent state, such as updating filters or client registration, must be prepared to handle potentially conflicting responses from different DHCP Servers. Some Layer 2 relay agents may use "the most recent DHCP packet" to update this persistent state but this may not necessarily reflect the actual state of the client. The above is possible when two DHCP servers acknowledge the request of a DHCP client with the same address but different lease times. In this case, if the relay agent selects the server reply with the shorter lease time, it would expire its state possibly before the client even has a chance to renew it. Therefore, Layer 2 relay Porfiri, et al. Expires 24 April 2024 [Page 26] Internet-Draft DHCPv4 RAIO Nesting October 2023 agents SHOULD select the longest lease time of two conflicting but similar replies, by discarding replies that shorten the lease time. 2. Other issues are the same as described in section Section 7.2.1.2 7.2.3. DHCP server on another subnet with one Layer 3 Relay Agent In certain network scenarios, there could be a Layer 3 Relay Agent which relays the DHCP messages from one subnet to a DHCP server on another subnet and vice versa. In typical deployments, the Access Concentrator acts as Layer 2 Relay Agent and the IP edge device (BRAS or IP Services Switch) acts as Layer 3 Relay Agent. +--------+ | End | +--------+ | | | Host#1 +--------| | | +-----------+ | +--------+ | Layer +-----| | | | | 2 | +--| Layer 3 |----| +--------+ | device | | | Relay | | | End +--------| #1 | | | Agent #1 | | | Host#2 | +--------+ | +-----------+ | +---------+ +--------+ | | | | | +--| DHCP | +--------+ | | | Server | | End | +--------+ | | | #1 | | Host#3 +--------| | | +---------+ +--------+ | Layer +-----| | 2 | | +--------+ | device | | | End +--------| #2 + | Host#n | +--------+ +--------+ Figure 6: DHCP server on a different subnet with a Layer 3 Relay Agent 7.2.3.1. Client-server interaction As far as DHCP message processing is concerned, the presence of Layer 3 Relay Agents is transparent to Layer 2 Relay Agents. So all the messages are handled in the same way as defined in section Section 7.2.1.1 for the Layer 2 Relay Agent. The Layer 3 Relay Agents are configured to trust/untrust an entity based on specific criteria (For example : VLAN/interface on which the message was received). If the DHCP message coming from the client has a relay agent option present, the Layer 3 Relay Agent checks if Porfiri, et al. Expires 24 April 2024 [Page 27] Internet-Draft DHCPv4 RAIO Nesting October 2023 it is coming in on a trusted interface. If it is coming from a trusted interface, it will set the 'giaddr' field to one of the local interface addresses and unicasts it to the configured server(s). If the message is coming from an untrusted interface, the Layer 3 Relay Agent discards the message. Typical message processing in this scenario is given below. 1. When the client sends a DHCPDISCOVER message, the Layer 2 Relay Agent forwards it as described in section Section 7.2.1.1. The Layer 3 Relay Agent receives this message and finds that it contains a Relay Agent Information option. It verifies whether the message is from a trusted entity or not. If it is from a trusted entity, the Layer 2 Relay Agent populates the 'giaddr' field as it deems appropriate and relays the message to the DHCP server. 2. The DHCP Server processes the message in the same way as described in section Section 7.2.1 and unicasts the DHCPOFFER to the Layer 3 Relay Agent on the address specified in the 'giaddr' field. 3. The Layer 3 Relay Agent processes the DHCPOFFER and identifies the outgoing interface. It resets the 'giaddr' field and broadcasts the message on the identified outgoing interface. 4. The client receives the DHCPOFFER and generates a DHCPREQUEST message. The Layer 2 Relay Agent processes it as described in section Section 7.2.1.1. The Layer 3 Relay Agent receives the DHCPREQUEST message and processes it similar to the DHCPDISCOVER message described in step #1. 5. The DHCP Server processes the DHCPREQUEST and unicasts the DHCP ACK message to the layer 3 Relay Agent if the 'broadcast' flag is set, or directly to the client if the 'broadcast' flag is not set. If the Layer 3 Relay Agent receives this message, it processes it similar to the DHCPOFFER as described in step #3. 6. In the case of unicast messages (For example: DHCPREQUEST in case of DHCPRENEW), a Layer 3 Relay Agent may or may not intercept the message. If it intercepts a unicast DHCP request message, it populates the 'giaddr' field and relays the message to the DHCP server. When the DHCP server sends a reply for this request message, it resets the 'giaddr' field, identifies the outgoing interface, and forwards the reply on the identified interface. Porfiri, et al. Expires 24 April 2024 [Page 28] Internet-Draft DHCPv4 RAIO Nesting October 2023 7.2.3.2. Issues due to introduction of Layer 2 Relay Agent Though the processing of DHCP messages remains the same in Layer 2 Relay Agents, we see some more issues when a Layer 3 Relay Agent is present to relay the DHCP messages to the DHCP server. 1. When a Layer 2 Relay Agent is configured to intercept unicast messages as well, it appends a Relay Agent Information option before forwarding the request message. A Layer 3 Relay Agent may not intercept these unicast messages. Due to this, a DHCP server may not echo back the Relay Agent Information option because the 'giaddr' field is not populated. 2. Existing Layer 3 Relay Agents populate the 'giaddr' field with the IP address of the interface on which the request was received. This helps the Layer 3 Relay Agent to identify the outgoing interface for the DHCP replies. In some cases, a Layer 3 Relay Agent may use unnumbered interfaces. In this case, it has to use a system wide IP address to populate the 'giaddr' field. Due to this, it becomes difficult to identify the correct outgoing interface for the messages received from the DHCP server. In these cases, some existing Layer 3 Relay Agent implementations maintain an internal state for each DHCP message and use this state to identify the outgoing interface. 3. The DHCP server uses certain parameters to differentiate the RENEW and REBIND state of a client. A DHCPREQUEST without 'giaddr' and the Relay Agent Information option is treated as RENEW request while DHCPREQUEST with 'giaddr' and Relay Agent Information option is treated as REBIND request. In a network configuration where both Layer 2 Relay Agent and Layer 3 Relay Agent are configured to intercept the unicast DHCP messages, the DHCP server will receive RENEW request with Relay Agent Information option and 'giaddr' field set. Since REBIND request will also have Relay Agent Information option and 'giaddr' field set, it becomes difficult for the DHCP server to differentiate between RENEW and REBIND requests. 7.2.4. DHCP server on another subnet with multiple Layer 3 Relay Agents In certain network scenarios, there could be more Layer 3 Relay Agents which relays the DHCP messages from one subnet to a DHCP server on another subnet and vice versa. In typical deployments, the Fronthaul Switch acts as Layer 2 Relay Agent and the Baseband Unit or a Router acts as Layer 3 Relay Agent. Porfiri, et al. Expires 24 April 2024 [Page 29] Internet-Draft DHCPv4 RAIO Nesting October 2023 +--------+ | End | +--------+ | | | Host#1 +--------| | | +-----------+ | +--------+ | Layer +-----| | | | | 2 | +--| Layer 3 |----| +--------+ | device | | | Relay | | | End +--------| #1 | | | Agent #1 | | | Host#2 | +--------+ | +-----------+ | +---------+ +--------+ | | | | | +--| DHCP | +--------+ | | | Server | | End | +--------+ | | | #1 | | Host#3 +--------| | | +-----------+ | +---------+ +--------+ | Layer +-----| | | | | 2 | +--| Layer 3 |----| +--------+ | device | | | Relay | | | End +--------| #2 + | | Agent #2 | | | Host#n | +--------+ | +-----------+ +--------+ | Figure 7: DHCP server on a different subnet with more Layer 3 Relay Agent 7.2.4.1. Client-server interaction Same as described in Section 7.2.3.1 7.2.4.2. Issues due to introduction of Layer 2 Relay Agent Same as described in Section 7.2.3.2 In a scenario where multiple Layer 3 relay agents exist the DHCP Server must consider the possibility that mutple requests for the same End Host will arrive via different Layer 3 Agents and take a decision to which one is to be used. It is expected that the DHCP Server can cope with that situation. 8. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Porfiri, et al. Expires 24 April 2024 [Page 30] Internet-Draft DHCPv4 RAIO Nesting October 2023 9. Security Considerations DHCP Relay Information Option (Patrick, M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046] limits relay agent information to a single relay agent, and provides some minimal anti- spoofing. By supporting relay agent chaining, it is now possible for a relay agent downstream of the trusted portion of a provider network to communicate relay agent information options to a DHCP server. This specification defines a much more robust spoofing rejection mechanism, by allowing the administrator to configure the relay to discard RELAYFORWARD messages originating from outside of the trusted portion of the network. Administrators of networks that rely on this trusted/untrusted configuration are encouraged to configure edge relays to discard RELAYFORWARD messages. In networks where trusted relay agents may be separated from the DHCP server by transit networks that are not trusted, it is possible to modify the message in transit. This possibility exists with normal DHCP relays as well. Administrators of such networks should consider using relay agent authentication (Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option," March 2005.) [RFC4030] to prevent modification of relay agent communications in transit. 10. IANA Considerations We request that IANA assign one new suboption code from the registry of DHCP Agent Sub-Option Codes maintained in http://www.iana.org/assignments/bootp-dhcp-parameters. This suboption code will be assigned to the Layer Two Address Suboption. 11. References 11.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, DOI 10.17487/RFC0951, September 1985, . [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, October 1993, . Porfiri, et al. Expires 24 April 2024 [Page 31] Internet-Draft DHCPv4 RAIO Nesting October 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, DOI 10.17487/RFC3011, November 2000, . [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, . [RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, . [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 2003, . [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, DOI 10.17487/RFC4030, March 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC6925] Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay Agent Identifier Sub-Option", RFC 6925, DOI 10.17487/RFC6925, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References Porfiri, et al. Expires 24 April 2024 [Page 32] Internet-Draft DHCPv4 RAIO Nesting October 2023 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] Lemon, T., Deng, H., and L. Huang, "Relay Agent Encapsulation for DHCPv4", Work in Progress, Internet- Draft, draft-ietf-dhc-dhcpv4-relay-encapsulation-01, 11 July 2011, . [I-D.ietf-dhc-l2ra] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", Work in Progress, Internet-Draft, draft- ietf-dhc-l2ra-06, 25 January 2012, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Acknowledgments The authors would like to acknowledge that much of the material in this document comes directly from [I-D.ietf-dhc-dhcpv4-relay-encapsulation] by Ted Lemon, Hui Deng, and Lu Huang, and [I-D.ietf-dhc-l2ra] by Bharat Joshi and Pavan Kurapati. These documents were the original ideas, which the current authors have only adopted and fine-tuned. The authors would also like to acknowledge interesting discussions in this problem space with Sarah Gannon, Ines Ramadza, Siddharth Sharma, and Bernie Volz. Authors' Addresses Claudio Porfiri Ericsson Email: claudio.porfiri@ericsson.com Jari Arkko Ericsson Email: jari.arkko@ericsson.com Mirja Kühlewind Ericsson Email: mirja.kuhlewind@ericsson.com Porfiri, et al. Expires 24 April 2024 [Page 33]