Skip to main content

IPv6 Parcels and Advanced Jumbos (AJs)
draft-templin-6man-parcels2-04

Document Type Active Internet-Draft (individual)
Author Fred Templin
Last updated 2024-05-22
Replaces draft-templin-6man-parcels
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-6man-parcels2-04
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: 9268 (if approved)                                  22 May 2024
Intended status: Standards Track                                        
Expires: 23 November 2024

                 IPv6 Parcels and Advanced Jumbos (AJs)
                     draft-templin-6man-parcels2-04

Abstract

   IPv6 packets contain a single unit of transport layer protocol data
   which becomes the retransmission unit in case of loss.  Transport
   layer protocols including the Transmission Control Protocol (TCP) and
   reliable transport protocol users of the User Datagram Protocol (UDP)
   prepare data units known as segments which the network layer packages
   into individual IPv6 packets each containing only a single segment.
   This specification presents new packet constructs termed IPv6 Parcels
   and Advanced Jumbos (AJs) with different properties.  Parcels permit
   a single packet to include multiple segments as a "packet-of-
   packets", while AJs offer essential operational advantages over basic
   jumbograms for transporting singleton segments of all sizes ranging
   from very small to very large.  Parcels and AJs provide essential
   building blocks for improved performance, efficiency and integrity
   while encouraging larger Maximum Transmission Units (MTUs) according
   to both the classic Internetworking link model and a new Delay
   Tolerant Network (DTN) link model.

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 23 November 2024.

Templin                 Expires 23 November 2024                [Page 1]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Background and Motivation . . . . . . . . . . . . . . . . . .   9
   5.  A Delay-Tolerant Networking (DTN) Link Model  . . . . . . . .  11
   6.  IPv6 Parcel Formation . . . . . . . . . . . . . . . . . . . .  14
     6.1.  TCP Parcels . . . . . . . . . . . . . . . . . . . . . . .  16
     6.2.  UDP Parcels . . . . . . . . . . . . . . . . . . . . . . .  17
     6.3.  Calculating J and K . . . . . . . . . . . . . . . . . . .  18
   7.  Transmission of IPv6 Parcels  . . . . . . . . . . . . . . . .  19
     7.1.  Packetization over Non-Parcel Links . . . . . . . . . . .  21
     7.2.  Parcellation over Parcel-capable Links  . . . . . . . . .  23
     7.3.  OMNI Interface Parcellation and Reunification . . . . . .  24
     7.4.  Final Destination Restoration/Reunification . . . . . . .  27
     7.5.  Parcel/AJ Path Probing  . . . . . . . . . . . . . . . . .  28
     7.6.  Parcel/Jumbo Reports  . . . . . . . . . . . . . . . . . .  32
   8.  Advanced Jumbos (AJ)  . . . . . . . . . . . . . . . . . . . .  33
   9.  OMNI Interface Jumbo-in-Jumbo Encapsulation . . . . . . . . .  35
   10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . .  39
   11. Implementation Status . . . . . . . . . . . . . . . . . . . .  42
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  44
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  45
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     15.2.  Informative References . . . . . . . . . . . . . . . . .  47
   Appendix A.  TCP Extensions for High Performance  . . . . . . . .  51
   Appendix B.  Extreme L Value Implications . . . . . . . . . . . .  52
   Appendix C.  Advanced Jumbo Cyclic Redundancy Check (CRC128J) . .  52
   Appendix D.  Change Log . . . . . . . . . . . . . . . . . . . . .  52
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  53

Templin                 Expires 23 November 2024                [Page 2]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

1.  Introduction

   IPv6 packets [RFC8200] contain a single unit of transport layer
   protocol data which becomes the retransmission unit in case of loss.
   Transport layer protocols such as the Transmission Control Protocol
   (TCP) [RFC9293] and reliable transport protocol users of the User
   Datagram Protocol (UDP) [RFC0768] (including QUIC [RFC9000], LTP
   [RFC5326] and others) prepare data units known as segments which the
   network layer packages into individual IPv6 packets each containing
   only a single segment.  This document presents a new construct termed
   the "IPv6 Parcel" which permits a single packet to include multiple
   segments.  The parcel is essentially a "packet-of-packets" with the
   full {TCP,UDP}/IPv6 headers appearing only once but with possibly
   multiple segments included.

   Transport layer protocol entities form parcels by preparing a data
   buffer (or buffer chain) containing at most 64 consecutive transport
   layer protocol segments that can be broken out into individual
   packets or smaller sub-parcels as necessary.  All segments except the
   final one must be equal in length and no larger than 65535 octets,
   while the final segment must be no larger than the others.  The
   transport layer protocol entity then presents the buffer(s), number
   of segments and non-final segment size to the network layer.  The
   network layer next appends per-segment headers and trailers, merges
   the segments into the parcel body, appends a single {TCP,UDP} header
   and finally appends a single IPv6 header plus extensions that
   identify this as a parcel and not an ordinary packet.

   The network layer then forwards each parcel over consecutive parcel-
   capable links in a path until they arrive at a node with a next hop
   link that does not support parcels, a parcel-capable link with a size
   restriction, or an ingress Overlay Multilink Network (OMNI) Interface
   [I-D.templin-6man-omni3] connection to an OMNI link that spans
   intermediate Internetworks.  In the first case, the original source
   or next hop router applies packetization to break the parcel into
   individual IPv6 packets.  In the second case, the node applies
   network layer parcellation to form smaller sub-parcels.  In the final
   case, the OMNI interface applies adaptation layer parcellation to
   form still smaller sub-parcels, then applies adaptation layer IPv6
   encapsulation and fragmentation if necessary.  The node then forwards
   the resulting packets/parcels/fragments to the next hop.

   Following IPv6 reassembly if necessary, an egress OMNI interface
   applies adaptation layer reunification if necessary to merge multiple
   sub-parcels into a minimum number of larger (sub-)parcels then
   delivers them to the network layer which either processes them
   locally or forwards them via the next hop link toward the final
   destination.  The final destination can then apply network layer

Templin                 Expires 23 November 2024                [Page 3]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   (parcel-based) reunification or (packet-based) restoration if
   necessary to deliver a minimum number of larger (sub-)parcels to the
   transport layer.  Reordering, loss or corruption of individual
   segments within the network is therefore possible, but most
   importantly the parcels delivered to the final destination's
   transport layer should be the largest practical size for best
   performance, and loss or receipt of individual segments (rather than
   parcel size) determines the retransmission unit.

   This document further introduces an "Advanced Jumbo (AJ)" service
   that provides essential extensions beyond the basic IPv6 jumbograms
   defined in [RFC2675].  AJs are simplified forms of parcels that
   provide end and intermediate systems with a robust delivery service
   when transmission of singleton segments of all sizes ranging from
   very small to very large is necessary.

   The following sections discuss rationale for adopting parcels and AJs
   as core elements of the Internet architecture, as well as the actual
   protocol constructs and operational procedures involved.  Parcels and
   AJs provide essential data transit for improved performance,
   efficiency and integrity while encouraging larger Maximum
   Transmission Units (MTUs).  A new Delay Tolerant Networking (DTN)
   link service model for parcels and AJs further supports delay/
   disruption tolerance especially suited for air/land/sea/space
   mobility applications.  These services should inspire future
   innovation in applications, transport protocols, operating systems,
   network equipment and data links in ways that promise to transform
   Internetworking.

2.  Terminology

   The Oxford Languages dictionary defines a "parcel" as "a thing or
   collection of things wrapped in paper in order to be carried or sent
   by mail".  Indeed, there are many examples of parcel delivery
   services worldwide that provide an essential transit backbone for
   efficient business and consumer transactions.

   In this same spirit, an "IPv6 parcel" is simply a collection of at
   most 64 transport layer protocol segments wrapped in an efficient
   package for transmission and delivery as a "packet-of-packets", with
   each segment including its own end-to-end integrity checks.  Each
   segment may be up to 65535 octets in length, and all non-final
   segments must be equal in length while the final segment must not be
   larger.  IPv6 parcels and AJs are distinguished from ordinary packets
   and jumbograms through the constructs specified in this document.

Templin                 Expires 23 November 2024                [Page 4]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The term "Advanced Jumbo (AJ)" refers to a parcel variation modeled
   from the basic IPv6 jumbogram construct defined in [RFC2675].  AJs
   include a 32-bit Jumbo Payload Length field and a single transport
   layer protocol segment the same as for basic IPv6 jumbograms, but are
   differentiated from true parcels and other jumbogram types by
   including an "Advanced Jumbo Type" value plus end-to-end segment
   integrity checks the same as for parcels.  Unlike basic IPv6
   jumbograms which are always 64KB or larger, AJs can range in size
   from as small as the headers plus a minimal or even null payload to
   as large as 2**32 octets minus headers.

   The term "link" is defined in [RFC8200] as: "a communication facility
   or medium over which nodes can communicate at the link layer, i.e.,
   the layer immediately below IPv6.  Examples are Ethernets (simple or
   bridged); PPP links; X.25, Frame Relay, or ATM networks; and
   internet-layer or higher-layer "tunnels", such as tunnels over IPv4
   or IPv6 itself".

   Where the document refers to "IPv6 header length", it means only the
   length of the base IPv6 header (i.e., 40 octets), while the length of
   any extension headers is referred to separately as the "IPv6
   extension header length".  The term "IPv6 header plus extensions"
   refers generically to an IPv6 header plus all included extension
   headers.

   Where the document refers to "{TCP,UDP} header length", it means the
   length of either the TCP header plus options (20 or more octets) or
   the UDP header (8 octets).  It is important to note that only a
   single IPv6 header and a single full {TCP,UDP} header appears in each
   parcel regardless of the number of segments included.  This
   distinction often provides a significant overhead savings advantage
   made possible only by parcels.

   Where the document refers to checksum calculations, it means the
   standard Internet checksum unless otherwise specified.  The same as
   for TCP [RFC9293] and UDP [RFC0768], the standard Internet checksum
   is defined as (sic) "the 16-bit one's complement of the one's
   complement sum of all (pseudo-)headers plus data, padded with zero
   octets at the end (if necessary) to make a multiple of two octets".
   A notional Internet checksum algorithm can be found in [RFC1071],
   while practical implementations require detailed attention to network
   byte ordering to ensure interoperability between diverse
   architectures.

   The term "Cyclic Redundancy Check (CRC)" is used consistently with
   its application in widely deployed Internetworking services.  Parcels
   that employ end-to-end CRC checks use the CRC32C [RFC3385] or CRC64E
   [ECMA-182] standards according to non-final segment length "L" (see:

Templin                 Expires 23 November 2024                [Page 5]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   Section 10).  AJs that employ end-to-end CRC checks include either a
   CRC or message digest calculated according to the MD5 [RFC1321], SHA1
   [RFC3174] or US Secure Hash [RFC6234] algorithms.  In all cases, the
   CRC or message digest is appended as a per-segment trailer arranged
   for transmission in network byte order per standard Internetworking
   conventions.

   The terms "application layer (L5 and higher)", "transport layer
   (L4)", "network layer (L3)", "(data) link layer (L2)" and "physical
   layer (L1)" are used consistently with common Internetworking
   terminology, with the understanding that reliable delivery protocol
   users of UDP are considered as transport layer elements.  The OMNI
   specification further defines an "adaptation layer" logically
   positioned below the network layer but above the link layer (which
   may include physical links and Internet- or higher-layer tunnels).
   The adaptation layer is not associated with a layer number itself and
   is simply known as "the layer below L3 but above L2".  A network
   interface is a node's attachment to a link (via L2), and an OMNI
   interface is therefore a node's attachment to an OMNI link (via the
   adaptation layer).

   The term "parcel-capable link/path" refers to paths that transit
   interfaces to adaptation layer and/or link layer media (either
   physical or virtual) capable of transiting {TCP,UDP}/IPv6 packets
   that employ the parcel/AJ constructs specified in this document.  The
   source and each router in the path has a "next hop link" that
   forwards parcels/AJs toward the final destination, while each router
   and the final destination has a "previous hop link" that accepts en
   route parcels/AJs.  Each next hop link must be capable of forwarding
   parcels/AJs (after first applying packetization or parcellation if
   necessary) with segment lengths no larger than can transit the link.

   The term "5-tuple" refers to a transport layer protocol entity
   identifier that includes the network layer (source address,
   destination address, source port, destination port, protocol number).
   The term "4-tuple" refers to a network layer parcel entity identifier
   that includes the adaptation layer (source address, destination
   address, Parcel ID, Identification).

   The Internetworking term "Maximum Transmission Unit (MTU)" is widely
   understood to mean the largest packet size that can transit a single
   link ("link MTU") or an entire path ("path MTU") without requiring
   network layer fragmentation.  The "Parcel/AJ Path MTU" value returned
   during parcel path qualification determines the maximum sized parcel/
   AJ that can transit the leading portion of the path up to a router
   that cannot forward the parcel/AJ further, while the "Residual Path
   MTU" determines the maximum-sized conventional packet that can
   transit the remainder of the path following packetization.  (Note

Templin                 Expires 23 November 2024                [Page 6]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   that for paths that include a significant number of routers that do
   not recognize the parcel construct the Residual Path MTU may be over-
   estimated.)

   The terms "packetization" and "restoration" refer to a network layer
   process in which the original source or a router on the path breaks a
   parcel/AJ out into individual IPv6 packets that can transit the
   remainder of the path without loss due to a size restriction.  The
   final destination then restores the combined packet contents into a
   parcel before delivery to the transport layer.  In current practice,
   packetization/restoration can be considered as functional equivalents
   to the well-known Generic Segmentation/Receive Offload (GSO/GRO)
   services.

   The terms "parcellation" and "reunification" refer to either network
   layer or adaptation layer processes in which the original source or a
   router on the path breaks a parcel into smaller sub-parcels that can
   transit the path without loss due to a size restriction.  These sub-
   parcels are then reunified into larger (sub-)parcels before delivery
   to the transport layer.  As a network layer process, the sub-parcels
   resulting from parcellation may only be reunified at the final
   destination.  As an adaptation layer process, the resulting sub-
   parcels may first be reunified at an adaptation layer egress node
   then possibly further reunified by the network layer of the final
   destination.

   The terms "fragmentation" and "reassembly" follow exactly from their
   definitions in the IPv6 standard [RFC8200].  In particular, OMNI
   interfaces support IPv6 encapsulation and fragmentation as an
   adaptation layer process that can transit packet/parcel/AJ sizes that
   exceed the underlying Internetwork path MTU.  OMNI interface
   fragmentation/reassembly occurs at a lower layer of the protocol
   stack than packetization/restoration and/or parcellation/
   reunification and therefore provides a complimentary service.  Note
   that IPv6 parcels and AJs are not eligible for direct fragmentation
   and reassembly at the network layer but become eligible for
   adaptation layer fragmentation and reassembly following OMNI IPv6
   encapsulation.

