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

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

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 2022, [RFC9293] restated the definition of the TCP protocol, giving detailed advice to implementers on the interactions between the IP and TCP layers, including IPv4-specific considerations. (WG tcpm)¶
• In 2020, [RFC8899] defined a new way to detect path MTUs, both for datagram protocols and stream protocols, without the use of ICMP error messages. (WG tsvwg)¶
• In 2020, [RFC8815] deprecated any-source multicast packets for interdomain uses, and recommended application support of source-specific multicast. (WG mboned)¶
• In 2017, [RFC8029] defined a way to "ping" the data plane of an MPLS network that carries IPv4 or IPv6 traffic. The details changed the behavior of IPv4 routers which receive certain UDP packets that use destination addresses in the 127/8 range. (WG mpls)¶
• In 2016, [RFC7766] updated the host requirements for DNS resolvers and servers, requiring them to implement TCP as well as UDP. It also changed various other requirements to improve DNS implementations' compatibility with larger resource records used for DNS Security. It superseded a similar update in [RFC5966] in 2010. (WG dnsop)¶
• In 2014, [RFC7413] created the TCP Fast Open option to allow reduced latency in some applications of TCP (both v4 and v6) such as http GET requests or DNS lookups. (WG tcpm)¶
• The IPv4 header's "ID" field is used in fragmentation and reassembly of IP packets. Under the original specifications for IPv4, this 16-bit field had to have a unique value in every packet, that would remain unique for the lifetime of the packets in transit between a particular pair of source and destination addresses. With a potential packet lifetime of about 2 minutes (120 seconds) during routing flaps, and typical packet sizes, this limited transmission speeds to only about 6 megabits per second. In 2013, [RFC6864] updated the specifications for this field in the header of every IPv4 packet, to allow for implementations that meet the standards and can operate at gigabit and greater speeds. (WG intarea)¶
• Also in 2013, [RFC6918] formally deprecated some ICMP message types that had become obsolete in practice, such as the Information Request, Information Reply, Address Mask Request, and Address Mask Reply messages that have been replaced by DHCP. (This was an individual submission to the IESG and did not go through any working group.)¶
• Also in 2013, [RFC6762] defined Multicast DNS and required that DNS queries for names of the form "foo.local" must be sent to a link-local multicast address. This protocol is part of the IETF's Zeroconf effort to reduce manual configuration of IPv4 and IPv6 networks. (WG dnsext)¶
• In 2012, [RFC6528] standardized a revised algorithm for generating Initial Sequence Numbers in the TCP protocol, which reduces the chance of an off-path attacker guessing those sequence numbers. This makes some kinds of automated attacks on network connections harder to accomplish. (WG tcpm)¶
• Also in 2012, [RFC6633] deprecated the ICMP Source Quench mechanism for congestion control, which has not been reliably used in the Internet since the 1990s. (WG tsvwg)¶
• In 2011, [RFC6093] clarified the specifications and limitations of the TCP "Urgent Data" mechanism. (WG tcpm)¶
• Also in 2011, [RFC6298] changed how the TCP retransmission timer is calculated, for recovering from a failure by the receiver to acknowledge sent data. (WG tcpm)¶

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

11. References