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 defining an IPv4 header option for Identification Extension.

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 document defines a new option for IPv4 that extends the Identification field to 32-bits (i.e., the same as for IPv6 packets that include a standard Fragment Header ) to support reassembly integrity at higher data rates. When an IPv4 packet includes this "Identification Extension" option, the value encoded in the IPv4 header Identification field represents the 2 least-significant octets while the option encodes the 2 most-significant octets of an extended 4-octet Identification. Nodes that recognize the option employ it for packet identification purposes in general and to fortify the IPv4 reassembly procedure in particular. This specification also supports an "advanced" mode that extends the IPv4 Identification field even further. This format 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.

As is often the case, extensions intended for IPv4 can be applied in similar fashion as for IPv6 (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 . All normative aspects of the IPv6 specification that can be applied for IPv4 apply also to this document.

IP Identification (IP ID) extension for IPv4 is based on a new IPv4 option . This new IPv4 ID Extension (IDEXT) Option begins with an option-type octet with "copied flag" set to '1', "option class" set to '0' and "option number" set to TBD (see: IANA Considerations). The option-type octet is followed immediately by an option-length octet set to the constant value '4'. The option-length octet is then followed by a 2-octet "ID Extension" field that (when combined with the 2 least-significant octets found in the IPv4 packet header Identification field) includes the 2 most-significant octets of an extended 4-octet (32-bit) IP ID for the packet. The option format is shown in :

When a source wishes to supply a 4-octet extended IP ID for an IPv4 packet, it includes an IDEXT option in the IPv4 packet header options area, i.e., following the same rules as for including any IPv4 option. The source next writes the 2 least-significant octets in the IPv4 header Identification field and writes the 2 most-significant octets in the "ID Extension" field. The source then applies source fragmentation if necessary while including the extended IP ID value. During fragmentation, the source copies the ID Extension option into each resulting fragment and sets or clears the "Don't Fragment (DF)" flag as desired. The source then forwards each IPv4 packet/fragment to the next hop, where each successive intermediate system will direct them toward the destination. If an intermediate system on the path needs to apply network fragmentation, it copies the IDEXT option into each resulting fragment to provide the destination with the correct reassembly context.

When a source produces a sustained burst of IPv4 packets for a flow at extreme data rates, (e.g., ~1Tbps) or when the source plans to reset the IP ID starting sequence to a new pseudo-random value frequently, it can optionally extend the IP ID even further by supplying an 8/12/16 octet value instead of a 2/4-octet value. To apply this longer extensions, the source includes an IDEXT option with option-type set to TBD the same as above, but with option-length ("optlen") set to '8', '12' or '16' instead of '4' as shown in :

The option-data then includes a 6/10/14-octet ID Extension, with the most significant IP ID octets appearing in the extension in network byte order and with the 2 least significant octets appearing in the IPv4 Identification field.

specifies procedures for fragmenting and reassembling the constituent packets derived from IP parcels that have been opened somewhere along the path. Since each packet derived from the same parcel shares the same Identification value, an ancillary (Parcel) Index field is also necessary to differentiate the packets. re-purposes the IPv6 Fragment Header 8-bit Reserved field to encode a (Parcel) Index, but the IPv4 header does not provide sufficient space. With reference to and , this document therefore specifies the following IDEXT option format with (Parcel) Index extension:

When the IPv4 TBD option-length is 5/9/13/17, the option-data instead includes 2/6/10/14 Identification extension octets followed by the (Parcel) Index extension octet. The (Parcel) Index extension octet field names and descriptions appear in .

limits the use of the IPv4 ID field to only supporting the fragmentation and reassembly processes. When an IPv4 packet includes a TBD option, however, the source asserts that the IPv4 ID includes a well-managed extended-length value that can satisfy uniqueness properties useful for other purposes. This specification therefore updates by permitting use of the extended IPv4 ID for purposes other than fragmentation and reassembly support. Note: The IDEXT option-length could conceivably encode any value up to and including 255, however implementations of this specification only honor those values specified in the previous two sections (future specifications may define different values).

The source must have assurance that each destination will recognize and accept the IDEXT option before it can assume the extended IP ID uniqueness properties. This can be through operational assurances or protocol message feedback. An operational assurance example is through application of a common encapsulation format shared by all nodes within a limited domain network for which recognition of the IDEXT option is mandatory (e.g., see: ). The scope of the IDEXT uniqueness then applies only within the boundaries of the limited domain. For open Internetworks and/or other networks with no operational assurances, the source must instead receive continuous feedback proving that the destination recognizes and applies the IDEXT option as long as the source sends packets/fragments with extended IP IDs at high data rates. (Note that continuous feedback rather than a one-time test is necessary in case the destination is anycast and routing redirects traffic to a new anycast destination that does not recognize the option.) Sources normally set the IDEXT option "option class" to '0' (control) for ordinary packets/fragments. To receive continuous feedback from the destination, the source can periodically set "option class" to '2' in a packet/fragment to be used as a probe. If the source receives an ICMPv4 Parameter Problem message with Code TBD2 , it has assurance that the destination (still) correctly recognizes the option. Destinations that receive IPv4 packets/fragments with an IDEXT option simply ignore the option if they do not recognize it. Destinations that recognize the option instead examine the "option class" value. If the value is '2', the destination returns an ICMPv4 Parameter Problem message with Code TBD2 to the source. The destination then accepts the packet/fragment for further processing. Intermediate systems that do not recognize the IDEXT option may be configured to ignore the option completely without taking the required action of copying the option into each fragment upon fragmentation . Sources therefore SHOULD NOT set the DF bit to 0 for IPv4 packets that include the IDEXT option on open Internetworks outside of a limited domain . Note: destinations that recognize and accept the IDEXT option are required to configure an EMTU_R of 65535 octets (see: ). Therefore, sources that receive ICMPv4 Parameter Problem messages with code TBD2 can also regard them as confirmation of the destination's EMTU_R.

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 or an ICMPv4 "Destination Unreachable - Fragmentation Needed" message 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. suggests that source and/or network fragmentation should instead be used to ensure that packets are delivered to the destination even if they exceed the path MTU. The document therefore defines new ICMPv6 PTB Code values to monitor and control the fragmentation and reassembly processes. Rather than define corresponding codes for ICMPv4, however, this document requires sources that send packets with IPv4 Identification Extension options to accept and take appropriate actions based on ICMPv6 PTB messages with one of the fragmentation/reassembly Code values defined in . This may require the intermediate or end system that sends the PTB message to employ UDP/IPv4 encapsulation so that the ICMPv6 message can traverse IPv4 networks.

IPv4 intermediate systems MUST forward without dropping packets with IPv4 option-type TBD while copying the option during network fragmentation. Sources MUST include at most one IPv4 Identification Extension option in each packet. Intermediate systems and destinations SHOULD silently drop packets with multiple options. Destinations that recognize IPv4 option-type TBD MUST accommodate packets that include any extended IP ID format included by the source. Sources MUST transmit and destinations MUST process the octets of the extended IP ID in network byte order with the base IP ID field containing the least significant octets and the ID Extension field containing the most significant octets. Destinations MUST be capable of reassembling packets as large as the minimum Effective MTU to Receive (EMTU_R) specified for IPv4 (, Section 3.3.2). Destinations that accept flows that include extended IP IDs: MUST configure a minimum EMTU_R of 65535 octets, SHOULD advertise the largest possible EMTU_R in PTB messages and MAY advertise a reduced EMTU_R during periods of congestion.

In progress.

The IANA is requested to assign a new IPv4 Option "IDEXT" with number "TBD" in the "IP Option Numbers" table in the 'ip-parameters' registry (registration procedures not defined). Two registry entries are inserted, where the first entry sets "Copy" to '1', "Class" to '0', "Number" to TBD and "Name" to "IDEXT" and the next entry sets "Copy" to '1', "Class" to '2', "Number" to TBD an "Name" to "IDEXT". The "Reference" for both entries is set to this document [RFCXXXX]. The IANA is requested to assign a new IPv4 Parameter Problem Code "TBD2" in the "Type 12 - Parameter Problem" table in the 'icmp-parameters-codes' registry (registration procedures IESG Approval or Standards Action). One registry entry is inserted that sets "Code" to "TBD2" and "Description" to "IDEXT Option Recognized". The "Reference" is set to this document [RFCXXXX].

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.

This work was inspired by continued DTN performance studies. Amanda Baber, Tom Herbert and Bob Hinden offered useful insights that helped improve the document. Honoring life, liberty and the pursuit of happiness.

<< RFC Editor - remove prior to publication >> Differences from earlier versions: First draft publication.