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 may be smaller than desired for some intended uses. This document addresses these limitations by defining both an Identification Extension option for IPv4 and a corresponding Destination Option for IPv6.

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 the length specified for Internet Protocol, version 6 (IPv6) ) to support reassembly integrity at high 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 IP ID. Hosts and routers 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 a "hyper-extended" mode that extends the Identification field to 64 bits for both IPv4 and IPv6. This format may be useful for future networks that operate at still higher data rates, or for source nodes that frequently reset the starting Identification sequence numbers of flows. Finally, for truly extreme environments, an optional "ultra-extended" mode that extends the Identification field to 128 bits is also supported.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the term "IP" to refer generically to either protocol version (i.e., IPv4 or IPv6), and uses the term "IP ID" to refer generically to the IP Identification field whether in simple or extended form.

Studies over many decades have shown that transport layer protocols often achieve greater performance by setting segment sizes that exceed the path Maximum Transmission Unit (MTU). When the segment size exceeds the path MTU, IP fragmentation at some layer is a natural consequence. A recent study proved that setting segment sizes that cause IPv4 packets to exceed the path MTU (thereby invoking IPv4 fragmentation and reassembly) provides a multiplicative performance increase at high data rates in comparison with using smaller segment sizes as long as fragment loss is negligible. An alternative to fortifying the IPv4 ID was also considered and examined in which IPv4 packets were first encapsulated in IPv6 headers then subjected to IPv6 fragmentation where a 32 bit Identification field already exists. While this IPv4-in-IPv6 encapsulation followed by IPv6 fragmentation also showed a performance increase for larger segment sizes in comparison with using MTU-sized or smaller segments, the magnitude of increase was significantly less than for invoking IP fragmentation directly without first applying encapsulation. An observation offered without supporting evidence is that common implementations base both IPv4 and IPv6 fragmentation and reassembly off a common code base since their algorithms are so similar. It therefore seems reasonable to conclude that IPv4 fragmentation and reassembly can support higher data rates than IPv6 when full (uncompressed) headers are used. For these reasons, it is clear that a robust IP fragmentation and reassembly service can provide a useful tool for performance maximization in the Internet. This document therefore presents a means to fortify the IP ID to support such a service.

IP ID extension for IPv4 is achieved by introducing 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 '00' and "option number" set to TBD. The option-type octet is followed immediately by an option-length octet set to the constant value "4". The option-type 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 IP ID for the packet. The option format is shown in :

When an IPv4 source node (i.e., an original source or an IPv4 encapsulation ingress) wishes to supply a 4-octet extended IP ID for the packet, it includes an IDEXT option in the IPv4 packet header options area, i.e., while 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. The source copies the ID Extension option to each resulting fragment and sets or clears the "Don't Fragment (DF)" flag as desired. (In the limiting case, the source can set DF to disable network fragmentation and replicate the conditions experienced for IPv6.) The source then forwards each packet/fragment to the next hop, where IPv4 forwarding will direct them toward the final destination. If an IPv4 router on the path needs to apply network fragmentation, it copies the IDEXT option into each resulting fragment to provide the final destination with the correct reassembly context.

When an IPv4 source produces a sustained burst of IPv4 packets that use the same source address, destination address and protocol at extreme data rates (e.g., in excess of 1Tbps), or when the source plans to reset the IP ID starting sequence frequently or even pseudo-randomly, it can optionally "hyper-extend" the IP ID by supplying an 8-octet value instead of a 2/4-octet value. To apply hyper-extension, the source includes an IDEXT option with option-type set to TBD the same as above, but with option-length set to 8 instead of 4 as shown in :

The option-data will then include the 2-octet ID Extension to be applied to the IPv4 Identification field as above, plus a 4-octet ID Hyper-Extension that includes the 4 most significant octets of the hyper-extended ID. The combined 8-octet IP ID can then fit properly within the longest word length for modern 64-bit architectures. Techniques that improve IPv4 often also apply in a corresponding fashion for IPv6 (and vice-versa). This document therefore defines a new IPv6 ID Extension Destination Option for IPv6 that extends the base Identification value found in the IPv6 Fragment Header. The source inserts the Destination Option immediately before the Fragment Header (or Routing Header, if present)) and the destination processes the option only if the Fragment Header is also present. The IPv6 ID Extension Option format is shown in :

All aspects of applying and processing the IPv6 ID Extension option follow exactly the same as for IPv4, with the exception that only source fragmentation is permitted since network fragmentation is deprecated in IPv6.

