Hello Dale Thanks for your review and let me reply about the “administrative issue” related to referring to draft-ietf-dhc-rfc8415bis-12<https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/> rather than to RFC 8415 as this was based on my AD review. Indeed, the rfc8415bis document is already in the RFC editor queue for more than 2 months and does not have any dependencies, i.e., it will be published before this I-D.
I hope that this clarifies 😊 Regards -éric From: Dale Worley via Datatracker <[email protected]> Date: Tuesday, 12 August 2025 at 04:16 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-04 ietf last call Genart review 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]
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
