One thing is clear, there is a serious amount of misinformation about IPv6. There are many blog posts and even official documents from respected sources that have blatantly incorrect information. Many blog posts that start out with an introduction such as this one, but end up spreading misinformation about IPv6 anyway. To avoid spreading misinformation myself, I’m going to cite the only sources of truth in the network world: the IETF RFC’s. If you’re looking for a clear and simple one-liner to sum up this article here it is:

Since the IETF issued RFC 6434 in 2011, the IPv6 standard does not require devices to implement (to be capable of) IPsec, nor does it require the enablement or use of IPsec for IPv6 nodes that do implement (are capable of) IPsec.

Yes, you read that right. You cannot count on IPsec even existing in nodes and devices running IPv6. For many years now a great number of sources have been trumpeting that IPv6 will herald an era of not having to think about network security anymore. Most respectable sources reject this notion, saying that it’s required to be implemented (to exist) in all IPv6 nodes, but not required to be turned on. Unfortunately that is also false.

RFC 1883 – where it all started

In December 1995, the IETF (Internet Engineering Task Force, a standards body accepted as the source of truth in the networking world) released RFC 1883, which defined IPv6 as a successor to IPv4.

Page 36 of that RFC briefly and quietly stated that Authentication Header (AH) and Encapsulating Security Payload (ESP) be required to secure IPv6 traffic:

This document specifies that the IP Authentication Header [RFC-1826] and the IP Encapsulating Security Payload [RFC-1827] be used with IPv6, in conformance with the Security Architecture for the Internet Protocol [RFC-1825].

https://datatracker.ietf.org/doc/html/rfc1883

This lead to a lot of folks being really excited about the ramifications of mandated secure connections in IPv6. While I can’t find any articles from 1995, this blog post from Bitdefender (a respected name in security) from 2012 is a really good example of an article making really misleading statements about how IPsec works with IPv6:

IPv6 comes with built-in IPSec , a technology that ensures secure host-to-host communication. This means that two clients communicating over IPv6 can automatically do authentication, message integrity and encryption or any combination of those.

https://www.bitdefender.com/blog/hotforsecurity/ipv6-is-here-ready-to-embrace-it

While the implementation (the capability) of IPsec was indeed mandatory in IPv6 for the first 16 years after RFC 1883 was released, no one ever said that the use or enablement of it would be mandatory.

RFC 6434 – IPsec from MUST to SHOULD

In December 2011, the IETF updated the IPv6 Node Requirements RFC with RFC 6434. In section 11 (Security), they make this unmistakable statement:

Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.

https://datatracker.ietf.org/doc/html/rfc6434

While IPv6 IPsec is implemented (the capability exists) in major desktop/laptop OS’s such as Windows and macOS, the Internet is made up of much more than that. Internet of Things comes to mind.

It seems the IETF realized that it doesn’t make sense (or in many cases it’s not possible) to include the complexity of IPsec in an IPv6 implementation. They went on to say in RFC 6434:

This document recognizes that there exists a range of device types and environments where approaches to security other than IPsec can be justified.

https://datatracker.ietf.org/doc/html/rfc6434

Loads of misinformation

So yes, starting in 2011, IPsec even existing in a device running IPv6 is a big maybe. Despite this, some of the most respected companies in the world write documentation that describe the mandatory-ness of IPsec in IPv6. Take this IOS configuration guide from Cisco, written in August 2012:

IPsec is a mandatory component of IPv6 specification.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2s/ipv6-15-2s-book/ip6-ipsec.html

Or this article from Microsoft written in 2020:

Internet Protocol Security (IPsec) is a set of security protocols used to transfer IP packets confidentially across the Internet. IPsec is mandatory for all IPv6 implementations and optional for IPv4.

https://docs.microsoft.com/en-us/windows/win32/fwp/ipsec-configuration

Or this article from Redhat written in 2019:

In What you need to know about IPv6, we mentioned that Internet Protocol Security (IPSec) is incorporated into IPv6. This statement simply means that communication between the two endpoints is either authenticated, encrypted, or both, via the extension headers. There is a long-running discussion on the internet regarding whether the interpretation of “IPSec being mandatory” in IPv6 is correct or not. If you need to know more about this topic, see RFC 6434.

https://www.redhat.com/sysadmin/ipv6-packets-and-ipsec

This last one from Redhat is particularly confusing. They mention the very RFC where IPsec became optional and even mention the ongoing debate, but continue to say that communications in IPv6 are either authenticated or encrypted, or both.

What’s actually happening? Not IPv6 IPsec.

All of this RFC and protocol stuff is a bunch of theoretical pie in the sky. What’s actually happening out in the wild? Well, I can’t speak to the whole Internet. Maybe folks are using IPsec like they do in IPv4 – for site-to-site tunnels. Or maybe something else. But to test typical web traffic, I have native IPv6 capability in my home. I took some Wireshark captures to various websites.

Here’s google.com:

Here’s microsoft.com:

Here’s wikipedia.org:

Where’s the IPsec? I don’t see any IKE, AH or ESP. Looks like typical TLS traffic to me. So… no change in security from IPv4, then.