IPv6 Operations (v6ops) Internet Drafts

      
 Considerations For Using Unique Local Addresses
 
 draft-ietf-v6ops-ula-usage-considerations-05.txt
 Date: 11/12/2024
 Authors: Sheng Jiang, Bing Liu, Nick Buraglio
 Working Group: IPv6 Operations (v6ops)
 This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them.
 Neighbor Discovery Considerations in IPv6 Deployments
 
 draft-ietf-v6ops-nd-considerations-08.txt
 Date: 03/12/2024
 Authors: XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, Nick Buraglio
 Working Group: IPv6 Operations (v6ops)
 Neighbor Discovery (ND) is a critical part of IPv6. ND uses multicast extensively and trusts all hosts. In some scenarios, such as wireless networks, multicast can be inefficient. In other scenarios, such as public access networks, hosts may not be trustworthy. Consequently, ND can have issues in some scenarios. The issues and mitigation solutions are documented in more than 20 RFCs, making it challenging to track all these issues and solutions. Therefore, an overview document is helpful. This document first summarizes the published ND issues and the solutions. This provides a one-stop reference. This document then analyzes these mitigation solutions to reveal that isolating hosts into different subnets or links can help prevent ND issues. Three isolation methods and their applicability are described. A simple guideline 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-08.txt
 Date: 17/10/2024
 Authors: Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Mohamed Boucadair, Thomas Graf
 Working Group: IPv6 Operations (v6ops)
 For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 services(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in one multi- domain underlay network. It lists the requirements of service traffic, illustrates major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery from the perspective of network operation. The document also discusses related security considerations.
 Use of the IPv6 Flow Label for WLCG Packet Marking
 
 draft-cc-v6ops-wlcg-flow-label-marking-03.txt
 Date: 03/07/2024
 Authors: Dale Carder, Tim Chown, Shawn McKee, Marian Babik
 Working Group: IPv6 Operations (v6ops)
 This document describes an experimentally deployed approach currently used within the Worldwide Large Hadron Collider Computing Grid (WLCG) to mark packets with their project (experiment) and application. The marking uses the 20-bit IPv6 Flow Label in each packet, with 15 bits used for semantics (community and activity) and 5 bits for entropy. Alternatives, in particular use of IPv6 Extension Headers (EH), were considered but found to not be practical. The WLCG is one of the largest worldwide research communities and has adopted IPv6 heavily for movement of many hundreds of PB of data annually, with the ultimate goal of running IPv6 only.
 IPv6 CE Routers LAN Prefix Delegation
 
 draft-ietf-v6ops-cpe-lan-pd-05.txt
 Date: 18/10/2024
 Authors: Timothy Winters
 Working Group: IPv6 Operations (v6ops)
 This document defines requirements for IPv6 CE Routers to support DHCPv6 Prefix Delegation for redistributing any unused prefix(es) that were delegated to the IPv6 CE Router. This document updates RFC 7084.
 464XLAT Customer-side Translator (CLAT): Node Recommendations
 
 draft-ietf-v6ops-claton-02.txt
 Date: 21/10/2024
 Authors: Jen Linkova, Tommy Jensen
 Working Group: IPv6 Operations (v6ops)
 464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions.
 IPv6-Mostly Networks: Deployment and Operations Considerations
 
 draft-ietf-v6ops-6mops-00.txt
 Date: 16/10/2024
 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-01.txt
 Date: 21/10/2024
 Authors: Gabor Lencse, Jordi Martinez, 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.

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-05 Approved
Document dependencies
Additional resources GitHub
Wiki, Zulip Stream
Personnel Chairs Nick Buraglio, Ron Bonica, XiPeng Xiao
Area Director Warren "Ace" Kumari
Tech Advisor Fred Baker
Delegates Éric Vyncke, Warren "Ace" Kumari
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 global deployment of IPv6 is underway, creating an Internet
consisting of IPv4-only, IPv6-only, IPv4-IPv6 dual-stack, and
IPv6+translation networks and nodes. This deployment must be properly
handled to avoid the division of the Internet into separate IPv4 and
IPv6 networks, ensuring addressing and connectivity for all IPv4 and
IPv6 nodes. IPv6 deployment has resulted in the shutdown of IPv4 in
some networks. Removing IPv4 constraints has resulted in innovations
in IPv6 network operations.

The IPv6 Operations Working Group (v6ops) develops guidelines for the
deployment and operation of new and existing IPv6 networks.

The goals of the v6ops working group are:

  1. Solicit input from network operators and users to identify
    operational issues with IPv6 networks, and determine solutions or
    workarounds to those issues.

  2. Solicit input from network operators and users to identify
    operational interaction issues with the IPv4 networks, and determine
    solutions or workarounds to those issues.

  3. Solicit discussion and documentation of the issues and opportunities
    in IPv6-only operation, and of the resulting innovations.

  4. Operational solutions for identified issues should be developed in
    v6ops and documented in informational or BCP drafts.

  5. Document operational requirements for IPv6 networks.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with IPv4
delivered as an overlay or translation service, or IPv6-only networks.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or
technologies. However, the v6ops Working Group may provide input to
those areas/groups, as needed, and cooperate with those areas/groups in
reviewing solutions to IPv6 operational and deployment problems.

Future work items within this scope will be adopted by the Working Group
only if there is a substantial expression of interest from the community
and if the work clearly does not fit elsewhere in the IETF.

There must be a continuous expression of interest for the Working Group
to work on a particular work item. If there is no longer sufficient
interest in the Working Group in a work item, the item may be removed
from the list of Working Group items.

Milestones

Date Milestone Associated documents
Dec 2026 Identify issues that prevent IPv6 traffic from becoming majority, and publish guidelines
Dec 2026 Publish BCP for enterprise IPv6 deployment
Jul 2026 Solicit IPv6-only deployment cases and publish BCP for IPv6-only
Jul 2026 Identify IPv6 issues that prevent H.E. from selecting IPv6 for Dual-Stack users, and publish operational solutions
Dec 2025 Update IPv6 CPE requirements (rfc7084-update)
Jul 2025 Publishing deployment and operations guidelines for IPv6-mostly
Dec 2024 Publish dhcp-pd, hbh, nd-considerations, rfc3849-update as RFCs

Done milestones

Date Milestone Associated documents
Done Recommendations regarding the use of DNS64
Done Update RFC 6555 with experience
Done Update RFC 7084 (IPv6 CE Requirements)
Done Prefix for use by IPv4/IPv6 translators in a network
Done File recommendation on how to build a commercial WiFi network