IPv6 Operations (v6ops) Internet Drafts


      
 Operational Issues with Processing of the Hop-by-Hop Options Header
 
 draft-ietf-v6ops-hbh-10.txt
 Date: 16/02/2024
 Authors: Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra
 Working Group: IPv6 Operations (v6ops)
This document describes the processing of the Hop-by-Hop Options Header (HBH) in current routers in the aspects of standards specification, common implementations, and default operations. This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how HBH Options Header could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The purpose of this draft is to document reasons why HBH Options Header is rarely used within networks. It motivates the benefits and requirements needed to enable wider use of HBH Options.
 Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Issues and Simplify IPv6 First-hops
 
 draft-ietf-v6ops-nd-considerations-03.txt
 Date: 04/03/2024
 Authors: XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, Nick Buraglio
 Working Group: IPv6 Operations (v6ops)
Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses multicast extensively and trusts all hosts. In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable. Consequently, ND has potential issues in various scenarios. The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview is useful. This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference. Analyzing these solutions reveals an insight: isolating hosts is effective in preventing ND issues. Five isolation methods are proposed and their applicability is discussed. Guidelines are described for selecting a suitable isolation method based on the deployment scenario. When ND issues are prevented with a proper isolation method, the solutions for these issues are not needed. This simplifies the IPv6 first- hops.
 Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
 
 draft-ietf-v6ops-framework-md-ipv6only-underlay-04.txt
 Date: 04/02/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 service(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. The document also discusses related security considerations.
 Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks
 
 draft-ietf-v6ops-dhcp-pd-per-device-08.txt
 Date: 03/04/2024
 Authors: Lorenzo Colitti, Jen Linkova, Xiao Ma
 Working Group: IPv6 Operations (v6ops)
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD, RFC8415).
 Expanding the IPv6 Documentation Space
 
 draft-ietf-v6ops-rfc3849-update-01.txt
 Date: 14/11/2023
 Authors: Geoff Huston, Nick Buraglio
 Working Group: IPv6 Operations (v6ops)
The document describes the reservation of an additional IPv6 address prefix for use in documentation. The reservation of a /20 prefix allows documented examples to reflect a broader range of realistic current deployment scenarios.
 IPv6-only Capable Resolvers Utilising NAT64
 
 draft-ietf-v6ops-ipv6-only-resolver-00.txt
 Date: 23/10/2023
 Authors: Momoka Yamamoto, Yasunobu Toyota
 Working Group: IPv6 Operations (v6ops)
This document outlines how IPv6-only iterative resolvers can use stateful NAT64 to establish communications with IPv4-only authoritative servers. It outlines a mechanism for translating the IPv4 addresses of authoritative servers to IPv6 addresses to initiate communications. Through the mechanism of IPv4-to-IPv6 address translation, these resolvers can operate in an IPv6-only network environment.
 IPv6 CE Routers LAN Prefix Delegation
 
 draft-ietf-v6ops-cpe-lan-pd-00.txt
 Date: 02/03/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.


data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

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
Issue tracker
Wiki
Zulip Stream
Personnel Chairs Nick Buraglio, Ron Bonica, XiPeng Xiao
Area Director Warren "Ace" Kumari
Tech Advisor Fred Baker
Delegates Éric Vyncke, Robert Wilton, 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
Jul 2019 Recommendations for DNS in an IPv6 Network

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