Boeing Research & Technology

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

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 adapting the IPv6 Extended Fragment Header for IPv4.

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 . This specification adapts the IPv6 Extended Fragment Header (EFH) for Identification extension and to support an alternate fragmentation and reassembly service for IPv4. IPv4 packets that include the IPv6 EFH can engage a "deep packet fragmentation" service that supports Identification, fragmentation and reassembly 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 packet Identification uniqueness assurance is critical.

Protocol extensions intended for IPv6 can often 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 the IPv6 Extended Fragment Header (EFH) as specified in . All normative aspects of the IPv6 specification that can be applied for IPv4 apply also to this document.

By default, IPv4 end systems and intermediate systems do not recognize the IP protocol numbers for IPv6 extension headers as these are typically used to support only IPv6 operations. However, implementations of this specification are required to recognize IP protocol number 60 (IPv6 Destination Options header per ) as an applicable extension for IPv4. Implementations of this specification also recognize the IPv6 EFH Option 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 . Recommendations for IPv6 extension header limits are found in . IPv4 sources insert an IPv6 Destination Option with an EFH 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 EFH fragmentation if necessary the same as for the IPv6 fragmentation procedures specified in . This will produce a sequence of fragment packets each containing a copy of the IPv4 header followed by any Per-Fragment headers up to and including the Destination Options Header with IPv6 EFH Option (with the fragmentation control fields and Identification set appropriately) followed by the fragment payload. The IPv4 source then sends the fragment packets 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 . IPv4 routers that recognize the IPv6 Destination Options Header in IPv4 packets forward (fragment) packets that include the option if they are no larger than the next hop link MTU. If the packet is too large, the router instead performs IPv4 fragmentation if the Don't Fragment (DF) flag is 0; otherwise, the router drops the packet and return an ICMPv4 Fragmentation Needed (also known as Packet Too Big (PTB)) message. Destinations that recognize the option perform IPv4 reassembly if necessary followed by EFH reassembly under the same conditions specified for the IPv6 EFH in .

IPv4 intermediate systems and destinations that do not recognize the IPv6 Destination Options Header with EFH Option appearing after the IPv4 header unconditionally drop the packet and SHOULD return an "ICMPv4 Destination Unreachable - Protocol Unreachable" message per . The source can therefore test whether the path up to and including the destination accepts the IPv6 Destination Options Header and EFH Option by occasionally sending "probe" packets of a given size 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.

specifies a new "Packet Too Big (PTB)" ICMP message Type plus Code values for PTB Soft Errors. Intermediate systems and destination end systems return ICMPv4 PTB Soft Errors to the source under the same conditions specified for IPv6.

All nodes that process IPv4 packets with an IPv6 Destination Options Header with EFH Option observe the requirements found in in addition to the requirements found in this section. Destinations that accept flows using EFH Options MUST configure an EMTU_R of 65535 octets or larger. Sources MUST set the DF bit to 0 for IPv4 packets with EFH options that include fragment payloads no larger than 1024 octets and MUST set DF to 1 for all others. Sources MUST include at most one EFH in each IPv4 packet. Intermediate systems and destinations SHOULD silently drop packets with multiples. Intermediate systems that recognize IPv6 extension headers MUST forward without dropping IPv4 packets that include a Destination Options Header with an EFH Option unless they detect a security policy threat through deeper inspection of the protocol data that follows.

In progress.

This document has no requirements for IANA.

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 and also provide an advanced degree of packet Identification uniqueness assurance. All other security aspects of the IPv6 Extended Fragment Header per apply also to its use in IPv4.

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.

<< RFC Editor - remove prior to publication >> Differences from version -06 to version -07: Now using normal (extended) ICMPv4 messages for IPv4 PTB instead of OMNI-encapsulated ICMPv6. Differences from version -05 to version -06: Removed reference to RFC9268. Clarified setting of DF bit. Differences from earlier versions: First draft publication.