IPv6 has been gaining traction since it was introduced and was intended as a solution to IPv4 address space constraints and security issues. Despite the clear advantages of the protocol, adoption of IPv6 throughout the industry has been hindered by a few factors, including misperceptions in IPv6 extension header use. What can we do to improve this?
Although an important part of IPv6’s planned flexibility, extension headers may hinder deployment for some. This article will analyse the reasons for this situation from several perspectives and make some suggestions that may help to improve the situation.
Challenges of IPv6
There are several perceived challenges with IPv6. The first is that IPv6 has a higher round-trip time (RTT) than IPv4 currently. According to Xipeng Xiao’s report at IETF 113, IPv6 RTT is decreasing worldwide, but the average is still 2.5ms higher than that of IPv4.
Additionally, according to RFC 7872 and RFC 9098, IPv6 is 2.5 times higher than IPv4 in terms of packet loss as a rate comparison.
Additionally, data from March 2022 shows that IPv6 has nearly four times the TCP failure rate of IPv4. The reason for the high IPv6 TCP failure rate may be due to the higher packet loss rate of IPv6. The high IPv6 packet loss rate may be due to the use of IPv6 extension headers, packet fragmentation, or filtering mechanisms that trigger as a result of either or both.
Let’s look at some of the potential issues with extension headers.
IPv6 vs IPv4
In some respects, IPv6 is designed to be a more processor-friendly protocol than IPv4. In particular, IPv4 headers are variable length, while IPv6 headers are fixed length. IPv6 also organizes its options in a fixed ‘stride’ packet structure for faster off-the-wire processing of the header and associated options.
In other respects, IPv6 presents a bigger challenge than IPv4. IPv6 has more options due to its greater scalability. The IPv6 header chain can get large enough to trigger some of the more costly problems in packet processing when the headers exceed the capacity of the forwarding engine to store them.
Potential issues of IPv6 extension headers
Extension headers, other than the Hop-by-Hop (HBH) Options header, are not processed, inserted, or removed by any node until the packet reaches the destination node, but this is a potential problem because both stateful and stateless firewalls should check them. Also, the destination node MUST accept and process the extended header in any order and any number of occurrences in the same packet. If the extension header is too complex, it will put processing pressure on the destination node. With an unlimited number of options in the extension header and an unlimited number of extension headers — without a specific order of extension headers — it will be a disaster for the destination in terms of processing cost and delay.
Path MTU discovery as an HBH function
IPv6 packets that carry the HBH option are not arbitrarily discarded by devices on the path or by the destination host. All forwarding devices should recognize this HBH option and update the Min Path MTU field when forwarding IPv6 packets that contain this HBH extension header.
All IPv6 hosts recognize this HBH option and receivers should echo all received path MTU HBH options values back to the sender as determined by the control flag. All IPv6 hosts should make local adjustments to their stored value of path MTU by this received MTU information. So, all IPv6 protocol implementations need to support a socket option to allow upper-layer protocols to request this path MTU probe function.
Suggested HBH handling procedure
The first suggested mechanism to improve extension header handling is source HBH option header encapsulation. When the source HBH option header is encapsulated, if there is no HBH option header to be filled, it is marked as ‘passed’ by default, and when there is an HBH option to be filled, it is marked as needing to be processed. The information to be carried in the HBH option header needs to be classified first, then encapsulated into control options or forwarding options, and finally encapsulated in different data packets.
This leads naturally to the cost of HBH processing at the edge nodes of the network. Edge nodes should check whether the packet contains an HBH header with control options or forwarding options. Packets with forwarding options should be allowed by the Access Control List (ACL), and packets with only control options are handled at the discretion of the node.
Reasons for IPv6 fragmentation loss
Firewalls are often configured to drop fragments. Network equipment may be configured to drop all IPv6 packets that contain Extension Headers. Network equipment may pass packets with Extension Headers to a ‘slow path’ processing, and this may have an associated queue build-up and cause sporadic loss There may be path MTU issues where larger packets are being dropped.
| Code | Region | Fragmentation drop rate | IPv6 samples |
| XA | World | 6.68% | 23,209,746 |
| XC | Americas | 10.94% | 6,274,581 |
| XB | Africa | 9.50% | 126,575 |
| XE | Europe | 9.33% | 2,532,014 |
| XF | Oceania | 6.62% | 75,380 |
| XG | Unclassified | 5.39% | 21,213 |
| XD | Asia | 4.29% | 14,179,983 |
Why is IPv6 extension header usage so low?
Extension headers require complex processing and have the potential to become a DoS vector. To mitigate this, many network operators deploy ACLs to drop packets containing extension headers. Since network operators deploy ACLs that drop packets containing extension headers, network protocol designers and engineers no longer define new extension header-dependent applications. With network engineers no longer defining new extension header applications, there is little incentive to fix the implementation issues that made extension headers a DoS vector. This is a vicious circle that is hard to break and will represent a barrier to extension header adoption in the future. It is already discouraging IPv6 adoption.
The flexibility of TLVs vs the fixedness of chips
A network processor chip that needs to process a large amount of traffic-forwarding data is quite different from other chips. This data is far greater than the data processed in the devices such as CPU, memory, and flash. It requires that the logic for chip hardware processing must be as simple as possible, otherwise, the efficiency of data traffic forwarding will become a problem. As a network processor’s flexibility decreases, its efficiency increases. The trick for vendors is to balance cost and performance.
For protocol designers, optional type-length-value (TLV) fields are more attractive. Flexible TLV fields allow protocols to be suitable for future needs. But for people who have to check for TLV presence in the fast path (inside FPGA and ASIC chips close to the line card, rather than in the core CPU of the router), and potentially parse an indeterminate number of TLVs, optional TLV fields will affect the speed of chip processing data.
This has inspired the growth of companies that are engaged in open-source programming for network chips, such as Barefoot Networks. The Barefoot Tofino is a programmable chip that can achieve up to 6.5TBPS processing speed. Users or network suppliers can use the P4 programming language to customize ‘white box’ solutions or fixed configuration products. Users can deploy new agreements within a few weeks without the need for new versions of chips to support them, providing great flexibility.
Suggestions
Based on the above discussion, we may be able to take the following approaches to avoid several problems caused by using extension headers:
- Secure the control plane. Once the packet is received by the network device, the extended options header should not be sent directly to the control plane, as these options may not be specific to the control plane. Extended options headers that should not be processed by the control plane should not be sent to the control plane, as this could potentially cause a DoS attack.
- Forwarding decisions must be appropriate for critical data, otherwise, they can result in additional processing behaviour for intermediate routers, which can lead to increased latency or even increased packet loss.
- Fixed-length headers are easier to parse, TLVs are highly scalable, and most people want to use the customizable features of TLVs. But for intermediate routers that require header processing, using fixed-length headers is the best choice.
- Use an established header in a novel way instead of inventing a new one. Considering the diversity of extension headers, we should use already existing extension headers in new ways. Redefining new headers will undoubtedly increase the processing behaviour of intermediate routers, which is undoubtedly detrimental to the rollout of extension headers (a significant overhead for both protocol stack and hardware changes).
- Manage header size. To avoid (as much as possible) the extension header becoming a vector for DoS attacks, we needed to increase the size of the header as well as the number of options. After all, no one wants to deal with an unknown packet that could seriously affect their network performance.
- Determine the order in which extension headers appear, let pipeline processors parse the packet before starting any lookup, and avoid any additional indirection inserted into this parsing process. After all, the router’s task is to deliver incoming packets as quickly as possible, using a header sequence defined in advance to minimize its processing time and complexity.
To better use and promote IPv6 extension headers, we need to make a clear definition of the extension header structure and consider the processing of extension headers by the target or intermediate nodes. The challenge is not just to think through the whole process of using extension headers but also to improve their performance and backward compatibility, which is perhaps more important.
Watch Haisheng (Johnson) Yu’s APNIC 54 presentations here:
Thanks to Aftab Siddiqui and Di Ma for helping prepare this report at the Routing Security SIG meeting during APNIC 54. Thanks also to Geoff Huston, John Scudder, and Xipeng Xiao, whose work I’ve referenced, and to Zhixian Liu’s input on this post.
Dr. Haisheng (Johnson) Yu is the director of Prospective Technology Laboratory, China Future Internet Engineering Center, engaged in the research of IPv6, DNS, SDN, and cloud computing.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.