There are a lot of similarities between IPv4 and IPv6. There are also a lot of differences, including some differences that may have security implications for network engineers who deploy IPv6. In this blog posting, I will discuss IPv6 extension headers and why network and security engineers may want to pay closer attention to them.
The IPv6 specification(1) supports what are known as extension headers, which have varying uses. The good thing about extension headers is that they are typically seldom seen with general Internet usage, except in specific situations, such as where packets must be handled in a specific manner that cannot be described in the standard IPv6 header. The bad thing about extension headers is that end nodes (such as user computers) and intermediate nodes (such as routers, firewalls and other security devices) generally need to be aware of and be able to handle extension headers.
Perhaps the most frequent and important extension header is the fragment extension header (which will be discussed in a later post). Other extension headers defined in the IPv6 specification include hop-by-hop options, destination options and routing. The authentication and the encapsulating security payload headers, defined in separate RFCs , support IPsec in IPv6.(2)
Source routing in IPv4 has been problematic because of opportunities for denial of service attacks and routers are usually configured to ignore source routing options.(3) Because of its similarity to IPv4 source routing and its even greater potential for facilitating denial of service attacks, the IPv6 routing extension header type 0 was deprecated by the IETF in December 2007. In packets that contain a type 0 routing header (also known as RH0), the routing header must be ignored or the packet must be dropped.(4)
Extension headers force the packet byte offset of the layer 4 header (typically a TCP or UDP header) to be shifted from its usual packet offset immediately after the main header. As a result, it is possible for the layer 4 header to appear at a variety of packet offsets into the packet.
In IPv4, if there are options present, the location of the layer 4 header will be at the offset indicated by the header length field. In IPv6, if a network device is to correctly detect the layer 4 header for an IPv6 packet with extension headers, it must parse the extension header chain until it reaches the layer 4 header. Some network devices are incapable of traversing the list of extension headers, with the result being that the network device either incorrectly identifies what it thinks is the layer 4 header or it doesn’t identify the layer 4 header information at all. In some cases, the network device may only be capable of parsing a specific number of extension headers or it may stop evaluating extension headers past a specific byte offset.(5)
Filters that make decisions based upon layer 4 information may fail if the network device or its software cannot parse extension headers. Other devices may evaluate packets with extension headers in a slower software processing mode, which can reduce the packet processing capabilities of the device. When purchasing a network device, it is important to confirm that the device can identify layer 4 headers at a variety of offsets in the packet and to confirm what performance penalties may occur if the device has to examine extension headers in packets.
The extent to which a router will attempt to process and report extension header or layer 4 information in flow varies. The Netflow v9 standard, as described in IETF RFC 3954(6), describes an “IPv6 option headers” field that is used for encoding which extension headers were observed in the packet. Not all router vendors implement this field. IPFIX provides a similar field and is described in IANA document “IP Flow Export (IPFIX) Entities“. Some router operating systems are unable to report layer 4 information when one or more extension headers are present.
In theory, extension headers allow for adding new functionality to IPv6. In reality, it is hard to create and implement new extension headers because of the lead time that network device implementers need to update their hardware and software. Many network devices will drop any packets with extension headers that aren’t recognized by the device. There will be a continual trade-off between the introduction of new extension headers to IPv6 and the cost to network device creators and maintainers of adding support for the new extension header.
Around 2002, I attended a presentation prepared by a systems engineer for a router manufacturer, in which the presenter argued that due to the obscure nature of extension headers and the inherent opportunities for problems, that extension headers should be eliminated. I have not heard anyone seriously suggest outright elimination of extension headers since, because some extension headers provide essential functionality in IPv6. But extension headers are still generally despised for how they complicate the IPv6 protocol.
SOURCES:
1. IETF RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” Deering, S and Hinden, R, December 1998.
2. IETF RFC 4302, “Authentication Header,” Kent, S, December 2005 and IETF RFC 4303, “IP Encapsulating Security Payload (ESP),” Kent, S, December 2005.
3. “Old IPv4 flaws resurface with IPv6,” Iljitsch, Ars Technica, May 2007. http://arstechnica.com/hardware/news/2007/05/old-ipv4-flaws-resurface-with-ipv6.ars
4. IETF RFC 5095, “Deprecation of Type 0 Routing Headers in IPv6”, Abley, J, Savola, P, and Neville-Neal, G, December 2007.
5. Arguably, from a purely functional point of view, routers, don’t need to parse extension headers; however where routers implement packet filtering based on header content, routers really must be able to parse extension headers.
6. IETF RFC 3954, “Cisco Systems NetFlow Services Export Version 9,” Claise, B, Editor, October 2004
Leave a reply
