Internet DRAFT - draft-templin-6man-parcels
draft-templin-6man-parcels
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: 2675, 9268 (if approved) 15 February 2024
Intended status: Standards Track
Expires: 18 August 2024
IPv6 Parcels and Advanced Jumbos (AJs)
draft-templin-6man-parcels-20
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 significant operational advantages over
basic jumbograms for transporting singleton segments of all sizes
ranging from very small to very large. Parcels and AJs provide
essential building blocks for improved performance, efficiency and
integrity while encouraging larger Maximum Transmission Units (MTUs)
according to both the classic Internetworking link model and a new
Delay Tolerant Network (DTN) link model.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 August 2024.
Templin Expires 18 August 2024 [Page 1]
Internet-Draft IPv6 Parcels and AJs February 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Background and Motivation . . . . . . . . . . . . . . . . . . 9
5. A Delay-Tolerant Networking (DTN) Link Model . . . . . . . . 11
6. IPv6 Parcel Formation . . . . . . . . . . . . . . . . . . . . 13
6.1. TCP Parcels . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. UDP Parcels . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Calculating J and K . . . . . . . . . . . . . . . . . . . 17
7. Transmission of IPv6 Parcels . . . . . . . . . . . . . . . . 18
7.1. Packetization over Non-Parcel Links . . . . . . . . . . . 20
7.2. Parcellation over Parcel-capable Links . . . . . . . . . 23
7.3. OMNI Interface Parcellation and Reunification . . . . . . 24
7.4. Final Destination Restoration/Reunification . . . . . . . 26
7.5. Parcel/AJ Path Probing . . . . . . . . . . . . . . . . . 27
7.6. Parcel/Jumbo Reports . . . . . . . . . . . . . . . . . . 31
8. Advanced Jumbos (AJ) . . . . . . . . . . . . . . . . . . . . 32
9. OMNI Interface Jumbo-in-Jumbo Encapsulation . . . . . . . . . 34
10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Normative References . . . . . . . . . . . . . . . . . . 47
15.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. TCP Extensions for High Performance . . . . . . . . 51
Appendix B. Extreme L Value Implications . . . . . . . . . . . . 52
Appendix C. Advanced Jumbo Cyclic Redundancy Check (CRC128J) . . 53
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
Templin Expires 18 August 2024 [Page 2]
Internet-Draft IPv6 Parcels and AJs February 2024
1. Introduction
IPv6 packets [RFC8200] contain a single unit of transport layer
protocol data which becomes the retransmission unit in case of loss.
Transport layer protocols such as the Transmission Control Protocol
(TCP) [RFC9293] and reliable transport protocol users of the User
Datagram Protocol (UDP) [RFC0768] (including QUIC [RFC9000], LTP
[RFC5326] and others) prepare data units known as segments which the
network layer packages into individual IPv6 packets each containing
only a single segment. This document presents a new construct termed
the "IPv6 Parcel" which permits a single packet to include multiple
segments. The parcel is essentially a "packet-of-packets" with the
full {TCP,UDP}/IPv6 headers appearing only once but with possibly
multiple segments included.
Transport layer protocol entities form parcels by preparing a data
buffer (or buffer chain) containing at most 64 consecutive transport
layer protocol segments that can be broken out into individual
packets or smaller sub-parcels as necessary. All segments except the
final one must be equal in length and no larger than 65535 octets,
while the final segment must be no larger than the others. The
transport layer protocol entity then presents the buffer(s), number
of segments and non-final segment size to the network layer. The
network layer next appends per-segment headers and trailers, merges
the segments into the parcel body, appends a single {TCP,UDP} header
and finally appends a single IPv6 header plus extensions that
identify this as a parcel and not an ordinary packet.
The network layer then forwards each parcel over consecutive parcel-
capable links in a path until they arrive at a node with a next hop
link that does not support parcels, a parcel-capable link with a size
restriction, or an ingress Overlay Multilink Network (OMNI) Interface
[I-D.templin-intarea-omni] connection to an OMNI link that spans
intermediate Internetworks. In the first case, the original source
or next hop router applies packetization to break the parcel into
individual IPv6 packets. In the second case, the node applies
network layer parcellation to form smaller sub-parcels. In the final
case, the OMNI interface applies adaptation layer parcellation to
form still smaller sub-parcels, then applies adaptation layer IPv6
encapsulation and fragmentation if necessary. The node then forwards
the resulting packets/parcels/fragments to the next hop.
Following IPv6 reassembly if necessary, an egress OMNI interface
applies adaptation layer reunification if necessary to merge multiple
sub-parcels into a minimum number of larger (sub-)parcels then
delivers them to the network layer which either processes them
locally or forwards them via the next hop link toward the final
destination. The final destination can then apply network layer
Templin Expires 18 August 2024 [Page 3]
Internet-Draft IPv6 Parcels and AJs February 2024
(parcel-based) reunification or (packet-based) restoration if
necessary to deliver a minimum number of larger (sub-)parcels to the
transport layer. Reordering, loss or corruption of individual
segments within the network is therefore possible, but most
importantly the parcels delivered to the final destination's
transport layer should be the largest practical size for best
performance, and loss or receipt of individual segments (rather than
parcel size) determines the retransmission unit.
This document further introduces an "Advanced Jumbo (AJ)" service
that provides essential extensions beyond the basic IPv6 jumbograms
defined in [RFC2675]. AJs are simplified forms of parcels that
provide end and intermediate systems with a robust delivery service
when transmission of singleton segments of all sizes ranging from
very small to very large is necessary.
The following sections discuss rationale for adopting parcels and AJs
as core elements of the Internet architecture, as well as the actual
protocol constructs and operational procedures involved. Parcels and
AJs provide essential data transit for improved performance,
efficiency and integrity while encouraging larger Maximum
Transmission Units (MTUs). A new Delay Tolerant Networking (DTN)
link service model for parcels and AJs further supports delay/
disruption tolerance especially suited for air/land/sea/space
mobility applications. These services should inspire future
innovation in applications, transport protocols, operating systems,
network equipment and data links in ways that promise to transform
Internetworking.
2. Terminology
The Oxford Languages dictionary defines a "parcel" as "a thing or
collection of things wrapped in paper in order to be carried or sent
by mail". Indeed, there are many examples of parcel delivery
services worldwide that provide an essential transit backbone for
efficient business and consumer transactions.
In this same spirit, an "IPv6 parcel" is simply a collection of at
most 64 transport layer protocol segments wrapped in an efficient
package for transmission and delivery as a "packet-of-packets", with
each segment including its own end-to-end integrity checks. Each
segment may be up to 65535 octets in length, and all non-final
segments must be equal in length while the final segment must not be
larger. IPv6 parcels and AJs are distinguished from ordinary packets
and jumbograms through the constructs specified in this document.
Templin Expires 18 August 2024 [Page 4]
Internet-Draft IPv6 Parcels and AJs February 2024
The term "Advanced Jumbo (AJ)" refers to a parcel variation modeled
from the basic IPv6 jumbogram construct defined in [RFC2675]. AJs
include a 32-bit Jumbo Payload Length field and a single transport
layer protocol segment the same as for basic IPv6 jumbograms, but are
differentiated from true parcels and other jumbogram types by
including an "Advanced Jumbo Type" value plus end-to-end segment
integrity checks the same as for parcels. Unlike basic IPv6
jumbograms which are always 64KB or larger, AJs can range in size
from as small as the headers plus a minimal or even null payload to
as large as 2**32 octets minus headers.
The term "link" is defined in [RFC8200] as: "a communication facility
or medium over which nodes can communicate at the link layer, i.e.,
the layer immediately below IPv6. Examples are Ethernets (simple or
bridged); PPP links; X.25, Frame Relay, or ATM networks; and
internet-layer or higher-layer "tunnels", such as tunnels over IPv4
or IPv6 itself".
Where the document refers to "IPv6 header length", it means only the
length of the base IPv6 header (i.e., 40 octets), while the length of
any extension headers is referred to separately as the "IPv6
extension header length". The term "IPv6 header plus extensions"
refers generically to an IPv6 header plus all included extension
headers.
Where the document refers to "{TCP,UDP} header length", it means the
length of either the TCP header plus options (20 or more octets) or
the UDP header (8 octets). It is important to note that only a
single IPv6 header and a single full {TCP,UDP} header appears in each
parcel regardless of the number of segments included. This
distinction often provides a significant overhead savings advantage
made possible only by parcels.
Where the document refers to checksum calculations, it means the
standard Internet checksum unless otherwise specified. The same as
for TCP [RFC9293] and UDP [RFC0768], the standard Internet checksum
is defined as (sic) "the 16-bit one's complement of the one's
complement sum of all (pseudo-)headers plus data, padded with zero
octets at the end (if necessary) to make a multiple of two octets".
A notional Internet checksum algorithm can be found in [RFC1071],
while practical implementations require detailed attention to network
byte ordering to ensure interoperability between diverse
architectures.
The term "Cyclic Redundancy Check (CRC)" is used consistently with
its application in widely deployed Internetworking services. Parcels
that employ end-to-end CRC checks use the CRC32C [RFC3385] or CRC64E
[ECMA-182] standards according to non-final segment length "L" (see:
Templin Expires 18 August 2024 [Page 5]
Internet-Draft IPv6 Parcels and AJs February 2024
Section 10). AJs that employ end-to-end CRC checks include either a
CRC or message digest calculated according to the MD5 [RFC1321], SHA1
[RFC3174] or US Secure Hash [RFC6234] algorithms. In all cases, the
CRC or message digest is appended as a per-segment trailer arranged
for transmission in network byte order per standard Internetworking
conventions.
The terms "application layer (L5 and higher)", "transport layer
(L4)", "network layer (L3)", "(data) link layer (L2)" and "physical
layer (L1)" are used consistently with common Internetworking
terminology, with the understanding that reliable delivery protocol
users of UDP are considered as transport layer elements. The OMNI
specification further defines an "adaptation layer" logically
positioned below the network layer but above the link layer (which
may include physical links and Internet- or higher-layer tunnels).
The adaptation layer is not associated with a layer number itself and
is simply known as "the layer below L3 but above L2". A network
interface is a node's attachment to a link (via L2), and an OMNI
interface is therefore a node's attachment to an OMNI link (via the
adaptation layer).
The term "parcel-capable link/path" refers to paths that transit
interfaces to adaptation layer and/or link layer media (either
physical or virtual) capable of transiting {TCP,UDP}/IPv6 packets
that employ the parcel/AJ constructs specified in this document. The
source and each router in the path has a "next hop link" that
forwards parcels/AJs toward the final destination, while each router
and the final destination has a "previous hop link" that accepts en
route parcels/AJs. Each next hop link must be capable of forwarding
parcels/AJs (after first applying packetization or parcellation if
necessary) with segment lengths no larger than can transit the link.
The term "5-tuple" refers to a transport layer protocol entity
identifier that includes the network layer (source address,
destination address, source port, destination port, protocol number).
The term "4-tuple" refers to a network layer parcel entity identifier
that includes the adaptation layer (source address, destination
address, Parcel ID, Identification).
The Internetworking term "Maximum Transmission Unit (MTU)" is widely
understood to mean the largest packet size that can transit a single
link ("link MTU") or an entire path ("path MTU") without requiring
network layer fragmentation. The "Parcel/AJ Path MTU" value returned
during parcel path qualification determines the maximum sized parcel/
AJ that can transit the leading portion of the path up to a router
that cannot forward the parcel/AJ further, while the "Residual Path
MTU" determines the maximum-sized conventional packet that can
transit the remainder of the path following packetization. (Note
Templin Expires 18 August 2024 [Page 6]
Internet-Draft IPv6 Parcels and AJs February 2024
that for paths that include a significant number of routers that do
not recognize the parcel construct the Residual Path MTU may be over-
estimated.)
The terms "packetization" and "restoration" refer to a network layer
process in which the original source or a router on the path breaks a
parcel/AJ out into individual IPv6 packets that can transit the
remainder of the path without loss due to a size restriction. The
final destination then restores the combined packet contents into a
parcel before delivery to the transport layer. In current practice,
packetization/restoration can be considered as functional equivalents
to the well-known Generic Segmentation/Receive Offload (GSO/GRO)
services.
The terms "parcellation" and "reunification" refer to either network
layer or adaptation layer processes in which the original source or a
router on the path breaks a parcel into smaller sub-parcels that can
transit the path without loss due to a size restriction. These sub-
parcels are then reunified into larger (sub-)parcels before delivery
to the transport layer. As a network layer process, the sub-parcels
resulting from parcellation may only be reunified at the final
destination. As an adaptation layer process, the resulting sub-
parcels may first be reunified at an adaptation layer egress node
then possibly further reunified by the network layer of the final
destination.
The terms "fragmentation" and "reassembly" follow exactly from their
definitions in the IPv6 standard [RFC8200]. In particular, OMNI
interfaces support IPv6 encapsulation and fragmentation as an
adaptation layer process that can transit packet/parcel/AJ sizes that
exceed the underlying Internetwork path MTU. OMNI interface
fragmentation/reassembly occurs at a lower layer of the protocol
stack than packetization/restoration and/or parcellation/
reunification and therefore provides a complimentary service. Note
that IPv6 parcels and AJs are not eligible for direct fragmentation
and reassembly at the network layer but become eligible for
adaptation layer fragmentation and reassembly following OMNI IPv6
encapsulation.
Templin Expires 18 August 2024 [Page 7]
Internet-Draft IPv6 Parcels and AJs February 2024
"Automatic Extended Route Optimization (AERO)"
[I-D.templin-intarea-aero] and the "Overlay Multilink Network
Interface (OMNI)" [I-D.templin-intarea-omni] 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 parcel sizing variables "J", "K", "L" and "M" are cited
extensively throughout this document. "J" denotes the number of non-
final segments included in the parcel, "K" is the length of the final
segment, "L" is the length of each non-final segment and "M" is
termed the "Parcel Payload Length".
3. Requirements
All IPv6 source hosts, destination hosts and routers that accept IPv6
parcels and Advanced Jumbos MUST implement all aspects of this
specification that apply to their functions. IPv6 nodes MUST NOT for
example implement some aspects of their functions according to the
specification while ignoring other aspects. All IPv6 nodes also MUST
observe their respective requirements found in the normative
references, including [RFC8200].
IPv6 parcels and AJs are derived from the basic jumbogram
specification found in [RFC2675], but the specifications in this
document take precedence whenever they differ from the basic
requirements. Most notably, IPv6 parcels and AJs use the IPv6
Minimum Path MTU Option [RFC9268] instead of the basic IPv6 Jumbo
Payload Hop-by-Hop Option [RFC2675].
IPv6 parcels/AJs are not limited only to segment sizes that exceed
65535 octets; instead, parcels can be as small as the packet headers
plus a singleton segment with its integrity checks while AJs can be
as small as the headers plus a NULL payload. IPv6 parcels/AJs are
Templin Expires 18 August 2024 [Page 8]
Internet-Draft IPv6 Parcels and AJs February 2024
not eligible for direct network layer IPv6 fragmentation and
reassembly although they may become eligible for adaptation layer
fragmentation and reassembly following OMNI IPv6 encapsulation. IPv6
parcels and AJs therefore SHOULD NOT include IPv6 (Extended) Fragment
Headers, and implementation MUST silently ignore any IPv6 (Extended)
Fragment Headers in IPv6 parcels and AJs.
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.
For further Hop-by-Hop Options considerations, see:
[I-D.ietf-6man-hbh-processing]. For IPv6 extension header limits,
see: [I-D.ietf-6man-eh-limits].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Background and Motivation
Studies have shown that applications can improve their performance by
sending and receiving larger packets due to reduced numbers of system
calls and interrupts as well as larger atomic data copies between
kernel and user space. Larger packets also result in reduced numbers
of network device interrupts and better network utilization (e.g.,
due to header overhead reduction) in comparison with smaller packets.
However, the most prominent performance increases were observed by
increasing the transport layer protocol segment size even if doing so
invoked network layer fragmentation.
A first study [QUIC] involved performance enhancement of the QUIC
protocol [RFC9000] using the linux Generic Segment/Receive Offload
(GSO/GRO) facility. GSO/GRO provides a robust service that has shown
significant performance increases based on a multi-segment transfer
capability between the operating system kernel and QUIC applications.
GSO/GRO performs (virtual) fragmentation and reassembly at the
transport layer with the transport protocol segment size limited by
the path MTU (typically 1500 octets or smaller in current
Internetworking practices).
A second study [I-D.templin-dtn-ltpfrag] showed that GSO/GRO also
improves performance for the Licklider Transmission Protocol (LTP)
[RFC5326] used for the Delay Tolerant Networking (DTN) Bundle
Templin Expires 18 August 2024 [Page 9]
Internet-Draft IPv6 Parcels and AJs February 2024
Protocol [RFC9171] for segments larger than the actual path MTU
through the use of IP fragmentation. Historically, the NFS protocol
also saw significant performance increases using larger (single-
segment) UDP datagrams even when IP fragmentation is invoked, and LTP
still follows this profile today. Moreover, LTP shows this (single-
segment) performance increase profile extending to the largest
possible segment size which suggests that additional performance
gains are possible using (multi-segment) parcels or AJs that approach
or even exceed 65535 octets in total length.
TCP also benefits from larger packet sizes and efforts have
investigated TCP performance using jumbograms internally with changes
to the linux GSO/GRO facilities [BIG-TCP]. The approach proposed to
use the Jumbo Payload option internally and to allow GSO/GRO to use
buffer sizes that exceed 65535 octets, but with the understanding
that links that support jumbograms natively are not yet widely
deployed and/or enabled. Hence, parcels/AJs provide a packaging that
can be considered in the near term under current deployment
limitations.
A limiting consideration for sending large packets is that they are
often lost at links with MTU restrictions, and the resulting Packet
Too Big (PTB) messages [RFC4443][RFC8201] may be lost somewhere in
the return path to the original source. This path MTU "black hole"
condition can degrade performance unless robust path probing
techniques are used, however the best case performance always occurs
when loss of packets due to size restrictions is minimized.
These considerations therefore motivate a design where transport
protocols can employ segment sizes as large as 65535 octets (minus
headers) while parcels that carry multiple segments may themselves be
significantly larger. (Transport layer protocols can also use AJs to
transit even larger singleton segments.) Parcels allow the receiving
transport layer protocol entity to process multiple segments in
parallel instead of one at a time per existing practices. Parcels
therefore support improvements in performance, integrity and
efficiency for the original source, final destination and networked
path as a whole. This is true even if the network and lower layers
need to apply packetization/restoration, parcellation/reunification
and/or fragmentation/reassembly.
An analogy: when a consumer orders 50 small items from a major online
retailer, the retailer does not ship the order in 50 separate small
boxes. Instead, the retailer packs as many of the small items as
possible into one or a few larger boxes (i.e., parcels) then places
the parcels on a semi-truck or airplane. The parcels may then pass
through one or more regional distribution centers where they may be
repackaged into different parcel configurations and forwarded further
Templin Expires 18 August 2024 [Page 10]
Internet-Draft IPv6 Parcels and AJs February 2024
until they are finally delivered to the consumer. But most often,
the consumer will only find one or a few parcels at their doorstep
and not 50 separate small boxes. This flexible parcel delivery
service greatly reduces shipping and handling cost for all including
the retailer, regional distribution centers and finally the consumer.
5. A Delay-Tolerant Networking (DTN) Link Model
The classic Internetworking link service model requires each link in
the path to apply a link-layer frame integrity check often termed a
"Frame Check Sequence (FCS)". 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 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.)
While the classic link model has contributed to the unparalleled
success of terrestrial Internetworks (including the global public
Internet), new uses in which significant delays or disruptions can
occur are not as well supported. For example, a path that contains
multiple links with higher bit error rates may be unable to pass an
acceptable percentage of packets since loss due to link errors can
occur at any hop. Moreover, packets that incur errors at an
intermediate link but somehow pass the link integrity check will be
forwarded by all remaining links in the path leaving only the final
destination's Internet checksum as a last resort integrity check.
Advanced error detection and correction services not typically
associated with packets are therefore necessary; especially with the
advent of space-domain and wireless Internetworking, long delays and
significant disruptions are often intolerant of retransmissions.
This specification therefore introduces a new Delay Tolerant
Networking (DTN) link model.
IPv6 parcels/AJs that engage this DTN link model include an end-to-
end Cyclic Redundancy Check (CRC) or message digest with each segment
that is calculated and inserted by the original source and verified
by the final destination. For each such parcel/AJ admitted into a
parcel-capable link, the link near-end applies its standard link-
layer FCS upon transmission which the link far-end then verifies upon
reception. Instead of unconditionally discarding frames with link
errors, however, the link far-end delivers all parcel/AJ frames that
engage the DTN link model to upper layers. If a link error was
detected, the link far-end also sets a "CRC error" flag in the
parcel/AJ header (see: Section 10).
Templin Expires 18 August 2024 [Page 11]
Internet-Draft IPv6 Parcels and AJs February 2024
Each link along the path simply discards any ordinary packets,
parcels/AJs that observe the classic link model if a link error is
detected according to current practice. For IPv6 parcels and AJs
that incur link errors under the DTN link model, however, each
intermediate hop SHOULD and the final destination MUST first verify
the parcel/AJ header Checksum to protect against mis-delivery. Each
intermediate hop then unconditionally forwards the parcel/AJ to the
next hop even though it may include link errors.
IPv6 Parcel/AJ segments may therefore acquire cumulative link errors
along the path, but the parcel/AJ error bit plus per segment end-to-
end CRCs/digests and/or Internet checksums support final destination
integrity checking. The final destination in turn delivers each
segment to the local transport layer along with an error flag that is
set only if an end-to-end CRC/digest or Internet checksum error was
detected. The error flag advises the transport layer, which should
employ transport or higher-layer integrity checks and invoke
corrective actions.
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
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.
Templin Expires 18 August 2024 [Page 12]
Internet-Draft IPv6 Parcels and AJs February 2024
IPv6 parcels and AJs therefore provide a revolutionary advancement
for delay/disruption tolerance in air/land/sea/space mobile
Internetworking applications. As the Internet continues to evolve
from its more stable fixed terrestrial network origins to one where
more and more nodes operate in the mobile edge, this new link service
model relocates error detection and correction responsibilities from
intermediate systems to the end systems that are uniquely capable of
taking corrective actions.
Note: IPv6 parcels and AJs may already be compatible with widely-
deployed link types such as 1/10/100-Gbps Ethernet. Each Ethernet
frame is identified by a preamble followed by a Start Frame Delimiter
(SFD) followed by the frame data itself followed by the FCS and
finally an Inter Packet Gap (IPG). Since no length field is
included, however, the frame can theoretically extend as long as
necessary for transmission of IPv6 parcels and AJs that are much
larger than the typical 1500 octet Ethernet MTU as long as the time
duration on the link media is properly bounded. Widely-deployed
links may therefore already include all of the necessary features to
natively support large parcels and AJs with no additional extensions,
while operating systems may require extensions to post larger receive
buffers.
6. IPv6 Parcel Formation
A transport protocol entity identified by its 5-tuple forms a parcel
body by preparing a data buffer (or buffer chain) containing at most
64 transport layer protocol segments, with each TCP segment preceded
by a 4-octet Sequence Number header. Each segment plus Sequence
Number (for TCP) is further preceded by a 2-octet Internet Checksum
header and followed by a 0/4/8-octet CRC trailer. All non-final
segments MUST be equal in length while the final segment MUST NOT be
larger and MAY be smaller. The number of non-final segments is
represented as J; the total number of segments is therefore (J + 1).
The non-final segment size L is set to a 16-bit value that MUST be no
smaller than 256 octets and SHOULD be no larger than 65535 octets
minus the length of the {TCP,UDP} header (plus options), minus the
length of the IPv6 header (plus extensions), minus 2 octets for the
Checksum header minus 4 octets for the Sequence Number (for TCP)
minus 0/4/8 octets for the CRC trailer (see: Appendix B). The final
segment length K MUST NOT be larger than L but MAY be smaller. The
transport layer protocol entity then presents the buffer(s) and size
L to the network layer, noting that the combined buffer length(s) may
exceed 65535 octets when there are sufficient segments of a large
enough size.
Templin Expires 18 August 2024 [Page 13]
Internet-Draft IPv6 Parcels and AJs February 2024
If the next hop link is not parcel capable, the network layer
performs packetization to package each segment as an individual IPv6
packet as discussed in Section 7.1. If the next hop link is parcel
capable, the network layer instead completes the parcel by appending
a single full {TCP,UDP} header (plus options) and a single full IPv6
header (plus extensions). The network layer finally includes a
specially-formatted Parcel Payload Hop-by-Hop Option as an extension
to the IPv6 header of each parcel prior to transmission over a
network interface as shown in Figure 1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Check | Parcel/AJ Format (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |C|S|D|X| Parcel Payload Length (22 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Parcel Payload Hop-by-Hop Option
The network layer includes the Parcel Payload option as an IPv6 Hop-
by-Hop option with Option Type set to '0x30' and Opt Data Len set to
12. The length also distinguishes this format from its use as the
IPv6 Minimum Path MTU Hop-by-Hop Option [RFC9268]. The network layer
then sets the IPv6 Payload Length field to the minimum of 1280 octets
and the true packet length (minus the length of the IPv6 header) and
sets Parcel/AJ Format to L. The network layer next sets Parcel
Payload Length to a 22-bit value M that encodes the length of the
IPv6 extension headers plus the length of the {TCP,UDP} header plus
the combined length of all concatenated segments with their Checksum
and sequence number (for TCP) headers and CRC trailers.
Templin Expires 18 August 2024 [Page 14]
Internet-Draft IPv6 Parcels and AJs February 2024
The network layer next sets Index to an ordinal parcel segment
"Index" value between 0 and 63, sets the "(C)RC" flag to 1 if CRC
trailers are used (otherwise 0) and sets the "More (S)egments" flag
to 1 for non-final sub-parcels or 0 for the final (sub-)parcel.
(Note that non-zero Index values identify the initial segment index
in non-first sub-parcels of a larger original parcel while the value
0 denotes the first (sub-)parcel.) The network layer next sets
"(D)TN" to 0 for the classic link model or 1 for the new DTN link
model and sets "e(X)treme" to 0 unless otherwise specified (see:
Section 9). The network layer then includes a 4-octet
Identification, sets Code to 255 and sets Check to the same value
that will appear in the IPv6 header Hop Limit field on transmission
(see: Section 7.5). These values provide hop-by-hop assurance that
previous hops correctly implement the parcel protocol without
applying legacy IPv6 option processing per [RFC9268].
Following this transport and network layer processing, {TCP,UDP}/IPv6
parcels therefore have the structures shown in Figure 2:
TCP/IPv6 Parcel Structure UDP/IPv6 Parcel Structure
+------------------------------+ +------------------------------+
| | | |
~ IPv6 Hdr plus extensions ~ ~ IPv6 Hdr plus extensions ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ TCP header (plus options) ~ ~ UDP header ~
| | | |
+------------------------------+ +------------------------------+
| Checksum 0 followed by | | Checksum 0 followed by |
~ Sequence Number 0 followed ~ ~ Segment 0 (L octets) ~
~ by Segment 0 (L octets) ~ ~ followed by ~
| followed by CRC 0 | | CRC 0 |
+------------------------------+ +------------------------------+
| Checksum 1 followed by | | Checksum 1 followed by |
~ Sequence Number 1 followed ~ ~ Segment 1 (L octets) ~
~ by Segment 1 (L octets) ~ ~ followed by ~
| followed by CRC 1 | | CRC 1 |
+------------------------------+ +------------------------------+
~ ... ~ ~ ... ~
~ More Segments ~ ~ More Segments ~
~ ... ~ ~ ... ~
+------------------------------+ +------------------------------+
| Checksum J followed by | | Checksum J followed by |
~ Sequence Number J followed ~ ~ Segment J (K octets) ~
~ by Segment J (K octets) ~ ~ followed by ~
| followed by CRC J | | CRC J |
+------------------------------+ +------------------------------+
Templin Expires 18 August 2024 [Page 15]
Internet-Draft IPv6 Parcels and AJs February 2024
Figure 2: {TCP,UDP}/IPv6 Parcel Structure
6.1. TCP Parcels
A TCP Parcel is an IPv6 parcel that includes an IPv6 header plus
extensions with a Parcel Payload option formed as shown in Section 6
with Parcel Payload Length encoding a value no larger than (2**22 -
1) octets. The IPv6 header plus extensions is then followed by a TCP
header plus options (20 or more octets) followed by (J + 1)
consecutive segments that each include a 2-octet Internet Checksum
plus 4-octet per-segment Sequence Number header and 0/4/8-octet CRC.
The TCP header Sequence Number is set to 0, each non-final segment is
L octets in length and the final segment is K octets in length. The
value L is encoded in the Parcel/AJ Format field while the overall
length of the parcel is determined by the Parcel Payload Length M.
The source prepares TCP Parcels in an alternative adaptation of TCP
jumbograms [RFC2675]. The source calculates a checksum of the TCP
header plus IPv6 pseudo-header only (see: Section 10). The source
then writes the exact calculated value in the TCP header Checksum
field (i.e., without converting calculated 0 values to '0xffff').
The source next calculates the Internet checksum for each segment
independently beginning with the Sequence Number header and extending
over the length of the segment, then writes the value into the
2-octet Checksum header. When C=1, the source then calculates the
CRC beginning with the Checksum header and extending over both the
Sequence Number header and the length of the segment, then writes the
value into the 4/8-octet CRC trailer.
Note: The parcel TCP header Source Port, Destination Port and (per-
segment) Sequence Number fields apply to each parcel segment, while
the TCP control bits and all other fields apply only to the first
segment (i.e., "segment(0)"). Therefore, only parcel segment(0) may
be associated with control bit settings while all other segment(i)'s
must be simple data segments.
See Appendix A for additional TCP considerations. See Section 10 for
additional integrity considerations.
6.2. UDP Parcels
A UDP Parcel is an IPv6 Parcel that includes an IPv6 header plus
extensions with a Parcel Payload option formed as shown in Section 6
with Parcel Payload Length encoding a value no larger than (2**22 -
1) octets. The IPv6 header plus extensions is then followed by an
8-octet UDP header followed by (J + 1) transport layer segments with
their 2-octet Checksum headers and 0/4/8-octet CRC trailers. Each
Templin Expires 18 August 2024 [Page 16]
Internet-Draft IPv6 Parcels and AJs February 2024
segment must begin with a transport-specific start delimiter (e.g., a
segment identifier, a sequence number, etc.) included by the
transport layer user of UDP. The length of the first segment L is
encoded in the Parcel/AJ Format field while the overall length of the
parcel is determined by the Parcel Payload Length M as above.
The source prepares UDP Parcels in an alternative adaptation of UDP
jumbograms [RFC2675] by setting the UDP header Length field to the
length of the UDP header plus all parcel segments with their headers/
trailers. (If this length exceeds 65535 octets, the source instead
sets UDP Length to 0.) The source then calculates the checksum of
the UDP header plus IPv6 pseudo-header (see: Section 10) and writes
the exact calculated value into the UDP header Checksum field (i.e.,
without converting calculated 0 values to '0xffff'). If UDP
checksums are enabled, the source also calculates a separate checksum
for each segment while writing the values into the corresponding per-
segment Checksum header with calculated 0 values converted to
'0xffff' (if UDP checksums are disabled, the source instead writes
the value 0). When C=1, the source then calculates the CRC over each
segment beginning with the segment Checksum field and writes the
value into the segment's 4/8-octet CRC trailer.
Note: Truly large UDP parcels that set the UDP Length field to 0 are
ineligible for carrying UDP options per [I-D.ietf-tsvwg-udp-options].
See: Section 10 for additional integrity considerations.
6.3. Calculating J and K
The parcel source unambiguously encodes the values L and M in the
corresponding header fields as specified above. The values J and K
are not encoded in header fields and must therefore be calculated by
intermediate and final destination nodes as follows:
Templin Expires 18 August 2024 [Page 17]
Internet-Draft IPv6 Parcels and AJs February 2024
/* L is non-final segment length;
M is parcel payload length;
H is length of {TCP,UDP} header plus IPv6 extensions;
P is parcel payload length minus headers;
C is combined length of per-segment header/trailer;
(integer arithmetic assumed.)*/
if ((L < 256) || ((P = (M - H)) <= 0))
drop parcel;
if ((J = (P / (L + C))) > 64)
drop parcel;
if ((K = (P % (L + C))) == 0) {
J--; K = L;
} else {
if ((J > 63) || ((K -= C) <= 0))
drop parcel;
}
Figure 3: Calculating J and K
Note: from the above calculations, a well-formed parcel is one that
sets L to at least 256, includes J segments of length L and includes
one segment of length K (with each segment including its per-segment
header(s) and trailer). In addition, all parcels set L to at most
65535 and contain no more than 64 segments.
7. Transmission of IPv6 Parcels
When the network layer of the source assembles a {TCP,UDP}/IPv6
parcel it fully populates all IPv6 header fields including the source
address, destination address and Parcel Payload option as above. The
source sets Hop Limit to the Parcel Limit value discovered through
probing (see: Section 7.5), sets D to 0 for classic or 1 for DTN link
models, sets X to 0 for normal or 1 for "e(X)treme path" OMNI link
traversal and also sets Parcel/AJ Format to L (between 256 and 65535)
to distinguish the parcel from other jumbogram types (see:
Section 8).
Templin Expires 18 August 2024 [Page 18]
Internet-Draft IPv6 Parcels and AJs February 2024
The source also maintains a randomly-initialized 4-octet (32-bit)
Identification value for each destination. For each packet, parcel
or AJ transmission, the source sets the Identification to the current
cached value for this destination and increments the cached value by
1 (modulo 2**32) for each successive transmission. (The source can
then reset the cached value to a new random number when necessary,
e.g., to maintain an unpredictable profile.) For each parcel
transmission, the source includes the Identification value in the
IPv6 Parcel Payload Option.
The source finally presents the parcel to an interface for
transmission to the next hop. For ordinary interface attachments to
parcel-capable links, the source simply admits each parcel into the
interface the same as for any IPv6 packet where it may be forwarded
by one or more routers over additional consecutive parcel-capable
links possibly even traversing the entire forward path to the final
destination. Note that any node in the path that does not recognize
the parcel construct may either drop it and return an ICMP Parameter
Problem message or attempt to forward it as a (truncated) packet,
where the IPv6 Payload Length determines a likely truncation length.
Most importantly, each parcel-capable link in the path forwards
parcels/AJs with D=1 even if link errors were detected since each
segment is responsible for its own end-to-end integrity. This
ensures that the vast majority of coherent data is delivered to the
final destination instead of being discarded along with a minor
amount of corrupted data at an intermediate hop. When the link far
end receives a parcel/AJ with D=1 it sets a "CRC error" flag in the
parcel/AJ header if a link error was detected before forwarding to
the next hop (see: Section 10).
When the next hop link does not support parcels at all, or when the
next hop link is parcel-capable but configures an MTU that is too
small to pass the entire parcel, the source breaks the parcel up into
individual IPv6 packets (in the first case) or into smaller sub-
parcels (in the second case). In the first case, the source can
apply packetization using Generic Segment Offload (GSO), and the
final destination can apply restoration using Generic Receive Offload
(GRO) to deliver the largest possible parcel buffer(s) to the
transport layer. In the second case, the source can apply
parcellation to break the parcel into sub-parcels with each
containing the same Identification value and with the S flag set
appropriately. The final destination can then apply reunification to
deliver the largest possible parcel buffer(s) to the transport layer.
In all other ways, the source processes of breaking a parcel up into
individual IPv6 packets or smaller sub-parcels entail the same
considerations as for a router on the path that invokes these
processes as discussed in the following subsections.
Templin Expires 18 August 2024 [Page 19]
Internet-Draft IPv6 Parcels and AJs February 2024
Parcel/AJ probes that test the forward path's ability to pass
parcels/AJs include "Parcel/AJ Path MTU" and "Residual Path MTU"
fields as discussed in Section 7.5. Each router in the path may
rewrite the fields to progressively smaller values in a similar
fashion as for [RFC9268]. The fact that the probe transited a
previous hop link provides sufficient evidence of forward progress
since path MTU determination is unidirectional in the forward path
only. Following successful parcel probing, each parcel/AJ
transmission may include {TCP,UDP} segment size probes used for
packetization layer path MTU discovery per [RFC4821][RFC8899]. Such
probes may be necessary to refine the Residual Path MTU, for which
parcel/AJ probes can only provide an estimate.
When a router or destination receives a parcel (or parcel/AJ probe)
it first compares Code with 255 and Check with the IPv6 header Hop
Limit; if either value differs, the node drops the parcel and returns
a negative Jumbo Report (see: Section 7.6) subject to rate limiting.
For all other intact parcels, each router next compares the value L
with the next hop link MTU. If the next hop link is parcel capable
but configures an MTU too small to admit a parcel with a single
segment of length L the router returns a positive Jumbo Report
(subject to rate limiting) with MTU set to the next hop link MTU. If
the next hop link is not parcel capable and configures an MTU too
small to pass an individual IPv6 packet with a single segment of
length L the router instead returns a positive Parcel Report (subject
to rate limiting) with MTU set to the next hop link MTU. If the next
hop link is parcel capable the router MUST forward the parcel to the
next hop while decrementing both Check and the IPv6 header Hop Limit
field by 1.
If the router recognizes parcels but the next hop link in the path
does not, or if the entire parcel would exceed the next hop link MTU,
the router instead opens the parcel. The router then forwards each
enclosed segment in individual IPv6 packets or in a set of smaller
sub-parcels that each contain a subset of the original parcel's
segments. If the next hop link is via an OMNI interface, the router
instead follows OMNI Adaptation Layer procedures. These
considerations are discussed in detail in the following sections.
7.1. Packetization over Non-Parcel Links
For transmission of individual packets over links that do not support
parcels, the source or router (i.e., the node) invokes packetization
in the spirt of Generic Segment Offload (GSO). The node determines
whether packetization is needed by examining the IPv6 Hop Limit. In
particular, the source initiates packetization if the Hop Limit is
already 0 while the router initiates packetization if decrementing
the Hop Limit would cause it to become 0. Otherwise, the node
Templin Expires 18 August 2024 [Page 20]
Internet-Draft IPv6 Parcels and AJs February 2024
forwards the intact parcel or performs parcellation (see: Section 7.5
for discussion of Parcel Limit).
To initiate packetization, the node first determines whether an
individual packet with segment of length L can fit within the next
hop link/path MTU. If an individual packet would be too large the
node drops the parcel and returns a positive Parcel Report message
(subject to rate limiting) with MTU set to the next hop link/path MTU
and with the leading portion of the parcel beginning with the IPv6
header as the "packet in error".
If an individual packet can be accommodated, the node next removes
the Parcel Payload option and caches the per-segment Checksum header
values (and for TCP also caches the Sequence Numbers). If C=1, the
node then verifies the CRCs of each segment(i) (for i = 0 thru J) and
discards any segment(i)'s with incorrect CRCs. The node then copies
the {TCP,UDP}/IPv6 headers followed by segment (i) (i.e., while
discarding the per-segment headers and trailers) into (J + 1)
individual packets ("packet(i)"). Each such packet(i) will be
subject to the independent link-layer CRC verifications of each
remaining link in the path.
For each packet(i), the node then clears the TCP control bits in all
but packet(0), and includes only those TCP options that are permitted
to appear in data segments in all but packet(0) which may also
include control segment options (see: Appendix A for further
discussion). The node then sets IPv6 Payload Length for each
packet(i) based on the length of segment(i) according to [RFC8200].
For each packet(i), the node then inserts a Parcel Parameters option
for TCP [RFC9293] or UDP [I-D.ietf-tsvwg-udp-options]. The {TCP,UDP}
option is formatted as shown in Figure 4:
Parcel Parameters Option for Multi-Segment Parcels
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | ExID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |R|S|Res| Parcel Payload Length (22 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parcel Parameters Option for Single-Segment Parcels/AJs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | ExID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Templin Expires 18 August 2024 [Page 21]
Internet-Draft IPv6 Parcels and AJs February 2024
Figure 4: Parcel Parameters {TCP,UDP} Option
The node includes the Parcel Parameters option in the {TCP,UDP}
header of each packet(i). The node sets Kind to 253 for TCP
[RFC6994][RFC9293] or 127 for UDP [I-D.ietf-tsvwg-udp-options], then
sets ExID to TBD1 (see: IANA Considerations). For multi-segment
parcels, the node next sets Length to 12 and includes a 4-octet
Parcel Payload Length (plus preamble) field. The node next sets
Index to 'i', sets S to 1 for non-final packet(i)'s or to 0 for the
final packet(i). The node finally includes the Parcel Payload Length
and Identification values found in the original parcel header. (For
single-segment parcels and AJs that include an identification, the
node instead sets Length to 8, omits the Parcel Payload Length and
Index fields then includes the parcel/AJ Identification value. For
AJs that do not include an identification, the node instead omits the
Parcel Parameters option.)
For each IPv6 packet, the node then sets Hop Limit to 64. This value
allows for sufficient conventional IPv6 forwarding hops along the
residual path from the node performing packetization to the final
destination while still providing an adequate termination count to
protect against routing loops.
For each TCP/IPv6 packet, the node next sets Payload Length according
to [RFC8200] then calculates/sets the checksum for the packet
according to [RFC9293]. For each UDP/IPv6 packet, the node instead
sets the Payload Length and UDP length fields then calculates/sets
the checksum according to [RFC0768]. The node reuses the cached
checksum value for each segment in the checksum calculation process.
The node first calculates the Internet checksum over the new packet
{TCP,UDP}/IPv6 headers then adds the cached segment checksum value.
For TCP, the node finally writes the cached Sequence Number value for
each segment into the TCP Sequence Number field which initially
encoded the value 0 (note that this operation ordering permits the
node to reuse the cached segment checksum value without having to
recalculate). For UDP, if a per-segment Checksum was 0 the node
instead writes the value 0 in the Checksum field of the corresponding
UDP/IPv6 packet. The node then forwards each IPv6 packet to the next
hop.
Note: Packets resulting from packetization may be too large to
transit the remaining path to the final destination, such that a
router may drop the packet(s) and possibly also return an ordinary
ICMP PTB message. Since these messages cannot be authenticated or
may be lost on the return path, the original source should take care
in setting a segment size as large as the Residual Path MTU unless as
part of an active probing service.
Templin Expires 18 August 2024 [Page 22]
Internet-Draft IPv6 Parcels and AJs February 2024
7.2. Parcellation over Parcel-capable Links
For transmission of smaller sub-parcels over parcel-capable links,
the source or intermediate system (i.e., the node) first determines
whether a single segment of length L can fit within the next hop link
MTU if packaged as a (singleton) sub-parcel. If a singleton sub-
parcel would be too large, the node returns a positive Jumbo Report
message (subject to rate limiting) with MTU set to the next hop link
MTU and containing the leading portion of the parcel beginning with
the IPv6 header then drops the parcel. Otherwise, the node employs
network layer parcellation to break the original parcel into smaller
groups of segments that can traverse the path as whole (sub-)parcels.
The node first determines the number of segments of length L that can
fit into each sub-parcel under the size constraints. For example, if
the node determines that each sub-parcel can contain 3 segments of
length L, it creates sub-parcels with the first containing Segments
0-2, the second containing 3-5, the third containing 6-8, etc., and
with the final containing any remaining Segments (where each segment
includes its Checksum header and when C=1 also the CRC trailer from
the original (sub-)parcel).
If the original parcel's Parcel Payload option has S set to 0, the
node then sets S to 1 in all resulting sub-parcels except the last
(i.e., the one containing the final segment of length K, which may be
shorter than L) for which it sets S to 0. If the original parcel has
S set to 1, the node instead sets S to 1 in all resulting sub-parcels
including the last. The node next sets the Index field to the value
'i' which is the ordinal number of the first segment included in each
sub-parcel. (In the above example, the first sub-parcel sets Index
to 0, the second sets Index to 3, the third sets Index to 6, etc.).
If another router further down the path toward the final destination
forwards the sub-parcel(s) over a link that configures a smaller MTU,
the router may break it into even smaller sub-parcels each with Index
set to the ordinal number of the first segment included.
The node next appends identical {TCP,UDP}/IPv6 headers (including the
Parcel Payload option plus any other extensions) to each sub-parcel
while resetting Index, S, and Parcel Payload Length in each as above.
The node also sets the Hop Limit in each sub-parcel to the same value
that occurred in the original (sub-)parcel.
Templin Expires 18 August 2024 [Page 23]
Internet-Draft IPv6 Parcels and AJs February 2024
For TCP, the node then clears the TCP control bits in all but the
first sub-parcel and includes only those TCP options that are
permitted to appear in data segments in all but the first sub-parcel
(which may also include control segment options). For both TCP and
UDP, the node then resets the {TCP,UDP} Checksum according to
ordinary parcel formation procedures (see above). The node finally
sets PMTU to the next hop link MTU then forwards each (sub-)parcel to
the parcel-capable next hop.
7.3. OMNI Interface Parcellation and Reunification
For transmission of original parcels or sub-parcels over OMNI
interfaces, the node admits all parcels into the interface
unconditionally since the OMNI interface can accommodate all parcel
sizes. The OMNI Adaptation Layer (OAL) of this First Hop Segment
(FHS) OAL source node then forwards the parcel to the next OAL hop
which may be either an intermediate node or a Last Hop Segment (LHS)
OAL destination. OMNI interface parcellation and reunification
procedures are specified in detail in the remainder of this section,
while parcel encapsulation and fragmentation procedures are specified
in [I-D.templin-intarea-omni].
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
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
Templin Expires 18 August 2024 [Page 24]
Internet-Draft IPv6 Parcels and AJs February 2024
(sub-)parcel identified by the 4-tuple information corresponding to
the OAL source. This reunification entails the concatenation of
Checksums/Segments included in sub-parcels with the same Parcel ID
and with Identification values within (modulo 64) of one another to
create a larger sub-parcel possibly even as large as the entire
original parcel. The OAL destination concatenates the segments plus
their checksums (and when C=1 also CRCs) for each sub-parcel in
ascending Identification value order, while ensuring that any sub-
parcel with TCP control bits set appears as the first concatenated
element in a reunified larger parcel and any sub-parcel with S flag
set to 0 appears as the final concatenation. The OAL destination
then sets S to 0 in the reunified (sub-)parcel if and only if one of
its constituent elements also had S set to 0; otherwise, it sets S to
1.
The OAL destination then appends a common {TCP,UDP}/IPv6 header plus
extensions to each reunified sub-parcel while resetting Index, S and
Parcel Payload Length in the corresponding header fields of each.
For TCP, if any sub-parcel has TCP control bits set the OAL
destination regards it as sub-parcel(0) and uses its TCP header as
the header of the reunified (sub-)parcel with the TCP options
including the union of the TCP options of all reunified sub-parcels.
The OAL destination then resets the {TCP,UDP}/IPv6 header checksum.
If the OAL destination is also the final destination, it then
delivers the sub-parcels to the network layer which processes them
according to the 5-tuple information supplied by the original source.
If the OAL destination is not the final destination, it instead
forwards each sub-parcel toward the final destination the same as for
an ordinary IPv6 packet.
Note: Adaptation layer parcellation over OMNI links occurs only at
the OAL source while adaptation layer reunification occurs only at
the OAL destination; intermediate OAL nodes do not engage in the
parcellation/reunification processes. The OAL destination should
retain sub-parcels in the reunification buffer only for a short time
(e.g., 1 second) or until all sub-parcels of the original parcel have
arrived. The OAL destination then delivers full and/or incomplete
reunifications to the network layer (in cases where loss and/or
delayed arrival interfere with full reunification).
Note: OMNI interface parcellation and reunification is an OAL process
based on the adaptation layer 4-tuple and not the network layer
5-tuple. This is true even if the OAL has visibility into network
layer information since some sub-parcels of the same original parcel
may be forwarded over different network paths.
Templin Expires 18 August 2024 [Page 25]
Internet-Draft IPv6 Parcels and AJs February 2024
Note: Some implementations may encounter difficulty in applying
adaptation layer reunification for sub-parcels that have already
incurred lower layer fragmentation and reassembly (e.g., due to
network kernel buffer structure limitations). In that case, the
adaptation layer can either linearize each sub-parcel before applying
reunification or deliver incomplete reunifications or even individual
sub-parcels to upper layers.
Note: If the original source selects the "e(X)treme path" for OMNI
link traversal, the OMNI interface forwards the entire parcel as a
(giant) singleton carrier packet using jumbo-in-jumbo encapsulation
instead of applying adaptation layer parcellation as discussed in
Section 9.
7.4. Final Destination Restoration/Reunification
When the original source or a router on the path opens a parcel and
forwards its contents as individual IPv6 packets, these packets will
arrive at the final destination which can hold them in a restoration
buffer for a short time before restoring the original parcel using
Generic Receive Offload. The 5-tuple information plus the Parcel
Parameters option values included by the source during packetization
(see: Figure 4) provide sufficient context for GRO restoration which
practical implementations have proven as a robust service at high
data rates.
When the original source or a router on the path opens a parcel and
forwards its contents as smaller sub-parcels, these sub-parcels will
arrive at the final destination which can hold them in a
reunification buffer for a short time or until all sub-parcels have
arrived. The 5-tuple information plus the Index, S and
Identification values provide sufficient context for reunification.
In both the restoration and reunification cases, the final
destination concatenates segments according to ascending Index and/or
Identification numbers to preserve segment ordering even if a small
degree of reordering and/or loss may have occurred in the networked
path. When the final destination performs restoration/reunification
on TCP segments, it must include the one with any TCP flag bits set
as the first concatenation and with the TCP options including the
union of the TCP options of all concatenated packets or sub-parcels.
For both TCP and UDP, any packet or sub-parcel containing the final
segment must appear as a final concatenation.
The final destination can then present the concatenated parcel
contents to the transport layer with segments arranged in (nearly)
the same order in which they were originally transmitted. Unless a
security encapsulation is included, strict ordering is not mandatory
Templin Expires 18 August 2024 [Page 26]
Internet-Draft IPv6 Parcels and AJs February 2024
since each segment will include a transport layer protocol specific
start delimiter with positional coordinates. However, the Index
field and/or Identification includes an ordinal value that preserves
ordering since each sub-parcel or individual IPv6 packet contains an
integral number of whole transport layer protocol segments.
Note: Restoration and/or reunification buffer management is based on
a hold timer during which singleton packets or sub-parcels are
retained until all members of the same original parcel have arrived.
Implementations should maintain a short hold timer (e.g., 1 second)
and advance any restorations/reunifications to upper layers when the
hold timer expires even if incomplete.
Note: Since loss and/or reordering may occur in the network, the
final destination may receive a packet or sub-parcel with S set to 0
before all other elements of the same original parcel have arrived.
This condition does not represent an error, but in some cases may
cause the network layer to deliver sub-parcels that are smaller than
the original parcel to the transport layer. The transport layer
simply accepts any segments received from all such deliveries and
will request retransmission of any segments that were lost and/or
damaged.
Note: Restoration and/or reunification buffer congestion may indicate
that the network layer cannot sustain the service(s) at current
arrival rates. The network layer should then begin to deliver
incomplete restorations/reunifications or even individual segments to
upper layers (e.g., via a socket buffer) instead of waiting for all
segments to arrive. The network layer can manage restoration/
reunification buffers, e.g., by maintaining buffer occupancy high/low
watermarks.
Note: Some implementations may encounter difficulty in applying
network layer restoration/reunification for packets/sub-parcels that
have already incurred adaptation layer reassembly/reunification. In
that case, the network layer can either linearize each packet/sub-
parcel before applying restoration/reunification or deliver
incomplete restorations/reunifications or even individual packets/
sub-parcels to upper layers.
7.5. Parcel/AJ Path Probing
Unless there is operational assurance that all routers and
destinations in the network will recognize Parcel/AJ constructs, the
original source should send an initial probe to determine whether
parcels/AJs can transit at least an initial portion of the forward
path toward the final destination. The original source prepares an
ordinary IPv6 packet with an IPv6 Minimum Path MTU Hop-by-Hop option
Templin Expires 18 August 2024 [Page 27]
Internet-Draft IPv6 Parcels and AJs February 2024
that contains Parcel/AJ Probe parameters as shown in Figure 5:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Code | Check |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel/AJ Path MTU (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Path MTU (16 bits) | Parcel Limit | Reserved |O|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Parcel/AJ Probe Hop-by-Hop Option
The IPv6 packet can be either a purpose-built probe or part of an
existing transport protocol session, but it should cause the
destination to return a responsive {TCP,UDP}/IPv6 packet with
authenticating credentials and with a Parcel/AJ 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
Payload Length the same as for an ordinary IPv6 packet. The source
next sets "Option Type" to '0x30' the same as for the Parcel Payload
Option, sets "Option Data Len" to 14, sets Code to 255 and sets Check
to the same value as Hop Limit.
Next, the source sets Parcel/AJ Path MTU to the 32-bit MTU of the
outgoing (parcel-capable) interface for the probe, sets Residual Path
MTU to the 16-bit value 'ffff', and sets Identification to a 32-bit
identification value for the next packet/parcel/AJ to be sent to this
destination. The source then sets the Parcel Limit, Reserved and O
fields all to 0, and sets the X flag to 1 if it is probing the
"e(X)treme path" for OMNI links (see below). The source finally adds
any padding options necessary for 8-octet alignment and sends the
packet to the next hop.
Each node in the path that observes this specification (including
IPv6 routers and the final destination itself) examines the packet
and processes the Parcel/AJ Probe Option as follows:
Templin Expires 18 August 2024 [Page 28]
Internet-Draft IPv6 Parcels and AJs February 2024
* If Code is 255 and Check contains the same value as the IPv6
header Hop Limit, then set Parcel/AJ Path MTU to the minimum of
its current value, the previous hop link MTU, and the node's own
receive buffer size (but no smaller than the IPv6 minimum MTU
[RFC8200]). Next increment Parcel Limit by 1 and, if the previous
hop link was an OMNI link, set the O flag to 1. Then (for
routers) forward the probe to the next hop while decrementing Hop
Limit by 1 and setting Check to the new Hop Limit value.
* If Code is not 255 or Check contains a different value than the
IPv6 header Hop Limit, then set Residual Path MTU to the minimum
of its current value, the previous hop link MTU, and the node's
own receive buffer size (but no smaller than the IPv6 minimum MTU
[RFC8200]). Then, (for routers) forward the probe to the next hop
while decrementing Hop Limit by 1 and setting Check to 255.
When the destination receives the probe, it performs the above
operations and also sets Residual Path MTU to 0 if Code is 255 and
Check contains the same value as the IPv6 header Hop Limit. The
destination then returns a responsive {TCP,UDP}/IPv6 packet that
includes a Parcel/AJ Probe Reply option as a {TCP,UDP} header option
formatted as shown in Figure 6.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | ExID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel/AJ Path MTU (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Path MTU (16 bits) | Parcel Limit | Reserved |O|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Parcel/AJ Probe Reply {TCP,UDP} Option
The destination sets Kind to 253 for TCP [RFC6994][RFC9293] or 127
for UDP [I-D.ietf-tsvwg-udp-options], then sets Length to 16 and ExID
to TBD1 (see: IANA Considerations). The destination then sets
Parcel/AJ Path MTU, Residual Path MTU, Parcel Limit, Reserved, O, X
and Identification to the values included in the probe, i.e., after
its own local probe processing as discussed above. The destination
then includes any additional identifying parameters (such as
authentication codes) in the {TCP,UDP}/IPv6 packet and returns the
packet to the source while discarding the probe.
The original source can therefore send parcel/AJ probes in the same
packets used to carry real data. The probes will transit all routers
on the forward path possibly extending all the way to the
Templin Expires 18 August 2024 [Page 29]
Internet-Draft IPv6 Parcels and AJs February 2024
destination. If the source receives a probe reply, it authenticates
the message and matches the Identification value with one of its
previous probes. If a match is confirmed, then the Parcel/AJ Probe
Reply option will contain all information necessary for the source to
use in its future parcel/AJ transmissions to this destination.
In particular, the Parcel/AJ Path MTU determines the largest-size
parcel/AJ that can transit the leading portion of the path up to a
point that packetization would be necessary. If the O flag is set
and X is clear, then the maximum-sized AJ is limited to 65535 octets
while parcels as large as the Parcel/AJ Path MTU can be accommodated;
if both the O and X flags are set, then the maximum-sized AJ is also
bounded by the Parcel/AJ Path MTU which may exceed 65535 octets.
If Residual Path MTU is non-zero, its value determines the maximum-
sized packet that can transit the remainder of the path following
packetization noting that the maximum packet size may be smaller
still if there are routers in the probed path that do not recognize
the protocol. (Note that a Residual Path MTU value of 0 instead
indicates that the path is parcel-capable in all hops from the source
to the destination.) Finally, Parcel Limit contains the value the
source must place in the IPv6 Hop Limit field of future parcels/AJ
transmissions to this destination.
All routers and destinations within a controlled environment /
limited domain are expected to forward or accept packets with IPv6
Hop-by-Hop Options extension headers without dropping them, i.e.,
even if they ignore the option contents. Conversely, for open
Internetworks outside of a controlled environment / limited domain
some paths may be unable to transit IPv6 packets that contain Hop-by-
Hop Options extension headers.
Sources that connect to open Internetworks should therefore send
"augmented" probes that include a UDP header inserted between the
IPv6 header and the Hop-by-Hop Options extension header. The source
next rewrites the Hop-by-Hop Options Next Header field per
Section 6.4 of [I-D.templin-intarea-omni] with the "Type" component
set to OMNI-HBH and with the "Next" component set to the value for
the next header that follows (e.g., OMNI-TCP, OMNI-UDP, etc.). Next,
the source sets the IPv6 Next Header field to UDP ("17"), sets the
UDP port numbers to OMNI ("8060"), calculates and sets the UDP
Checksum, then sends the prepared probe to the destination.
Templin Expires 18 August 2024 [Page 30]
Internet-Draft IPv6 Parcels and AJs February 2024
This implies that all routers that recognize parcels/AJs and all
destinations that accept them must be capable of accepting and
processing the contents of these OMNI protocol UDP messages as though
they arrived as ordinary probes. Such routers and destinations must
therefore implement enough of the OMNI interface to be able to
recognize and process the messages.
When there may be one or more OMNI links in the path, the source can
optionally send probes that test and measure the OMNI link "e(X)treme
path" which uses jumbo-in-jumbo encapsulation instead of IP
fragmentation (see: Section 9). In one approach, the source can
first send probes with the X flag set to 0. If the probe reply
returns with the O flag set to 1, and if jumbo-in-jumbo encapsulation
is needed (e.g., to forward very large AJs and parcels at extreme
data rates), the source can next send probes with the X flag set to
1. The source can then remember the MTU and Parcel Limit values for
both types of probes, and can subsequently send smaller parcels/AJs
using the first set of parameters while sending larger parcels/AJs
using the second set of parameters.
All parcels/AJs also serve as implicit probes and may cause a router
in the path to return an ordinary ICMPv6 error [RFC4443] and/or
Packet Too Big (PTB) message [RFC8201] concerning the parcel if the
path changes. If the path changes, a router in the path may also
return a Parcel/Jumbo Report (subject to rate limiting per [RFC4443])
as discussed in Section 7.6.
7.6. Parcel/Jumbo Reports
When the destination returns a Parcel/Jumbo Report, it packages the
report as a {TCP,UDP} option in a {TCP,UDP}/IPv6 packet to return to
the source the same as for a Parcel Probe Reply (see: Figure 6). For
a positive report, the destination may set Parcel/AJ Path MTU and
Residual Path MTU to smaller values that reflect its (reduced)
receive buffer size. For a negative report, the destination instead
sets Parcel Path MTU, Residual MTU and Parcel Limit to 0 as an
indication to the source that the path must be re-probed before
sending additional parcels/AJs.
When a router returns a Parcel/Jumbo Report, it prepares an ICMPv6
PTB message [RFC4443] with Code set to either Parcel Report or Jumbo
Report (see: IANA considerations) and with MTU set to either the
minimum MTU value for a positive report or to 0 for a negative
report. The router then writes its own IPv6 address as the Parcel/
Jumbo Report source and writes the source address of the packet that
invoked the report as the Parcel/Jumbo Report destination.
Templin Expires 18 August 2024 [Page 31]
Internet-Draft IPv6 Parcels and AJs February 2024
The router next copies as much of the leading portion of the invoking
parcel/AJ as possible (beginning with the IPv6 header) into the
"packet in error" field without causing the entire Parcel/Jumbo
Report (beginning with the IPv6 header) to exceed the IPv6 Minimum
MTU. The router then calculates and sets the Checksum field the same
as for an ordinary ICMPv6 message then sends the prepared Parcel/
Jumbo Report to the original source of the probe.
This implies that original sources that send parcels/AJs must be
capable of accepting and processing Parcel/Jumbo reports (formatted
as above) with coming from either a router or the final destination.
Note: For positive Parcel/Jumbo reports, the source can continue
sending parcels/AJs into the path with its segment sizes reduced
accordingly. For negative Parcel/Jumbo reports, the source should
instead re-probe the path before sending additional parcels/AJs.
8. Advanced Jumbos (AJ)
This specification introduces an IPv6 Advanced Jumbo (AJ) service as
a (single-segment) parcel alternative to basic jumbograms. The
function employs an Advanced Jumbo Option with the same IPv6 Hop-by-
Hop option Type and same basic format as for the Parcel Payload
option.
When the source prepares an AJ it sets Opt Data Len to 12 and
includes the Parcel/AJ Format and Index fields the same as for the
Parcel Payload option, but replaces the 4-octet Parcel Payload Length
field (plus preamble) by a single 4-octet Jumbo Payload Length field
as shown in Figure 7:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Check | Parcel/AJ Format (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Advanced Jumbo Hop-by-Hop Option
The source forms {TCP/UDP}/IPv6 AJs by setting the most significant
octet of the Parcel/AJ Format field to 0 and treating the least
significant octet of the field as an "Advanced Jumbo (AJ) Format"
octet as shown in Figure 8:
Templin Expires 18 August 2024 [Page 32]
Internet-Draft IPv6 Parcels and AJs February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |D|X|FEC| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<-- AJ Format -->
Figure 8: Parcel/AJ Format for Advanced Jumbos
In the AJ Format octet, the source sets "D" to 0 for the classic link
model or 1 for the DTN link model and sets "X" to 0 for classic OMNI
link traversal or 1 for "e(X)treme path" traversal. The source then
sets "Type" to one of the CRC/digest types found in Figure 9 and sets
"FEC" to 0 (future specifications may define new values, e.g., for
Forward Error Correction (FEC) parameters, etc.). Implementations
MUST support the following integrity checking algorithms identified
by "Type":
Type Algorithm CRC/digest Length
---- --------- -----------------
0 NULL 0 octets
1 CRC32C 4 octets
2 CRC64E 8 octets
3 MD5 16 octets
4 SHA1 20 octets
5 SHA-224 28 octets
6 SHA-256 32 octets
7 SHA-384 48 octets
8 SHA-512 64 octets
Figure 9: Mandatory Advanced Jumbo CRC/Digest Algorithms
The source then forms {TCP/UDP}/IPv6 AJs the same as for parcels as
shown in Figure 2 except that it includes only a single segment
("Segment 0"). For all Types other than 0, the source then includes
a 2-octet Checksum header and an N-octet CRC/digest trailer for the
segment according to Figure 9. Unlike parcels, TCP AJs do not
include a separate Sequence Number header for the (single) segment
since the sequence number is coded in the TCP header the same as for
an ordinary packet. UDP AJs set the UDP Length field the same as
specified for UDP parcels.
AJs that include a message digest employ the algorithms specified for
MD5 [RFC1321], SHA1 [RFC3174] and the advanced US Secure Hash
Algorithms [RFC6234] according the to AJ Type. AJs can instead
employ a CRC32C/CRC64E integrity check by selecting a Type value with
a CRC code instead of a message digest. (A Type value is also
reserved by IANA as a non-functional placeholder for a nominal
CRC128J algorithm, which may be specified in future documents - see:
Appendix C.)
Templin Expires 18 August 2024 [Page 33]
Internet-Draft IPv6 Parcels and AJs February 2024
When the source prepares an AJ, it sets the Identification the same
as for a parcel, sets Code to 255 and sets Check and Hop Limit to the
Parcel Limit for this destination (see: Section 7.5). The source
then calculates the {TCP,UDP} Checksum based on the same pseudo
header as for an ordinary parcel (see: Figure 11) but with the
4-octet Parcel Payload Length (plus preamble) fields replaced with a
4-octet Jumbo Payload Length field and with Parcel/AJ Format encoding
the AJ Format Octet - see above.
The source calculates the header checksum only and writes the value
into the {TCP,UDP} header checksum field the same as specified for
parcels. For all AJ Types other than 0, the source then calculates
the checksum of the segment payload, writes the value into the
segment Checksum header, then calculates the CRC/digest over the
length of the (single) segment beginning with the Checksum field and
writes the value into the trailer. The source then sends the AJ via
the next hop link toward the final destination.
At each forwarding hop, the router examines Code and Check then drops
the AJ and returns a negative Jumbo Report if either value is
incorrect. (Note that the AJ may also have been truncated in length
by a previous-hop router that does not recognize the construct.) For
all other intact AJs, if decrementing would cause the Hop Limit to
become 0 the router performs packetization to convert the AJ into a
packet the same as specified for parcels (see: Section 7.1) and
forwards the packet to the next hop; otherwise, the router decrements
both Hop Limit and Check by 1 and forwards the intact AJ to the next
hop.
Note: If the original source selects the "e(X)treme path" for OMNI
link traversal, the OMNI interface forwards the intact AJ as a
carrier packet using jumbo-in-jumbo encapsulation instead of applying
adaptation layer IP fragmentation. These jumbo carrier packets are
then subject to best-effort delivery over the (previously-probed)
path. The original source may select "e(X)treme" for any parcel/AJ,
but must select "e(X)treme" for all AJs larger than 65535 octets -
see: Section 9.
9. OMNI Interface Jumbo-in-Jumbo Encapsulation
OMNI interfaces can process parcels of all sizes as well as AJs as
large as 65535 octets according to normal OMNI link parcellation,
encapsulation and fragmentation procedures. For larger AJs as well
as for parcels that may experience better performance by avoiding
parcellation and fragmentation, the original source can instead
select OMNI link "e(X)treme path" traversal. For probes/parcels/AJs
that select the "e(X)treme path", the source sends the probe/parcel/
AJ via the first-hop link under standard procedures specified in
Templin Expires 18 August 2024 [Page 34]
Internet-Draft IPv6 Parcels and AJs February 2024
previous sections with standard IP forwarding providing service for
each successive link up to the OMNI link ingress. When the
probe/parcel/AJ arrives at the OMNI link ingress, the X flag provides
an indication that "e(X)treme path" OMNI link traversal is desired as
follows.
For parcel/AJ probes, the OMNI link ingress first verifies that all
previous hops were jumbo-capable by examining the Code and Check
values. If Code or Check are incorrect, the OMNI link ingress clears
the X flag and forwards the probe using normal OMNI encapsulation.
If Code and Check are both correct, the OMNI link ingress instead
inserts the OMNI and L2 encapsulations as specified in
[I-D.templin-intarea-omni] then performs "jumbo-in-jumbo"
encapsulation by copying the (L3) Parcel/AJ Probe option Hop-by-Hop
extension header from the original IPv6 probe packet into the L2
headers as shown in Figure 10. The OMNI link ingress then calculates
the UDP checksum over the entire length of the encapsulated probe (as
the UDP payload) and writes the value into the L2 UDP checksum field.
Each L2 forwarding hop in the path to the next OAL intermediate node
will then process the probe exactly as specified in Section 7.5,
where each parcel/AJ capable hop adjusts the Code, Check, Parcel/AJ
Path MTU and Parcel Limit fields then re-calculates/re-sets the L2
UDP checksum.
Templin Expires 18 August 2024 [Page 35]
Internet-Draft IPv6 Parcels and AJs February 2024
Jumbo-in-Jumbo Parcel/AJ Probe Jumbo-in-Jumbo Parcel/AJ
+------------------------------+ +------------------------------+
| | | |
~ L2 IPv6 Hdr ~ ~ L2 IPv6 Hdr ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L2 UDP header ~ ~ L2 UDP header ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L2 Parcel/AJ Probe ~ ~ L2 Advanced Jumbo Type 0 ~
| HBH option | | HBH option |
+------------------------------+ +------------------------------+
| | | |
~ OMNI IPv6 Header ~ ~ OMNI IPv6 Header ~
| plus extensions | | plus extensions |
+------------------------------+ +------------------------------+
| | | |
~ L3 IPv6 Hdr ~ ~ L3 IPv6 Hdr ~
| | | |
+------------------------------+ +------------------------------+
| | | |
~ L3 Parcel/AJ Probe ~ ~ L3 Parcel/AJ ~
| HBH option | | HBH option |
+------------------------------+ +------------------------------+
| | | |
~ {TCP,UDP} header and ~ ~ {TCP,UDP} header and ~
~ packet body ~ ~ parcel/AJ body ~
| | | |
+------------------------------+ +------------------------------+
Figure 10: Jumbo-in-Jumbo Encapsulation
When each successive OAL intermediate node receives the parcel probe,
it propagates the Parcel/AJ Probe option Hop-by-Hop extension header
into the L2 headers for the next OAL hop while updating the probe
parameters the same as for an ordinary IP forwarding hop. When the
OAL destination receives the parcel/AJ probe, it first verifies that
all previous hops were jumbo-capable by examining the Code and Check
values. If Code or Check are incorrect, the OAL destination drops
the probe and returns a negative Jumbo Report to the OAL source,
which then returns a negative Jumbo Report to the original source.
Otherwise, the OAL destination removes the L2 and OAL headers while
copying the L2 probe parameters into the L3 Parcel/AJ Probe option
(with the L2 encapsulation header lengths subtracted from the Parcel/
AJ Path MTU).
Templin Expires 18 August 2024 [Page 36]
Internet-Draft IPv6 Parcels and AJs February 2024
The OAL destination then forwards the probe to the next hop toward
the final destination. If the probe traverses the entire path to the
final destination, the Parcel/AJ Path MTU will contain the minimum
MTU and the Parcel Limit will contain the total number of parcel/AJ-
capable L2/L3 hops between the source and destination. (Note that
the Residual Path MTU may also indicate that the final portion of the
path is not parcel/AJ capable even though the leading portion of the
path was.) The destination will then return a probe reply to the
source, and if the X flag is set the source can begin sending
parcels/AJs with the X flag set to enable the OMNI link "e(X)treme
path".
If the source receives an intact probe reply with X flag set, it can
use the enclosed Parcel/AJ Path MTU, Residual Path MTU and Parcel
Limit values to prepare future parcels/AJs for transmission via the
"e(X)treme path" by setting the X flag. Each L3 forwarding hop in
the path from the original source to the OMNI link ingress then
forwards the parcel/AJ the same as for the standard procedures
specified in previous sections.
When the OMNI link ingress receives a parcel/AJ with the X flag set,
it performs "jumbo-in-jumbo encapsulation" by leaving the L3 parcel/
AJ headers intact, then appending OMNI adaptation layer IPv6
encapsulations plus L2 encapsulations that include an Advanced Jumbo
Type 1 option (but without including a segment checksum field as for
{TCP,UDP} AJs) in either a full or minimal AJ extension header as an
L2 extension. The OMNI link ingress sets the Jumbo Payload Length
field to the length of the L2 extension headers (including the L2 UDP
header, if present) plus the lengths of the OMNI IPv6 encapsulation
header and the L3 packet (including all L3 headers). The OMNI link
ingress sets all other OMNI and L2 encapsulation header fields as
specified in [I-D.templin-intarea-omni]. The parcel/AJ "jumbo-in-
jumbo" encapsulation format is shown in Figure 10.
Templin Expires 18 August 2024 [Page 37]
Internet-Draft IPv6 Parcels and AJs February 2024
The OMNI link ingress then calculates the L2 UDP checksum over the L2
UDP/IP pseudo-header and extending to cover the OMNI adaptation
layers up to but not including the L3 IP header, then writes the
value into the L2 UDP header checksum field. The OMNI link ingress
then copies the L3 TTL/Hop Limit into the L2 IP header TTL/Hop Limit
and forwards the encapsulated parcel/AJ to the next L2 hop. When the
parcel/AJ arrives at an OAL intermediate node, the node discards the
L2 headers from the previous hop OMNI segment and inserts L2 headers
for the next hop OMNI segment while updating the OMNI encapsulation
header fields accordingly (see: [I-D.templin-intarea-omni]). In the
process, the OAL intermediate node decrements the previous L2 hop
TTL/Hop Limit and writes this value into the next L2 hop IP header
while also transferring the previous hop Advanced Jumbo Type 1 header
to the next hop L2 header chain. The node also re-calculates and re-
sets the L2 UDP header checksum before forwarding toward the next
OMNI hop.
When the parcel/AJ arrives at the OAL destination, the OAL
destination copies the L2 IP TTL/Hop Limit into the L3 IP TTL/Hop
Limit field, then removes the L2 and OMNI encapsulation headers and
forwards the packet to the next L3 hop while decrementing the IP TTL/
Hop Limit by 1 according to standard IP forwarding rules. The final
destination will then receive the intact original parcel/jumbo.
While a probe/parcel/AJ is traversing an OMNI link "e(X)treme path",
it may encounter an L2 link that does not recognize the construct.
This may cause a subsequent link to detect a formatting error and
return a negative Jumbo Report that will be returned to a previous
hop OAL intermediate node or the OAL source. The OAL node that
receives the (L2) Jumbo Report must then prepare and generate an (L3)
Jumbo Report to return to the original source. The L3 Jumbo Report
contains the leading portion of the L3 probe/parcel/AJ with the L2
and OMNI headers removed. This will provide indication to the
original source that the OMNI link "e(X)treme path" has failed for
this particular transmission.
Note: If an OMNI link ingress receives an "e(X)treme path" probe with
an incorrect Code or Check, it clears the X flag and forwards the
probe as an ordinary IP packet using standard OMNI encapsulation and
fragmentation since a previous L3 hop was determined to be jumbo-
incapable yet may be able to perform packetization. This is true
even if there may be multiple OMNI links in the L3 path, where the X
flag applies to all OMNI links in the series and not just the first.
Note: The L2 UDP checksum extends over the entire length of each
jumbo-in-jumbo encapsulated parcel/AJ probe, but only over the L2 and
OMNI headers for each jumbo-in-jumbo encapsulated parcel/AJ following
probing. This is due to the fact that the source must disguise the
Templin Expires 18 August 2024 [Page 38]
Internet-Draft IPv6 Parcels and AJs February 2024
probe as an ordinary IP packet while probing is in progress; after
probing has converged, subsequent parcels/AJs only require an
integrity check of the headers.
Note: The D flag has the same effect for jumbo-in-jumbo encapsulated
parcels/AJs as for ordinary parcels/AJs. Namely, if the D flag is
set and a link in the L2 path detects an error, it sets the CRC error
flag and forwards the (errored) jumbo-in-jumbo parcel/AJ as long as
the L2/OMNI header checksum is correct.
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. In the DTN link model, intermediate system lower
layers forward parcels/AJs with correct headers to the final
destination transport layer even if cumulative link errors were
incurred at intermediate hops. The destination is then ultimately
responsible for its own integrity assurance.
The {TCP,UDP}/IPv6 header plus each segment of a parcel/AJ includes
its own integrity checks. In the DTN link model, the {TCP,UDP}
Checksum header integrity check SHOULD be verified by each hop for
which a link error is encountered to ensure that parcels/AJs with
errored addressing information are detected. The per-segment
Checksums/CRCs are set by the source and verified by the destination.
Note that both checks are important (when no other integrity checks
are present) since there will be many instances when errors missed by
the CRC are detected by the Checksum [STONE].
IPv6 parcels can range in length from as small as only the
{TCP,UDP}/IPv6 headers plus a single segment to as large as the
headers plus (64 * 65535) octets, while AJs include only a single
segment that can be as small as a null segment to as large as 2**32
octets (minus headers). Due to parcellation/packetization in the
path, the segment contents of a received parcel may arrive in an
incomplete and/or rearranged order with respect to their original
packaging.
Templin Expires 18 August 2024 [Page 39]
Internet-Draft IPv6 Parcels and AJs February 2024
IPv6 parcels and AJs include a separate 2-octet Internet Checksum
header for each segment noting that the per-segment Checksum value 0
indicates that the segment checksum is disabled. The original source
calculates the checksum for each segment beginning with the first
octet of the per-segment Sequence Number (for TCP) then continuing
with the first segment octet and extending over the entire segment
length up to but not including the integrity check trailer (if
present).
IPv6 parcels with C=1 use one of two different CRC types according to
the non-final segment length "L". For values of L smaller than 9216
octets (9KB), the original source uses the CRC32C specification
[RFC3385] and encodes the CRC in a 4 octet trailer. For larger L
values, the source uses the CRC64E specification [ECMA-182] and
encodes the CRC in an 8 octet trailer. AJs that set an Advanced
Jumbo Type other than NULL instead include either a 4/8 octet CRC or
an N-octet message digest trailer calculated per [RFC1321], [RFC3174]
or [RFC6234] according to the hash algorithm assigned to Type.
Under the DTN link model, when the network layer of the link far end
detects a link error it SHOULD verify the parcel/AJ {TCP,UDP}/IPv6
header Checksum at its layer, since an errored header could result in
mis-delivery. If the network layer of the link far end detects an
incorrect {TCP,UDP}/IP header Checksum it should discard the entire
parcel/AJ unless the header(s) can somehow first be repaired. If the
{TCP,UDP}/IPv6 header Checksum was correct, but the link far end
detected CRC errors, the network layer sets a "CRC error" flag in the
parcel/AJ option.
The CRC error flag entails clearing/setting the IPv6 Hop-by-Hop
option Type third-highest-order bit as "0 - Option does not change en
route or "1 - Option Data may change en route" or [RFC8200].
Therefore, nodes must recognize the Option Type '0x10' as "IPv6
Parcel/AJ with errors' and Option Type '0xE2' as "Minimal IPv6
Parcel/AJ with errors" (see: IANA Considerations).
To support the parcel/AJ header checksum calculation, the network
layer uses a modified version of the {TCP,UDP}/IPv6 pseudo-header
found in Section 8.1 of [RFC8200] as shown in Figure 11. This allows
for maximum reuse of widely deployed code while ensuring
interoperability.
Templin Expires 18 August 2024 [Page 40]
Internet-Draft IPv6 Parcels and AJs February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Source Address (16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Destination Address (16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel/Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parcel/AJ Format | zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: {TCP,UDP}/IPv6 Parcel/AJ Pseudo-Header Formats
where the following fields appear:
* Source Address is the 16-octet IPv6 source address of the prepared
parcel/AJ.
* Destination Address is the 16-octet IPv6 destination address of
the prepared parcel/AJ.
* For parcels, the 4-octets of the Parcel/Jumbo Payload Length
encode the Index/C/S/D/X preamble and 22-bit Parcel Payload Length
as they appear in the Parcel Payload Option fields of the same
name. For AJs, the Parcel/Jumbo Payload Length encodes the
4-octet Jumbo Payload Length value found in the Jumbo Payload
Option.
* Parcel/Jumbo Format is the value that appears in the Parcel/Jumbo
Option header.
* zero encodes the constant value 0.
* Next Header is the IP protocol number corresponding to the
transport layer protocol, i.e., TCP or UDP.
When the transport layer protocol entity of the source delivers a
parcel body to the network layer, it presents the values L and J
along with the (J + 1) segments in canonical order as a list of data
buffers and with each TCP segment preceded by a 4-octet Sequence
Number field. (For AJs, the transport layer instead delivers the
singleton AJ segment along with the Jumbo Payload Length.) When the
network layer of the source accepts the parcel/AJ body from the
transport layer protocol entity, it calculates the Internet checksum
for each segment and writes the value in the per-segment Checksum
header (or writes the value 0 when UDP checksums are disabled).
Templin Expires 18 August 2024 [Page 41]
Internet-Draft IPv6 Parcels and AJs February 2024
For parcels/AJs that include trailing integrity checks, the network
layer then calculates the CRC/digest for each segment beginning with
the Checksum field and inserts the result as a segment trailer in
network byte order. The network layer then concatenates all segments
and appends the necessary {TCP,UDP}/IPv6 headers and extensions to
form a parcel. The network layer then calculates the {TCP,UDP}/IPv6
header checksum over the length of only the {TCP,UDP} headers plus
IPv6 pseudo header then forwards the parcel to the next hop without
further processing.
When the network layer of the destination accepts an AJ or reunifies
a parcel from one or more sub-parcels received from the source it
first verifies the {TCP,UDP}/IPv6 header checksum then for each
segment verifies the CRC/digest (if present) followed by the Checksum
(except when UDP checksums are disabled) and marks any segments with
incorrect integrity check values as errors.
When the network layer restores a parcel from one or more individual
{TCP,UDP}/IPv6 packets received from the source, it instead marks the
CRCs of each segment as correct since the individual packets were
subject to CRC checks at each hop along the path. The network layer
then verifies the Internet checksum of each individual packet (except
when UDP checksums are disabled), restores the parcel, and delivers
each parcel/AJ segment along with a CRC/Checksum error flag to the
transport layer.
When the transport layer of the destination processes parcel or AJ
segments, it can accept any with correct CRCs/Checksums while
optionally applying additional higher-layer integrity checks. The
transport layer can instead process any segments with incorrect CRC/
Checksum by either discarding the entire segment or applying higher-
layer integrity checks on the component elements of the segment to
accept as many non-errored elements as possible. The transport layer
can then either reconstruct from local information or request
retransmission for any segment elements that may have been damaged in
transit as necessary.
Note: Under the DTN link model, when the destination's network layer
receives a parcel with an IPv6 Option Type with third-highest-order
bit set/cleared to indicate that a link CRC error was detected, it
still engages its per-segment integrity checks to accept as many
error-free segments as possible. When the destination receives an AJ
with CRC errors, it need not engage its (single segment) integrity
checks since the segment is already known to include link errors.
Note: Under the DTN link model, when the destination network layer
detects a per-segment CRC error it immediately posts the segment plus
an error code for delivery to the transport instead of continuing to
Templin Expires 18 August 2024 [Page 42]
Internet-Draft IPv6 Parcels and AJs February 2024
verify the segment Checksum. Performing a second integrity check on
a segment already determined to contain errors by a first check would
serve no useful purpose.
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.
12. IANA Considerations
The IANA is instructed to add a reference to this document
([RFCXXXX]) in the "Jumbo Payload" and "Minimum Path MTU Hop-by-Hop
Option" entries in the "Destination Options and Hop-by-Hop Options"
table of the 'ipv6-parameters' registry.
The IANA is instructed to assign new Code values in the "ICMPv6 Code
Fields: Type 2 - Packet Too Big" table in the 'icmpv6-parameters'
registry (registration procedure is Standards Action or IESG
Approval). The registry entries should appear as follows:
Templin Expires 18 August 2024 [Page 43]
Internet-Draft IPv6 Parcels and AJs February 2024
Code Name Reference
--- ---- ---------
3 (suggested) Parcel Report [RFCXXXX]
4 (suggested) Jumbo Report [RFCXXXX]
Figure 12: ICMPv6 Code Fields: Type 2 - Packet Too Big Values
The IANA is requested to assign two new entries in the
'ipv6-parameters' registry "Destination Options and Hop-by-Hop
Options" table (registration procedures IESG Approval, IETF Review or
Standards Action). The first entry sets "Hex Value" to '0xE2',
"acct" to '11', "chg" to '1', "rest" to '00010' and Description to
"Minimal Parcel/AJ With Errors". The second entry sets "Hex Value"
to '0x10', "acct" to '00', "chg" to '0', "rest" to '10000' and
Description to "Parcel/AJ With Errors". Both entries set "Reference"
to this document [RFCXXXX].
The IANA is instructed to assign a new entry in the "TCP Experimental
Option Experiment Identifiers (TCP ExIDs)" table of the 'tcp-
parameters' registry (registration procedures First Come First Served
per [RFC6994]). The table entry should set "Value" to TBD1,
"Description" to "Parcel Parameters" and "Reference" to this document
[draft-templin-6man-parcels]. The IANA is also instructed to assign
the same value TBD1 as an entry in the to-be-created "UDP
Experimental Option Experiment Identifiers (UDP ExIDs)" table
(registration procedures First Come First served per
[I-D.ietf-tsvwg-udp-options]). This document places no preferences
on the actual TBD1 value assignment.
Finally, the IANA is instructed to create and maintain a new registry
titled "IPv6 Parcel and Advanced Jumbo Formats and Types" as follows:
For IPv6 parcels and Advanced Jumbos, the value in the 'Opt Data Len'
field of the IPv6 Minimum Path MTU Hop-by-Hop Option [RFC9268] serves
as an "Option Format" code that distinguishes the various IPv6 option
formats specified in this document. Initial values are given below:
Value Option Format Reference
----- ------------- ---------
0-3 Unassigned [RFCXXXX]
4 IPv6 Minimum Path MTU [RFC9268]
5-11 Unassigned [RFCXXXX]
12 Parcel/Advanced Jumbo [RFCXXXX]
13 Unassigned [RFCXXXX]
14 Parcel/AJ Probe [RFCXXXX]
15-253 Unassigned [RFCXXXX]
254 Reserved for Experimentation [RFCXXXX]
255 Reserved by IANA [RFCXXXX]
Templin Expires 18 August 2024 [Page 44]
Internet-Draft IPv6 Parcels and AJs February 2024
Figure 13: IPv6 Parcel/Jumbo Option Formats
For IPv6 Advanced Jumbos, when the most significant octet of the
Parcel/AJ Format field encodes the value 0 the least significant 4
bits of the field encode an "Advanced Jumbo Type" value. The IANA is
therefore instructed to establish an "IPv6 Advanced Jumbo Types"
registry with the initial values given below:
Value Jumbo Type Reference
----- ---------- ---------
0 Advanced Jumbo / NULL [RFCXXXX]
1 Advanced Jumbo / CRC32C [RFCXXXX]
2 Advanced Jumbo / CRC64E [RFCXXXX]
3 Advanced Jumbo / MD5 [RFCXXXX]
4 Advanced Jumbo / SHA1 [RFCXXXX]
5 Advanced Jumbo / SHA-224 [RFCXXXX]
6 Advanced Jumbo / SHA-256 [RFCXXXX]
7 Advanced Jumbo / SHA-384 [RFCXXXX]
8 Advanced Jumbo / SHA-512 [RFCXXXX]
9 Advanced Jumbo / CRC128J [RFCXXXX]
10-15 Unassigned [RFCXXXX]
Figure 14: IPv6 Advanced Jumbo Types
13. Security Considerations
In the control plane, original sources match the Identification (and/
or other identifying information) received in Parcel/Jumbo Reports
with their earlier parcel/AJ transmissions. If the identifying
information matches, the report is likely authentic. When stronger
authentication is needed, nodes that send Parcel/Jumbo Reports can
apply the message authentication services specified for AERO/OMNI.
For nodes that include {TCP,UDP} Parcel Parameter options in ordinary
data packets, however, the authenticating services that apply to the
data packets also authenticate the options.
In the data plane, multi-layer security solutions may be needed to
ensure confidentiality, integrity and availability. According to
[RFC8200], a full IPv6 implementation includes the Authentication
Header (AH) [RFC4302] and Encapsulating Security Payload (ESP)
[RFC4303] per the IPsec architecture [RFC4301] to support
authentication, data integrity and (optional) data confidentiality.
These AH/ESP services provide comprehensive integrity checking for
parcel/AJ upper layer protocol headers and all upper layer protocol
payload that follows. Since the network layer does not manipulate
transport layer segments, parcels/AJs do not interfere with transport
or higher-layer security services such as (D)TLS/SSL [RFC8446] which
may provide greater flexibility in some environments.
Templin Expires 18 August 2024 [Page 45]
Internet-Draft IPv6 Parcels and AJs February 2024
IPv4 fragment reassembly is considered dangerous at high data rates
where undetected reassembly buffer corruptions can result from
fragment misassociations [RFC4963]. IPv6 is less subject to these
concerns when the 32-bit Identification field is managed responsibly.
IPv6 Parcels and AJs are not subject to fragmentation unless exposed
to OMNI interface encapsulation which includes a 64-bit
Identification space.
For IPv6 parcels and AJs that engage the DTN link model, the
destination end system is uniquely positioned to verify and/or
correct the integrity of any transport layer segments received. For
this reason, transport layer protocols that use parcels/AJs should
include higher layer integrity checks and/or forward error correction
codes in addition to the per-segment link error integrity checks.
The CRC/digest trailers included with parcels/AJs that engage the DTN
link model provide integrity checks only and must not be considered
as authentication codes in the absence of additional security
services. Further security considerations related to IPv6 parcels
and Advanced Jumbos are found in the AERO/OMNI specifications.
14. Acknowledgements
This work was inspired by ongoing AERO/OMNI/DTN investigations. The
concepts were further motivated through discussions with colleagues.
A considerable body of work over recent years has produced useful
segmentation offload facilities available in widely-deployed
implementations.
With the advent of networked storage, big data, streaming media and
other high data rate uses the early days of Internetworking have
evolved to accommodate the need for improved performance. The need
fostered a concerted effort in the industry to pursue performance
optimizations at all layers that continues in the modern era. All
who supported and continue to support advances in Internetworking
performance are acknowledged.
This work has been presented at working group sessions of the
Internet Engineering Task Force (IETF). The following individuals
are acknowledged for their contributions: Roland Bless, Scott
Burleigh, Madhuri Madhava Badgandi, Joel Halpern, Tom Herbert, Andy
Malis, Herbie Robinson, Bhargava Raman Sai Prakash.
Honoring life, liberty and the pursuit of happiness.
15. References
Templin Expires 18 August 2024 [Page 46]
Internet-Draft IPv6 Parcels and AJs February 2024
15.1. Normative References
[I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-28,
17 November 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-28>.
[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 18 August 2024 [Page 47]
Internet-Draft IPv6 Parcels and AJs February 2024
[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-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
Templin Expires 18 August 2024 [Page 48]
Internet-Draft IPv6 Parcels and AJs February 2024
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-12, 21 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-12>.
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Fragmentation", Work in Progress,
Internet-Draft, draft-templin-dtn-ltpfrag-16, 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-
templin-dtn-ltpfrag-16>.
[I-D.templin-intarea-aero]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
intarea-aero-66, 12 February 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-aero-66>.
[I-D.templin-intarea-omni]
Templin, F., "Transmission of IP Packets over Overlay
Multilink Network (OMNI) Interfaces", Work in Progress,
Internet-Draft, draft-templin-intarea-omni-66, 12 February
2024, <https://datatracker.ietf.org/doc/html/draft-
templin-intarea-omni-66>.
[QUIC] Ghedini, A., "Accelerating UDP packet transmission for
QUIC, https://blog.cloudflare.com/accelerating-udp-packet-
transmission-for-quic/", 8 January 2020.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>.
[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
"Internet Protocol Small Computer System Interface (iSCSI)
Cyclic Redundancy Check (CRC)/Checksum Considerations",
RFC 3385, DOI 10.17487/RFC3385, September 2002,
<https://www.rfc-editor.org/info/rfc3385>.
Templin Expires 18 August 2024 [Page 49]
Internet-Draft IPv6 Parcels and AJs February 2024
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
DOI 10.17487/RFC5326, September 2008,
<https://www.rfc-editor.org/info/rfc5326>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>.
[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>.
Templin Expires 18 August 2024 [Page 50]
Internet-Draft IPv6 Parcels and AJs February 2024
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[STONE] Stone, J. and C. Partridge, "When the CRC and TCP Checksum
Disagree, ACM SIGCOMM Computer Communication Review,
Volume 30, Issue 4, October 2000, pp. 309-319,
https://doi.org/10.1145/347057.347561", October 2000.
Appendix A. TCP Extensions for High Performance
TCP Extensions for High Performance are specified in [RFC7323], which
updates earlier work that began in the late 1980's and early 1990's.
These efforts determined that the TCP 16-bit Window was too small to
sustain transmissions at high data rates, and a TCP Window Scale
option allowing window sizes up to 2^30 was specified. The work also
defined a Timestamp option used for round-trip time measurements and
as a Protection Against Wrapped Sequences (PAWS) at high data rates.
TCP users of IPv6 parcels/AJs are strongly encouraged to adopt these
mechanisms.
Since TCP/IPv6 parcels only include control bits for the first
segment ("segment(0)"), nodes must regard all other segments of the
same parcel as data segments. When a node breaks a TCP/IPv6 parcel
out into individual packets or sub-parcels, only the first packet or
sub-parcel contains the original segment(0) and therefore only its
TCP header retains the control bit settings from the original parcel
TCP header. If the original TCP header included TCP options such as
Maximum Segment Size (MSS), Window Scale (WS) and/or Timestamp, the
node copies those same options into the options section of the new
TCP header.
For all other packets/sub-parcels, the note sets all TCP header
control bits to 0 as data segment(s). Then, if the original parcel
contained a Timestamp option, the node copies the Timestamp option
into the options section of the new TCP header. Appendix A of
[RFC7323] provides implementation guidelines for the Timestamp option
layout.
Templin Expires 18 August 2024 [Page 51]
Internet-Draft IPv6 Parcels and AJs February 2024
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].
Appendix B. Extreme L Value Implications
For each parcel, the transport layer can specify any L value between
256 and 65535 octets. Transport protocols that send isolated control
and/or data segments smaller than 256 octets should package them as
ordinary packets, AJs, singleton parcels or as the final segment of a
larger parcel. It is also important to note that segments smaller
than 256 octets are likely to include control information for which
timely delivery rather than bulk packaging is desired. Transport
protocol streams therefore often include a mix of (larger) parcels
and (smaller) ordinary packets, AJs or singleton parcels.
The transport layer should also specify an L value no larger than can
accommodate the maximum-sized transport and network layer headers
that the source will include without causing a single segment plus
headers to exceed 65535 octets. For example, if the source will
include a 28 octet TCP header plus a 40 octet IPv6 header with 24
extension header octets (plus 6/10 octets for the per-segment
Checksum/CRC) the transport should specify an L value no larger than
(65535 - 28 - 40 - 24 - 10) = 65433 octets.
The transport can specify still larger "extreme" L values up to 65535
octets, but the resulting parcels might be lost along some paths with
unpredictable results. For example, a parcel with an extreme L value
set as large as 65535 might be able to transit paths that can pass
large parcels/AJs natively but might not be able to transit a path
that includes conventional links. The transport layer should
therefore carefully consider the benefits of constructing parcels
with extreme L values larger than the recommended maximum due to high
risk of loss compared with only minor potential performance benefits.
Templin Expires 18 August 2024 [Page 52]
Internet-Draft IPv6 Parcels and AJs February 2024
Finally, the transport layer must not set "extreme" L values that
would cause the Parcel Payload Length to exceed (2**22 - 1) octets,
since the resulting malformed parcel could not be properly processed.
Appendix C. Advanced Jumbo Cyclic Redundancy Check (CRC128J)
This section postulates a 128-bit Cyclic Redundancy Check (CRC)
algorithm for AJs termed "CRC128J". An Advanced Jumbo Type value is
reserved for CRC128J, but at the time of this writing no algorithm
exists. Future specifications may update this document and provide
an algorithm for handling Advanced Jumbos with Type CRC128J.
Appendix D. Change Log
<< RFC Editor - remove prior to publication >>
Changes from earlier versions:
* Submit for review.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Templin Expires 18 August 2024 [Page 53]
