IPv6 Support Within IETF protocol work
draft-george-ipv6-support-00

Abstract

Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document recommends that IETF formally require protocol work to be IP version agnostic or to explicitly include support for IPv6, with some exceptions.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 31, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 1.2. Terminology
• 2. Requirements and Recommendation
• 3. Acknowledgements
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

[I-D.ietf-intarea-ipv6-required] gives guidance to implementers that IP-capable devices need to support IPv6, because global IPv4 exhaustion creates many circumstances where the use of IPv6 will no longer be optional.

In the above draft, IETF is making the recommendation that IP-capable devices need to support IPv6. Therefore, it is imperative that the protocols that result from IETF work enable implementers to follow that recommendation. This document provides explicit recommendations and guidance as to how IETF itself should handle future work to ensure that it can meet the requirements of [I-D.ietf-intarea-ipv6-required], especially "SHOULD NOT require IPv4 for proper and complete operation."

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.2. Terminology

There are several terms used by this document and other standards work which have commonly-accepted meanings, but are not necessarily defined within IETF's current body of documents. Because this draft is recommending that exceptions are made for certain areas of IETF work, the authors felt it necessary to formally define these terms for improved clarity.

• IPv4-IPv6 Transition – network technologies that offer IPv6 support over an IPv4 network (e.g. 6in4 [RFC4213], ISATAP [RFC5214], 6RD [RFC5969], etc.)
• IPv4-IPv6 Coexistence – network technologies (e.g. DSLite [I-D.ietf-softwire-dual-stack-lite], CGN [RFC6264], etc.) that maintain support for legacy IPv4 devices and applications after IPv4 exhaustion.
• IPv4-IPv6 Interworking – network technologies (e.g. NAT64 [RFC6146]) that allow IPv6-only devices to communicate with IPv4-only devices
• IP version agnostic - the idea that the implementation is at a higher layer than IP (layer 3) and therefore the use of IPv4 or IPv6 at the Network Layer should be transparent to the upper-layer implementation or protocol.
• IPv4-IPv6 Feature parity - the absence of 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 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 feature parity will begin to swing in the other direction as the decision is made not to implement certain features and protocols in IPv4.

Additional terminology can be found in [I-D.arkko-ipv6-transition-guidelines]

[Authors' note: These are strawman definitions, probably need to be wordsmithed further. Also, we were unable to find an existing draft or RFC which defines these terms. If one exists, we are happy to reference that instead.]

It is important to note that the protocols listed in this section are merely examples, and this is not intended to be an exhaustive list of the applications of each term. Ultimately the decision as to whether an IETF WG, protocol, or draft should remain focused primarily or exclusively on IPv4 remains with the appropriate ADs.

2. Requirements and Recommendation

• Within the IETF, further development on protocols and applications that are IPv4 only SHOULD cease, except to address vital operational or security issues, to maintain support for existing IPv4-only applications during the transition to IPv6, or to update the protocol or application to support IPv6.
• This will enable IETF WGs to concentrate on work that is either IP version agnostic, explicitly supports both IPv4 and IPv6, or in some cases, targets only IPv6. The goal is to ensure IPv4-IPv6 feature parity in most cases, and enable networks to operate seamlessly in any combination of IPv4-only, dual-stack, or IPv6-only as their needs dictate.
• New features and protocols SHOULD NOT be introduced for use as IPv4-only unless they are specifically in support of IPv4-IPv6 transition, IPv4-IPv6 coexistence or IPv4-IPv6 interworking.
• 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 the goals of IPv4-IPv6 feature parity and elimination of any remaining places in IETF standards and protocols where IPv4 is required for complete and proper function.
• Put another way:
• IETF SHOULD continue to update IPv4-only protocols and features for vital operational or security issues.
• IETF work SHOULD continue on IPv4-IPv6 transition and IPv4-IPv6 coexistence technologies as necessary.
• IETF work that is not related to the above exceptions MUST be IP version agnostic or MUST explicitly support IPv6.
• IETF work SHOULD continue to update IPv4-only protocols and applications to support IPv6 as necessary and appropriate.
• 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.

3. Acknowledgements

Thanks to the following people for their comments: Jari Arkko, Scott Brim, Margaret Wasserman

4. IANA Considerations

This memo includes no request to IANA.

5. Security Considerations

This document generates no new security considerations because it is not defining a new protocol. However, it is important to note that the recommendations above to stop work on IPv4-only protocols and applications include an exception for fixes to critical security issues. The definition of critical in this context will be left to the appropriate ADs, but while IPv4 is still in wide use, it is expected that these exceptions will occur from time to time.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses