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 engage a "deep packet fragmentation" service that supports Identification, fragmentation and reassembly 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.

IPv4 end systems, intermediate systems and routers by default 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 Header with an EFH option in an extension header chain beginning immediately after the IPv4 header (plus options) and ending 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 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 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 IPv6 Destination Options Header with EFH Option followed by the fragment payload. The IPv4 source then forwards the fragment packets toward the final destination which processes them only if all nodes in the path pass IPv4 packets that include the IPv6 Destination Options header. Intermediate systems and IPv4 routers on the path forward the fragment packets if the next hop link MTU is sufficient. A router may perform IPv4 fragmentation if a fragment packet is too large and the Don't Fragment (DF) flag is 0; otherwise, the router drops the packet and returns an ICMPv4 Fragmentation Needed message. When the fragment packets arrive at the IPv4 destination, it performs IPv4 reassembly if necessary followed by EFH reassembly under the same conditions specified for the IPv6 EFH in .

IPv4 intermediate systems, routers 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 and routers 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.

Destinations that return Fragmentation Report (FR) messages per set the Flow Label field to the value included by the source of the packet that elicited the FR. When the source does not include an explicit Flow Label value, the destination sets the field to 0.

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 including the EFH Option observe the requirements found in in addition to the requirements found in this section. Sources SHOULD set DF to 0 and include a suitable IPv4 ID value for packets that include fragment payloads based on the 1024 octet minimum non-final EFH fragment size. Sources MUST set DF to 1 and include any IPv4 ID value for all others. An updated specification of the IPv4 ID field is found in . Sources MUST include at most one EFH in each IPv4 packet. Intermediate systems and destinations SHOULD silently drop packets with multiples. Destinations that accept flows using EFH Options MUST configure an EMTU_R of 65535 octets or larger.

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 -07 to version -09: Clarified IPv4 DF bit setting requirements. Included section on IPv4 Flow Label. IPv4 router fragmentation considerations. 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.