Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft 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 Destination Options Extended Fragment Header option that includes a 64-bit Identification; it further defines a control messaging service for fragment retransmission and reassembly congestion management.

The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets , but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks . For Internet Protocol, version 6 (IPv6), the Identification field is only present in packets that include a Fragment Header where its standard length is 32-bits , but even this length may be too small for some applications. This specification therefore defines a means to extend the IPv6 Identification length through the introduction of a new IPv6 Destination Options Extended Fragment Header option. The Extended Fragment Header option 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 specification further defines a messaging service for adaptive realtime response to loss and congestion related to fragmentation and reassembly. Together, these extensions support robust fragmentation and reassembly services as well as packet Identification uniqueness for IPv6.

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)", "Effective MTU to Send (EMTU_S)" and "Maximum Segment Lifetime (MSL)" are used exactly the same as for standard Internetworking terminology . The term MSL is equivalent to the term "maximum datagram lifetime (MDL)" defined in . The term "Packet Too Big (PTB)" refers to an IPv6 "Packet Too Big" message. The term "flow" refers to a sequence of packets sent from a particular source to a particular unicast, anycast or multicast destination . 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 header 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 when, and only when, they appear in all capitals, as shown here.

Upper layer protocols often achieve greater performance by configuring segment sizes that exceed the path Maximum Transmission Unit (MTU). When the segment size exceeds the path MTU, IP fragmentation at some layer is a natural consequence. However, the 4-octet (32-bit) IPv6 Identification field 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 . This specification therefore proposes to fortify the IP ID by extending its length. 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. A robust IP fragmentation and reassembly service can provide a useful tool for performance maximization in the Internet when an extended IP ID is available. This document therefore presents a means to extend the IPv6 ID to better support these services through the introduction of an IPv6 Extended Fragment Header.

For a standard 4-octet IPv6 Identification, the source can simply include an ordinary IPv6 Fragment Header as specified in 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 and/or for paths that drop packets including the standard IPv6 Fragment Header, this specification permits the source to instead include an IPv6 Extended Fragment Header in a Destination Options Header. The Extended Fragment Header is included in a Per-Fragment Destination Options Header following the Hop-by-Hop Options (if present) but before the Routing Header (if present) - see Sections 4.1 and 4.5 of . The IPv6 Destination Options Header (with an Extended Fragment Header as the first option) is formatted as shown in :

