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

[Mahesh Jethanandani <[e-mail]>]

That works. Thanks for making the change. 

Cheers. 

Mahesh Jethanandani 

[e-mail]

On May 8, 2026, at 11:57 PM, Chongfeng Xie <[e-mail]> wrote:



Hi Mahesh，

Sorry for not accurately understanding your point at first. I think I get it now. We have just 

submitted a new version (-v22), in which we have made the following change，

    OLD：

    It also differs from "IP-in-IP" tunneling in that this approach includes a 

    control plane for encapsulation or translation, whereas "IP-in-IP" does not.

New：

       Unlike IP-in-IP tunnel mechanism, where tunnels often operate alongside routing protocols that

       form a control plane (e.g., routing adjacencies over the tunnel), this framework includes

       a specific mechanism for distributing IPv4 to-IPv6 mapping rules across domains.

Do you think it is OK?

Best regards

Chongfeng

 

From: Mahesh Jethanandani

Date: 2026-05-09 01:34

To: Chongfeng Xie

CC: list; [e-mail]

Subject: Re: [v6ops] AD review of draft-ietf-v6ops-framework-md-ipv6only-underlay-20

Hi Chongfeng,

Please see inline with [mj].

On May 7, 2026, at 7:09 PM, Chongfeng Xie <[e-mail]> wrote:

Hi Mahesh，

Thank you very much for your thorough review and raising so many constructive comments.  Based on your 

comments,  I have revised the document and submitted a new version (version -21). In addition, 

please see my  feedback inline [Chongfeng],

 

From: Mahesh Jethanandani

Date: 2026-05-06 06:18

To: draft-ietf-v6ops-framework-md-ipv6only-underlay.all

CC: ops-ads; v6ops

Subject: [v6ops] Re: AD review of draft-ietf-v6ops-framework-md-ipv6only-underlay-20

Resending the review after correcting one of the email addresses.

On May 5, 2026, at 2:53 PM, Mahesh Jethanandani <[e-mail]> wrote:

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.

[Chongfeng]: We choose option A, table 1 has been corrected and becomes 

consistent with table 1 of RFC6052. The following changes have made to the text, 

OLD:

This framework proposes to use algorithmic translation of an IPv4

   address to a corresponding IPv6 address, and vice versa, using only

   statically configured information.  With this approach, IPv4-embedded

   IPv6 addresses are composed by concatenating the prefix, the 32 bits

   of the IPv4 address, and the suffix (if needed) to obtain a 128-bit

   address.  As specified in [RFC6052], commonly used prefix lengths

   include 32/40/48/56/64/96; in this model the embedded IPv4 address

   occupies the last 32 bits.  The middle bits may be set to zero (or

   otherwise as per the operator's addressing plan).  Examples of such

   representations are presented in Table 1.

NEW:

This framework proposes to algorithmically translate an IPv4 address to a 

corresponding IPv6 address, and vice versa, using only statically configured

  information. The IPv6 address translated from an IPv4 address is called an

  IPv4 embedded IPv6 address, which has been defined in [RFC6052]. As shown in Section

  2.2 of [RFC6052], IPv4-embedded IPv6 addresses are composed of a 

variable-length prefix, the embedded IPv4 address, and a variable-length

  suffix. Table 1 shows examples of such representations, it is the same as

  Table 1 of RFC6052, except that the first column of the latter is "Network-Specific Prefix"

. Note that [RFC7915] also allows the use of unicast

  addresses without u-bit (as long as they're not derived from an IEEE 

MAC-layer address).

[mj] This change works for me. Thanks for making it.

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.

[Chongfeng]: RFC6877 has be moved to informative references.

[mj] I consider this issue resolved.

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.

[Chongfeng]: The last sentence was proposed by Xipeng, one of the 

co-chairs of the v6ops working group. IP-in-IP is a simple tunneling 

protocol in which one IP packet (the inner packet) is encapsulated

 inside another IP packet (the outer packet) as its payload. The point

 that "IP-in-IP" does not include a control plane means that the

encapsulation-based tunnel can be setup manually and does not 

need to be setup by specific control protocol. The case that

 “Routing adjacencies over the tunnel” you mentioned refers 

to that routing adjacencies may use a tunnel to exchange the 

routing information, but the routing here is not used for tunnel setup. 

To reduce the confusion in the original text, I have changed the last 

sentence to,

“It also differs from "IP-in-IP" tunneling in that this approach includes a 

control plane for encapsulation or translation, whereas "IP-in-IP" does not.

[mj] My original comment pointed out that IP-in-IP tunnels frequently do operate alongside routing protocols that constitute a control plane, and the real distinction is the specific mechanism for distributing IPv4-to-IPv6 mapping rules across domains. The revised text has moved from "a control plane" to "a control plane for encapsulation or translation," which is marginally more specific, but still does not precisely identify the mapping rule exchange/distribution mechanism as the differentiator. An IP-in-IP tunnel with BGP over it also has "a control plane for encapsulation." The fix is an improvement but doesn't fully answer the concern. I am not going to block on the issue, but would suggest that the changes have not hit the mark.

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.

[Chongfeng]：PE is directly defined as below,

      PE: Provider Edge, a device at the edge of the IPv6-only underlay network, 

          providing the functionality required for IPv4-as-a-Service.

and RFC4026 is removed from the reference section.

[mj] I consider this issue resolved.

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.

[Chongfeng]: Done.

[mj] Resolved

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.

[Chongfeng]: OK.

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.

[Chongfeng]: The equally egress behavior is added as below,

 *  Recover IPv4 packets from IPv4-embedded IPv6 packets via translation or decapsulation.

[mj] Resolved.

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.

[Chongfeng]: The "should" and "recommend" is not a normative (BCP14) SHOULD and 

RECOMMENT respectively, so they have been changed in the sentences as below,

For NPs, having all IPv6 mapping prefixes share the same length during deployment 

       will likely avoid the unnecessary processing cost and complexity caused by prefix 

       length diversity.

[mj] Resolved.

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.

[Chongfeng]: Based on the suggestion above, a specific section of “

Operational Considerations” has been added.

[mj] Thanks for adding the section.

Section 8, paragraph 0

>    There are no other special IANA considerations.

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

[Chongfeng]: This has been changed to "This document has no IANA action."

[mj] Resolved.

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.

[Chongfeng]: Does this mean a new template which contains “consensus boilerplate”? 

If yes, can you give me an example draft?

[mj] I consider this resolved.

Found terminology that should be reviewed for inclusivity; see

https://www.rfc-editor.org/part2/#inclusive_language" rel="nofollow">https://www.rfc-editor.org/part2/#inclusive_language for background and more

guidance:

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

   "intrinsic", "original"

[Chongfeng]: The term of “native” has been removed.

[mj] Thanks.

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

Best regards

Chongfeng On behalf of all the co-authors

Mahesh Jethanandani

[e-mail]