Internet DRAFT - draft-templin-6man-ipid-ext2

draft-templin-6man-ipid-ext2







Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: 8200, 8900, 9268 (if approved)                 19 February 2024
Intended status: Standards Track                                        
Expires: 22 August 2024


                     IPv6 Extended Fragment Header
                    draft-templin-6man-ipid-ext2-01

Abstract

   The Internet Protocol, version 4 (IPv4) header includes a 16-bit
   Identification field in all packets, but this length is too small to
   ensure reassembly integrity even at moderate data rates in modern
   networks.  Even for Internet Protocol, version 6 (IPv6), the 32-bit
   Identification field included when a Fragment Header is present may
   be smaller than desired for some applications.  This specification
   addresses these limitations by defining an IPv6 Extended Fragment
   Header that includes a 64-bit Identification; it further defines a
   control messaging service for fragment retransmission and reassembly
   congestion management.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.



Templin                  Expires 22 August 2024                 [Page 1]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IPv6 Extended Fragment Header . . . . . . . . . . . . . . . .   4
   5.  IPv6 Source Fragmentation . . . . . . . . . . . . . . . . . .   7
   6.  Destination Qualification and Path MTU  . . . . . . . . . . .   8
   7.  Packet Size Issues  . . . . . . . . . . . . . . . . . . . . .   8
   8.  MTU/Fragmentation Reports and Retransmissions . . . . . . . .   9
   9.  Multicast and Anycast . . . . . . . . . . . . . . . . . . . .  10
   10. Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. A Note on Fragmentation Considered Harmful  . . . . . . . . .  12
   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  13
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     16.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The Internet Protocol, version 4 (IPv4) header includes a 16-bit
   Identification in all packets [RFC0791], but this length is too small
   to ensure reassembly integrity even at moderate data rates in modern
   networks [RFC4963][RFC6864][RFC8900].  For Internet Protocol, version
   6 (IPv6), the Identification field is only present in packets that
   include a Fragment Header where its standard length is 32-bits
   [RFC8200], but even this length may be too small for some
   applications (such as those that regard the Identification value as a
   sequence number).  This specification therefore defines a means to
   extend the IPv6 Identification length through the introduction of a
   new IPv6 Extended Fragment Header.

   The Extended Fragment Header may be useful for networks that engage
   fragmentation and reassembly at extreme data rates, or for cases when
   advanced packet Identification uniqueness assurance is critical.
   (The placement of the Extended Fragment Header in a Destination
   Options header also makes the packet less prone to loss due to



Templin                  Expires 22 August 2024                 [Page 2]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   network filtering.)  This specification further defines a messaging
   service for adaptive realtime response to loss and congestion related
   to fragmentation/reassembly.  Together, these extensions support
   robust fragmentation and reassembly services as well as packet
   Identification uniqueness for IPv6.

2.  Terminology

   The terms "Maximum Transmission Unit (MTU)", "Effective MTU to
   Receive (EMTU_R)", "Effective MTU to Send (EMTU_S)" and "Maximum
   Segment Lifetime (MSL)" are used exactly the same as for standard
   Internetworking terminology [RFC1122].  The term MSL is equivalent to
   the term "maximum datagram lifetime (MDL)" defined in
   [RFC0791][RFC6864].

   The term "Packet Too Big (PTB)" refers to an IPv6 "Packet Too Big"
   [RFC8201][RFC4443] message.

   The term "flow" refers to a sequence of packets sent from a
   particular source to a particular unicast, anycast or multicast
   destination [RFC6437].

   The Automatic Extended Route Optimization (AERO)
   [I-D.templin-intarea-aero2] and Overlay Multilink Network Interface
   (OMNI) [I-D.templin-intarea-omni2] services rely on the IPv6 Extended
   Fragment Header for secure adaptation layer encapsulation and
   fragmentation.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Motivation

   Upper layer protocols often achieve greater performance by
   configuring segment sizes that exceed the path Maximum Transmission
   Unit (MTU).  When the segment size exceeds the path MTU, IP
   fragmentation at some layer is a natural consequence.  However, the
   4-octet (32-bit) Identification field of the Fragment Header may be
   too small to ensure reassembly integrity at sufficiently high data
   rates, especially when the source resets the starting sequence number
   often to maintain an unpredictable profile [RFC7739].  This
   specification therefore proposes to fortify the IPv6 Identification
   by extending its length.





