Dynamic Host Configuration                                    C. Porfiri
Internet-Draft                                                  Ericsson
Intended status: Standards Track                             S. Krishnan
Expires: 23 June 2025                                              Cisco
                                                                J. Arkko
                                                            M. Kühlewind
                                                                Ericsson
                                                        20 December 2024


         DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support
                draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-01

Abstract

   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

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-
   dhcpv6-ra/.

   Source for this draft and an issue tracker can be found at
   https://github.com/mirjak/dhc-dhcpv4-over-dhcpv6-ra.

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."



Porfiri, et al.           Expires 23 June 2025                  [Page 1]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   This Internet-Draft will expire on 23 June 2025.

Copyright Notice

   Copyright (c) 2024 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Applicability Scope . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  DHCPv4 over DHCPv6 Relay Agent (4o6RA)  . . . . . . . . . . .   4
     3.1.  Intermediate relays . . . . . . . . . . . . . . . . . . .   5
     3.2.  4o6RA and Topology Discovery  . . . . . . . . . . . . . .   5
   4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Example Use Case: Topology Discovery for IPv4-only
           Radio Unit in the RAN Switched Fronthaul  . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC7341] describes a transport mechanism for carrying DHCPv4
   [RFC2131] messages using DHCPv6 [RFC8415] for the dynamic
   provisioning of IPv4 addresses and other DHCPv4 specific
   configuration parameters across IPv6-only networks.  The deployment
   of [RFC7341] 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.




Porfiri, et al.           Expires 23 June 2025                  [Page 2]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   Similarly, the specifications for DHCPv6 Relay Agents such as LDRA
   [RFC6221] or L3RA [RFC8415] do not foresee the possibility to handle
   legacy DHCPv4, other than implementing DHCP 4o6 in the client.

   This document specifies an [RFC7341]-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 [RFC7341] that allows a Relay Agent to perform the DHCP 4o6
   encapsulation and decapsultion instead of the client.

1.1.  Applicability Scope

   The mechanisms described in this document apply to the configuration
   phase of the host, specifically when a DHCP server for IPv4 [RFC2131]
   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 [RFC7341] and the
   host doesn't implement a DHCP client conform to [RFC7341] itself.

2.  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 [RFC2131]

   *  DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures and
      the protocols described in the DHCPv4-over-DHCPv6 document
      [RFC7341].

   *  DHCP Relay Agent: This is a concept in all of the protocols, BOOTP
      [RFC0951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
      [RFC8415], 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 [RFC6221].

   *  DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent
      that implements the 4o6 specified in this document.








Porfiri, et al.           Expires 23 June 2025                  [Page 3]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   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.

3.  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 Figure 1.

                     .-----------.             .-----------.
                    |             |           |             |
           +--------+-+    L2   +-+-----------+-+  IPv6   +-+--------+
           |  DHCPv4  | Network |    DHCPv6     | Network | DHCP 4o6 |
           |  Client  +---------+  Relay Agent  +---------+  Server  |
           |          |         |   with 4o6RA  |         |          |
           +--------+-+         +-+-----------+-+         +-+--------+
                    |             |           |             |
                     '-----------'             '-----------'

           Figure 1: Architecture Example with Legacy DHCP Client

   This document specifies the encapsulation and decapsulation described
   in [RFC7341] 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
   Section 5 of [RFC7341] shall be applied to 4o6RA instead.

   [RFC7341] 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 [RFC7341] 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 [RFC8415].  The 4o6RA implements
   the same message types as a normal DHCPv6 Relay Agent Section 6 of
   [RFC7341].






Porfiri, et al.           Expires 23 June 2025                  [Page 4]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   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 Section 6 of
   [RFC6221].

   DHCPv6 servers must be compliant with 4o6 according to [RFC7341].  No
   additional requirements on DHCPv6 servers are set by this
   specification.

3.1.  Intermediate relays

   Intermediate relays shall behave according to section 10 of
   [RFC7341].

3.2.  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 [RFC2131] and DHCPv6 [RFC3315] 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 [RFC7969], 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 [RFC7969] 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 [RFC7969]).  Thus in a generic
   network involving more than one Relay Agent only part of the topology
   is transported via DHCPv4.






Porfiri, et al.           Expires 23 June 2025                  [Page 5]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   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 [RFC6221] 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 [RFC7341] 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.

               .-----------.     .-------------------------.
              | L2 Network  |   |        IPv6 Network       |
     +--------+-+         +-+---+---+    +--------+       +-+--------+
     |  DHCPv4  |         |  4o6    |    | DHCPv6 |       | DHCP 4o6 |
     |  Client  +---------+  Relay  +----+ Relay  +-------+  Server  |
     |          |         |  Agent  |    | Agent  |       |          |
     +--------+-+         +-+---+---+    +--------+       +-+--------+
              |             |   |                           |
               '-----------'     '-------------------------'

                       Figure 2: Topology broken path

   As shown in Figure 2, 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 [RFC6221] 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 Section 5.3.2 of [RFC6221].  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.











