IPv6 Deployment

Declaring IPv4 Historic: One Issue, Two Sides

Should IPv4 be declared "Historic" now? Lines have been drawn and supporting arguments on both sides show significant merit. To shed light on the pros and cons of declaring IPv4 Historic, the IETF Journal invited Lee Howard and Geoff Huston to share their thoughts.

By: Geoff Huston, Lee Howard

Date: July 6, 2016

line break image

During IETF 95, in a meeting of the IPv4 Sunset Working Group, Lee Howard presented on a proposal that recommends that IP version 4, or to be specific, the technical protocol specification documented in RFC 791, be declared Historic.

In the context of the Internet Standards Process, the term Historic has a particular meaning. RFC 2026 defines Historic to mean:

A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level.

While it looks simple on paper, actually acting on RFC 2026 is anything but. Lines have been drawn and supporting arguments on both sides show significant merit. To shed light on the pros and cons of declaring IPv4 Historic, the IETF Journal invited Lee Howard and Geoff Huston to share their thoughts.

Lee Howard: Yes!

The original document defining IPv6 says that “IP version 6 (IPv6) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4)” [RFC 1883]. A “designed successor” may not instantly supersede its predecessor, but that sounds like the intent, and the successful deployment of IPv6 means the time is near.

IPv4 is historic. It has enabled new means of communicating that have changed the world. IPv4 is also historical: it belongs to the past. Like stone knives, it is a technology that enabled other life-improving innovations, but whose time has passed.

A Historic protocol can still be used. Early discussion in the sunset4 working group shows that it is too soon to deprecate IPv4. “Deprecating” would be saying it should be avoided because it is harmful or not recommended. IPv4 does have inherent limitations that cannot be mitigated: primarily, the length of the address space. IPv6 does not have this limitation.

IPv4 may still be perfectly viable for communication in some circumstances. Other historic protocols are still in use, when administrators understand the risks, usually when both end points and the network between them are under single administrative control. Network operators are free to continue using IPv4 as long as it suits their needs.

Declaring an Internet Standard to be Historic does have implications. When RFC 791 is moved to Historic status, any Standards Track RFC with a Normative reference to RFC 791 becomes Historic. Over one hundred RFCs cite RFC 791, but not all of them are normative references, and not all of them would reasonably be obsolete. For instance, RFC 7676 defines “IPv6 Support for GRE” and even though it includes RFC 791 as a normative reference, there’s nothing in it that fails if IPv4 is declared Historic.

Some RFCs define IPv4 options, which would seem to make them Historic. Most, such as RFC 1035 “Domain Names – Implementation And Specification” which defines A records and the IN-ADDR.ARPA zone, will be updated by this document, but are not Historic. Other documents with incidental references to RFC791 should not be affected. Documents requiring updates should be included in [draft-ietf-sunset4-gapanalysis].

Why go to all this trouble?

It’s not just housekeeping. Although a tidy house is appealing, there’s plenty of clutter in the RFC series. Some clutter doesn’t matter, though—there’s no need to tell people to ignore the disused ashtray under the sofa, they’re ignoring it already, and fewer and fewer people need ashtrays. IPv4, however, is significant, with new transition mechanisms, new optimizations, and new Network Address Translation (NAT) workarounds still being introduced. Developing consensus on that work distracts people, whose time could be better spent developing IPv6 features or optimizing performance or security in IPv6.

It is therefore important to stop working on IPv4. This tool is becoming more fragile (or brittle) over time with patchwork like NAT and its workarounds. An IETF consensus declaring IPv4 to be Historic will signal to future IETF contributors that we are done with it. The process of considering, discussing, and building consensus on that declaration is how we as a community determine how we want to spend our precious time. We can decide that we no longer want to support those who refuse or have taken too long to upgrade to IPv6.

For those who choose to continue using IPv4, there are some considerations. The IETF may not normally update Historic RFCs. This doesn’t mean that the IETF can never update IPv4, but the bar is set higher, requiring scrutiny from the IESG. Maybe we continue optimizing transition technologies. As described in RFC 6540, IPv6 support is required, and some documents may be confusing as to whether “IP” means IPv4 plus IPv6, IPv6-only, or IPv4-only.

