Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: 6864, 8200, 8900 (if approved) 6 October 2023
Intended status: Standards Track
Expires: 8 April 2024
Identification Extension for the Internet Protocol
draft-templin-intarea-ipid-ext-19
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 both an IPv4 header option
and an IPv6 Extended Fragment Header for Identification Extension; it
further provides a messaging service for fragmentation 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 8 April 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.
Templin Expires 8 April 2024 [Page 1]
Internet-Draft IP Identification Extension October 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv4 ID Extension . . . . . . . . . . . . . . . . . . . . . . 5
5. IPv4 ID Advanced Extension . . . . . . . . . . . . . . . . . 6
6. IPv4 ID (Parcel) Index Extension . . . . . . . . . . . . . . 6
7. IPv4 ID Applications . . . . . . . . . . . . . . . . . . . . 7
8. IPv6 ID Extension . . . . . . . . . . . . . . . . . . . . . . 7
9. IPv6 Network Fragmentation . . . . . . . . . . . . . . . . . 9
10. Packet Too Big (PTB) Extensions . . . . . . . . . . . . . . . 9
11. OMNI L2 Fragmentation and Reassembly . . . . . . . . . . . . 12
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13
13. A Note on Fragmentation Considered Harmful . . . . . . . . . 15
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . . 16
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Multicast and Anycast . . . . . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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]. 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 standard Fragment
Header [RFC8200]) to support reassembly integrity at higher data
rates.
Templin Expires 8 April 2024 [Page 2]
Internet-Draft IP Identification Extension October 2023
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. Nodes 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 an "advanced" mode that extends the
Identification field further for both IPv4 and IPv6. This format may
be useful for networks that operate at extreme data rates, or for
other cases when packet Identification uniqueness assurance is
critical. The specification finally supports a messaging service for
adaptive realtime response to congestion. Together, these extensions
enable robust fragmentation and reassembly services as well as packet
Identification uniqueness for the Internet.
2. Terminology
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
extended form.
The terms "Maximum Transmission Unit (MTU)", "Effective MTU to
Receive (EMTU_R)" and "Maximum Segment Lifetime (MSL)" are used
exactly the same as for standard Internetworking terminology
[RFC1122].
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.
The term "flow" refers to a sequence of packets sent from a
particular source to a particular unicast, anycast or multicast
destination [RFC6437].
The term "source" refers to either the original end system that
produces an IP packet or an encapsulation ingress intermediate system
on the path.
The term "destination" refers to either a decapsulation egress
intermediate system on the path or the final end system that consumes
an IP packet.
The term "intermediate system" refers to a node on the path from the
(original) source to the (final) destination that forward packets not
addressed to itself. Intermediate systems that decrement the IP TTL/
Hop Limit are also known as "routers".
Templin Expires 8 April 2024 [Page 3]
Internet-Draft IP Identification Extension October 2023
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 upper layer protocols can
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 2-octet (16-bit) IPv4 and 4-octet (32-bit)
IPv6 Identification fields may be too short to support reassembly
integrity at sufficiently high data rates. This specification
therefore proposes to fortify the IP ID by extending its length.
A recent study [I-D.templin-dtn-ltpfrag] proved that configuring
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. This
contradicts decades of unfounded assertions to the contrary and
validates the Internet architecture which includes fragmentation and
reassembly as core functions.
An alternative to extending the IP ID was also examined in which IPv4
packets were first encapsulated in IPv6 headers then subjected to
IPv6 fragmentation where a 4-octet 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 smaller 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, while the rates
may be comparable when IPv6 header compression is applied.
In addition to accommodating higher data rates in the presence of
fragmentation and reassembly, extending 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 to aid detection of potential
duplicates (note however that the network layer must not incorrectly
Templin Expires 8 April 2024 [Page 4]
Internet-Draft IP Identification Extension October 2023
flag intentional lower layer retransmissions as duplicates). An
extended IP ID can also provide a packet sequence number that allows
communicating peers to exclude any packets with IP ID values outside
of a current sequence number window for a flow as potential spurious
transmissions. These and other cases also apply even if the source
frequently resets its starting IP ID sequence numbers to maintain an
unpredictable profile [RFC7739].
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 provide
greater uniqueness assurance. This document therefore presents a
means to extend the IP ID to better support these services.
4. IPv4 ID Extension
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-length octet 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
Figure 1: IPv4 ID Extension (IDEXT) Option
When a source wishes to supply a 4-octet extended IP ID for an IPv4
packet, it includes an IDEXT option in the IPv4 packet header options
area, i.e., 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. During fragmentation, the source
copies the ID Extension option into each resulting fragment and sets
or clears the "Don't Fragment (DF)" flag as desired.
Templin Expires 8 April 2024 [Page 5]
Internet-Draft IP Identification Extension October 2023
The source then forwards each IPv4 packet/fragment to the next hop,
where each successive intermediate system will direct them toward the
destination. If an intermediate system on the path needs to apply
network fragmentation, it copies the IDEXT option into each resulting
fragment to provide the destination with the correct reassembly
context.
5. IPv4 ID Advanced Extension
When a source produces a sustained burst of IPv4 packets for a flow
at extreme data rates, (e.g., ~1Tbps) or when the source plans to
reset the IP ID starting sequence to a new pseudo-random value
frequently, it can optionally extend the IP ID even further by
supplying an 8-octet (64-bit), 12-octet (96-bit) or 16-octet
(128-bit) value instead of a 2/4-octet value.
To apply these longer extensions, the source includes an IDEXT option
with option-type set to TBD the same as above, but with option-length
("optlen") set to '8', '12' or '16' instead of '4' as shown in
Figure 2:
+--------+--------+--------+-~~~-+--------+
|100[TBD]| optlen | ID Extension |
+--------+--------+--------+-~~~-+--------+
Type=TBD Length=8/12/16
Figure 2: IDEXT Option with Advanced Extension
The option-data then includes a 6, 10 or 14-octet ID Extension, with
the most significant IP ID octets appearing in the extension in
network byte order and with the 2 least significant octets appearing
in the IPv4 Identification field. For a 6-octet extension, the
8-octet IP ID can then fit properly within the longest word length
for modern 64-bit architectures.
6. IPv4 ID (Parcel) Index Extension
[I-D.templin-intarea-parcels] specifies procedures for fragmenting
and reassembling the constituent packets derived from IP parcels that
have been opened somewhere along the path. Since each packet derived
from the same parcel shares the same Identification value, an
ancillary (Parcel) Index field is also necessary to differentiate the
packets.
Templin Expires 8 April 2024 [Page 6]
Internet-Draft IP Identification Extension October 2023
[I-D.templin-intarea-parcels] re-purposes the IPv6 Fragment Header
8-bit Reserved field to encode a (Parcel) Index, but the IPv4 header
does not provide sufficient space. With reference to Section 4 and
Section 5, this document therefore specifies the following IDEXT
option format with (Parcel) Index extension:
+--------+--------+--------+-~~~-+--------+--------+
|100[TBD]| optlen | ID Extension | Index |
+--------+--------+--------+-~~~-+--------+--------+
Type=TBD Length=5/9/13/17
Figure 3: IDEXT Option with (Parcel) Index Extension
When the IPv4 TBD option-length is '5', '9', '13', or '17', the
option-data instead includes 2, 6, 10 or 14 Identification extension
octets followed by the (Parcel) Index extension octet.
The (Parcel) Index extension octet field names and descriptions
appear in [I-D.templin-intarea-parcels].
7. IPv4 ID Applications
[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 extended-length 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 fragmentation and
reassembly support.
8. IPv6 ID Extension
Techniques that improve IPv4 often also apply in a corresponding
fashion for IPv6 (and vice-versa). The same is also true for IPv6 ID
Extensions.
For a simple 4-octet Identification value in IPv6, 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.
Templin Expires 8 April 2024 [Page 7]
Internet-Draft IP Identification Extension October 2023
For an advanced 4-octet Identification as well as for 8-octet or
12-octet Identification values, this document defines a new IPv6
Extended Fragment Header. The IPv6 Extended Fragment Header is
identified by the Next Header type value 'TBD2' (see: IANA
Considerations) and the format is shown in Figure 4:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- -+-+-+-+
| Identification (12 octets) |
+-+-+-+- -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Extended Fragment Header
In the above format, the control values in the first four octets are
interpreted exactly the same as for the standard IPv6 Fragment
Header, while the Identification field is 12 octets in length and
encodes a 96-bit value in network byte order. (When only a 32/64-bit
Identification is needed, the source sets the most significant 64/32
Identification bits to '0'.)
For both the Standard and Extended IPv6 Fragment Header, this
document further specifies a new coding for the 3 least significant
("flag") bits of the control field as shown in Figure 5:
2 3 3
9 0 1
+---+---+---+
| R | P | M |
| F | F | F |
+---+---+---+
Figure 5: Fragmentation Flag Bits
In this new coding, Bit 31 remains as the "More Fragments (MF)" flag,
while bit 30 is re-defined as the "Permit Fragmentation (PF)" flag
and bit 29 remains as a "Reserved Fragmentation (RF)" flag. When bit
30 is set to 0, network intermediate systems are not permitted to
fragment the packet; otherwise, network fragmentation is permitted.
Bit 29 is set to 0 on transmission and ignored on reception.
Templin Expires 8 April 2024 [Page 8]
Internet-Draft IP Identification Extension October 2023
9. IPv6 Network Fragmentation
When an IPv6 network intermediate system forwards a packet that
includes an IPv6 (Extended) Fragment Header, it applies (further)
fragmentation if the next hop link MTU is insufficient and if the
"Permit Fragmentation (PF)" flag is set to '1' (see: Section 8).
The "Permit Fragmentation (PF)" flag for IPv6 therefore provides a
"network fragmentation permitted" indication in the opposite sense of
the IPv4 "Don't Fragment (DF)" flag. When PF is set to 1, IPv6
intermediate systems are permitted to apply fragmentation on packets
that already include an IPv6 (Extended) Fragment Header, but never to
insert a fragment header themselves.
This specification therefore updates [RFC8200] by permitting network
fragmentation for IPv6 under the above conditions.
10. Packet Too Big (PTB) Extensions
When an intermediate system attempts to forward an IP packet that
exceeds the next hop link MTU but for which fragmentation is
forbidden, it returns a "Packet Too Big (PTB)" message to the source
[RFC1191][RFC4443][RFC8201] and discards the packet. This always
results in wasted transmissions by the source and all intermediate
systems on the path toward the one with the restricting link.
Conversely, when network fragmentation is permitted the network will
perform (further) fragmentation if necessary allowing the packet to
reach the destination without loss due to a size restriction. This
results in an internetwork that is adaptive to dynamic MTU
fluctuations and not subject to wasted transmissions.
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 that should be
communicated to the source. The source should then take measures to
reduce the size of the packets/fragments that it sends.
The IPv4 PTB format includes an "unused" field while the IPv6 PTB
format includes 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 due to a size restriction.
For end systems and intermediate systems that recognize IP ID
extensions according to this specification, the following additional
PTB unused/Code values are defined:
Templin Expires 8 April 2024 [Page 9]
Internet-Draft IP Identification Extension October 2023
1 Sent by an intermediate system (subject to rate limiting) when it
performs fragmentation on a packet with an extended IP ID (or a
UDP port, IP protocol or Ethernet type that honors IP ID
extensions such as OMNI [I-D.templin-intarea-omni]). The
intermediate system sends the PTB message while still fragmenting
and forwarding the packet. The MTU field of the PTB message
includes the maximum fragment size that can pass through the
restricting link as an indication for the source to reduce its
(source) fragment sizes. This size will often be considerably
smaller than the current EMTU_R advertised by the destination.
2 The same as for Code 1, except that the intermediate system drops
the packet instead of fragmenting and forwarding. This message
type represents a hard error that indicates loss. In one possible
strategy, the intermediate system could begin sending Code 1 PTBs
then revert to sending Code 2 PTBs if the source fails to reduce
its fragment sizes.
3 Sent by the destination (subject to rate limiting) when it
performs reassembly on a packet with an extended IP ID (or a UDP
port, IP protocol or Ethernet type that honors IP ID extensions
such as OMNI) either during periods of reassembly congestion or to
provide a keepalive pulse if it has no prior coordination with the
source. The destination sends the PTB message while still
reassembling and accepting the packet. The MTU field of the PTB
message includes the largest possible EMTU_R value under current
reassembly buffer congestion constraints as an indication for the
source to begin sending smaller packets if necessary. This size
will often be considerably larger than the path MTU and must be no
smaller than the IP protocol version minimum EMTU_R.
4 The same as for Code 3, except that the destination drops the
packet instead of reassembling and accepting. This message type
represents a hard error that indicates loss. In one possible
strategy, the destination could begin sending Code 3 PTBs then
revert to sending Code 4 PTBs if the source fails to reduce its
packet sizes.
5 Parcel Report - Sent by an intermediate system or destination in
response to an IP parcel that triggered the event (see:
[I-D.templin-intarea-parcels]).
6 Jumbo Report - Sent by an intermediate system or destination in
response to an IP advanced jumbo that triggered the event (see:
[I-D.templin-intarea-parcels]).
Templin Expires 8 April 2024 [Page 10]
Internet-Draft IP Identification Extension October 2023
When the source receives an authentic Code 1 or 2 PTB, it performs
source fragmentation on future packets for this flow using the
fragment size found in the MTU field which may be smaller than the
first hop link MTU. This reduces the burden on intermediate systems
in the path which will experience a reduced dependence on network
fragmentation.
When the source receives a Code 3 or 4 PTB, it reduces the size of
future packets for this flow if necessary based on the EMTU_R size
found in the MTU field which may be larger than the path MTU. This
reduces the burden on the destination which will experience a reduced
dependence on reassembly.
When a source that has no prior coordination with the destination
(such as a UDP port, IP protocol or Ethernet type that honors IP ID
extensions such as OMNI) ceases to receive Code 3 or 4 PTB messages,
it must assume that the destination no longer recognizes IP ID
extensions and must then impose rate limiting based on the wraparound
threshold for a non-extended Identification within the MSL [RFC6864].
These rate limitations can be relaxed when the source can include an
integrity check which the destination can verify.
When an intermediate system or destination returns a Code 1-6 PTB, it
prepares an ICMPv6 PTB message [RFC4443] and with MTU set as
discussed above. The node then writes its own IP address as the PTB
source and writes the source address of the packet that invoked the
report as the PTB destination (for IPv4, the node writes the PTB
address as an IPv4-Compatible IPv6 address [RFC4291]).
The node next copies as much of the leading portion of the invoking
packet as possible (beginning with the IP header) into the "packet in
error" field without causing the entire PTB (beginning with the IPv6
header) to exceed 512 octets in length. The node then sets the
ICMPv6 Checksum field to 0 instead of calculating and setting a true
checksum since the UDP checksum (see below) already provides an
integrity check.
Since IPv6 packets cannot transit IPv4 paths, and since middleboxes
often filter ICMPv6 messages as they transit IPv6 paths, the node
next wraps the ICMPv6 PTB message in UDP/IP headers of the correct IP
version with the IP source and destination addresses copied from the
PTB and with UDP port numbers set to the OMNI UDP port number
[I-D.templin-intarea-omni]. The node then calculates and sets the
UDP Checksum (and for IPv4 clears the DF bit). The node finally
sends the prepared PTB to the source.
Templin Expires 8 April 2024 [Page 11]
Internet-Draft IP Identification Extension October 2023
Note: Original sources that send packets with extended IP IDs must be
capable of accepting and processing these OMNI protocol UDP messages.
A source that sends packets with extended IP IDs must therefore
implement enough of the OMNI interface to be able to recognize and
process these messages.
11. OMNI L2 Fragmentation and Reassembly
The OMNI specification [I-D.templin-intarea-omni] provides an
encapsulation format in which UDP/IP headers that use UDP port 8060
serve as a "Layer 2 (L2)" encapsulation for OMNI IPv6-encapsulated IP
packets. The 4 bits immediately following the UDP header encode a
Type/Version code that determines the format of the information that
follows. The special Type value '5' identifies an IPv6 (Extended)
Fragment Header which is then followed by an OMNI IPv6 encapsulation
header followed by the original IP packet as shown in Figure 6:
+---------------------------+
| L2 IP Header |
+---------------------------+
| L2 UDP Header (port 8060) |
+---+-----------------------+
| 5 | IPv6 Fragment Header |
+---+-----------------------+
| OMNI IPv6 Encapsulation |
+---------------------------+
| |
~ ~
~ Original IP Packet ~
~ ~
| |
+---------------------------+
Figure 6: OMNI L2 Fragmentation and Reassembly
The OMNI interface encapsulates each original IP packet in an IPv6
encapsulation header as an OMNI Adaptation Layer (OAL) encapsulation.
The interface next encapsulates this "OAL packet" in UDP/IP headers
as "L2" encapsulations. When the packet requires L2 fragmentation,
however, the OMNI interface instead performs the following
operations:
* If the L2 IP header is IPv4, convert it to an IPv6 header while
converting the source and destination addresses to IPv4-compatible
IPv6 addresses.
Templin Expires 8 April 2024 [Page 12]
Internet-Draft IP Identification Extension October 2023
* Encapsulate the OAL packet in this L2 IPv6 header, then perform
normal IPv6 fragmentation. Each resulting IPv6 fragment will
include an IPv6 (Extended) Fragment Header with the correct
fragmentation parameters.
* Insert a UDP header between the L2 IPv6 header and IPv6 (Extended)
Fragment Header, then change the first 4 bits of the fragment
header to '5'.
* If the original L2 IP header was IPv4, re-convert the IPv6 header
back to IPv4.
* Set the UDP/IP header fields to the correct values for each
fragment, then transmit each fragment to the L2 destination.
When the L2 destination receives these (disguised) fragments, it
first notices the Type value '5' in the 4 bits immediately following
the L2 UDP header (using UDP port number 8060). The destination then
removes the L2 UDP header and (for IPv4) also converts the L2 IPv4
header to IPv6. The destination then changes the IPv6 (Extended)
Fragment Header "Next Header" field to '41' (i.e., IPv6
encapsulation) and submits the fragments for IPv6 reassembly.
Following reassembly, the destination discards the L2 headers to
arrive at the original OAL packet for delivery to the adaptation
layer.
Note: on the wire, these UDP/IP encapsulated IPv6 fragments will
appear as ordinary packets to network middleboxes that inspect
headers. This allows network middleboxes to make consistent
forwarding decisions on each fragment of the same original OAL packet
and without first attempting virtual fragment reassembly since each
fragment appears as a whole UDP/IP packet.
12. Requirements
IPv4 intermediate systems MUST forward without dropping packets with
IPv4 option-type TBD while copying the option during network
fragmentation, and IPv6 intermediate systems MUST forward without
dropping packets with IPv6 Next Header type TBD2.
IPv6 sources MUST include at most one IPv6 (Extended) Fragment Header
in each packet. IPv6 intermediate systems and destinations SHOULD
silently drop packets with multiple fragment headers.
Destinations that recognize IPv4 option-type TBD MUST accommodate
packets that include all extended IP ID formats based on any
4/8/12/16-octet value included by the source.
Templin Expires 8 April 2024 [Page 13]
Internet-Draft IP Identification Extension October 2023
Sources MUST transmit and destinations MUST process the octets of the
extended IP ID in network byte order with the base IP ID field
containing the least significant octets and the ID Extension field
containing the most significant octets. Implementations maintain the
IP ID as a 16-octet (128-bit) integer with any most significant
octets not included in an extension set to 0.
Destinations MUST be capable of reassembling packets as large as the
minimum Effective MTU to Receive (EMTU_R) specified for IPv4
([RFC1122], Section 3.3.2) or IPv6 ([RFC8200], section 5).
Destinations that accept flows using a UDP port number, IP protocol
number and/or Ethernet type value that recognizes extended IP IDs:
* MUST configure a minimum EMTU_R of 65535 octets,
* SHOULD advertise the largest possible EMTU_R in PTB messages and
* MAY advertise a reduced EMTU_R during periods of congestion.
Sources that produce flows using a UDP port number, IP protocol
number and/or Ethernet type value known to recognize extended IP IDs
(and for IPv4 when network fragmentation is disabled), can send
fragmented packets with extended IP IDs at high data rates and the
destination can silently reassemble unless/until it needs to assert
an EMTU_R indication due to reassembly congestion. For other flows,
the destination MUST return a continuous stream of EMTU_R indications
subject to rate limiting (see: Section 10) while it continues to
reassemble packets from the source. (Note that this latter option
applies only for unicast destinations; see: Appendix A for multicast/
anycast considerations.)
While a source has assurance that the destination(s) will recognize
and correctly process extended IP IDs, it can continue to send
fragmented or fragmentable packets as large as the EMTU_R at rates
within the Maximum Segment Lifetime (MSL) wraparound threshold for
the extended IP ID length; otherwise, the source honors the MSL
threshold for the non-extended Identification field length [RFC6864].
When the source includes sufficiently strong integrity checks that
the destination(s) can use to detect reassembly errors, however, it
can continue to send at rates that exceed the MSL wraparound
threshold.
Extended IP ID formats supported by this specification include only
the mandatory-to-implement (advanced) extended formats found in this
document which are differentiated by the option-length value for IPv4
or the extension header type for IPv6. Future documents may specify
additional extended IP ID formats.
Templin Expires 8 April 2024 [Page 14]
Internet-Draft IP Identification Extension October 2023
Note: IP fragmentation can only be applied for conventional packets
as large as 65535 octets. IP parcels and advanced jumbos provide a
means for efficiently packaging and shipping multiple large segments
or truly large singleton segments in packets that may exceed this
size [I-D.templin-intarea-parcels].
13. A Note on Fragmentation Considered Harmful
During the earliest days of internetworking, researchers asserted
that fragmentation should be deemed "harmful" based on empirical
observations in the ARPANET, DARPA Internet and other internetworks
of the day [KENT87]. These assertions somehow inspired an
engineering discipline known as "Path MTU Discovery" within a new
community that evolved to become the Internet Engineering Task Force
(IETF). In more recent times, the IETF amplified these assertions in
"IP Fragmentation Considered Fragile" [RFC8900].
Rather than encourage timely course corrections, however, the IETF
somehow forgot that IP fragmentation and reassembly still serve as
essential internetworking functions. This has resulted in a modern
Internet where path MTU discovery (including its recent derivatives)
provides a poor service for conventional packet sizes especially in
dynamic networks with path MTU diversity. This document 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, the services cannot be applied for jumbo packets that exceed
this size. Instead, modern path MTU discovery methods provide the
only possible solution to accommodate jumbos. This means that a
combined solution with fragmentation and reassembly applied for
conventional packets and path MTU discovery applied for jumbos
provides the necessary combination for internetworking futures. This
document therefore updates [RFC8900].
14. Implementation Status
In progress.
15. IANA Considerations
The IANA is requested to assign a new IPv4 Option named "IDEXT" in
the "IP Option Numbers" table in the 'ip-parameters' registry
(registration procedures not defined). The option sets "Copy" to
'1', "Class" to '00' and "Number" to TBD.
Templin Expires 8 April 2024 [Page 15]
Internet-Draft IP Identification Extension October 2023
The IANA is further requested to assign a new Protocol Number TBD2 in
the in the "Assigned Internet Protocol Numbers" table in the
'protocol-numbers' registry (registration procedures IESG Approval or
Standards Action). The registry sets Decimal to "TBD2", Keyword to
"IPv6-XFrag", Protocol to "Extended Fragment Header for IPv6" and
IPv6 Extension Header to "Y".
The IANA is instructed to assign new Code values in the "ICMPv6 Code
Fields: Type 2 - Packet Too Big" table in the 'icmpv6-parameters'
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 (soft) [RFCXXXX]
2 Fragmentation Needed (hard) [RFCXXXX]
3 Reassembly Needed (soft) [RFCXXXX]
4 Reassembly Needed (hard) [RFCXXXX]
5 Parcel Report [RFCXXXX]
6 Jumbo Report [RFCXXXX]
Figure 7: ICMPv6 Code Fields: Type 2 - Packet Too Big Values
(Note: this registry also defines the same above values for the
"unused" field of ICMPv4 "Destination Unreachable - Fragmentation
Needed" messages [RFC1191].)
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 a known
IPv4 reassembly integrity concern [RFC4963] and also provide an
advanced degree of packet Identification uniqueness assurance.
17. Acknowledgements
This work was inspired by continued DTN performance studies. Bob
Hinden and Tom Herbert offered useful insights that helped improve
the document.
Honoring life, liberty and the pursuit of happiness.
18. References
18.1. Normative References
Templin Expires 8 April 2024 [Page 16]
Internet-Draft IP Identification Extension October 2023
[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>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
18.2. Informative References
Templin Expires 8 April 2024 [Page 17]
Internet-Draft IP Identification Extension October 2023
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Fragmentation", Work in Progress,
Internet-Draft, draft-templin-dtn-ltpfrag-13, 20 September
2023, <https://datatracker.ietf.org/doc/html/draft-
templin-dtn-ltpfrag-13>.
[I-D.templin-intarea-omni]
Templin, F., "Transmission of IP Packets over Overlay
Multilink Network (OMNI) Interfaces", Work in Progress,
Internet-Draft, draft-templin-intarea-omni-39, 29
September 2023, <https://datatracker.ietf.org/doc/html/
draft-templin-intarea-omni-39>.
[I-D.templin-intarea-parcels]
Templin, F., "IP Parcels and Advanced Jumbos", Work in
Progress, Internet-Draft, draft-templin-intarea-parcels-
76, 26 September 2023,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels-76>.
[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.
[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>.
[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>.
Templin Expires 8 April 2024 [Page 18]
Internet-Draft IP Identification Extension October 2023
[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>.
[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>.
Appendix A. Multicast and Anycast
Although unicast flows are assumed throughout this document, the same
considerations apply for flows in which the destination is a
multicast group or an anycast address.
In order to send fragmented/fragmentable packets with IP ID
extensions (or IP fragmentation checksums) to a multicast group, the
source must have prior assurance that all group members will
correctly recognize and process them. This assurance is normally
through use of a UDP port number, IP protocol number and/or Ethernet
type for which extended IP ID processing is mandatory.
When a source sends fragmented/fragmentable packets with extended IP
IDs (or IP fragmentation checksums) to a multicast group, the
packets/fragments may be replicated in the network such that a single
transmission may reach N destinations over as many as N different
paths. Intermediate systems in each such path may return a Code 1/2
PTB message if (further) fragmentation is needed, and each such
destination may return a Code 3/4 PTB message if it experiences
reassembly congestion.
While the source receives these PTB messages, it should reduce the
fragment/packet sizes that 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.
When a source sends fragmented/fragmentable packets with extended IP
IDs (or IP fragmentation checksums) 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.
Templin Expires 8 April 2024 [Page 19]
Internet-Draft IP Identification Extension October 2023
Note: the source must not send fragmented/fragmentable packets that
include an extended IP ID (or IP fragmentation checksum) to a
multicast group or anycast address for which it does not have prior
assurance that all potential recipients will recognize them.
Otherwise, some recipients may correctly apply the IP ID extensions
while others silently ignore them and may become subject to
reassembly corruption.
Appendix B. 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 8 April 2024 [Page 20]