| Internet-Draft | IPv6 Maximum Header Size | October 2023 |
| Liu & Shen | Expires 21 April 2024 | [Page] |
This document proposes the concept and the requirement of IPv6 Maximum Header Size to represent the total header size that a node is able to process from an incoming packet in IPv6, as well as the requirement for it.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In terms of packet processing, a device has various capabilities. For IPv6 routers, one of the capabilities is the Maximum Header Size that a node can read and process from an incoming packet. And the Maximum Header Size include the IPv6 header and IPv6 extension header.¶
The introduction of IPv6 extension headers especially SRH, has increased the packet header size greatly. And the possibility of combination of extension headers packets makes the situation worse.¶
Without the knowledge of the processing abilities of downstream nodes, the total header size of the packets sent by the upstream may exceed the Maximum Header Size that the downstreams can process, which may cause the packets to be discarded.¶
Although for some network devices, even when the size of the header accepted exceeds the header processing buffer of the device, they can still try to process this packet by recycling, but it's an impact of packet forwarding efficiency.¶
So for efficient packet forwarding, in many cases it's very important to know the maximum header size that each downstream nodes is able to process at full forwarding rate.¶
Although there're already some related works on packet processing size, but they are not sufficient.¶
The concept Maximum SID Depth (MSD) is originally introduced for SR-MPLS to represent the number of SIDs supported by a node or a link on a node. MSD is further extended for SRv6 as per [RFC9352]. This can be collected via IS-IS [RFC8491], OSPF [RFC8476], BGP-LS [RFC8814], or PCEP [RFC8664].¶
MSD types for SRv6 are related with the number of SRv6 SIDs, but other components within SRH such as SRH TLVs are not in the scope of MSD. Not to speak of other IPv6 extension headers.¶
Based on the considerations above, this document defines the term "IPv6 Maximum Header Size", which means, the maximum packet size, starting from the IPv6 header, that a node is able to process at full forwarding rate from an incoming IPv6 packet. And the signaling requirement is also included.¶
MSD: Maximum SID Depth as in [RFC8491].¶
Full Forwarding Rate: As in [I-D.ietf-6man-hbh-processing] this is the rate that a router can forward packets without adversely impacting the aggregate forwarding rate.¶
MPD: Maximum Packet Depth supported by a node or a link on a node.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The headend node can attach data on the packet.¶
For SRv6 IOAM pre-allocated trace, the headend attachs the hop-by-hop options header with the IOAM data fields ahead of SRH as introduced in [RFC9486].¶
In the case of SR service programming[I-D.ietf-spring-sr-service-programming], the SRH Opaque Metadata TLV and NSH Carrier TLV may be inserted by the headend.¶
For network slicing purpose, the VTN Option in IPv6 Hop-by-Hop option may be carried in the packet [I-D.ietf-6man-enhanced-vpn-vtn-id].¶
And all the above functions may be used in combination.¶
The intermediate nodes may increase the size of the packet. The IPv6 extension headers, as well as their TLVs may be attached by the intermediate destination nodes(e.g SR Segment Endpoint nodes) via inserting or tunneling. In this case it is very important for attaching nodes to obtain the packet processing sizes of the downstream nodes.¶
For an SR Segment Endpoint nodes with an End.B6.Encaps[RFC8986] SID instantiated, it will push a new IPv6 header with its own SRH containing an segment list above the original IPv6 header.¶
Based on the usecases, there're requirements for the headend and intermediate nodes to be aware of the IPv6 Maximum Header Size of other nodes.¶
Considering of the exsiting works for MSD in IGP [RFC8491][RFC8476], using IGP to advertise this capability at node and/or link granularity is an feasible solution.¶
BGP-LS MAY also needed if there's an controller needs to collect this information and it does not participate in IGP routing.¶
This document makes no request of IANA.¶
TBD¶