Early Review of draft-ietf-v6ops-framework-md-ipv6only-underlay-23
review-ietf-v6ops-framework-md-ipv6only-underlay-23-opsdir-early-chown-2026-06-20-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-v6ops-framework-md-ipv6only-underlay-23

- Reviewer: Tim Chown

- Review Date: 18 June 2026

- Intended Status: Informational

The draft describes a proposed framework for a (multi-domain) IPv6 underlay
that uses stateless address mapping as a means to facilitate transmission of
IPv4 packets across an IPv6-only network.

The document is Informational, so does not contain any new specifications,
rather it describes how existing specifciations can be used to provide the
"IPv4-as-a-service" functionality.

The document is very well written, easy to read and follow.  An excellent
example of how to write.

It is also, potentially, a useful document to publish.

The general thrust of the draft is ok, but I consider it status as "Has
Issues", for the reason given below.

Major issues:

The main issue I have with this document is that it frequently refers to, and
requires, an address mapping rule, but the specific structure(s) of this is/are
stated as being out of scope for the document in sections 1 and 4.1. While it
states how the information can be shared in 5.2 (which for a routing approach
requires an additional spec currently at a draft stage, i.e.,
ietf-idr-mpbgp-extension-4map6), sections 4.1 and 5.2 state those specifics are
out of scope.

The authors may argue that to include these details might require an elevation
of the document to a standards document rather than informational, or would the
solution be based on an existing spec?  It's not clear. I think more needs to
be said here. Nor is it clear for example how the prefix mapping might change
on a per-AS basis - is the address mapping the same from any domain to a given
destination, or might it change.  Or what other capabilities may be present
based on the (to be defined) structures.

Having a clearer picture of the complete solution prior to publication would be
useful.

Minor issues:

In the introduction, the text could cite added security complexity of two
protocols as a rationale to move away from dual-stack. There is also relevance
of Happy Eyeballs in the section - HE means in many cases operators may not
receive reports of outages of one of the IP protocols.  The "what is IPv6-only"
part could cite Jordi's draft.

Tim