Templin                  Expires 22 August 2024                 [Page 3]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Performance increases for upper layer protocols that use larger
   segment sizes was historically observed for NFS over UDP, and can
   still be readily observed today for TCP and the Delay Tolerant
   Network (DTN) Licklider Transmission Protocol (LTP).  A simple test
   setup consists of a pair of modern high-performance servers with
   100Gbps Ethernet cards connected via a point-to-point link and
   running a public domain linux release such as Ubuntu.  TCP
   performance using the public domain 'iperf3' tool is proven to
   increase when larger segment sizes are used even if they exceed the
   path MTU.

   LTP performance with segment sizes that exceed the path MTU is
   similarly proven using the HDTN and ION-DTN LTP implementations.
   QUIC performance testing using the 'qperf' tool does not show an
   advantage for the use of larger path MTUs (with or without
   fragmentation) since 'qperf' limits its packet sizes to 1280 octets.
   For this reason, 'qperf' performance was a factor of 4 less than LTP
   and a factor of 8 less than TCP when those protocols used larger
   packet sizes and/or invoked fragmentation.

   In addition to accommodating higher data rates in the presence of
   fragmentation and reassembly, extending the IPv6 Identification can
   enable other important services.  For example, an extended
   Identification can enable a duplicate packet detection service in
   which the network remembers recent Identification values for a flow
   to aid detection of potential duplicates (note however that the
   network layer must not incorrectly flag intentional lower layer
   retransmissions as duplicates).  An extended Identification can also
   provide a packet sequence number that allows communicating peers to
   exclude any packets with values outside of a current sequence number
   window for a flow as potential spurious transmissions.

   A robust IP fragmentation and reassembly service can provide a useful
   tool for performance maximization in the Internet when an extended
   Identification is available.  This document therefore presents a
   means to extend the IPv6 Identification to better support these
   services through the introduction of an IPv6 Extended Fragment
   Header.

4.  IPv6 Extended Fragment Header

   For a standard 4-octet IPv6 Identification, the source can simply
   include an ordinary IPv6 Fragment Header as specified in [RFC8200]
   with the Fragment Offset field and M flag set either to values
   appropriate for a fragmented packet or the value 0 for an
   unfragmented packet.  The source then includes a 4-octet
   Identification value for the packet.




Templin                  Expires 22 August 2024                 [Page 4]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   For an extended Identification and/or for paths that drop packets
   including the standard IPv6 Fragment Header, this specification
   permits the source to instead include an IPv6 Extended Fragment
   Header in a Destination Options Header in the same extension header
   order where the Fragment Header would normally appear.

   The source includes the Extended Fragment Header as the lone option
   in a Destination Options header inserted after any Per-Fragment
   headers and before the Extension and Upper Layer Headers for the
   first fragment or before the Fragment data for non-first fragments.
   The header therefore appears in each fragment in the same position
   where the standard Fragment Header would otherwise appear - see
   Sections 4.1 and 4.5 of [RFC8200].

   Since middleboxes may not recognize this as a Fragment Header,
   however, the source caches the Destination Options Next Header value
   in the Extended Fragment Header Option NH-Cache field and upon
   fragmentation sets the Next Header field to "No Next Header" to avoid
   any possibility for confusion (the destination will restore the Next
   Header value upon reassembly).

   The IPv6 Extended Fragment Header is formatted as shown in Figure 1:





























