An Identification Extension (IDEXT) Option 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 28 January 2024.¶

Copyright Notice

Copyright (c) 2023 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 (termed the "IP ID") in all packets [RFC0791], but this length is too small to ensure reassembly integrity at high data rates in modern networks [RFC4963] [RFC6864]. This document defines a new Identification Extension (IDEXT) option that extends the IP ID to 32 bits, i.e., the same as the Identification length specified for Internet Protocol, version 6 (IPv6) [RFC8200].¶

When an IPv4 packet includes this 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" IDEXT mode that extends the IP ID to 64 bits. This format may be useful for future networks that operate at extreme data rates, or for source nodes that frequently reset the starting identification sequence numbers of flows. This format also allows for safe assignment of pseudo-random values on a per-packet basis when use of the IP ID as a sequence number is unnecessary.¶

2. Terminology

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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Motivation

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 [I-D.templin-dtn-ltpfrag] proved that setting segment sizes that exceed the path MTU (thereby invoking IP fragmentation) provides a multiplicative performance increase at high data rates in comparison with using smaller segment sizes when fragment loss is negligible.¶

An alternative to fortifying the IPv4 ID was also considered and examined in which IPv4 packets were 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 shows a performance increase for larger segment sizes in comparison with using MTU-sized or smaller segments, the increase factor is significantly less than for invoking IPv4 fragmentation directly (i.e., without applying IPv6 encapsulation).¶

For these reasons, it is clear that a robust IPv4 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.¶

4. IP ID Extension

IP ID extension 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 Figure 1:¶

   +--------+--------+--------+--------+
   |100[TBD]|00000100|  ID Extension   |
   +--------+--------+--------+--------+
    Type=TBD Length=4

When an IPv4 source node (whether 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 an 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.¶

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.¶

5. IP ID Hyper-Extension

When an IPv4 source produces a sustained burst of IPv4 packets all having the same (src, dst, sport, dport, proto) "5-tuple" 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 Figure 2:¶

   +--------+--------+--------+--------+
   |100[TBD]|00001000|  ID Extension   |
   +--------+--------+--------+--------+
   |         ID Hyper-Extension        |
   +--------+--------+--------+--------+

The option-data will then include 6 IP ID extension octets instead of only 2 octets. Future specifications may define even longer ID Hyper-Extension lengths. Acceptable option-length values are in increments of 4 octets (i.e., 12, 16, 20, etc.) with the resulting extended IP IDs always including a multiple of 4 octets.¶

6. Requirements

Implementations that recognize option-type TBD MUST recognize and process all IDEXT formats based on any 2-, 4- or 8-octet IP ID value included by the source.¶

Implementations MUST process the octets of the extended IP ID in network byte order with the base IPv4 header Identification field containing the least significant 2 octets, the ID Extension field (when present) containing the next most significant 2 octets and the ID Hyper-Extension field (when present) containing the most significant 4 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 correctly processes the option by sending a fragmented 'ping' packet with the same 2-octet IPv4 Identification value in all fragments but with two or more fragments containing different pseudo-random 6-octet values in the combined (long-format) IDEXT fields. (The source can also first send an ordinary 'ping' to test whether the destination is reachable.) If the destination also responds to the fragmented ping with mismatched IP IDs (proving that reassembly was performed without honoring the IDEXT option) the source can infer that the destination and/or some router on the path does not correctly process the option.¶

Note: IP fragmentation can 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 [I-D.templin-intarea-parcels].¶

7. Implementation Status

In progress.¶

8. IANA Considerations

IANA is requested to assign a new IP 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.¶

The community could instead consider instructing IANA to re-assign a deprecated option instead of allocating a new option, for example the "Extended Internet Protocol (EIP)" option which is currently assigned as option "Number" 17 with "Value" 145. Earlier works have already finalized the deprecation of the EIP option [RFC6814], however [RFC7126] went a step further by recommending routers to drop packets that include the option.¶

9. Security Considerations

All aspects of IPv4 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 [RFC4963].¶

10. Acknowledgements

This work was inspired by continued DTN performance studies.¶

Author's Address