Network Working Group F. L. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Experimental T. Herbert Expires: 23 October 2025 Unaffiliated 21 April 2025 IPv6 Extended Fragment Header (EFH) draft-templin-6man-ipid-ext2-11 Abstract The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification with efficient fragmentation and reassembly procedures. Status of This Memo 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 23 October 2025. Copyright Notice Copyright (c) 2025 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 Templin & Herbert Expires 23 October 2025 [Page 1] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Extended Fragment Header (EFH) . . . . . . . . . . . . . 5 5. IPv6 Source Fragmentation . . . . . . . . . . . . . . . . . . 7 6. IPv6 Intermediate System Fragmentation . . . . . . . . . . . 8 7. IPv6 Destination Reassembly . . . . . . . . . . . . . . . . . 8 8. Destination Qualification and Path MTU . . . . . . . . . . . 9 9. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 9 10. Fragmentation Reports and Retransmissions . . . . . . . . . . 10 11. Multicast and Anycast . . . . . . . . . . . . . . . . . . . . 11 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Relation to GSO/GRO . . . . . . . . . . . . . . . . . . . . . 13 14. A Note on Fragmentation Considered Harmful . . . . . . . . . 14 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 16.1. IPv6 Parameters . . . . . . . . . . . . . . . . . . . . 14 16.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . 15 16.3. ICMP Parameters . . . . . . . . . . . . . . . . . . . . 15 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 19.1. Normative References . . . . . . . . . . . . . . . . . . 16 19.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets [RFC0791], but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks [RFC4963][RFC6864][RFC8900]. For Internet Protocol, version 6 (IPv6), the Identification field is only present in packets that include a Fragment Header [RFC8200], but even its standard length of 32 bits may be too small for some applications such as those that regard the Identification value as a sequence number. This specification therefore defines a means to extend the IPv6 Identification length to 64 bits through the introduction of a new IPv6 Extended Fragment Header (EFH). Templin & Herbert Expires 23 October 2025 [Page 2] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 The IPv6 EFH employs a fragmentation/reassembly algorithm based on an ordinal fragment index in combination with the non-final fragment payload size instead of a 13-bit integer encoding an 8-octet offset. In this arrangement, both fragmentation and reassembly are greatly simplified allowing for efficient implementations. These improvements are based on an ample minimum fragment payload size made possible by the 1280 octet IPv6 minimum MTU. The IPv6 EFH may be useful for networks that engage fragmentation and reassembly at extreme data rates, or for cases when advanced packet Identification uniqueness assurance is critical. (The placement of the IPv6 EFH in a Destination Options header may also make the option less prone to network filtering.) This specification further defines a messaging service for adaptive realtime response to loss and congestion related to fragmentation/reassembly. Together, these extensions support robust fragmentation and reassembly services as well as packet Identification uniqueness for IPv6. The IPv6 EFH 64-bit Identification is in principle analogous to the Extended Sequence Number (ESN) supported by IPsec AH [RFC4302] and ESP [RFC4303]. When transmitting the full 64-bit Identification may be wasteful, nodes can apply header compression techniques to transmit only the least significant bits while retaining the full 64-bit value in cache memory. 2. Terminology The terms "Maximum Transmission Unit (MTU)", "Effective MTU to Receive (EMTU_R)", "Effective MTU to Send (EMTU_S)" and "Maximum Segment Lifetime (MSL)" are used exactly the same as for standard Internetworking terminology [RFC1122]. The term "Maximum Reassembly Unit (MRU)" is equivalent to EMTU_R, and the term "maximum datagram lifetime (MDL)" (defined in [RFC0791][RFC6864]) is equivalent to MSL. The term "Packet Too Big (PTB)" refers to an ICMPv6 "Packet Too Big" [RFC8201][RFC4443] message. The term "flow" refers to a sequence of packets sent from a particular source to a particular unicast, anycast or multicast destination that a node desires to label as a flow per [RFC6437]. The term "Extended Fragment Header (EFH)" refers to a new IPv6 Destination Option as specified in this document. The EFH is included in a Destination Options header as the final Per-Fragment header, while the remainder of the packet that follows the Per- Fragment headers is known as the "fragment payload". Templin & Herbert Expires 23 October 2025 [Page 3] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 The term "Fragmentation Report (FR)" refers to an alternate option type encoding of the EFH option. Destinations may include the FR in return packets to sources of EFH fragments. The Automatic Extended Route Optimization (AERO) [I-D.templin-6man-aero3] and Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni3] services employ the IPv6 EFH for secure adaptation layer encapsulation and fragmentation. New packet types known as IP Parcels and Advanced Jumbos (AJs) are specified in [I-D.templin-6man-parcels2]. 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. 3. Motivation Upper layer protocols can achieve greater performance by configuring segment sizes that exceed the path Maximum Transmission Unit (MTU). When the segment size exceeds the path MTU, lower layer IP fragmentation is a natural consequence. However, the 4-octet (32-bit) Identification field of the Fragment Header may be too small to ensure reassembly integrity at sufficiently high data rates, especially when the source resets the starting sequence number often to maintain an unpredictable profile [RFC7739]. This specification therefore proposes to fortify the IPv6 Identification by extending its length. Performance increases for upper layer protocols that use larger segment sizes was historically observed for NFS over UDP, and can still be readily observed today for TCP and the Delay Tolerant Network (DTN) Licklider Transmission Protocol (LTP) as reported in [I-D.templin-dtn-ltpfrag]. The test setup included a pair of modern high-performance servers with 100Gbps Ethernet cards connected via a point-to-point link and running a modern public domain linux release. TCP performance using the public domain 'iperf3' tool was proven to increase when larger user buffer sizes are used even if they exceed the path MTU and invoke a service known as Generic Segment/Receive Offload (GSO/GRO). LTP performance with segment sizes that exceed the path MTU was similarly proven using the HDTN and ION-DTN LTP implementations which engage IP fragmentation and reassembly. In addition to accommodating higher data rates in the presence of fragmentation and reassembly, extending the IPv6 Identification can enable other important services. For example, an extended Identification can enable a duplicate packet detection service where Templin & Herbert Expires 23 October 2025 [Page 4] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 the network remembers recent Identification values for a flow to aid detection of potential duplicates. When an encapsulation source includes an IPv6 EFH, the extended Identification can also serve as a sequence number that allows each encapsulation destination to exclude any packets with values outside of the current sequence number window for a flow as potential spurious transmissions. An optimized IP fragmentation and reassembly service using an extended Identification can provide a useful tool for performance maximization in the Internet. This document therefore presents a means to extend the IPv6 Identification in a more efficient fragmentation and reassembly specification to better support these services through the introduction of an IPv6 Extended Fragment Header (EFH). 4. IPv6 Extended Fragment Header (EFH) For a conventional 4-octet IPv6 Identification, the source can simply include a standard IPv6 Fragment Header as specified in [RFC8200] with the Fragment Offset field and M flag set either to values appropriate for a fragmented packet or the value 0 for an unfragmented packet. The source then includes a 4-octet Identification value for the packet. For an extended Identification, advanced fragmentation and reassembly procedures and/or for paths that drop packets including the standard IPv6 Fragment Header, this specification permits the source to instead include an IPv6 EFH. The source includes the IPv6 EFH in a Destination Options Header positioned as the final IPv6 Per-Fragment Header. The remainder of the packet beyond the EFH beginning with the Extension and Upper Layer Headers for the first fragment or protocol data for non-first fragments is known as the fragment payload. The Destination Options header that includes the EFH option therefore appears in each fragment in the same position where the standard Fragment Header would normally appear while the Fragment Header itself is omitted - see Sections 4.1 and 4.5 of [RFC8200]. The IPv6 EFH Destination Option is formatted as shown in Figure 1: Templin & Herbert Expires 23 October 2025 [Page 5] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH-Actual | Reserved |P|M| Index |D|N| Sub-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+- Identification (64 bits) -+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit value 'XX0[TBD1]'. Opt Data Len 8-bit value 12. NH-Actual the actual value of the original Destination Options Next Header prior to fragmentation. Reserved an 8-bit Reserved field. Initialized to zero on transmission; ignored on reception. P/M/Index a 6-bit "Index" field that identifies the ordinal index for each fragment payload, preceded by a 1-bit "(P)robe" flag and a 1-bit "(M)ore Fragments" flag. R/N/Sub-Index a 6-bit "Sub-Index" field that identifies the ordinal index for each sub-fragment of the same original fragment, preceded by a 1-bit "(D)on't Sub-Fragment" flag (set to 0) and a 1-bit "(N)ext Sub-Fragment" flag. Identification an 8-octet (64 bit) unsigned integer Identification, in network byte order. Figure 1: IPv6 EFH Destination Option The IPv6 EFH Destination Option is therefore identified as an Option Type with the low-order 5 bits set to TBD1 (see: IANA Considerations) and with the third-highest-order bit (i.e., "chg") set to 1. The highest-order 2 bits (i.e., "act") are set to '01' or '1X' so that destinations that do not recognize the option will drop the packet or fragment either silently or while also returning an ICMPv6 Parameter Problem message. The Identification field is 8 octets (64 bits) in length and a Destination Options header that includes the option may appear either in an unfragmented IPv6 packet or in one for which IPv6 fragmentation is applied. Templin & Herbert Expires 23 October 2025 [Page 6] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 For improved efficiency, sources often send packets that include full IPv6 headers (including a full EFH) only as initial packets of a flow, while subsequent packets can include greatly compressed headers. When a flow becomes stale, the source can send additional full header packets to refresh flow state until header compression can resume. The AERO/OMNI service is an example where the EFH is subject to efficient header compression. 5. IPv6 Source Fragmentation IPv6 fragmentation using the EFH is conducted in a similar manner as for standard IPv6 fragmentation (see: Section 4.5 of [RFC8200]) with the following exceptions. When the source performs fragmentation using the IPv6 EFH, it SHOULD produce the smallest number of fragments possible within current path MTU constraints and MUST produce no more than 64 fragments per packet. The fragment payload of each non-final fragment following the Destination Options header MUST NOT be smaller than 1024 octets, allowing for up to 256 octets of Per-Fragment headers plus any lower- layer IP encapsulations within the 1280 octet IPv6 minimum path MTU. Each non-final fragment payload MUST be equal in length, while the final fragment payload MAY be smaller and MUST NOT be larger. For each of the F fragments produced during fragmentation, the source writes an ordinal index number beginning with 0 in the "Index" field for the first fragment and increasing by 1 for each successive non- first fragment while setting the "M" flag accordingly. Specifically, the source sets (Index, M) to (0, 1) for the first fragment, (1, 1) for the second, (2, 1) for the third, etc., up to and including ((F-1), 0) for the final fragment. The source also sets (Sub-Index, N) to (0, 0) in all fragments. For each fragment, the source also sets or clears the D flag according to whether it wants to permit intermediate systems to perform further fragmentation if necessary - see below and Section 6. Intermediate systems MUST NOT perform further fragmentation on fragments with the D flag set. For each fragment produced during fragmentation, the source inserts a Destination Options header including the IPv6 EFH option as the final Per-Fragment header. The source then caches the Destination Options header Next Header value in the NH-Actual field and (for each non- first fragment) resets the Next Header field to "No Next Header". Intermediate systems that forward non-first fragments prepared in this way will therefore ignore the fragment payload that follows (by virtue of the "No Next Header" setting) unless they are configured to more deeply inspect the data content. Templin & Herbert Expires 23 October 2025 [Page 7] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 After performing source fragmentation but before releasing the fragments, the source may become aware that the path and/or path MTU has changed. If so, the source can perform further fragmentation for each original fragment by producing "S" minimum-length sub-fragments under the same procedures above, with non-final sub-fragment payloads equal in length and no smaller than 1024 octets. The source MUST write the same (NH-Actual, Index, M) values into each sub-fragment while setting (Sub-Index, N) to (0, 1), (1, 1), (2, 1), etc. in each successive non-final sub-fragment and setting ((S-1), 0) in the final sub-fragment. The source also sets P to 0 in each sub-fragment and MUST NOT perform further fragmentation on sub-fragments that already include non-zero (Sub-Index, N) values. 6. IPv6 Intermediate System Fragmentation Section 4.5 of [RFC8200] states that: "unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers" however there are no protocol limitations to prevent an intermediate system along a packet's delivery path from performing further fragmentation if the Fragment Header is already present. Intermediate systems SHOULD NOT perform such further fragmentation unless loss due to a size restriction is imminent; in that case, the destination will reassemble correctly the same as if the additional fragments originated at the source. Similarly for packets that include an IPv6 EFH, when an intermediate system detects a path change and/or a path MTU reduction it MAY perform further fragmentation based on the (Sub-Index, D, N) fields. Otherwise, the intermediate system drops the fragment and returns a PTB message. If the D flag is clear, intermediate system procedures for performing further EFH fragmentation are identical to those specified for the source (see: Section 5). If the D flag is set, the intermediate system MUST NOT perform further fragmentation. The intermediate system therefore acts as a passive agent of the source according to the D flag and MUST NOT insert an EFH itself. 7. IPv6 Destination Reassembly IPv6 reassembly using the EFH is conducted in a similar manner as for standard IPv6 reassembly (see: Section 4.5 of [RFC8200]) with the following exceptions. When the destination receives original EFH fragments with the same (Source, Destination, Identification)-tuple, it reassembles by concatenating the payloads of consecutive fragments in ascending ordinal Index numbers, i.e., ordinal 0, followed by 1, followed by 2, Templin & Herbert Expires 23 October 2025 [Page 8] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 etc. until all fragments are concatenated. In the process, the destination discards any non-final fragments with fragment payloads less than 1024 octets in length or with fragment payload lengths that differ from the others. When the destination receives EFH sub-fragments that set (Sub-Index, N) to a value other than (0, 0), it first reassembles the original fragment by concatenating the payloads of each sub-fragment the same as described above. When the original fragment has been reconstructed, the destination submits it for fragment-level reassembly as described above. The destination should also return an indication to inform the source that the path may have changed (see: Section 10). 8. Destination Qualification and Path MTU Destinations that do not recognize the IPv6 EFH option drop the packet. If the Option Type "act" code is '1X', the destination also returns a Code 2 ICMPv6 Parameter Problem message [RFC4443]. (ICMPv6 messages may be lost on the return path and/or manufactured by an adversary, however, and therefore provide only an advisory indication.) The source can then test whether destinations recognize the IPv6 EFH option by occasionally sending "probe" packets that include the option. The source has assurance that a destination recognizes the option if it receives acknowledgments; otherwise, it may receive Code 2 ICMPv6 Parameter Problem messages as hints that a destination does not recognize the option. The source should re-probe destinations occasionally in case routing redirects a flow to a different anycast destination or in case a multicast group membership changes (see: Section 11). 9. Packet Size Issues When the source node sends fragment payloads larger than the minimum size of 1024 octets using the IPv6 EFH option, it should occasionally probe the path MTU per [RFC8899] by setting the P flag to 1 in probe first fragments, i.e., those with Index set to 0. When the destination receives a probe fragment, it returns an ICMPv6 Packet Too Big (PTB) message [RFC4443] [RFC8201] with Code set to "Probe Reply" (see: IANA Considerations) and MTU set to the probe fragment payload size. The source can then perform source fragmentation using the IPv6 EFH option with a maximum fragment payload size advanced to the size in the Probe Reply MTU field. Templin & Herbert Expires 23 October 2025 [Page 9] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 If the destination experiences reassembly congestion, it can begin returning ICMPv6 PTB messages to the source with Code set to "PTB Soft Error (loss)" or "PTB Soft Error (no loss)" (see: IANA Considerations) and with MTU set to a reduced size. When the source receives the PTB messages, it should temporarily reduce the size of its future transmissions to this destination but may resume using larger sizes if the PTB messages subside. If the source is an encapsulation ingress, it also returns a translated PTB message with a corresponding soft error Code to the original source per [RFC2473]. For IPv4 original sources, the translation uses a new ICMP message Type TBD2 and with a corresponding soft error Code (see: IANA Considerations). If an intermediate system detects a path change and can easily locate the IPv6 EFH included by the source, it can perform sub-fragmentation to produce sub-fragments that will not incur further MTU restrictions (see: Section 6). 10. Fragmentation Reports and Retransmissions End systems that recognize the IPv6 EFH also recognize an IPv6 Fragmentation Report (FR) Option that uses option type TBD1 the same as for the EFH itself except with the act code set to '00' and formatted as shown below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label (20 bits) |C| MRU (11 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+- Identification (64 bits) -+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +~+~+~+~ Bitmap (64 bits when present) ~+~+~+~+ | | +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ Figure 2: IPv6 Fragmentation Report Option The destination end system includes the IPv6 FR option in a return packet to the source to report reassembly congestion conditions and/ or fragment loss. Any return packet (i.e., one with the IPv6 Source and Destination Addresses from the packet that triggered the FR reversed) can be used to carry the option, especially if it includes identifying parameters and/or authentication signatures. Templin & Herbert Expires 23 October 2025 [Page 10] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 The destination sets Flow Label to the 20-bit Flow Label corresponding to this reassembly. The destination then sets the C flag to 1 if the path has changed as determined by the arrival of sub-fragments and sets MRU to the most significant 11 bits of the recommended 16-bit maximum reassembly size under current congestion conditions. When the 11 transmitted MRU bits are all-1's, the 5 untransmitted bits are also interpreted as all-1's; otherwise, they are interpreted as all-0's. If all fragments of the packet (or the unfragmented packet itself) have arrived the destination sets Opt Data Len to 12 and omits the Bitmap field. If some fragments are missing, the destination instead sets Opt Data Len to 20 and includes a 64-bit Bitmap field with Bitmap(i) (for i=0 to 63) set to 1 for each ordinal fragment index it has received for this reassembly and set to 0 for all others. When the source receives authentic IP packets with the IPv6 FR option, it should reduce the size of its continued packet transmissions for the flow if necessary according to the MRU. If the C flag is set, the source should reduce its fragment payload size to 1024 and again begin probing for larger sizes. If the option further includes a Bitmap, the source can retransmit any missing ordinal fragments if it still has them in its cache provided the delay would not interfere with upper layer protocol retransmissions. When the source receives IPv6 FRs that advertise a larger MRU (or when it ceases to receive IPv6 FRs), it can begin to increase its packet sizes for the flow. This ensures that the packet size is adaptive for a given flow. Note: the IPv6 FR option may appear in the same Destination Options header that includes an IPv6 EFH option. Their compact sizes permit both options to appear without exceeding recommended limits (see: [I-D.ietf-6man-eh-limits]). 11. Multicast and Anycast In addition to unicast flows, similar considerations apply for flows in which the Destination Address is multicast or anycast. Unless the source and all candidate destinations are members of a limited domain network [RFC8799] for which all nodes recognize the IPv6 EFH, some destinations may recognize the option while others drop packets containing the option and may return a Code 2 ICMPv6 Parameter Problem message [RFC4443]. When a source sends packets/fragments with IPv6 EFH options to a multicast group, the packets/fragments may be replicated in the network such that a single transmission may reach N destinations over Templin & Herbert Expires 23 October 2025 [Page 11] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 as many as N different paths. Some destinations may then return IPv6 packets with IPv6 FR options if they experience congestion and/or loss, while other destinations may return Code 2 ICMPv6 Parameter Problem messages if they do not recognize the IPv6 EFH option. While the source receives authentic PTB messages or authentic IP packets with IPv6 FR options, it should reduce the sizes of the packets/fragments it sends to the multicast group even if only one or a few paths or destinations are currently experiencing congestion. This means that transmissions to a multicast group will converge to the performance characteristics of the lowest common denominator group member destinations and/or paths. While the source receives ICMPv6 Parameter Problem messages and/or otherwise detects that some multicast group members do not recognize the IPv6 Extended Fragment Header option, it must determine whether the benefits for group members that recognize the option outweigh the drawbacks of service denial for those that do not. When a source sends packets/fragments with IPv6 Extended Fragment Headers option to an anycast address, routing may direct initial fragments of the same packet to a first destination while directing the remaining fragments to other destinations that configure the same address. These wayward fragments will simply result in incomplete reassemblies at each such anycast destination which will soon purge the fragments from the reassembly buffer. The source will eventually retransmit, and all resulting fragments should eventually reach a single reassembly target. 12. Requirements Normative aspects of standard IPv6 fragmentation and reassembly as specified in [RFC8200] apply also to the IPv6 EFH except where this document specifies differences. Destinations that accept flows using IPv6 EFH options MUST configure an EMTU_R of 65535 octets or larger. Sources MUST NOT include more than one IPv6 Standard or Extended Fragment Header in each IPv6 packet/fragment, and destinations MUST silently drop packets/fragments with multiples. If the source includes an IPv6 EFH, it MUST appear in a Destination Options header that appears as the final Per-Fragment header before the fragment payload. Sources that include an IPv6 EFH option MUST perform fragmentation such that at most 64 fragments are produced and all non-final fragments include equal-length fragment payloads no smaller than 1024 octets. The final fragment MAY be smaller and MUST NOT be larger. Templin & Herbert Expires 23 October 2025 [Page 12] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 Sources that include the IPv6 EFH option in packet transmissions MUST also recognize the IPv6 FR option in return packets as specified in Section 10. 13. Relation to GSO/GRO EFH fragmentation and reassembly operate on IPv6 packets that include a single upper layer protocol (ULP) segment with its corresponding ULP headers, e.g., TCP [RFC9293], QUIC/UDP [RFC9000], IPv6 [RFC2473], etc. This means that even for very large ULP segments only a single instance of ULP headers appears in the resulting sequence of interdependent fragments even if the segment size exceeds the path MTU. A widely-used service known as Generic Segment Offload (GSO) with its counterpart Generic Receive Offload (GRO) performs a similar fragmentation and reassembly service using the same algorithm specified for the EFH but with segment sizes no larger than the path MTU. GSO/GRO produce fragment sequences (independent packets, actually) that include a separate instance of the ULP headers in each packet instead of a single instance for the entire sequence. With a nominal ULP header size of 20 octets for TCP, this means that a 64-packet sequence would be required to carry 1260 redundant octets for each GSO/GRO transaction - a significant increase in overhead. When transport layer security encapsulations such as TLS/SSL are present, the ULP header overhead becomes greater still. ULP use of EFH fragmentation and reassembly in comparison with GSO/ GRO therefore requires an adaptive consideration of the packet loss profile for a given flow. Assuming a nominal path MTU (e.g., 1280 octets, 1500 octets, etc.) and with minimal packet loss, EFH with larger ULP segment sizes offers efficiency advantages in comparison with GSO/GRO with MTU-sized segment sizes. When packet loss levels increase, however, ULPs that use EFH should adaptively reduce their segment sizes to compensate. When loss levels become significant, ULPs that use both EFH and GSO/GRO may need to reduce their transmission rates until loss profiles improve. These adaptations are necessary to dynamically balance the flow's loss unit in relation to the retransmission unit under the current loss profile. Under larger path MTUs (e.g., 4500 octets, 9000 octets, or larger still), the two services converge to offer similar performance profiles at segment sizes no larger than the path MTU, while EFH can advance to still larger segment sizes for improved efficiency. EFH can also transport IP parcels and AJs (following IPv6 encapsulation) even if the underlying path does not support them natively. Templin & Herbert Expires 23 October 2025 [Page 13] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 14. A Note on Fragmentation Considered Harmful During the earliest days of internetworking, researchers attributed the warning label "harmful" to IP fragmentation based on empirical observations in the ARPANET, DARPA Internet and other internetworks of the day [KENT87]. This inspired an engineering discipline known as "Path MTU Discovery" within an emerging community of interest known as the Internet Engineering Task Force (IETF). In more recent times, the IETF published "IP Fragmentation Considered Fragile" [RFC8900] to characterize the current state of fragmentation in the modern Internet. The IPv6 Extended Fragment Header now introduces a more robust solution based on an improved IPv6 fragmentation and reassembly service that addresses these historical concerns. These early directions failed to consider that proper mitigations for fragment loss can ensure a dynamic system that adaptively tunes packet sizes according to current networking conditions on a per-flow basis. Such a system can offer performance maximization benefits through adaptive packet size management in a manner that parallels TCP congestion control. 15. Implementation Status In progress. 16. IANA Considerations 16.1. IPv6 Parameters The IANA is requested to assign a new IPv6 Destination Option type in the "Destination Options and Hop-by-Hop Options" table of the https://www.iana.org/assignments/ipv6-parameters/ registry group (registration procedures IESG Approval, IETF Review or Standards Action). The option type should appear in 4 consecutive table entries. The first entry sets "act" to '00', "chg" to '0', "rest" to TBD1, "Description" to "IPv6 Fragmentation Report" and "Reference" to this document [RFCXXXX]. The next three entries set "act" to {'01', '10', '11'}, "chg" to '1', "rest" to TBD1, "Description" to "IPv6 Extended Fragment Header" and "Reference" to this document [RFCXXXX]. Each table entry finally sets "Hex Value" to the 2-digit hexadecimal value corresponding to the 8-bit concatenation of act/chg/rest. Templin & Herbert Expires 23 October 2025 [Page 14] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 16.2. ICMPv6 Parameters The IANA is instructed to assign new Code values in the "ICMPv6 Code Fields: Type 2 - Packet Too Big" registry in the https://www.iana.org/assignments/icmpv6-parameters registry group (registration procedure is Standards Action or IESG Approval). The registry entries should appear as follows: Code Name Reference --- ---- --------- 0 PTB Hard Error [RFC4443] 1 (suggested) PTB Soft Error (loss) [RFCXXXX] 2 (suggested) PTB Soft Error (no loss) [RFCXXXX] 3 (suggested) MTU Probe Reply [RFCXXXX] Figure 3: ICMPv6 Code Fields: Type 2 - Packet Too Big Values 16.3. ICMP Parameters The IANA is instructed to assign a new Type number TBD2 in the "ICMP Type Numbers" registry in the https://www.iana.org/assignments/icmp- parameters registry group (registration procedures IESG Approval or Standards Action). The entry should set "Type" to TBD2, "Name" to "Packet Too Big (PTB)" and "Reference" to [RFCXXXX] (i.e., this document). The IANA is further instructed to create a new table titled: "Type TBD2 - Packet Too Big (PTB)" in the "Code Fields" registry, with registration procedures IESG Approval or Standards Action. The table should have the following initial format: Code Name Reference --- ---- --------- 0 Reserved [RFCXXXX] 1 (suggested) PTB Soft Error (loss) [RFCXXXX] 2 (suggested) PTB Soft Error (no loss) [RFCXXXX] Figure 4: Type TBD2 - Packet Too Big (PTB) 17. Security Considerations All aspects of IP security apply equally to this document, which does not introduce any new vulnerabilities. Moreover, when employed correctly the mechanisms in this document robustly address known IP reassembly integrity concerns [RFC4963] and also provide an advanced degree of packet Identification uniqueness assurance. Templin & Herbert Expires 23 October 2025 [Page 15] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 All security aspects of [RFC7739], including the algorithms for selecting fragment identification values, apply also to the IPv6 EFH. In particular, the source should reset its starting Identification value frequently (e.g., per the algorithms found in [RFC7739]) to maintain an unpredictable profile. All normative security guidance on IPv6 fragmentation found in [RFC8200] (e.g., processing of tiny first fragments, overlapping fragments, etc.) applies also to the fragments generated under the IPv6 EFH. IPsec AH [RFC4302] and ESP [RFC4303] define an Extended Sequence Number (ESN) that is analogous to the 64-bit Identification specified for the IPv6 EFH option. Nodes that employ the IPv6 EFH can use the Identification value as a sequence number to improve security in the same fashion as for IPsec AH/ESP ESNs. 18. Acknowledgements This work was inspired by continued DTN performance studies. Amanda Baber, Bob Hinden, Christian Huitema, Mark Smith and Eric Vyncke offered useful insights that helped improve the document. Honoring life, liberty and the pursuit of happiness. 19. References 19.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . Templin & Herbert Expires 23 October 2025 [Page 16] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . 19.2. Informative References [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-19, 27 February 2025, . [I-D.templin-6man-aero3] Templin, F., "Automatic Extended Route Optimization (AERO)", Work in Progress, Internet-Draft, draft-templin- 6man-aero3-43, 10 April 2025, . [I-D.templin-6man-omni3] Templin, F., "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Work in Progress, Internet-Draft, draft-templin-6man-omni3-56, 16 April 2025, . [I-D.templin-6man-parcels2] Templin, F., "IPv6 Parcels and Advanced Jumbos (AJs)", Work in Progress, Internet-Draft, draft-templin-6man- parcels2-24, 16 April 2025, . Templin & Herbert Expires 23 October 2025 [Page 17] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 [I-D.templin-dtn-ltpfrag] Templin, F., "LTP Performance Maximization", Work in Progress, Internet-Draft, draft-templin-dtn-ltpfrag-17, 23 May 2024, . [KENT87] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", SIGCOMM '87: Proceedings of the ACM workshop on Frontiers in computer communications technology, DOI 10.1145/55482.55524, http://www.hpl.hp.com/techreports/ Compaq-DEC/WRL-87-3.pdf.", August 1987. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . Templin & Herbert Expires 23 October 2025 [Page 18] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . Appendix A. Change Log << RFC Editor - remove prior to publication >> Differences from draft version -09 to -11: * Discussed implications of ULPs that include security encapsulations such as TLS/SSL. * Additional discussion of flow loss profiles. * Added "D" flag to prevent intermediate systems from fragmenting. Differences from draft version -08 to -09: * Added note on header compression. Differences from draft version -07 to -08: * Added section on "Relation to GSO/GRO". * Removed requirement citing a non-normative reference. Differences from draft version -06 to -07: * Introduced ICMP PTB Soft Errors. Differences from draft version -05 to -06: Templin & Herbert Expires 23 October 2025 [Page 19] Internet-Draft IPv6 Extended Fragment Header (EFH) April 2025 * Introduced ICMPv6 PTB "Probe Reply" message to support fragment based RFC8899 path probing. * Numerous supporting revisions to Fragmentation Report message. * Removed stale references. Differences from earlier versions: * First draft publication. Authors' Addresses Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 United States of America Email: fltemplin@acm.org Tom Herbert Unaffiliated San Jose, CA United States of America Email: tom@herbertland.com Templin & Herbert Expires 23 October 2025 [Page 20]