We can’t declare IPv4 Historic tomorrow. “Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level” [RFC 2026]. Therefore, any RFC depending on IP must have IPv6 at full maturity before declaring IPv4 Historic. Since the IETF IPv6 Maintenance (6MAN) Working Group is in the process of promoting IPv6 to Full Standard, we would have to wait. Being dependent on that work does not mean it’s too soon to discuss it and to work on building consensus.

It is possible that bugs inherent to IPv4 may yet be discovered. This seems unlikely, given the extent of testing and production use it has. RFC 791 has only been directly updated three times:

  1. RFC 1349 “Type of Service in the Internet Protocol Suite”
  2. RFC 2474 “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”
  3. RFC 6864 “Updated Specification of the IPv4 ID Field”

Still, it is conceivable that an inherent flaw will be found, and if IPv4 is Historic, it will be easier to update IPv6 than IPv4. Therefore, for security reasons, the use of IPv6 only is recommended; IPv4 should be used only as needed for backward compatibility.

“Art is never finished, only abandoned.”[1] It’s time to stop working on our previous master work, and show how much farther we have come than our original stone knives. The combined focus of the IETF on IPv6 can give it a even greater resilience, flexibility, and security than we did with IPv4.


Geoff Huston: Not Yet!

The rationale for the proposed redesignation of IPv4 was that the protocol has been superseded by a more-recent specification, IP version 6. Furthermore, it is thought that this action would add to the impetus to deploy IPv6. The take-up of IPv6 is not overly uniform. While some service providers are enthusiastic proponents of IPv6, many more providers are at best hesitant and at worst ignoring it and hoping that it will go away. As a message to both the laggards and potentially their customer bases, it was argued that the IETF should clearly indicate that it is time to move to IPv6. One way to do that is to declare IPv4 a Historic technical specification.

If that were all there is to it, then perhaps a case can be made that the IPv4 technical specification should be declared Historic. But there are additional aspects to consider. As pointed out by RFC 2026:

Not Recommended: A Technical Specification that is considered to be inappropriate for general use is labeled “Not Recommended”. This may be because of its limited functionality, specialized nature, or historic status.

This text seems to imply that a status of Historic also suggests Not Recommended, which may send the wrong signal to the existing user base that relies on IPv4.

The proposed redesignation also would throw the IPv4 specification out of the Internet Standards set.

Specifications that are not on the standards track are labeled with one of three “off-track” maturity levels: “Experimental”, “Informational”, or Historic. The documents bearing these labels are not Internet Standards in any sense.

So maybe this is a bigger step than just observing that IPv6 supersedes IPv4. As one commenter in the Working Group session pointed out, declaring IPv4 Historic would likely backfire and serve no better purpose other than exposing the IETF to ridicule. Certainly there is some merit in wondering why a standards body would take a protocol specification used by more than 3 billion people and approximately 10 billion devices every day and declare it to be Historic. In any other context, such adoption figures for a technology would conventionally be called outstandingly successful!

Perhaps we can put this into a broader context by looking at other Historic specifications. Unfortunately, the IETF does not have an obviously consistent story when declaring technical specifications Historic. Some very old and now unused services as described in Request for Comments (RFCs) are not declared to be Historic. For example, we can go a long way back in time to RFC 162, and find a specification that the completely forgotten protocol, “netbugger3”, is not Historic. If there are any extant implementations of this curiously-named protocol, I would be keen to learn of them. Similarly, Gopher, a specification that enjoyed a brief moment in the sun in the early 90s before the juggernaut that is today’s Web superseded it, is not, according to the IETF, Historic.

