Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!-- [rfced] Please review the text below. We were unable to find "L3RA"
used in
[draft-ietf-dhc-rfc8415bis] (now published as RFC 9915).
Original:
Similarly, the specifications for DHCPv6 Relay Agents such as
Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent
(L3RA) [draft-ietf-dhc-rfc8415bis] do not foresee the possibility to
handle legacy DHCPv4, other than implementing DHCP 4o6 in the client.
-->
2) <!-- [rfced] Section 2:
a) May we adjust the items in this list to appear in alphabetical order?
b) May we make these list items consistent as follows?
Original:
* DHCP: If not otherwise specified, DHCP refers to DHCPv4 and/or
DHCPv6.
* DHCPv4: DHCP as defined in [RFC2131].
* DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures, and
the protocols specified in the DHCPv4-over-DHCPv6 document
[RFC7341].
* DHCP Relay Agent: This is a concept in all of the following
protocols, although the details differ between them: BOOTP
[RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
[draft-ietf-dhc-rfc8415bis].
* 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 transport as specified in this document.
Perhaps:
DHCP:
Refers to DHCPv4 and/or DHCPv6 if not otherwise specified.
DHCPv4:
Refers to DHCP as defined in [RFC2131].
DHCPv4 over DHCPv6 (DHCP 4o6):
Refers to the architecture, the procedures, and the protocols specified in
the DHCPv4-over-DHCPv6 document [RFC7341].
(etc.)
-->
3) <!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations
should be expanded upon first use. How and where should "CPE" be expanded as
it appears in Figure 4?
Original:
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.
Perhaps:
In a simple case, where the same node hosts the 4o6RA and the DHCP 4o6
server, it might be enough to only use 4o6RA, as shown in Figure 4, where
CPE stands for "Customer Premises Equipment".
-->
4) <!-- [rfced] Security Considerations:
a) Would the following adjustment clarify what "the 4o6 DHCP specification"
refers to?
b) Please note that we have changed "4o6 DHCP" to "DHCP 4o6" in this
section for consistency with the rest of the document.
Original:
This document does not change anything else in the 4o6 DHCP specification
and therefore the security considerations of [RFC7341] still apply.
Perhaps:
This document does not change anything else in the DHCP 4o6 specification
[RFC7341];
therefore, the security considerations of that document still apply.
-->
5) <!-- [rfced] Appendix A: Please review our questions and suggested updates to
the text below, including the following items:
a) Should the abbreviation for "Baseband Units (BB)" be updated to "Baseband
Units (BBUs)"
as seen in the text below? If so, please note that we would also update
instances of
"BB"/"BBs" to "BBU"/"BBUs" accordingly throughout the rest of this section as
well.
b) Should the abbreviation for "Radio Fronthaul Network (FH)" be adjusted for
clarity?
Original:
In 3GPP mobile network architecture, the User Equipments (UE) are
connected via Radio Access Network (RAN). RAN is built up with
Baseband Units (BB) and Radio Units (RU). Radio Fronthaul Network
(FH) connects RU and BB, each of RU and BB is an IP host, they may
support IPv4 only, IPv6 only or both depending on the vendor and the
model.
Perhaps:
In 3GPP mobile network architecture, the User Equipment (UE) is
connected via a Radio Access Network (RAN). RAN is built up with
Baseband Units (BBUs) and Radio Units (RUs). A radio Fronthaul (FH) network
connects RUs and BBUs. Each RU and BBU is an IP host, and they may
support IPv4 only, IPv6 only, or both, depending on the vendor and the
model.
-->
6) <!-- [rfced] Terminology and Abbreviations:
a) We note that the phrase "4o6" appears a few times by itself throughout this
document. For consistency and context, should these instances be updated to
"DHCP 4o6"?
We have provided a few examples below:
the 4o6 transport
are expected to be compliant with 4o6
the introduction of 4o6 at the edge
moving 4o6 to a intermediate node
a 4o6 client
b) We note the following phrases appear after their abbreviations are
introduced. For consistency, should these terms (on the left) be updated to
their abbreviated form (on the right) after first use?
Expansion -> Abbreviation
DHCPv4-over-DHCPv6 -> DHCP 4o6
4o6 Relay Agent -> 4o6RA
Layer 2 -> L2
c) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Bootstrap Protocol (BOOTP)
Layer 2 (L2)
-->
7) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
Thank you.
Alanna Paloma and Kaelin Foody
RFC Production Center
On Feb 18, 2026, at 11:00 AM, [email protected] wrote:
*****IMPORTANT*****
Updated 2026/02/18
RFC Author(s):
--------------
Your document has now entered AUTH48.
The document was edited in kramdown-rfc as part of the RPC pilot test (see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
Please review the procedures for AUTH48 using kramdown-rfc:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
Once your document has completed AUTH48, it will be published as
an RFC.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9928.md
https://www.rfc-editor.org/authors/rfc9928.html
https://www.rfc-editor.org/authors/rfc9928.pdf
https://www.rfc-editor.org/authors/rfc9928.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9928-diff.html
https://www.rfc-editor.org/authors/rfc9928-rfcdiff.html (side by side)
Diff of the kramdown:
https://www.rfc-editor.org/authors/rfc9928-md-diff.html
https://www.rfc-editor.org/authors/rfc9928-md-rfcdiff.html (side by side)
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9928
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9928 (draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06)
Title : DHCPv4-over-DHCPv6 with Relay Agent Support
Author(s) : C. Porfiri, S. Krishnan, J. Arkko, M. Kühlewind
WG Chair(s) : Timothy Winters, Bernie Volz
Area Director(s) : Erik Kline, Éric Vyncke
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