Templin                  Expires 22 August 2024                 [Page 5]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Option Type  |  Opt Data Len |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   NH-Cache    |   Index   |Res|      Fragment Offset    |Res|M|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-              Identification (64 bits)           -+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Next Header           Identifies the next header following the
                          Destination Options header containing the
                          Extended Fragment Header Option.

    Hdr Ext Len           Encodes the constant value 1, meaning 2
                          8-octet units.

    Option Type           8-bit value 'XX0[TBD1]'.

    Opt Data Len          8-bit value 12.

    NH-Cache              a cached copy of the original Destination
                          Options Next Header prior to fragmentation.

    Index/Res             a 6-bit "Index" field  that identifies the
                          ordinal fragment index for non-first fragments
                          of a fragmented packet, followed by a 2-bit
                          "(Res)erved" field. (For first fragments, the
                          Index field is also Reserved.)

    Offset/Res/M          the same as the fields of the standard IPv6
                          Fragment Header.

    Identification        an 8-octet (64 bit) unsigned integer
                          Identification, in network byte order.

                Figure 1: IPv6 Extended Fragment Header

   The Extended Fragment Header Option is therefore identified as an
   Option Type with the low-order 5 bits set to TBD1 (see: IANA
   Considerations), with the third-highest-order bit (i.e., "chg") set
   to 0 and with the highest-order 2 bits (i.e., "act") set as discussed
   below.  The Identification field is 8 octets (64 bits) in length, and
   a Destination Options header that includes the option may appear
   either in an unfragmented IPv6 packet or in one for which IPv6
   fragmentation is applied (with a copy of the header appearing in each
   fragment).




