IPv6 Extended Fragment Header for IPv4

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 14 October 2024.¶

Copyright Notice

Copyright (c) 2024 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

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]. This specification adapts the IPv6 Extended Fragment Header [I-D.templin-6man-ipid-ext2] for Identification extension and to support an alternate fragmentation and reassembly service for IPv4.¶

When an IPv4 packet includes the IPv6 Extended Fragment Header, a "deep packet fragmentation" capability is enabled that supports Identification, fragmentation and reassembly services from deep within the packet independently of any IPv4 header level services. This may be useful for networks that engage fragmentation and reassembly at extreme data rates, or for cases when advanced IPv4 packet Identification uniqueness assurance is critical.¶

2. Relation to IPv6

As is often the case, extensions intended for IPv6 can be applied in similar fashion as for IPv4 (and vice-versa). The terminology used and the motivation for extending the Identification field for IPv4 is the same as for IPv6 Identification extension as specified in [I-D.templin-6man-ipid-ext2]. All normative aspects of the IPv6 specification that can be applied for IPv4 apply also to this document.¶

3. IPv6 Extended Fragment Header for IPv4

IPv4 end systems and intermediate systems do not by default recognize the IP protocol numbers for IPv6 extension headers, as these are typically used to support IPv6 operations only. However, implementations of this specification are required to recognize IP protocol number 0 and the IPv6 Minimum Path MTU Option formats as defined for the IPv6 Hop-by-Hop Options header per [RFC8200][RFC9268] as well as IP protocol number 60 and its associated header and option formats as defined for the IPv6 Destination Options header per [RFC8200].¶

Implementations of this specification also recognize the IPv6 Extended Fragment Header Option as specified in [I-D.templin-6man-ipid-ext2] when it appears in an IPv6 Destination Options Header following the IPv4 header. Requirements for encapsulation of extension headers in IPv4 packets are introduced and discussed in [I-D.herbert-ipv4-eh].¶

IPv4 sources insert an IPv6 Destination Option with an Extended Fragment Header in an IPv6 extension header chain that begins immediately after the end of the IPv4 header and ends immediately before the upper layer protocol header, e.g., TCP, UDP, etc. The source then increments the IPv4 Total Length by the length of the extension headers, and sets the IPv4 Protocol field to the protocol number of the first extension header. The source then sets the IPv6 Destination Options Header Next Header field to the protocol number of the next extension header or the upper layer protocol number if there are no further extensions.¶

The IPv4 source then applies fragmentation if necessary the same as for the IPv6 fragmentation procedures specified in [I-D.templin-6man-ipid-ext2]. This will produce a sequence of fragments each containing a copy of the IPv4 header followed by any Per-Fragment headers up to and including the Destination Options Header with IPv6 Extended Fragment Header Option (with Index, Fragment Offset, M and Identification set appropriately) followed by a fragment of the upper layer protocol payload.¶

The IPv4 source then sends the fragments to the IPv4 destination which accepts and processes them only if it recognizes the IP Protocol value of the first extension header. The destination then reassembles per the procedures specified in [I-D.templin-6man-ipid-ext2].¶

IPv4 intermediate systems that recognize the IPv6 Destination Options Header in IPv4 packets forward packets or fragments that include the option if they are no larger than the next hop link MTU; otherwise, they drop the packet/fragment and return a PTB message. Destinations that recognize the option perform reassembly and/or return PTB messages as necessary under the same conditions specified for the IPv6 Extended Fragment Header in [I-D.templin-6man-ipid-ext2].¶

4. Destination Qualification and Path MTU

IPv4 intermediate systems and destinations that do not recognize the IPv6 Destination Options Header with Extended Fragment Header Option appearing after the IPv4 header unconditionally drop the packet and SHOULD return an "ICMPv4 Destination Unreachable - Protocol Unreachable" message per [RFC0792].¶