The Extended Fragment Header option is therefore identified as an Option Type with the low-order 5 bits set to TBD1 (see: IANA Considerations), with the third-highest-order bit (i.e., "chg") set to 0 and with the highest-order 2 bits (i.e., "act") set as discussed below. The Identification field is 8 octets (64 bits) in length, and the option may appear either in an unfragmented IPv6 packet or in one for which IPv6 fragmentation is applied (with a copy of the header appearing in each fragment). When the source includes an Extended Fragment Header option and applies source fragmentation (see: , it sets the highest-order 2 bits of the option code to '01', '10' or '11' so that destinations that do not recognize the option will drop the fragments and (possibly) also return an ICMPv6 Parameter Problem message. When no source fragmentation is applied, the source can optionally set the highest-order 2 bits of the option code to '00' allowing the destination to process the packet even if it does not recognize the Extended Fragment Header.

When the source applies source fragmentation using the Extended Fragment Header destination option, fragmentation procedures are the same as for the standard IPv6 Fragment Header except that the Destination Option itself is included in the Per-Fragment headers (see: Section 4.5 of ) and the standard IPv6 Fragment Header is omitted. During source fragmentation, the source SHOULD produce the smallest number of fragments possible (i.e., the largest possible fragments) within current path MTU constraints. In particular, the source SHOULD limit the number of fragments produced to no more than 64 fragments per packet, allowing for all conventional packet sizes up to and including the 65535 octet maximum under the 1280 octet IPv6 minimum path MTU. For each fragment produced during fragmentation except for the first (i.e., the one with Offset=0), the source writes an ordinal index number in the Extended Fragment Header "Index" field. Specifically, the source sets Index to 1 for the first non-first fragment, 2 for the second, 3 for the third, etc., up to and including the final fragment (i.e., the one with M=0). If there are more than 64 fragments, the source sets Index to 63 in all remaining fragments beginning with the 64th up to and including the final. For each fragment produced during fragmentation, the source also caches the Next Header value found in the final Per-Fragment extension header in the NH-Cache field. The source then resets this final Next Header field to "No Next Header", noting that the "final" Per-Fragment extension header may be the Destination Options header containing the Extended Fragment Header itself. The destination then reassembles the same as specified in Section 4.5 of . Following reassembly, the destination resets the final Per-Fragment extension header Next Header field to the value cached in the NH-Cache field. Intermediate systems that forward packets fragmented in this way will therefore interpret the data that follows the Per-Fragment headers as undefined data (by virtue of the "No Next Header" setting) unless they are configured to more deeply inspect the data content.

Destinations that do not recognize the Extended Fragment Header Destination Option accept or drop the packet according to the Option Type "act" code. If the "act" code is '00', destinations ignore the option and accept the packet. For other codes, destinations instead drop the packet and (for "act" codes '1X') may return a Code 2 ICMPv6 Parameter Problem message . (ICMPv6 messages may be lost on the return path and/or manufactured by an adversary, however, and therefore provide only an advisory indication.) The source can then test whether destinations recognize the Extended Fragment Header by occasionally sending "probe" packets (either fragmented or unfragmented) that include the option with an "act" code other than '00'. The source has assurance that some destinations recognize the option if it receives acknowledgments and/or hints that some destinations do not recognize the option if it receives ICMPv6 Parameter Problem messages. The source should re-probe destinations occasionally in case routing redirects a flow to a different anycast destination or in case a multicast group membership changes (see: ). The source can also include IPv6 Minimum Path MTU Discovery Hop-by-Hop options in packets/fragments sent to unicast, multicast or anycast destinations per . If the source receives acknowledgements that include a return path MTU option, the source should regard the reported MTU as the largest potential fragment size for this destination under current path MTU conditions noting that the actual size may be smaller still for some paths.

When an intermediate system attempts to forward an IPv6 packet (or fragment) that exceeds the next hop link MTU but for which fragmentation is forbidden, it returns a standard ICMPv6 Packet Too Big (PTB) message to the source 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. Since intermediate systems are not permitted to perform IPv6 fragmentation, this means that the source should perform source fragmentation (if necessary) with a maximum fragment size limited to the path MTU. If the source receives PTB messages, it should reduce the size of the packets/fragments it sends. While the fragmentation and reassembly processes eliminate wasted transmissions and support significant performance gains by accommodating upper layer protocol segment sizes that exceed the path MTU, the processes sometimes represent pain points for the destination and/or network as a whole that the destination should communicate to the source. The source should then take measures to reduce the size of the packets that it sends. The ICMPv6 PTB format includes a Code field 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. End systems that recognize the Extended Fragment Header according to this specification also recognize a new PTB message type with Code value TBD2 instead of 0 (see: IANA Considerations). The message is sent by the destination end system as an advisory directive to the source end system when reassembly congestion and/or fragment loss occurs. This new PTB message type has a format and encoding as shown in :

Destinations that experience reassembly congestion and/or fragment loss can return a PTB message to the source with Code TBD2 and MTU set to a recommended maximum receive packet size under current congestion constraints. The destination sets Identification to the value for the current reassembly then, if all fragments of the packet have arrived, the destination sets all Bitmap(i) bits (for i=0 to 63) to 1. If some fragments are missing, the destination instead sets Bitmap(i) to 1 for each ordinal fragment index 'i' it has received for this reassembly and sets Bitmap(i) to 0 for all others. The destination finally includes as much of the first fragment as possible as the "packet-in-error" following the Bitmap; it the first fragment is missing, the destination instead includes the lowest-numbered ordinal fragment available. Sources that receive PTB messages with Code TBD2 should adaptively tune the size of the packets they send according to the recommended maximum receive packet size for better performance and to minimize congestion for the destination and the network as a whole. If the PTB includes a Bitmap with some Bitmap(i) bits set to 0, the source can retransmit any missing ordinal fragments if it still has them in its cache (ordinal fragments for which Bitmap(i) is set to 1 need not be retransmitted). Note: for reassembly of fragment chains that include more than 64 fragments, the destination sets Bitmap(63) to 1 only if all ordinal fragments beginning with the 64th and beyond have been received; otherwise, it sets Bitmap(63) to 0.

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 for which all nodes recognize the IPv6 Extended Fragment Header Destination Option, some destinations may recognize the option while others drop packets containing the option and may return a Code 2 ICMPv6 Parameter Problem message . When a source sends packets/fragments with IPv6 Extended Fragment Headers to a multicast group, the packets/fragments may be replicated in the network such that a single transmission may reach N destinations over as many as N different paths. Each such destination may return a Code TBD2 PTB message if it experiences congestion and/or loss. (Each destination may also return a Code 2 ICMPv6 Parameter Problem message if it does not recognize the option.) While the source receives 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. While the source receives ICMPv6 Parameter Problem messages, it must determine whether the benefits for group members that recognize the Extended Fragment Header option outweigh the drawbacks of service denial for those that do not. When a source sends packets/fragments with IPv6 Extended Fragment Headers to an anycast address, routing may direct initial fragments of the same packet to a first destination that configures the address while directing the remaining fragments to other destinations that configure the address. These wayward fragments will simply result in incomplete reassemblies at each such anycast destination which will soon purge the fragments from the reassembly buffer. The source will eventually retransmit, and all resulting fragments should eventually reach a single reassembly target.

All nodes that process an IPv6 Destination Options Header with Extended Fragment Header option observe the extension header limits specified in . Intermediate systems MUST forward without dropping IPv6 packets that include a Destination Options header with an Extended Fragment Header unless they detect a security policy threat through deeper inspection of the protocol data that follows. Sources MUST include at most one IPv6 Standard or Extended Fragment Header in each IPv6 packet/fragment. Intermediate systems and destinations SHOULD silently drop packets/fragments with multiples. If the source includes an Extended Fragment Header option, it must appear in a Per-Fragment Destination Options Header following the Hop-by-Hop Options Header if present but before the Routing Header if present. Destinations that accept flows using Extended Fragment Headers: MUST configure an EMTU_R of 65535 octets or larger, SHOULD advertise the largest possible receive packet size (i.e., as large as EMTU_R) in Code TBD2 PTB messages, and MAY advertise a reduced receive packet size in Code TBD2 PTB messages during periods of congestion. Sources and Destinations that recognize the Extended Fragment Header option MUST also recognize Code TBD2 PTB messages as specified in . Sources SHOULD maintain a cache of recently-sent fragments in case the destination requests retransmission. The destination is required to send an "ICMP Time Exceeded - Fragment Reassembly Time Exceeded" message if insufficient fragments are received to complete reassembly within 60 seconds (see: Section 4.5 of ), but that time may be longer than practical for the source to retain fragments in a retransmission cache. The source SHOULD therefore maintain the cache for only a small time delta beyond the round-trip time to the destination, and the destination SHOULD generate Code TBD2 PTBs as early as practically possible upon experiencing fragment loss.

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 . 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" to characterize the current state of fragmentation in the modern Internet. The IPv6 Extended Fragment Header now introduces a more robust solution based on a properly functioning IP fragmentation and reassembly service as intended in the original architecture. Although the IP fragmentation and reassembly services provide an appropriate solution for conventional packet sizes as large as 65535 octets, they cannot be applied for larger packets nor for IP parcels and Advanced Jumbos (AJs) . This means that a combined solution with robust fragmentation and reassembly applied in parallel with traditional path MTU probing provides a combination well suited for Internetworking futures. This document therefore updates .

In progress.

The IANA is requested to assign a new IPv6 Destination Option type in the "Destination Options and Hop-by-Hop Options" table of the 'ipv6-parameters' registry (registration procedures IESG Approval, IETF Review or Standards Action). The option should appear in 4 consecutive table entries that set "act" to 'XX', "chg" to '0', "rest" to TBD1, "Description" to "IPv6 Extended Fragment Header" and "Reference" to this document [RFCXXXX] (i.e., with act/chg set to 00/0 for the first line, 01/0 for the second line, 10/0 for the third line, and 11/0 for the fourth and final line). Each line also sets "Hex Value" to the 2-digit hexadecimal value corresponding to the 8-bit concatenation of act/chg/rest. The IANA is further instructed to assign a new Code value TBD2 in the "ICMPv6 Code Fields: Type 2 - Packet Too Big" table of the 'icmpv6-parameters' registry (registration procedure is Standards Action or IESG Approval). The registry should appear as follows:

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 and also provide an advanced degree of packet Identification uniqueness assurance. All normative security guidance on IPv6 fragmentation (e.g., processing of tiny first fragments, overlapping fragments, etc.) applies also to the fragments generated under the Extended Fragment Header.

This work was inspired by continued DTN performance studies. Amanda Baber, Tom Herbert, Bob Hinden, Christian Huitema, Mark Smith and Eric Vyncke offered useful insights that helped improve the document. Honoring life, liberty and the pursuit of happiness.

<< RFC Editor - remove prior to publication >> Differences from earlier versions: First draft publication.