Templin                  Expires 22 August 2024                 [Page 6]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   When the source includes an Extended Fragment Header Option and
   applies source fragmentation (see: Section 5, it sets "act" to '01',
   '10' or '11' so that destinations that do not recognize the option
   will drop the fragments and (possibly) also return an ICMPv6
   Parameter Problem message.  When no source fragmentation is applied,
   the source can optionally set "act" to '00' allowing the destination
   to process the packet even if it does not recognize the Extended
   Fragment Header.

5.  IPv6 Source Fragmentation

   When the source applies source fragmentation using the Extended
   Fragment Header Option, fragmentation procedures are the same as for
   standard IPv6 fragmentation except that the Destination Options
   header containing the option appears in place of the standard IPv6
   Fragment Header (see: Section 4.5 of [RFC8200]) and the Fragment
   Header is omitted.

   During source fragmentation, the source SHOULD produce the smallest
   number of fragments possible (i.e., the largest possible fragments)
   within current path MTU constraints.  In particular, the source
   SHOULD limit the number of fragments produced to no more than 64
   fragments per packet, allowing for all conventional packet sizes up
   to and including the 65535 octet maximum under the 1280 octet IPv6
   minimum path MTU.

   For each fragment produced during fragmentation except for the first
   (i.e., the one with Offset=0), the source writes an ordinal index
   number in the Extended Fragment Header "Index" field.  Specifically,
   the source sets Index to 1 for the first non-first fragment, 2 for
   the second, 3 for the third, etc., up to and including the final
   fragment (i.e., the one with M=0).  If there are more than 64
   fragments, the source sets Index to 63 in all remaining fragments
   beginning with the 64th up to and including the final.

   The source also caches the Destination Options header Next Header
   value in the NH-Cache field.  For each fragment produced during
   fragmentation, the source includes the Destination Options header in
   place of the standard Fragment Header and resets its Next Header
   field to "No Next Header".

   The destination then reassembles the same as specified in Section 4.5
   of [RFC8200].  Following reassembly, the destination resets the
   Destination Options header Next Header field to the value cached in
   the NH-Cache field of the first fragment.






Templin                  Expires 22 August 2024                 [Page 7]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Intermediate systems that forward packets fragmented in this way will
   therefore ignore the data that follows the Extended Fragment Header
   Destination Options header (by virtue of the "No Next Header"
   setting) unless they are configured to more deeply inspect the data
   content.

6.  Destination Qualification and Path MTU

   Destinations that do not recognize the Extended Fragment Header
   Destination Option accept or drop the packet according to the Option
   Type "act" code.  If "act" is '00', destinations ignore the option
   and accept the packet.  For other "act" codes, destinations instead
   drop the packet and (for codes '1X') may return a Code 2 ICMPv6
   Parameter Problem message [RFC4443].  (ICMPv6 messages may be lost on
   the return path and/or manufactured by an adversary, however, and
   therefore provide only an advisory indication.)

   The source can then test whether destinations recognize the Extended
   Fragment Header by occasionally sending "probe" packets (either
   fragmented or unfragmented) that include the option with an "act"
   code other than '00'.  The source has assurance that some
   destinations recognize the option if it receives acknowledgments and/
   or hints that some destinations do not recognize the option if it
   receives ICMPv6 Parameter Problem messages.  The source should re-
   probe destinations occasionally in case routing redirects a flow to a
   different anycast destination or in case a multicast group membership
   changes (see: Section 9).

   The source can also include IPv6 Minimum Path MTU Discovery Hop-by-
   Hop Options in packets/fragments sent to unicast, multicast or
   anycast destinations per [RFC9268].  If the source receives
   acknowledgements that include an MTU/Fragmentation Report Option
   (see: Section 8), the source should regard the reported MTU as the
   largest potential fragment size for this destination under current
   path MTU conditions noting that the actual size may be smaller still
   for some paths.

7.  Packet Size Issues

   When a router attempts to forward an IPv6 packet (or fragment) that
   exceeds the next hop link MTU but for which fragmentation is
   forbidden, it returns a standard ICMPv6 Packet Too Big (PTB) message
   to the source [RFC4443][RFC8201] and discards the packet.  This
   always results in wasted transmissions by the source and all routers
   on the path toward the one with the restricting link.  Moreover, the
   messages are subject to spoofing and loss in the network [RFC2923].





Templin                  Expires 22 August 2024                 [Page 8]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Since routers are not permitted to perform IPv6 fragmentation, this
   means that the source should perform source fragmentation (if
   necessary) with a maximum fragment size limited to the path MTU.  If
   the source receives PTB messages, it should reduce the size of the
   packets/fragments it sends.

   While the fragmentation and reassembly processes eliminate wasted
   transmissions and support significant performance gains by
   accommodating upper layer protocol segment sizes that exceed the path
   MTU, the processes sometimes represent pain points for the
   destination and/or network as a whole that the destination should
   communicate to the source.  The source should then take measures to
   reduce the size of the packets that it sends.

8.  MTU/Fragmentation Reports and Retransmissions

   End systems that recognize the Extended Fragment Header also
   recognize an MTU/Fragmentation Report Option for TCP [RFC9293] and
   UDP [I-D.ietf-tsvwg-udp-options].  The {TCP,UDP} option is formatted
   as shown in Figure 2:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind      |     Length    |             ExID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         MTU (32 bits)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-            Identification (64 bits)             -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      +~+~+~+~          Bitmap (64 bits when present)          ~+~+~+~+
      |                                                               |
      +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+

                 Figure 2: MTU/Fragmentation Report Option

   The destination end system includes the MTU/Fragmentation Report
   Option in the {TCP,UDP} header of a return packet to the source when
   reassembly congestion and/or fragment loss occurs.  (Destinations
   that receive IPv6 packets with both the Extended Fragment Header
   Destination Option and the IPv6 Minimum Path MTU Discovery Hop-by-Hop
   Option [RFC9268] also return MTU/Fragmentation Reports in this way.)
   Any {TCP,UDP} packet that is part of an ongoing flow can be used to
   carry the option, especially if it includes identifying parameters
   and/or authentication signatures.





Templin                  Expires 22 August 2024                 [Page 9]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   The destination sets Kind to 253 for TCP [RFC6994][RFC9293] or 127
   for UDP [I-D.ietf-tsvwg-udp-options], then sets ExID to TBD2 (see:
   IANA Considerations).  The destination next sets MTU to the
   recommended receive size under current congestion conditions and sets
   Identification to the value for the current reassembly.  If all
   fragments of the packet (or the unfragmented packet itself) have
   arrived the destination sets Length to 16 and omits the Bitmap field.
   If some fragments are missing, the destination instead sets Length to
   20 and includes a 64-bit Bitmap field with Bitmap(i) (for i=0 to 63)
   set to 1 for each ordinal fragment index it has received for this
   reassembly and set to 0 for all others.

   When the source receives authentic {TCP,UDP}/IPv6 packets with the
   MTU/Fragmentation Report Option, it should decrease the size of its
   future packet transmissions to this destination, where the value in
   the MTU field includes a recommended maximum packet size under
   current congestion conditions.  If the option includes a Bitmap with
   some bits set to 0, the source can retransmit any missing ordinal
   fragments if it still has them in its cache.  When the source ceases
   to receive MTU/Fragmentation Reports, it can begin to increase the
   size of its future packet transmissions to this destination.

   Note: when the destination reassembles a fragment chain that includes
   more than 64 fragments, it sets Bitmap(63) to 1 only if it has
   received all ordinal fragments beginning with the 64th and beyond;
   otherwise, it sets Bitmap(63) to 0.  This may cause the source to
   unnecessarily retransmit many trailing fragments beginning with
   ordinal 63 up to and including the final fragment.

   Note: the above source packet size adaptation based on destination
   reassembly feedback parallels the Additive Increase, Multiplicative
   Decrease (AIMD) congestion control strategy employed by TCP and other
   reliable transports.

9.  Multicast and Anycast

   In addition to unicast flows, similar considerations apply for flows
   in which the destination is a multicast group or an anycast address.
   Unless the source and all candidate destinations are members of a
   limited domain network [RFC8799] for which all nodes recognize the
   IPv6 Extended Fragment Header Destination Option, some destinations
   may recognize the option while others drop packets containing the
   option and may return a Code 2 ICMPv6 Parameter Problem message
   [RFC4443].

   When a source sends packets/fragments with IPv6 Extended Fragment
   Headers to a multicast group, the packets/fragments may be replicated
   in the network such that a single transmission may reach N



Templin                  Expires 22 August 2024                [Page 10]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   destinations over as many as N different paths.  Some destinations
   may then return {TCP/UDP}/IPv6 packets with MTU/Fragmentation Reports
   if they experience congestion and/or loss.  (Some destinations may
   also return Code 2 ICMPv6 Parameter Problem messages if they do not
   recognize the Extended Fragment Header.)

   While the source receives authentic PTB messages or {TCP,UDP} packets
   with MTU/Fragmentation Reports, it should reduce the sizes of the
   packets/fragments it sends to the multicast group even if only one or
   a few paths or destinations are currently experiencing congestion.
   This means that transmissions to a multicast group will converge to
   the performance characteristics of the lowest common denominator
   group member destinations and/or paths.  While the source receives
   ICMPv6 Parameter Problem messages and/or otherwise detects that some
   multicast group members do not recognize the Extended Fragment Header
   Option, it must determine whether the benefits for group members that
   recognize the option outweigh the drawbacks of service denial for
   those that do not.

   When a source sends packets/fragments with IPv6 Extended Fragment
   Headers to an anycast address, routing may direct initial fragments
   of the same packet to a first destination that configures the address
   while directing the remaining fragments to other destinations that
   configure the address.  These wayward fragments will simply result in
   incomplete reassemblies at each such anycast destination which will
   soon purge the fragments from the reassembly buffer.  The source will
   eventually retransmit, and all resulting fragments should eventually
   reach a single reassembly target.

10.  Requirements

   All nodes that process an IPv6 Destination Options Header with
   Extended Fragment Header observe the extension header limits
   specified in [I-D.ietf-6man-eh-limits].

   Intermediate systems MUST forward without dropping IPv6 packets that
   include a Destination Options header with an Extended Fragment Header
   unless they detect a security policy threat through deeper inspection
   of protocol data that follows.

   Destinations that accept flows using Extended Fragment Headers MUST
   configure an EMTU_R of 65535 octets or larger.









Templin                  Expires 22 August 2024                [Page 11]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Sources MUST include at most one IPv6 Standard or Extended Fragment
   Header in each IPv6 packet/fragment.  Intermediate systems and
   destinations SHOULD silently drop packets/fragments with multiples.
   If the source includes an Extended Fragment Header Option, it must
   appear as the only option in a Destination Options header that
   appears in the same extension header order that the IPv6 Standard
   Fragment Header would normally appear.

   Sources and Destinations that recognize the Extended Fragment Header
   Option MUST also recognize the {TCP,UDP} MTU/Fragmentation Report
   Option as specified in Section 8.

   Sources SHOULD maintain a cache of recently-sent fragments in case
   the destination requests retransmission.  The destination is required
   to send an "ICMP Time Exceeded - Fragment Reassembly Time Exceeded"
   message if insufficient fragments are received to complete reassembly
   within 60 seconds (see: Section 4.5 of [RFC8200]), but that time may
   be longer than practical for the source to retain fragments in a
   retransmission cache.  The source SHOULD therefore maintain the cache
   for only a small time delta beyond the round-trip time to the
   destination, and the destination SHOULD send Fragmentation Reports as
   early as practically possible upon experiencing fragment loss.

11.  A Note on Fragmentation Considered Harmful

   During the earliest days of internetworking, researchers attributed
   the warning label "harmful" to IP fragmentation based on empirical
   observations in the ARPANET, DARPA Internet and other internetworks
   of the day [KENT87].  This inspired an engineering discipline known
   as "Path MTU Discovery" within an emerging community of interest
   known as the Internet Engineering Task Force (IETF).

   In more recent times, the IETF published "IP Fragmentation Considered
   Fragile" [RFC8900] to characterize the current state of fragmentation
   in the modern Internet.  The IPv6 Extended Fragment Header now
   introduces a more robust solution based on a properly functioning IP
   fragmentation and reassembly service as intended in the original
   architecture.

   Although the IP fragmentation and reassembly services provide an
   appropriate solution for conventional packet sizes as large as 65535
   octets, they cannot be applied for larger packets nor for IP parcels
   and Advanced Jumbos (AJs) of any size [I-D.templin-intarea-parcels2].
   This means that a combined solution with robust fragmentation and
   reassembly applied in parallel with traditional path MTU probing
   provides a combination well suited for Internetworking futures.  This
   document therefore updates [RFC8900].




Templin                  Expires 22 August 2024                [Page 12]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


12.  Implementation Status

   In progress.

13.  IANA Considerations

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

   The IANA is instructed to assign a new entry in the "TCP Experimental
   Option Experiment Identifiers (TCP ExIDs)" table of the 'tcp-
   parameters' registry (registration procedures First Come First Served
   per [RFC6994]).  The table entry should set "Value" to TBD2,
   "Description" to "MTU/Fragmentation Report" and "Reference" to this
   document [RFCXXXX].  The IANA is also instructed to assign the same
   value TBD2 as an entry in the to-be-created "UDP Experimental Option
   Experiment Identifiers (UDP ExIDs)" table (registration procedures
   First Come First served per [I-D.ietf-tsvwg-udp-options]).  This
   document places no preferences on the actual TBD2 value assignment.

