Hi Dale, Thanks for your valuable work. We have considered all your suggestions for a revised version of the draft. About the Technical issue, I see your point. Actually the draft is depending on rfc7341 for configuration, and rfc7341 simply says: Before the client can use DHCPv4 over DHCPv6, it MUST obtain the necessary IPv6 configuration. The client requests the DHCP 4o6 Server Address option from the server by sending the option code in an Option Request option as described in [RFC3315]. In case of 4o6RA, it may be not aware of the way the host has been configured. In the draft we wrote: As the 4o6RA takes the role of the client in respect to [RFC7341], it 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. I think this may be improved by replacing with: As the 4o6RA takes the role of the client in respect to [RFC7341], it 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. It is RECOMMENDED that the 4o6RA requests the DHCP 4o6 Server Address option from the server by sending the option code in an Option Request option using an INFORMATION-REQUEST message as described in [draft-ietf-dhc-rfc8415bis]. About the Appendix A, We did some improvements to the wording. Since it's not relevant for the implementor, I'd wish to avoid going too much in details. All the other comments have been implemented according to your suggestions. Best Regards, Claudio (from the author's team) > -----Original Message----- > From: Dale Worley via Datatracker <noreply@xxxxxxxx> > Sent: Tuesday, August 12, 2025 4:16 AM > To: gen-art@xxxxxxxx > Cc: dhcwg@xxxxxxxx; draft-ietf-dhc-dhcpv4-over-dhcpv6-ra.all@xxxxxxxx; last- > call@xxxxxxxx > 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%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cclaudio.porfiri%4 > 0ericsson.com%7C6ee5611b77814e88c9d708ddd9462ce2%7C92e84cebfbfd47a > bbe52080c6b87953f%7C0%7C0%7C638905617608078611%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=25Mf0hUucc > LtAt7NiKewJp4ZlSr6FdIDxtaMSlOCMfE%3D&reserved=0>. > > 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] > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