Templin                 Expires 23 November 2024                [Page 7]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   "Automatic Extended Route Optimization (AERO)"
   [I-D.templin-6man-aero3] and the "Overlay Multilink Network Interface
   (OMNI)" [I-D.templin-6man-omni3] provide an adaptation layer
   framework for transmission of parcels/AJs over one or more
   concatenated Internetworks.  AERO/OMNI will provide an operational
   environment for parcels/AJs beginning from the earliest deployment
   phases and extending indefinitely to accommodate continuous future
   growth.  As more and more parcel/AJ-capable links are enabled (e.g.,
   in data centers, wireless edge networks, space-domain optical links,
   etc.)  AERO/OMNI will continue to provide an essential service for
   Internetworking performance maximization.

   The terms "(original) source" and "(final) destination" refer to host
   systems that produce and consume IPv6 packets/parcels/AJs,
   respectively.  The term "router" refers to a system that forwards
   IPv6 packets/parcels/AJs not addressed to itself while decrementing
   the Hop Limit.  The terms "OAL source", "OAL intermediate system" and
   "OAL destination" refer to OMNI Adaptation Layer (OAL) nodes that
   (respectively) produce, forward and consume OAL-encapsulated IPv6
   packets/parcels/AJs over an OMNI link.

   The terms "controlled environment" and "limited domain" follow
   directly from [RFC8799].  All nodes within a controlled environment /
   limited domain are expected to honor the protocol specifications
   found in this document, whereas nodes on open Internetworks may
   exhibit varying levels of conformance.

   The parcel sizing variables "J", "K", "L" and "M" are cited
   extensively throughout this document.  "J" denotes the number of non-
   final segments included in the parcel, "K" is the length of the final
   segment, "L" is the length of each non-final segment and "M" is
   termed the "Parcel Payload Length".

3.  Requirements

   All IPv6 source hosts, destination hosts and routers that accept IPv6
   parcels and Advanced Jumbos MUST implement all aspects of this
   specification that apply to their functions.  IPv6 nodes MUST NOT for
   example implement some aspects of their functions according to the
   specification while ignoring other aspects.  All IPv6 nodes also MUST
   observe their respective requirements found in the normative
   references, including [RFC8200].

Templin                 Expires 23 November 2024                [Page 8]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   IPv6 parcels and AJs are derived from the basic jumbogram
   specification found in [RFC2675], but the specifications in this
   document take precedence whenever they differ from the basic
   requirements.  Most notably, IPv6 parcels and AJs use an adaptation
   of the IPv6 Minimum Path MTU Hop-By-Hop Option [RFC9268] instead of
   the basic IPv6 Jumbo Payload Option [RFC2675].

   IPv6 parcels/AJs are not limited only to segment sizes that exceed
   65535 octets; instead, parcels can be as small as the packet headers
   plus a singleton segment with its integrity checks while AJs can be
   as small as the headers plus a NULL payload.  IPv6 parcels/AJs are
   not eligible for direct network layer IPv6 fragmentation and
   reassembly although they may become eligible for adaptation layer
   fragmentation and reassembly following OMNI IPv6 encapsulation.  IPv6
   parcels and AJs therefore SHOULD NOT include IPv6 (Extended) Fragment
   Headers, and implementation MUST silently ignore any IPv6 (Extended)
   Fragment Headers in IPv6 parcels and AJs.

   For further Hop-by-Hop Options considerations, see:
   [I-D.ietf-6man-hbh-processing].  For IPv6 extension header limits,
   see: [I-D.ietf-6man-eh-limits].  For IPv4 parcel and advanced jumbo
   considerations, see: [I-D.templin-intarea-parcels2].

   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.

4.  Background and Motivation

   Studies have shown that applications can improve their performance by
   sending and receiving larger packets due to reduced numbers of system
   calls and interrupts as well as larger atomic data copies between
   kernel and user space.  Larger packets also result in reduced numbers
   of network device interrupts and better network utilization (e.g.,
   due to header overhead reduction) in comparison with smaller packets.
   However, the most prominent performance increases were observed by
   increasing the transport layer protocol segment size even if doing so
   invoked network layer fragmentation.

Templin                 Expires 23 November 2024                [Page 9]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   A first study [QUIC] involved performance enhancement of the QUIC
   protocol [RFC9000] using the linux Generic Segment/Receive Offload
   (GSO/GRO) facility.  GSO/GRO provides a robust service that has shown
   significant performance increases based on a multi-segment transfer
   capability between the operating system kernel and QUIC applications.
   GSO/GRO performs (virtual) fragmentation and reassembly at the
   transport layer with the transport protocol segment size limited by
   the path MTU (typically 1500 octets or smaller in current
   Internetworking practices).

   A second study [I-D.templin-dtn-ltpfrag] showed that GSO/GRO also
   improves performance for the Licklider Transmission Protocol (LTP)
   [RFC5326] used for the Delay Tolerant Networking (DTN) Bundle
   Protocol [RFC9171] for segments larger than the actual path MTU
   through the use of IP fragmentation.  Historically, the NFS protocol
   also saw significant performance increases using larger (single-
   segment) UDP datagrams even when IP fragmentation is invoked, and LTP
   still follows this profile today.  Moreover, LTP shows this (single-
   segment) performance increase profile extending to the largest
   possible segment size which suggests that additional performance
   gains are possible using (multi-segment) parcels or AJs that approach
   or even exceed 65535 octets in total length.

   TCP also benefits from larger packet sizes and efforts have
   investigated TCP performance using jumbograms internally with changes
   to the linux GSO/GRO facilities [BIG-TCP].  The approach proposed to
   use the Jumbo Payload Option internally and to allow GSO/GRO to use
   buffer sizes that exceed 65535 octets, but with the understanding
   that links that support jumbograms natively are not yet widely
   deployed and/or enabled.  Hence, parcels/AJs provide a packaging that
   can be considered in the near term under current deployment
   limitations.

   A limiting consideration for sending large packets is that they are
   often lost at links with MTU restrictions, and the resulting Packet
   Too Big (PTB) messages [RFC4443][RFC8201] may be lost somewhere in
   the return path to the original source.  This path MTU "black hole"
   condition can degrade performance unless robust path probing
   techniques are used, however the best case performance always occurs
   when loss of packets due to size restrictions is minimized.

   These considerations therefore motivate a design where transport
   protocols can employ segment sizes as large as 65535 octets (minus
   headers) while parcels that carry multiple segments may themselves be
   significantly larger.  (Transport layer protocols can also use AJs to
   transit even larger singleton segments.)  Parcels allow the receiving
   transport layer protocol entity to process multiple segments in
   parallel instead of one at a time per existing practices.  Parcels

Templin                 Expires 23 November 2024               [Page 10]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   therefore support improvements in performance, integrity and
   efficiency for the original source, final destination and networked
   path as a whole.  This is true even if the network and lower layers
   need to apply packetization/restoration, parcellation/reunification
   and/or fragmentation/reassembly.

   An analogy: when a consumer orders 50 small items from a major online
   retailer, the retailer does not ship the order in 50 separate small
   boxes.  Instead, the retailer packs as many of the small items as
   possible into one or a few larger boxes (i.e., parcels) then places
   the parcels on a semi-truck or airplane.  The parcels may then pass
   through one or more regional distribution centers where they may be
   repackaged into different parcel configurations and forwarded further
   until they are finally delivered to the consumer.  But most often,
   the consumer will only find one or a few parcels at their doorstep
   and not 50 separate small boxes.  This flexible parcel delivery
   service greatly reduces shipping and handling cost for all including
   the retailer, regional distribution centers and finally the consumer.

5.  A Delay-Tolerant Networking (DTN) Link Model

   The classic Internetworking link service model requires each link in
   the path to apply a link-layer integrity check often termed a "Frame
   Check Sequence (FCS)" over the entire length of the frame.  The link
   near-end calculates and appends an FCS trailer to each packet pending
   transmission, and the link far-end verifies the FCS upon packet
   reception.  If verification fails, the link far-end unconditionally
   discards the packet.  This process is repeated for each link in the
   path so that only packets that pass all link-layer checks over their
   full lengths are delivered to the final destination.  (Note that
   Internet- or higher-layer tunnels may traverse many underlying
   physical links that each apply their own FCS in series.)

Templin                 Expires 23 November 2024               [Page 11]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   While the classic link model has contributed to the unparalleled
   success of terrestrial Internetworks (including the global public
   Internet), new uses in which significant delays or disruptions can
   occur are not as well supported.  For example, a path that contains
   multiple links with higher bit error rates may be unable to pass an
   acceptable percentage of packets since loss due to link errors can
   occur at any hop.  Moreover, packets that incur errors at an
   intermediate link but somehow pass the link integrity check will be
   forwarded by all remaining links in the path leaving only the final
   destination's integrity checking as a last resort.  Advanced error
   detection and correction services not typically associated with
   packets are therefore necessary; especially with the advent of space-
   domain and wireless Internetworking, long delays and significant
   disruptions are often intolerant of retransmissions.  This
   specification therefore introduces a new Delay Tolerant Networking
   (DTN) link model.

   IPv6 parcels/AJs that engage this DTN link model include a limited
   hop-by-hop integrity check that covers only the headers plus a
   leading portion of the payload.  Each IPv6 parcel/AJ also includes
   per-segment end-to-end Cyclic Redundancy Checks (CRCs) or message
   digests inserted by the original source and verified by the final
   destination.  For each parcel/AJ admitted under the DTN link model,
   the link near-end applies its standard link-layer FCS for only the
   leading portion upon transmission as indicated by the IPv6 Payload
   Length then writes the FCS as a trailer following the end of the
   parcel/AJ payload.

   The link far-end then verifies the FCS for the leading portion upon
   reception and discards the parcel/AJ if an error is detected.
   However, each link in the path passes parcels/AJs with valid headers
   through to the final destination even if the unchecked portion of the
   payload accumulates bit errors in transit.  The per segment end-to-
   end CRCs/digests and/or Internet checksums included by the original
   source support final destination integrity checking.  The final
   destination in turn delivers each segment to the local transport
   layer which should employ transport or higher-layer integrity checks
   and invoke any necessary corrective actions such as Forward Error
   Correction (FEC).

   The ubiquitous 1500 octet link MTU had its origins in the very
   earliest deployments of 10Mbps Ethernet technologies, however modern
   wired-line link data rates of 1Gbps are now typical for end user
   devices such as laptop computers while much higher rates of 10Gbps,
   100Gbps or even more commonly occur for data center servers.  At
   these data rates, the serialization delays range from 1200usec at
   10Mbps to only .12usec at 100Gbps [ETHERMTU] (still higher data rates
   are expected in the near future).  This suggests that the legacy 1500

Templin                 Expires 23 November 2024               [Page 12]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   MTU may be too small by multiple orders of magnitude for many well-
   connected data centers, wide-area wired-line networked paths or even
   for deep space communications over optical links.  For such cases,
   larger parcels and AJs present performance maximization constructs
   that support larger transport layer segment sizes.

   While data centers, Internetworking backbones and deep space networks
   are often connected through robust fixed link services, the Internet
   edge is rapidly evolving into a much more mobile environment where 5G
   (and beyond) cellular services and WiFi radios connect a growing
   majority of end user systems.  Although some wireless edge networks
   and mobile ad-hoc networks support considerable data rates, more
   typical rates with wireless signal disruption and link errors suggest
   that limiting channel contention by configuring more conservative MTU
   levels is often prudent.  Even in such environments, a mixed link
   model with error-tolerant data sent in DTN parcels/AJs and error-
   intolerant data sent in classic packet/parcel/AJ constructs may
   present a more balanced profile.

   IPv6 parcels and AJs therefore provide a revolutionary advancement
   for delay/disruption tolerance in air/land/sea/space mobile
   Internetworking applications.  As the Internet continues to evolve
   from its more stable fixed terrestrial network origins to one where
   more and more nodes operate in the mobile edge, this new link service
   model relocates bulk error detection and correction responsibilities
   from intermediate systems to end systems that are uniquely capable of
   taking corrective actions.

   Note: IPv6 parcels and AJs may already be compatible with widely-
   deployed link types such as 1/10/100-Gbps Ethernet.  Each Ethernet
   frame is identified by a preamble followed by a Start Frame Delimiter
   (SFD) followed by the frame data itself followed by the FCS and
   finally an Inter Packet Gap (IPG).  Since no length field is
   included, however, the frame can theoretically extend as long as
   necessary for transmission of IPv6 parcels and AJs that are much
   larger than the typical 1500 octet Ethernet MTU as long as the time
   duration on the link media is properly bounded.  Widely-deployed
   links may therefore already include all of the necessary features to
   natively support large parcels and AJs with no additional extensions,
   while operating systems may require extensions to post larger receive
   buffers.