14.  Security Considerations

   All aspects of IP security apply equally to this document, which does
   not introduce any new vulnerabilities.  Moreover, when employed
   correctly the mechanisms in this document robustly address known IP
   reassembly integrity concerns [RFC4963] and also provide an advanced
   degree of packet Identification uniqueness assurance.

   All security aspects of [RFC7739], including the algorithms for
   selecting fragment identification values, apply also to the IPv6
   Extended Fragment Header.  In particular, the source should reset its
   starting Identification value frequently (e.g., per the [RFC7739]
   algorithms) to maintain an unpredictable profile.

   All normative security guidance on IPv6 fragmentation found in
   [RFC8200] (e.g., processing of tiny first fragments, overlapping
   fragments, etc.) applies also to the fragments generated under the
   Extended Fragment Header.




Templin                  Expires 22 August 2024                [Page 13]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


15.  Acknowledgements

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

   Honoring life, liberty and the pursuit of happiness.

16.  References

16.1.  Normative References

   [I-D.ietf-tsvwg-udp-options]
              Touch, J. D., "Transport Options for UDP", Work in
              Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-28,
              17 November 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tsvwg-udp-options-28>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.





Templin                  Expires 22 August 2024                [Page 14]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              DOI 10.17487/RFC8201, July 2017,
              <https://www.rfc-editor.org/info/rfc8201>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

