Stretching IPv6 with extension headers

Extending IPv6

by Craig Miller

IPv6  Extension Headers

Extending the reach

There was great concern when IPv6 was being created in the '90s about the increase in size of the IP header. After all, the IP source and destination addresses were increasing from 4 to 16 bytes each. 

It was important to keep the header size to a minimum, since every packet would have a header, and it represents overhead. After all, sending packets isn't about the headers, it is about the data that is being carried (e.g. web, streaming video,  voice over IP, etc.).

By rearranging things, and removing fields (like the header checksum), the creators of IPv6 managed to make the new header only 40 bytes long. 

But in removing as much as possible, the IPv6 header was stripped of many common things we have come to expect, such as fragmentation, and encryption. The concept of extension headers was added. It is important to know about extension headers, as they can also be misused to cause problems in your network. 

Extension headers defined in IPv6 (RFC 2460) are:

1. Hop-by-Hop Options
2. Routing (Type 0) - Removed by RFC 5095
3. Fragment
4. Destination Options
5. Authentication (AH)
6. Encapsulating Security Payload (ESP)

IPv6 extension headers are inserted after the IPv6 header and before the layer 4 (think: tcp, udp) header.

The purpose of some of the extension headers are obvious, such as Fragment, Authentication (authenticated header), and ESP. Let's look at the less obvious ones.

Hop-by-hop options: It was thought that there may be cases where the forwarding routers might need more information than what was left in the pared down IPv6 header.

Destination options: This is used to pad the header to align it to an 8 byte boundary, making it easier for the destination host to process. 

Security concerns

Many extension headers do not make sense between two hosts on the same link. For example, fragmentation. If both hosts are on the same link, there should be no need to fragment (remember IPv6 fragmentation is only done by the sender, not by the routers). Therefore, a host on the same link should not accept a packet with a fragmentation extension header.

Why is this a problem? Remember router advertisements (RAs)? These are only transmitted on a link (e.g. do not cross routers). Remember also that RAs define a network prefix, and a default gateway. What if a BAD person where to transmit their own RAs, telling hosts on the link that the BAD person was the default router. This would be a excellent method to do man-in-the-middle attack, since now all packets would travel through the BAD guy.

Cisco implemented a feature (in hardware) called RA Guard to block against this. Their layer 2 switches would examine packets for RAs, and discard them if they weren't from a designated router port. But the BAD guys figured out that they could use an extension header, like the fragmentation header, to pad out the RA packet a bit, and get past RA Guard.

Valid RAs should never be encapsulated in a fragmentation extension header, since RAs are always transmitted on the same link as the receiving host.

More extension headers

Since RFC 2460 was written in 1998, more extension headers have been added to IPv6. RFC 7045 gives a good list of current extension headers. Here are some additional headers added since RFC 2460:

1. Mobility Header, (RFC 6275)
2. Experimental use, Host Identity Protocol (RFC 5201)
3. Shim6 Protocol, (RFC 5533)
4. Use for experimentation and testing, (RFC 3692), (RFC 4727)

Extend this ...

You don't have to be an extension header expert to use IPv6. Most IPv6 packets will have no extension headers. They add back functionality that was stripped out of the IPv6 header, and used only when needed. 

Every networking mechanism has vulnerabilities and complexities. IPv6 simplifies many things in your network, and most likely you won't have problems with extension headers. Knowing about them, can help you troubleshoot, and fix your network faster.