IPv6 Extended Fragment Header (EFH)
draft-templin-6man-ipid-ext2-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Fred Templin , Tom Herbert | ||
| Last updated | 2024-06-20 | ||
| Replaces | draft-templin-6man-ipid-ext | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-templin-6man-ipid-ext2-04
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Experimental T. Herbert
Expires: 22 December 2024 SiPanda
20 June 2024
IPv6 Extended Fragment Header (EFH)
draft-templin-6man-ipid-ext2-04
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 (EFH) that includes a 64-bit Identification with efficient
fragmentation and reassembly procedures.
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 December 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.
Please review these documents carefully, as they describe your rights
Templin & Herbert Expires 22 December 2024 [Page 1]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Extended Fragment Header (EFH) . . . . . . . . . . . . . 5
5. IPv6 Source Fragmentation . . . . . . . . . . . . . . . . . . 7
6. IPv6 Intermediate System Fragmentation . . . . . . . . . . . 8
7. IPv6 Destination Reassembly . . . . . . . . . . . . . . . . . 8
8. Destination Qualification and Path MTU . . . . . . . . . . . 9
9. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 9
10. MTU/Fragmentation Reports and Retransmissions . . . . . . . . 10
11. Multicast and Anycast . . . . . . . . . . . . . . . . . . . . 11
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
13. A Note on Fragmentation Considered Harmful . . . . . . . . . 13
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
16. Security Considerations . . . . . . . . . . . . . . . . . . . 14
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
18.1. Normative References . . . . . . . . . . . . . . . . . . 14
18.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 [RFC8200], but even its standard length of
32 bits 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 to 64 bits through the introduction of a new
IPv6 Extended Fragment Header (EFH).
The IPv6 EFH employs a fragmentation/reassembly algorithm based on an
ordinal fragment index combined with the non-final fragment payload
size instead of a 13-bit integer encoding an 8-octet offset. In this
arrangement, both fragmentation and reassembly are greatly simplified
Templin & Herbert Expires 22 December 2024 [Page 2]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
allowing for efficient implementations. These improvements are based
on an ample minimum fragment payload size made possible by the 1280
octet IPv6 minimum MTU.
The IPv6 EFH 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 IPv6 EFH in a Destination Options header may also make the option
less prone to 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.
The IPv6 EFH 64-bit Identification in some aspects analogous to the
Extended Sequence Number (ESN) supported by IPsec AH [RFC4302] and
ESP [RFC4303]. When transmitting the full 64-bit Identification may
be wasteful, nodes can apply header compression techniques to
transmit only the least significant bits while retaining the full
64-bit value in cache memory.
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 "Maximum Reassembly
Unit (MRU)" is equivalent to EMTU_R, and the term "maximum datagram
lifetime (MDL)" (defined in [RFC0791][RFC6864]) is equivalent to MSL.
The term "Packet Too Big (PTB)" refers to an ICMPv6 "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 that a node desires to label as a flow per [RFC6437].
The term "Extended Fragment Header (EFH)" refers to a new IPv6
Destination Option as specified in this document. The EFH is
included as the first option in the final Per-Fragment header, while
the remainder of the packet that follows is known as the "fragment
payload".
The Automatic Extended Route Optimization (AERO)
[I-D.templin-6man-aero3] and Overlay Multilink Network Interface
(OMNI) [I-D.templin-6man-omni3] services rely on the IPv6 EFH for
secure adaptation layer encapsulation and fragmentation.
Templin & Herbert Expires 22 December 2024 [Page 3]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
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, lower layer
IP fragmentation 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.
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) as reported in
[I-D.templin-dtn-ltpfrag]. The test setup included a pair of modern
high-performance servers with 100Gbps Ethernet cards connected via a
point-to-point link and running a modern public domain linux release.
TCP performance using the public domain 'iperf3' tool was proven to
increase when larger segment sizes are used even if they exceed the
path MTU and invoke a service known as Generic Segment/Receive
Offload (GSO/GRO).
LTP performance with segment sizes that exceed the path MTU was
similarly proven using the HDTN and ION-DTN LTP implementations which
engage IP fragmentation and reassembly. A significant effort was
made to incorporate Generic Segment and Receive Offload (GSO/GRO) in
ION-DTN, but those services contributed minimal performance
improvements whereas the performance improvements with IP
fragmentation and reassembly were dramatic.
Templin & Herbert Expires 22 December 2024 [Page 4]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
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 where
the network remembers recent Identification values for a flow to aid
detection of potential duplicates. When an encapsulation source
includes an IPv6 EFH, the extended Identification can also serve as a
sequence number that allows each encapsulation destination to exclude
any packets with values outside of the 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
(EFH).
4. IPv6 Extended Fragment Header (EFH)
For a standard 4-octet IPv6 Identification, the source can simply
include a standard 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.
For an extended Identification, advanced fragmentation and reassembly
procedures and/or for paths that drop packets including the standard
IPv6 Fragment Header, this specification permits the source to
instead include an IPv6 EFH. The source includes the IPv6 EFH as the
first option in a Destination Options Header positioned as the final
IPv6 Per-Fragment Header. The remainder of the packet beginning with
the Extension and Upper Layer Headers for the first fragment or
protocol data for non-first fragments is known as the fragment
payload.
The Destination Options header that includes the EFH option therefore
appears in each fragment in the same position where the standard
Fragment Header would otherwise appear while the Fragment Header
itself is omitted - see Sections 4.1 and 4.5 of [RFC8200].
The IPv6 EFH Destination Option is formatted as shown in Figure 1:
Templin & Herbert Expires 22 December 2024 [Page 5]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH-Actual | Reserved | Index |R|M| Sub-Index |R|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- Identification (64 bits) -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value 'XX0[TBD]'.
Opt Data Len 8-bit value 12.
NH-Actual the actual value of the original Destination
Options Next Header prior to fragmentation.
Reserved an 8-bit Reserved field. Initialized to zero
for transmission; ignored on reception.
Index/R/M a 6-bit "Index" field that identifies the
ordinal index for each fragment, followed
by a 1-bit "(R)eserved" flag (set to 0) and
a 1-bit "(M)ore Fragments" flag.
Sub-Index/R/N a 6-bit "Sub-Index" field that identifies the
ordinal index for each sub-fragment of the
same original fragment, followed by a 1-bit
"(R)eserved" flag (set to 0) and a 1-bit
"(N)ext Sub-Fragment" flag.
Identification an 8-octet (64 bit) unsigned integer
Identification, in network byte order.
Figure 1: IPv6 EFH Destination Option
The IPv6 EFH Destination Option is therefore identified as an Option
Type with the low-order 5 bits set to TBD (see: IANA Considerations)
and with the third-highest-order bit (i.e., "chg") set to 1. The
highest-order 2 bits (i.e., "act") are set to '01' or '1X' so that
destinations that do not recognize the option will drop the packet or
fragment and (possibly) also return an ICMPv6 Parameter Problem
message. 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.
Templin & Herbert Expires 22 December 2024 [Page 6]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
5. IPv6 Source Fragmentation
All aspects of IPv6 fragmentation using the EFH are conducted exactly
as for standard IPv6 fragmentation per Section 4.5 of [RFC8200]
except as specified below.
When the source performs fragmentation using the IPv6 EFH, it SHOULD
produce the smallest number of fragments possible within current path
MTU constraints and MUST produce no more than 64 fragments per
packet. The payload of each non-final fragment following the
Destination Options header MUST NOT be smaller than 1024 octets,
allowing for up to 256 octets of Per-Fragment headers plus any lower-
layer IP encapsulations within the 1280 octet IPv6 minimum path MTU.
Each non-final fragment payload MUST be equal in length, while the
final fragment payload MAY be smaller and MUST NOT be larger.
For each of the F fragments produced during fragmentation, the source
writes an ordinal index number beginning with 0 in the "Index" field
for the first fragment and increasing by 1 for each successive non-
first fragment while setting the "M" flag accordingly. Specifically,
the source sets (Index, M) to (0, 1) for the first fragment, (1, 1)
for the second, (2, 1) for the third, etc., up to and including
((F-1), 0) for the final fragment. The source also sets (Sub-Index,
N) to (0, 0) in all fragments.
For each fragment produced during fragmentation, the source includes
a Destination Options header as the final Per-Fragment header with
the IPv6 EFH as the first option followed by any other options. The
source then caches the Destination Options header Next Header value
in the NH-Actual field and (for each non-first fragment) resets the
Next Header field to "No Next Header". Intermediate systems that
forward non-first fragments prepared in this way will therefore
ignore the fragment payload that follows (by virtue of the "No Next
Header" setting) unless they are configured to more deeply inspect
the data content.
After performing source fragmentation but before releasing the
fragments, the source may become aware that the path and/or path MTU
has changed. If so, the source can perform further fragmentation for
each original fragment by producing "S" minimum-length sub-fragments
under the same procedures above, with non-final sub-fragment payloads
equal in length and no smaller than 1024 octets. The source MUST
write the same (NH-Actual, Index, M) values into each sub-fragment
while setting (Sub-Index, N) to (0, 1), (1, 1), (2, 1), etc. in each
successive non-final sub-fragment and setting ((S-1), 0) in the final
sub-fragment. The source MUST NOT perform further fragmentation on
sub-fragments that already include non-zero (Sub-Index, N) values.
Templin & Herbert Expires 22 December 2024 [Page 7]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
Note: when the source performs fragmentation in conjunction with IPv6
encapsulation over small MTU paths, the size of the encapsulation
headers may require the source to use a slightly larger non-final
fragment payload size (e.g., 1025 octets, 1026 octets, etc.) to
accommodate (near-)maximum sized original IP packets within the 64
fragment limit. The source is then responsible for ensuring that
this larger size does not cause the fragments to exceed the path MTU.
6. IPv6 Intermediate System Fragmentation
When an intermediate system detects a path change and/or a path MTU
reduction while forwarding an original fragment it MAY perform
further fragmentation using the (Sub-Index, N) fields if it can
easily locate the IPv6 EFH supplied by the source; otherwise, it
drops the fragment and returns a PTB message.
Intermediate system procedures for performing further fragmentation
are identical to those specified for the source (see: Section 5).
The intermediate system acts only as an agent for the source and
therefore MUST NOT insert an EFH itself.
7. IPv6 Destination Reassembly
All aspects of IPv6 reassembly using the EFH are conducted exactly as
for standard IPv6 reassembly per Section 4.5 of [RFC8200] except as
specified below.
When the destination receives original EFH fragments with the same
(Source, Destination, Identification)-tuple, it reassembles by
concatenating the payloads of consecutive fragments in ascending
ordinal Index numbers, i.e., ordinal 0, followed by 1, followed by 2,
etc. until all fragments are concatenated. In the process, the
destination discards any non-final fragments with payload lengths
less than 1024 octets or with payload lengths that differ from the
others.
When the destination receives EFH sub-fragments that set (Sub-Index,
N) to a value other than (0, 0), it first reassembles the original
fragment by concatenating the payloads of each sub-fragment the same
as described above. When the original fragment has been
reconstructed, the destination submits it for fragment-level
reassembly as described above. The destination should also return an
indication (see: Section 10) to recommend that the source re-probe
the path MTU.
Templin & Herbert Expires 22 December 2024 [Page 8]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
8. Destination Qualification and Path MTU
Destinations that do not recognize the IPv6 EFH option drop the
packet. If the Option Type "act" code is '1X', the destination also
returns 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 IPv6 EFH
option by occasionally sending "probe" packets that include the
option. The source has assurance that a destination recognizes the
option if it receives acknowledgments; otherwise, it may receive Code
2 ICMPv6 Parameter Problem messages as hints that a destination does
not recognize the option. 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 11).
The source can also include the IPv6 Minimum Path MTU Discovery Hop-
by-Hop option 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 10), it should regard the reported MTU as the largest
potential packet/fragment size for this destination under current
path MTU constraints noting that the actual size may be smaller still
for some paths.
9. 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 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].
The source should therefore probe the path MTU per [RFC9268] to
determine the maximum fragment size that can traverse the path. The
source can then perform source fragmentation using the IPv6 EFH
option with a maximum fragment size limited to the path MTU. If an
intermediate system detects a path change and can easily locate the
IPv6 EFH included by the source, it can perform sub-fragmentation to
produce sub-fragments that will not incur further MTU restrictions
(see: Section 6).
Templin & Herbert Expires 22 December 2024 [Page 9]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
10. MTU/Fragmentation Reports and Retransmissions
End systems that recognize the IPv6 EFH also recognize an MTU/
Fragmentation Report Option that uses option type TBD the same as for
the EFH itself except with the act code set to '00' and formatted as
shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | MRU (most-significant bits) |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- 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 a return packet to the source to report reassembly
congestion conditions and/or fragment loss. (Destinations that
receive IPv6 packets with both the IPv6 EFH Destination Option and
the IPv6 Minimum Path MTU Discovery Hop-by-Hop Option [RFC9268] can
also return MTU/Fragmentation Reports in this way.) Any return
packet (i.e., one with the source and destination addresses reversed)
can be used to carry the option, especially if it includes
identifying parameters and/or authentication signatures.
The destination sets MTU to the minimum of the incoming link MTU and
the MTU value recoded in the IPv6 Minimum Path MTU HBH option (if
present) to determine the maximum fragment size for the path. The
destination then sets MRU to the most significant 15 bits of the
recommended maximum reassembly size under current congestion
conditions and sets the P flag to 1 if the source should re-probe the
path. The destination then includes the leading 8 octets of the IPv6
header followed by the 8-octet Identification value for the current
packet undergoing reassembly in all cases.
Templin & Herbert Expires 22 December 2024 [Page 10]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
If all fragments of the packet (or the unfragmented packet itself)
have arrived the destination sets Opt Data Len to 20 and omits the
Bitmap field. If some fragments are missing, the destination instead
sets Length to 28 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 IP packets with the MTU/
Fragmentation Report Option, it should begin to reduce the size of
its future packet transmissions for the flow according to the MRU.
If the P flag is set, the source should also arrange to include an
IPv6 Minimum Path MTU Hop-by-Hop option in future packets to re-probe
the path. If the option further 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 as long as this would not interfere with
upper layer protocol retransmissions. When the source receives MTU/
Fragmentation Reports that advertise a larger MRU (or when it ceases
to receive reports), it can begin to increase its packet sizes for
the flow. This ensures that the packet size is adaptive for a given
flow.
Note: the MTU/Fragmentation Report option may appear in the same
Destination Options header that includes an IPv6 EFH option. The
IPv6 EFH must appear as the first option in the header and the two
options are differentiated by their 8-bit Option Type values. Their
sizes permit both options to appear without exceeding recommended
extension header limits (see: [I-D.ietf-6man-eh-limits]), but the
space remaining to include additional options in the same header may
be limited.
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.
11. 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 EFH, 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 EFH options to a
multicast group, the packets/fragments may be replicated in the
network such that a single transmission may reach N destinations over
Templin & Herbert Expires 22 December 2024 [Page 11]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
as many as N different paths. Some destinations may then return IPv6
packets with MTU/Fragmentation Reports if they experience congestion
and/or loss, while other destinations may return Code 2 ICMPv6
Parameter Problem messages if they do not recognize the IPv6 EFH
option.
While the source receives authentic PTB messages or authentic IP
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 IPv6 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 option 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.
12. Requirements
All normative aspects of standard IPv6 fragmentation and reassembly
as specified in [RFC8200] apply also to the IPv6 EFH except where
this document specifies differences.
All nodes that process an IPv6 Destination Options Header with EFH
and/or MTU/Fragmentation Report options observe the extension header
limits specified in [I-D.ietf-6man-eh-limits].
Destinations that accept flows using IPv6 EFH options MUST configure
an EMTU_R of 65535 octets or larger.
Sources MUST include at most one IPv6 Standard or Extended Fragment
Header in each IPv6 packet/fragment, and destinations MUST silently
drop packets/fragments with multiples. If the source includes an
IPv6 EFH, it MUST appear as the first option in a Destination Options
header that MUST appear as the final Per-Fragment header before the
fragment payload.
Templin & Herbert Expires 22 December 2024 [Page 12]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
Sources that include an IPv6 EFH option MUST perform fragmentation
such that at most 64 fragments are produced and all non-final
fragments include equal-length fragment payloads no smaller than 1024
octets. The final fragment MAY be smaller and MUST NOT be larger.
Sources that include the IPv6 EFH option in packet transmissions MUST
also recognize the MTU/Fragmentation Report option in received
packets as specified in Section 10.
13. 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 an improved IPv6
fragmentation and reassembly service that addresses these historical
concerns.
These early directions failed to consider that proper mitigations for
fragment loss can ensure a dynamic system that adaptively tunes
packet sizes according to current networking conditions on a per-flow
basis. Such a system can offer performance maximization benefits
through adaptive packet size management in a manner that parallels
TCP congestion control.
14. Implementation Status
In progress.
15. 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 type should appear in 4
consecutive table entries.
The first entry sets "act" to '00', "chg" to '0', "rest" to TBD,
"Description" to "IPv6 MTU/Fragmentation Report" and "Reference" to
this document [RFCXXXX].
Templin & Herbert Expires 22 December 2024 [Page 13]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
The next three entries set "act" to {'01', '10', '11'}, "chg" to '1',
"rest" to TBD, "Description" to "IPv6 Extended Fragment Header" and
"Reference" to this document [RFCXXXX].
Each table entry finally sets "Hex Value" to the 2-digit hexadecimal
value corresponding to the 8-bit concatenation of act/chg/rest.
16. 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 EFH.
In particular, the source should reset its starting Identification
value frequently (e.g., per the algorithms found in [RFC7739]) 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
IPv6 EFH.
IPsec AH [RFC4302] and ESP [RFC4303] define an Extended Sequence
Number (ESN) that is analogous to the 64-bit Identification specified
for the IPv6 EFH option. Nodes that employ the IPv6 EFH can use the
Identification value as a sequence number to improve security in the
same fashion as for IPsec AH/ESP ESNs.
17. Acknowledgements
This work was inspired by continued DTN performance studies. Amanda
Baber, 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.
18. References
18.1. Normative References
Templin & Herbert Expires 22 December 2024 [Page 14]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
[I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-32,
21 March 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-32>.
[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>.
[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>.
18.2. Informative References
Templin & Herbert Expires 22 December 2024 [Page 15]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
[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-13, 12 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-13>.
[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero3-08, 17 June 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero3-08>.
[I-D.templin-6man-omni3]
Templin, F., "Transmission of IP Packets over Overlay
Multilink Network (OMNI) Interfaces", Work in Progress,
Internet-Draft, draft-templin-6man-omni3-07, 14 June 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
omni3-07>.
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Performance Maximization", Work in
Progress, Internet-Draft, draft-templin-dtn-ltpfrag-17, 23
May 2024, <https://datatracker.ietf.org/doc/html/draft-
templin-dtn-ltpfrag-17>.
[I-D.templin-intarea-parcels2]
Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
Work in Progress, Internet-Draft, draft-templin-intarea-
parcels2-04, 22 May 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels2-04>.
[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.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
Templin & Herbert Expires 22 December 2024 [Page 16]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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>.
[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 >>
Differences from earlier versions:
* First draft publication.
Templin & Herbert Expires 22 December 2024 [Page 17]
Internet-Draft IPv6 Extended Fragment Header (EFH) June 2024
Authors' Addresses
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Tom Herbert
SiPanda
Santa Clara, CA
United States of America
Email: tom@sipanda.io
Templin & Herbert Expires 22 December 2024 [Page 18]