An introduction to IPv6 packets and IPSec

IPv6 is the next-generation internet protocol, and will eventually replace IPv4 entirely. While new network infrastructures, routers, protocols are being developed, a smarter internet protocol is needed to better utilize bandwidth, and improve security and manageability.

In the article What you need to know about IPv6, we gave a general overview of IPv6. Then, in Configuring an IPv6 address in Red Hat Enterprise Linux 7 and 8, we showed you how to set up IPv6 on your RHEL systems, plus how to test whether your IPv6 configuration works (Hint: Use ping6).

When pinging an endpoint, packets are exchanged, whether you’re pinging a host, router, or mobile device. In this article, we’ll dive into the details of IPv6 packets and the role of IPSec.

IPv6 packet breakdown

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.

To better understand how this process works, we first need to understand the structure of the IPv6 packet. Here is an example of an IPv6 packet header:

Source: Wikipedia

This header consists of the following fields. Wikipedia lays them out nicely:

• Version (4 bits)
  This field is the version number 6 which is written in binary (0110).
• Traffic class (8 bits)
  This field is used to classify packets. In this field, a source indicates if it should use congestion control (to not overwhelm the destination with an excessive amount of data) or not.
• Flow Label (20 bits)
  This field is used to control the packet flow. A non-zero value in this field means that the packet should be treated specially; i.e., the packet should not be sent through different routes to reach the destination but rather use the same path. An advantage to this is that the receiving end doesn’t have to reorder the package, thus speeding the process.
• Payload Length (16 bits)
  Dictates the size of the payload including all the extension headers a packet can include.
• Next Header (8 bits)
  This field (if extension header present) defines what header comes next; i.e, the Next Header could be Routing, and then Routing has "fragmentation" as the next header, and so on.
• Hop Limit (8 bits)
  This field is equivalent to time to live (TTL) in IPv4.
• Source Address (128 bits)
  The source address, which is 128 bits in IPv6.
• Destination Address (128 bits)
  As above.

There are two extension headers we are interested in when we talk about IPv6 and IPSec, namely the Authentication Header (AH) and the Encapsulating Security Payload (ESP).

Authentication Header

As the name implies and as dictated by RFC 2402, AH is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replay attacks using a sequence number.

This above checking is done based on the Integrity Check Value (ICV) calculated over the payload. So, what does "connectionless" mean in this regard? The receiving host cannot notify the sender that ICV didn’t match and the data was discarded. There is no state at this level between the sender and receiver, so that’s why it’s connectionless.

Encapsulating Security Payload

In addition to AH, ESP supports confidentiality and privacy by encrypting the payload. See RFC 2406. ESP supports encryption only and authentication only, but using encryption without authentication is considered to be insecure. We’ll see in a minute how this works.

IPSec modes

IPSec operates in two different modes: Transport and Tunnel. In Transport (Host-to-Host) mode, only the payload is encrypted or authenticated. The original IPv6 header is used, followed by AH and ESP, and eventually the payload itself. In Tunnel (Gateway-to-Gateway or Gateway-to-Host) mode, the entire IPv6 packet is encrypted and authenticated. This packet is then encapsulated by a new IPv6 header.

AH in Transport and Tunnel Modes

AH authenticates the packet header itself. It does not provide authentication for mutable fields (fields altered during transmit, such as DSCP, ECN, Flow Label, and Hop Limit) and/or payload. AH can not be used when a packet traverses NATs. NATs would translate addresses, resulting in an invalid ICV.

Let’s illustrate this with a picture:

ESP in Transport and Tunnel Modes

In Transport mode, the IPv6 and extension headers are not included in the authentication process. However, in Tunnel mode, the original IP header and extension headers are authenticated and encrypted.

This process is best described by the following figure:

ESP is used to build site-to-site VPN tunnels and can handle NAT traversal since the new IP header and extension headers are not included in the ICV calculation. When both, AH and ESP are used, ESP is applied first, after which AH authenticates the entire packet.

The authentication and encryption of these packets is done based on Security Association (SA) records, which are stored in the database at each endpoint. These records hold algorithms, keys, modes, sequence numbers, destination address, SA lifetime, etc.

The selection of SA can be configured manually using pre-shared keys, or automatically with Internet Key Exchange (IKE/IKEv2). IKE uses Diffie-Hellman to share the key securely, and it depends on Public Key Infrastructure (PKI). For more information, see RFC 2408.

Wrap-up

IPv6 is feature-rich, building on lessons learned with IPv4. Even with all of the features included in this article series, more are still in the process of being developed and finalized. With its support of IPSec and cryptographically generating IP addresses to provide optimal anonymity and security, it’s time to take a serious look at IPv6 if you haven’t already.