Home / Blogs

A Look at RFC8200 Which Officially Made IPv6 an Internet Standard

Russ White

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.

By Russ White, Network Architect at LinkedIn

Related topics: IPv6


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper

IP Addressing

Sponsored by Avenue4 LLC

Mobile Internet

Sponsored by Afilias Mobile & Web Services


Sponsored by Verisign

DNS Security

Sponsored by Afilias

Promoted Posts

Buying or Selling IPv4 Addresses?

ACCELR/8 is a transformative IPv4 market solution developed by industry veterans Marc Lindsey and Janine Goodman that enables organizations buying or selling blocks as small as /20s to keep pace with the evolving demands of the market by applying processes that have delivered value for many of the largest market participants. more»

Industry Updates – Sponsored Posts

Avenue4 Helps IPv4 Sellers and Buyers Gain Market Access, Overcome Complexities

Introduction to ACCELR/8 - Fast Lane to the IPv4 Market

Avenue4 Launches ACCELR/8, Transforming the IPv4 Market with Automated Order-Driven Trading

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Dyn Adds Chris Griffiths As New VP of Labs

New Nixu Solution Slashes Cloud Application Delivery Times from Weeks to Milliseconds

Domain Name Registrations Pass 233 Million in the First Quarter Of 2012

Nominum selected as 2012 AlwaysOn Global 250 Top Private Company

Nominum Releases New Version of Carrier-Grade DHCP Software for Telecom Providers

Nominum Survey of World's Leading ISPs Shows Nearly 60% of ISPs Plan to Roll-Out IPv6 by End of 2012

Nominum Sets New Record for Network Speed and Efficiency

Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)

Nominum and Nixu Software to Deliver Centralized DNS and DHCP Management Solution

Nixu NameSurfer 7.2 Strikes Rich at Dojo

DotConnectAfrica Participates at ICANN 43 In Costa Rica, the "Rich Coast"

Nominum Launches World's First Purpose-Built Suite of DNSā€Based Solutions for Mobile Operators

Is IPv6 the New Y2K? (Primer)

Nixu NEE Powers Location-Aware IPAM

Nixu DDI Awarded Gold Medal for Its IPv6 Support

UK Cabinet Office Looks to BlueCat Networks' Expertise and Best Practices for Securing PSN