The IETF published RFC8200 last week, which officially makes IPv6 an Internet Standard. While this move was a long time coming—IPv6 has now reached about 20% deployment—a more interesting question is: what has changed since RFC2460, which was a draft standard, was published in 2013? After all, the point of moving from the experimental to the draft standard to the internet standard states is to learn more about the protocol as it operates on the wire, and to make changes to improve deployability and performance.

Where would you look to determine what these changes might be? The IETF draft tracker tool, of course. If you look at the data tracker page for RFC8200, you will find a tab called history. From there, you have the option of looking at the revision differences, as shown below.

When you click on the Wdiff button, you will see something like this —

In this case, I went back to the original version of the RFC2460bis draft (which just means the draft was designed to replace RFC2460). There are earlier versions of this draft from before it was accepted as a working group document, but even this comparison should give you some idea of the major changes between the original document and the new document that replaces it. If you want a more complete diff, you will need to download the documents and run a diff in a tool like Atom or Notepad++.

Looking through the diffs, the major changes from the earliest 2015 version and the current 2017 version are in the area of extension headers.

First, according to section 4 of the new RFC, “the first one that is not an extension header [IANA-EH] indicates that the next item in the packet is the corresponding upper-layer header.” While older revisions of IPv6 actually carried a TLV that essentially said “the next header is TCP, and it begins in X octets,” the new revision assumes that if a header is reached that does not fit into the number range of an extension header indicates the next header is an upper layer protocol header.

What if you want to format a packet that is carrying no upper layer protocol? A new extension header is defined in section 4.7 of the new RFC for just this purpose. An implementation can end the chain of extension headers with a no next header extension header, which effectively tells the receiver to stop processing the packet. This allows you to form an IPv6 packet that carries only headers and extension headers, and no actual data.

Second, the way the extension headers are processed has been changed. In fact, this is probably the most far reaching change in the document from 2015 to the currently published version. Three specific changes have taken place here —

• Extension headers are not to be modified in any way by intermediate nodes (normally known as routers). This not only rules out fragmentation, but any modification of any extension header, including hop-by-hop headers. This is considered in the main body of section 4, before the beginning of the first subsection.
• There is note in this same area that changes the default behavior of intermediate nodes towards hop-by-hop headers. In RFC2460, each node was required to examine and process any hop-by-hop headers in the packet. In the newly published standard, intermediate nodes are only expected to examine these headers if they are configured to do so. Implementations cannot expect intermediate nodes to examine, or act on, hop-by-hop headers.
• In section 4.8, there are several paragraphs pointing out that because of these changes, no new extension headers will be defined without strong justification. While the text is in lower case (which generally means it is not “binding” on compliant implementations), a note here says: “New extension headers that require hop-by-hop behavior must not be defined…”

Instead of new extension headers, the new RFC recommends that any extensions be placed into Destination Headers, which are only processed by the destination. This recommendation is towards the bottom of section 6.8.

There are also a good number of changes in the fragmentation section, but these appear (primarily) to be changes in the way the text is organized. The basic concept—that fragmentation can only be performed by the originating host—has not been changed.

While it might seem like it took a long time for IPv6 to move from a draft standard to a “real” standard, it takes experience with a protocol to actually understand what it will look like in real deployments, and to work out those little details that make a huge difference in the usefulness of the protocol over the long term. Welcome to Internet Standard status, IPv6.

And now there is no excuse to not deploy IPv6 in your network today.