[Gen-art] draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-04 ietf last call Genart review

[Dale Worley via Datatracker <[e-mail]>]

Document: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra
Title: DHCPv4-over-DHCPv6 with Relay Agent Support
Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document:  draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-04
Reviewer:  Dale R. Worley
Review Date:  2025-08-11
IETF LC End Date:  2025-08-14
IESG Telechat date:  [not known]

Summary:

    This draft is basically ready for publication, but has nits that
    should be fixed before publication.

Technical issue:

It seems to me that there is a technical issue:  A 4o6 client
determines that 4o6 service is available and determines the address(es)
to be used for sending DHCPV4-QUERY messages by receiving a DHCP 4o6
Server Address option in a DHCPv6 response.  In the implementation of
an RFC 7341 client, this causes no operational difficulties; the
client must have recently executed a DHCPv6 request and response to
obtain its IPv6 address(es), and so it has had the opportunity to
send/receive the DHCP 4o6 Server Address option.

But it's not clear that a 4o6RA, especially a LDRA, will necessarily
have obtained its address(es) via DHCPv6, it may have them statically
configured, especially if it is a router.

What can likely be done to resolve this is, if necessary, the 4o6
client sends a "no-op" DHCPv6 request whose primary operation does
nothing significant, but which carries the DHCP 4o6 Server Address
option.  This allows the 4o6RA to obtain a response with a DHCP 4o6
Server Address option.

If I understand RFC 8415 correctly, the "Information-request" message
suffices for this purpose.  Also, if I understand section 18.3.6 of
RFC 8415 correctly, to ensure the server responds to the message, the
4o6RA MUST insert a Client Identifier option.

I expect that this issue has already been considered by the WG, but it
seems to me that it would be valuable to the less-than-expert
implementor to describe this technique explicitly.

Administrative issue:

In a few places, the draft references draft-ietf-dhc-rfc8415bis.  But
it's not clear to me that the draft depends on 8415bis, only on 8415.
It seems to me that if possible, it is more expedient to only
reference 8415 and not introduce a dependency on another draft, which
might delay the publication of this draft.

Editorial comments:

Abstract

   This document specifies a RFC7341-based approach that
   allows DHCP 4o6 to be deployed as a Relay Agent that implements the
   4o6 DHCP encapsulation and decapsulation in an intermediate node
   rather than the client.

In a number of places in the document, this phrasing seems to me to
not quite clearly differentiate protocols from their implementations.
In this case "DHCP 4o6 to be deployed as a Relay Agent" is a rather
awkward phrasing.  I prefer

   This document specifies a RFC7341-based approach that
   allows a Relay Agent to implement the DHCP 4o6 encapsulation and
   decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a
   DHCPv4 client.

1.  Introduction

   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.

This situation is a problem even if the host cannot be updated for
even a single reason.  You want to say something like

   However, if a client is embedded in a host that only supports IPv4
   and cannot easily be replaced or updated (which could be due to any
   number of technical or business reasons), this approach does not
   work.

2.  Conventions and Definitions

   *  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].

This seems to me to be correct but hard to read.  Perhaps better

   *  Lightweight DHCPv6 Relay Agent (or LDRA): This is an extension of
      the original DHCPv6 Relay Agent specification, to allow
      layer-2-only devices to perform 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.

The phrase "the 4o6" seems to be missing a noun.  Perhaps "that
implements the 4o6 functionality specified in this document".

3.  DHCPv4 over DHCPv6 Relay Agent (4o6RA)

   As the 4o6RA takes the role of the client in respect to [RFC7341], it
   also takes the responsibility for finding a suitable interface; that
   can be a network interface or another Relay Agent.

What does "a network interface or another Relay Agent" mean?  It seems
to me that network interfaces and Relay Agents are different
categories of things.  I think that two things are meant:  The 4o6RA
is responsible for determining a suitable interface on which to be a
DHCPv6 client, and it is responsible for locating a suitable DHCPv6
server or relay agent.

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

This sounds like it is a blanket requirement on all DHCPv6 servers,
but it seems to me that the actual meaning is "DHCPv6 servers in
architectures where 4o6 is used (including 4o6RAs) MUST support RFC
7341."  See RFC 7341 section 4 which suggests that 4o6 support is not
expected to be universal in DHCPv6 servers.  But there are several
mechanisms in RFC 7341 by which 4o6 requests may be diverted to
specialized 4o6 servers, which means that not all DHCPv6 servers will
receive 4o6 requests.  Perhaps a better description is

   In any given environment, DHCPv6 servers to which DHCPV4-QUERY
   requests are routed are expected to be compliant with 4o6 according
   to [RFC7341].  No additional requirements on DHCPv6 servers are set
   by this specification.

3.2.  4o6RA and Topology Discovery

   When provided, the topology information is available at the DHCPv6
   server in form of sequence of the link-address and Interface-ID.

s.b. "the link-address field and the Interface-ID option."

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

I found this hard to understand properly at the first reading.  I
suggest clarifying it along these lines:

   In order to provide full topology information, it is RECOMMENDED
   that any implementation of 4o6RA be combined with an implementation
   of an LDRA [RFC6221] in a back-to-back structure, and that the LDRA
   implementation has a mechanism to get interface information that
   can be used to provide the Interface-ID option to outgoing
   DHCPV4-QUERY messages, as specified in Section 5.3.2 of [RFC6221].

--

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

I think you want to phrase this "Topology path preserved by 4o6 Relay
Agent in DHCP server".

Though I think you want to change "topology path" to "topology
information", since "topology path" doesn't seem to be a conventional
term.

Appendix A.  Example Use Case: Topology Discovery for IPv4-only Radio

   RAN is built up with
   Baseband Unis (BB) and Radio Units (RU).

"Unis" should be "Units".

But in general, the text uses terminology which doesn't appear in the
figure (Figure 5).  That makes it hard to understand.

   Radio Fronthaul Network
   (FH) connects RU and BB, each of RU and BB is an IP host.

This means that the RUs and BBs operate at level 3, but in the context
of this draft, it's important to know whether the RUs and BBs support
IPv6 or only IPv4.  Later in the text it says "An example ... where
IPv6 is used." but the text should be clearer as to what the described
situation is.

   In order to extend the solution described above also to the case
   where RUs are using IPv4 but cannot support [RFC7341], the mechanisms
   described in this document can be used by introducing 4o6RA in the
   switches.

Given the nature of this draft, it would be helpful to explain "can be
used by introducing 4o6RA in the switches" in detail, rather than just
stating that in the last sentence of the Appendix.  Better to specify
what each component of the DHCP client-to-server path is doing.

[END]