[SRv6OPS] AD review of draft-ietf-v6ops-framework-md-ipv6only-underlay-20

[Mahesh Jethanandani <[e-mail]>]

Hi Authors,

The shepherd writeup confirms strong WG consensus after four years of development. The document is well-structured and addresses a real operational need. Thank you for working on it.

I have one MAJOR and some MINOR comments that I believe will go towards improving this document.

Thanks

MAJOR:

Section 4.1, paragraph 8
>    +-------------------+------------+--------------------------+
>    |IPv6 mapping prefix|IPv4 address|IPv4-embedded IPv6 address|
>    +-------------------+------------+--------------------------+
>    |2001:db8::/32      |192.0.2.33  |2001:db8::192.0.2.33      |
>    |2001:db8:100::/40  |192.0.2.33  |2001:db8:100::192.0.2.33  |
>    |2001:db8:122::/48  |192.0.2.33  |2001:db8:122::192.0.2.33  |
>    +-------------------+------------+--------------------------+
>     Table 1: Representation Examples of IPv4-Embedded IPv6 Address

This table shows, for a /32 prefix (2001:db8::/32) and IPv4 address 
192.0.2.33, the result as 2001:db8::192.0.2.33. This representation 
places the IPv4 address at bits 96–127 (the last 32 bits).

However, RFC 6052 Section 2.2 places the IPv4 address at different 
bit positions depending on prefix length:

Prefix Length   IPv4 address bits
/32     32–63
/40     40–63, 72–79
/48     48–63, 72–87
/56     56–63, 72–95
/64     72–103
/96     96–127

Only for /96 does RFC 6052 place IPv4 in the last 32 bits. For all 
other prefix lengths, Table 1's examples diverge from RFC 6052 format.
The document needs to resolve this. The options are:

(a) Correct the table and description to use RFC 6052 bit positions 
(different for each prefix length). This maintains RFC 7915 compatibility.

(b) Restrict the framework to /96 prefix lengths for translation use 
cases, and explicitly note that non-/96 prefix lengths are only valid 
for encapsulation.

(c) Explicitly describe a simplified mapping scheme (IPv4 always at 
bits 96–127) and note that this diverges from RFC 6052 for non-/96 prefixes, 
and that encapsulation (not translation) must be used for non-/96 prefixes.

Option (a) aligns best with the stated RFC 6052 compliance, but changes 
the examples significantly. Option (b) or (c) maintains the simpler model 
but requires additional text. Any of these is acceptable, but the current 
text is technically inconsistent and will confuse implementors.

MINOR:

Section 1, paragraph 3
>    For the IPv6-only deployment in the access section, to date various
>    transition technologies such as 464XLAT [RFC6877], MAP-T [RFC7599],
>    MAP-E [RFC7597], and DS-Lite [RFC6333] have been developed and
>    deployed [RFC9313].  These solutions allocate only IPv6 addresses to
>    customer terminals or networks, addressing IPv4 address exhaustion on
>    the user side while enabling access to both IPv4 and IPv6 Internet
>    services.  [I-D.ietf-v6ops-6mops] describes a deployment scenario
>    referred to as "an IPv6-Mostly network", where IPv6-only and
>    IPv4-enabled endpoints coexist on the same network (network segment,
>    VLAN, SSID etc.).  It allows IPv6-capable devices to remain IPv6-only
>    while the network is seamlessly supplying IPv4 access to those that
>    require it.

RFC 6877 is not normatively required to implement or understand this 
framework. It should be moved to informative references. Other RFCs 
cited, including RFC 6333 (DS-Lite), RFC 7597 (MAP-E), and 
RFC 7599 (MAP-T) — they are in the informative section already, 
but RFC 6877 was left in normative section.

Section 1, paragraph 3
>    Unless otherwise stated, the term “IPv6-only network” in this
>    document refers specifically to “IPv6-only underlay network”. This
>    document presents a framework for building a large-scale IPv6-only
>    network from the perspective of network operators.  As it is
>    described at a high level, this framework is not meant to replace
>    existing IPv6-only technologies but rather to leverage and remain
>    compatible with them, nor does it propose any new IPv6 transition
>    mechanisms or IPv4-as-a-Service solutions.  When transmitting IPv4
>    service data, this framework enables end-to-end tunneling or
>    translation across multiple network providers, and therefore is
>    different from existing SRv6/MPLS VPN solutions which are for a
>    single NP.  It also differs from "IPinIP" tunneling in that this
>    approach includes a control plane, whereas "IP-in-IP" does not.

I am not an expert here, but the last sentence seems misleading to me.
IP-in-IP tunnels frequently operate alongside routing protocols 
that constitute a control plane (e.g., routing adjacencies over 
the tunnel). The real distinction is that this framework includes a 
specific mechanism for distributing IPv4-to-IPv6 mapping rules 
across domains. Can this sentence be restated for the actual 
distinction more precisely.

