A few weeks ago I went through RFC 791, which was the original IPv4 specification. I thought it could be interesting to follow up on this by looking at RFC 8200 which is the latest specification for IPv6.

The primary rationale for IPv6 is to go beyond the limits of IPv4’s address space. As you recall, IPv4 addresses are 32 bits, limiting the protocol to roughly 4 billion addresses. Over the past decade or so, various entities responsible for managing IPv4 addresses have allocated their final blocks. The IANA declared the ’top-level’ allocation exhausted in 2011, followed by various regional registries in subsequent years. Wikipedia has a more detailed discussion of this here.

IPv6 introduces a 128-bit address space. Many of the fundamentals of IPv4 are still here: datagrams, “best-effort delivery”, and so on. But in some ways IPv6 also smooths some of the rough edges of IPv4.

You can see this by looking at the IPv6 header:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Let’s take a look at the fields in more detail:

• The Version field is a hardcoded 6 for IPv6.
• The Traffic Class field can be used for differentiated services and explicit congestion notification. This basically lets IPv6 routers do things like traffic shaping or signal congestion to transport-level protocols like TCP.
• The Payload Length specifies the size of the data following the header.
• The Next Header field indicates the type of header immediately following this one (e.g. ICMP, UDP, TCP). You can see the current values here.
• The Hop Limit is equivalent to the IPv4 time-to-live (TTL) field.
• The Source Address and Destination Address are as you would expect.

Compared to the IPv4 header (see here) this is remarkably streamlined. In particular, forwarding an IPv6 packet is simplified because the header has a fixed size (whereas IPv4 has “options”) and there is no checksum that has to be recomputed when the hop limit / TTL gets decremented.

IPv6 eliminates the IPv4 variable-length “Options” field in a simple and elegant way: it defers options to various “Extension Headers” that sit between the IPv6 header and transport-layer data. Each of these extension headers has a “Next Header” field, allowing them to be chained together. About a third of RFC 8200 is defining these extension headers, but a virtue of this approach is that the basic mechanism of datagram forwarding can be accomplished without needing any of these.

IPv6 also eliminates IPv4’s fragment offset field. The spec requires that any implementor have a minimum transmission unit (MTU) of 1280 bytes, and suggests using Path MTU Discovery.

There’s much more that could be said about IPv6 – I only briefly touched on the extension headers, and didn’t discuss IPv6 addressing in any detail. But I have been wondering: how many people actually use IPv6? The original specification is almost 30 years old, but adoption of IPv6 has been slowed by the ubiquity of IPv4 and the use of things such as network address translation to cope with the limited address space. Google has a running chart of IPv6 traffic to their services. At the time of writing this article, total IPv6 usage only accounts for 47% or so of Google’s requests. There’s still a long way to go!