Porfiri, et al.           Expires 23 June 2025                  [Page 6]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


                  .-----------.     .---------------------------.
                 | L2 Network  |   |          IPv6 Network       |
        +--------+-+         +-+---+--+---------+      +----------+
        |  DHCPv4  |         |  4o6   |  LDRA   |      | DHCP 4o6 |
        |  Client  +---------+  Relay + RFC6221 +------+  Server  |
        |          |         |  Agent |         |      |          |
        +--------+-+         +-+---+--+---------+      +----------+
                 |             |   |                             |
                  '-----------'     '---------------------------'

                Figure 3: Topology path preserved with LDRA

   The assumed architecture is shown in Figure 3 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 Figure 4.

                           .-----------.
                          | L2 Network  |
                 +--------+-+         +-+------+----------+
                 |   DHCP   |         |  4o6   | DHCP 4o6 |
                 |  Client  +---------+  Relay +  Server  |
                 |  on CPE  |         |  Agent |          |
                 +--------+-+         +-+------+----------+
                          |             |
                           '-----------'

      Figure 4: Topology path preserved 4o6 Relay Agent in DHCP server

4.  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.

5.  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 [RFC7341] still apply.



Porfiri, et al.           Expires 23 June 2025                  [Page 7]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   This mechanism differs from [RFC7341] as the DHCP client sends and
   receives DHCPv4 messages, whereas in [RFC7341] 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.

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [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, <https://www.rfc-editor.org/rfc/rfc3315>.

   [RFC6221]  Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
              Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
              DOI 10.17487/RFC6221, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6221>.

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
              RFC 7341, DOI 10.17487/RFC7341, August 2014,
              <https://www.rfc-editor.org/rfc/rfc7341>.

   [RFC7969]  Lemon, T. and T. Mrugalski, "Customizing DHCP
              Configuration on the Basis of Network Topology", RFC 7969,
              DOI 10.17487/RFC7969, October 2016,
              <https://www.rfc-editor.org/rfc/rfc7969>.




Porfiri, et al.           Expires 23 June 2025                  [Page 8]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/rfc/rfc8415>.

7.2.  Informative References

   [RFC0951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              DOI 10.17487/RFC0951, September 1985,
              <https://www.rfc-editor.org/rfc/rfc951>.

   [RFC1542]  Wimer, W., "Clarifications and Extensions for the
              Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
              October 1993, <https://www.rfc-editor.org/rfc/rfc1542>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

Appendix A.  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.





Porfiri, et al.           Expires 23 June 2025                  [Page 9]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   Examples for switched networks are show in section 3 of [RFC7969] and
   demonstrate the different levels of complexity.  An example of a FH
   is depicted in Figure 5.

     +--------+
     |  RU1   |     P1 +-+------+     |                   |
     |        +--------| | L2RA |     |  +----+------+    |
     +--------+        | +------+     |  |    | L3RA |    |
                       |  L2    |     +--|    +------+    |
     +--------+     P2 | switch |     |  |           |    |
     |  RU2   +--------|  #1    +-----|  |   Router  +----|
     |        |        +--------+     |  +-----------+    |  +---------+
     +--------+                       |                   |  |         |
                                      |                   +--| DHCP    |
     +--------+                       |                   |  | Server  |
     |  RU3   |     P1 +-+------+     |                   |  |   #1    |
     |        +--------| | L2RA |     |  +-----------+    |  +---------+
     +--------+        | +------+     |  |           |    |
                       |  L2    |     +--| Baseband  |    |
     +--------+     P2 | switch |     |  |   Unit    |    |
     |  RU4   +--------|  #2    +-----|  |           +----|
     |        |        +--------+     |  +-----------+    |
     +--------+                       |                   |

             Figure 5: 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 [RFC7969].  The same mechanisms applies when RUs are
   connected via IPv4 and implement 4o6 according to [RFC7341].

   In order to extend the solution described above also to the case
   where RUs are using IPv4 but cannot support [RFC7341], 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.

Authors' Addresses

   Claudio Porfiri
   Ericsson
   Email: claudio.porfiri@ericsson.com



Porfiri, et al.           Expires 23 June 2025                 [Page 10]

Internet-Draft            DCHP 4o6 Relay Agent             December 2024


   Suresh Krishnan
   Cisco
   Email: suresh.krishnan@gmail.com


   Jari Arkko
   Ericsson
   Email: jari.arkko@ericsson.com


   Mirja Kühlewind
   Ericsson
   Email: mirja.kuehlewind@ericsson.com






































Porfiri, et al.           Expires 23 June 2025                 [Page 11]