Templin                 Expires 23 November 2024               [Page 13]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

6.  IPv6 Parcel Formation

   A transport protocol entity identified by its 5-tuple forms a parcel
   body by preparing a data buffer (or buffer chain) containing at most
   64 transport layer protocol segments, with each TCP segment preceded
   by a 4-octet Sequence Number header.  Each segment plus Sequence
   Number (for TCP) is further preceded by a 2-octet Internet Checksum
   header and followed by a 0/4/8-octet CRC trailer.  All non-final
   segments MUST be equal in length while the final segment MUST NOT be
   larger and MAY be smaller.  The number of non-final segments is
   represented as J; the total number of segments is therefore (J + 1).

   The non-final segment size L is set to a 16-bit value that MUST be no
   smaller than 256 octets and SHOULD be no larger than 65535 octets
   minus the length of the {TCP,UDP} header (plus options), minus the
   length of the IPv6 header (plus extensions), minus 2 octets for the
   Checksum header minus 4 octets for the Sequence Number (for TCP)
   minus 0/4/8 octets for the CRC trailer (see: Appendix B).  The final
   segment length K MUST NOT be larger than L but MAY be smaller.  The
   transport layer protocol entity then presents the buffer(s) and size
   L to the network layer, noting that the combined buffer length(s) may
   exceed 65535 octets when there are sufficient segments of a large
   enough size.

   If the next hop link is not parcel capable, the network layer
   performs packetization to package each segment as an individual IPv6
   packet as discussed in Section 7.1.  If the next hop link is parcel
   capable, the network layer instead completes the parcel by appending
   a single full {TCP,UDP} header (plus options) and a single full IPv6
   header (plus extensions).  The network layer finally includes a
   specially-formatted IPv6 Parcel Payload Hop-By-Hop Option as an
   extension to the IPv6 header of each parcel prior to transmission
   over a network interface as shown in Figure 1:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |  Opt Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |     Check     |   Parcel/AJ Format (16 bits)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Index   |C|S|X|       Parcel Payload Length (23 bits)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: IPv6 Parcel Payload Option

Templin                 Expires 23 November 2024               [Page 14]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The network layer includes the Parcel Payload Option as an IPv6 Hop-
   by-Hop option with Option Type set to '0x30' and Opt Data Len set to
   12.  The length also distinguishes this format from its use as the
   IPv6 Minimum Path MTU Hop-by-Hop Option [RFC9268].  The network layer
   then sets the IPv6 Payload Length field to the length of the leading
   portion of the parcel subject to hop-by-hop integrity checks and sets
   Parcel/AJ Format to L.  The network layer next sets Parcel Payload
   Length to a 23-bit value M that encodes the length of the IPv6
   extension headers plus the length of the {TCP,UDP} header plus the
   combined length of all concatenated segments with their Checksum and
   sequence number (for TCP) headers and CRC trailers.  Note that in
   this arrangement the IPv6 Payload Length determines the leading
   length of the parcel subject to link layer FCS protection while the
   Parcel Payload Length determines the end of the parcel payload after
   which the link layer appends the trailing FCS itself.

   The network layer next sets Index to an ordinal parcel segment
   "Index" value between 0 and 63, sets the "(C)RC" flag to 1 if CRC
   trailers are used (otherwise 0) and sets the "More (S)egments" flag
   to 1 for non-final sub-parcels or 0 for the final (sub-)parcel.
   (Note that non-zero Index values identify the initial segment index
   in non-first sub-parcels of a larger original parcel while the value
   0 denotes the first (sub-)parcel.)  The network layer next sets the
   "e(X)treme" flag to 0 unless otherwise specified (see: Section 9).
   The network layer then includes a 4-octet Identification, sets Code
   to 255 and sets Check to the same value that will appear in the IPv6
   header Hop Limit field on transmission (see: Section 7.5).  These
   values provide hop-by-hop assurance that previous hops correctly
   implement the parcel protocol without applying legacy IPv6 option
   processing per [RFC9268].

   Following this transport and network layer processing, {TCP,UDP}/IPv6
   parcels therefore have the structures shown in Figure 2:

Templin                 Expires 23 November 2024               [Page 15]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

         TCP/IPv6 Parcel Structure          UDP/IPv6 Parcel Structure
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~   IPv6 Hdr plus extensions   ~   ~   IPv6 Hdr plus extensions   ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~   TCP header (plus options)  ~   ~         UDP header           ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+
     |    Checksum 0 followed by    |   |    Checksum 0 followed by    |
     ~  Sequence Number 0 followed  ~   ~     Segment 0 (L octets)     ~
     ~    by Segment 0 (L octets)   ~   ~         followed by          ~
     |      followed by CRC 0       |   |            CRC 0             |
     +------------------------------+   +------------------------------+
     |    Checksum 1 followed by    |   |    Checksum 1 followed by    |
     ~  Sequence Number 1 followed  ~   ~     Segment 1 (L octets)     ~
     ~    by Segment 1 (L octets)   ~   ~         followed by          ~
     |      followed by CRC 1       |   |            CRC 1             |
     +------------------------------+   +------------------------------+
     ~             ...              ~   ~             ...              ~
     ~         More Segments        ~   ~         More Segments        ~
     ~             ...              ~   ~             ...              ~
     +------------------------------+   +------------------------------+
     |    Checksum J followed by    |   |    Checksum J followed by    |
     ~  Sequence Number J followed  ~   ~     Segment J (K octets)     ~
     ~    by Segment J (K octets)   ~   ~         followed by          ~
     |      followed by CRC J       |   |            CRC J             |
     +------------------------------+   +------------------------------+

                Figure 2: {TCP,UDP}/IPv6 Parcel Structure

6.1.  TCP Parcels

   A TCP Parcel is an IPv6 parcel that includes an IPv6 header plus
   extensions with a Parcel Payload Option formed as shown in Section 6
   with Parcel Payload Length encoding a value no larger than (2**23 -
   1) octets.  The IPv6 header plus extensions is then followed by a TCP
   header plus options (20 or more octets) followed by (J + 1)
   consecutive segments that each include a 2-octet Internet Checksum
   plus 4-octet per-segment Sequence Number header and 0/4/8-octet CRC.
   The TCP header Sequence Number is set to 0, each non-final segment is
   L octets in length and the final segment is K octets in length.  The
   value L is encoded in the Parcel/AJ Format field while the overall
   length of the parcel is determined by the Parcel Payload Length M.

Templin                 Expires 23 November 2024               [Page 16]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The source prepares TCP Parcels in an alternative adaptation of TCP
   jumbograms [RFC2675].  The source calculates a checksum of the TCP
   header plus IPv6 pseudo-header only (see: Section 10).  The source
   then writes the exact calculated value in the TCP header Checksum
   field (i.e., without converting calculated 0 values to '0xffff').

   The source next calculates the Internet checksum for each segment
   independently beginning with the Sequence Number header and extending
   over the length of the segment, then writes the value into the
   2-octet Checksum header.  When C=1, the source then calculates the
   CRC beginning with the Checksum header and extending over both the
   Sequence Number header and the length of the segment, then writes the
   value into the 4/8-octet CRC trailer.

   Note: The parcel TCP header Source Port, Destination Port and (per-
   segment) Sequence Number fields apply to each parcel segment, while
   the TCP control bits and all other fields apply only to the first
   segment (i.e., "segment(0)").  Therefore, only parcel segment(0) may
   be associated with control bit settings while all other segment(i)'s
   must be simple data segments.

   See Appendix A for additional TCP considerations.  See Section 10 for
   additional integrity considerations.

6.2.  UDP Parcels

   A UDP Parcel is an IPv6 Parcel that includes an IPv6 header plus
   extensions with a Parcel Payload Option formed as shown in Section 6
   with Parcel Payload Length encoding a value no larger than (2**23 -
   1) octets.  The IPv6 header plus extensions is then followed by an
   8-octet UDP header followed by (J + 1) transport layer segments with
   their 2-octet Checksum headers and 0/4/8-octet CRC trailers.  Each
   segment must begin with a transport-specific start delimiter (e.g., a
   segment identifier, a sequence number, etc.) included by the
   transport layer user of UDP.  The length of the first segment L is
   encoded in the Parcel/AJ Format field while the overall length of the
   parcel is determined by the Parcel Payload Length M as above.

   The source prepares UDP Parcels in an alternative adaptation of UDP
   jumbograms [RFC2675] by setting the UDP header Length field to the
   length of the UDP header plus all parcel segments with their headers/
   trailers.  (If this length exceeds 65535 octets, the source instead
   sets UDP Length to 0.)  The source then calculates the checksum of
   the UDP header plus IPv6 pseudo-header (see: Section 10) and writes
   the exact calculated value into the UDP header Checksum field (i.e.,
   without converting calculated 0 values to '0xffff').  If UDP
   checksums are enabled, the source also calculates a separate checksum
   for each segment while writing the values into the corresponding per-

Templin                 Expires 23 November 2024               [Page 17]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   segment Checksum header with calculated 0 values converted to
   '0xffff' (if UDP checksums are disabled, the source instead writes
   the value 0).  When C=1, the source then calculates the CRC over each
   segment beginning with the segment Checksum field and writes the
   value into the segment's 4/8-octet CRC trailer.

   Note: Truly large UDP parcels that set the UDP Length field to 0 are
   ineligible for carrying UDP options per [I-D.ietf-tsvwg-udp-options].

   See: Section 10 for additional integrity considerations.

6.3.  Calculating J and K

   The parcel source unambiguously encodes the values L and M in the
   corresponding header fields as specified above.  The values J and K
   are not encoded in header fields and must therefore be calculated by
   intermediate and final destination nodes as follows:

          /* L is non-final segment length;
             M is parcel payload length;
             H is length of {TCP,UDP} header plus IPv6 extensions;
             P is parcel payload length minus headers;
             C is combined length of per-segment header/trailer;
             (integer arithmetic assumed.)*/

          if ((L < 256) || ((P = (M - H)) <= 0))
              drop parcel;

          if ((J = (P / (L + C))) > 64)
              drop parcel;

          if ((K = (P % (L + C))) == 0) {
              J--; K = L;
          } else {
              if ((J > 63) || ((K -= C) <= 0))
                  drop parcel;
          }

                       Figure 3: Calculating J and K

   Note: from the above calculations, a well-formed parcel is one that
   sets L to at least 256, includes J segments of length L and includes
   one segment of length K (with each segment including its per-segment
   header(s) and trailer).  In addition, all parcels set L to at most
   65535 and contain no more than 64 segments.

Templin                 Expires 23 November 2024               [Page 18]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

7.  Transmission of IPv6 Parcels

   When the network layer of the source assembles a {TCP,UDP}/IPv6
   parcel it fully populates all IPv6 header fields including the source
   address, destination address and Parcel Payload Option as above.  The
   source sets Hop Limit to the Parcel Limit value discovered through
   probing (see: Section 7.5), sets X to 0 for normal or 1 for
   "e(X)treme path" OMNI link traversal and also sets Parcel/AJ Format
   to L (between 256 and 65535) to distinguish the parcel from other
   jumbogram types (see: Section 8).

   The source also maintains a randomly-initialized 4-octet (32-bit)
   Identification value for each destination.  For each packet, parcel
   or AJ transmission, the source sets the Identification to the current
   cached value for this destination and increments the cached value by
   1 (modulo 2**32) for each successive transmission.  (The source can
   then reset the cached value to a new random number when necessary,
   e.g., to maintain an unpredictable profile.)  For each parcel
   transmission, the source includes the Identification value in the
   Parcel Payload Option.

   The source finally presents the parcel to an interface for
   transmission to the next hop.  For ordinary interface attachments to
   parcel-capable links, the source simply admits each parcel into the
   interface the same as for any IPv6 packet where it may be forwarded
   by one or more routers over additional consecutive parcel-capable
   links possibly even traversing the entire forward path to the final
   destination.  Note that any node in the path that does not recognize
   the parcel construct may either drop it and return an ICMP Parameter
   Problem message or attempt to forward it as a (truncated) packet,
   where the IPv6 Payload Length determines a likely truncation length.

   Most importantly, each parcel-capable link in the path forwards
   parcels/AJs with integrity-checked headers even if the remainder of
   the payload accumulated link errors since each segment is responsible
   for its own end-to-end integrity.  This ensures that the vast
   majority of coherent data is delivered to the final destination
   instead of being discarded along with a minor amount of corrupted
   data at an intermediate hop.  When the link far end receives a
   parcel/AJ it verifies only the leading portion of the parcel/AJ
   header before forwarding to the next hop while leaving integrity
   assurance for the remainder as an end-to-end service (see:
   Section 10).

   When the next hop link does not support parcels at all, or when the
   next hop link is parcel-capable but configures an MTU that is too
   small to pass the entire parcel, the source breaks the parcel up into
   individual IPv6 packets (in the first case) or into smaller sub-

