IPv6 Parcels and Advanced Jumbos (AJs)
draft-templin-6man-parcels2-21
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2025-01-02 | ||
| 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-21
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track 1 January 2025
Expires: 5 July 2025
IPv6 Parcels and Advanced Jumbos (AJs)
draft-templin-6man-parcels2-21
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 Networking (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 5 July 2025.
Templin Expires 5 July 2025 [Page 1]
Internet-Draft IPv6 Parcels and AJs January 2025
Copyright Notice
Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Background and Motivation . . . . . . . . . . . . . . . . . . 10
5. A Delay-Tolerant Networking (DTN) Link Model . . . . . . . . 11
6. IPv6 Parcel Formation . . . . . . . . . . . . . . . . . . . . 14
6.1. TCP Parcels . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. UDP Parcels . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Calculating K . . . . . . . . . . . . . . . . . . . . . . 19
7. Transmission of IPv6 Parcels . . . . . . . . . . . . . . . . 20
7.1. Packetization over Non-Parcel Links . . . . . . . . . . . 22
7.2. Parcellation over Parcel-capable Links . . . . . . . . . 24
7.3. OMNI Interface Parcellation and Reunification . . . . . . 25
7.4. Final Destination Restoration/Reunification . . . . . . . 27
7.5. Parcel Probing . . . . . . . . . . . . . . . . . . . . . 29
7.6. Parcel/Jumbo Reports . . . . . . . . . . . . . . . . . . 33
8. Advanced Jumbos (AJ) . . . . . . . . . . . . . . . . . . . . 33
9. OMNI Interface Jumbo-in-Jumbo Encapsulation . . . . . . . . . 36
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. GSO/GRO API . . . . . . . . . . . . . . . . . . . . 52
D.1. GSO (i.e., Parcel Packetization) . . . . . . . . . . . . 53
D.2. GRO (i.e., Parcel Restoration) . . . . . . . . . . . . . 53
Templin Expires 5 July 2025 [Page 2]
Internet-Draft IPv6 Parcels and AJs January 2025
Appendix E. Relation to Standard RFC2675 Jumbograms . . . . . . 54
Appendix F. Change Log . . . . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
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. IPv6 parcels represent a network
encapsulation for the multi-segment buffers managed by Generic
Segment Offload (GSO) and Generic Receive Offload (GRO); these
buffers are termed "parcel buffers" or simply "parcels" which become
"IP parcels" following encapsulation in {TCP,UDP}/IP.
Transport layer protocol entities form parcels by preparing a buffer
(or buffer chain) containing at most 64 consecutive transport layer
protocol segments that lower layers can break out into individual
packets or smaller sub-parcels as necessary. All non-final segments
must be equal in length while the final segment must not be larger.
The transport layer protocol entity then presents the parcel buffer,
number of segments and non-final segment size to the network layer.
The network layer next either performs packetization to forward each
segment as an individual IPv6 packet or appends a single {TCP,UDP}
header and a single IPv6 header plus extensions that identify this as
a parcel and not an ordinary packet. Any included {TCP,UDP} options
are associated with all segments, therefore parcels may only include
segments that employ compatible options.
Templin Expires 5 July 2025 [Page 3]
Internet-Draft IPv6 Parcels and AJs January 2025
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 adaptation layer IPv6 reassembly if necessary, an egress
OMNI interface applies 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
(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. Loss or receipt of individual segments (rather than
parcel size) therefore determines the retransmission unit.
This document further introduces an "Advanced Jumbo (AJ)" service
that provides essential improvements over the basic IPv6 jumbograms
defined in [RFC2675]. AJs are single-segment 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 an essential data transit service for improved
performance, efficiency and integrity while supporting larger Maximum
Transmission Units (MTUs). A new Delay Tolerant Networking (DTN)
link service model for parcels and AJs further supports delay/
disruption tolerance especially well 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 for Internetworking performance
maximization.
Templin Expires 5 July 2025 [Page 4]
Internet-Draft IPv6 Parcels and AJs January 2025
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 with {TCP,UDP}/IPv6 headers appended for transmission and
delivery as a "packet-of-packets". 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.
The term "Advanced Jumbo (AJ)" refers to a parcel variation modeled
from the basic IPv6 jumbogram construct defined in [RFC2675]. AJs
include a single transport layer protocol segment the same as for
basic IPv6 jumbograms. Unlike basic IPv6 jumbograms which are never
smaller than 64KB, however, 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
UDP header plus options (8 or more octets). Most significantly, only
a single IPv6 header and a single full {TCP,UDP} header plus options
appears in each parcel regardless of the number of segments included.
This distinction often provides a measurable overhead savings made
possible only by parcels.
Templin Expires 5 July 2025 [Page 5]
Internet-Draft IPv6 Parcels and AJs January 2025
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] with
the understanding that practical implementations require strict
attention to network byte ordering for multi-octet fields 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 (see: Section 10). AJs that employ end-to-end
integrity checks include either a CRC or message digest calculated
according to the MD5 [RFC1321], SHA1 [RFC3174] or US Secure Hash
[RFC6234] algorithms.
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 introduces 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.
(Note: parcels that do not include a Parcel Payload Hop-by-Hop (HBH)
Option are compatible with any IPv6 Internetworking path with
sufficient MTU even if some or all of the routers in the path do not
recognize the option.)
Templin Expires 5 July 2025 [Page 6]
Internet-Draft IPv6 Parcels and AJs January 2025
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 Path MTU" value returned
during parcel path qualification determines the maximum sized parcel/
AJ segment 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
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 standard practice,
parcel packetization and restoration are functional equivalents of
the well-known 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/
Templin Expires 5 July 2025 [Page 7]
Internet-Draft IPv6 Parcels and AJs January 2025
reunification and therefore provides a complementary service. Note
that parcels and AJs that include an extended payload length are
ineligible for fragmentation unless they are presented for OMNI
encapsulation and are no larger than 65535 octets.
"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.
When present, the "Parcel Integrity Block (PIB)" follows the
{TCP,UDP}/IPv6 headers of each parcel/AJ and includes integrity check
fields for each parcel segment.
The "Parcel Buffer (PB)" includes the concatenated upper layer
protocol segments of the parcel. The PB follows the PIB when
present; otherwise it follows the {TCP,UDP}/IPv6 headers.
The "Forward Error Correction (FEC)" services specified in this
document conform to the IETF FEC architecture found in
[RFC5052][RFC5445]. In this FEC architecture, a source node applies
FEC encoding to an original IP packet/parcel/AJ and the corresponding
destination(s) in turn apply FEC decoding to obtain the original data
minus any corrected errors.
Templin Expires 5 July 2025 [Page 8]
Internet-Draft IPv6 Parcels and AJs January 2025
The parcel sizing variables "J", "K", "L" and "M" are cited
extensively throughout this document. "J" denotes the number of
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
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.
All IPv6 nodes MUST observe their respective requirements found in
the normative references, including [RFC8200].
IPv6 parcels and AJs are similar to the basic jumbogram specification
found in [RFC2675], but observe the specifications in this document.
Most notably, IPv6 parcels and AJs include a new a Destination Option
and may also include a new Hop-by-Hop (HBH) Option when link-layer
support is needed.
All IPv6 parcels and AJs include exactly one Parcel Payload
Destination Option and at most one Parcel Payload HBH option; if more
than one is included, the first is processed and the others are
ignored. Only those parcels/AJs intended for paths that support the
new link service model and/or larger sizes include the HBH Option.
IPv6 parcels and AJs that include a Parcel Payload HBH option MAY
also include a Parcel Probe option but if so the Payload option
SHOULD appear before the Probe.
IPv6 parcels and AJs SHOULD NOT include more than one Parcel Probe
HBH or Destination option. If more are included, the first is
processed and all others ignored or regarded as an unrecognized
option.
IPv6 parcels/AJs are not limited only to segment sizes that exceed
65535 octets; instead, parcels can be as small as the packet and
parcel headers plus a NULL singleton segment. Parcels that are no
larger than 65535 octets and set the IPv6 Payload Length to a non-
zero value may be subject to source network layer fragmentation the
same as for ordinary IPv6 packets.
Templin Expires 5 July 2025 [Page 9]
Internet-Draft IPv6 Parcels and AJs January 2025
For further IPv6 HBH Option considerations, see: [RFC9673]. 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].
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.
A first study [QUIC] involved performance enhancement of the QUIC
protocol [RFC9000] using the linux 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 the QUIC transport. GSO/GRO performs
packetization and restoration with a 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.
Templin Expires 5 July 2025 [Page 10]
Internet-Draft IPv6 Parcels and AJs January 2025
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 negatively impact performance unless robust path
probing techniques are used, however optimal 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
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 or 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 smaller parcel configurations and forwarded further
until they are finally delivered to the consumer. But most often,
the consumer will find only 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 5 July 2025 [Page 11]
Internet-Draft IPv6 Parcels and AJs January 2025
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 transits
one or more 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 checks as a last resort. Especially with the
advent of space-domain and wireless Internetworking in inhospitable
environments where retransmissions may be onerous or even
impractical, advanced end-to-end error detection and correction
services not typically associated with packets are needed. This
specification therefore introduces a new Delay Tolerant Networking
(DTN) link model.
IPv6 parcels/AJs that engage this DTN link model request 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 plus Internet checksums to be verified by the final
destination. For each parcel/AJ admitted under the DTN link model,
the original source applies Forward Error Correction (FEC) encoding
[RFC5052][RFC5445] if necessary. Each delay/disruption challenged
link near-end in the path then applies its standard link-layer FCS
for only the leading portion upon transmission according to the
Integrity Limit specified by the source 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 final destination
then invokes FEC decoding [RFC5052][RFC5445] if necessary, verifies
integrity using per segment end-to-end CRCs/Digests plus Internet
checksums and delivers each segment to the local transport layer
which may employ higher-layer integrity checks.
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 5 July 2025 [Page 12]
Internet-Draft IPv6 Parcels and AJs January 2025
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 are exposed to extreme conditions, this new link
service model shifts bulk error detection and correction
responsibilities to end systems that are uniquely qualified to take
corrective actions. This is true even for paths where only one or a
few links engage the new reduced coverage link integrity service
model, while all other links can continue to employ the full frame
checking services as they have always done.
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 5 July 2025 [Page 13]
Internet-Draft IPv6 Parcels and AJs January 2025
6. IPv6 Parcel Formation
A transport protocol entity of the source identified by its 5-tuple
forms a Parcel Buffer (PB) by concatenating "J" transport layer
protocol segments (for J between 1 and 64) into a contiguous buffer
or chain of smaller buffers. All non-final segments MUST be of equal
length "L" while the final segment of length "K" MUST NOT be larger
and MAY be smaller. The overall parcel length (including all
segments and headers) is represented by the value "M".
The source sets L to a 16-bit non-final segment length of at least 1
but no larger than 65535 octets minus the lengths of the {TCP,UDP}
header (plus options) and IPv6 header (plus extensions) (see:
Appendix B). The transport layer protocol entity then presents the
resulting PB and non-final segment length L to the network layer,
noting that the combined PB length may exceed 65535 octets when there
are sufficient segments of a large enough size.
If the next hop link is not parcel capable and/or the path MTU is
insufficient, the network layer of the source performs packetization
to package each PB segment as an individual IPv6 packet as discussed
in Section 7.1. Otherwise, the source optionally prepends a Parcel
Integrity Block (PIB) before the PB that includes J N-octet CRCs
followed by J 2-octet Internet Checksums. When present, the PIB
appears as shown in Figure 1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CRC (0) through CRC (J-1) (N octets each) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Checksum (0) through Checksum (J-1) (2 octets each) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Parcel Integrity Block (PIB) Format
The source then prepends a single full {TCP,UDP} header and a single
full IPv6 header that includes a Parcel Payload Destination Option
formatted as shown in Figure 2:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Length (16 bits) | Nsegs | Index |F|P|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Parcel Payload Destination Option
Templin Expires 5 July 2025 [Page 14]
Internet-Draft IPv6 Parcels and AJs January 2025
In this encoding, the source includes the Parcel Payload Option as an
IPv6 Destination Option with Option Type "rest" set to '00010',
"action" set to '11' and "change" set to '0' (i.e., as Hex Value
0xC2). Note that this is the same Option Type as for the Jumbo
Payload option specified in [RFC2675] but appearing as a Destination
option and not a HBH option. All destinations must therefore
consistently accept or discard packets with Destination option 0xC2
according to this specification.
The source then sets Opt Data Len to 4 and sets Segment Length to a
16-bit non-final segment length between 1 and 65535. The source also
sets a 6-bit Nsegs field to the value (J-1) and sets a 6-bit Index
field to the index (between 0 and J-1) of the first PB segment. The
source next sets the F flag to 1 if a Forward Error Correction (FEC)
header follows (see: Section 8) and sets the P flag to 1 if a PIB is
included. The source finally sets the S flag to 0 if the final
parcel segment is included (otherwise sets S to 1) and sets the U
flag to 1 if a trailing UDP option length field is included.
When the PIB is present, the CRC length "N" is 4 octets for CRC32
when Segment Length is no larger than 9216 or 8 octets for CRC64 when
Segment Length is larger. When Segment Length, Nsegs are S are all
set to 0, the Parcel appears in the form of an Advanced Jumbo as
specified in Section 8.
The source then either includes or omits a Parcel Payload HBH Option
as shown in Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel Payload Length (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Limit (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Parcel Payload HBH Option
When the source includes a Parcel Payload HBH Option, it sets Option
Type "rest" to '00010', "action" to '00' and "change" to '0' (i.e.,
as Hex Value 0x02) then sets Opt Data Len to either 4, 8 or 12. If
Opt Data Len is 4, only the Parcel Payload Length is included. If
Opt Data Len is 8, an Integrity Limit is also included. If Opt Data
Len is 12, an Identification is also included. If Opt Data Len
encodes any other value, the HBH option is ignored. (Note: The
destination plus all intermediate nodes must therefore consistently
Templin Expires 5 July 2025 [Page 15]
Internet-Draft IPv6 Parcels and AJs January 2025
accept, ignore or discard packets with HBH option 0x02 according to
this specification. Intermediate nodes must not regard the presence
of the option as a reason to submit the packet for slow path
processing.)
The source then sets the IPv6 Payload Length field to 0 and sets
Parcel Payload Length to a 32-bit value M that encodes the length of
the IPv6 extension headers plus the length of the {TCP,UDP} header
(plus options and option length field when present) plus the length
of the PIB plus the combined lengths of all concatenated segments.
This arrangement will cause any intermediate systems that do not
recognize the option to discard or truncate the parcel to only the
IPv6 header due to the IPv6 Payload Length of 0.
If an Integrity Limit is included, the source next sets Integrity
Limit to the 32-bit length of the leading portion of the parcel
subject to hop-by-hop integrity checks by any delay/disruption
challenged links in the path. (Other link types can continue to
perform integrity checking over the entire Parcel Payload Length
according to the classic link model.) Integrity Limit therefore
determines the leading length of the parcel subject to link layer FCS
protection at links that engage the new link service model while
Parcel Payload Length determines the end of the parcel payload after
which the link layer appends the trailing FCS itself. Integrity
Limit therefore must be less than or equal to Parcel Payload Length.
The source finally assigns an Identification value for this parcel/
AJ; if the Parcel Payload HBH option includes an Identification
field, the source writes the value into the field.
{TCP,UDP}/IPv6 parcels produced by the transport and network layers
of the source therefore have the structures shown in Figure 4:
Templin Expires 5 July 2025 [Page 16]
Internet-Draft IPv6 Parcels and AJs January 2025
TCP/IPv6 Parcel Structure UDP/IPv6 Parcel Structure
+------------------------------+ +------------------------------+
| | | |
~ IPv6 Hdr (plus extensions) ~ ~ IPv6 Hdr (plus extensions) ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ TCP header (plus options) ~ ~ UDP header ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ Parcel Integrity Block ~ ~ Parcel Integrity Block ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ Segment 0 (L octets) ~ ~ Segment 0 (L octets) ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ Segment 1 (L octets) ~ ~ Segment 1 (L octets) ~
| | | |
+------------------------------+ +------------------------------+
~ More Segments ~ ~ More Segments ~
+------------------------------+ +------------------------------+
| | | |
~ Segment J-1 (K octets) ~ ~ Segment J-1 (K octets) ~
| | | |
+------------------------------+ +------------------------------+
~ UDP Options / Length ~
+------------------------------+
Figure 4: {TCP,UDP}/IPv6 Parcel Structure
6.1. TCP Parcels
A TCP Parcel is an IPv6 parcel that includes a TCP header plus
options preceded by an IPv6 header plus extensions with a Parcel
Payload Destination Option formed as specified in Section 6. The TCP
header is then followed by an optional PIB followed by the J
consecutive PB segments. 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 Segment Length field while the overall length of the
parcel is determined by the payload length M.
When the Parcel Payload HBH Option is absent, the source sets the
IPv6 Payload Length the same as for an ordinary IPv6 packet. When
the HBH option is included, the source instead sets the IPv6 Payload
Length to 0. The source then sets the Sequence Number field in the
Templin Expires 5 July 2025 [Page 17]
Internet-Draft IPv6 Parcels and AJs January 2025
TCP header to identify the first sequence numbered octet of the first
segment present; all additional segments present must then begin on
successive sequence number offsets according to L. The destination
and any intermediate systems can then determine the starting sequence
number for each segment by examining the Segment Length and Index
values with respect to the first segment.
When the PIB is absent, the source then calculates the Internet
checksum over the entire length of the parcel the same as for an
ordinary TCP packet and writes the value in the TCP checksum field.
When the PIB is present, the source instead calculates the Internet
checksum only over the TCP/IP headers and writes the value into the
TCP checksum field. The source then calculates the Internet checksum
for each Segment(i) (for i between 0 and (J-1)) beginning with the
Sequence number then writes the value into the PIB Checksum(i) field.
The source then calculates a CRC32/64 beginning with Checksum(i) as a
"psuedo-header" then extending over the length of Segment(i), then
writes the value into the PIB CRC(i) field.
See Appendix A for additional TCP considerations. See Section 10 for
additional integrity considerations.
Note: The parcel TCP header Source Port, Destination Port and
Sequence Number fields apply to each parcel segment (modulo Segment
Length and Index), 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.
6.2. UDP Parcels
UDP/IPv6 parcels include a UDP header preceded by an IPv6 header plus
extensions with a Parcel Payload Destination Option formed as shown
in Section 6. The UDP header is followed by an optional PIB followed
by a PB containing J transport layer segments followed by any UDP
options followed by a trailing 2-octet length field when necessary
(see below). Each PB 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 Segment Length field while the overall
length of the parcel is determined by the parcel payload length M as
above.
Templin Expires 5 July 2025 [Page 18]
Internet-Draft IPv6 Parcels and AJs January 2025
The source prepares UDP Parcels in an alternative adaptation of UDP
jumbograms [RFC2675] . When the Parcel Payload HBH Option is absent,
the source sets the IPv6 Payload Length normally. When a Parcel
Payload HBH option is present, the source instead sets the IPv6
Payload Length to 0.
The source then sets the UDP header Length field to the length of the
UDP header plus the lengths of the PIB plus all PB segments. If this
length exceeds 65535 octets, the source instead sets UDP Length to 0.
When UDP options are present but the IPv6 Payload Length is set to 0,
the source also includes a 2-octet trailing "UDP Option Length" field
that encodes the length of the UDP options which immediately precede
it plus the length of the UDP Option Length field itself (i.e., for a
minimum value of 2 octets).
When UDP checksums are disabled, the source writes the value '0' in
the checksum field. When UDP checksums are enabled and the PIB is
absent, the source calculates the UDP checksum the same as for an
ordinary UDP packet and writes the value into the UDP checksum field
while rewriting calculated 0 values as '0xffff'. When the PIB is
present, the source instead calculates the UDP checksum only over the
UDP/IP headers and writes this value into the UDP checksum field with
'0' written as '0xffff'.
The source next populates the PIB by calculating the Internet
checksum over the length of each Segment(i) and writes the value into
the Checksum(i) field while rewriting calculated 0 values as
'0xffff'. The source then calculates the CRC32/64 beginning with
Checksum(i) and extending over the length of Segment(i), then writes
the value into CRC(i).
For the final segment, the source extends the CRC calculation beyond
the length of the segment to also include the UDP options plus UDP
Option Length field when either or both are present. (Note that the
length of the UDP Option Length field itself is also included in the
Parcel Payload Length.)
See: Section 10 for additional integrity considerations.
6.3. Calculating K
The parcel source unambiguously encodes the values J, L and M in
parcel header fields as specified above. The value K is not encoded
in a header and must therefore be calculated by nodes that process
the parcel. A temporary value T is calculated as the payload length
M minus the length of the IPv6 extension headers minus the length of
the {TCP,UDP} header (plus options and option length when present)
minus the length of the PIB. K is then calculated as the remainder
Templin Expires 5 July 2025 [Page 19]
Internet-Draft IPv6 Parcels and AJs January 2025
of T divided by the Segment Length.
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
and destination addresses, then sets the Parcel Payload Destination
Option fields as above with Segment Length L set to a value between 1
and 65535. If it will also include a Parcel Payload HBH Option, the
source then sets Hop Limit to the Parcel Limit value discovered
through probing (see: Section 7.5); otherwise, it sets Hop Limit the
same as for an ordinary IPv6 packet.
The source also maintains a randomly-initialized 4-octet (32-bit)
Identification value for each destination. For each 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). (The source can then reset the cached value to a
new random number when necessary, e.g., to maintain an unpredictable
profile.) If the parcel/AJ includes a Parcel Probe Option or a
Parcel Payload HBH Option with an Identification field, the source
writes the current Identification value into the HBH option field of
the same name.
The source also populates all {TCP,UDP} header and option fields,
includes a populated PIB/PB then presents the parcel to an interface
for transmission to the next hop the same as for an ordinary packet.
If the new link model and/or an extended payload length field are
required, the source instead first inserts a Parcel Payload HBH
Option, sets the IPv6 Payload Length to 0 and forwards the parcel
over the parcel-capable path.
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 based on the IPv6 Payload Length
set to 0.
Templin Expires 5 July 2025 [Page 20]
Internet-Draft IPv6 Parcels and AJs January 2025
When the Parcel Payload HBH option Integrity Limit field is present,
each delay/disruption challenged link in the path checks integrity of
only that leading portion of the parcel/AJ even if the remainder of
the payload contains accumulated link errors. This ensures that the
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 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, the source
breaks the parcel up into individual IPv6 packets. 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 smaller
sub-parcels. In the first case, the source can apply packetization
(i.e., GSO), and the final destination can apply restoration (i.e.,
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 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 probes can only
provide an estimate.
When a router or destination receives a parcel/probe with a Parcel
Probe HBH Option, it first compares Check with the IPv6 header Hop
Limit if the values differ, the node drops the parcel/probe 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
Templin Expires 5 July 2025 [Page 21]
Internet-Draft IPv6 Parcels and AJs January 2025
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 forwards the parcel/
probe to the next hop while decrementing both the IPv6 header Hop
Limit field and Check (when present) 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
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
the same as for GSO. Routers also invoke packetization if
decrementing the parcel Hop Limit would cause it to become 0.
Otherwise, the node forwards the intact (sub-)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 HBH and Destination Options then removes the PIB (if
present) while retaining the contents for integrity reference. When
the PIB is present, the node first verifies the CRCs and Checksums of
each segment(i) (for i between 0 and (J-1)) and discards any
segment(i)'s with incorrect integrity checks. The node then copies
the {TCP,UDP}/IPv6 headers followed by segment (i) into J 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,UDP} options that are
permitted to appear in data segments in all but packet(0) which may
Templin Expires 5 July 2025 [Page 22]
Internet-Draft IPv6 Parcels and AJs January 2025
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 single Parcel Parameters
Destination Option. The option is formatted as shown in Figure 5:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |R|S|
+-+-+-+-+-+-+-+-+
Figure 5: Parcel Parameters Destination Option
The node then sets Option Type "rest" to '00010', "action" to '00'
and "change" to '0' (i.e., as Hex Value 0x02) then sets Opt Data Len
to 5. The node includes the Identification values corresponding to
the original parcel then sets Index to 'i' and sets S to 1 for non-
final packet(i)'s or to 0 for the final packet(i) of the final
(sub-)parcel. (If the original parcel does not contain an
identification, the node instead sets Identification to a random
value.) The node should include only a single Parcel Parameters
Destination Option; if multiple are included, the first is processed
and all others ignored.
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 IPv6 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 IPv6 Payload Length and UDP length fields then
calculates/sets the checksum according to [RFC0768].
When a PIB is present, the node reuses the PIB 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 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.
Templin Expires 5 July 2025 [Page 23]
Internet-Draft IPv6 Parcels and AJs January 2025
Note: Packets resulting from packetization may be too large to
transit the residual 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. When a PIB is
present, the node also includes a PIB in each sub-parcel that
contains the corresponding CRC and Checksum fields for its included
segments (where the per-segment fields of the sub-parcel PIB are
copied from the PIB of the original parcel).
If the original parcel's Parcel Payload Destination 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.
Templin Expires 5 July 2025 [Page 24]
Internet-Draft IPv6 Parcels and AJs January 2025
The node next appends identical {TCP,UDP}/IPv6 headers (including the
Parcel Payload Options 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 sets the TCP sequence number to the sequence number
of the first octet found in the first (sub-)parcel segment which can
be determined from the original parcel's sequence number plus the
Segment Length and Index for this new first segment. The node then
clears the TCP control bits in all sub-parcels except the first and
includes only those {TCP,UDP} options that are permitted to appear in
data segments in all non-first sub-parcels (while the first may also
include control segment options). 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 MTU is unlimited. 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
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
Templin Expires 5 July 2025 [Page 25]
Internet-Draft IPv6 Parcels and AJs January 2025
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 PIBs
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 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.
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).
Templin Expires 5 July 2025 [Page 26]
Internet-Draft IPv6 Parcels and AJs January 2025
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.
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 the same
as for Generic Receive Offload. The 5-tuple information plus the
Parcel Parameters Option values included by the source during
packetization (see: Figure 5) provide unambiguous 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.
Templin Expires 5 July 2025 [Page 27]
Internet-Draft IPv6 Parcels and AJs January 2025
The final destination can then present the concatenated parcel
contents to the transport layer with segments arranged in the same
order in which they were originally transmitted. 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.
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 the 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.
Templin Expires 5 July 2025 [Page 28]
Internet-Draft IPv6 Parcels and AJs January 2025
7.5. Parcel Probing
The original source can send parcels without risk of causing harm or
triggering alerts even with no prior coordination with the final
destination. Unless the source has operational assurance that all
nodes in the networked path up to and including the final destination
will correctly process Parcel options, however, this approach may
lead to systematic parcel loss resulting in a black hole.
The original source should therefore send initial probes into the
forward path using either ordinary IPv6 packets or expendable
parcels. The source should thereafter occasionally send additional
probes to determine whether path characteristics have changed and/or
to detect black hole conditions.
The original source prepares a packet/parcel with a Parcel Probe HBH
Option containing the parameters shown in Figure 6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Check | P-Limit |D|O| Residual Path MTU (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel Path MTU (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Parcel Probe HBH Option
The packet/parcel 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.
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
the IPv6 Payload Length the same as for an ordinary packet/parcel.
The source next sets Option Type "rest" to '00010' but with "action"
set to '00' and "change" set to '1' (i.e., as Hex Value 0x22). (This
Option Type setting distinguishes the Parcel Probe from the other
Parcel options.) The source then sets "Opt Data Len" to 12, and sets
Check to the same value as Hop Limit. The source should include only
a single Parcel Probe HBH Option; if multiple are included, the first
is processed and all others ignored.
Templin Expires 5 July 2025 [Page 29]
Internet-Draft IPv6 Parcels and AJs January 2025
Next, the source sets Parcel Limit (i.e., "P-Limit") to 0, sets
Residual Path MTU to the 16-bit value 'ffff' and sets Parcel Path MTU
to the 32-bit MTU of the outgoing (parcel-capable) interface for the
probe.
The source then sets D to 1 if the first hop link would benefit from
the new DTN link model; otherwise sets D to 0. Any intermediate
system in the path resets D to 1 if the new DTN link model is advised
for the next hop link. The source can then use the returned D value
to determine whether or not to include end-to-end link integrity
checks.
The source next sets O to 1 if it intends for the probe to traverse
any OMNI links in the path using jumbo-in-jumbo encapsulation where
large segment sizes are possible. If the source instead requires
assured delivery for smaller segments, it sets O to 0 to cause any
OMNI links in the path to engage encapsulation and IP fragmentation
with segment size limited to 65535 octets.
The source finally sends the parcel/packet containing the probe.
Each node in the path that observes this specification (including
IPv6 routers and the final destination itself) then examines and
processes the parcel probe as follows:
* If Check contains the same value as the IPv6 header Hop Limit,
then set Parcel 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 ("P-Limit") by 1 (up to a maximum value of 63). 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 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.
When the destination receives the probe, it performs the above
operations and also sets Residual Path MTU to 0 if Check contains the
same value as the IPv6 header Hop Limit. The destination then
returns a responsive IPv6 packet that includes a Parcel Probe Reply
Destination Option formatted as shown in Figure 7.
Templin Expires 5 July 2025 [Page 30]
Internet-Draft IPv6 Parcels and AJs January 2025
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | P-Limit |D|O| Residual Path MTU (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel Path MTU (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Parcel Probe Reply Destination Option
When the destination includes a Parcel Probe Reply Destination
Option, it sets Option Type "rest" to '00010', "action" to '00' and
"change" to '0' (i.e., as Hex Value 0x02) then sets Opt Data Len to
12. The destination then sets Parcel Path MTU, Residual Path MTU,
Parcel Limit, Reserved, D, O 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 IPv6
packet and returns the packet to the source while discarding the
probe. The destination should include only a single Parcel Probe
Reply Destination Option; if multiple are included, the first is
processed and all others ignored.
The original source can therefore send parcel 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 does not receive a probe reply, it is
likely that the path or the final destination does not recognize and
correctly process Parcel options. 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 Path MTU determines the largest-size
parcel/AJ segment that can transit the path up to a point that
parcellation or packetization would be necessary. If the O flag is
clear, then the maximum-sized segment that can traverse an
encapsulating link in the path without further probing is limited to
65535 octets. If the O flag is set, still larger segment sizes may
be possible.
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
Templin Expires 5 July 2025 [Page 31]
Internet-Draft IPv6 Parcels and AJs January 2025
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 parcel/AJ
transmissions to this destination.
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 Report (subject to rate limiting per [RFC4443]) as
discussed in Section 7.6.
After the initial path probing, any parcels/AJs may include a Parcel
Probe HBH option to determine whether a path change resulting in a
packet size-based black hole may have occurred. This allows for
inline probing with real protocol data and with less dependence on
transmission of explicit probe data.
When the source includes a Parcel Probe as a HBH option, it can
regard the receipt of an authentic Parcel Probe Reply as evidence
that the probe transited the entire forward path to the destination
and that the destination observes all aspects of this specification.
If the source receives no probe reply, or if it only needs to
determine whether the destination accepts parcels without also
probing the path, the source can include the Parcel Probe option as a
Destination option (i.e., instead of a HBH option).
When the source includes a probe as a Destination Option, it uses the
same Parcel Probe format and encoding as above except with 'act' set
to '11' (i.e., as Hex Value 0xE2) and with all fields in the option
body except Identification set to 0. If the destination recognizes
the option, it returns a Parcel Probe Reply Destination Option in an
authentic packet the same as for the HBH option case, but the zero-
valued fields other than Identification differentiate this as a
Destination Option probe instead of a HBH probe. If the destination
does not recognize the probe, it will instead return an ordinary
ICMPv6 message to the source. The destination should include only a
single Parcel Probe Reply Destination Option whether in response to a
HBH or Destination Probe option; if multiple are included, the first
is processed and all others ignored.
Templin Expires 5 July 2025 [Page 32]
Internet-Draft IPv6 Parcels and AJs January 2025
7.6. Parcel/Jumbo Reports
When the destination returns a Parcel/Jumbo Report, it packages the
report as a Destination Option in an IPv6 packet to return to the
source the same as for a Parcel Probe Reply (see: Figure 7). For a
positive report, the destination may set Parcel 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) 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.
8. Advanced Jumbos (AJ)
This specification introduces an IPv6 Advanced Jumbo (AJ) service as
a (single-segment) parcel alternative to basic jumbograms. Each AJ
begins with a {TCP,UDP}/IPv6 header followed by the additional header
encodings specified below.
When the source employs the Parcel Payload Destination Option to form
an AJ it sets Opt Data Len to 4 the same as for parcels but sets
Segment Length, Nsegs and S to 0. The source next replaces the Index
field with AJ-specific parameters as shown in Figure 8:
Templin Expires 5 July 2025 [Page 33]
Internet-Draft IPv6 Parcels and AJs January 2025
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Length | Nsegs |Res| Digest|F|P|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Parcel Payload Destination Option for Advanced Jumbos
The source then sets "Digest" to one of the CRC/Digest types found in
Figure 9. Implementations support the following integrity checking
services identified by "Digest":
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: Advanced Jumbo Integrity Algorithms
The source then sets "F" to 0 for "Non-FEC" or 1 for "IANA FEC" (see
below). If F is 1, the source includes an "IANA FEC Header"
immediately following the {TCP,UDP} header (i.e., appearing before
the PIB/PB) as shown in Figure 10:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Scheme | FEC Encoding Instance | FEC Framework |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IANA FEC Header
The source sets FEC Scheme according to the appropriate registry
values found in [IANA-FEC] and includes a 16-bit FEC Encoding
Instance field (with value set according to [IANA-FEC]) only if FEC
Scheme is larger than 127. The source then sets FEC Framework
according to [IANA-FEC] then sets FEC Length to the length of this
FEC header (i.e., either 4 or 6 octets) plus the number of padding
octets to be added by the FEC encoding operation. The source then
increments the AJ payload length by this value.
Templin Expires 5 July 2025 [Page 34]
Internet-Draft IPv6 Parcels and AJs January 2025
When P is 1, the source next includes an (N+2)-octet AJ PIB formatted
as shown in Figure 11 with the first N octets including the CRC/
Digest according to the appropriate length given in Figure 9 and the
final 2 octets including the Internet Checksum: "
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CRC/Digest (N octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Checksum (2 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: AJ Parcel Integrity Block (PIB) Format
When the source includes a Parcel Payload HBH Option, it then sets
Parcel Payload Length to the entire AJ payload length and optionally
sets Integrity Limit to the length of the leading portion of the AJ
intended for coverage by hop-by-hop FCS integrity checks. The source
next forms the {TCP/UDP}/IPv6 AJ the same as for parcels as shown in
Figure 4 except that the PIB is followed by only a single segment
corresponding to Index 0. Unlike parcels, the AJ PIB CRC/Digest
field length may exceed 8 octets according to the selected Digest
type. UDP AJs set the UDP Length field the same as specified for UDP
parcels, and include a trailing UDP Option Length field if U is set
to 1.
The source then includes a CRC/Digest in the AJ PIB for CRC32, CRC64,
MD5 [RFC1321], SHA1 [RFC3174] or the advanced US Secure Hash
Algorithms [RFC6234] according the to AJ Digest field value. (An AJ
Digest 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.)
The source next calculates the {TCP,UDP} Checksum based on the same
pseudo header as for an ordinary parcel (see: Figure 13). When P=1,
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 Digest values 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 AJ PIB Digest field. The source then
performs FEC encoding if necessary, resets the Payload Length to
include the additional length introduced by the FEC algorithm, then
sends the AJ via the next hop link toward the final destination.
At each forwarding hop, 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
Templin Expires 5 July 2025 [Page 35]
Internet-Draft IPv6 Parcels and AJs January 2025
forwards the packet to the next hop. Otherwise, the router
decrements Hop Limit (and Check when present) by 1 and forwards the
intact AJ to the next hop.
When the AJ arrives, the destination parses the IPv6 header and
Parcel Payload Options then applies FEC decoding for the payload if
necessary. The destination then rewrites the (Parcel) Payload Length
to reflect the payload decrease due to FEC, then verifies the message
CRC/Digest and Checksums. If all integrity checks agree, the
destination delivers the AJ to upper layers.
9. OMNI Interface Jumbo-in-Jumbo Encapsulation
OMNI interfaces set an unlimited MTU and 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.
When an OMNI interface ingress receives an IPv6 packet or an AJ/
parcel with a Parcel Probe HBH option, it examines the O flag. If O
is set to 0, the OMNI ingress sets Parcel Path MTU to the minimum of
its current value and 65535. The OMNI ingress then updates Check and
forwards the packet to the OMNI egress using OMNI encapsulation and
IP fragmentation if necessary.
To determine whether the path supports parcel/AJ segments that exceed
65535 octets, the original source can prepare a probe with a Parcel
Probe HBH option with O set to 1. For each such probe, the OMNI link
ingress inserts OMNI and L2 encapsulations per
[I-D.templin-6man-omni3] then performs "jumbo-in-jumbo" encapsulation
by copying the (L3) Parcel Probe HBH Option extension header from the
original probe into the L2 headers as shown in Figure 12.
Templin Expires 5 July 2025 [Page 36]
Internet-Draft IPv6 Parcels and AJs January 2025
Jumbo-in-Jumbo Parcel Probe Jumbo-in-Jumbo Parcel
+------------------------------+ +------------------------------+
| | | |
~ L2 IPv6 Hdr ~ ~ L2 IPv6 Hdr ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L2 UDP header ~ ~ L2 UDP header ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L2 Parcel Probe ~ ~ L2 Parcel Payload ~
| HBH Option | | HBH Option |
+------------------------------+ +------------------------------+
| | | |
~ OMNI IPv6 Header ~ ~ OMNI IPv6 Header ~
| plus extensions | | plus extensions |
+------------------------------+ +------------------------------+
| | | |
~ L3 IPv6 Hdr ~ ~ L3 IPv6 Hdr ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L3 Parcel Probe ~ ~ L3 Parcel Payload ~
| HBH Option | | HBH Option |
+------------------------------+ +------------------------------+
| | | |
~ {TCP,UDP} header and ~ ~ {TCP,UDP} header and ~
~ packet body ~ ~ parcel/AJ body ~
| | | |
+------------------------------+ +------------------------------+
Figure 12: Jumbo-in-Jumbo Encapsulation
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 Check, Parcel Path MTU and Parcel Limit
fields then re-calculates/re-sets the L2 UDP checksum.
When each successive OAL intermediate node receives the parcel probe,
it propagates the Parcel Probe HBH Option 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 probe, it first verifies that all
previous hops were jumbo-capable by examining Check. If Check does
Templin Expires 5 July 2025 [Page 37]
Internet-Draft IPv6 Parcels and AJs January 2025
not match the IPv6 Hop Limit, 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 Path MTU).
The OAL destination then forwards the probe to the next hop toward
the final destination from where it may transit multiple additional
parcel capable OMNI and non-OMNI links. If the probe traverses the
entire path to the final destination, the Parcel 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.
When the OMNI link ingress receives an AJ larger than 65535 octets,
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
HBH Option as an L2 extension. The OMNI link ingress sets the Parcel
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 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 Parcel Payload HBH Option 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.
Templin Expires 5 July 2025 [Page 38]
Internet-Draft IPv6 Parcels and AJs January 2025
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/AJ.
While a probe/parcel/AJ is traversing an OMNI link, 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.
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,
any links in the path that employ the model may forward parcels/AJs
with correct headers to the final destination transport layer even if
the upper layer protocol data accumulates link errors. The
destination is then ultimately responsible for its own end-to-end
error correction and integrity assurance.
Parcels/AJs include a PIB when there is at least one DTN link in the
path, or when the path may otherwise not support adequate hop-by-hop
integrity checks for larger-sized segments. For parcels/AJs that
include a PIB, the {TCP,UDP}/IPv6 header includes an integrity check
of only the headers while the PIB includes integrity checks for each
segment. 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 may be
instances when errors missed by the CRC are detected by the Checksum
[STONE].
Templin Expires 5 July 2025 [Page 39]
Internet-Draft IPv6 Parcels and AJs January 2025
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 with P=1 include CRC32/64 integrity checks in the PIB.
The original source uses either the CRC32C specification [RFC3385] or
the CRC64E specification [ECMA-182] to populate the PIB. AJs that
set a Digest type other than NULL instead include an N-octet CRC/
Digest calculated per [RFC1321], [RFC3174] or [RFC6234] according to
the hash algorithm assigned to Type.
For links that observe 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 and/or corrupted FEC/PIB fields.
Otherwise, the link far end unconditionally forwards the parcel/AJ to
the next hop even if the upper layer protocol data incurred link
errors. Following any FEC repairs, the PIB integrity checks will
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 13. This allows
for maximum reuse of widely deployed code while ensuring
interoperability.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Source Address (16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Destination Address (16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel Payload Length (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Length | Index |P|S| Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: {TCP,UDP}/IPv6 Parcel Pseudo-Header Formats
where the following fields appear:
* Source Address is the 16-octet IPv6 source address of the prepared
parcel/AJ.
Templin Expires 5 July 2025 [Page 40]
Internet-Draft IPv6 Parcels and AJs January 2025
* Destination Address is the 16-octet IPv6 destination address of
the prepared parcel/AJ.
* Parcel Payload Length is set to the 4-octet field of the same name
when the Parcel Payload HBH Option is included; otherwise, set to
the 2-octet IPv6 Payload Length.
* Segment Length, Index, P and S are the values that appear in the
fields of the same name in the Parcel Payload Destination Option
header.
* 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 segments in canonical order as a list of data
buffers. (For AJs, the transport layer instead delivers the
singleton AJ segment along with the Parcel 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 into the correct PIB field (or
writes the value 0 when UDP checksums are disabled).
For parcels/AJs that include CRC/Digest integrity checks, the network
layer then calculates the CRC/Digest for each segment beginning with
the per-segment Checksum (followed by the Sequence number for TCP)
and inserts the result in the correct PIB field. The network layer
then concatenates all segments then appends the PIB plus all
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 of the destination restores a parcel from one
or more individual {TCP,UDP}/IPv6 packets received from the source,
it verifies the Internet checksum of each individual packet (except
when UDP checksums are disabled), restores the parcel, and delivers
each parcel/AJ segment to the transport layer.
Templin Expires 5 July 2025 [Page 41]
Internet-Draft IPv6 Parcels and AJs January 2025
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. Hop-by-hop integrity checks
should at a minimum extend to cover the {TCP,UDP}/IP headers (plus
options/extensions) plus the FEC preamble and PIB.
Note: the source performs FEC encoding after calculating the PIB
contents and the destination performs FEC decoding before verifying
the PIB contents. This ensures that the source and destination will
obtain identical copies of the original parcel provided any errors
incurred in the path were corrected.
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 5 July 2025 [Page 42]
Internet-Draft IPv6 Parcels and AJs January 2025
12. IANA Considerations
The IANA is instructed to add the following new entries to the
"Internet Protocol Version 6 (IPv6) Parameters Registry group:
- in the "Destination Options and Hop-by-Hop Options" Registry
(registration procedure IESG Approval, IETF Review or Standards
Action) assign the following new entries:
Hex Val act chg rest Description Reference
------- --- --- ----- ----------- ---------
0x02 00 0 00010 Parcel Payload HBH Option [RFCXXXX]
0x02 00 0 00010 Parcel Param/Reply DestOpt [RFCXXXX]
0x22 00 1 00010 Parcel Probe HBH Option [RFCXXXX]
0xC2 11 0 00010 Parcel Payload Dest Option [RFCXXXX]
0xE2 11 1 00010 Parcel Probe Dest Option [RFCXXXX]
Figure 14: Destination Options and Hop-by-Hop Options
Note that the "rest" value is the same as for the existing Jumbo
Payload option [RFC2675] but the act/chg and resulting Hex Values
differentiate.
The IANA is instructed to add the following new entries to the
"Internet Control Message Protocol version 6 (ICMPv6) Parameters"
Registry group:
- in the "ICMPv6 Code Fields" Registry and "Type 2 - Packet Too
Big" Sub-registry (registration procedure Standards Action or IESG
Approval) assign the following new Code values:
Code Name Reference
--- ---- ---------
3 (suggested) Parcel Report [RFCXXXX]
4 (suggested) Jumbo Report [RFCXXXX]
Figure 15: ICMPv6 Code Fields: Type 2 - Packet Too Big Values
Finally, the IANA is instructed to create and maintain a new registry
titled "IPv6 Parcels and Advanced Jumbos (AJs)" that includes an
"IPv6 Advanced Jumbo Digest Types" table with the initial values
given below:
Templin Expires 5 July 2025 [Page 43]
Internet-Draft IPv6 Parcels and AJs January 2025
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 16: IPv6 Advanced Jumbo Digest Types
13. Security Considerations
In the control plane, original sources match the Identification (and/
or other identifying information) received in Parcel 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 Reports can apply
the message authentication services specified for AERO/OMNI.
In the data plane, multi-layer security solutions may be necessary 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 that include the Parcel Payload HBH Option are
not subject to fragmentation unless exposed to OMNI interface
encapsulation which includes a 64-bit Identification space.
Templin Expires 5 July 2025 [Page 44]
Internet-Draft IPv6 Parcels and AJs January 2025
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 codes 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.
The Parcel Payload Destination and HBH Options support end-to-end
authentication since the option contents are not permitted to change
en route. The Parcel Probe Destination and HBH options permit their
contents to change en route excluding them from end-to-end
authentication coverage.
14. Acknowledgements
This work was inspired by ongoing AERO/OMNI/DTN investigations
through Boeing Internal Research and Development (IRAD) supporting
DTN operations for the International Space Station (ISS). Some of
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.
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 IETF and
Boeing colleagues are acknowledged for their contributions: Roland
Bless, Ron Bonica, Scott Burleigh, Madhuri Madhava Badgandi, Brian
Carpenter, David Dong, Joel Halpern, Mike Heard, Tom Herbert, Bob
Hinden, Andy Malis, Bill Pohlchuck, Herbie Robinson, Bhargava Raman
Sai Prakash, Joe Touch and others who have provided guidance.
Honoring life, liberty and the pursuit of happiness.
Templin Expires 5 July 2025 [Page 45]
Internet-Draft IPv6 Parcels and AJs January 2025
15. References
15.1. Normative References
[I-D.ietf-tsvwg-udp-options]
Touch, J. D. and C. M. Heard, "Transport Options for UDP",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-
options-38, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
udp-options-38>.
[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>.
[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>.
Templin Expires 5 July 2025 [Page 46]
Internet-Draft IPv6 Parcels and AJs January 2025
[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.
[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-17, 6 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-17>.
Templin Expires 5 July 2025 [Page 47]
Internet-Draft IPv6 Parcels and AJs January 2025
[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero3-21, 4 November 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero3-21>.
[I-D.templin-6man-ipid-ext2]
Templin, F. and T. Herbert, "IPv6 Extended Fragment Header
(EFH)", Work in Progress, Internet-Draft, draft-templin-
6man-ipid-ext2-04, 20 June 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
ipid-ext2-04>.
[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-23, 4 November
2024, <https://datatracker.ietf.org/doc/html/draft-
templin-6man-omni3-23>.
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Performance Maximization", Work in
Progress, Internet-Draft, draft-templin-dtn-ltpfrag-17, 23
May 2024, <https://datatracker.ietf.org/doc/html/draft-
templin-dtn-ltpfrag-17>.
[I-D.templin-intarea-parcels2]
Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
Work in Progress, Internet-Draft, draft-templin-intarea-
parcels2-14, 16 December 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels2-14>.
[IANA-FEC] FEC, I., "Reliable Multicast Transport (RMT) FEC Encoding
IDs and FEC Instance IDs,
https://www.iana.org/assignments/rmt-fec-parameters",
November 2002.
[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>.
Templin Expires 5 July 2025 [Page 48]
Internet-Draft IPv6 Parcels and AJs January 2025
[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>.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052,
DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.
[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>.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
<https://www.rfc-editor.org/info/rfc5445>.
[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 5 July 2025 [Page 49]
Internet-Draft IPv6 Parcels and AJs January 2025
[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>.
[RFC9673] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", RFC 9673, DOI 10.17487/RFC9673,
October 2024, <https://www.rfc-editor.org/info/rfc9673>.
[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 5 July 2025 [Page 50]
Internet-Draft IPv6 Parcels and AJs January 2025
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). If the original parcel
contained a Timestamp option, the node then copies the Timestamp
option into the options section of the new TCP header. Appendix A of
[RFC7323] provides implementation guidelines for the Timestamp option
format.
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 5 July 2025 [Page 51]
Internet-Draft IPv6 Parcels and AJs January 2025
Appendix B. Extreme L Value Implications
For each parcel, the transport layer can specify any L value between
1 and 65535 octets.
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 the transport should specify an L value no
larger than (65535 - 28 - 40 - 24) = 65443 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.
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. GSO/GRO API
Some modern operating systems include Generic Segment Offload (GSO)
and Generic Receive Offload (GRO) services for use by Upper Layer
Protocols (ULPs) that engage segmentation. For example, GSO/GRO
support has been included in linux beginning with kernel version
4.18. Some network drivers and network hardware also support GSO/GRO
at or below the operating system network device driver interface
layer to provide benefits of delayed segmentation and/or early
reassembly. The following sections discuss the linux GSO and GRO
APIs.
Templin Expires 5 July 2025 [Page 52]
Internet-Draft IPv6 Parcels and AJs January 2025
D.1. GSO (i.e., Parcel Packetization)
GSO allows ULP implementations to present the sendmsg() or sendmmsg()
system calls with parcel buffers that include up to 64 ULP segments,
where each concatenated segment is distinguished by an ULP segment
delimiter. The operating system kernel will in turn prepare each
parcel buffer segment for transmission as an individual UDP/IP
packet. ULPs enable GSO either on a per-socket basis using the
"setsockopt()" system call or on a per-message basis for
sendmsg()/sendmmsg() as follows:
/* Set GSO segment size */
unsigned integer gso_size = SEGSIZE;
...
/* Enable GSO for all messages sent on the socket */
setsockopt(fd, SOL_UDP, UDP_SEGMENT, &gso_size, sizeof(gso_size)));
...
/* Alternatively, set per-message GSO control */
cm = CMSG_FIRSTHDR(&msg);
cm->cmsg_level = SOL_UDP;
cm->cmsg_type = UDP_SEGMENT;
cm->cmsg_len = CMSG_LEN(sizeof(uint16_t));
*((uint16_t *) CMSG_DATA(cm)) = gso_size;
ULPs must set SEGSIZE to a value no larger than the path MTU via the
underlying network interface, minus header overhead; this ensures
that UDP/IP datagrams generated during GSO segmentation will not
incur local IP fragmentation prior to transmission (Note: the linux
kernel returns EINVAL if SEGSIZE encodes a value that exceeds the
Path-MTU.)
ULPs should therefore dynamically determine SEGSIZE for paths that
traverse multiple links through Packetization Layer Path MTU
Discovery for Datagram Transports [RFC8899] (DPMTUD). ULPs should
set an initial SEGSIZE to either a known minimum MTU for the path or
to the protocol-defined minimum path MTU. The ULP may then
dynamically increase SEGSIZE without service interruption if the
discovered Path-MTU is larger.
D.2. GRO (i.e., Parcel Restoration)
GRO allows the kernel to return parcel buffers that contain multiple
concatenated received segments to the ULP in recvmsg() or recvmmsg()
system calls, where each concatenated segment is distinguished by an
ULP segment delimiter. ULPs enable GRO on a per-socket basis using
the "setsockopt()" system call, then optionally set up per receive
message ancillary data to receive the segment length for each message
as follows:
Templin Expires 5 July 2025 [Page 53]
Internet-Draft IPv6 Parcels and AJs January 2025
/* Enable GRO */
unsigned integer use_gro = 1; /* boolean */
setsockopt(fd, SOL_UDP, UDP_GRO, &use_gro, sizeof(use_gro)));
...
/* Set per-message GRO control */
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
*((int *)CMSG_DATA(cmsg)) = 0;
cmsg->cmsg_level = SOL_UDP;
cmsg->cmsg_type = UDP_GRO;
...
/* Receive per-message GRO segment length */
if ((segmentLength = *((int *)CMSG_DATA(cmsg))) <= 0)
segmentLength = messageLength;
ULPs include a pointer to a "use_gro" boolean indication to the
kernel to enable GRO; the only interoperability requirement therefore
is that each UDP/IP packet includes a parcel buffer with an integral
number of properly-formed segments. The kernel and/or underlying
network hardware will first coalesce multiple received segments into
a larger single segment whenever possible and/or return multiple
coalesced or singular segments to the ULP so as to maximize the
amount of data returned in a single system call.
ULPs that invoke recvmsg( ) and/or recvmmsg() will therefore receive
parcel buffers that include one or more concatenated received ULP
segments. The ULP accepts all received segments and identifies any
segments that may be missing. The ULP then engages segment ACK/NACK
procedures if necessary to request retransmission of any missing
segments.
Appendix E. Relation to Standard RFC2675 Jumbograms
This specification uses a new Parcel Payload Destination Option along
with a companion HBH Option of the same name instead of the [RFC2675]
Jumbo Payload HBH Option.
Standard [RFC2675] jumbograms are incompatible with UDP options,
since they always set the IPv6 Payload Length field to 0 and do not
otherwise encode a UDP options length. Standard jumbograms are
further subject to myriad formatting rules that require intermediate
systems to drop packets containing the option that do not fully
observe all rules and return an ICMPv6 Parameter Problem message.
Standard jumbograms are also always 64KB or larger and rely on IPv6
Path MTU Discovery (PMTUD) ICMPv6 Packet Too Big (PTB) messages to
determine whether the end-to-end path supports jumbograms. But the
ICMPv6 messages produced for Parameter Problem and PTB are often
unreliable and/or untrustworthy in nature.
Templin Expires 5 July 2025 [Page 54]
Internet-Draft IPv6 Parcels and AJs January 2025
Appendix F. Change Log
<< RFC Editor - remove prior to publication >>
Changes from version -20 to -21:
* General clean-up.
Changes from version -17 to -20:
* Clarified the need for end-to-end integrity checking and forward
error correction when retransmissions may be impractical.
* Clarified that the path MTU determines the maximum parcel/AJ
segment size, which may be smaller than the maximum parcel which
may contain multiple segments.
* Clarified that OMNI interfaces set an unlimited MTU and provide an
assured service for segments up to 65535 octets and a best-effort
service for larger segments.
* TCP sequence numbers for each parcel segment are now calculated
according to their offset from the base TCP header sequence number
and are not explicitly included as ancillary header fields.
* Changed {TCP,UDP} options to IPv6 Destination Options and removed
defunct text from IANA Considerations.
Changes from version -16 to -17:
* Made Parcel/AJ Destination Options more similar to one another to
simplify processing and easily distinguish parcels from AJs.
Changes from version -15 to -16:
* Closer integration with RFC2675; options codes now share the same
value as RFC2675.
Changes from version -14 to -15:
* Changed to request a new IPv6 option for Parcel Payload instead of
overloading the RFC9268 option.
* Parcel Payload Option exists as both a HBH and Destination option.
When only the DO is present, parcels/AJs follow the existing
Internet link model. When the HBH is present, the new link model
is engaged. This allows parcels/AJs to transit paths of
intermediate nodes that do not recognize the construct.
Templin Expires 5 July 2025 [Page 55]
Internet-Draft IPv6 Parcels and AJs January 2025
Changes from version -13 to -14:
* Updated IANA considerations based on IANA early review input.
Changes from version -12 to -13:
* Added new appendix "Relation to Standard RFC2675 Jumbograms".
Changes from version -11 to -12:
* Tightened specification of Parcel/Jumbo Payload Length.
Changes from version -10 to -11:
* Added Appendix on "GSO/GRO API".
* Updated text on handling UDP options.
Changes from version -09 to -10:
* Allow UDP options to appear in larger parcels and AJs based on a
"UDP Option Length" trailer.
Changes from version -08 to -09:
* Terminology.
Changes from version -07 to -08:
* Add terminology and general cleanup.
Changes from version -06 to -07:
* TCP and UDP options for parcels now apply to all parcel segments
and not just the first or final segment.
* TCP Sequence Numbers for parcels always appear in the PIB and with
the TCP header Sequence Number set to 0.
Changes from version -05 to -06:
* Moved all per-segment integrity checks into Parcel Integrity Block
header. This allows hop-by-hop integrity checking of the end-to-
end integrity check values.
Changes from earlier versions:
* Submit for review.
Templin Expires 5 July 2025 [Page 56]
Internet-Draft IPv6 Parcels and AJs January 2025
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 5 July 2025 [Page 57]