IPv6 Fragment Retransmission
and Path MTU Discovery Soft ErrorsBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftInternet Protocol version 6 (IPv6) provides a fragmentation and
reassembly service for end systems allowing for the transmission of
packets that exceed the path MTU. However, loss of individual fragments
requires retransmission of original packets in their entirety leading to
cascading reassembly failures. This document specifies an IPv6 fragment
retransmission scheme that matches the loss unit to the retransmission
unit. The document further specifies an update to Path MTU Discovery
that distinguishes hard link size restrictions from reassembly
congestion events.Internet Protocol version 6 (IPv6) provides
a fragmentation and reassembly service similar to that found in IPv4
, with the exception that only the source host
(i.e., and not routers on the path) may perform fragmentation. When an
IPv6 packet is fragmented, the loss unit (i.e., a single IPv6 fragment)
becomes smaller than the retransmission unit (i.e., the entire packet)
which even under moderate loss conditions could result in cascading
reassembly failures that degrade forward progress .The presumed drawbacks of fragmentation are tempered by the fact that
performance increases can often be realized when the source sends
packets larger than the path MTU. This is due to the fact that larger
packets result in fewer application system calls, plus transmission of a
single large packet results in a burst of multiple IPv6 fragments
separated by minimal inter-packet delays. These bursts yield high
network utilization for the burst duration, while modern reassembly
implementations have proven capable of accommodating the bursts. If the
loss unit can somehow be made to match the retransmission unit, the
performance benefits of IPv6 fragmentation can be realized.This document therefore proposes an IPv6 fragment retransmission
service where the source marks fragments as retransmission-eligible
while the destination may request retransmission of lost fragments. The
service provides opportunistic best-effort retransmissions over an
imaginary "link" extending from the source to the destination consistent
with the Automatic Repeat Request (ARQ) function of common data links
. The service does not attempt to replace true
end-to-end reliability, but instead often allows the destination to
recover missing individual fragments of partial reassemblies before true
end-to-end timers would cause retransmission of the entire packet.The original packet source may be either co-located with or many IP
network hops before the IPv6 fragmentation source. In the same fashion,
the IPv6 reassembly destination may be either co-located with or many IP
network hops before the final destination. When conditions suggest that
an original source should begin sending smaller packets, the
fragmentation source and/or reassembly destination can return a new type
of ICMPv6/ICMPv4 Packet Too Big (PTB) message termed a PTB "soft
error".PTB "soft errors" are distinguished from classic "hard errors" by a
non-zero PTB Code (ICMPv6) or unused (ICMPv4) field value. The
fragmentation source can return rate-limited soft errors to recommend
smaller packet sizes to the original source while fragmentation of large
packets is producing excessive numbers of fragments. Similarly, the
reassembly destination can return rate-limited soft errors (i.e., via
the fragmentation source to the original source) while reassembly of
large packets is causing excessive reassembly congestion. Original
sources that receive these soft errors should reduce their packet sizes
until the errors subside, but can begin to increase packet sizes again
without delay until further soft or hard errors arrive.The following sections discuss common use cases and operational
considerations for applying IPv6 fragment retransmission and path MTU
discovery soft errors. They further specify new codings for the IPv6
fragment header Reserved field, a new ICMPv6 message type and updates to
ICMPv6/ICMPv4 PTB messages. This document therefore updates existing
standards where necessary.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.A common use case of interest is to improve the state of affairs for
IPv6 encapsulation (i.e., "tunneling") when the
original source may be many IP hops away from the tunnel ingress, and
the tunnel packet may be fragmented following encapsulation. The tunnel
is seen as a "link" on the path from the original source to the final
destination, and the goal is to increase link reliability in order to
minimize wasteful end-to-end retransmissions.When the original source and IPv6 fragmentation source are co-located
on the same platform (physical or virtual) the window of opportunity for
successful retransmission of individual fragments may be narrow unless
the link persistence timeframe is carefully coordinated with upper layer
retransmission timers. (In an uncoordinated case, upper layers may
retransmit the entire packet before or at roughly the same time the IPv6
fragmentation source retransmits individual fragments, leading to
increased congestion and wasted retransmissions.) However, the same
retransmission facility can be applied to both the tunneled and end
system source models.Upper layer protocols of the original source can further assign a
"Parcel ID" to groups of packets eligible for delivery to final
destination applications as a larger aggregate instead of smaller
individual packets (see: ).
The upper layer protocols supply the Parcel ID to lower layers which
insert the value as discussed in , while the
destination lower layer protocols deliver the Parcel ID to upper layers.
Further details on parcel grouping are out of scope for this
document.IPv6 fragmentation is specified in Section 4.5 of and is based on the IPv6 Fragment extension header
formatted as shown below:In this format:Next Header is a 1-octet IP protocol version of the next header
following the Fragment Header.Reserved is a 1-octet reserved field set to 0 on transmission and
ignored on reception.Fragment Offset is a 13-bit field that provides the offset (in
8-octet units) of the data portion that follows from the beginning
of the packet.Res is a 2-bit field set to 0 on transmission and ignored on
reception.M is the "More Fragments" bit telling whether additional
fragments follow.Identification is a 32 bit numerical identification value for the
entire IPv6 packet. The value is copied into each fragment of the
same IPv6 packet.The fragmentation and reassembly specification in can be considered as the standard method which
adheres to the details of that RFC. This document presents an enhanced
method that allows for retransmissions of individual fragments.Fragmentation implementations that follow this specification reuse
the (formerly) Reserved field of the IPv6 Fragment Header. For first
fragments (i.e., those with zero Fragment Offset) the 8-bit Reserved
field is replaced with a 7-bit Parcel ID followed by a 1-bit A(RQ) flag,
and the 2-bit Res field is replaced with a 1-bit P(arcel) flag followed
by a 1-bit S(ub-parcels) flag as shown below:For non-first fragments (i.e., those with non-zero Fragment Offset),
the Reserved field is replaced with a 7-bit "Ordinal" field followed by
a 1-bit A(RQ) flag as shown below: When a source that follows this specification fragments an IPv6
packet it sets the first fragment A flag to 1, then for IP parcels sets
Parcel ID, P and S according to the processing and transmission
procedures found in and
. For non-parcels, the source
instead sets Parcel ID, P and S to 0.The source then sets the Ordinal value for each successive non-first
fragment to a monotonically-increasing value beginning with 1, i.e., it
sets Ordinal to '1' for the first non-first fragment, '2' for the second
non-first fragment, '3' for the third non-first fragment, etc. up to
either Ordinal '127' or the final fragment (whichever comes first) while
also setting the A flag to 1. (If there are additional non-first
fragments beyond Ordinal '127', the source instead sets their Ordinals
to '0' to indicate that the fragment is not eligible for
retransmission.)When a destination that follows this specification receives IPv6
fragments with the A flag set, it infers that the source participates in
the protocol and maintains a checklist of all Ordinal fragments received
for a specific Identification number. (Note that receipt of any IPv6
fragments with the A flag set provides an implicit assertion that any
lost Ordinals of the same packet are also eligible for
retransmission.)If the destination notices one or more Ordinals missing after most
other Ordinals for the same Identification have arrived, it can prepare
an ICMPv6 Fragmentation Report (FRAGREP) message to send back to the source. The message is formatted
as follows:In this format, the destination prepares the FRAGREP message
as a list of 20-octet (Identification(i), Bitmap(i)) pairs. The first 4
octets in each pair encode the Identification value for the IPv6 packet
that is subject of the report, while the remaining 16 octets encode a
128-bit Bitmap of Ordinal fragments received for this Identification.
For example, if the destination receives the first fragment (i.e.,
Ordinal number 0) plus non-first fragment Ordinals 1, 3, 4, 6, and 8 it
sets Bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and sets all other bits to
'0'. The destination may include as many (Identification, Bitmap) pairs
as necessary without causing the entire message to exceed the minimum
IPv6 MTU (i.e., 1280 octets); if additional pairs are necessary, the
destination may prepare and send multiple messages.The destination next transmits the FRAGREP message to the IPv6
fragment source. When the source receives the message, it examines each
entry to determine the per-Identification Ordinal fragments that require
retransmission. For example, if the source receives a Bitmap for
Identification 0x12345678 with bits 0, 1, 3, 4, 6 and 8 set to '1', it
would retransmit Ordinal fragments (0x12345678, 2), (0x12345678, 5) and
(0x12345678, 7).This implies that the source should retain a cache of recently
transmitted fragments for a time that determines "link persistence"
. The link persistence should be at least as
long as the round-trip time from the fragmentation source to the
reassembly destination, plus an additional small delay to allow for
processing overhead and/or delay variance. Then, if the source receives
a FRAGREP message requesting retransmission of one or more Ordinals, it
can retransmit any still in its cache. Otherwise, the Ordinal will incur
a cache miss and the original source will eventually retransmit the
original packet in its entirety. After processing all entries in the
FRAGREP, the source discards the message.The maximum-sized IPv6 packet that a source can submit for
fragmentation is 65535 octets, and the minimum IPv6 path MTU is 1280
octets. Assuming the minimum IPv6 path MTU as the nominal size for
non-final fragments, the number of Ordinals for each IPv6 packet should
therefore easily fit within the available Bitmap bits when the fragments
are transmitted over IPv6-only network paths. However, when the path may
traverse one or more IPv4 networks (e.g., via tunneling) the path MTU
may be significantly smaller. In that case, the number of IPv6 fragments
needed may exceed the maximum number of Ordinal retransmission
candidates.When the number of IPv6 fragments exceeds 128, the source assigns an
Ordinal value in the first 127 non-first fragments, but sets Ordinal to
0 in any remaining non-first fragments then transmits all fragments.
When the destination receives the fragments, it may return a FRAGREP to
request retransmission of the first fragment and/or any missing Ordinal
non-first fragments, but may not request retransmission of non-first
fragments with zero Ordinals for which the default behavior of
best-effort delivery applies. However, all fragments are presented
equally to the reassembly cache regardless of the (formerly) Reserved
field settings, where the Reserved values are ignored and successful
reassembly is likely.Finally, transmission of IPv6 fragments over IPv6-only paths can be
safely conducted without a fragmentation-layer integrity check since
IPv6 includes reassembly safeguards and a 32-bit Identification value.
Conversely, transmission of IPv6 fragments over IPv4-only or mixed
IPv6/IPv4 paths requires a fragmentation-layer integrity check inserted
by the source before fragmentation and verified by the destination
following reassembly since IPv4 provides only a 16-bit Identification
and no reassembly safeguards. (In cases where the full path cannot be
determined a priori, an integrity check should always be included as
specified in AERO and OMNI .)When an IPv6 fragmentation source forwards packets that produce what
it considers as excessive numbers fragments (e.g., 32, 48, 64, more),
the fragmentation source can also return PTB "soft errors" to the
original source (subject to rate limiting). Either the fragmentation
source or reassembly destination may also return PTB soft errors if the
frequency of retransmissions or reassembly failures exceeds acceptable
thresholds.PTB soft errors are distinguished from ordinary "hard errors" through
non-zero values in the ICMPv6 "Code" or ICMPv4 "unused" fields.
The following values are currently defined:0 - "PTB hard error" - Original sources that receive these
messages obey the classic Path MTU Discovery (PMTUD) specifications
found in .1 - "PTB soft error (packet lost)" - Original sources that
receive these messages should reduce their packet sizes while
retransmitting the lost packet data, but need not wait the
prescribed 10 minutes before attempting to again increase packet
sizes.2 - "PTB soft error (packet forwarded)" - Original sources that
receive these messages should reduce their packet sizes without
invoking retransmission, and also need not wait the prescribed 10
minutes before attempting to again increase packet sizes.3-255 - reserved for future use.PTB soft errors include as much of the invoking packet as
possible without the message exceeding the minimum MTU (i.e., 1280
octets for IPv6 or 576 octets for IPv4). Original sources that recognize
PTB soft errors should follow common logic to dynamically tune their
packet sizes to obtain the best performance. In particular, an original
source can gradually increase its packet sizes while PTB soft errors are
suppressed then again reduce packet sizes when excessive soft errors
arrive.Original sources that do not recognize PTB soft errors (i.e., that do
not examine the Code/unused field value) follow the same standards as
for hard errors as described above and may therefore miss performance
improvement opportunities.TBD.A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)"
is requested. The registration procedure is "IETF Review" and the
reference is this document [RFCXXXX].The IANA is instructed to create new registries for "ICMPv6 Packet
Too Big Code field" and "ICMPv4 Fragmentation Needed unused field"
values. Both registries should have the following initial values:Communications networking security is necessary to preserve
confidentiality, integrity and availability.This work was inspired by ongoing AERO/OMNI/DTN investigations along
with recent innovations with IP Parcels..