The source can therefore test whether the path up to and including the destination accepts the IPv6 Destination Options Header and Extended Fragment Header Option by occasionally sending "probe" packets that include them. If the source receives an acknowledgement, it has assurance that the destination recognizes the protocol and that intermediate systems at least forward the protocol messages without dropping; the source can instead consider receipt of an ICMPv4 Destination Unreachable - Protocol Unreachable as a hint that some node in the path rejects the protocol. The source should occasionally re-probe each destination in case routing redirects a flow to a different anycast destination.¶

The source can also include IPv6 Minimum Path MTU Discovery Hop-by-Hop Options in packets/fragments sent to unicast, multicast or anycast destinations per [RFC9268]. The source inserts the Hop-by-Hop Options Header between the IPv4 header and the Destination Options header, then increments the IPv4 Total Length by 8 octets, sets the IPv4 Protocol field to 0 (i.e., the protocol number for the Hop-by-Hop Options header) and sets the Hop-by-Hop Options Header Next Header field to 60. If the source receives acknowledgements that include a {TCP,UDP} MTU/Fragmentation Report Option, the source should regard the reported MTU as the largest potential fragment size for this destination under current path MTU conditions noting that the actual size may be smaller still for some paths.¶

5. Packet Too Big (PTB) Extensions

When an intermediate system attempts to forward an IP packet that exceeds the next hop link MTU but for which fragmentation is forbidden, it returns an ICMPv6 "Packet Too Big (PTB)" message with Code 0 [RFC4443] [RFC8201] or an ICMPv4 "Destination Unreachable - Fragmentation Needed" message [RFC1191] to the source and discards the packet. This always results in wasted transmissions for which the source is required to reduce the size of the packets it is sending and retransmit. (Note: IPv4 intermediate systems that recognize the IPv6 Destination Option header with Extended Fragment Header Option return ICMPv6 PTB messages instead of ICMPv4 messages.¶

IPv4 intermediate systems and destinations that send Code 0 ICMPv6 PTB messages must therefore employ OMNI UDP/IPv4 encapsulation of ICMPv6 messages with IPv4-compatible IPv6 addresses so the messages can traverse IPv4 networks [I-D.templin-6man-omni3]. IPv4 sources that include the IPv6 Extended Fragment Header Option must therefore monitor the OMNI UDP port for UDP/IPv4-encapsulated ICMPv6 messages.¶

6. Requirements

All nodes that process an IPv6 Destination Options Header with Extended Fragment Header Option observe the extension header limits specified in [I-D.ietf-6man-eh-limits].¶

Intermediate systems that recognize IPv6 extension headers MUST forward without dropping IPv4 packets that include a Destination Options Header with an Extended Fragment Header Option unless they detect a security policy threat through deeper inspection of the protocol data that follows.¶

Sources MUST include at most one Extended Fragment Header in each IPv4 packet/fragment. Intermediate systems and destinations SHOULD silently drop packets/fragments with multiples.¶

Destinations that accept flows using Extended Fragment Headers MUST configure an EMTU_R of 65535 octets or larger.¶

Note: IP fragmentation can only be applied for conventional packets as large as 65535 octets. IP parcels and Advanced Jumbos (AJs) provide a means for efficiently packaging and shipping multiple or singleton segments ranging in size from very small to very large, but they are not eligible for fragmentation at any size [I-D.templin-intarea-parcels2].¶

7. Implementation Status

In progress.¶

8. IANA Considerations

This document has no requirements for IANA.¶

9. 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 IPv4 reassembly integrity concerns [RFC4963] and also provide an advanced degree of packet Identification uniqueness assurance.¶

All other security aspects of the IPv6 Extended Fragment Header per [I-D.templin-6man-ipid-ext2] apply also to its use in IPv4.¶

10. Acknowledgements

This work was inspired by continued DTN performance studies. Amanda Baber, Tom Herbert, Bob Hinden and Eric Vyncke offered useful insights that helped improve the document.¶

Honoring life, liberty and the pursuit of happiness.¶

Author's Address