16.2.  Informative References

   [I-D.ietf-6man-eh-limits]
              Herbert, T., "Limits on Sending and Processing IPv6
              Extension Headers", Work in Progress, Internet-Draft,
              draft-ietf-6man-eh-limits-12, 18 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
              limits-12>.

   [I-D.templin-intarea-aero2]
              Templin, F. L., "Automatic Extended Route Optimization
              (AERO)", Work in Progress, Internet-Draft, draft-templin-
              intarea-aero2-00, 16 February 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              templin-intarea-aero2/>.

   [I-D.templin-intarea-omni2]
              Templin, F. L., "Transmission of IP Packets over Overlay
              Multilink Network (OMNI) Interfaces", Work in Progress,
              Internet-Draft, draft-templin-intarea-omni2-01, 16
              February 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              templin-intarea-omni2/>.

   [I-D.templin-intarea-parcels2]
              Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
              Work in Progress, Internet-Draft, draft-templin-intarea-
              parcels2-00, 15 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-templin-
              intarea-parcels2-00>.

   [KENT87]   Kent, C. and J. Mogul, ""Fragmentation Considered
              Harmful", SIGCOMM '87: Proceedings of the ACM workshop on
              Frontiers in computer communications technology, DOI
              10.1145/55482.55524, http://www.hpl.hp.com/techreports/
              Compaq-DEC/WRL-87-3.pdf.", August 1987.






