Internet DRAFT - draft-templin-intarea-ipv4-idext
draft-templin-intarea-ipv4-idext
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track 27 July 2023
Expires: 28 January 2024
An Identification Extension (IDEXT) Option for IP
draft-templin-intarea-ipv4-idext-01
Abstract
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 at high data rates in modern networks.
This document addresses the issue by defining an Identification
Extension (IDEXT) option for IPv4 as well as a corresponding
Destination Option for IPv6.
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.
Templin Expires 28 January 2024 [Page 1]
Internet-Draft IP Identification Extension July 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IP ID Extension . . . . . . . . . . . . . . . . . . . . . . . 3
5. IP ID Hyper-Extension . . . . . . . . . . . . . . . . . . . . 4
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IPv6 ID Hyper-Extension . . . . . . . . . . . . . . . . . . . 6
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Templin Expires 28 January 2024 [Page 2]
Internet-Draft IP Identification Extension July 2023
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".
Templin Expires 28 January 2024 [Page 3]
Internet-Draft IP Identification Extension July 2023
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
Figure 1: IPv4 ID Extension (IDEXT) Option
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:
Templin Expires 28 January 2024 [Page 4]
Internet-Draft IP Identification Extension July 2023
+--------+--------+--------+--------+
|100[TBD]|00001000| ID Extension |
+--------+--------+--------+--------+
| ID Hyper-Extension |
+--------+--------+--------+--------+
Figure 2: IDEXT Option 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].
Templin Expires 28 January 2024 [Page 5]
Internet-Draft IP Identification Extension July 2023
7. IPv6 ID Hyper-Extension
As usual, techniques that improve IPv4 can also apply in the same
fashion for IPv6. This document defines a new Destination Option for
IPv6 that includes an IPv6 ID Hyper-Extension for the base
Identification value found in the Fragment Header. The option is
processed only if the IPv6 Fragment Header is also present; otherwise
the option is ignored.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 ID Hyper-Extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value TBD2.
Opt Data Len 8-bit value 4.
ID Hyper-Extension 32-bit unsigned integer. The option data
includes a 4-octet extension to the (4-octet)
IPv6 Fragment Header Identification field.
Future specifications may define even longer
extensions in increments of 4 octets (i.e.,
8, 12, 16, etc.) with the resulting extended
IPv6 ID including a multiple of 4 octets.
Figure 3: IPv6 ID Hyper-Extension Option
All aspects of applying and processing the IPv6 ID Hyper-Extension
follow exactly the same as for IPv4, with the exception that only
source fragmentation is permitted since IPv6 does not support network
fragmentation.
8. Implementation Status
In progress.
9. 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
Templin Expires 28 January 2024 [Page 6]
Internet-Draft IP Identification Extension July 2023
finalized the deprecation of the EIP option [RFC6814], however
[RFC7126] went a step further by recommending routers to drop packets
that include the option.
IANA is further requested to assign a new IPv6 Destination Option
with description "IPv6 ID Hyper-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.
10. 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].
11. Acknowledgements
This work was inspired by continued DTN performance studies.
12. References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
12.2. Informative References
Templin Expires 28 January 2024 [Page 7]
Internet-Draft IP Identification Extension July 2023
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Fragmentation", Work in Progress,
Internet-Draft, draft-templin-dtn-ltpfrag-10, 5 May 2023,
<https://datatracker.ietf.org/doc/html/draft-templin-dtn-
ltpfrag-10>.
[I-D.templin-intarea-parcels]
Templin, F., "IP Parcels and Advanced Jumbos", Work in
Progress, Internet-Draft, draft-templin-intarea-parcels-
66, 26 July 2023, <https://datatracker.ietf.org/doc/html/
draft-templin-intarea-parcels-66>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, DOI 10.17487/RFC6814, November 2012,
<https://www.rfc-editor.org/info/rfc6814>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options",
BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
<https://www.rfc-editor.org/info/rfc7126>.
Appendix A. Change Log
<< RFC Editor - remove prior to publication >>
Differences from earlier versions:
* First draft publication.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Templin Expires 28 January 2024 [Page 8]
