Problem Statement with Aggregate Header Limit for IPv6

Introduction The introduction of IPv6 extension headers, especially SRH, and some advanced features/functions have increased the total packet header chain size greatly, which may cause inefficient packet processing due to the header chain size exceeding the processing limit of the router. As in , some hardware devices implement a parsing buffer of a fixed size to process packets. The parsing buffer is expected to contain all the headers that a device needs to examine. If the aggregate length of headers in a packet exceeds the size of the parsing buffer, a device will either discard the packet or defer processing to a software slow path. proposes the concept "aggregate header limit" to indicate this size limit. As per , an ICMPv6 Destination Unreachable error with code for "Headers too long" SHOULD be sent when a node discards a packet because the aggregate length of the headers in the packet exceeds the processing limits of the node. also mentions that due to packet-forwarding engine constraints, if an IPv6 header chain is sufficiently long such that it exceeds the packet lookup capacity of the router, the router might be unable to determine how the packet should be handled and thus could resort to dropping the packet. And some packet-forwarding engines manage IPv6 header chains using recirculation, but recirculation can impact the forwarding capacity of hardware, as each packet will pass through the processing engine multiple times. defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. It provides the minimum baseline of support for use of extension headers on the Internet. The default limit for the IPv6 header chain is 104 bytes,including 64 bytes of extension headers, which is far more than enough for some usecases. Before discussing the problem, this document proposes the concept of Aggregate Header Limit for IPv6 as below: "Aggregate Header Limit for IPv6 (AHL-IPv6) is the total header size(i.e, from the IPv6 header chain as well as any headers that are part of network encapsulation up to the innermost transport layer) that a router is able to process at full forwarding rate(e.g, at fast path). For some devices designed with parsing buffer, this limit is related with its buffer size and buffer design." The different between AHL-IPv6 and the existing concepts:

Difference with Aggregate Header Limit(AHL) introduced in RFC8883: There's not a clear definition for AHL in RFC8883. If AHL is understood as the total header size that a router is able to process at full forwarding rate, the values of AHL and AHL-IPv6 may be the same or may be difference based on router design.
Difference with extension header chain size limit, the extension header chain size is no bigger than aggregate header size since the packet may contain upper layer headers.As mentioned in , the intermediate nodes/systems may need to process Layer 3/Layer 4 information to make a forwarding decision, in this case, even the extension header chain size limit is not exceeded, an intermediate node may drop the packet due to AHL-IPv6 exceeding.

This document describes the problems for path calculation and function enablement without the awareness of AHL-IPv6, and the considerations for AHL-IPv6 collection are also included.

Conventions used in this document

Terminology MSD: Maximum SID Depth as in . AHL-IPv6: Aggregate header limit for IPv6. It's the total header size(i.e, from the IPv6 header chain as well as any headers that are part of network encapsulation up to the innermost transport layer) that a router is able to process at full forwarding rate(e.g, at fast path). For some device designed with parsing buffer, this limit is related with its buffer size and buffer design. The terminology defined in are used in this document as below: Forwarding Plane: IPv6 routers exchange user or applications data through the forwarding plane. Routers process fields contained in IPv6 packet headers. However, they do not process information contained in packet payloads. Control Plane: Routers exchange management and routing information. They also exchange routing information with one another. Management and routing information are processed by its recipient. Management and control information can be forwarded by a router that process fields contained in packet headers. Fast Path: A path through a router that is optimized for forwarding packets. The Fast Path might be supported by Application Specific Integrated Circuits (ASICS), Network Processor (NP), or other special purpose hardware. This is the usual processing path within a router taken by the forwarding plane. Slow Path: A path through a router that is capable of general purpose processing and is not optimized for any particular function. This processing path is used for packets that require special processing or differ from assumptions made in Fast Path heuristics or to process router control protocols used by the control plane. Full Forwarding Rate: This is the rate that a router can forward packets without adversely impacting the aggregate forwarding rate. For example, a router could process packets at a rate that allows it to maintain the full speed on its outgoing interfaces, which is sometimes called "wire speed".

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement The introduction of IPv6 extension headers, especially SRH, and some further features/functions have increased the total packet header chain size greatly. Following are some possible scenarios that would greatly increase the difficulty of efficient packet processing from the aspects of total header size increasing.