So if some pretty obviously defunct protocols are not Historic, what is? A browse of the Historic RFCs reveals a collection of TCP extension specifications, including RFC 1072 and RFC 1106. They were declared Historic by RFC 6247 with the rationale that they “have never seen widespread use”. That’s not applicable to IPv4 by any stretch of the imagination! Browsing the Historic RFC list at https://www.rfc-editor.org, it’s evident that there are more than a few RFC documents that never even saw the light of day as current specifications, as they were declared Historic at the outset. Again, quite obviously, this is not applicable to IPv4.

What about other Internet Standards? There is a reasonable case to be made that Internet Standards numbers 23 and 24 (Quote of the Day and Finger, respectively) have long passed out of common use. Historic status seems to be entirely applicable for both of those quite venerable standards, as their previously widespread use has waned to the point of almost complete invisibility.

So we appear to treat Historic status somewhat whimsically. We could be a little more consistent, and in that vein there is a case to be made to push Finger, Quote of the Day, Gopher, Netbugger3, and their like into Historic. The world has moved on and these protocols are stuck in an older world. But not IPv4. And not just because it is used by an unprecedented number of people and devices and we all still rely on it.

It’s not just that.

It’s because we probably haven’t finished with IPv4 yet.

While many folk, including myself, would dearly like to see an all-IPv6 Internet today, I’d like to think I’m pragmatic enough to understand that we’re stuck with a dual-stack Internet for many years to come. And that pragmatic observation has its consequences. So far, we have managed to cram some 10 billion unique devices into the Internet. The silicon industry is not going to stop and wait for us to complete this IPv6 transition, and, in the meantime, we can readily imagine a near future that crams every new computer, smartphone, personal pad, television, new car, and a whole heap of other applications, on this dual-stack Internet. We may well need to push the IPv4 Internet to encompass 20 billion or so devices on this strange and protracted dual-stack journey to IPv6.

One immediate change so far is the semantics of IPv4 addresses. Increasingly, IPv4 addresses are ephemeral short-term elements of conversation stream identifiers. The have lost any concept of being a stable endpoint identifier. The more devices we push into the network, the more we change the way IPv4 behaves. As we try and make IPv4 stretch just that little bit farther, we may need to make more subtle changes, which may or may not impact the current specification for IPv4. We just don’t know yet. What we do know is that right now the story is by no means over for IPv4.

As a standards body, it may sound like a good idea for the IETF to send a strong signal to the industry about the need to take this transition seriously by declaring IPv4 to be Historic. But if this is what the IETF does, then the work on IPv4 will probably continue. The risk is that it will continue without the benefit and support of the acknowledged Internet Standards organization, the IETF. And we have some prior experience with what happens then.

The last time the IETF turned its back on a technology specification was the development of the specification of Network Address Translation (NAT). The result was that implementers could not rely on a complete and coherent specification, and they were forced to make it up as they went along. Every NAT product had subtle behavioural differences with every other NAT product. The losers in this scenario were application developers and, ultimately, the users. Applications had to work across NATs and negotiate functionality across a diverse set of undocumented and, at times, inconsistent behaviours. The resulting environment can be brittle and fail in unanticipated ways.

Standards help us understand how to interoperate and how to rely upon predictable ways to interoperate. It takes a lot of the guesswork out of technology specification, and can eliminate a large amount of complexity in implementing technology. I would be horrified if we managed to repeat this mistake at this point in IPv4’s life history. Oddly, it is now, while we continue to work through the dual stack phase of the transition to an IPv6 Internet, that the IPv6 part of the Internet needs a consistent and relevant IPv4 specification the most!

IPv4 Historic? No. We haven’t finished with it yet!

