[Gen-art] Re: [Last-Call] draft-ietf-v6ops-framework-md-ipv6only-underlay-23 ietf last call Genart review

[Chongfeng Xie <[e-mail]>]

Hi Stewart,

Thank you for your review and valuable feedback. We have resubmitted the revised draft,  and our responses are provided inline [Chongfeng].
 

On 25-Jun-26 03:34, Stewart Bryant via Datatracker wrote:
Document: draft-ietf-v6ops-framework-md-ipv6only-underlay
Title: Framework for Multi-domain IPv6-only Underlay Network and
IPv4-as-a-Service Reviewer: Stewart Bryant 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-v6ops-framework-md-ipv6only-underlay-23
Reviewer: Stewart Bryant
Review Date: 2026-06-24
IETF LC End Date: 2026-06-22
IESG Telechat date: Not scheduled for a telechat
Summary: I am reviewing from a GENART perspective and with this perspective I
think the text of the draft should reassure me that this unconditionally works
for any legitimate IPv4 protocol stack and any legitimate operation of that
protocol stack.
The draft adequately describes how an IPv4 packet is sent and delivered over an
IPv6 network at the network layer but IPv4/6 hosts have assumptions about the
network they are using at other layers of the protocol stack and there is no
in-depth exploration of the wider considerations. Hopefully these are addressed
in other similar mechanisms that I did not have time to explore, but I think
the general reader should be reassured in the body of the text.



Major issues:The draft has covered ICMP by asserting the presence of a
stateless translator, but I cannot but worry that the are a lot of other
assumptions built into an IPv4 protocol stack that may surface during
deployment. For example IPv6 has the assumption (for integrity reasons) that
UDP will have a checksum. IPv4 is acrostic on that and frequently sets CS = 0
and yet the draft seems to be silent on the consequences. I wonder if the draft
needs to be experimental until there is operational experience with the method.

[Chongfeng]: 
This draft builds on prior works practice. As Brian noted, the translation mechanism in 
this draft adheres to RFC7915, which explicitly addresses the UDP zero-checksum issue. 
Moreover, the IPv4 data delivery cross IPv6-only network which is specified in RFC7915 
has already been tested on large-scale production networks such as CERNET (see RFC6219) 
and ChinaNet, and there are no major issues observed in these operational environments, 
it is reasonable to conclude that the necessary experimental validation has been effectively done.

The process of ICMP in the case of stateless translator is so mature that it can also be seen at,
https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/ip-addressing/ip-addressing/m_iadnat-stateless-nat64.html

Following the comment of Brian about implementation status, the following sentence has 
been added in section 7,

“It should be noted that the IPv4 data delivery cross IPv6-only network specified in RFC7915 
has already been tested on some large-scale networks, such as CERNET, and there are no major issues observed.”


Minor issues: None

Nits/editorial comments:There seems to be a minor confusion between Network
Operator and Network Provider in the text that needs examining. "service
continuity after IPv4 address exhaustion, network operators (NPs). I assume
this is just a typo

[Chongfeng]: To reduce confusion, all occurrences of “network operator” in the text 
have been changed to “network provider”.


If you have more comments, please feel free to let me know. Thanks.

Chongfeng