[v6ops] Fw: I-D Action: draft-ietf-v6ops-framework-md-ipv6only-underlay-15.txt

[Chongfeng Xie <[e-mail]>]

Hi  all,

Based on the comments of Xipeng, we have submitted a new version of draft-ietf-v6ops-framework-md-ipv6only-underlay, the new revisions include,

[Xipeng]: Value proposition is now clear but can be better stated
This approach is different from existing “IPv4 over IPv6” solutions such as MPLS/SRv6 VPNs in that this approach can work across multiple Network Providers (NPs) while MPLS/SRv6 VPNs are single-NP solutions.
This approach is different from “IPinIP” tunneling in that this approach includes a control plane while “IPinIP” doesn’t have a control plane
I suggest you make these 2 points clear in the abstract
 
[Chongfeng]:  The two points are important, they have been added to the introduction section.  Also, the sentence below has been added to the abstract,
“This framework is not meant to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them.”
 
[Xipeng]:  A few technical issues
Section 9.1: is the egress PE being attacked here?  I think it just processes and forwards packets as usual.  Whether the packets are faked or not is not its business.  If you think that the egress PE is being attacked by forwarding faked packets, then all other routers forwarding the faked packets should be considered attacked as well.
“Since the PE in this framework is stateless, the effect of the attack is limited.” – the logic is not clear
 
[Chongfeng]: This illustrates a potential attack scenario (albeit with low probability of occurrence) where, by knowing the IPv6 mapping prefix of a specific egress PE, one or more malicious ingress PEs may intentionally flood that egress PE with substantial traffic in attempt to launch an attack. In this situation, the egress PE would experience increased traffic volume, and intermediate routers along the path might also see elevated traffic loads. However, as you mentioned, they just process and forward packets as usual, Moreover, since the egress PE is stateless, even when receiving massive traffic flows, it won't increase mapping session counts within the device like stateful NAT equipment would, thus avoiding significant consequences.
 
Based on the analysis above, the section of "Authenticity and Integrity of Packets" has been changed to make it more clear.
 
[Xipeng]:  Section 9.2: I think wording in this section needs improvement:
                i.     “The framework allows BGP to propagate mapping rule information over an IPv6-only underlay network”: not just over an IPv6-only underlay network
[Chongfeng]: This has been changed to “The framework allows BGP to propagate mapping information over an IPv6-only network”
              ii.     “BGP is vulnerable to traffic diversion attacks”: I think it’s the network that is vulnerable, not BGP
[Chongfeng]: This has been changed to “However, BGP has inherent vulnerability, such as route hijacking”
             iii.     “Such an attack differs from pre-existing vulnerabilities” and “The security issues already exist in BGP-4 and MP-BGP for IPv6, the same security mechanisms are applicable” seem contradictory
[Chongfeng]: This section has been changed to make it more clear,
“When the capability to advertise address mapping rules via BGP is introduced, attackers may alter the IPv6 mapping prefix within these rules, leading to improper delivery of IPv4 service traffic over IPv6-only network. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a remote target across an intervening network infrastructure (e.g., an IPv6 core), allowing an attack to potentially succeed more easily since less infrastructure needs to be compromised. To mitigate this risk, proposes an approach by leveraging RPKI architecture to verify the authenticity of the address mapping rule associated with an IPv4 address block.”
”
Accordingly, I-D.ietf-sidrops-moa-profile and RFC6480 added as informative references
 
[Xipeng]:  Some editorial issues
Abstract: “in an multi-domain” -> “in a multi-domain”
MAP-E cites RFC6333 but that’s DS-Lite, should cite RFC7597
Section 6.3, “Otherwise, it the egress PE extracts”: delete “it”,  “decapsulation it” -> “decapsulates it”
Section 6.3, “Encapsulation” part: still cites RFC7915 which is about “translation” – is it correct?
[Chongfeng]: Yes. Encapsulation uses the same packet header translation approach to translation. Nevertheless, this sentence is removed to avoid any unnecessary misunderstanding. 
Suggest “Network N1” -> “NP1” to be consistent with Figure 1
Suggest “MD: Mapping rule Database” -> “MR-DB” in the terminology section, and change 2 instances of “MD database” in the draft to “MR-DB”.  Otherwise, people may feel that “MD database” is undefined.
 
[Chongfeng]: These issues have been addressed.
 
[Xipeng]: Readability
Overall I think the draft is readable, but can be simplified
i.               Section 3 is not essential to the draft.  Could be deleted;
[Chongfeng]: It has been deleted.
 
ii.              Section 6, especially Figure 3, looks more like implementation details.  Does a framework draft need it?
 
[Chongfeng]: The implementation details and the figure 3 have been removed. The remaining part mainly introduces the architecture through functional description. 
 
             iii.     Section 8 “Applicability of SRv6 for Multi-domain IPv6-only Network” – why singling out “SRv6”?  I know you added this section based on request of another commenter, but this section appears out-of-nowhere to me.  If you already explain the difference between your approach and SRv6/MPLS VPN, I don’t think you need this section any more.
 
[Chongfeng]: This has been removed.
 
I suggest you use Duolingal or some LLMs to further improve readability/grammar.
[Chongfeng]: Good suggestion, LLM tool has been used to check and improve the documents. 
 
[Chongfeng]: Some unused terms have been removed from terminology section.
Some RFCs have been removed from the informative reference section.

Best regards
Chongfeng
On behalf of all the co-authors







[e-mail]
 
From: internet-drafts
Date: 2025-11-27 16:13
To: [e-mail]
CC: v6ops
Subject: [v6ops] I-D Action: draft-ietf-v6ops-framework-md-ipv6only-underlay-15.txt
Internet-Draft draft-ietf-v6ops-framework-md-ipv6only-underlay-15.txt is now
available. It is a work item of the IPv6 Operations (V6OPS) WG of the IETF.
 
   Title:   Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
   Authors: Chongfeng Xie
            Chenhao Ma
            Xing Li
            Gyan Mishra
            Thomas Graf
   Name:    draft-ietf-v6ops-framework-md-ipv6only-underlay-15.txt
   Pages:   19
   Dates:   2025-11-27
 
Abstract:
 
   For the IPv6 transition, IPv6-only is considered the final stage
   where only IPv6 protocol is used for transport while maintaining
   global reachability for both IPv6 and IPv4 services.  This document
   introduces a framework for a multi-domain IPv6-only underlay network
   from the perspective of network operators.  In particular, it
   proposes stateless address mapping as the basis for enabling IPv4
   service data transmission in a multi-domain IPv6-only environment
   (i.e., IPv4-as-a-Service).  It describes the methodology of stateless
   IPv4/IPv6 mapping, illustrates the behaviors of network devices,
   analyzes the options of IPv6 mapping prefix allocation, and discusses
   the security considerations.  This framework is not intended to
   replace existing IPv6-only technologies, but rather to leverage or
   remain compatible with them.
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/
 
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-framework-md-ipv6only-underlay-15
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-framework-md-ipv6only-underlay-15
 
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
 
 
_______________________________________________
v6ops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]