Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
Schoen, et al. Expires 23 February 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-intarea-ietf-maintaining-ipv4-01
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
S.D. Schoen
IPv4 Unicast Extensions Project
J. Gilmore
IPv4 Unicast Extensions Project
D. Täht
IPv4 Unicast Extensions Project

The IETF Will Continue Maintaining IPv4

Abstract

This document confirms the consensus of the IETF that IETF and its affiliated working groups will continue to maintain the IPv4 protocol family.

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 https://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 23 February 2023.

Table of Contents

1. Introduction

It might seem surprising to imagine the IETF ceasing to maintain the IP version 4 protocol suite which it has led to worldwide success. However, just such a change has been advanced in the past. [ipv6-ietf], and the issue continues to produce confusion and uncertainty during discussions of unrelated technical questions.

This document explicitly confirms the IETF's prior practice of maintaining IPv4 in the interest of its user and implementer community, and affirms that doing so is the considered and continued consensus of the IETF.

IETF actions or inactions whose motivation or effect is to fail to maintain IPv4 disrupt the ordinary practice of IETF working groups and functions, and bear a burden of justification.

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].

2. The Evolution of the Internet

Since version 4 of the Internet Protocol (IPv4) was created as an experiment in 1981 in [RFC0791], the Internet has grown enormously to become a vital resource for humanity.

IPv4 is easily the most popular network-layer protocol in the world, carrying the majority of the world's commercial data traffic, as well as the majority of traffic on private intranets. For more than 40 years, the IPv4 protocol has formed the central common agreement that has enabled technologists, entrepreneurs, and policymakers to build a worldwide network-of-networks containing billions of nodes, and serving billions of users. Use of the IPv4 protocol remains a necessity for the vast majority of Internet nodes today.

The Internet has grown by many orders of magnitude in physical size, bandwidth, and traffic volume. It has increased dramatically in organizational, administrative, and operational complexity. With that growth, the original specifications and understandings underlying IPv4 and its related protocol suite have required adaptation and adjustment. Congestion control, security, address allocation, routing, and many other areas were adjusted gradually over time as the world gained experience in managing and growing a single worldwide network that puts every user only a few hundred milliseconds away from every other user. Most such adjustments have been done with gradual, compatible changes. On a few occasions, this adjustment required protocol changes in every node on the Internet, such as the transition to CIDR [RFC1519] in the 1990s, or in every node that supported a particular protocol, such as the removal for security reasons of SSL v3 in [RFC7568].

3. Internet Evolution and the IETF

To promote the reliability and stability of the Internet, the user and implementer base for IPv4 have gathered together for coordination, guidance in its use, and both technical and policy development and evolution. Since 1986, the Internet Engineering Task Force (IETF) has been the home of that community gathering.

Discussions in the IETF community have exposed a variety of attitudes toward the continued existence of IPv4 and toward occasions and circumstances in which the IETF is called upon to maintain, support, and coordinate the use of IPv4 and IPv4-based protocols. These occasions will likely continue to arise as the Internet continues to evolve.

This document confirms the consensus among IETF members and IETF leadership that the IETF will continue to maintain the IPv4 protocol suite.

4. Challenges to the IETF's Role as Maintainer of IPv4

Some IETF participants would prefer that the IETF act to hasten the day when IPv6 would completely replace IPv4. Others see an ongoing role for both protocols. These differing points of view play out in the IETF in various ways.

The most radical position the authors have encountered views some limitations and problems with IPv4 as actively beneficial, because its proponents view increased pain or cost of using IPv4 as encouraging people to adopt IPv6 as a substitute.

Holders of this position have suggested that the IETF should sometimes deliberately allow breakage or degradation in the IPv4 protocol. [nat-undocumented] Or that IETF should declare that IPv4 has "historic" status and should no longer be implemented.[v4historic] They may wish that IETF or some other body could take on the power to actively put an end to use or deployment of IPv4, much as the ARPA funding agency could compel all ARPANET hosts to switch from NCP to IPv4 protocols between 1981 and 1983 [RFC0801]; or how the Defense Communications Agency, as the source of funding for the ARPANET, physically took apart the ARPANET by 1990-02-28 in order to force its users (who were all using IPv4) to switch to connecting via the NSFnet or other more modern networks. [decommission-arpanet]

