Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

Unaffiliated

San Jose CA USA tom@herbertland.com

I-D Internet-Draft 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.

The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets , but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks . For Internet Protocol, version 6 (IPv6), the Identification field is only present in packets that include a Fragment Header , but even its standard length of 32 bits may be too small for some applications. Standard IP fragmentation is also subject to numerous performance and security issues that indicate a need for a more robust service. This specification therefore defines a new fragmentation service that addresses these issues through the introduction of an IPv6 Extended Fragment Header (EFH). The 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 EFH is needed for networks that engage fragmentation and reassembly at extreme data rates, or for cases when advanced packet Identification uniqueness assurance is critical. (Placement of the 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 EFH 64-bit Identification concept is similar to the Extended Sequence Number (ESN) framework found in IPsec AH and ESP . In both cases, nodes can apply header compression to transmit only the least significant bits while retaining the most significant bits in cache memory.

The terms "Maximum Transmission Unit (MTU)", "Effective MTU to Receive (EMTU_R)", "Effective MTU to Send (EMTU_S)" and "Maximum Segment Lifetime (MSL)" from standard Internetworking terminology apply . The term "Maximum Receive Unit (MRU)" is equivalent to EMTU_R, and the term "maximum datagram lifetime (MDL)" (see: ) is equivalent to MSL. The term "Packet Too Big (PTB)" refers to an ICMPv6 "Packet Too Big" message or a new ICMPv4 "PTB" message type defined in this document (see: IANA Considerations). 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 . The term "Extended Fragment Header (EFH)" refers to a new IPv6 Destination Option defined 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". The term "Fragmentation Report (FRAGREP)" refers to an alternate IPv6 option type encoding of the EFH option used to report reassembly conditions. Destinations may include FRAGREPs in return packets to EFH fragment sources. The Automatic Extended Route Optimization (AERO) and Overlay Multilink Network Interface (OMNI) services employ the EFH for secure adaptation layer encapsulation and fragmentation. New packet types termed "IPv6 Parcels and Advanced Jumbos (AJs)" are specified in . 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.

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 . 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) - see: . The performance testbed included a pair of modern high-performance workstations 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 improvement with segment sizes that exceed the path MTU was similarly proven using the HDTN and ION-DTN LTP implementations when IP fragmentation and reassembly were invoked. 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 support a duplicate packet detection service where the network remembers recent Identification values to aid detection of potential duplicates. When an encapsulation source includes an 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 as potential spurious transmissions. The standard IPv6 Fragment Header also carried forward the awkward fragmentation parameters found in IPv4 including a 13-bit quadword Fragment Offset value, no restrictions on fragment-by-fragment payload sizes and no limits on numbers of fragments produced. In contrast, the EFH service mandates same-sized fragments, forbids tiny fragments, places a conservative limit on the maximum number of fragments and eliminates any possibilities for fragment overlap. These factors ensure a more secure and performance-optimized fragmentation and reassembly service. An optimized IP fragmentation and reassembly service using an extended Identification can provide a useful tool for performance maximization and path MTU robustness 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 Extended Fragment Header (EFH).

For a conventional 4-octet IPv6 Identification, the source can simply include a standard IPv6 Fragment Header as specified in 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 EFH. The source includes the EFH in a Destination Options header positioned as the final IPv6 Per-Fragment Header. The remainder of the packet beyond the Destination Option header beginning with any 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 . The EFH Destination Option is formatted as shown in :

The EFH Destination Option is therefore identified as an IPv6 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 0. The highest-order 2 bits (i.e., "act") are set to '10' so that destinations that do not recognize the option will drop the packet or fragment and (possibly) also return an ICMPv6 Parameter Problem message. When Opt Data Len is 10, the Identification field is 8 octets (64 bits) in length and the option is aligned such that the field begins on a natural 8-octet boundary as "8n+4" (see: ). In a compressed form, the source sets Opt Data Len to the value 6 (i.e., instead of 10) and includes only the 4 least significant octets of the (8-octet) Identification field and the option is aligned such that the field begins on a natural 4-octet boundary as "4n" (see: ). The source can engage this compressed form after it has already published the 4 most significant octets to establish state in any intermediate systems and the destination end system. Intermediate and end systems that have already cached the 4 most significant octets regard the Identification as a full 8 octet value for the purpose of packet filtering and reassembly; otherwise, they regard the 4 most significant octets as 0. For improved efficiency, sources often send packets that include full IPv6 headers (including the EFH extension) only as initial packets of a flow while including greatly compressed headers in subsequent packets. 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.