Templin                 Expires 23 November 2024               [Page 19]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   parcels (in the second case).  In the first case, the source can
   apply packetization using Generic Segment Offload (GSO), and the
   final destination can apply restoration using Generic Receive Offload
   (GRO) to deliver the largest possible parcel buffer(s) to the
   transport layer.  In the second case, the source can apply
   parcellation to break the parcel into sub-parcels with each
   containing the same Identification value and with the S flag set
   appropriately.  The final destination can then apply reunification to
   deliver the largest possible parcel buffer(s) to the transport layer.
   In all other ways, the source processes of breaking a parcel up into
   individual IPv6 packets or smaller sub-parcels entail the same
   considerations as for a router on the path that invokes these
   processes as discussed in the following subsections.

   Parcel probes that test the forward path's ability to pass parcels/
   AJs include "Parcel/AJ Path MTU" and "Residual Path MTU" fields as
   discussed in Section 7.5.  Each router in the path may rewrite the
   fields to progressively smaller values in a similar fashion as for
   [RFC9268].  The fact that the probe transited a previous hop link
   provides sufficient evidence of forward progress since path MTU
   determination is unidirectional in the forward path only.  Following
   successful parcel probing, each parcel/AJ transmission may include
   {TCP,UDP} segment size probes used for packetization layer path MTU
   discovery per [RFC4821][RFC8899].  Such probes may be necessary to
   refine the Residual Path MTU, for which parcel/AJ probes can only
   provide an estimate.

   When a router or destination receives a parcel (or parcel/AJ probe)
   it first compares Code with 255 and Check with the IPv6 header Hop
   Limit; if either value differs, the node drops the parcel and returns
   a negative Jumbo Report (see: Section 7.6) subject to rate limiting.
   For all other intact parcels, each router next compares the value L
   with the next hop link MTU.  If the next hop link is parcel capable
   but configures an MTU too small to admit a parcel with a single
   segment of length L the router returns a positive Jumbo Report
   (subject to rate limiting) with MTU set to the next hop link MTU.  If
   the next hop link is not parcel capable and configures an MTU too
   small to pass an individual IPv6 packet with a single segment of
   length L the router instead returns a positive Parcel Report (subject
   to rate limiting) with MTU set to the next hop link MTU.  If the next
   hop link is parcel capable the router MUST forward the parcel to the
   next hop while decrementing both Check and the IPv6 header Hop Limit
   field by 1.

   If the router recognizes parcels but the next hop link in the path
   does not, or if the entire parcel would exceed the next hop link MTU,
   the router instead opens the parcel.  The router then forwards each
   enclosed segment in individual IPv6 packets or in a set of smaller

Templin                 Expires 23 November 2024               [Page 20]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   sub-parcels that each contain a subset of the original parcel's
   segments.  If the next hop link is via an OMNI interface, the router
   instead follows OMNI Adaptation Layer procedures.  These
   considerations are discussed in detail in the following sections.

7.1.  Packetization over Non-Parcel Links

   For transmission of individual packets over links that do not support
   parcels, the source or router (i.e., the node) invokes packetization
   in the spirt of Generic Segment Offload (GSO).  The node determines
   whether packetization is needed by examining the IPv6 Hop Limit.  In
   particular, the source initiates packetization if the Hop Limit is
   already 0 while the router initiates packetization if decrementing
   the Hop Limit would cause it to become 0.  Otherwise, the node
   forwards the intact parcel or performs parcellation (see: Section 7.5
   for discussion of Parcel Limit).

   To initiate packetization, the node first determines whether an
   individual packet with segment of length L can fit within the next
   hop link/path MTU.  If an individual packet would be too large the
   node drops the parcel and returns a positive Parcel Report message
   (subject to rate limiting) with MTU set to the next hop link/path MTU
   and with the leading portion of the parcel beginning with the IPv6
   header as the "packet in error".

   If an individual packet can be accommodated, the node next removes
   the Parcel Payload Option and caches the per-segment Checksum header
   values (and for TCP also caches the Sequence Numbers).  If C=1, the
   node then verifies the CRCs of each segment(i) (for i = 0 thru J) and
   discards any segment(i)'s with incorrect CRCs.  The node then copies
   the {TCP,UDP}/IPv6 headers followed by segment (i) (i.e., while
   discarding the per-segment headers and trailers) into (J + 1)
   individual packets ("packet(i)").  Each such packet(i) will be
   subject to the independent link-layer CRC verifications of each
   remaining link in the path.

   For each packet(i), the node then clears the TCP control bits in all
   but packet(0), and includes only those TCP options that are permitted
   to appear in data segments in all but packet(0) which may also
   include control segment options (see: Appendix A for further
   discussion).  The node then sets IPv6 Payload Length for each
   packet(i) based on the length of segment(i) according to [RFC8200].

   For each packet(i), the node then inserts a Parcel Parameters Option
   for TCP [RFC9293] or UDP [I-D.ietf-tsvwg-udp-options].  The {TCP,UDP}
   option is formatted as shown in Figure 4:

Templin                 Expires 23 November 2024               [Page 21]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

             Parcel Parameters Option for Multi-Segment Parcels
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind      |     Length    |             ExID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Index  |R|S|R|      Parcel Payload Length (23 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Parcel Parameters Option for Single-Segment Parcels/AJs
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind      |     Length    |             ExID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: {TCP,UDP} Parcel Parameters Option

   The node includes the Parcel Parameters Option in the {TCP,UDP}
   header of each packet(i).  The node sets Kind to 253 for TCP
   [RFC6994][RFC9293] or 127 for UDP [I-D.ietf-tsvwg-udp-options], then
   sets ExID to TBD1 (see: IANA Considerations).  For multi-segment
   parcels, the node next sets Length to 12 and includes a 4-octet
   Parcel Payload Length (plus preamble) field.  The node next sets
   Index to 'i', sets S to 1 for non-final packet(i)'s or to 0 for the
   final packet(i).  The node finally includes the Parcel Payload Length
   and Identification values found in the original parcel header.  (For
   single-segment parcels and AJs that include an identification, the
   node instead sets Length to 8, omits the Parcel Payload Length and
   Index fields then includes the parcel/AJ Identification value.  For
   AJs that do not include an identification, the node instead omits the
   Parcel Parameters Option.)

   For each IPv6 packet, the node then sets Hop Limit to a conservative
   value that allows for sufficient conventional IPv6 forwarding hops
   along the residual path from the node performing packetization to the
   final destination while still providing an adequate termination count
   to protect against routing loops.

   For each TCP/IPv6 packet, the node next sets Payload Length according
   to [RFC8200] then calculates/sets the checksum for the packet
   according to [RFC9293].  For each UDP/IPv6 packet, the node instead
   sets the Payload Length and UDP length fields then calculates/sets
   the checksum according to [RFC0768].  The node reuses the cached
   checksum value for each segment in the checksum calculation process.
   The node first calculates the Internet checksum over the new packet
   {TCP,UDP}/IPv6 headers then adds the cached segment checksum value.
   For TCP, the node finally writes the cached Sequence Number value for

Templin                 Expires 23 November 2024               [Page 22]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   each segment into the TCP Sequence Number field which initially
   encoded the value 0 (note that this operation ordering permits the
   node to reuse the cached segment checksum value without having to
   recalculate).  For UDP, if a per-segment Checksum was 0 the node
   instead writes the value 0 in the Checksum field of the corresponding
   UDP/IPv6 packet.  The node then forwards each IPv6 packet to the next
   hop.

   Note: Packets resulting from packetization may be too large to
   transit the remaining path to the final destination, such that a
   router may drop the packet(s) and possibly also return an ordinary
   ICMP PTB message.  Since these messages cannot be authenticated or
   may be lost on the return path, the original source should take care
   in setting a segment size as large as the Residual Path MTU unless as
   part of an active probing service.

7.2.  Parcellation over Parcel-capable Links

   For transmission of smaller sub-parcels over parcel-capable links,
   the source or intermediate system (i.e., the node) first determines
   whether a single segment of length L can fit within the next hop link
   MTU if packaged as a (singleton) sub-parcel.  If a singleton sub-
   parcel would be too large, the node returns a positive Jumbo Report
   message (subject to rate limiting) with MTU set to the next hop link
   MTU and containing the leading portion of the parcel beginning with
   the IPv6 header then drops the parcel.  Otherwise, the node employs
   network layer parcellation to break the original parcel into smaller
   groups of segments that can traverse the path as whole (sub-)parcels.
   The node first determines the number of segments of length L that can
   fit into each sub-parcel under the size constraints.  For example, if
   the node determines that each sub-parcel can contain 3 segments of
   length L, it creates sub-parcels with the first containing Segments
   0-2, the second containing 3-5, the third containing 6-8, etc., and
   with the final containing any remaining Segments (where each segment
   includes its Checksum header and when C=1 also the CRC trailer from
   the original (sub-)parcel).

Templin                 Expires 23 November 2024               [Page 23]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   If the original parcel's Parcel Payload Option has S set to 0, the
   node then sets S to 1 in all resulting sub-parcels except the last
   (i.e., the one containing the final segment of length K, which may be
   shorter than L) for which it sets S to 0.  If the original parcel has
   S set to 1, the node instead sets S to 1 in all resulting sub-parcels
   including the last.  The node next sets the Index field to the value
   'i' which is the ordinal number of the first segment included in each
   sub-parcel.  (In the above example, the first sub-parcel sets Index
   to 0, the second sets Index to 3, the third sets Index to 6, etc.).
   If another router further down the path toward the final destination
   forwards the sub-parcel(s) over a link that configures a smaller MTU,
   the router may break it into even smaller sub-parcels each with Index
   set to the ordinal number of the first segment included.

   The node next appends identical {TCP,UDP}/IPv6 headers (including the
   Parcel Payload Option plus any other extensions) to each sub-parcel
   while resetting Index, S, and Parcel Payload Length in each as above.
   The node also sets the Hop Limit in each sub-parcel to the same value
   that occurred in the original (sub-)parcel.

   For TCP, the node then clears the TCP control bits in all but the
   first sub-parcel and includes only those TCP options that are
   permitted to appear in data segments in all but the first sub-parcel
   (which may also include control segment options).  For both TCP and
   UDP, the node then resets the {TCP,UDP} Checksum according to
   ordinary parcel formation procedures (see above).  The node finally
   sets PMTU to the next hop link MTU then forwards each (sub-)parcel to
   the parcel-capable next hop.

7.3.  OMNI Interface Parcellation and Reunification

   For transmission of original parcels or sub-parcels over OMNI
   interfaces, the node admits all parcels into the interface
   unconditionally since the OMNI interface can accommodate all parcel
   sizes.  The OMNI Adaptation Layer (OAL) of this First Hop Segment
   (FHS) OAL source node then forwards the parcel to the next OAL hop
   which may be either an intermediate node or a Last Hop Segment (LHS)
   OAL destination.  OMNI interface parcellation and reunification
   procedures are specified in detail in the remainder of this section,
   while parcel encapsulation and fragmentation procedures are specified
   in [I-D.templin-6man-omni3].

   When the OAL source forwards a parcel (whether generated by a local
   application or forwarded over a network path that transited one or
   more parcel-capable links), it first assigns a monotonically-
   incrementing (modulo 64) adaptation layer Parcel ID (note that this
   value differs from the (Parcel) Index encoded in the Parcel Payload
   Option).  If the parcel is larger than the OAL maximum segment size

Templin                 Expires 23 November 2024               [Page 24]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   of 65535 octets, the OAL source next employs parcellation to break
   the parcel into sub-parcels the same as for the above network layer
   procedures.  This includes re-setting the Index, S and Parcel Payload
   Length fields in each sub-parcel the same as specified in
   Section 7.2.

   The OAL source next assigns a different monotonically-incrementing
   adaptation layer Identification value for each sub-parcel of the same
   Parcel ID then performs adaptation layer encapsulation while writing
   the Parcel ID into the OAL IPv6 Extended Fragment Header.  The OAL
   source then performs OAL fragmentation if necessary and finally
   forwards each fragment to the next OAL hop toward the OAL
   destination.  (During encapsulation, the OAL source examines the
   Parcel Payload Option S flag to determine the setting for the
   adaptation layer fragment header S flag according to the same rules
   specified in Section 7.2.)

   When the sub-parcels arrive at the OAL destination, it retains them
   along with their Parcel IDs and Identifications for a short time to
   support reunification with peer sub-parcels of the same original
   (sub-)parcel identified by the 4-tuple information corresponding to
   the OAL source.  This reunification entails the concatenation of
   Checksums/Segments included in sub-parcels with the same Parcel ID
   and with Identification values within (modulo 64) of one another to
   create a larger sub-parcel possibly even as large as the entire
   original parcel.  The OAL destination concatenates the segments plus
   their checksums (and when C=1 also CRCs) for each sub-parcel in
   ascending Identification value order, while ensuring that any sub-
   parcel with TCP control bits set appears as the first concatenated
   element in a reunified larger parcel and any sub-parcel with S flag
   set to 0 appears as the final concatenation.  The OAL destination
   then sets S to 0 in the reunified (sub-)parcel if and only if one of
   its constituent elements also had S set to 0; otherwise, it sets S to
   1.

Templin                 Expires 23 November 2024               [Page 25]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The OAL destination then appends a common {TCP,UDP}/IPv6 header plus
   extensions to each reunified sub-parcel while resetting Index, S and
   Parcel Payload Length in the corresponding header fields of each.
   For TCP, if any sub-parcel has TCP control bits set the OAL
   destination regards it as sub-parcel(0) and uses its TCP header as
   the header of the reunified (sub-)parcel with the TCP options
   including the union of the TCP options of all reunified sub-parcels.
   The OAL destination then resets the {TCP,UDP}/IPv6 header checksum.
   If the OAL destination is also the final destination, it then
   delivers the sub-parcels to the network layer which processes them
   according to the 5-tuple information supplied by the original source.
   If the OAL destination is not the final destination, it instead
   forwards each sub-parcel toward the final destination the same as for
   an ordinary IPv6 packet.

   Note: Adaptation layer parcellation over OMNI links occurs only at
   the OAL source while adaptation layer reunification occurs only at
   the OAL destination; intermediate OAL nodes do not engage in the
   parcellation/reunification processes.  The OAL destination should
   retain sub-parcels in the reunification buffer only for a short time
   (e.g., 1 second) or until all sub-parcels of the original parcel have
   arrived.  The OAL destination then delivers full and/or incomplete
   reunifications to the network layer (in cases where loss and/or
   delayed arrival interfere with full reunification).

   Note: OMNI interface parcellation and reunification is an OAL process
   based on the adaptation layer 4-tuple and not the network layer
   5-tuple.  This is true even if the OAL has visibility into network
   layer information since some sub-parcels of the same original parcel
   may be forwarded over different network paths.

   Note: Some implementations may encounter difficulty in applying
   adaptation layer reunification for sub-parcels that have already
   incurred lower layer fragmentation and reassembly (e.g., due to
   network kernel buffer structure limitations).  In that case, the
   adaptation layer can either linearize each sub-parcel before applying
   reunification or deliver incomplete reunifications or even individual
   sub-parcels to upper layers.

   Note: If the original source selects the "e(X)treme path" for OMNI
   link traversal, the OMNI interface forwards the entire parcel as a
   (giant) singleton carrier packet using jumbo-in-jumbo encapsulation
   instead of applying adaptation layer parcellation as discussed in
   Section 9.

Templin                 Expires 23 November 2024               [Page 26]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

7.4.  Final Destination Restoration/Reunification

   When the original source or a router on the path opens a parcel and
   forwards its contents as individual IPv6 packets, these packets will
   arrive at the final destination which can hold them in a restoration
   buffer for a short time before restoring the original parcel using
   Generic Receive Offload.  The 5-tuple information plus the Parcel
   Parameters Option values included by the source during packetization
   (see: Figure 4) provide sufficient context for GRO restoration which
   practical implementations have proven as a robust service at high
   data rates.

   When the original source or a router on the path opens a parcel and
   forwards its contents as smaller sub-parcels, these sub-parcels will
   arrive at the final destination which can hold them in a
   reunification buffer for a short time or until all sub-parcels have
   arrived.  The 5-tuple information plus the Index, S and
   Identification values provide sufficient context for reunification.

   In both the restoration and reunification cases, the final
   destination concatenates segments according to ascending Index and/or
   Identification numbers to preserve segment ordering even if a small
   degree of reordering and/or loss may have occurred in the networked
   path.  When the final destination performs restoration/reunification
   on TCP segments, it must include the one with any TCP flag bits set
   as the first concatenation and with the TCP options including the
   union of the TCP options of all concatenated packets or sub-parcels.
   For both TCP and UDP, any packet or sub-parcel containing the final
   segment must appear as a final concatenation.

   The final destination can then present the concatenated parcel
   contents to the transport layer with segments arranged in (nearly)
   the same order in which they were originally transmitted.  Unless a
   security encapsulation is included, strict ordering is not mandatory
   since each segment will include a transport layer protocol specific
   start delimiter with positional coordinates.  However, the Index
   field and/or Identification includes an ordinal value that preserves
   ordering since each sub-parcel or individual IPv6 packet contains an
   integral number of whole transport layer protocol segments.

   Note: Restoration and/or reunification buffer management is based on
   a hold timer during which singleton packets or sub-parcels are
   retained until all members of the same original parcel have arrived.
   Implementations should maintain a short hold timer (e.g., 1 second)
   and advance any restorations/reunifications to upper layers when the
   hold timer expires even if incomplete.

Templin                 Expires 23 November 2024               [Page 27]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   Note: Since loss and/or reordering may occur in the network, the
   final destination may receive a packet or sub-parcel with S set to 0
   before all other elements of the same original parcel have arrived.
   This condition does not represent an error, but in some cases may
   cause the network layer to deliver sub-parcels that are smaller than
   the original parcel to the transport layer.  The transport layer
   simply accepts any segments received from all such deliveries and
   will request retransmission of any segments that were lost and/or
   damaged.

   Note: Restoration and/or reunification buffer congestion may indicate
   that the network layer cannot sustain the service(s) at current
   arrival rates.  The network layer should then begin to deliver
   incomplete restorations/reunifications or even individual segments to
   upper layers (e.g., via a socket buffer) instead of waiting for all
   segments to arrive.  The network layer can manage restoration/
   reunification buffers, e.g., by maintaining buffer occupancy high/low
   watermarks.

   Note: Some implementations may encounter difficulty in applying
   network layer restoration/reunification for packets/sub-parcels that
   have already incurred adaptation layer reassembly/reunification.  In
   that case, the network layer can either linearize each packet/sub-
   parcel before applying restoration/reunification or deliver
   incomplete restorations/reunifications or even individual packets/
   sub-parcels to upper layers.

7.5.  Parcel/AJ Path Probing

   Unless there is operational assurance that all routers and
   destinations in the network will recognize Parcel/AJ constructs, the
   original source should send an initial probe to determine whether
   parcels/AJs can transit at least an initial portion of the forward
   path toward the final destination.  The original source prepares an
   ordinary IPv6 packet with an alternate encoding of the IPv6 Minimum
   Path MTU Option that contains Parcel Probe parameters as shown in
   Figure 5:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Type  | Opt Data Len  |     Code      |     Check     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Parcel/AJ Path MTU (32 bits)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Residual Path MTU (16 bits)  |  Parcel Limit |  Reserved |O|X|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Templin                 Expires 23 November 2024               [Page 28]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

                       Figure 5: Parcel Probe Option

   The IPv6 packet can be either a purpose-built probe or part of an
   existing transport protocol session, but it should cause the
   destination to return a responsive {TCP,UDP}/IPv6 packet with
   authenticating credentials and with a Parcel Probe Reply Option - see
   below.  (Note that the probe must appear in an ordinary IPv6 packet
   and not a parcel/AJ to ensure that it will traverse the entire path
   to the destination.)

   The source sets the IPv6 probe Hop Limit to a sufficiently large
   value to allow the probe to traverse the path.  The source then sets
   Payload Length the same as for an ordinary IPv6 packet.  The source
   next sets "Option Type" to '0x30' the same as for the Parcel Payload
   Option, sets "Option Data Len" to 14, sets Code to 255 and sets Check
   to the same value as Hop Limit.

   Next, the source sets Parcel/AJ Path MTU to the 32-bit MTU of the
   outgoing (parcel-capable) interface for the probe, sets Residual Path
   MTU to the 16-bit value 'ffff', and sets Identification to a 32-bit
   identification value for the next packet/parcel/AJ to be sent to this
   destination.  The source then sets the Parcel Limit, Reserved and O
   fields all to 0, and sets the X flag to 1 if it is probing the
   "e(X)treme path" for OMNI links (see below).  The source finally adds
   any padding options necessary for 8-octet alignment and sends the
   packet to the next hop.

   Each node in the path that observes this specification (including
   IPv6 routers and the final destination itself) examines the packet
   and processes the Parcel Probe Option as follows:

   *  If Code is 255 and Check contains the same value as the IPv6
      header Hop Limit, then set Parcel/AJ Path MTU to the minimum of
      its current value, the previous hop link MTU, and the node's own
      receive buffer size (but no smaller than the IPv6 minimum MTU
      [RFC8200]).  Next increment Parcel Limit by 1 and, if the previous
      hop link was an OMNI link, set the O flag to 1.  Then (for
      routers) forward the probe to the next hop while decrementing Hop
      Limit by 1 and setting Check to the new Hop Limit value.

   *  If Code is not 255 or Check contains a different value than the
      IPv6 header Hop Limit, then set Residual Path MTU to the minimum
      of its current value, the previous hop link MTU, and the node's
      own receive buffer size (but no smaller than the IPv6 minimum MTU
      [RFC8200]).  Then, (for routers) forward the probe to the next hop
      while decrementing Hop Limit by 1 and setting Check to 255.

Templin                 Expires 23 November 2024               [Page 29]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   When the destination receives the probe, it performs the above
   operations and also sets Residual Path MTU to 0 if Code is 255 and
   Check contains the same value as the IPv6 header Hop Limit.  The
   destination then returns a responsive {TCP,UDP}/IPv6 packet that
   includes a Parcel Probe Reply Option as a {TCP,UDP} header option
   formatted as shown in Figure 6.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind      |     Length    |             ExID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Parcel/AJ Path MTU (32 bits)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Residual Path MTU (16 bits)  |  Parcel Limit |  Reserved |O|X|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6: {TCP,UDP} Parcel Probe Reply Option

   The destination sets Kind to 253 for TCP [RFC6994][RFC9293] or 127
   for UDP [I-D.ietf-tsvwg-udp-options], then sets Length to 16 and ExID
   to TBD1 (see: IANA Considerations).  The destination then sets
   Parcel/AJ Path MTU, Residual Path MTU, Parcel Limit, Reserved, O, X
   and Identification to the values included in the probe, i.e., after
   its own local probe processing as discussed above.  The destination
   then includes any additional identifying parameters (such as
   authentication codes) in the {TCP,UDP}/IPv6 packet and returns the
   packet to the source while discarding the probe.

   The original source can therefore send parcel/AJ probes in the same
   packets used to carry real data.  The probes will transit all routers
   on the forward path possibly extending all the way to the
   destination.  If the source receives a probe reply, it authenticates
   the message and matches the Identification value with one of its
   previous probes.  If a match is confirmed, then the Parcel Probe
   Reply Option will contain all information necessary for the source to
   use in its future parcel/AJ transmissions to this destination.

   In particular, the Parcel/AJ Path MTU determines the largest-size
   parcel/AJ that can transit the leading portion of the path up to a
   point that packetization would be necessary.  If the O flag is set
   and X is clear, then the maximum-sized AJ is limited to 65535 octets
   while parcels as large as the Parcel/AJ Path MTU can be accommodated;
   if both the O and X flags are set, then the maximum-sized AJ is also
   bounded by the Parcel/AJ Path MTU which may exceed 65535 octets.

Templin                 Expires 23 November 2024               [Page 30]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   If Residual Path MTU is non-zero, its value determines the maximum-
   sized packet that can transit the remainder of the path following
   packetization noting that the maximum packet size may be smaller
   still if there are routers in the probed path that do not recognize
   the protocol.  (Note that a Residual Path MTU value of 0 instead
   indicates that the path is parcel-capable in all hops from the source
   to the destination.)  Finally, Parcel Limit contains the value the
   source must place in the IPv6 Hop Limit field of future parcels/AJ
   transmissions to this destination.

   All routers and destinations within a controlled environment /
   limited domain are expected to forward or accept packets with IPv6
   Hop-by-Hop Options extension headers without dropping them, i.e.,
   even if they ignore the option contents.  Conversely, for open
   Internetworks outside of a controlled environment / limited domain
   some paths may be unable to transit IPv6 packets that contain Hop-by-
   Hop Options extension headers.

   Sources that connect to open Internetworks should therefore send
   "augmented" probes that include a UDP header inserted between the
   IPv6 header and the Hop-by-Hop Options extension header.  The source
   next rewrites the Hop-by-Hop Options Next Header field per
   Section 6.4 of [I-D.templin-6man-omni3] with the "Type" component set
   to OMNI-HBH and with the "Next" component set to the value for the
   next header that follows (e.g., OMNI-TCP, OMNI-UDP, etc.).  Next, the
   source sets the IPv6 Next Header field to UDP ("17"), sets the UDP
   port numbers to OMNI ("8060"), calculates and sets the UDP Checksum,
   then sends the prepared probe to the destination.

   This implies that all routers that recognize parcels/AJs and all
   destinations that accept them must be capable of accepting and
   processing the contents of these OMNI protocol UDP messages as though
   they arrived as ordinary probes.  Such routers and destinations must
   therefore implement enough of the OMNI interface to be able to
   recognize and process the messages.

   When there may be one or more OMNI links in the path, the source can
   optionally send probes that test and measure the OMNI link "e(X)treme
   path" which uses jumbo-in-jumbo encapsulation instead of IP
   fragmentation (see: Section 9).  In one approach, the source can
   first send probes with the X flag set to 0.  If the probe reply
   returns with the O flag set to 1, and if jumbo-in-jumbo encapsulation
   is needed (e.g., to forward very large AJs and parcels at extreme
   data rates), the source can next send probes with the X flag set to
   1.  The source can then remember the MTU and Parcel Limit values for
   both types of probes, and can subsequently send smaller parcels/AJs
   using the first set of parameters while sending larger parcels/AJs
   using the second set of parameters.

Templin                 Expires 23 November 2024               [Page 31]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   All parcels/AJs also serve as implicit probes and may cause a router
   in the path to return an ordinary ICMPv6 error [RFC4443] and/or
   Packet Too Big (PTB) message [RFC8201] concerning the parcel if the
   path changes.  If the path changes, a router in the path may also
   return a Parcel/Jumbo Report (subject to rate limiting per [RFC4443])
   as discussed in Section 7.6.

7.6.  Parcel/Jumbo Reports

   When the destination returns a Parcel/Jumbo Report, it packages the
   report as a {TCP,UDP} option in a {TCP,UDP}/IPv6 packet to return to
   the source the same as for a Parcel Probe Reply (see: Figure 6).  For
   a positive report, the destination may set Parcel/AJ Path MTU and
   Residual Path MTU to smaller values that reflect its (reduced)
   receive buffer size.  For a negative report, the destination instead
   sets Parcel Path MTU, Residual MTU and Parcel Limit to 0 as an
   indication to the source that the path must be re-probed before
   sending additional parcels/AJs.

   When a router returns a Parcel/Jumbo Report, it prepares an ICMPv6
   PTB message [RFC4443] with Code set to either Parcel Report or Jumbo
   Report (see: IANA considerations) and with MTU set to either the
   minimum MTU value for a positive report or to 0 for a negative
   report.  The router then writes its own IPv6 address as the Parcel/
   Jumbo Report source and writes the source address of the packet that
   invoked the report as the Parcel/Jumbo Report destination.

   The router next copies as much of the leading portion of the invoking
   parcel/AJ as possible (beginning with the IPv6 header) into the
   "packet in error" field without causing the entire Parcel/Jumbo
   Report (beginning with the IPv6 header) to exceed the IPv6 Minimum
   MTU.  The router then calculates and sets the Checksum field the same
   as for an ordinary ICMPv6 message then sends the prepared Parcel/
   Jumbo Report to the original source of the probe.

   This implies that original sources that send parcels/AJs must be
   capable of accepting and processing Parcel/Jumbo reports (formatted
   as above) with coming from either a router or the final destination.

   Note: For positive Parcel/Jumbo reports, the source can continue
   sending parcels/AJs into the path with its segment sizes reduced
   accordingly.  For negative Parcel/Jumbo reports, the source should
   instead re-probe the path before sending additional parcels/AJs.

Templin                 Expires 23 November 2024               [Page 32]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

8.  Advanced Jumbos (AJ)

   This specification introduces an IPv6 Advanced Jumbo (AJ) service as
   a (single-segment) parcel alternative to basic jumbograms.  The
   service employs the Parcel Payload Option the same as for IP Parcels;
   it sets Opt Data Len to 12 the same as for Parcels but replaces the
   3-octet Parcel Payload Length field plus 1-octet preamble by a
   4-octet Jumbo Payload Length field as shown in Figure 7:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |  Opt Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Code     |     Check     |   Parcel/AJ Format (16 bits)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Jumbo Payload Length (32 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Identification (32 bits)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7: Parcel Payload Option for Advanced Jumbos

   The source forms {TCP/UDP}/IPv6 AJs by setting the most significant
   octet of the Parcel/AJ Format field to 0 and treating the least
   significant octet of the field as an "Advanced Jumbo (AJ) Format"
   octet as shown in Figure 8:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       0       |X| FEC |  Type |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      <-- AJ Format -->

               Figure 8: Parcel/AJ Format for Advanced Jumbos

   In the AJ Format octet, the source sets "X" to 0 for classic OMNI
   link traversal or 1 for "e(X)treme path" traversal.  The source then
   sets "Type" to one of the CRC/digest types found in Figure 9 and sets
   "FEC" to 0 (future specifications may define new values, e.g., for
   Forward Error Correction (FEC) parameters, etc.).  Implementations
   MUST support the following integrity checking algorithms identified
   by "Type":

Templin                 Expires 23 November 2024               [Page 33]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

      Type    Algorithm      CRC/digest Length
      ----    ---------      -----------------
      0       NULL           0 octets
      1       CRC32C         4 octets
      2       CRC64E         8 octets
      3       MD5            16 octets
      4       SHA1           20 octets
      5       SHA-224        28 octets
      6       SHA-256        32 octets
      7       SHA-384        48 octets
      8       SHA-512        64 octets

          Figure 9: Mandatory Advanced Jumbo CRC/Digest Algorithms

   The source then sets the IPv6 Payload Length to the length of the
   leading portion of the AJ to be covered by hop-by-hop FCS integrity
   checks noting that the remainder of the AJ will be covered only by
   end-to-end integrity checks with FEC applied if necessary.  The
   source next forms the {TCP/UDP}/IPv6 AJ the same as for parcels as
   shown in Figure 2 except that it includes only a single segment
   ("Segment 0").  For all Types other than 0, the source then includes
   a 2-octet Checksum header and an N-octet CRC/digest trailer for the
   segment according to Figure 9.  Unlike parcels, TCP AJs do not
   include a separate Sequence Number header for the (single) segment
   since the sequence number is coded in the TCP header the same as for
   an ordinary packet.  UDP AJs set the UDP Length field the same as
   specified for UDP parcels.

   AJs that include a message digest employ the algorithms specified for
   MD5 [RFC1321], SHA1 [RFC3174] and the advanced US Secure Hash
   Algorithms [RFC6234] according the to AJ Type.  AJs can instead
   employ a CRC32C/CRC64E integrity check by selecting a Type value with
   a CRC code instead of a message digest.  (A Type value is also
   reserved by IANA as a non-functional placeholder for a nominal
   CRC128J algorithm, which may be specified in future documents - see:
   Appendix C.)

   When the source prepares an AJ, it sets the Identification the same
   as for a parcel, sets Code to 255 and sets Check and Hop Limit to the
   Parcel Limit for this destination (see: Section 7.5).  The source
   then calculates the {TCP,UDP} Checksum based on the same pseudo
   header as for an ordinary parcel (see: Figure 11) but with the
   4-octet Parcel Payload Length (plus preamble) fields replaced with a
   4-octet Jumbo Payload Length field and with Parcel/AJ Format encoding
   the AJ Format Octet - see above.

Templin                 Expires 23 November 2024               [Page 34]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The source calculates the header checksum only and writes the value
   into the {TCP,UDP} header checksum field the same as specified for
   parcels.  For all AJ Types other than 0, the source then calculates
   the checksum of the segment payload, writes the value into the
   segment Checksum header, then calculates the CRC/digest over the
   length of the (single) segment beginning with the Checksum field and
   writes the value into the trailer.  The source then sends the AJ via
   the next hop link toward the final destination.

   At each forwarding hop, the router examines Code and Check then drops
   the AJ and returns a negative Jumbo Report if either value is
   incorrect.  (Note that the AJ may also have been truncated in length
   by a previous-hop router that does not recognize the construct.)  For
   all other intact AJs, if decrementing would cause the Hop Limit to
   become 0 the router performs packetization to convert the AJ into a
   packet the same as specified for parcels (see: Section 7.1) and
   forwards the packet to the next hop; otherwise, the router decrements
   both Hop Limit and Check by 1 and forwards the intact AJ to the next
   hop.

   Note: If the original source selects the "e(X)treme path" for OMNI
   link traversal, the OMNI interface forwards the intact AJ as a
   carrier packet using jumbo-in-jumbo encapsulation instead of applying
   adaptation layer IP fragmentation.  These jumbo carrier packets are
   then subject to best-effort delivery over the (previously-probed)
   path.  The original source may select "e(X)treme" for any parcel/AJ,
   but must select "e(X)treme" for all AJs larger than 65535 octets -
   see: Section 9.

9.  OMNI Interface Jumbo-in-Jumbo Encapsulation

   OMNI interfaces can process parcels of all sizes as well as AJs as
   large as 65535 octets according to normal OMNI link parcellation,
   encapsulation and fragmentation procedures.  For larger AJs as well
   as for parcels that may experience better performance by avoiding
   parcellation and fragmentation, the original source can instead
   select OMNI link "e(X)treme path" traversal.  For probes/parcels/AJs
   that select the "e(X)treme path", the source sends the probe/parcel/
   AJ via the first-hop link under standard procedures specified in
   previous sections with standard IP forwarding providing service for
   each successive link up to the OMNI link ingress.  When the
   probe/parcel/AJ arrives at the OMNI link ingress, the X flag provides
   an indication that "e(X)treme path" OMNI link traversal is desired as
   follows.

   For parcel/AJ probes, the OMNI link ingress first verifies that all
   previous hops were jumbo-capable by examining the Code and Check
   values.  If Code or Check are incorrect, the OMNI link ingress clears

Templin                 Expires 23 November 2024               [Page 35]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   the X flag and forwards the probe using normal OMNI encapsulation.
   If Code and Check are both correct, the OMNI link ingress instead
   inserts the OMNI and L2 encapsulations as specified in
   [I-D.templin-6man-omni3] then performs "jumbo-in-jumbo" encapsulation
   by copying the (L3) Parcel Probe Option Hop-by-Hop extension header
   from the original IPv6 probe packet into the L2 headers as shown in
   Figure 10.  The OMNI link ingress then calculates the UDP checksum
   over the entire length of the encapsulated probe (as the UDP payload)
   and writes the value into the L2 UDP checksum field.  Each L2
   forwarding hop in the path to the next OAL intermediate node will
   then process the probe exactly as specified in Section 7.5, where
   each parcel/AJ capable hop adjusts the Code, Check, Parcel/AJ Path
   MTU and Parcel Limit fields then re-calculates/re-sets the L2 UDP
   checksum.

      Jumbo-in-Jumbo Parcel/AJ Probe        Jumbo-in-Jumbo Parcel/AJ
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~         L2 IPv6 Hdr          ~   ~         L2 IPv6 Hdr          ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~        L2 UDP header         ~   ~        L2 UDP header         ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~     L2 Parcel/AJ Probe       ~   ~   L2 Advanced Jumbo Type 0   ~
     |         HBH option           |   |         HBH option           |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~       OMNI IPv6 Header       ~   ~       OMNI IPv6 Header       ~
     |       plus extensions        |   |        plus extensions       |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~         L3 IPv6 Hdr          ~   ~          L3 IPv6 Hdr         ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~      L3 Parcel/AJ Probe      ~   ~        L3 Parcel/AJ          ~
     |         HBH option           |   |         HBH option           |
     +------------------------------+   +------------------------------+
     |                              |   |                              |
     ~     {TCP,UDP} header and     ~   ~     {TCP,UDP} header and     ~
     ~          packet body         ~   ~        parcel/AJ body        ~
     |                              |   |                              |
     +------------------------------+   +------------------------------+

                 Figure 10: Jumbo-in-Jumbo Encapsulation

Templin                 Expires 23 November 2024               [Page 36]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   When each successive OAL intermediate node receives the parcel probe,
   it propagates the Parcel Probe Option Hop-by-Hop extension header
   into the L2 headers for the next OAL hop while updating the probe
   parameters the same as for an ordinary IP forwarding hop.  When the
   OAL destination receives the parcel/AJ probe, it first verifies that
   all previous hops were jumbo-capable by examining the Code and Check
   values.  If Code or Check are incorrect, the OAL destination drops
   the probe and returns a negative Jumbo Report to the OAL source,
   which then returns a negative Jumbo Report to the original source.
   Otherwise, the OAL destination removes the L2 and OAL headers while
   copying the L2 probe parameters into the L3 Parcel Probe Option (with
   the L2 encapsulation header lengths subtracted from the Parcel/AJ
   Path MTU).

   The OAL destination then forwards the probe to the next hop toward
   the final destination.  If the probe traverses the entire path to the
   final destination, the Parcel/AJ Path MTU will contain the minimum
   MTU and the Parcel Limit will contain the total number of parcel/AJ-
   capable L2/L3 hops between the source and destination.  (Note that
   the Residual Path MTU may also indicate that the final portion of the
   path is not parcel/AJ capable even though the leading portion of the
   path was.)  The destination will then return a probe reply to the
   source, and if the X flag is set the source can begin sending
   parcels/AJs with the X flag set to enable the OMNI link "e(X)treme
   path".

   If the source receives an intact probe reply with X flag set, it can
   use the enclosed Parcel/AJ Path MTU, Residual Path MTU and Parcel
   Limit values to prepare future parcels/AJs for transmission via the
   "e(X)treme path" by setting the X flag.  Each L3 forwarding hop in
   the path from the original source to the OMNI link ingress then
   forwards the parcel/AJ the same as for the standard procedures
   specified in previous sections.

   When the OMNI link ingress receives a parcel/AJ with the X flag set,
   it performs "jumbo-in-jumbo encapsulation" by leaving the L3 parcel/
   AJ headers intact, then appending OMNI adaptation layer IPv6
   encapsulations plus L2 encapsulations that include a Parcel Payload
   Option with Advanced Jumbo Type 0 (but without including a segment
   checksum field as for {TCP,UDP} AJs) in either a full or minimal AJ
   extension header as an L2 extension.  The OMNI link ingress sets the
   Jumbo Payload Length field to the length of the L2 extension headers
   (including the L2 UDP header, if present) plus the lengths of the
   OMNI IPv6 encapsulation header and the L3 packet (including all L3
   headers).  The OMNI link ingress sets all other OMNI and L2
   encapsulation header fields as specified in [I-D.templin-6man-omni3].
   The parcel/AJ "jumbo-in-jumbo" encapsulation format is shown in
   Figure 10.

Templin                 Expires 23 November 2024               [Page 37]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   The OMNI link ingress then calculates the L2 UDP checksum over the L2
   UDP/IP pseudo-header and extending to cover the OMNI adaptation
   layers up to but not including the L3 IP header, then writes the
   value into the L2 UDP header checksum field.  The OMNI link ingress
   then copies the L3 TTL/Hop Limit into the L2 IP header TTL/Hop Limit
   and forwards the encapsulated parcel/AJ to the next L2 hop.  When the
   parcel/AJ arrives at an OAL intermediate node, the node discards the
   L2 headers from the previous hop OMNI segment and inserts L2 headers
   for the next hop OMNI segment while updating the OMNI encapsulation
   header fields accordingly (see: [I-D.templin-6man-omni3]).  In the
   process, the OAL intermediate node decrements the previous L2 hop
   TTL/Hop Limit and writes this value into the next L2 hop IP header
   while also transferring the previous hop Advanced Jumbo Type 1 header
   to the next hop L2 header chain.  The node also re-calculates and re-
   sets the L2 UDP header checksum before forwarding toward the next
   OMNI hop.

   When the parcel/AJ arrives at the OAL destination, the OAL
   destination copies the L2 IP TTL/Hop Limit into the L3 IP TTL/Hop
   Limit field, then removes the L2 and OMNI encapsulation headers and
   forwards the packet to the next L3 hop while decrementing the IP TTL/
   Hop Limit by 1 according to standard IP forwarding rules.  The final
   destination will then receive the intact original parcel/jumbo.

   While a probe/parcel/AJ is traversing an OMNI link "e(X)treme path",
   it may encounter an L2 link that does not recognize the construct.
   This may cause a subsequent link to detect a formatting error and
   return a negative Jumbo Report that will be returned to a previous
   hop OAL intermediate node or the OAL source.  The OAL node that
   receives the (L2) Jumbo Report must then prepare and generate an (L3)
   Jumbo Report to return to the original source.  The L3 Jumbo Report
   contains the leading portion of the L3 probe/parcel/AJ with the L2
   and OMNI headers removed.  This will provide indication to the
   original source that the OMNI link "e(X)treme path" has failed for
   this particular transmission.

   Note: If an OMNI link ingress receives an "e(X)treme path" probe with
   an incorrect Code or Check, it clears the X flag and forwards the
   probe as an ordinary IP packet using standard OMNI encapsulation and
   fragmentation since a previous L3 hop was determined to be jumbo-
   incapable yet may be able to perform packetization.  This is true
   even if there may be multiple OMNI links in the L3 path, where the X
   flag applies to all OMNI links in the series and not just the first.

   Note: The L2 UDP checksum extends over the entire length of each
   jumbo-in-jumbo encapsulated parcel/AJ probe, but only over the L2 and
   OMNI headers for each jumbo-in-jumbo encapsulated parcel/AJ following
   probing.  This is due to the fact that the source must disguise the

Templin                 Expires 23 November 2024               [Page 38]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   probe as an ordinary IP packet while probing is in progress; after
   probing has converged, subsequent parcels/AJs only require an
   integrity check of the headers.

10.  Integrity

   IPv6 parcel/AJ integrity assurance responsibility is shared between
   lower layers of the protocol stack and the transport layer where more
   discrete compensations for lost or corrupted data recovery can be
   applied.  In the classic link model, parcels and AJs are delivered to
   the final destination only if they pass the integrity checks of all
   links in the path over their entire length.  In the DTN link model,
   intermediate system lower layers forward parcels/AJs with correct
   headers to the final destination transport layer even if the upper
   layer protocol data accumulates link errors at intermediate hops.
   The destination is then ultimately responsible for its own end-to-end
   integrity assurance.

   The {TCP,UDP}/IPv6 header plus each segment of a parcel/AJ includes
   its own integrity checks.  The per-segment Checksums/CRCs are set by
   the source and verified by the destination.  Note that both checks
   are important (when no other integrity checks are present) since
   there will be many instances when errors missed by the CRC are
   detected by the Checksum [STONE].

   IPv6 parcels can range in length from as small as only the
   {TCP,UDP}/IPv6 headers plus a single segment to as large as the
   headers plus (64 * 65535) octets, while AJs include only a single
   segment that can be as small as a null segment to as large as 2**32
   octets (minus headers).  Due to parcellation/packetization in the
   path, the segment contents of a received parcel may arrive in an
   incomplete and/or rearranged order with respect to their original
   packaging.

   IPv6 parcels and AJs include a separate 2-octet Internet Checksum
   header for each segment noting that the per-segment Checksum value 0
   indicates that the segment checksum is disabled.  The original source
   calculates the checksum for each segment beginning with the first
   octet of the per-segment Sequence Number (for TCP) then continuing
   with the first segment octet and extending over the entire segment
   length up to but not including the integrity check trailer (if
   present).

   IPv6 parcels with C=1 use one of two different CRC types according to
   the non-final segment length "L".  For values of L smaller than 9216
   octets (9KB), the original source uses the CRC32C specification
   [RFC3385] and encodes the CRC in a 4 octet trailer.  For larger L
   values, the source uses the CRC64E specification [ECMA-182] and

Templin                 Expires 23 November 2024               [Page 39]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   encodes the CRC in an 8 octet trailer.  AJs that set an Advanced
   Jumbo Type other than NULL instead include either a 4/8 octet CRC or
   an N-octet message digest trailer calculated per [RFC1321], [RFC3174]
   or [RFC6234] according to the hash algorithm assigned to Type.

   Under the DTN link model, the link far end discards the parcel/AJ if
   it detects an FCS error in the leading portion to avoid the
   possibility of misdelivery.  Otherwise, the link far end
   unconditionally forwards the parcel/AJ to the next hop even if the
   upper layer protocol data incurred link errors.  End-to-end integrity
   checks in conjunction with any FEC repairs will then ensure that good
   data is delivered to upper layers.

   To support the parcel/AJ header checksum calculation, the network
   layer uses a modified version of the {TCP,UDP}/IPv6 pseudo-header
   found in Section 8.1 of [RFC8200] as shown in Figure 11.  This allows
   for maximum reuse of widely deployed code while ensuring
   interoperability.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~               IPv6 Source Address (16 octets)                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~             IPv6 Destination Address (16 octets)              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Parcel/Jumbo Payload Length (4 Octets)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Parcel/AJ Format        |      zero     |  Next Header  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 11: {TCP,UDP}/IPv6 Parcel/AJ Pseudo-Header Formats

   where the following fields appear:

   *  Source Address is the 16-octet IPv6 source address of the prepared
      parcel/AJ.

   *  Destination Address is the 16-octet IPv6 destination address of
      the prepared parcel/AJ.

   *  For parcels, the 4-octets of the Parcel/Jumbo Payload Length
      encode the Index/C/S/X preamble and 23-bit Parcel Payload Length
      as they appear in the Parcel Payload Option fields of the same
      name.  For AJs, the Parcel/Jumbo Payload Length encodes the
      4-octet Jumbo Payload Length value found in the Parcel Payload
      Option.

   *  Parcel/Jumbo Format is the value that appears in the Parcel
      Payload Option header.

Templin                 Expires 23 November 2024               [Page 40]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   *  zero encodes the constant value 0.

   *  Next Header is the IP protocol number corresponding to the
      transport layer protocol, i.e., TCP or UDP.

   When the transport layer protocol entity of the source delivers a
   parcel body to the network layer, it presents the values L and J
   along with the (J + 1) segments in canonical order as a list of data
   buffers and with each TCP segment preceded by a 4-octet Sequence
   Number field.  (For AJs, the transport layer instead delivers the
   singleton AJ segment along with the Jumbo Payload Length.)  When the
   network layer of the source accepts the parcel/AJ body from the
   transport layer protocol entity, it calculates the Internet checksum
   for each segment and writes the value in the per-segment Checksum
   header (or writes the value 0 when UDP checksums are disabled).

   For parcels/AJs that include trailing integrity checks, the network
   layer then calculates the CRC/digest for each segment beginning with
   the Checksum field and inserts the result as a segment trailer in
   network byte order.  The network layer then concatenates all segments
   and appends the necessary {TCP,UDP}/IPv6 headers and extensions to
   form a parcel.  The network layer next calculates the {TCP,UDP}/IPv6
   header checksum over the length of only the {TCP,UDP} headers plus
   IPv6 pseudo header then forwards the parcel to the next hop without
   further processing.

   When the network layer of the destination accepts an AJ or reunifies
   a parcel from one or more sub-parcels received from the source it
   first verifies the {TCP,UDP}/IPv6 header checksum then for each
   segment verifies the CRC/digest (if present) followed by the Checksum
   (except when UDP checksums are disabled) and marks any segments with
   incorrect integrity check values as errors.

   When the network layer restores a parcel from one or more individual
   {TCP,UDP}/IPv6 packets received from the source, it instead marks the
   CRCs of each segment as correct since the individual packets were
   subject to CRC checks at each hop along the path.  The network layer
   then verifies the Internet checksum of each individual packet (except
   when UDP checksums are disabled), restores the parcel, and delivers
   each parcel/AJ segment along with a CRC/Checksum error flag to the
   transport layer.

   When the transport layer of the destination processes parcel or AJ
   segments, it can accept any with correct CRCs/Checksums while
   optionally applying additional higher-layer integrity checks.  The
   transport layer can instead process any segments with incorrect CRC/
   Checksum by either discarding the entire segment or applying higher-
   layer integrity checks on the component elements of the segment to

Templin                 Expires 23 November 2024               [Page 41]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   accept as many non-errored elements as possible.  The transport layer
   can then either reconstruct from local information or request
   retransmission for any segment elements that may have been damaged in
   transit as necessary.

   Note: Classical links often use CRC32 as their hop-by-hop integrity
   checking service and this specification assumes that future DTN-
   capable links will also use CRC32.  Since the error detection
   resolution for CRC32 diminishes for frame sizes larger than ~9KB,
   implementations should select hop-by-hop integrity protection for
   only the leading portions of parcels/AJs while leaving the remaining
   payload for end-to-end integrity checks.

   Note: the source and destination network layers can often engage
   hardware functions to greatly improve CRC/Checksum calculation
   performance.

11.  Implementation Status

   Common widely-deployed implementations include services such as TCP
   Segmentation Offload (TSO) and Generic Segmentation/Receive Offload
   (GSO/GRO).  These services support a robust service that has been
   shown to improve performance in many instances.

   An early prototype of UDP/IPv4 parcels (draft version -15) has been
   implemented relative to the linux-5.10.67 kernel and ION-DTN ion-
   open-source-4.1.0 source distributions.  Patch distribution found at:
   "https://github.com/fltemplin/ip-parcels.git".

   Performance analysis with a single-threaded receiver has shown that
   including increasing numbers of segments in a single parcel produces
   measurable performance gains over fewer numbers of segments due to
   more efficient packaging and reduced system calls/interrupts.  For
   example, sending parcels with 30 2000-octet segments shows a 48%
   performance increase in comparison with ordinary packets with a
   single 2000-octet segment.

   Since performance is strongly bounded by single-segment receiver
   processing time (with larger segments producing dramatic performance
   increases), it is expected that parcels with increasing numbers of
   segments will provide a performance multiplier on multi-threaded
   receivers in parallel processing environments.

Templin                 Expires 23 November 2024               [Page 42]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

12.  IANA Considerations

   The IANA is instructed to add a reference to this document
   ([RFCXXXX]) in the "Minimum Path MTU Hop-by-Hop Option" entry in the
   "Destination Options and Hop-by-Hop Options" table of the
   'ipv6-parameters' registry.

   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 entries should appear as follows:

      Code            Name                         Reference
      ---             ----                         ---------
      3 (suggested)   Parcel Report                [RFCXXXX]
      4 (suggested)   Jumbo Report                 [RFCXXXX]

       Figure 12: ICMPv6 Code Fields: Type 2 - Packet Too Big Values

   The IANA is requested to assign two new entries in the
   'ipv6-parameters' registry "Destination Options and Hop-by-Hop
   Options" table (registration procedures IESG Approval, IETF Review or
   Standards Action).  The first entry sets "Hex Value" to '0xE2',
   "acct" to '11', "chg" to '1', "rest" to '00010' and Description to
   "Minimal Parcel/AJ With Errors".  The second entry sets "Hex Value"
   to '0x10', "acct" to '00', "chg" to '0', "rest" to '10000' and
   Description to "Parcel/AJ With Errors".  Both entries set "Reference"
   to this document [RFCXXXX].

   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 TBD1,
   "Description" to "Parcel Parameters" and "Reference" to this document
   [draft-templin-6man-parcels].  The IANA is also instructed to assign
   the same value TBD1 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 TBD1 value assignment.

   Finally, the IANA is instructed to create and maintain a new registry
   titled "IPv6 Parcel and Advanced Jumbo Formats and Types" as follows:

   For IPv6 parcels and Advanced Jumbos, the value in the 'Opt Data Len'
   field of the IPv6 Minimum Path MTU Option [RFC9268] serves as an
   "Option Format" code that distinguishes the various option formats
   specified in this document.  Initial values are given below:

Templin                 Expires 23 November 2024               [Page 43]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

      Value       Option Format                   Reference
      -----       -------------                   ---------
      0-3         Unassigned                      [RFCXXXX]
      4           IPv6 Minimum Path MTU           [RFC9268]
      5-11        Unassigned                      [RFCXXXX]
      12          Parcel Payload                  [RFCXXXX]
      13          Unassigned                      [RFCXXXX]
      14          Parcel Probe                    [RFCXXXX]
      15-253      Unassigned                      [RFCXXXX]
      254         Reserved for Experimentation    [RFCXXXX]
      255         Reserved by IANA                [RFCXXXX]

                   Figure 13: IPv6 Parcel Option Formats

   For IPv6 Advanced Jumbos, when the most significant octet of the
   Parcel Payload Option Parcel/AJ Format field encodes the value 0, the
   least significant 4 bits of the field encode an "Advanced Jumbo Type"
   value.  The IANA is therefore instructed to establish an "IPv6
   Advanced Jumbo Types" registry with the initial values given below:

      Value        Jumbo Type                     Reference
      -----        ----------                     ---------
      0            Advanced Jumbo / NULL          [RFCXXXX]
      1            Advanced Jumbo / CRC32C        [RFCXXXX]
      2            Advanced Jumbo / CRC64E        [RFCXXXX]
      3            Advanced Jumbo / MD5           [RFCXXXX]
      4            Advanced Jumbo / SHA1          [RFCXXXX]
      5            Advanced Jumbo / SHA-224       [RFCXXXX]
      6            Advanced Jumbo / SHA-256       [RFCXXXX]
      7            Advanced Jumbo / SHA-384       [RFCXXXX]
      8            Advanced Jumbo / SHA-512       [RFCXXXX]
      9            Advanced Jumbo / CRC128J       [RFCXXXX]
      10-15        Unassigned                     [RFCXXXX]

                    Figure 14: IPv6 Advanced Jumbo Types

13.  Security Considerations

   In the control plane, original sources match the Identification (and/
   or other identifying information) received in Parcel/Jumbo Reports
   with their earlier parcel/AJ transmissions.  If the identifying
   information matches, the report is likely authentic.  When stronger
   authentication is needed, nodes that send Parcel/Jumbo Reports can
   apply the message authentication services specified for AERO/OMNI.
   For nodes that include {TCP,UDP} Parcel Parameter Options in ordinary
   data packets, however, the authenticating services that apply to the
   data packets also authenticate the options.

Templin                 Expires 23 November 2024               [Page 44]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   In the data plane, multi-layer security solutions may be needed to
   ensure confidentiality, integrity and availability.  According to
   [RFC8200], a full IPv6 implementation includes the Authentication
   Header (AH) [RFC4302] and Encapsulating Security Payload (ESP)
   [RFC4303] per the IPsec architecture [RFC4301] to support
   authentication, data integrity and (optional) data confidentiality.
   These AH/ESP services provide comprehensive integrity checking for
   parcel/AJ upper layer protocol headers and all upper layer protocol
   payload that follows.  Since the network layer does not manipulate
   transport layer segments, parcels/AJs do not interfere with transport
   or higher-layer security services such as (D)TLS/SSL [RFC8446] which
   may provide greater flexibility in some environments.

   IPv4 fragment reassembly is considered dangerous at high data rates
   where undetected reassembly buffer corruptions can result from
   fragment misassociations [RFC4963].  IPv6 is less subject to these
   concerns when the 32-bit Identification field is managed responsibly.
   IPv6 Parcels and AJs are not subject to fragmentation unless exposed
   to OMNI interface encapsulation which includes a 64-bit
   Identification space.

   For IPv6 parcels and AJs that engage the DTN link model, the
   destination end system is uniquely positioned to verify and/or
   correct the integrity of any transport layer segments received.  For
   this reason, transport layer protocols that use parcels/AJs should
   include higher layer integrity checks and/or forward error correction
   codes in addition to the per-segment link error integrity checks.

   The CRC/digest trailers included with parcels/AJs that engage the DTN
   link model provide integrity checks only and must not be considered
   as authentication codes in the absence of additional security
   services.  Further security considerations related to IPv6 parcels
   and Advanced Jumbos are found in the AERO/OMNI specifications.

14.  Acknowledgements

   This work was inspired by ongoing AERO/OMNI/DTN investigations.  The
   concepts were further motivated through discussions with colleagues.

   A considerable body of work over recent years has produced useful
   segmentation offload facilities available in widely-deployed
   implementations.

Templin                 Expires 23 November 2024               [Page 45]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   With the advent of networked storage, big data, streaming media and
   other high data rate uses the early days of Internetworking have
   evolved to accommodate the need for improved performance.  The need
   fostered a concerted effort in the industry to pursue performance
   optimizations at all layers that continues in the modern era.  All
   who supported and continue to support advances in Internetworking
   performance are acknowledged.

   This work has been presented at working group sessions of the
   Internet Engineering Task Force (IETF).  The following individuals
   are acknowledged for their contributions: Roland Bless, Scott
   Burleigh, Madhuri Madhava Badgandi, Joel Halpern, Tom Herbert, Andy
   Malis, Herbie Robinson, Bhargava Raman Sai Prakash.

   Honoring life, liberty and the pursuit of happiness.

15.  References

15.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-32,
              21 March 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tsvwg-udp-options-32>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

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

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [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>.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, DOI 10.17487/RFC2675, August 1999,
              <https://www.rfc-editor.org/info/rfc2675>.

Templin                 Expires 23 November 2024               [Page 46]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [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>.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 7323, DOI 10.17487/RFC7323, September 2014,
              <https://www.rfc-editor.org/info/rfc7323>.

   [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>.

   [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>.

15.2.  Informative References

   [BIG-TCP]  Dumazet, E., "BIG TCP, Netdev 0x15 Conference (virtual),
              https://netdevconf.info/0x15/session.html?BIG-TCP", 31
              August 2021.

Templin                 Expires 23 November 2024               [Page 47]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   [ECMA-182] ECMA, E., "European Computer Manufacturers Association
              (ECMA) Standard ECMA-182, https://ecma-international.org/
              wp-content/uploads/ECMA-
              182_1st_edition_december_1992.pdf", December 1992.

   [ETHERMTU] Murray, D., Koziniec, T., Lee, K., and M. Dixon, "Large
              MTUs and Internet Performance, 2012 IEEE 13th
              International Conference on High Performance Switching and
              Routing, https://ieeexplore.ieee.org/document/6260832", 24
              June 2012.

   [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.ietf-6man-hbh-processing]
              Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
              Processing Procedures", Work in Progress, Internet-Draft,
              draft-ietf-6man-hbh-processing-17, 16 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-17>.

   [I-D.templin-6man-aero3]
              Templin, F., "Automatic Extended Route Optimization
              (AERO)", Work in Progress, Internet-Draft, draft-templin-
              6man-aero3-03, 16 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-templin-6man-
              aero3-03>.

   [I-D.templin-6man-omni3]
              Templin, F., "Transmission of IP Packets over Overlay
              Multilink Network (OMNI) Interfaces", Work in Progress,
              Internet-Draft, draft-templin-6man-omni3-03, 15 April
              2024, <https://datatracker.ietf.org/doc/html/draft-
              templin-6man-omni3-03>.

   [I-D.templin-dtn-ltpfrag]
              Templin, F., "LTP Fragmentation", Work in Progress,
              Internet-Draft, draft-templin-dtn-ltpfrag-16, 23 October
              2023, <https://datatracker.ietf.org/doc/html/draft-
              templin-dtn-ltpfrag-16>.

   [I-D.templin-intarea-parcels2]
              Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
              Work in Progress, Internet-Draft, draft-templin-intarea-

Templin                 Expires 23 November 2024               [Page 48]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

              parcels2-03, 12 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-templin-
              intarea-parcels2-03>.

   [QUIC]     Ghedini, A., "Accelerating UDP packet transmission for
              QUIC, https://blog.cloudflare.com/accelerating-udp-packet-
              transmission-for-quic/", 8 January 2020.

   [RFC1071]  Braden, R., Borman, D., and C. Partridge, "Computing the
              Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
              September 1988, <https://www.rfc-editor.org/info/rfc1071>.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <https://www.rfc-editor.org/info/rfc1321>.

   [RFC3174]  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
              <https://www.rfc-editor.org/info/rfc3174>.

   [RFC3385]  Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
              "Internet Protocol Small Computer System Interface (iSCSI)
              Cyclic Redundancy Check (CRC)/Checksum Considerations",
              RFC 3385, DOI 10.17487/RFC3385, September 2002,
              <https://www.rfc-editor.org/info/rfc3385>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [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>.

   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
              Transmission Protocol - Specification", RFC 5326,
              DOI 10.17487/RFC5326, September 2008,
              <https://www.rfc-editor.org/info/rfc5326>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

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

Templin                 Expires 23 November 2024               [Page 49]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   [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>.

   [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>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [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>.

   [RFC8899]  Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
              Völker, "Packetization Layer Path MTU Discovery for
              Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
              September 2020, <https://www.rfc-editor.org/info/rfc8899>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
              Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
              January 2022, <https://www.rfc-editor.org/info/rfc9171>.

   [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>.

   [STONE]    Stone, J. and C. Partridge, "When the CRC and TCP Checksum
              Disagree, ACM SIGCOMM Computer Communication Review,
              Volume 30, Issue 4, October 2000, pp. 309-319,
              https://doi.org/10.1145/347057.347561", October 2000.

Templin                 Expires 23 November 2024               [Page 50]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

Appendix A.  TCP Extensions for High Performance

   TCP Extensions for High Performance are specified in [RFC7323], which
   updates earlier work that began in the late 1980's and early 1990's.
   These efforts determined that the TCP 16-bit Window was too small to
   sustain transmissions at high data rates, and a TCP Window Scale
   option allowing window sizes up to 2^30 was specified.  The work also
   defined a Timestamp option used for round-trip time measurements and
   as a Protection Against Wrapped Sequences (PAWS) at high data rates.
   TCP users of IPv6 parcels/AJs are strongly encouraged to adopt these
   mechanisms.

   Since TCP/IPv6 parcels only include control bits for the first
   segment ("segment(0)"), nodes must regard all other segments of the
   same parcel as data segments.  When a node breaks a TCP/IPv6 parcel
   out into individual packets or sub-parcels, only the first packet or
   sub-parcel contains the original segment(0) and therefore only its
   TCP header retains the control bit settings from the original parcel
   TCP header.  If the original TCP header included TCP options such as
   Maximum Segment Size (MSS), Window Scale (WS) and/or Timestamp, the
   node copies those same options into the options section of the new
   TCP header.

   For all other packets/sub-parcels, the note sets all TCP header
   control bits to 0 as data segment(s).  Then, if the original parcel
   contained a Timestamp option, the node copies the Timestamp option
   into the options section of the new TCP header.  Appendix A of
   [RFC7323] provides implementation guidelines for the Timestamp option
   layout.

   Appendix A of [RFC7323] also discusses Interactions with the TCP
   Urgent Pointer as follows: "if the Urgent Pointer points beyond the
   end of the TCP data in the current segment, then the user will remain
   in urgent mode until the next TCP segment arrives.  That segment will
   update the Urgent Pointer to a new offset, and the user will never
   have left urgent mode".  In the case of IPv6 parcels, however, it
   will often be the case that the next TCP segment is included in the
   same (sub-)parcel as the segment that contained the urgent pointer
   such that the urgent pointer can be updated immediately.

   Finally, if a parcel/AJ contains more than 65535 octets of data
   (i.e., even if spread across multiple segments), then the Urgent
   Pointer can be regarded in the same manner as for jumbograms as
   described in Section 5.2 of [RFC2675].

Templin                 Expires 23 November 2024               [Page 51]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

Appendix B.  Extreme L Value Implications

   For each parcel, the transport layer can specify any L value between
   256 and 65535 octets.  Transport protocols that send isolated control
   and/or data segments smaller than 256 octets should package them as
   ordinary packets, AJs, singleton parcels or as the final segment of a
   larger parcel.  It is also important to note that segments smaller
   than 256 octets are likely to include control information for which
   timely delivery rather than bulk packaging is desired.  Transport
   protocol streams therefore often include a mix of (larger) parcels
   and (smaller) ordinary packets, AJs or singleton parcels.

   The transport layer should also specify an L value no larger than can
   accommodate the maximum-sized transport and network layer headers
   that the source will include without causing a single segment plus
   headers to exceed 65535 octets.  For example, if the source will
   include a 28 octet TCP header plus a 40 octet IPv6 header with 24
   extension header octets (plus 6/10 octets for the per-segment
   Checksum/CRC) the transport should specify an L value no larger than
   (65535 - 28 - 40 - 24 - 10) = 65433 octets.

   The transport can specify still larger "extreme" L values up to 65535
   octets, but the resulting parcels might be lost along some paths with
   unpredictable results.  For example, a parcel with an extreme L value
   set as large as 65535 might be able to transit paths that can pass
   large parcels/AJs natively but might not be able to transit a path
   that includes conventional links.  The transport layer should
   therefore carefully consider the benefits of constructing parcels
   with extreme L values larger than the recommended maximum due to high
   risk of loss compared with only minor potential performance benefits.

   Finally, the transport layer must not set "extreme" L values that
   would cause the Parcel Payload Length to exceed (2**23 - 1) octets,
   since the resulting malformed parcel could not be properly processed.

Appendix C.  Advanced Jumbo Cyclic Redundancy Check (CRC128J)

   This section postulates a 128-bit Cyclic Redundancy Check (CRC)
   algorithm for AJs termed "CRC128J".  An Advanced Jumbo Type value is
   reserved for CRC128J, but at the time of this writing no algorithm
   exists.  Future specifications may update this document and provide
   an algorithm for handling Advanced Jumbos with Type CRC128J.

Appendix D.  Change Log

   << RFC Editor - remove prior to publication >>

   Changes from earlier versions:

Templin                 Expires 23 November 2024               [Page 52]
Internet-Draft            IPv6 Parcels and AJs                  May 2024

   *  Submit for review.

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 23 November 2024               [Page 53]