Other positions do not necessarily view problems with IPv4 as a good thing in themselves. But they promote the view that the total resources available for standardization, coordination, and/or implementation efforts, are inherently limited in such a way that doing any work related to the IPv4 protocol would cause less work to be done on the IPv6 protocol. Multiple people who seem to hold this position respond to requests to improve IPv4 with an objection that "we should not be improving IPv4; we should be deploying IPv6 instead".

The objection takes the form of a false dilemma; that is, it assumes that there are only two possible actions, and that taking one prevents the other from being taken. But in actual fact, it is possible to do neither, either, or both of those actions; they are unrelated. It is exceedingly unlikely that if this objection prevents someone from improving IPv4, as it did in 2008 during discussions of the unicast use of the 240/4 address block in the intarea Working Group [FLM], for example, that they would immediately turn their efforts to deploying IPv6. And most of the work required for increased deployment of IPv6 involves neither coordinating new standards nor implementing IPv6; IPv6 is already widely standardized and implemented.

Those expressing either of these views may worry that ongoing IPv4 work provides an "excuse" for decision makers, such as network operators, to delay IPv6 adoption, because they will seemingly perceive the IETF's blessing for doing so, because they will perceive IPv4 as not obsolete, or because specific technical problems they would otherwise encounter with IPv4 will be mitigated.

5. Neglecting IPv4 is Not Our Transition Strategy

A strong consensus exists to continue the IETF's work in support of IPv6 and to promote its adoption [RFC6540]. However, no consensus has been found to actively discourage IPv4. Instead, one serious attempt to form such a consensus was definitively rejected.

The IETF chartered a working group, "sunset4", which existed between 2012 and 2018. Its original remit included:

The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6.

The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed.

A year later, the charter was revised to say:

In order to fully transition the Internet to IPv6, individual applications, hosts, and networks that have enabled IPv6 must also be able to operate fully in the absence of IPv4. The Working Group will point out specific areas of concern, provide recommendations, and standardize protocols that facilitate the graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has been deployed. This includes the act of shutting down IPv4 itself, as well as the ability of IPv6-only portions of the Internet to continue to connect with portions of the Internet that remain IPv4-only.

A participant in this working group produced an Internet-Draft [v4historic] entitled "IPv4 Declared Historic", whose abstract was the single sentence, "IPv4 has been superseded by IPv6, and is therefore Historic." It stated:

The use of IPv4 is deprecated. The term "deprecated" is used to indicate a feature, characteristic, or practice that should be avoided, in this case because it is being superseded by a newer protocol. The term does not indicate that the practice is harmful, but that there will be no further development in IPv4...