IPv6 fragmentation using the EFH is conducted in a manner similar to standard IPv6 fragmentation (see: Section 4.5 of ) with the following exceptions. When the source performs fragmentation using the EFH, it creates fragments of the same packet based on the (Source, Destination, Identification)-tuple. The source 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 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 (a zero-length final fragment payload is therefore also permissible). 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. For each fragment produced during fragmentation, the source inserts a Destination Options header including the 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.

Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path . However, the standard IPv6 Fragment Header has no protocol provisions to prevent intermediate systems from performing further fragmentation on individual packets processed in isolation and the destination would still reassemble correctly the same as for fragments produced by the source. For packets that include an EFH, any fragmentation by an intermediate system would cause malformed fragments to arrive at the destination and therefore spoil any in-progress reassemblies. An intermediate system could instead perform the onerous task of (virtual) reassembly of all fragments of the same packet before applying re-fragmentation, but this might not scale well in all environments.

Destination reassembly using the EFH is conducted in a similar manner as for standard IPv6 reassembly (see: Section 4.5 of ) 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, etc. until all fragments are concatenated. In the process, the destination discards any non-final fragments with fragment payload lengths less than 1024 octets or with fragment payload lengths that differ from the others.

IPv6 destinations that do not recognize the EFH option drop the packet and may also return a Code 2 ICMPv6 Parameter Problem message . (ICMPv6 messages may be lost on the return path and/or manufactured by an adversary, however, and therefore provide only an advisory indication.) The IPv6 source can then test whether destinations recognize the EFH option by occasionally sending "probe" packets/fragments 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 the path occasionally in case routing redirects a flow to a different anycast destination or in case a multicast group membership changes (see: ).

When the source node sends fragment payloads larger than the minimum size of 1024 octets using the EFH option, it should probe the path MTU for each flow occasionally per 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 for a particular flow (i.e., one with P set to 1 and Index set to 0), it returns a responsive packet that includes a Fragmentation Report (FRAGREP) Destination Option per . The responsive packet can be any authentic return packet with the Source and Destination addresses reversed. The source can then perform source fragmentation using the EFH option with the fragment payload size advanced to the size of the probe. If the destination experiences reassembly congestion, it can begin returning authentic packets with FRAGREP options to the source (see: ) and with MRU set to a reduced size. When the source receives the messages, it should temporarily reduce the size of its future transmissions for the flow but may resume using larger sizes if the FRAGREP 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 . If the source regards the packet as lost, it sets the Code to "Soft Error (loss); otherwise, it sets the Code to "Soft Error (no loss)". For IPv4, the source uses a new ICMPv4 PTB message Type TBD2 and with a corresponding soft error Code (see: IANA Considerations).

End systems that recognize the EFH also recognize an IPv6 Fragmentation Report (FRAGREP) option that uses type TBD1 the same as for the EFH itself but with the act/change bits set to '000' and formatted as shown below:

The destination end system includes the FRAGREP option in a return packet to the source to report receipt of an explicit probe (see: , reassembly congestion and/or fragment loss. The destination also regards all first fragments with Index set to 0 and M set to 1 as implicit probes for the purpose of including FRAGREP options subject to rate limiting. The destination can use any return packet (i.e., one with the Source and Destination Addresses from the packet that triggered the FRAGREP reversed) to carry the option, especially if it includes identifying parameters and/or authentication signatures. The option is aligned such that the Identification field begins on a natural 8-octet boundary as "8n+2" (see: ). The destination sets Flow Label to the 20-bit Flow Label corresponding to this reassembly, sets the "Resvd" bits to 0 then sets MRU to the most significant 8 bits of the recommended 16-bit maximum reassembly size under current congestion conditions. When the 8 transmitted MRU bits are all-1's, the recipient regards the 8 untransmitted bits as all-1's; otherwise, it regards them as all-0's. If no fragments of the subject packet have (yet) been lost, the destination sets Opt Data Len to 12, sets (L)oss to 0 and omits the Bitmap field. If the destination has abandoned reassembly for the packet due to fragment loss, it instead sets L to 1. The destination then includes the full 8 octet (64-bit) Identification even if the invoking packet included only the 4 least significant octets. If some fragments are missing, the destination optionally sets Opt Data Len to 20 (i.e., instead of 12) and includes a 64-bit ordinal fragment index Bitmap field. The destination sets each Bitmap(i) bit (for i=0 to 63) to 1 for each ordinal fragment index received or 0 for each index not received for this reassembly. When the source receives authentic packets with the FRAGREP option, it matches the Identification with one of its recent transmissions for the corresponding flow. If the recent transmission was a probe, the source can advance the fragment size for the flow to the probe size. The source should also reduce, maintain or increase the size of its continued packet transmissions for the flow if necessary according to the advertised MRU. If the FRAGREP 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 FRAGREPs that advertise a larger MRU (or when it ceases to receive FRAGREPs), it can begin to increase its packet sizes. This ensures that the packet size is adaptive for a given flow. Note: the FRAGREP option may appear in the same Destination Options header that includes an EFH option. Their bounded sizes permit both options to appear without exceeding recommended limits (see: ). Note: by definition, the destination will not generate rate-limited FRAGREPs for continuous flows of "atomic fragments", i.e., those with Index and M both set to 0. The source must therefore use occasional explicit probes and/or higher-layer protocol indications to confirm that atomic fragment flows are reaching the destination. If the source suspects its atomic fragments are being dropped for reasons other than a size restriction, it can apply source fragmentation to create multi-fragment sequences where the final fragment length for each sequence may be 0.

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 for which all nodes recognize the EFH, some destinations may recognize the option while others drop packets containing the option and may return a Code 2 ICMPv6 Parameter Problem message . 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 as many as N different paths. Some destinations may then return packets with FRAGREP 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 EFH option. While the source receives authentic PTB messages or authentic packets with FRAGREP options, it should reduce the sizes of the packets/fragments it sends to the flow multicast group even if only one or a few paths or destinations are currently experiencing congestion. This means that transmissions to a multicast group for a given flow 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 EFH 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 EFH options 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.

Normative aspects of standard IPv6 fragmentation and reassembly apply also to the EFH except where this document specifies differences. Sources and Destinations MUST apply EFH fragmentation and reassembly according to the 3-tuple (Source, Destination, Identification). This means that all flows share the same Identification number space for the purpose of fragmentation and reassembly, but path MTU feedback is on a per-flow basis. Destinations that accept flows using EFH options MUST configure an EMTU_R of 65535 octets or larger. Destinations MAY advertise "soft" temporary EMTU_R reductions in FRAGREP messages during periods of loss/congestion, but MUST continue to honor the "hard" upper limit. The source SHOULD therefore respond to FRAGREP messages from the destination by sending EFH fragments at rates that will minimize reassembly congestion. Sources MUST NOT include more than one IPv6 Fragment Header or EFH option in each IPv6 packet/fragment, and destinations MUST silently drop packets/fragments with multiples. If the source includes an EFH option, it MUST appear in a Destination Options header that appears as the final Per-Fragment header before the fragment payload. Sources that include an 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 (or even zero-length) and MUST NOT be larger. Sources that include the EFH option in packet transmissions MUST also recognize the FRAGREP option in return packets as specified in .

In progress.

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 2 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 second entry sets "act" to '10', "chg" to '0', "rest" to TBD1, "Description" to "IPv6 Extended Fragment Header" and "Reference" to this document [RFCXXXX]. Both table entries finally set "Hex Value" to the 2-digit hexadecimal value corresponding to the 8-bit concatenation of act/chg/rest.

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:

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:

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 and also provide an advanced degree of packet Identification uniqueness assurance. All security aspects of , 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 to maintain an unpredictable profile. All normative security guidance on IPv6 fragmentation found in (e.g., processing of tiny first fragments, overlapping fragments, etc.) applies also to the fragments generated under the EFH. IPsec AH and ESP define an Extended Sequence Number (ESN) that is analogous to the 64-bit Identification specified for the IPv6 EFH option. Nodes that employ the EFH can use the Identification value as a sequence number to improve security in the same fashion as for IPsec AH/ESP ESNs.

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.

<< RFC Editor - remove prior to publication >> Differences from draft version -17 to -18: Specified option alignment requirements. Zero-length final fragment payloads now permissible. Fragmentation Reports for atomic fragments. Removed back reference to network fragmentation. Differences from draft version -16 to -17: Clarifications on option fields and formats. Differences from draft version -15 to -16: Included option to transmit only the 4 least significant octets of the Identification when the most significant octets have been transmitted recently. Differences from draft version -13 to -15: Walked back requirement to include Flow Label in reassembly. Statement on intermediate system fragmentation (-14). Differences from draft version -12 to -13: Removed intermediate system (sub-)fragmentation features. Removed non-normative discussions about GSO/GRO and Fragmentation Considered Harmful/Fragile. Aligned fragment probing with Fragmentation Report messaging. Differences from draft version -11 to -12: Under "Motivation", added specific justifications for including a new fragmentation and reassembly algorithm. Requirements for "hard" and "soft" EMTU_R limits discussed. General cleanup. 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: 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.