What happened at the sunset4 working group discussion at IETF95.
You may remember my previous post about declaring IPv4 historic. IPv4 and IPv6 were specified in RFCs published by consensus at the IETF, the Internet Engineering Task Force. Changes required a new internet-draft to be written and discussed, and if it achieves consensus (usually after edits), it is published as an RFC.
My internet-draft attempting to declare IPv4 historic was discussed in the sunset4 working group at IETF95. It was a productive discussion, with very good suggestions for moving forward.
I won’t reiterate the full meeting proceedings, but I did go back and listen to the MeetEcho recording of it. I came away with a list of things we should pursue at the IETF to make progress toward sunsetting IPv4:
- Update v4historic draft.
- Based on feedback on mailing lists, I will remove the section on deprecating the protocol. Fred Baker pointed out that the IETF does have a definition of “deprecated,” in rfc1158 which says a deprecated MIB object “must be supported, but one which will most likely be removed from the next version.” The RFC goes on to say that “no functionality is lost with the deprecation” because the new version includes better functionality. That statement should apply: there’s nothing that can be done in IPv4 that can’t be done in IPv6.
- Dave Thaler pointed out that “Historic” doesn’t mean “can’t update;” it says that “standards track documents normally must not depend on (documents) at a lower maturity level.” He emphasized “normally” and gave examples of exceptions, and concluded that declaring IPv4 Historic would not prevent updates to IPv4, it would just raise the level of scrutiny by the IESG.
- Barbara Stark, among others, requested great clarity in the goal of the document.
- Several people said that while the status of IPv4 is changing, it’s not yet historic. Phillip Hallam-Baker suggested a new status: “It’s complicated.” Based on what I heard at the meeting, a new draft describing the changing status, and milestones marking the changes, would be welcome. Such a draft should include:
- Deprecate IPv4, in the sense described in the original draft: its use should be avoided.
- In particular, use of IP literals should be avoided.
- The likely path to Historic status is via IPv6-only plus IPv4-as-a-Service. It seems to me that various organizations will go through one phase when little enough of their traffic is IPv4 that they are willing to put the rest on a transition service. When little enough traffic (that users don’t complain) is IPv4, they will disable IPv4 completely, even if others are using IPv4 exclusively.
- IPv4 can be declared historic when enough people are running IPv6-only that it’s clear that heterogeneous networks can run without IPv4 as a dependency.
- Milestones for various levels of historicity.
- IAB Liaison statements or other messages to SDOs that IPv4 is waning, IPv6-only is acceptable, IPv4aaS is good, or some variation thereon.
- The IESG (or the IETF community) can squelch proposed charters that include IPv4 work. A statement to that effect would be helpful, but needs to allow for updates in support of transition.
- WG Chairs (or IETF community) can search for IPv4 literals, IPv4-only examples, and IPv4 dependencies, and clean them up.
- Update id-nits checker to warn if there are IPv4-only examples. Done! Henrik Levkowetz, working from positive comments among participants and WG chairs, added a warning to the id-nits tool (invoked whenever an internet-draft is uploaded) that will warn, “The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too?”
- Run IPv6+NAT64 as default IETF SSID. I’ve discussed with some of the appropriate people, and there is some willingness but would like some reassurance that we won’t get complaints from people trying to do work.
This is a good set of tasks to step toward sunsetting IPv4. What else can the IETF do?