]> Ericsson

claudio.porfiri@ericsson.com

Cisco

suresh.krishnan@gmail.com

Ericsson

jari.arkko@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com

Internet Dynamic Host Configuration dhcp This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4-over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in contexts where it is not possible at 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 describes a transport mechanism for carrying DHCPv4 messages using DHCPv6 for the dynamic provisioning of IPv4 addresses and other DHCPv4 specific configuration parameters across IPv6-only networks. The deployment of requires support in DHCP clients and at the DHCPv6 server. However, if a client is embedded in a host that only supports IPv4 and cannot easily be replaced or updated due to a number of technical or business reasons, this approach does not work. Similarly, the specifications for DHCPv6 Relay Agents such as LDRA or L3RA do not foresee the possibility to handle legacy DHCPv4, other than implementing DHCP 4o6 in the client. This document specifies an -based solution that can be implemented in intermediate nodes such as switches or routers, without putting any requirements on clients. No new protocols or extensions are needed, instead this document specifies an amendment to that allows a Relay Agent to perform the DHCP 4o6 encapsulation and decapsultion instead of the client.

Applicability Scope The mechanisms described in this document apply to the configuration phase of the host, specifically when a DHCP server for IPv4 is not reacheable directly from the host, the host needs to receive an IPv4 address and there's a DHCPv6 server than can provide IPv4 addresses by means of the mechanisms described in and the host doesn't implement a DHCP client conform to itself.

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

• DHCP: In this document when not otherwise specified it referres to DHCPv4 and/or DHCPv6
• DHCPv4: DHCP as defined in
• DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures and the protocols described in the DHCPv4-over-DHCPv6 document .
• 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 (or LDRA): This is an extension of the original DHCPv6 Relay Agent, to support also Layer 2 devices performing a Relay Agent function .
• DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent that implements the 4o6 specified in this document.

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.

DHCPv4 over DHCPv6 Relay Agent (4o6RA) This document assumes a network, where IPv4-only hosts are connected to a network that supports IPv6 and limited IPv4 services. To address such a network setup, this document extends DHCPv6 Relay Agents with DHCPv4-over-DHCPv6, as shown in .

Architecture Example with Legacy DHCP Client

This document specifies the encapsulation and decapsulation described in to be performed in the Relay Agent whereas the DHCPv4 client does not require any change. In this case it is up to the Relay Agent to provide the full DHCP 4o6 support whereas a legacy client is not aware of being served via a DHCP 4o6 service. All prerequisites and configuration that apply to the DHCP client in shall be applied to 4o6RA instead. specifies that before applying for an IPv4 address via a DHCPv4-query message, the client must identify a suitable network interface for the address. In the case described in this document where the client functionality described in is replaced by 4o6RA, it is 4o6RA that shall also identify a suitable interface, that can be a network interface or another Relay Agent. To maintain interoperability with existing DHCPv6 relays and servers, the message format is unchanged from . The 4o6RA implements the same message types as a normal DHCPv6 Relay Agent . 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 requesting DHCPv4 client. Layer 2 Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages are expected to handle them as specified in . DHCPv6 servers must be compliant with 4o6 according to . No additional requirements on DHCPv6 servers are set by this specification.

Intermediate relays Intermediate relays shall behave according to section 10 of .

4o6RA and Topology Discovery In some networks the configuration of a host may depend on the topology. However, when the new host attaches to a network, it may be unaware of the topology and respectively how it has to be configured. DHCPv4 and DHCPv6 specifications describe how addresses can be allocated to clients based on network topology information provided by a DHCP relay, typically. Address/prefix allocation decisions are integral to the allocation of addresses and prefixes in DHCP. The argument is described in details in , here we want to guarantee that 4o6RA does not break any legacy capability when related to the use of topology. The topology discovery as described in differs between IPv4 and IPv6 because for IPv4 it is only the first Relay Agent that can set the giaddr field (section 3.1 of ). Thus in a generic network involving more than one Relay Agent only part of the topology is transported via DHCPv4. When in IPv6 context and using DHCPv6, all Relay Agents can send link-address and Interface-ID options, that provide information about the complete path between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server. When in a L2 network, Lightway DHCPv6 Relay Agents can be used. Then, topology information for the given IP address can be obtained from the DHCPv6 server and used for configuration or other purposes. The adoption of at the client permits to use the DHCPv6 mechanisms for topology discovery even in case of DHCPv4. as using DHCPv6 encapsulation the DHCPv6 Relay Agent knows the interface where the encapsulated DHCP request is received. Moving 4o6 in the intermediate node rather than at the client breaks the topology propagation as 4o6RA-only does not provide any interface information in the encapsulated message.

