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

[Stewart Bryant <[e-mail]>]

Thank you Brian. 

Experimental is another possibility I wondered about, but either way you address my immediate concern.

Best regards

Stewart

> On 25 Jun 2026, at 02:19, Brian E Carpenter <[e-mail]> wrote:
> 
> Stewart,
> 
>> 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.
> 
> The draft states clearly that translation complies with RFC7915, which covers
> the UDP zero checksum issue explicitly.
> 
> You are of correct that other issues _might_ appear during deployment, but this
> is only asking for Informational status, although there could be an argument
> for going directly to BCP.
> 
> (Note to authors: an Implementation Status section would have made it
> easier to reply to Stewart!)
> 
> Regards/Ngā mihi
>   Brian Carpenter
> 
>> 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.
>> 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.