[v6ops] Re: WG Last Call: draft-ietf-v6ops-6mops-04 (Ends 2025-12-05)

[Goetz Goerisch <[e-mail]>]

Dear authors and WG,

I support the addoption and I already earlier sent comments for consideration.
To ease the work of the authors I submitted a PR directly to the working document.

https://github.com/furry13/v6mostly-ops/pull/35

Best regards,
Goetz

> The WGLC is supposed to end on Dec. 5, but we only got 2 reviews by Brian and Philipp.  So I will extend the WGLC for 1 more week and request more reviews.   Mine is below.  Thank you.   XiPeng 
> 
> 
> ======== review of draft-ietf-v6ops-6mops-04 =========
> 
>   Network segment: a link (VLAN, a broadcast domain etc) where hosts
>    share the same IP subnet.
> ==>
> “Network segment” is L3, “link” is L2.  So this seems a little awkward.  suggest “Network segment: an IP subnet”
> 
> 
>    However, dual-stack networks do not address the core problem driving
>    IPv6 adoption: IPv4 address exhaustion.  They still require the same
>    amount of IPv4 resources as IPv4-only networks.  Even worse, this
>    dual-stack approach has been demonstrated to be a long-term crutch,
>    frequently masking problems that would otherwise be exposed and
>    remedied as normal operational workflows.
> ==>
> Dual stack allows people to gain IPv6 experience so that they can move to IPv6-Mostly or IPv6-Only later. For many organizations, it’s a useful (middle) step.  I think it’s better not to complain about dual stack, but simply say something like:
> Dual stack consumes more network resources and requires more management effort, i.e. for both IPv4 and IPv6. Therefore, once organizations gain sufficient IPv6 experience, it is advisable to move as many devices to IPv6 as possible.
> 
> 
>    Those concerns make DNS64 is suboptimal and undesirtable solution
> ==>
> s/undesirtable/undesirable
> 
> 
> This capability potentially allows for the
>       use of IPv4 subnets that are 2 to 4 times smaller than those
>       required for dual-stack.  It is important to note that migrating a
>       dual-stack network to an IPv6-only mode does not reduce the amount
>       of public IPv4 space required for network elements such as NAT
>       pools. 
> ==>
> The first sentence says smaller IPv4 subnet size so people would think that they can reduce the amount of public IPv4 addresses needed. But the second sentence says no. It can be a surprise.  Therefore, it may be worth explaining why.
> 
> 
>    To provide IPv6-only endpoints with DNS recursive server addresses,
>    the administrator MUST configure the network to include the DNS
>    servers IPv6 addresses into RA option, as per [RFC8106].
> ==>
> Can DHCPv6 be used?  MUST or SHOULD?
> 
> 
> DNSSEC Incompatibility: DNS64 responses fail DNSSEC validation.
> ==>
> Is this sentence too strong?  Maybe: DNS64 can interfere with DNSSEC validation for validating stubs or when synthesis happens in an untrusted resolver.
> 
> 
> Simplified troubleshooting due reduced impact of Happy Eyeballs
>       [RFC8305]: 
> ==>
> s/due/due to
> 
> 
> such as translating flows from different hosts to thesame
> ==>
> s/thesame/the same
> 
> 
>    *  User-selected fallback to dual-stack
>       networks can mask issues with IPv6-only operation, hindering
>       problem reporting and resolution.  
> ==>
> I think it’s better not to say dual stack and HE are “hindering problem reporting and resolution” – they don’t - but simply say that IPv6-Mostly may expose issues masked by dual stack and HE. To draw an analogy, taking a pain killer doesn’t prevent a person from seeking medical treatment, and if he doesn’t, it may be because he is too busy on the day (good reason), or he is too lazy (bad reason). But anyhow, we should not blame the pain killer. 
> 
> 
> For recurring temporary
>    networks, for instance during a conference, it might be a good
>    practice to change the network SSID of the last resort fallback
>    network between each event.
> ==>
> Not clear.  Please consider rewording.
> 
> 
> transating from IPv4 to IPv6 can result in packets exceeding the path
>    MTU on the IPv6 side.  In that case NAT64 creates IPv6 packets with
>    the Fragment Header (see Section 4 of [RFC6145] for more details.
> ==>
> 1.	s/transating/translating
> 2.	RFC6145 has been obsoleted by RFC7915.  Please consider quoting RFC7915.
> 
> 
> Currently (2024), all implementations use SLAAC for CLAT address
> ==>
> The latest status, as of Dec 2025, should be discussed here.
> 
> 
> In that case NAT64 creates IPv6 packets with
>    the Fragment Header (see Section 4 of [RFC6145] for more details.
> ==>
> Missing “)”
> 
> 
> As IPv6-only device can not fall back to IPv4
>    if IPv6 connectivity is not available or impacted by a malicious
>    actor.  Therefore any attack affecting IPv6 connectivity would have
>    much more drastic outcome, comparing to dual-stack networks.
> ==>
> The two sentences should become one sentence.
> 
> 
> -----Original Message-----
> From: Xipengxiao <xipengxiao=[e-mail]> 
> Sent: Saturday, 22 November 2025 15:16
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: WG Last Call: draft-ietf-v6ops-6mops-04 (Ends 2025-12-05)
> 
> Hi folks,
> 
> As Nick is a co-author, I will be watching and judging consensus for this WGLC. Please review the document and indicate whether you support or object to proceeding with its publication. As a reminder, this is not an adoption call, so please avoid statements such as “I support adoption of this draft.” Thank you.
> 
> XiPeng 
> 
> -----Original Message-----
> From: Nick Buraglio via Datatracker <[e-mail]> 
> Sent: Friday, 21 November 2025 18:41
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: WG Last Call: draft-ietf-v6ops-6mops-04 (Ends 2025-12-05)
> 
> 
> Subject: WG Last Call: draft-ietf-v6ops-6mops-04 (Ends 2025-12-05)
> 
> This message starts a 2-week WG Last Call for this document.
> 
> Abstract:
>    This document discusses a deployment scenario called "an IPv6-Mostly
>    network", when IPv6-only and IPv4-enabled endpoints coexist on the
>    same network (network segment, VLAN, SSID etc).
> 
> File can be retrieved from:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6mops/
> 
> Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [e-mail] in copy. Objections should be motivated and suggestions to resolve them are highly appreciated.
> 
> Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3].
> 
> Thank you.
> 
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
> 
> 
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]