Return-Path: X-Original-To: srv6ops@mail2.ietf.org Delivered-To: srv6ops@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AB430E984DC6 for ; Tue, 5 May 2026 14:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778018043; bh=W3Jsd8Nk7KQ7VD8Y73T8dRllnb2l9SsKBQlbs8kyG4A=; h=From:Subject:Date:Cc:To; b=PMzf4bZGl98lVeMdBmFMUMyYjmme0AIEVNHpMO1237k2tleB8nefMYSqB3e1nG7u/ Ip1mdQ/PmYmfhMYJFldRO9s9GiV9tZxQBsiq7RQTzsTb8fpPbI3Uqlw86WxLsSnaAS ATcMef/rhgSj6gxMYEOKEW88DpwWizZgd6ZimhAs= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRIp5caZZmV6 for ; Tue, 5 May 2026 14:53:59 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9F950E984DB5 for ; Tue, 5 May 2026 14:53:59 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4893940bb5eso31534945e9.3 for ; Tue, 05 May 2026 14:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778018039; x=1778622839; darn=ietf.org; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=WIl8OCAgOzyDEFrCJSLwlUVwbWpfj3TuGMUQ/E6lf0M=; b=PTDgKgB7W9ngM7ORpdbKydSJso9RuyNeMMsIl5/hDFz2yxWU1aZuNT6+QJoUOMQtJE ihWw+bzAwM4pryMpknzrlKJLSDxeh09chu8cn5/cKYsr/WuKO51skCje2cRGONkFovCo DElneQzBlFfdJnoy1jITU6AVzWHJsOlA7nQiemDRoAZvU40Tdsmg5RcuaKOLuM5QiELd ym9ZYf9L1bdt95D9A2urkDWpspIcp4ovQMxdwIxg9LEzfRH+aYIfRVzf7YQ+iZB7ep9X o6hR7tEnYanGllsjab4EDwDLn+/7aNpRD4jIam2Bz0LQz+lAmkJEdUEEpKPeErw98PnJ qyag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778018039; x=1778622839; h=to:cc:date:message-id:subject:mime-version:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WIl8OCAgOzyDEFrCJSLwlUVwbWpfj3TuGMUQ/E6lf0M=; b=Gq2KeVHizAMgXtQtpLpDTa+cTFAKXQvyV2Q8so4KjxeWgButBNcgEqhiNRAXOVvRbp DDwf0X5utF08LzYUAXBTwcxHPzlFSfssU1Ez8pzH634MGLjcroyKN/13ta/OKgUngGLi j6eVgQpvsxy5WvN+fseBCL8oTyNxdwfeZV0A9iLciPS0y+OCr6ZYoa8pD+vTR89NvzyT 2urvpIlTwEKP018x5V5cWmRk4Z1r/30VfluBXCgKKJ6Aw1UrPVDtl4axcfcuC5XT+2fj t2xdy88gfMj03jpzTePnwytM6NsHBTj7G8RKKZDXG+yQshwwydKW30liLj/4wT8Gv+Po J3wg== X-Gm-Message-State: AOJu0YxKCcutFtqB1FjBeg7K8Kgl1KeBCpdo7bn8S9BjiC0FV++e24X+ xBe6nI3r9AEnPSsZ59PtopvDJDetT3tE/ei8YMiseasDgbJuziUOQvI1SotQBA== X-Gm-Gg: AeBDiesYy7NBAlJ/+zh/K/IWiv29o/HFXnwCphcDwj1GdrzzpG5uCtP3JCtOQPmk/WO tAHOJVuCCAr7rNpry1fPV53HGHr7dZ8REoPMZ3MwnDS9ZZK24sV86GOd8UCayOAWURx6+iRkAZz P9qloU8+Z/hsY1iE717ltEZFdis5PlFmOkWkiJk0xR1Mx7NspgAzl2iNJ2M+XlMPJ86IEmxSzh5 YbRvIp4CIJJdqQH0O1b2xpdZevM2iVFGuitDHTkB5pbFjBDzw6GiJpoNITIFTbBdKx3EsL8leUc TkT/apTdjXqdCTqqr8Q9ocuBj8pd2WtUO2mtR3I0aO+AIkLfYLGj0X3q7+/qS88KnkMHSnZwN16 yaFATVFq/QLfFFhCi0NO4CPqJtA/mZMk3hbZN1DXSWWdbHQS+iZagBRYG1epFv42aQtWLgpfcEY R0Aqu7lzzuZqzFS6rebabkVUWUSLk4+kGHA0V42Gff/grH1GdOAcWgFxRxPltO9QfeGnEtdShWS BF3jgjTF+jizhBUU5HOx+HohFJL X-Received: by 2002:a05:600c:8218:b0:48a:6798:52e9 with SMTP id 5b1f17b1804b1-48e51dd386fmr18000295e9.0.1778018038374; Tue, 05 May 2026 14:53:58 -0700 (PDT) Received: from smtpclient.apple (c-67-180-189-3.hsd1.ca.comcast.net. [67.180.189.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a82301adesm418347775e9.10.2026.05.05.14.53.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2026 14:53:57 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_C1AA5160-6821-4DD7-8C48-D2BC1C52F81E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\)) Message-Id: <4988194F-6242-4849-BE0F-DC47C9642662@gmail.com> Date: Tue, 5 May 2026 14:53:44 -0700 To: draft-ietf-v6ops-framework-md-ipv6only-underlay.all@ietf.org X-Mailer: Apple Mail (2.3731.700.6.1.21) Message-ID-Hash: EYMHHLZ5ECP4MOQWMQN2BL7QFZ65PNB5 X-Message-ID-Hash: EYMHHLZ5ECP4MOQWMQN2BL7QFZ65PNB5 X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: srv6ops@ietf.org, ops-ads X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSRv6OPS=5D_AD_review_of_draft-ietf-v6ops-framework-md-ipv6only-?= =?utf-8?q?underlay-20?= List-Id: "SRv6 Operations (SRv6OPS) Working Group List" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_C1AA5160-6821-4DD7-8C48-D2BC1C52F81E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=20 192.0.2.33, the result as 2001:db8::192.0.2.33. This representation=20 places the IPv4 address at bits 96=E2=80=93127 (the last 32 bits). However, RFC 6052 Section 2.2 places the IPv4 address at different=20 bit positions depending on prefix length: Prefix Length IPv4 address bits /32 32=E2=80=9363 /40 40=E2=80=9363, 72=E2=80=9379 /48 48=E2=80=9363, 72=E2=80=9387 /56 56=E2=80=9363, 72=E2=80=9395 /64 72=E2=80=93103 /96 96=E2=80=93127 Only for /96 does RFC 6052 place IPv4 in the last 32 bits. For all=20 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=20 (different for each prefix length). This maintains RFC 7915 = compatibility. (b) Restrict the framework to /96 prefix lengths for translation use=20 cases, and explicitly note that non-/96 prefix lengths are only valid=20 for encapsulation. (c) Explicitly describe a simplified mapping scheme (IPv4 always at=20 bits 96=E2=80=93127) and note that this diverges from RFC 6052 for = non-/96 prefixes,=20 and that encapsulation (not translation) must be used for non-/96 = prefixes. Option (a) aligns best with the stated RFC 6052 compliance, but changes=20= the examples significantly. Option (b) or (c) maintains the simpler = model=20 but requires additional text. Any of these is acceptable, but the = current=20 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=20 framework. It should be moved to informative references. Other RFCs=20 cited, including RFC 6333 (DS-Lite), RFC 7597 (MAP-E), and=20 RFC 7599 (MAP-T) =E2=80=94 they are in the informative section already,=20= but RFC 6877 was left in normative section. Section 1, paragraph 3 > Unless otherwise stated, the term =E2=80=9CIPv6-only network=E2=80=9D= in this > document refers specifically to =E2=80=9CIPv6-only underlay = network=E2=80=9D. 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=20 that constitute a control plane (e.g., routing adjacencies over=20 the tunnel). The real distinction is that this framework includes a=20 specific mechanism for distributing IPv4-to-IPv6 mapping rules=20 across domains. Can this sentence be restated for the actual=20 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=20= VPNs. The PE concept in this document is used in a broader underlay=20 routing context that does not have VPN semantics. Two options: Define PE directly in the terminology section (recommended for clarity),=20= and move RFC 4026 to informative. Or explain why the VPN-context definition from RFC 4026 is the right one = to=20 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=20= progress (at -05 as of December 2025). It should be noted that the=20 framework cannot be fully deployed until the address mapping rule = exchange=20 mechanism is standardized, and that [I-D.ietf-idr-mpbgp-extension-4map6]=20= represents the current leading candidate for that mechanism. Similarly,=20= [I-D.ietf-sidrops-moa-profile], referenced in Section 7.2 for security=20= mitigations, is also still in progress =E2=80=94 its status should be = noted. Section 5.1, paragraph 4 > 2. Packet Conversion >=20 > * Generate IPv4-embedded IPv6 packets using either translation or > encapsulation This sub-section covers only ingress behavior (generating IPv6 packets=20= from IPv4). The equally important egress behavior (converting IPv6 back=20= to IPv4) is not listed here. It's described later in Section 5.3 but=20 omitted from this overview list. Please add egress packet conversion=20 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=20 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=20 packets are encapsulated in IPv6, the encapsulated packet is=20 40 bytes larger than the original. When translated, the IPv6 header=20 is 20 bytes larger than the IPv4 header. In a multi-domain network=20 traversing multiple ASes, MTU differences between domains can cause=20 silent packet drops or performance degradation. This is a fundamental=20 operational concern for any IPv4-over-IPv6 framework. The document=20 should at minimum note that deployers need to handle MTU/fragmentation = =E2=80=94=20 for example, by configuring appropriate MSS clamping, ensuring=20 consistent MTU across domains, or following the recommendations in=20 RFC 7915 Section 1.4 for general MTU/fragmentation handling and Section 4.2/5.2 for specific ICMP translation handling. The absence=20 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 mjethanandani@gmail.com --Apple-Mail=_C1AA5160-6821-4DD7-8C48-D2BC1C52F81E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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:<= /div>

Section 4.1, paragraph 8
> =   =  +-------------------+------------+--------------------------+
<= div>>    |IPv6 mapping prefix|IPv4 address|IPv4-embedded = IPv6 address|
>   =  +-------------------+------------+--------------------------+
<= div>>    |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  |
>   =  +-------------------+------------+--------------------------+
<= div>>     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=E2=80=93127 (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=E2=80=9363
/40 =     40=E2=80=9363, 72=E2=80=9379
/48     = 48=E2=80=9363, 72=E2=80=9387
/56     56=E2=80=9363, = 72=E2=80=9395
/64     72=E2=80=93103
/96 =     96=E2=80=93127

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=E2=80=93127) 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) =E2=80=94 they are in the = informative section already, 
but RFC 6877 was left in = normative section.

Section 1, paragraph = 3
>    Unless otherwise stated, the term = =E2=80=9CIPv6-only network=E2=80=9D in this
>   =  document refers specifically to =E2=80=9CIPv6-only underlay = network=E2=80=9D. 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 =E2=80=94 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 =E2=80=94 
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
mjethanandani@gmail.com

<= br class=3D"Apple-interchange-newline">




= --Apple-Mail=_C1AA5160-6821-4DD7-8C48-D2BC1C52F81E--