Unlike MPLS, even as an intermediate endpoint, the total SRH should be withine the processing buffer to achieve efficient packet forwarding. And SRH itself may carry additional TLVs for additional functions, e.g, the SRH Opaque Metadata TLV and NSH Carrier TLV for SR service programming . Besides the headend node, the intermediate nodes may push extra header to the packet as well. For example, for Binding SID, an SR Segment Endpoint nodes would push a new IPv6 header with its own SRH containing an segment list above the original IPv6 header. And in the case of TI-LFA , the PLR node may push a repair SID list to the original packet.
For network performance measurement, several functions have been defined. For IPv6 IOAM pre-allocated trace, the headend attachs the hop-by-hop/destination options header with the IOAM data fields as introduced in . And to implement the Alternate-Marking Method in IPv6, the AltMark Option is carried by the Hop-by-Hop Options Header or the Destination Options Header.
To improve the service capability of the network, features like network slicing and detnet are proposed. For network slicing, the VTN Option in IPv6 Hop-by-Hop option are provided . For detnet, there're discussion on carrying detnet related within the IPv6 extension headers, either as SRH TLV [draft-wang-detnet-tsn-over-srv6] or as Destination Options and Hop-by-Hop Options [draft-xiong-detnet-6man-queuing-option].

Most of the functions mentioned above are not mutually-exclusive, the possibility of combination of extension headers/TLVs would make total header size even bigger. Normally, there're different models/versions of network devices(i.e, switches, routers) from multiple vendors in an operator's network, different devices may have different aggregate header limits and different behaviors after aggregate header limit exceeding. As more and more functions mentioned above are superimposed in the operator's network, packet dropping or rate limiting due to AHL exceeding is a potential risk, which makes it difficult to management the network. Path calculation, whether by the controller or the headend, without the awareness of AHL of the nodes in the network and the prediction on which features would be enabled along the path, may result in a path with nodes with lower AHLs than required. If the controller is aware of aforesaid information, e.g, when calculation certain path for SR Policy, and the controller knows that and per-hop IOAM and network slicing would be enabled for this SR Policy, the controller would leave out the space for HBH header with options for IOAM and VTN-ID and to ensure that the packet header size wouldn't exceed the AHLs of the intermediate segment endpoints along the list. The situation is similar for packet encapsulation triggered by function enablement, whether on the headend or the intermediate nodes, packets may be encapsulated with larger header size than the downstream nodes able to process. If AHL-IPv6 information of the nodes/path can be obtained in advance, when the node needs to attach extra data along the existing path, and the aggregate header limit of the downstream nodes along the path are not sufficient to process the headers, the node may choose to not to use the related function and log an error.

AHL-IPv6 Collection Considerations As per , an ICMPv6 Destination Unreachable error with code for "Headers too long" SHOULD be sent when a node discards a packet because the aggregate length of the headers in the packet exceeds the processing limits of the node. Base on this definition, obtaining the minimum AHL along the path can be achieved by sending detection messages of certain size and receiving the ICMPv6 error messages, which is similar with path MTU discovery for IPv6 in RFC8201. This mechanism may works for small networks with static paths in it. But there may be some problems in the following scenarios:

When the number of paths increases, more and more detection messages need to be sent, and the burden of processing the received ICMPv6 error messages also increases.
For SR dynamic candidate paths , the segment lists of the paths may change over time, which makes it more difficult to detect the AHL-IPv6s.

leverages an Hop-by-Hop Option to collect the limit(i.e, minimum path MTU) along the path. An Hop-by-Hop Option for AHL-IPv6 collection purpose might be another option taking example by RFC9268. This mechanism works for some cases. But in SRv6, there might be transit routers who just forward the SRv6 packets like normal IPv6 packets without inspecting into the extension header chain. Even if the AHLs of these nodes have smaller AHLs than other nodes, the SRv6 packets would still be processed normally along the path. In this case, if mechanism like RFC9268 is used, the AHL of the path be collected would be one of the AHLs of these transit nodes, but actually packets with larger header chain size could be sent and processed normally. Signaling could be another option. Considering that there're already mechanisms like IGP-MSD to advertise certain size limit at per node and per link basis. The mechanism for advertising AHL-IPv6 is similar with IGP-MSD. In the inter-domain scenario, the BGP signaling may help as well.For the controller, it can get the AHLs of the nodes in the network via BGP-LS, YANG or other south-north mechanisms.The details of signaling mechanism is out of the scope of the document and would be discussed in separated documents.

IANA Considerations This document makes no request of IANA.

Security Considerations This document does not introduce any new security issues.

Acknowledgement The authors would like to thank Tom Herbert, Alvaro Retana, Eric Vyncke, Jeff Tantsura, Sasha Vainshtein and Acee Lindem for their helpful comments and suggestions.