This draft was discussed by the working group (with some of the results documented in its author's blog entry, [IPv4-NOT-Declared-Historic]. The working group's co-chair remarked on the mailing list, "That's part of the reason this discussion is happening - it's looking for rough consensus from the IETF that we are done making changes to IPv4." [wes-george-sunset4-2016-03-22] A later draft [ipv6-support] explicitly stated, "new functionality should be developed in IPv6, and IETF effort SHOULD NOT be spent retrofitting features into the legacy protocol."

Eventually an evolved draft [ipv6-ietf] went through a Working Group last call. The document was entitled "IETF: End Work on IPv4" and its abstract was:

The IETF will stop working on IPv4, except where needed to mitigate documented security issues, to facilitate the transition to IPv6, or to enable IPv4 decommissioning.

It specifically declared: "The IETF will not initiate new IPv4 extension technology development." The WG chair officially summarized it as a request for "IETF to stop working on IPv4 except for security issues." He noted that

The working group last call got strong support but only very few people participated in the last call. Given the relative inactivity of the working group for quite a while, it is possible that the mailing list is not watched. Given that this document has widespread implications to any work within IETF, the real wide review should be done IETF wide.

(Only three people had responded to the WG Last Call.) A Routing Directorate reviewer, Ron Bonica, reviewed it for the IESG, saying it "Needs Work", and noted, "Given that the majority of Internet traffic still runs over IPv4, is that a good idea?" as well as asking, "Does this mean that RFC 791 cannot be updated? Or does it mean more than this?"

The draft went through an IETF Last Call, and generated a lot of controversy. While some participants were supportive, other participants expressed concerns that the IETF was proposing to abdicate a vital responsibility for maintaining one of the most important and widely-used technologies in the world. If the IETF would not do this work, some suggested, other standards-development organizations would be compelled to take it up instead -- but they would likely be less qualified to do so because they would have far less historic expertise and experience with the technology, and would also not necessarily share other IETF values such as openness. The result was that the draft expired without attaining IETF-wide consensus. The IESG counted this as a rejection.

This history demonstrates that there was no IETF-wide consensus to neglect the maintenance of IPv4. However, it did not demonstrate the opposite consensus either, but left that question for a later day.

This document is in some sense that opposite proposal, demonstrating that there IS an IETF-wide consensus to continue to maintain IPv4.

6. IPv4 Requires Ongoing Maintenance

As a protocol in use in billions of nodes, IPv4 continues to evolve. New situations and new realizations have resulted in numerous proposals for protocol modifications that have reached consensus in the recent past. Below are several examples of recent IETF work that contributed to this evolution. Each one identifies the IETF working group in which it was approved.

In recent years, various other draft proposals did not reach consensus, partly due to confusion about the proper role of the IETF in working on IPv4-related protocols. Had this IPv4-maintenance issue been resolved independently, as proposed in this document, those proposals would have had a better chance of reaching consensus on their technical merits, rather than being pulled into unrelated issues about IPv4 versus IPv6.

In addition, various errata have been noted in the IPv4 standards, including significant technical errors in [RFC0791] noted in 2016 and 2021.

7. The IETF is Uniquely Positioned to Maintain IPv4

The Internet Engineering Task Force (IETF) was initially an informal work group of government-funded grant recipients involved with building the Internet technologies. It has grown into a major standards development organization, while retaining its traditional values such as transparency, consensus, and informality. As changes in protocol specifications and operational practices have been needed, the IETF has provided a forum where these can be discussed, agreed upon, and publicized.

Implementers and operators care a great deal about the IETF's recommendation for the technologies that were developed here, and questions affecting interoperability in IPv4 continue to arise. There is no other organization that would be as clearly empowered to do this work as the IETF. If the IETF actively neglected to coordinate IPv4 work, it would squander some of the trust that the community places in it.

While predicting is hard, especially about the future, decades of experience suggest that the IPv4 and IPv6 protocols will continue to co-exist for the foreseeable future. Increased IPv6 adoption by individual sites does not typically eliminate those sites' need for continued use of IPv4 services in reaching parts of the Internet that do not use IPv6. In addition, even if IPv6 soon becomes the predominant network-layer protocol on the global Internet, IPv4 is likely to remain important on LANs and private networks, with corresponding needs for suppliers and operators to continue to coordinate interoperability.

Implementers and operators continue to look to the IETF as the authority for IPv4 standardization efforts. The IETF is better-positioned than any other organization to play this role both because of its conspicuous position in evolving IPv4 and IPv6, and because of its deep institutional knowledge and broadly representative participation model.

Since IPv4 is still the world's most-used networking protocol, many parties will look for a standards-development organization to coordinate its ongoing standardization and to maximize interoperability among systems using it. Though the IETF could attempt to make IPv4 less attractive by deprecating it or refusing to maintain it, it's not clear that this course of action would lead to faster IPv6 adoption. Instead, it might encourage non-IETF organizations to take up responsibility for IPv4's maintenance, which could lead to IPv4 being a stronger competitor against IPv6, or greater fragmentation in Internet standards development, as the location of the authority to define and coordinate IPv4 would no longer be clear.

8. The IETF Continues to Support IPv4 as Well as IPv6

There are many reasons to encourage IPv6 adoption and support everywhere on the Internet. This document does not change the IETF's policy in favor of IPv6, but merely makes it clear that the IETF intends to continue fully maintaining and supporting IPv4, in addition to continuing the promotion and evolution of IPv6.

9. IANA Considerations

This document makes no change to IANA's existing role in providing and maintaining IPv4-related registries.

10. Security Considerations

The IETF's ongoing responsibility for IPv4 includes remaining apprised of emerging security threats to IPv4 users and applications, and developing or publicizing guidance for how to mitigate these threats. In some cases, the IETF may modify existing and deployed protocols as required or useful in adjusting to security concerns. [RFC2644]

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6540]
George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, , <https://www.rfc-editor.org/info/rfc6540>.

