| Internet-Draft | IP Identification Extension | August 2023 |
| Templin | Expires 29 February 2024 | [Page] |
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 intended uses. This document addresses these limitations by defining both an IPv4 Identification Extension option and a corresponding IPv6 Hop-by-Hop Option.¶
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 29 February 2024.¶
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.¶
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets [RFC0791], but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks [RFC4963] [RFC6864]. 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 Fragment Header [RFC8200]) 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 Identification. 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 networks that operate at still higher data rates, or for other cases when Identification uniqueness assurance is critical.¶
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.¶
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 (hyper-)extended form.¶
The term "Maximum Transmission Unit (MTU)" is used exactly the same as for standard Internetworking terminology.¶
The term "Packet Too Big (PTB)" refers to either an IPv6 "Packet Too Big" [RFC8201][RFC4443] or an IPv4 "Destination Unreachable - Fragmentation Needed" [RFC1191] message.¶
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 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 IP ID was also 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.¶
Widely deployed implementations also often employ a common code base for both IPv4 and IPv6 fragmentation/reassembly 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.¶
In addition to enabling higher data rates in the presence of fragmentation and reassembly, fortifying the IP ID can enable other important services. For example, an extended IP ID can support a duplicate packet detection service in which the network remembers recent IP ID values for a flow and excludes any packets that repeat recently-used values. An extended IP ID can also provide a packet sequence number that allows communicating peers to exclude as potential spurious transmissions any packets with IP ID values outside of a current window. These and other cases also hold true even if the source frequently resets its starting IP ID sequence numbers to maintain an unpredictable profile.¶
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 and that an extended IP ID can enable greater uniqueness assurance. This document therefore presents a means to fortify the IP ID to support these services.¶
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 (32-bit) 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 (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 (64-bit) 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 Extension | +--------+--------+--------+--------+
The option will then include a 6-octet ID Extension, with the 6 most significant IP ID octets appearing in network byte order in the option-data and with the 2 least significant octets appearing in the IPv4 Identification field. 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 Hop-by-Hop (HBH) Option for IPv6 that (hyper-)extends the base IPv6 ID.¶
IPv6 packets that include an IPv6 Fragment Header already have a 4-octet (32-bit) IPv6 ID , while those that do not include a Fragment Header have a 0-octet (0-bit) IPv6 ID. The IPv6 ID Extension HBH Option format is shown in Figure 3:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 ID Extension ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value TBD2.
Opt Data Len 8-bit value 0, 4 or 8.
IPv6 ID Extension 0 octets, or a 4/8-octet unsigned integer
that encodes the extension, in network byte
order.
When an IPv6 packet that includes the IPv6 ID Extension HBH Option does not include a Fragment Header, the option data length must be either 4 or 8, and the option body correspondingly includes the full 4-octet or 8-octet IPv6 ID for the packet in network byte order.¶
When an IPv6 packet that includes the IPv6 ID Extension HBH Option also includes a Fragment Header, the option length must be either 0 or 4, and the option body correspondingly includes the 0 or 4 most significant IPv6 ID octets in network byte order while the Fragment Header includes the 4 least significant octets.¶
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 HBH Option Type TBD2.¶
Destinations that recognize IPv4 option-type TBD and/or IPv6 HBH Option Type TBD2 MUST accommodate packets that include all extended and hyper-extended IP ID formats based on any 4-octet or 8-octet value 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 header Identification field containing the least significant octets and the ID (Hyper-)Extension field containing the most significant octets. When the ID (Hyper-)Extension field is absent, implementations consider its value 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 option (hyper-)extension fields (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 (hyper-)extended formats which are differentiated by the option-length value for IPv4 or the Option Data 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 [I-D.templin-intarea-parcels].¶
[RFC6864] 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 4/8-octet value that can satisfy uniqueness properties useful for other purposes.¶
This specification therefore updates [RFC6864] by permitting use of the extended IPv4 ID for purposes other than to support fragmentation and reassembly.¶
When an IPv6 router forwards a packet that includes both an IPv6 HBH Option with type TBD2 and a Fragment Header, it applies (further) fragmentation if the next hop link MTU is insufficient. The presence of both the TBD2 HBH Option and Fragment Header therefore provides a "network fragmentation permitted" indication for IPv6 in the same spirit as setting the "Don't Fragment (DF)" flag to 0 in IPv4. (Conversely, IPv6 routers treat all other packets as DF=1.)¶
This specification therefore updates [RFC8200] by permitting network fragmentation for IPv6 under the above conditions.¶
When a node forwards an IP packet that exceeds the next hop link MTU but for which fragmentation is forbidden, it drops the packet and returns a "Packet Too Big (PTB)" message to the original source [RFC1191][RFC4443][RFC8201]. This always results in wasted retransmissions by the source as well as all routers on the path toward the node with the restricting link. Conversely, when a packet includes an IP ID Extension option (and also a Fragment Header for IPv6) the network will perform fragmentation if necessary allowing the packet to reach the final destination without loss due to a size restriction.¶
While the fragmentation and reassembly processes eliminate wasted retransmissions and can also support significant performance gains through transmissions of upper layer protocol segment sizes that exceed the path MTU, the processes sometimes represent pain points that should be communicated to the original source. The original source should then take measures to reduce the pain.¶
The IPv4 PTB format includes an "unused" field while the IPv6 PTB format include a "Code" field, with both fields set to the value "0" for ordinary PTB messages. The value "0" signifies a "classic" PTB and always denotes that the subject packet was unconditionally dropped. For IP packets that include an IP ID Extension option (and also a Fragment Header for IPv6) other PTB unused/Code values are defined as follows:¶
When the original source receives an authentic Code 1 or 2 PTB, it begins to perform source fragmentation using the fragment size indicated in the MTU field which may be smaller than the first hop link MTU. This reduces the burden on routers in the path which will no longer need to perform network fragmentation.¶
When the original source receives a Code 3 or 4 PTB, it reduces the size of the packets it sends based on the packet size indicted in the MTU field which may be larger than the path MTU. This reduces the burden on the final destination which will no longer need to reassemble such large packets.¶
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.¶
The IANA is instructed to assign new Code values in the "ICMPv6 Code Fields: Type 2 - Packet Too Big" registry (registration procedure is Standards Action or IESG Approval). The registry should appear as follows:¶
Code Name Reference --- ---- --------- 0 PTB Hard Error [RFC4443] 1 Fragmentation Needed [RFCXXXX] 2 Fragmentation Needed (loss) [RFCXXXX] 3 Reassembly Needed [RFCXXXX] 4 Reassembly Needed (loss) [RFCXXXX]
(Note: this registry also defines values for the "unused" field of ICMPv4 "Destination Unreachable - Fragmentation Needed" messages.)¶
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 [RFC4963] 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:¶