IPv6 Support Within IETF work

When considering support for IPv4 vs IPv6 within IETF work, the general goal is to provide tools that enable networks and applications to operate seamlessly in any combination of IPv4-only, dual-stack, or IPv6-only as their needs dictate. As IPv6 deployment grows, IETF will naturally focus on features and protocols that enhance and extend IPv6, along with continuing work on items that are IP version agnostic. New features and protocols will not typically be introduced for use as IPv4-only. However, as of this document's writing, there is no documented requirement for all IETF work to support IPv6, either implicitly by being network-layer agnostic or explicitly by having an IPv6-specific implementation. Due to the existing operational base of IPv4, it is not realistic to completely bar further work on IPv4 within the IETF at this time, nor to formally declare it historic. This draft is viewed as a first step in IPv4's eventual phase-out, in that it limits IPv4-specific activities within the IETF to a few key areas. Until the time when IPv4 is no longer in wide use and/or declared historic, the IETF needs to continue to update IPv4-only protocols and features for vital operational or security issues. Similarly, IETF needs to continue the work related to IPv4-to-IPv6 transition tools for migrating more traffic to IPv6. As the transition to IPv6-capable networks accelerates, it is also likely that some changes may be necessary in IPv4 protocols to facilitate decommissioning IPv4 in a way that does not create unacceptable impact to applications or users. These sorts of IPv4-focused activities should be allowed to continue, especially if they are accompanied by real operational experience documenting the problem to be solved. Generally, the IETF should be focused on two goals as it relates to IP version support: Transition technologies that enable IPv6 Complete support for IPv6-only operation It is helpful to clarify what the above statements mean. "Transition technologies" is a fairly broad term that can be interpreted in a lot of different ways. At its broadest, it includes providing IPv6 support over an IPv4 network and vice versa, methods to interwork IPv4-only devices and IPv6-only devices, as well as technologies to extend IPv4's life despite the lack of additional globally unique addresses to provide to hosts and networks. This document makes the distinction between those technologies which provide a path for an IPv4-only network to become dual-stack or otherwise use native IPv6, and those which primarily serve to extend the life of IPv4 while not providing a path to native IPv6 support on the network in question. The IETF needs to be focusing their work on transition mechanisms that provide progress toward native IPv6, are simple, stateless, and use mechanisms which preserve end-to-end connectivity as much as possible. While the eventual end state may be networks and end points that are IPv6-only, the timeframe for that to become a reality is likely to be different within each network. This means that there are multiple legitimate use cases for continued support for IPv4, including methods to translate between IPv4-only hosts and IPv6-only hosts, as well as methods for IPv4 address sharing in order to reduce the impact of IPv4 exhaustion on implementations that still use IPv4. The IETF has provided several soutions that have implementations to address the need to keep business running and users happy during this transition, including Dual Stack Lite RFC 6333, NAT64 RFC 6146, as well as Carrier Grade NAT ( and RFC 6264). As the above documents complete the IETF document lifecycle and become RFCs, and the BEHAVE WG closes after completion of its charter, this should comprise a body of solutions to meet the needs of the majority of IPv4's continued use cases such that work on additional protocols to extend the life of IPv4 no longer needs to be an area of focus for the IETF. [**authors' note, remove before publication**] This document is not intended to be yet another survey of available transition mechanisms, so the list above does not have to be exhaustive. The intent was to cite the most likely candidates for wide deployment as evidence that there exists a consensus solution for each major case. There are a number of other drafts that could be included in the above list of solutions, but as draft documents, they have not yet found consensus. For example, A+P is an Experimental RFC (6346), and its derivative works such as MAP (draft-mdt-softwire-mapping-address-and-port) and potentially 4rd- {E,T,U}, dIVI-PD, stateless 4over6, etc. are current internet-draft documents. Under the structure proposed in this document, a working group would need to find consensus on a problem statement, defining a real operational problem that the proposed solution would solve, before any proposed solution could be adopted as a WG item. [end author's note] It is not possible to document completely which technologies and drafts are and are not acceptable, so this document is intended to be a guideline for working groups and IESG members when evaluating new and existing work, rather than being an exhaustive list. There are corner cases and use cases for which the existing solutions may not be a perfect fit, as well as unsolved theoretical problems, but standardizing solutions for every possible permutation moves into the realm of diminishing returns, and solutions applicable only to one or two networks are best pursued between the operator and their vendors. Thus, further work on IPv4-extension protocols such as those mentioned MUST be triggered by a draft documenting actual operational experiences, focusing on problems encountered in deployment that the IETF needs to solve through protocol changes. This will ensure that IETF is focusing its energies on solving real operational problems that exist in IPv4 and transition technologies, rather than interesting theoretical problems, corner cases or new features. To put this set of guidelines succinctly: IETF SHOULD continue to update IPv4-only protocols and features to address vital operational or security issues. IETF work SHOULD update existing IPv4 to IPv6 transition and interworking technologies as necessary to address operational problems encountered during the implementation phase. IETF work SHOULD continue to make updates to IPv4 protocols and features to facilitate IPv4 decommissioning IETF work that is not related to the above exceptions MUST be IP version agnostic (because it is implemented above the network layer) or MUST explicitly support IPv6. IETF SHOULD NOT initiate new IPv4 extension technology development. IETF work MAY support IPv6-only applications and protocols, especially in cases where supporting the protocol or feature in IPv4 would be difficult or impossible. IETF work SHOULD continue to update IPv4-only protocols and applications to support IPv6 as necessary and appropriate. This last item raises a question about where feature parity between IPv4 and IPv6 fits into the discussion. In this context, feature parity ensures that there are no gaps where functionality exists in IPv4 but has no equivalent in IPv6. Note that this does not mean a direct 1:1 relationship where every feature that exists in IPv4 will exist in IPv6. This is because IPv6 eliminates the need for some features that exist in IPv4, IPv4 supports some legacy features that are no longer in use, and some existing IPv4 features are integrated into other parts of IPv6. In addition, as new features and implementations take advantage of the differences between IPv6 and IPv4, it is expected that IPv6 will surpass IPv4 and certain features and protocols will not have specific support for IPv4. A comprehensive list of needed parity items and enhancements for IPv6 is outside the scope of this document, but this document recommends that the charters and work items of currently active IETF Working Groups (WGs) be evaluated to ensure that they are supporting a goal to eliminate of any remaining places in IETF standards and protocols where IPv4 is required for complete and proper function, and that they do not focus on IPv4 extension technologies. This document does not suggest a timeline where this must be completed, as it will likely happen organically over a long period of time.