Topology broken path

As shown in , the introduction of 4o6 at the edge of the IPv6 network hides the L2 network from the DHCPv6 RA. In order to preserve the topology information, it is recommended that the implementation of 4o6RA is combined with the implementation of LDRA and that the implementation has a mechanism for LDRA to get interface information that can be used for the Interface-ID option, as specified in . The internal mechanisms to exchange interface information, their format and whether the interface information contains an indication that a 4o6RA is involved are out of the scope for this document.

Topology path preserved with LDRA

The assumed architecture is shown in where the whole The Relay Agent is built up with cooperating 4o6RA and LDRA, and an internal interface to propagate topology information from 4o6RA to LDRA. In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 server, it might be enough to only use 4o6RA, as shown in .

Topology path preserved 4o6 Relay Agent in DHCP server

Deployment Considerations As clients are not aware of the presence of 4o6RA, the network deployment needs to ensure that all DHCPv4 broadcast and unicast messages from clients are steered to a 4o6RA. This can, e.g., be achieved by placing the 4o6RA in a central position that can observe all traffic from the clients or use of address translation with the 4o6RA address for unicast messages.

Security Considerations This documents specifies the applicability of 4o6 DHCP in a scenario where legacy IPv4 clients are connected to 4o6 DHCP Relay Agents that performs the encapsulation and decapsulation. This document does not change anything else in the 4o6 DHCP specification and therefore the security consideration of still apply. This mechanism differs from as the DHCP client sends and receives DHCPv4 messages, whereas in it only sends DHCPv6 messages. This makes it possible that DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA. While this can cause erroneous state in both clients and servers and potentially even lead to misconfigurations that impact reachability, this is not seen as a security concern rather than a deployment error. Further, even though it may be used for attacks from within the network, this is not new and it is not introduced because of this specification. More generally, legacy IPv4 clients are not aware of this mechanism, however, even when DHCP 4o6 is used, the client does not have any control about the information provided by the Relay agent. As such this change does not raise any additional security concerns.

IANA Considerations This document has no IANA actions.

References Normative References 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] 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. DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation. 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] 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] 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]

Example Use Case: Topology Discovery for IPv4-only Radio Unit in the RAN Switched Fronthaul The Radio Fronthaul Network (FH) is built up with Radio Units (RU) and Baseband Units (BB), each being an IP host. Each RU is unique as it is tied to a set of antennas, and each antenna is serving a specific Cell and Sector. Each RU is configured by the BB depending on the Cell and Sectors it serves. However, that dependency is only specified by the cabling between RU and antennas. If BB is directly cabled to a set of RUs, the BB can recognize the relationship between Russia and Cell/Sectors based on the cabling between the RUs and antennas. The introduction of a switched network between RUs and BBs has added a level of complexity that requires the BBs to have a deeper knowledge of the topology in order to properly configure the RUs, involving knowledge all the cabling in the switched network. Examples for switched networks are show in section 3 of and demonstrate the different levels of complexity. An example of a FH is depicted in .

Layer 2 Switched Fronthaul Example

Among the various alternatives, DHCP topology knowledge can be used for solving the RU configuration problem when the FH is IPv6. Such solution would use the topology discovery mechanisms described in section 3.2 of . The same mechanisms applies when RUs are connected via IPv4 and implement 4o6 according to . In order to extend the solution described above also to the case where RUs are using IPv4 but cannot support , it is possible to adopt the mechanisms described in this document by introducing 4o6RA in the switches.

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