What IPv6 features can be found in the latest specification?

It's been 20 years since the Internet Engineering Task Force, or IETF, published the first request for comments leading to the development of IPv6. Last year, the IETF published its latest IPv6 request for comments, RFC 8200, which proposed to make IPv6 and a number of IPv6 features part of an internet standard.

IETF standards are judged in one of three ways: as either a proposed standard, a draft standard or an internet standard.

Proposed standards represent the entry level for standards-track protocol specifications and imply the specification is generally stable and well-understood. However, they do not require any implementation or operational experience with the associated protocols.

A draft standard -- the next step -- requires at least two independent and interoperable implementations of the specification, along with successful operational experience. A specification merits internet standard recognition when it has significant implementation and successful operational experience has been obtained. This is the highest maturity level an IETF protocol specification may achieve.

This article examines some of the main changes in the revised IPv6 specification, as well as controversies that arose during the associated publication process.

The core IPv6 specification and how it's changed

The core IPv6 specification -- RFC 2460 -- has changed considerably since it was first released. The new IPv6 features are geared toward reliability, as well as operational and security considerations.

To that end, the revised spec contains a security analysis of IPv6, with references to some of the work that's been carried out during the last few years, particularly in the area of IPv6 addressing. Other enhancements target IPv6 extension headers and fragmentation.

For example, the original IPv6 specification allowed overlapping fragments -- that is, fragments that covered the same chunk of data from the original unfragmented datagram. The use of overlapping fragments to circumvent security controls was already very popular in the IPv4 world. However, even when there was no legitimate use for them in the IPv6 world, overlapping fragments were still considered valid. Such fragments were eventually declared illegal by RFC 5722, which published in 2009. Thus, the new specification incorporates that update, banning overlapping fragments.

The original spec also let packets employing extension headers to be split into multiple fragments. In other words, the upper-layer heading -- for example, TCP -- could be present in a fragment other than the initial one, as illustrated below.

This essentially prevented stateless filtering of IPv6 packets, and it was banned by RFC 7112, published in 2014. The ban remains; the first fragment of a datagram must contain the entire IPv6 header chain.

Another area where IPv6 repeated IPv4's history is the use of predictable fragment identification values, which were exploited in IPv4 in a number of ways, such as for implementing stealth port-scanning attacks. The upcoming revision of the IPv6 specification references RFC 7739 for possible algorithms for generating fragment identification values.

Atomic fragments now part of IPv6 features

Yet another improvement associated with IPv6 fragmentation is related to so-called atomic fragments. Essentially, the initial IPv6 specification said, upon receipt of an Internet Control Message Protocol version 6 "packet too big" message reporting a maximum transmission unit smaller than 1280 bytes, the receiving host had to include a fragment header in all subsequent packets sent on the associated flow, as follows.

Hackers exploited this feature to launch denial-of-service (DoS) attacks; therefore, it's been removed from the updated specification. Instead, atomic fragments will be processed in a different way, based on the advice originally provided by RFC 6946.

Finally, the upcoming revision also removes the specification of Routing Header Type 0, which was also identified as a DoS vector.

As with any modification to an existing specification, some controversy erupted over some of the suggested IPv6 features. The most heated debate centered around the insertion of extension headers by middleboxes.

IPv6 has always been an end-to-end protocol. Thus, intermediate systems have never been allowed to modify IPv6 packets, other than decrementing the hop limit. However, a technology called IPv6 segment routing -- largely based on middleboxes inserting and removing IPv6 extension headers -- triggered a very heated debate regarding whether the revised IPv6 specification should allow the insertion and removal of extension headers by middleboxes.

Such heated debate continued until the final approval of the revised IPv6 specification for publication as an RFC and settled on maintaining the status quo: Insertion and removal of extension headers by middleboxes is forbidden.