| Internet-Draft | IP Identification Extension | October 2023 |
| Templin | Expires 14 April 2024 | [Page] |
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some 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.¶
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 14 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets [RFC0791], but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks [RFC4963] [RFC6864][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.¶
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.¶
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".¶
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.¶
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 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.¶
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
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.¶
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.¶
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
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.¶
[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.¶
[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
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].¶
[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.¶
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.¶
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) | +-+-+-+- -+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+---+---+---+
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.¶
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.¶
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:¶
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 [I-D.templin-intarea-omni]).¶
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.¶
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.¶
For paths that reject unrecognized IPv4 options or IPv6 extension headers, an alternate coding is necessary to avoid middlebox filtering. The source can elect to engage this alternate coding if the primary IP ID extension method fails or advance immediately to the alternate coding if it has reason to believe there is better opportunity for success. The alternate coding is based on the IPv6 (Extended) Fragment Header encapsulated in UDP/IP/Ethernet headers.¶
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 UDP header is then followed by a chain of IPv6 extension headers including an (Extended) Fragment Header with a 4 octet or longer IP ID. The extension header chain is then followed by an OMNI IPv6 encapsulation header in full/compressed form followed by the original IP packet as shown in Figure 6:¶
+---------------------------+ | L2 IP/Ethernet Header | +---------------------------+ | L2 UDP Header (port 8060) | +---------------------------+ ~ IPv6 Extension Headers ~ +---------------------------+ | OMNI IPv6 Encapsulation | +---------------------------+ | | ~ ~ ~ Original IP Packet ~ ~ ~ | | +---------------------------+
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 and/or any other extension header processing, the OMNI interface instead performs the following operations:¶
If the L2 header is IPv4 or Ethernet, convert it to an IPv6 header while converting the IPv4/EUI source and destination addresses to IPv4-compatible IPv6 addresses per [I-D.templin-intarea-omni].¶
Encapsulate the OAL packet in this L2 IPv6 header with any necessary IPv6 extension headers per [I-D.templin-intarea-omni], then perform normal extension header processing including fragmentation per [RFC8200]. Each resulting IPv6 fragment will include an IPv6 (Extended) Fragment Header with the correct fragmentation parameters.¶
For each fragment, insert a UDP header between the L2 IPv6 header and IPv6 extension headers, then adjust the Next Header field of each successive extension header per [I-D.templin-intarea-omni].¶
If the original L2 header was IPv4 or Ethernet, re-convert the IPv6 header back to IPv4/Ethernet.¶
If the L2 header was IP, change {Protocol, Next Header} to '17' (UDP), set the remaining 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 OMNI-encoded IPv6 extension headers immediately following the L2 OMNI UDP header. The destination then removes the L2 UDP header and (for IPv4) also converts the L2 IPv4 header to IPv6. The destination then applies any necessary OMNI IPv6 extension header processing, including reassembly. Following reassembly, the destination discards the L2 headers to arrive at the original OAL packet for delivery to the adaptation layer.¶
For L2 encapsulations that do not include a UDP header (e.g., IP-only), these fragments will include the IPv6 extension headers immediately after the L2 IP header. The L2 IP header must then set its IP {Protocol, Next Header} to the protocol number reserved for OMNI [I-D.templin-intarea-omni].¶
For L2 encapsulations that do not include UDP/IP headers (e.g., Ethernet-only), these fragments will include the IPv6 extension headers immediately after the true L2 header. The L2 header must then set its L2 type to the Ethertype reserved for OMNI [I-D.templin-intarea-omni].¶
Note: on the wire, these encapsulated IPv6 fragments will include an extended IP ID but will appear as ordinary packets to network middleboxes that inspect headers. This allows network middleboxes to make consistent forwarding decisions for each fragment of the same original OAL packet and without first attempting virtual fragment reassembly since each fragment appears as a whole packet.¶
Note: the above procedures can also be applied to ordinary TCP/UDP datagrams. In that case, the L2 IPv6 extension headers are immediately followed by a TCP/UDP header instead of an OMNI IPv6 encapsulation header.¶
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.¶
Sources MUST include at most one IPv6 (Extended) Fragment Header in each packet. 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.¶
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.¶
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].¶
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].¶
In progress.¶
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.¶
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]
(Note: this registry also defines the same above values for the "unused" field of ICMPv4 "Destination Unreachable - Fragmentation Needed" messages [RFC1191].)¶
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.¶
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.¶
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.¶
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.¶
<< RFC Editor - remove prior to publication >>¶
Differences from earlier versions:¶
First draft publication.¶