To support truly extreme environments (e.g., where IP ID duplication in ultra-high speed networks carries severe consequences and/or where sophisticated adversaries actively try to guess IP ID values), an optional "ultra-extension" mode is also supported that extends the IP ID to 16 octets. Nodes invoke ultra-extension mode by replacing the "Hyper-Extension" fields in and with an "Ultra-Extension" field containing the most significant 12 octets of a 16-octet ultra-extended IP ID. For IPv4, the option sets option-length to 16 and, for IPv6, the option sets Opt Data Len to 12. Nodes process the IP ID ultra-extension format the same as for the other extension forms, except that the option contains 12 octets in network byte order that form the most significant octets of a 16 octet IP ID. The combined 16-octet IP ID can then fit properly within two words under the longest word length for modern 64-bit architectures. Since processing two long words instead of a single word may require extra machine instructions even in modern architectures, and since transporting longer ultra-extended IP IDs consumes additional network bandwidth, ultra-extended mode performance may be less than for extended/hyper-extended modes under modern day architectures. However, these issues may be overcome by future architectures that support 128-bit instruction sets natively over ultra-high speed networks. Due to the added complexity and overhead, nodes are not required to support ultra-extended mode natively. Destination nodes that implement the extended/hyper-extended modes but do not support ultra-extended mode unconditionally drop packets that include an ultra-extended IP ID. After first testing for basic IP ID extension support (see: ) source nodes can therefore test for ultra-extension support by sending a 'ping' packet that includes an ultra-extended option. If the source receives a ping response, it can begin sending packets with ultra-extended IP IDs.

IPv4 routers MUST forward without dropping any packets with IPv4 option-type TBD while copying the option during (router) fragmentation, and IPv6 routers MUST forward without dropping any packets with IPv6 Option Type TBD2. Destinations that recognize IPv4 option-type TBD and/or IPv6 Option Type TBD2 MUST accommodate packets that include all simple, extended and hyper-extended IP ID formats based on any 2-, 4- or 8-octet value included by the source. Destinations that implement the OPTIONAL ultra-extended IP ID format MUST accommodate packets with ultra-extended 16-octet IP IDs, while destinations that implement only the required extended IP ID formats MUST drop packets that include an ultra-extended IP ID. Sources MUST transmit and destinations MUST process the octets of the extended IP ID in network byte order with the base IP header Identification field containing the least significant octets, the ID Extension field (when present) containing the next most significant octets and the ID Hyper/Ultra-Extension field (when present) containing the most significant octets. When either or both extension fields are absent, implementations consider their values to be "0". Since the option is included only by the source and reassembly is performed only by the destination, the source can test whether the path and/or destination are compliant by sending a fragmented 'ping' packet with the same IP Identification in all fragments but with two or more fragments containing different pseudo-random values in the combined extension/hyper-extension fields of an ID extension option (the source can first send an ordinary 'ping' to test reachability). If the destination responds to a fragmented ping sent with mismatched hyper-extended IP IDs (proving that reassembly was performed without honoring the option) the source can infer that the destination and/or some router on the path does not recognize the option. Option formats supported by this specification include only the mandatory-to-implement extended/hyper-extended formats and optional ultra-extended format. The formats are differentiated by the option-length value for IPv4 or the Option Length value for IPv6. Future documents may specify additional formats that use different option length values. Note: IP fragmentation can only be applied for packet lengths up to a maximum of 65535 octets. IP parcels and advanced jumbos provide a means for efficiently packaging and shipping multiple large segments or truly large singleton segments in IP packets that may exceed this size .

In progress.

IANA is requested to assign a new IPv4 Option named "IDEXT" in the 'ip-parameters' registry (registration procedures not defined). The option sets "Copy" to '1', "Class" to '00' and "Number" to TBD. IANA is further requested to assign a new IPv6 Destination Option with description "IPv6 ID Extension" in the 'ipv6-parameters' registry (registration procedures IESG Approval, IETF Review or Standards Action). The option sets "act" to '00', "chg" to '0' and "rest" to TBD2. Note: IANA could alternatively re-assign a deprecated IPv4 option instead of allocating a new option; for example, the "Extended Internet Protocol (EIP)" option which still appears as option "Number" 17 with "Value" 145. Earlier works formalized deprecation of the EIP option , while took the further step of advising routers to drop packets that include the option.

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 a known IPv4 reassembly integrity concern and also provide an advanced degree of packet uniqueness assurance.

This work was inspired by continued DTN performance studies.

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