IPv6 Operations (v6ops) Internet Drafts

      
 Neighbor Discovery Considerations in IPv6 Deployments
 
 draft-ietf-v6ops-nd-considerations-14.txt
 Date: 26/05/2025
 Authors: XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, Nick Buraglio
 Working Group: IPv6 Operations (v6ops)
 The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than 20 RFCs. There is a need to track these issues and solutions in a single document. To that aim, this document summarizes the published ND issues and then describes how all these issues originate from three causes. Addressing the issues is made simpler by addressing the causes. This document also analyzes the mitigation solutions and demonstrates that isolating hosts into different subnets and links can help to address the three causes. Guidance is provided for selecting a suitable isolation method to prevent potential ND issues.
 Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
 
 draft-ietf-v6ops-framework-md-ipv6only-underlay-14.txt
 Date: 08/10/2025
 Authors: Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Thomas Graf
 Working Group: IPv6 Operations (v6ops)
 For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an 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, examines the utilization of SRv6, and discusses the security considerations.
 464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations
 
 draft-ietf-v6ops-claton-10.txt
 Date: 18/10/2025
 Authors: Lorenzo Colitti, Jen Linkova, Tommy Jensen
 Working Group: IPv6 Operations (v6ops)
 464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) by further defining CLAT node behavior and IPv6 Customer Edge Routers to Support IPv4-as-a-Service by providing recommendations for the node developers on enabling and disabling CLAT.
 IPv6-Mostly Networks: Deployment and Operations Considerations
 
 draft-ietf-v6ops-6mops-04.txt
 Date: 20/10/2025
 Authors: Nick Buraglio, Ondrej Caletka, Jen Linkova
 Working Group: IPv6 Operations (v6ops)
 This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc).
 Basic Requirements for IPv6 Customer Edge Routers
 
 draft-ietf-v6ops-rfc7084bis-04.txt
 Date: 20/10/2025
 Authors: Gabor Lencse, Jordi Martinez, Ben Patton, Timothy Winters
 Working Group: IPv6 Operations (v6ops)
 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084.
 Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)
 
 draft-ietf-v6ops-icmpext-xlat-v6only-source-00.txt
 Date: 04/07/2025
 Authors: David Lamparter, Jen Linkova
 Working Group: IPv6 Operations (v6ops)
 This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages.
 A recommendation for filtering address records in stub resolvers
 
 draft-ietf-v6ops-aaaa-filtering-00.txt
 Date: 16/10/2025
 Authors: Ondrej Caletka
 Working Group: IPv6 Operations (v6ops)
 Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network.

data-group-menu-data-url="/group/groupmenu.json">

IPv6 Operations (v6ops)

WG Name IPv6 Operations
Acronym v6ops
Area Operations and Management Area (ops)
State Active
Charter charter-ietf-v6ops-06 Approved
Document dependencies
Additional resources GitHub
Wiki, Zulip Stream
Personnel Chairs Nick Buraglio, XiPeng Xiao
Area Director Mohamed Boucadair
Tech Advisor Ron Bonica
Materials Managers Ron Bonica, XiPeng Xiao
Mailing list Address v6ops@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/v6ops
Archive https://mailarchive.ietf.org/arch/browse/v6ops/
Chat Room address https://zulip.ietf.org/#narrow/stream/v6ops

Charter for Working Group

The V6OPS Working Group (WG) facilitates the universal deployment of IPv6. It will focus on both IPv6 deployment and IPv6 traffic growth.

Also, V6OPS provides operators, including service providers, enterprises, and other organizations a venue to share IPv6 operational experience, challenges, and lessons learned, as well as other work within scope for the WG. Specifically, V6OPS is a venue to share reports on IPv6-related network monitoring experiments and applications that perform well in IPv4 networks but do not perform well in IPv6 networks, and vice versa.

Objectives

  • Publish Informational or BCP documents that provide IPv6 operational guidance in specific deployment contexts. For example, this includes:

    • Documents summarizing requirements and defining current practices for nodes, applications, and services adopting and operating over IPv6.

    • Documents that demonstrate how IPv6 can be deployed in a specific environment (data centers, enterprise networks, WAN, access networks, etc.).

    • Documents explaining IPv6's advantages over IPv4 (e.g., features that reduce operational complexity and improve reliability).

    • Use cases, transition strategies, and best practices that enable IPv6-only operation.

  • Publish Informational documents that identify obstacles to IPv6 deployment and IPv6 operational issues in general. Each document should describe the problem statement and include discussion of operational solutions, if any are available. These documents can be used as input to protocol-developing WGs. For example, this includes:

    • A study that compares the performance of existing IPv4 networks to the performance of existing IPv6 networks. When IPv6 networks do not perform as well as IPv4 networks and vice versa, identify the root causes if possible.

    • Use cases where dual-stack hosts prefer IPv4 or fail to utilize available IPv6 connectivity.

  • Maintain and specify Standards Track extensions to NAT64 (RFC 6146), Stateless IP/ICMP Translation Algorithm (SIIT, RFC 7915), IPv6 Addressing of IPv4/IPv6 Translators (RFC 6052), 464XLAT (RFC 6877), Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC, RFC 7755/RFC 7756), Explicit Address Mappings for Stateless IP/ICMP Translation (RFC 7757), and Stateless Source Address Mapping for ICMPv6 Packets (RFC 6791) (including, updating those published as Informational to Standards Track and Proposed Standard to Internet Standard).

WG Practices

In order to achieve these goals, the WG will work with regional network operators' groups and other IPv6 proponents. It will also interact with the HAPPY, SRV6OPS, and 6MAN WGs, exchanging information and being mindful of each WG's charter.

Occasionally, deployment issues will require protocol enhancements. Protocol enhancements are the responsibility of the WGs that developed the protocols, if such WGs are not concluded. However, the V6OPS WG may provide input to those WGs and cooperate with them in reviewing solutions to IPv6 deployment problems.

Milestones

Date Milestone Associated documents
Dec 2026 Adopt IPv4 Versus IPv6 Performance
Dec 2026 Adopt Deploying IPv6 in the WAN
Dec 2026 Adopt Deploying IPv6 in the Data Center
Dec 2026 Adopt Deploying IPv6 in the Enterprise
Dec 2026 Adopt Deploying IPv6 in the Access Network
Jun 2026 Submit "A Recommendation for Filtering Address Records in Stub Resolvers" to the IESG for publication as Informational RFC
Dec 2025 Submit "IPv6-Mostly Networks: Deployment and Operations Considerations" to the IESG for publication as Informational RFC draft-ietf-v6ops-6mops
Dec 2025 Submit Updated IPv6 CPE Requirements (rfc7084-update) to the IESG for publication as BCP draft-ietf-v6ops-rfc7084bis
Dec 2025 Submit "Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators" to the IESG for publication as Proposed Standard draft-ietf-v6ops-icmpext-xlat-v6only-source
Nov 2025 Submit "Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service" to the IESG for publication as Informational RFC draft-ietf-v6ops-framework-md-ipv6only-underlay
Oct 2025 Submit "464XLAT Customer-side Translator (CLAT): Node Recommendations" to the IESG for publication as Proposed Standard draft-ietf-v6ops-claton