]> Ericsson

claudio.porfiri@ericsson.com

Cisco

suresh.krishnan@gmail.com

Ericsson

jari.arkko@ericsson.com

Ericsson

mirja.kuhlewind@ericsson.com

Internet Dynamic Host Configuration dhcp This document describes a general mechanism for networks with legacy IPv4-only clients to use DHCPv4-over-DHCPv6 (DHCP 4o6) for discovering information about network Topology. To address this scenario, this document specifies an amendment to RFC7341 that allows a new 4o6 Relay Agent (4o6RA) to perform the 4o6 DHCP en- and decapsulation instead of the client. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction In some networks the configuration of a client host may depend on the Topology. However, when a new client host gets connected to the network, it may be unaware of the Topology and respectively how it has to be configured. In IPv6 networks, Topology discover can be realized using DHCPv6 Relay Agents that insert relay agent options in DHCPv6 message exchanges in order to identify the client-facing interfaces, e.g. using the Serial Number or other hardcoded information. Then, a reference host that is responsible for providing configuration to the client host can obtain Topology information from the DHCP server. In DHCPv6, a Relay Agent can encapsulate the DHCP message from the client in a new DHCP message along with any options it chooses to add to provide information to the DHCP server. This mode of operation also supports networks that include a hierarchy of switches. However, if the client only supports IPv4 and cannot easily be replaced or updated, this approach does not work, as DHCPv4 support for relays is much more limited. For instance, there is no support in DHCPv4 for hierarchical modes of deployment, as the specifications prohibit chaining of Relay Agent Information Options (RAIOs) . A typical example where Topology Discovery is needed for host configuration is the switched fronthaul in the Radio Access Network (see ). However, the specified approach in this document is not limited to that example. This document specifies how to provide Topology Discover using Relay Agent functionality for legacy IPv4 clients using DHCPv4-over-DHCPv6 (DHCP 4o6) . No new protocols or extensions are needed, instead this document specifies an amendment to that allows a Relay Agent to perform the 4o6 DHCP en- and decapsultion instead of the client in order to address the specific scenario that is detailed in .

Conventions and Definitions The following terms and acronyms are used in this document:

• 4o6 The architecture, the procedures and the protocols described in the DHCPv4-over-DHCPv6 document .
• 4o6RA The 4o6 Relay Agent is the part of an LDRA implementing 4o6
• DHCP Relay Agent This is a concept in all of the protocols, BOOTP , DHCPv4 , and DHCPv6 , although the details differ between the protocols.
• Lightweight DHCPv6 Relay Agent (LDRA) This is an extension of the original DHCPv6 Relay Agent mechanism, to support also Layer 2 devices performing a Relay Agent function .
• Relay Agent Information Option (RAIO) This is a DHCP option defined in . Also commonly referred to as "Option 82". RAIO options were later extended to be able to carry suboptions .

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 when, and only when, they appear in all capitals, as shown here.

Example Use Case: Switched Fronthaul In Radio Access Networks (RANs) the Fronthaul is the network segment that connects Radio Units, the distributed radio elements in a mobile network, to other network elements. The aggregation of Radio Unit devices (also known as Switched Fronthaul) hides the relationship between the Radio Units themselves and the physical ports where they are connected. The Radio Units are the client hosts in the switched Fronthaul network and need to be configured based on their Topology.

Layer 2 Switched Fronthaul Example

shows multiple Radio Units that are connected to one Baseband Unit by means of a Layer 2 switched network. The Baseband Unit is the central processing unit that handles baseband information. A Baseband Unit is often placed rather centrally, while the Radio Units need to be distributed to be co-located with or near the antennas. Traffic between Radio Units and Bandband Units is both IP-based and Layer-2-based and may pass a hierarchy of L2 switches. In order to properly address the Radio Unit, the Baseband Unit needs to associate the Radio Unit's MAC address to the L2 switch and respective port where the Radio Unit is connected. To realize this device configuration in the Switched Fronthaul network, DHCP can be used to discover the network Topology.

Existing DHCP-based Solutions for Topology Discovery

IPv6 Clients using DHCPv6 If the network is fully IPv6 enabled, DHCPv6 can be used for Topology Discovery. This solution exploits DHCPv6 Relay Agent support in the server, whilst Lightweight DHCPv6 Relay Agents (LDRA) are implemented in the L2 switches to inform DHCPv6 server about the L2 Topology.

Clients with Dual Connectivity and 4o6 DHCP support When the client needs an IPv4 address but is dual connected and can support DHCPv4-over-DHCPv6 , DHCPv6 with a DHCPv4-over-DHCPv6 compliant DHCP server can be used for Topology Discovery whereas DHCP is used still for IP address assignment. An example network with 4o6 compliant clients can be sketched as follows:

Layer 2 Topology discover with 4o6

In the client supports by implementing the 4o6 encapsulation whereas the intermediate nodes implement LDRA or L3RA and finally the DHCP server is 4o6 DHCP capable . Still, does not provide a solution for legacy IPv4 clients that respectively do not support 4o6 encapsulation.

Layer 2 Topogoy Discovery using 4o6 DHCP with legacy IPv4 clients This document extends to enable a deployment scenario where the 4o6 encapsulation is implemented at the Relay Agent instead of the DHCP client. This makes it possible to enable Topology Discovery for legacy IPv4 DHCP clients through a 4o6-DHCP-enabled network.

Layer 2 architecture with 4o6 and legacy client

The new scenario, not described in , is shown in . In such a scenario, the 4o6 encapsulation is implemented in the Relay Agent deployed in the edge L2 switch, or in general in the edge device providing connectivity to the legacy client. In this case it is up to the Relay Agent to provide the full 4o6 DHCP set of functionality whereas the legacy client is not aware of being served via a 4o6 DHCP service. This new 4o6 Relay Agent (4o6RA), as specified in this document, exchanges DHCP messages between clients and servers using the message formats established in . To maintain interoperability with existing DHCP relays and servers, the message format is unchanged from . The 4o6RA implements the same message types as a normal DHCPv6 Relay Agent . They are: - Relay-Forward Messages - Relay-Reply Messages In this specification, the 4o6RA creates the DHCPV4-QUERY Message and encapsulates the DHCP request message received from the legacy DHCPv4 client. When DHCPV4-RESPONSE Message is received by the 4o6 Relay Agent, it looks for the DHCPv4 Message option within this message. If this option is not found, the DHCPv4-response message MUST be discarded. If the DHCPv4 Message option is present, the 4o6RA MUST extract the DHCPv4 message and forward the encapsulated DHCPv4-response to the legacy DHCPv4 client. An Layer 2 Relay Agent receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages will handle them as specified in Section 6 of .

Security Considerations This documents applies 4o6 DHCP in a scenario where legacy IPv4 clients are connected to 4o6 DHCP Relay Agent that performs the en- and decapsulation. This document does not change anything else in the 4o6 DHCP speacification and therefore the security consideration of still apply. The legacy IPv4 client is not aware of this mechanism, however, even when 4o6 DHCP is used, the client does not have any control about the information provided by the Relay agent. As such this change does not provide any additional secruity concerns.

IANA Considerations This document has no IANA actions.

References Normative References Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK] This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK] This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends. IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK] This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

Acknowledgments The authors would also like to acknowledge interesting discussions in this problem space with Sarah Gannon, Ines Ramadza and Siddharth Sharma.