Section 2, paragraph 11
>    *  PE: Provider Edge (Section 5.2 of [RFC4026]).

RFC 4026 defines PE specifically in the context of provider-provisioned 
VPNs. The PE concept in this document is used in a broader underlay 
routing context that does not have VPN semantics. Two options:

Define PE directly in the terminology section (recommended for clarity), 
and move RFC 4026 to informative.

Or explain why the VPN-context definition from RFC 4026 is the right one to 
import here.

Section 3, paragraph 0
>    This framework is designed to assist large NPs in deploying IPv6-only
>    networks in a multi-domain environment.  Large-scale NPs usually
>    manage network infrastructure comprising multiple interconnected
>    Autonomous Systems (ASes).  This is referred to as a "Multi-domain
>    Underlay Network" in this document.  These ASes often support
>    different functions, such as metro area networks (MANs), backbone
>    networks, 4G/5G mobile core networks, Data Centers (DCs), and may be
>    administered by separate departments or NPs with different routing
>    and security policies.  In a multi-domain network environment, edge
>    nodes are commonly referred to as Provider Edge (PE) routers.  The
>    ingress PE is the router where a packet enters the network, while the
>    egress PE is the router where it exits.  Internal nodes are typically
>    called Provider (P) routers.

s/metro area network (MANs)/Metro Area Networks (MANs) and add MAN
to the terminology section.


Section 4.2, paragraph 4
>    To support the MR-DB operations in the framework, PE1 and PE3 should
>    support [I-D.ietf-idr-mpbgp-extension-4map6].  For the mapping rules
>    to propagate from PE3 to PE1 across the network, the intermediate BGP
>    speakers (e.g., route reflectors / ASBRs) that propagate the relevant
>    NLRI MUST support [RFC8950].  [I-D.ietf-idr-mpbgp-extension-4map6]
>    provides IPv4-to-Pref6 mappings processing at each PE device.
>    [RFC8950] specifies the extensions necessary to allow the advertising
>    of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to
>    the IPv6 protocol.  It allows gradual deployment of the functionality
>    of advertising IPv4 reachability via an IPv6 next hop without any
>    flag day or any risk of traffic black-holing.

The IDR draft draft-ietf-idr-mpbgp-extenstion-4map6 is still a work in 
progress (at -05 as of December 2025). It should be noted that the 
framework cannot be fully deployed until the address mapping rule exchange 
mechanism is standardized, and that [I-D.ietf-idr-mpbgp-extension-4map6] 
represents the current leading candidate for that mechanism. Similarly, 
[I-D.ietf-sidrops-moa-profile], referenced in Section 7.2 for security 
mitigations, is also still in progress — its status should be noted.

Section 5.1, paragraph 4
>    2.  Packet Conversion
> 
>    *  Generate IPv4-embedded IPv6 packets using either translation or
>       encapsulation

This sub-section covers only ingress behavior (generating IPv6 packets 
from IPv4). The equally important egress behavior (converting IPv6 back 
to IPv4) is not listed here. It's described later in Section 5.3 but 
omitted from this overview list. Please add egress packet conversion 
to the function list.

Section 6, paragraph 1
>    NPs should carefully determine the IPv6 mapping prefix length during
>    deployment.  It is recommended that all IPv6 mapping prefixes have
>    the same length to avoid unnecessary processing cost and complexity
>    introduced by prefix length diversity.

Is the "should" and "recommend" a normative (BCP14) SHOULD and 
RECOMMENT respectively. If not, use other words to remove confusion.

Section 8, paragraph 0
> 8.  IANA Considerations

This comment is really about Operational Considerations, but since
that section is missing, just anchoring it here.

Again, I am not an expert, but my understanding was that when IPv4 
packets are encapsulated in IPv6, the encapsulated packet is 
40 bytes larger than the original. When translated, the IPv6 header 
is 20 bytes larger than the IPv4 header. In a multi-domain network 
traversing multiple ASes, MTU differences between domains can cause 
silent packet drops or performance degradation. This is a fundamental 
operational concern for any IPv4-over-IPv6 framework. The document 
should at minimum note that deployers need to handle MTU/fragmentation — 
for example, by configuring appropriate MSS clamping, ensuring 
consistent MTU across domains, or following the recommendations in 
RFC 7915 Section 1.4 for general MTU/fragmentation handling and
Section 4.2/5.2 for specific ICMP translation handling. The absence 
of any MTU discussion is a gap for an operational framework document.

Section 8, paragraph 0
>    There are no other special IANA considerations.

What does "other" mean? Just say "This document has no IANA action."

Document has Informational status, but uses the RFC2119 keywords "SHOULD",
"MUST", "RECOMMENDED", and "OPTIONAL". Check if this is really necessary?

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"


Mahesh Jethanandani
[e-mail]