[1] Attributed to Leonardo da Vinci.

  • Ipv6 is more expensive than ipv4, therefore ipv4 should be kept alive and enhanced to continue supporting a lower costs internet, way sufficient for many countries and usage. Ipv6 will then develop as the larger wider internet, for the rich and developed countries, able to upgrade their infrastructure.

    • v6 is not really more expensive than v4 in today’s world. It is expensive to support both protocols. To ease the support of both protocols especially v4 has to adapt. This is made difficult if it is supposed to be historic.

    • How do you calculate that IPv6 is more expensive?
      IPv6 addresses are available cheaply from the RIRs. IPv4 addresses cost US$6-18 each on the market. IPv4 address scarcity drives NAT, which is additional complexity and expense, including a lot of IETF work just to get through NAT boxes. So I’m interested in how you reckon the price of the two.

      • It is not fair to judge the cost of a system based on the market price of its ID tags (the IP addresses). The ID is an essential element of a communications system. Thus, it should not be treated as a private property to be owned by individuals (either persons or organizations) in any sense. So, the entire ongoing philosophy behind how to handle the IP address is very questionable. We need to recognize this fundamental issue, instead of continuing on the current practice. For example, while emerging regions and rural areas of developed countries are struggling due to lack of IPv4 addresses, ever so often we see certain parties were selling a fairly large block of surplus (never used) addresses. And, more surprisingly, some of the buyers turned out to be IPv6 promoters! How could we close the loop on this kind of logistics?

    • The only time I’ve seen IPv6 cost money is when a vendor ships an IPv4-only device and charges for firmware updates. Sadly, that is often the case. Some vendors even required a maintenance agreement for Heartbleed fixes, Shellshock fixes, and firmware that supports TLS 1.2 and turns off RC4.

  • Adobe obtained the software rights for Freehand, then obsoleting it to protect its competing software Illustrator. 6000 Freehand users complained, the Federal Trade Commission tried to stop Adobe obtaining a monopoly in advanced drawing programs. Nothing helped. Windows XP, the venerable graphics interface marketed in 2005 will be obsoleted by Microsoft in 2016. And now IPv4, new in 1981, is to become historical after 35 years.

    Software systems used by thousands people is like forbidding an author his computer to write new novels on, or forbidding an artist from using his artistic tools.

    I am 75 years old. Maybe I am too old, when I complain over old hardware and software becoming obsoleted.

    • I am a veteran from the last life AT&T Consent Decree era. Back then, there was only one party (the monopolyer) who was responsible for any objectionable behavior. So, we were all disciplined to be “Kosher”. In the current Internet environment, the “open competition” banner produces several dominating players in each field who can wiggle out of the customer complaint by offering their competitors as the alternatives. For a few nearly monopoly fields, this is practically back to the old days, yet without regulations.

  • I agree that it’s time to stop using IPv4 when possible, and to use IPv6 in all future deployments. This coincides with T-Mobile and Verizon Wireless deploying IPv6-only networks with IPv4 translators (in contrast with Verizon “Wired” which is still IPv4-only). Perhaps the IETF needs a new designator, somewhere between Historic and Not Recommended For New Deployments Unless Necessary.

    Still, when brand-new devices deploy with IPv6 as an afterthought (like my home’s new eero routers) or a half-implemented technology (like my new SonicWall router that doesn’t support management over DHCPv6-PD addresses), perhaps we need something stronger than an RFC to spur adoption. Hopefully that something isn’t as dour as widespread Carrier-Grade NAT.

    • Hi, Jim:

      There may be an answer to your wish. We have figured out a method of utilizing the very original IPv4 standard RFC791 and the long-reserved yet hardly–used 240/4 address block to expand each public IP address by 256M (Million) fold. It will restore the end-to-end connectivity by taking over the CG-NAT function. A Draft proposal called EzIP (phonetic for Easy IPv4) has been submitted to IETF. (I am not sure if this website allows posting URL. If interested readers could not locate the posted Draft, let me know. I will try to supply it via some other manner.)

      Among several EzIP benefits, one immediate application is that most (75%) countries will now be able to provide an Internet service to the whole country in a configuration called “sub-Internet” from just one of the IPv4 addresses already assigned by the RIR (Regional Internet Registry) to that country. This is in parallel to that by the current ISP, offering end-users the opportunity to compare then to choose. This is the beginning of the open competition that everyone has been looking for.

      Since this approach needs, mathematically, only about 200 public IPv4 addresses to serve all of the 50B (Billion) projected IoTs needs by Year 2020, there will be a lot of spare IPv4 addresses ready for other new applications.