11.2. Informative References

[decommission-arpanet]
Living Internet, "NSFNET -- National Science Foundation Network", <https://livinginternet.com/i/ii_nsfnet.htm>.
[FLM]
Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 as usable unicast address space", Work in Progress, Internet-Draft, draft-fuller-240space-02, , <https://datatracker.ietf.org/doc/html/draft-fuller-240space-02>.
[IPv4-NOT-Declared-Historic]
Howard, L., "IPv4 NOT Declared Historic", , <https://web.archive.org/web/20200708045029/http://www.wleecoyote.com/blog/ietf95-sunset4.htm>.
[ipv6-ietf]
Howard, L., "IETF: End Work on IPv4", Work in Progress, Internet-Draft, draft-ietf-sunset4-ipv6-ietf-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-ipv6-ietf-01>.
[ipv6-support]
George, W. and L. Howard, "IPv6 Support Within IETF work", Work in Progress, Internet-Draft, draft-george-ipv6-support-03, , <https://datatracker.ietf.org/doc/html/draft-george-ipv6-support-03>.
[nat-undocumented]
Perlman, R., "Keynote: Do the Wrong Thing! (starting from 41:50 within the presentation)", , <https://www.youtube.com/watch?v=5D1v42nw25E>.
[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/info/rfc791>.
[RFC0801]
Postel, J., "NCP/TCP transition plan", RFC 801, DOI 10.17487/RFC0801, , <https://www.rfc-editor.org/info/rfc801>.
[RFC1519]
Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, , <https://www.rfc-editor.org/info/rfc1519>.
[RFC2644]
Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, , <https://www.rfc-editor.org/info/rfc2644>.
[RFC5966]
Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, , <https://www.rfc-editor.org/info/rfc5966>.
[RFC6093]
Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, , <https://www.rfc-editor.org/info/rfc6093>.
[RFC6298]
Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, , <https://www.rfc-editor.org/info/rfc6298>.
[RFC6528]
Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, , <https://www.rfc-editor.org/info/rfc6528>.
[RFC6633]
Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, , <https://www.rfc-editor.org/info/rfc6633>.
[RFC6762]
Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, , <https://www.rfc-editor.org/info/rfc6762>.
[RFC6864]
Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, , <https://www.rfc-editor.org/info/rfc6864>.
[RFC6918]
Gont, F. and C. Pignataro, "Formally Deprecating Some ICMPv4 Message Types", RFC 6918, DOI 10.17487/RFC6918, , <https://www.rfc-editor.org/info/rfc6918>.
[RFC7413]
Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, , <https://www.rfc-editor.org/info/rfc7413>.
[RFC7568]
Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, , <https://www.rfc-editor.org/info/rfc7568>.
[RFC7766]
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, , <https://www.rfc-editor.org/info/rfc7766>.
[RFC8029]
Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, , <https://www.rfc-editor.org/info/rfc8029>.
[RFC8815]
Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, "Deprecating Any-Source Multicast (ASM) for Interdomain Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, , <https://www.rfc-editor.org/info/rfc8815>.
[RFC8899]
Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, , <https://www.rfc-editor.org/info/rfc8899>.
[RFC9293]
Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, , <https://www.rfc-editor.org/info/rfc9293>.
[v4historic]
Howard, L., "IPv4 Declared Historic", Work in Progress, Internet-Draft, draft-howard-sunset4-v4historic-00, , <https://datatracker.ietf.org/doc/html/draft-howard-sunset4-v4historic-00>.
[wes-george-sunset4-2016-03-22]
George, W., "Re: [sunset4] Declaring IPv4 Historic", , <https://mailarchive.ietf.org/arch/msg/sunset4/bvuqbcPPazA9WF1I3hye7envYRU/>.

Authors' Addresses

Seth David Schoen
IPv4 Unicast Extensions Project
San Francisco, CA
United States of America
John Gilmore
IPv4 Unicast Extensions Project
PO Box 170640-rfc
San Francisco, CA 94117-0640
United States of America
David M. Täht
IPv4 Unicast Extensions Project
Half Moon Bay, CA
United States of America