Filtering IPv6 extension headers is sometimes necessary

Filtering IPv6 extension headers is sometimes necessary

Technology News


A recent study by the IETF has shown that IPv6 packets sent to public Internet servers suffer a packet drop rate between 10% to more than 50% when they employ extension headers. Such widespread filtering is generally seen as undesirable, since it hinders not only future extensions of the IPv6 protocol, but also the use of basic functionality, such as IPsec or even IPv6 fragmentation.

While undesirable from the user’s perspective, filtering IPv6 extension headers can also be considered a pragmatic approach to the security and operational implications associated with these headers, as well as common network devices and setups. Why is this so? There are security and operational considerations, among other factors, that explain why operators may have valid reasons for dropping IPv6 packets that contain IPv6 extension headers.

Security implications of IPv6 extension headers

The security implications of IPv6 extension headers have been covered in detail in previous articles. They can be summarized as follows:

  • Evasion of security controls
  • Denial-of-service conditions due to implementation errors
  • Denial-of-service conditions due to processing requirements
  • Issues that are specific to each extension header

IPv6 extension headers also have operational implications that may be challenging (if at all possible) to overcome with current implementations.

Flaws in security products, in addition to the inability of some products to properly process IPv6 extension headers, may allow the evasion of security controls. The complexity associated with processing these extension headers has also resulted in implementation errors that can be leveraged for performing denial-of-service (DoS) attacks.

Additionally, some router implementations can only process packets with extension headers on the slow path; thus, IPv6 packets that use extension headers can also be leveraged for performing DoS attacks due to the associated processing requirements. Finally, filtering Pv6 extension headers can prevent the fragment header from being used for resource-exhaustion attacks and some routing header types (such as the deprecation of type 0) from being leveraged for amplification attacks.

Operational implications of IPv6 extension headers

IPv6 extension headers also have operational implications that may be challenging (if at all possible) to overcome with current implementations. Some of the operational reasons for which operators may drop IPv6 packets that contain extension headers are:

Infrastructure ACLs are meant to drop unwanted packets destined to parts of a provider’s infrastructure where they are not operationally needed and can be used for attacks against the router’s control plane. Customer DDoS protection filters are similar in nature to the infrastructure ACL protection; Layer 4 ACLs generally need to be applied as close to the edge of the network as possible, even though the intent is to protect the customer edge rather than the provider core.

In the case of ECMP load sharing, a router needs to make a decision regarding which of the links to use for each outgoing packet. Most forwarding engines achieve this by computing a simple hash function using the source and destination IPv6 addresses and some Layer 4 information, such as the source and destination transport protocol port numbers. However, the use of extension headers may, for example, prevent the forwarding device from gleaning the transport protocol port numbers.

Finally, we note that most modern router implementations use dedicated hardware to determine how to forward packets across their internal fabrics. Such implementations can only look into a limited number of bytes into the packet (e.g., 128 bytes). Thus, if a hardware-forwarding engine on a modern router cannot make a forwarding decision about a packet because critical information is past the aforementioned implementation-specific limit, the router will normally drop the packet.