Internet DRAFT - draft-templin-6man-ipid-ext2
draft-templin-6man-ipid-ext2
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: 8200, 8900, 9268 (if approved) 19 February 2024
Intended status: Standards Track
Expires: 22 August 2024
IPv6 Extended Fragment Header
draft-templin-6man-ipid-ext2-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 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 IPv6 Extended Fragment
Header that includes a 64-bit Identification; it further defines a
control messaging service for fragment retransmission and reassembly
congestion management.
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 22 August 2024.
Copyright Notice
Copyright (c) 2024 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.
Templin Expires 22 August 2024 [Page 1]
Internet-Draft IPv6 Extended Fragment Header February 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IPv6 Extended Fragment Header . . . . . . . . . . . . . . . . 4
5. IPv6 Source Fragmentation . . . . . . . . . . . . . . . . . . 7
6. Destination Qualification and Path MTU . . . . . . . . . . . 8
7. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 8
8. MTU/Fragmentation Reports and Retransmissions . . . . . . . . 9
9. Multicast and Anycast . . . . . . . . . . . . . . . . . . . . 10
10. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
11. A Note on Fragmentation Considered Harmful . . . . . . . . . 12
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
16.1. Normative References . . . . . . . . . . . . . . . . . . 14
16.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
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][RFC8900]. For Internet Protocol, version
6 (IPv6), the Identification field is only present in packets that
include a Fragment Header where its standard length is 32-bits
[RFC8200], but even this length may be too small for some
applications (such as those that regard the Identification value as a
sequence number). This specification therefore defines a means to
extend the IPv6 Identification length through the introduction of a
new IPv6 Extended Fragment Header.
The Extended Fragment Header 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.
(The placement of the Extended Fragment Header in a Destination
Options header also makes the packet less prone to loss due to
Templin Expires 22 August 2024 [Page 2]
Internet-Draft IPv6 Extended Fragment Header February 2024
network filtering.) This specification further defines a messaging
service for adaptive realtime response to loss and congestion related
to fragmentation/reassembly. Together, these extensions support
robust fragmentation and reassembly services as well as packet
Identification uniqueness for IPv6.
2. Terminology
The terms "Maximum Transmission Unit (MTU)", "Effective MTU to
Receive (EMTU_R)", "Effective MTU to Send (EMTU_S)" and "Maximum
Segment Lifetime (MSL)" are used exactly the same as for standard
Internetworking terminology [RFC1122]. The term MSL is equivalent to
the term "maximum datagram lifetime (MDL)" defined in
[RFC0791][RFC6864].
The term "Packet Too Big (PTB)" refers to an IPv6 "Packet Too Big"
[RFC8201][RFC4443] message.
The term "flow" refers to a sequence of packets sent from a
particular source to a particular unicast, anycast or multicast
destination [RFC6437].
The Automatic Extended Route Optimization (AERO)
[I-D.templin-intarea-aero2] and Overlay Multilink Network Interface
(OMNI) [I-D.templin-intarea-omni2] services rely on the IPv6 Extended
Fragment Header for secure adaptation layer encapsulation and
fragmentation.
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
Upper layer protocols often achieve greater performance by
configuring 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. However, the
4-octet (32-bit) Identification field of the Fragment Header may be
too small to ensure reassembly integrity at sufficiently high data
rates, especially when the source resets the starting sequence number
often to maintain an unpredictable profile [RFC7739]. This
specification therefore proposes to fortify the IPv6 Identification
by extending its length.
Templin Expires 22 August 2024 [Page 3]
Internet-Draft IPv6 Extended Fragment Header February 2024
Performance increases for upper layer protocols that use larger
segment sizes was historically observed for NFS over UDP, and can
still be readily observed today for TCP and the Delay Tolerant
Network (DTN) Licklider Transmission Protocol (LTP). A simple test
setup consists of a pair of modern high-performance servers with
100Gbps Ethernet cards connected via a point-to-point link and
running a public domain linux release such as Ubuntu. TCP
performance using the public domain 'iperf3' tool is proven to
increase when larger segment sizes are used even if they exceed the
path MTU.
LTP performance with segment sizes that exceed the path MTU is
similarly proven using the HDTN and ION-DTN LTP implementations.
QUIC performance testing using the 'qperf' tool does not show an
advantage for the use of larger path MTUs (with or without
fragmentation) since 'qperf' limits its packet sizes to 1280 octets.
For this reason, 'qperf' performance was a factor of 4 less than LTP
and a factor of 8 less than TCP when those protocols used larger
packet sizes and/or invoked fragmentation.
In addition to accommodating higher data rates in the presence of
fragmentation and reassembly, extending the IPv6 Identification can
enable other important services. For example, an extended
Identification can enable a duplicate packet detection service in
which the network remembers recent Identification values for a flow
to aid detection of potential duplicates (note however that the
network layer must not incorrectly flag intentional lower layer
retransmissions as duplicates). An extended Identification can also
provide a packet sequence number that allows communicating peers to
exclude any packets with values outside of a current sequence number
window for a flow as potential spurious transmissions.
A robust IP fragmentation and reassembly service can provide a useful
tool for performance maximization in the Internet when an extended
Identification is available. This document therefore presents a
means to extend the IPv6 Identification to better support these
services through the introduction of an IPv6 Extended Fragment
Header.
4. IPv6 Extended Fragment Header
For a standard 4-octet IPv6 Identification, the source can simply
include an ordinary IPv6 Fragment Header as specified in [RFC8200]
with the Fragment Offset field and M flag set either to values
appropriate for a fragmented packet or the value 0 for an
unfragmented packet. The source then includes a 4-octet
Identification value for the packet.
Templin Expires 22 August 2024 [Page 4]
Internet-Draft IPv6 Extended Fragment Header February 2024
For an extended Identification and/or for paths that drop packets
including the standard IPv6 Fragment Header, this specification
permits the source to instead include an IPv6 Extended Fragment
Header in a Destination Options Header in the same extension header
order where the Fragment Header would normally appear.
The source includes the Extended Fragment Header as the lone option
in a Destination Options header inserted after any Per-Fragment
headers and before the Extension and Upper Layer Headers for the
first fragment or before the Fragment data for non-first fragments.
The header therefore appears in each fragment in the same position
where the standard Fragment Header would otherwise appear - see
Sections 4.1 and 4.5 of [RFC8200].
Since middleboxes may not recognize this as a Fragment Header,
however, the source caches the Destination Options Next Header value
in the Extended Fragment Header Option NH-Cache field and upon
fragmentation sets the Next Header field to "No Next Header" to avoid
any possibility for confusion (the destination will restore the Next
Header value upon reassembly).
The IPv6 Extended Fragment Header is formatted as shown in Figure 1:
Templin Expires 22 August 2024 [Page 5]
Internet-Draft IPv6 Extended Fragment Header February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH-Cache | Index |Res| Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- Identification (64 bits) -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Identifies the next header following the
Destination Options header containing the
Extended Fragment Header Option.
Hdr Ext Len Encodes the constant value 1, meaning 2
8-octet units.
Option Type 8-bit value 'XX0[TBD1]'.
Opt Data Len 8-bit value 12.
NH-Cache a cached copy of the original Destination
Options Next Header prior to fragmentation.
Index/Res a 6-bit "Index" field that identifies the
ordinal fragment index for non-first fragments
of a fragmented packet, followed by a 2-bit
"(Res)erved" field. (For first fragments, the
Index field is also Reserved.)
Offset/Res/M the same as the fields of the standard IPv6
Fragment Header.
Identification an 8-octet (64 bit) unsigned integer
Identification, in network byte order.
Figure 1: IPv6 Extended Fragment Header
The Extended Fragment Header Option is therefore identified as an
Option Type with the low-order 5 bits set to TBD1 (see: IANA
Considerations), with the third-highest-order bit (i.e., "chg") set
to 0 and with the highest-order 2 bits (i.e., "act") set as discussed
below. The Identification field is 8 octets (64 bits) in length, and
a Destination Options header that includes the option may appear
either in an unfragmented IPv6 packet or in one for which IPv6
fragmentation is applied (with a copy of the header appearing in each
fragment).
Templin Expires 22 August 2024 [Page 6]
Internet-Draft IPv6 Extended Fragment Header February 2024
When the source includes an Extended Fragment Header Option and
applies source fragmentation (see: Section 5, it sets "act" to '01',
'10' or '11' so that destinations that do not recognize the option
will drop the fragments and (possibly) also return an ICMPv6
Parameter Problem message. When no source fragmentation is applied,
the source can optionally set "act" to '00' allowing the destination
to process the packet even if it does not recognize the Extended
Fragment Header.
5. IPv6 Source Fragmentation
When the source applies source fragmentation using the Extended
Fragment Header Option, fragmentation procedures are the same as for
standard IPv6 fragmentation except that the Destination Options
header containing the option appears in place of the standard IPv6
Fragment Header (see: Section 4.5 of [RFC8200]) and the Fragment
Header is omitted.
During source fragmentation, the source SHOULD produce the smallest
number of fragments possible (i.e., the largest possible fragments)
within current path MTU constraints. In particular, the source
SHOULD limit the number of fragments produced to no more than 64
fragments per packet, allowing for all conventional packet sizes up
to and including the 65535 octet maximum under the 1280 octet IPv6
minimum path MTU.
For each fragment produced during fragmentation except for the first
(i.e., the one with Offset=0), the source writes an ordinal index
number in the Extended Fragment Header "Index" field. Specifically,
the source sets Index to 1 for the first non-first fragment, 2 for
the second, 3 for the third, etc., up to and including the final
fragment (i.e., the one with M=0). If there are more than 64
fragments, the source sets Index to 63 in all remaining fragments
beginning with the 64th up to and including the final.
The source also caches the Destination Options header Next Header
value in the NH-Cache field. For each fragment produced during
fragmentation, the source includes the Destination Options header in
place of the standard Fragment Header and resets its Next Header
field to "No Next Header".
The destination then reassembles the same as specified in Section 4.5
of [RFC8200]. Following reassembly, the destination resets the
Destination Options header Next Header field to the value cached in
the NH-Cache field of the first fragment.
Templin Expires 22 August 2024 [Page 7]
Internet-Draft IPv6 Extended Fragment Header February 2024
Intermediate systems that forward packets fragmented in this way will
therefore ignore the data that follows the Extended Fragment Header
Destination Options header (by virtue of the "No Next Header"
setting) unless they are configured to more deeply inspect the data
content.
6. Destination Qualification and Path MTU
Destinations that do not recognize the Extended Fragment Header
Destination Option accept or drop the packet according to the Option
Type "act" code. If "act" is '00', destinations ignore the option
and accept the packet. For other "act" codes, destinations instead
drop the packet and (for codes '1X') may return a Code 2 ICMPv6
Parameter Problem message [RFC4443]. (ICMPv6 messages may be lost on
the return path and/or manufactured by an adversary, however, and
therefore provide only an advisory indication.)
The source can then test whether destinations recognize the Extended
Fragment Header by occasionally sending "probe" packets (either
fragmented or unfragmented) that include the option with an "act"
code other than '00'. The source has assurance that some
destinations recognize the option if it receives acknowledgments and/
or hints that some destinations do not recognize the option if it
receives ICMPv6 Parameter Problem messages. The source should re-
probe destinations occasionally in case routing redirects a flow to a
different anycast destination or in case a multicast group membership
changes (see: Section 9).
The source can also include IPv6 Minimum Path MTU Discovery Hop-by-
Hop Options in packets/fragments sent to unicast, multicast or
anycast destinations per [RFC9268]. If the source receives
acknowledgements that include an MTU/Fragmentation Report Option
(see: Section 8), the source should regard the reported MTU as the
largest potential fragment size for this destination under current
path MTU conditions noting that the actual size may be smaller still
for some paths.
7. Packet Size Issues
When a router attempts to forward an IPv6 packet (or fragment) that
exceeds the next hop link MTU but for which fragmentation is
forbidden, it returns a standard ICMPv6 Packet Too Big (PTB) message
to the source [RFC4443][RFC8201] and discards the packet. This
always results in wasted transmissions by the source and all routers
on the path toward the one with the restricting link. Moreover, the
messages are subject to spoofing and loss in the network [RFC2923].
Templin Expires 22 August 2024 [Page 8]
Internet-Draft IPv6 Extended Fragment Header February 2024
Since routers are not permitted to perform IPv6 fragmentation, this
means that the source should perform source fragmentation (if
necessary) with a maximum fragment size limited to the path MTU. If
the source receives PTB messages, it should reduce the size of the
packets/fragments it sends.
While the fragmentation and reassembly processes eliminate wasted
transmissions and support significant performance gains by
accommodating upper layer protocol segment sizes that exceed the path
MTU, the processes sometimes represent pain points for the
destination and/or network as a whole that the destination should
communicate to the source. The source should then take measures to
reduce the size of the packets that it sends.
8. MTU/Fragmentation Reports and Retransmissions
End systems that recognize the Extended Fragment Header also
recognize an MTU/Fragmentation Report Option for TCP [RFC9293] and
UDP [I-D.ietf-tsvwg-udp-options]. The {TCP,UDP} option is formatted
as shown in Figure 2:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | ExID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- Identification (64 bits) -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+~+~+~+~ Bitmap (64 bits when present) ~+~+~+~+
| |
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
Figure 2: MTU/Fragmentation Report Option
The destination end system includes the MTU/Fragmentation Report
Option in the {TCP,UDP} header of a return packet to the source when
reassembly congestion and/or fragment loss occurs. (Destinations
that receive IPv6 packets with both the Extended Fragment Header
Destination Option and the IPv6 Minimum Path MTU Discovery Hop-by-Hop
Option [RFC9268] also return MTU/Fragmentation Reports in this way.)
Any {TCP,UDP} packet that is part of an ongoing flow can be used to
carry the option, especially if it includes identifying parameters
and/or authentication signatures.
Templin Expires 22 August 2024 [Page 9]
Internet-Draft IPv6 Extended Fragment Header February 2024
The destination sets Kind to 253 for TCP [RFC6994][RFC9293] or 127
for UDP [I-D.ietf-tsvwg-udp-options], then sets ExID to TBD2 (see:
IANA Considerations). The destination next sets MTU to the
recommended receive size under current congestion conditions and sets
Identification to the value for the current reassembly. If all
fragments of the packet (or the unfragmented packet itself) have
arrived the destination sets Length to 16 and omits the Bitmap field.
If some fragments are missing, the destination instead sets Length to
20 and includes a 64-bit Bitmap field with Bitmap(i) (for i=0 to 63)
set to 1 for each ordinal fragment index it has received for this
reassembly and set to 0 for all others.
When the source receives authentic {TCP,UDP}/IPv6 packets with the
MTU/Fragmentation Report Option, it should decrease the size of its
future packet transmissions to this destination, where the value in
the MTU field includes a recommended maximum packet size under
current congestion conditions. If the option includes a Bitmap with
some bits set to 0, the source can retransmit any missing ordinal
fragments if it still has them in its cache. When the source ceases
to receive MTU/Fragmentation Reports, it can begin to increase the
size of its future packet transmissions to this destination.
Note: when the destination reassembles a fragment chain that includes
more than 64 fragments, it sets Bitmap(63) to 1 only if it has
received all ordinal fragments beginning with the 64th and beyond;
otherwise, it sets Bitmap(63) to 0. This may cause the source to
unnecessarily retransmit many trailing fragments beginning with
ordinal 63 up to and including the final fragment.
Note: the above source packet size adaptation based on destination
reassembly feedback parallels the Additive Increase, Multiplicative
Decrease (AIMD) congestion control strategy employed by TCP and other
reliable transports.
9. Multicast and Anycast
In addition to unicast flows, similar considerations apply for flows
in which the destination is a multicast group or an anycast address.
Unless the source and all candidate destinations are members of a
limited domain network [RFC8799] for which all nodes recognize the
IPv6 Extended Fragment Header Destination Option, some destinations
may recognize the option while others drop packets containing the
option and may return a Code 2 ICMPv6 Parameter Problem message
[RFC4443].
When a source sends packets/fragments with IPv6 Extended Fragment
Headers to a multicast group, the packets/fragments may be replicated
in the network such that a single transmission may reach N
Templin Expires 22 August 2024 [Page 10]
Internet-Draft IPv6 Extended Fragment Header February 2024
destinations over as many as N different paths. Some destinations
may then return {TCP/UDP}/IPv6 packets with MTU/Fragmentation Reports
if they experience congestion and/or loss. (Some destinations may
also return Code 2 ICMPv6 Parameter Problem messages if they do not
recognize the Extended Fragment Header.)
While the source receives authentic PTB messages or {TCP,UDP} packets
with MTU/Fragmentation Reports, it should reduce the sizes of the
packets/fragments it sends to the multicast group even if only one or
a few paths or destinations are currently experiencing congestion.
This means that transmissions to a multicast group will converge to
the performance characteristics of the lowest common denominator
group member destinations and/or paths. While the source receives
ICMPv6 Parameter Problem messages and/or otherwise detects that some
multicast group members do not recognize the Extended Fragment Header
Option, it must determine whether the benefits for group members that
recognize the option outweigh the drawbacks of service denial for
those that do not.
When a source sends packets/fragments with IPv6 Extended Fragment
Headers to an anycast address, routing may direct initial fragments
of the same packet to a first destination that configures the address
while directing the remaining fragments to other destinations that
configure the address. These wayward fragments will simply result in
incomplete reassemblies at each such anycast destination which will
soon purge the fragments from the reassembly buffer. The source will
eventually retransmit, and all resulting fragments should eventually
reach a single reassembly target.
10. Requirements
All nodes that process an IPv6 Destination Options Header with
Extended Fragment Header observe the extension header limits
specified in [I-D.ietf-6man-eh-limits].
Intermediate systems MUST forward without dropping IPv6 packets that
include a Destination Options header with an Extended Fragment Header
unless they detect a security policy threat through deeper inspection
of protocol data that follows.
Destinations that accept flows using Extended Fragment Headers MUST
configure an EMTU_R of 65535 octets or larger.
Templin Expires 22 August 2024 [Page 11]
Internet-Draft IPv6 Extended Fragment Header February 2024
Sources MUST include at most one IPv6 Standard or Extended Fragment
Header in each IPv6 packet/fragment. Intermediate systems and
destinations SHOULD silently drop packets/fragments with multiples.
If the source includes an Extended Fragment Header Option, it must
appear as the only option in a Destination Options header that
appears in the same extension header order that the IPv6 Standard
Fragment Header would normally appear.
Sources and Destinations that recognize the Extended Fragment Header
Option MUST also recognize the {TCP,UDP} MTU/Fragmentation Report
Option as specified in Section 8.
Sources SHOULD maintain a cache of recently-sent fragments in case
the destination requests retransmission. The destination is required
to send an "ICMP Time Exceeded - Fragment Reassembly Time Exceeded"
message if insufficient fragments are received to complete reassembly
within 60 seconds (see: Section 4.5 of [RFC8200]), but that time may
be longer than practical for the source to retain fragments in a
retransmission cache. The source SHOULD therefore maintain the cache
for only a small time delta beyond the round-trip time to the
destination, and the destination SHOULD send Fragmentation Reports as
early as practically possible upon experiencing fragment loss.
11. A Note on Fragmentation Considered Harmful
During the earliest days of internetworking, researchers attributed
the warning label "harmful" to IP fragmentation based on empirical
observations in the ARPANET, DARPA Internet and other internetworks
of the day [KENT87]. This inspired an engineering discipline known
as "Path MTU Discovery" within an emerging community of interest
known as the Internet Engineering Task Force (IETF).
In more recent times, the IETF published "IP Fragmentation Considered
Fragile" [RFC8900] to characterize the current state of fragmentation
in the modern Internet. The IPv6 Extended Fragment Header now
introduces a more robust solution based on a properly functioning IP
fragmentation and reassembly service as intended in the original
architecture.
Although the IP fragmentation and reassembly services provide an
appropriate solution for conventional packet sizes as large as 65535
octets, they cannot be applied for larger packets nor for IP parcels
and Advanced Jumbos (AJs) of any size [I-D.templin-intarea-parcels2].
This means that a combined solution with robust fragmentation and
reassembly applied in parallel with traditional path MTU probing
provides a combination well suited for Internetworking futures. This
document therefore updates [RFC8900].
Templin Expires 22 August 2024 [Page 12]
Internet-Draft IPv6 Extended Fragment Header February 2024
12. Implementation Status
In progress.
13. IANA Considerations
The IANA is requested to assign a new IPv6 Destination Option type in
the "Destination Options and Hop-by-Hop Options" table of the
'ipv6-parameters' registry (registration procedures IESG Approval,
IETF Review or Standards Action). The option should appear in 4
consecutive table entries that set "act" to 'XX', "chg" to '0',
"rest" to TBD1, "Description" to "IPv6 Extended Fragment Header" and
"Reference" to this document [RFCXXXX] (i.e., with "act" set to '00
for the first entry, '01' for the second, '10' for the third, and
'11' for the final entry). Each table entry also sets "Hex Value" to
the 2-digit hexadecimal value corresponding to the 8-bit
concatenation of act/chg/rest.
The IANA is instructed to assign a new entry in the "TCP Experimental
Option Experiment Identifiers (TCP ExIDs)" table of the 'tcp-
parameters' registry (registration procedures First Come First Served
per [RFC6994]). The table entry should set "Value" to TBD2,
"Description" to "MTU/Fragmentation Report" and "Reference" to this
document [RFCXXXX]. The IANA is also instructed to assign the same
value TBD2 as an entry in the to-be-created "UDP Experimental Option
Experiment Identifiers (UDP ExIDs)" table (registration procedures
First Come First served per [I-D.ietf-tsvwg-udp-options]). This
document places no preferences on the actual TBD2 value assignment.
14. Security Considerations
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 IP
reassembly integrity concerns [RFC4963] and also provide an advanced
degree of packet Identification uniqueness assurance.
All security aspects of [RFC7739], including the algorithms for
selecting fragment identification values, apply also to the IPv6
Extended Fragment Header. In particular, the source should reset its
starting Identification value frequently (e.g., per the [RFC7739]
algorithms) to maintain an unpredictable profile.
All normative security guidance on IPv6 fragmentation found in
[RFC8200] (e.g., processing of tiny first fragments, overlapping
fragments, etc.) applies also to the fragments generated under the
Extended Fragment Header.
Templin Expires 22 August 2024 [Page 13]
Internet-Draft IPv6 Extended Fragment Header February 2024
15. Acknowledgements
This work was inspired by continued DTN performance studies. Amanda
Baber, Tom Herbert, Bob Hinden, Christian Huitema, Mark Smith and
Eric Vyncke offered useful insights that helped improve the document.
Honoring life, liberty and the pursuit of happiness.
16. References
16.1. Normative References
[I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-28,
17 November 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-28>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[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>.
Templin Expires 22 August 2024 [Page 14]
Internet-Draft IPv6 Extended Fragment Header February 2024
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
16.2. Informative References
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
[I-D.templin-intarea-aero2]
Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
intarea-aero2-00, 16 February 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
templin-intarea-aero2/>.
[I-D.templin-intarea-omni2]
Templin, F. L., "Transmission of IP Packets over Overlay
Multilink Network (OMNI) Interfaces", Work in Progress,
Internet-Draft, draft-templin-intarea-omni2-01, 16
February 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
templin-intarea-omni2/>.
[I-D.templin-intarea-parcels2]
Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
Work in Progress, Internet-Draft, draft-templin-intarea-
parcels2-00, 15 February 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels2-00>.
[KENT87] Kent, C. and J. Mogul, ""Fragmentation Considered
Harmful", SIGCOMM '87: Proceedings of the ACM workshop on
Frontiers in computer communications technology, DOI
10.1145/55482.55524, http://www.hpl.hp.com/techreports/
Compaq-DEC/WRL-87-3.pdf.", August 1987.
Templin Expires 22 August 2024 [Page 15]
Internet-Draft IPv6 Extended Fragment Header February 2024
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.
[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>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
Appendix A. Change Log
<< RFC Editor - remove prior to publication >>
Templin Expires 22 August 2024 [Page 16]
Internet-Draft IPv6 Extended Fragment Header February 2024
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 22 August 2024 [Page 17]
