Fragmentation Revisited: For What It's Worth

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 11 December 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 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

Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". This is true for both IPv4 [RFC0791] and IPv6 [RFC8200] which differ only in the length of the IP Identification field.¶

Beginning in the late 1980's, "Fragmentation Considered Harmful" [KENT87] inspired an investigation into path Maximum Transmission Unit (MTU) discovery that has only recently reached successful conclusions [RFC4821][RFC8899]. Still more recently, "IP Fragmentation Considered Fragile" [RFC8900] documented enough protocol and operational concerns to merit BCP status. However, both studies failed to observe that the shortcomings identified can be addressed by sound engineering solutions in support of a more robust service. The warning labels have instead inspired myths, folklore and urban legends that have caused deeply-embedded misgivings to carry forward from generation to generation in the Internet engineering community.¶

This document examines IP fragmentation and reassembly within the context of the larger multi-layer Internetworking architecture for transferring data between peer end systems. A systematic examination instead of an exclusive focus on the IP layer services viewed in isolation is needed to set the appropriate context. The document concludes that an improved IP fragmentation and reassembly service is both practical and necessary while citing a specification that offers a robust alternative solution.¶

2. Multi-Layer Internetworking Architecture

Figure 1 illustrates a common architecture where an Original Source host connects to End User Network (EUN) A and a Final Destination host connects to EUN B. An Encapsulation Source for EUN A in turn connects to an Encapsulation Destination for EUN B via a virtual link spanning any intermediate Internetworks.¶

         +-------+                                        +-------+
         | Orig. |                                        | Final |
         | Source|                                        | Dest. |
       ` +-------+                                        +-------+
             |                                                |
       .-(::::::::)                                     .-(::::::::)
    .-(: End User :)-.                               .-(: End User :)-.
   (:::  Network A :::)                             (:::  Network B :::)
    `-(::::::::::::)-'                               `-(::::::::::::)-'
       `-(::::::)-'                                     `-(::::::)-'
             |                 .-(::::::::)                   |
         +-------+           .-(::::::::::::)-.           +-------+
         | Encap.|---------(: Internetwork(s) :)----------| Encap.|
         | Source| virtual   `-(::::::::::::)-'    link   | Dest. |
       ` +-------+              `-(::::::)-'              +-------+

Applications on the Original Source prepare user data buffers for presentation to lower layers. In environments where delay or disruption may be significant, user data buffers may be based on "bundles" according to the Delay Tolerant Networking (DTN) Bundle Protocol (BP) [RFC9171]. The user data buffers (or bundles) may range in size from very small for interactive communications such as Internet telephony to very large for transactional services such as large file transfer.¶

Original source applications present user data to transport layer protocols such as TCP [RFC9293], QUIC [RFC9000] and others which divide them into segments. Traditional wisdom suggests that each segment should be no larger than the path MTU and that each IP packet should carry exactly one segment. But, a more robust IP fragmentation and reassembly service would permit segment sizes to exceed the path MTU and IP parcels [I-D.templin-6man-parcels2] would permit a single IP packet to carry multiple segments. The resulting services can support improved performance profiles for common operational environments.¶

Following segmentation, the transport layer protocol may present either a single segment or a parcel of multiple segments to the network layer for packetization. If each packet will contain a single segment, the network layer applies traditional packetization procedures while engaging a fragmentation-like service known as Generic Segment Offload (GSO) to packetize multi-segment parcels if necessary. If each packet will contain multiple segments, the network layer instead prepares the packet with a multi-segment transport layer parcel to form an IP parcel. The network layer then applies IP fragmentation if necessary and forwards the IP packets or fragments into EUN A. Standard IP forwarding within the local EUN will then deliver the packets/fragments either directly to the Final Destination or to an Encapsulation Source when the Final Destination resides in a remote EUN.¶

Unlike the Original Source, the Encapsulation Source operates only at the network layer and below. The Encapsulation Source encapsulates any original packets or fragments bound for a remote destination according to [RFC2003] or [RFC2473] then forwards the resulting packets to an appropriate Encapsulation Destination as an adaptation layer service. As a source, the Encapsulation Source can apply adaptation layer IP fragmentation following encapsulation to ensure that the resulting fragments will not be lost due to a size restriction in an intermediate Internetwork. The Encapsulation Destination is then responsible for reassembling these fragments.¶

After the Encapsulation Destination reassembles at the adaptation layer, it decapsulates to obtain the original IP packet or fragments which it then forwards to the Final Destination. The Final Destination then reassembles at the network layer if necessary using IP reassembly and/or Generic Receive Offload (GRO) according to the manner in which the Original Source applied fragmentation. The Final Destination then delivers the resulting segment or parcel to the transport layer which delivers the resulting user data to the application layer.¶

3. Discussion

To efficiently engage fragmentation, each source requires a means to determine the per-flow path MTU. From the above architecture, the contributing elements include: 1) the path MTU from the Original Source to the Encapsulation Source, 2) the path MTU from the Encapsulation Source to the Encapsulation Destination, and 3) the path MTU from the Encapsulation Destination to the Final Destination. In common use cases, however, EUNs often comprise limited domains with robust link MTUs while intervening Internetworks may be arbitrarily complex including heterogeneous links with widely varying MTUs possibly as small as the minimum IP link MTU.¶

More specifically, the EUN path MTUs are visible at the network layer while the path MTU between the encapsulation endpoints is visible at the adaptation layer and presents the appearance of a single virtual link to the network layer. This suggests a multi-layer path MTU probing discipline is required, where both the Original Source probes the Final Destination at the network layer and the Encapsulation Source probes the Encapsulation Destination at the adaptation layer. The former allows the original source to determine the largest original IP packet or fragment size that can traverse the entire path to the destination while the latter allows the encapsulation source to determine the maximum adaptation layer fragment size for the encapsulation destination.¶

In common deployments, the Original Source is often positioned close to or possibly even co-resident on the same physical platform as the Encapsulation Source. The same is true of the Encapsulation Destination and Final Destination. When the Original Source and Encapsulation Source are co-resident, multiple layers of fragmentation may be needed for the same original packet before the resulting fragment packets are transmitted over the physical or virtual data link media. When the Encapsulation Destination and Final Destination are co-resident, multiple layers of reassembly may be needed before the reassembled segments or parcels are delivered to upper layers. This may require the operating system to perform expensive buffer linearization following initial stages of reassembly before presenting them to additional stages. The original IP and encapsulation services could alternatively be located in separate virtual machines on the same physical platform so that each virtual machine engages only a single layer of fragmentation or reassembly.¶

While the Encapsulation Source is fragmenting at the adaptation layer, it should probe the forward path to the Encapsulation Destination to determine the largest fragment size that can traverse the intermediate Internetworks for each flow. At the same time, the Encapsulation Source can represent an unbounded MTU to the network layer in order to accommodate all original IP packets up to 65535 octets with fragmentation-assured delivery while allowing larger original IP packets to proceed without fragmentation based on best-effort delivery.¶

Alternatively, the Encapsulation Source could refrain from performing fragmentation and adaptation layer path MTU probing while forwarding all encapsulated packets to the Encapsulation Destination based on best-effort delivery regardless of their size. This means that the network layer path MTU probing between the Original Source and Final Destination would also have the effect of probing the path between the Encapsulation Source and Destination over the intermediate Internetworks. The drawback of this approach is that the link MTUs in the intermediate Internetworks are often beyond the control of the source and destination endpoints and will often configure MTU sizes that are significantly smaller than those in the EUNs. Such an arrangement will often fail to benefit from the larger native MTU sizes of the EUNs.¶

4. IP Fragmentation Issues

Considerable evidence suggests that aspects of standard fragmentation procedures for both IPv4 [RFC0791] and IPv6 [RFC8200] introduce serious performance and/or security issues in some environments. For example, IPv4 provides only a 16-bit Identification field which means that a source must limit its transmission rate to avoid wrapping the Identification value within the Maximum Datagram Lifetime (MDL) which may be multiple orders of magnitude too slow for modern networks [RFC4963][RFC6864]. IPv6 addresses this issue by providing a 32-bit Identification field, but reuse within the MDL is still possible when the source resets the Identification sequence frequently to avoid predictable values [RFC7739].¶

Additionally, both IPv4 and IPv6 fragmentation can produce non final fragments of differing lengths as small as 8 octets (while the final fragment may be smaller still) and the offsets of later fragments may overlap with those of earlier fragments. This (offset, length) relationship further allows intermediate systems to perform gratuitous fragmentation on individual fragments in isolation without first (virtually) reassembling all fragments of the same packet. This is true for IPv4 even when the DF bit is set to 1 and also true for IPv6 even though the standard deprecates intermediate system fragmentation. Accordingly, there is no assurance that the fragments produced by the source will be the same size as the fragments that arrive at the destination.¶

Finally, the number of fragments per packet is bounded only by the size of the original packet divided by the 8 octet minimum fragment size. For example, an 8KB packet could be fragmented into as many as 1024 fragments - far too many to support efficient reassembly procedures. Plus, the loss of a single fragment would result in retransmission of all fragments of the original packet.¶

These issues suggest that the original IP fragmentation and reassembly design has shortcomings that can be addressed through a well-engineered alternative solution. However, the earlier publications raised alarms that resonated both broadly and deeply throughout the Internetworking industry. This has resulted in a state of paralysis where little progress to address the issues has been made even in the modern era.¶

5. IP Fragmentation Solution

As discussed above, standard IP fragmentation has a number of issues that have been widely known but left unaddressed for many decades. This condition can be corrected by applying the classic IETF process of problem statement leading to solution. This document in conjunction with "IP Fragmentation Considered Fragile" [RFC8900] should therefore be considered as a problem statement, with a solution found in [I-D.templin-6man-ipid-ext2].¶

The offered solution addresses IP fragmentation issues by establishing an Extended Fragment Header (EFH) intended for use instead of the standard IPv4 and IPv6 fragmentation headers and procedures. The EFH is based on a 64-bit Identification value, mandates no more than 64 fragments per packet, mandates a minimum non-final fragment size of 1024 octets, mandates an identical size for all non-final fragments and eliminates any possibility for fragment overlap. Additionally, intermediate systems are unable to alter the size of individual fragments in isolation without first (virtually) reassembling the entire packet. The size of the fragments produced by the source will therefore be the same as the size of fragments that arrive at the destination unless an intermediate system performs the onerous task of (virtual) reassembly and re-fragmentation.¶

The EFH solution also has provisions for managing the loss unit with respect to the retransmission unit. In networks where loss is rare, this means that the source may send large packets at high data rates even if fragmentation with a non-final fragment size as small as 1024 octets is necessary. When loss becomes significant, the EFH solution provides a means for the destination to advise the source to reduce the size of its packets resulting in fewer fragments.¶

The EFH solution is based on an IPv6 Destination Option that appears instead of the IPv6 Fragment Header. The EFH may also appear in IPv4 packets if they are able to transit the path. When (UDP)/IP encapsulation is applied, however, IP packets containing the EFH can often transit limited domains [RFC8799] without loss at intermediate systems that filter packets with IPv6 extension headers.¶

6. Conclusion

Standard IP fragmentation has well known issues that were presented in ways that caused the community to become paralyzed with uncertainty rather than move forward in confidence according to the time-proven IETF process of problem statement leads to solution. While the earlier publications succeeded in articulating the issues, their titles inspired fear, uncertainty and doubt instead of promoting a well-balanced engineering approach toward a robust solution. The time for such a solution has now arrived.¶

7. IANA Considerations

This document is an informational problem statement and does not in itself request any IANA actions. IANA considerations can be found in the cited solution space document.¶

8. Security Considerations

This document is an informational problem statement and does not in itself address security. Security considerations can be found in the cited solution space document.¶

9. Acknowledgements

Performance maximization efforts in the Internet engineering community have produced foundational improvements. Those who contributed are acknowledged.¶

Honoring life, liberty and the pursuit of happiness.¶

Author's Address