Templin                  Expires 22 August 2024                [Page 15]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
              RFC 2923, DOI 10.17487/RFC2923, September 2000,
              <https://www.rfc-editor.org/info/rfc2923>.

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4963,
              DOI 10.17487/RFC4963, July 2007,
              <https://www.rfc-editor.org/info/rfc4963>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC6864]  Touch, J., "Updated Specification of the IPv4 ID Field",
              RFC 6864, DOI 10.17487/RFC6864, February 2013,
              <https://www.rfc-editor.org/info/rfc6864>.

   [RFC6994]  Touch, J., "Shared Use of Experimental TCP Options",
              RFC 6994, DOI 10.17487/RFC6994, August 2013,
              <https://www.rfc-editor.org/info/rfc6994>.

   [RFC7739]  Gont, F., "Security Implications of Predictable Fragment
              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
              February 2016, <https://www.rfc-editor.org/info/rfc7739>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8900]  Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
              and F. Gont, "IP Fragmentation Considered Fragile",
              BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
              <https://www.rfc-editor.org/info/rfc8900>.

   [RFC9268]  Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
              2022, <https://www.rfc-editor.org/info/rfc9268>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>




Templin                  Expires 22 August 2024                [Page 16]

Internet-Draft        IPv6 Extended Fragment Header        February 2024


   Differences from earlier versions:

   *  First draft publication.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org







































Templin                  Expires 22 August 2024                [Page 17]