IPv6 Fragment
RetransmissionBoeing 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 just a single
fragment requires retransmission of the original packet in its entirety,
with the potential for devastating effects on performance. This document
specifies an IPv6 fragment retransmission scheme that matches the loss
unit to the retransmission unit.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 under intermittent loss conditions could result in sustained
retransmission storms with little or no forward progress.This document proposes IPv6 fragment retransmission service in which
the source marks each fragment with an "Ordinal" number, and the
destination may request retransmissions of any ordinal fragments not
received. This retransmission request service is intended only for
short-duration and opportunistic best-effort recovery (i.e., and not
true end-to-end reliability). In this way, the service mirrors the
Automatic Repeat Request (ARQ) function of common data links by
considering an imaginary virtual link that extends from the IPv6 source
to destination. The goal therefore is for the destination to quickly
obtain missing individual fragments of partial reassemblies before true
end-to-end timers would cause retransmission of the entire packet.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.IPv6 fragmentation is specified in Section 4.5 of and is based on an 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 default 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 obey this specification write an
"Ordinal Number" beginning with 1 and monotonically incrementing for
each successive fragment in the one-octet "Reserved" field of the IPv6
Fragment Header. The Reserved field is then renamed as "Ordinal" as
shown below:In particular, when a source that obeys this specification fragments
an IPv6 packet it sets the Ordinal value for the first fragment to '1',
the Ordinal value for the second fragment to '2', the Ordinal value for
the third fragment to '3', etc. up to the total number of IPv6
fragments. When a destination that obeys this specification receives an
IPv6 fragment with the Reserved/Ordinal field set to non-zero, it infers
that the source participates in the protocol and maintains a checklist
of all Ordinal numbered fragments received for a specific Identification
number.If the destination notices one or more Ordinal numbers missing after
most other Ordinals for the same Identification have arrived, it can
prepare a Fragmentation Report (Fragrep) ICMPv6 message to send back to the source. The Fragrep message is
formatted as follows:In this format, the destination prepares the Fragrep message
as a list of ordered-triples of 4-octet fields. The first field in each
triple includes the Identification value for the IPv6 packet that is
subject of the report, while the second and third fields include a
64-bit bitmap of the Ordinal values received for this Identification.
For example, if the destination receives Ordinals 1, 2, 4, 5, 7, 9, then
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 ordered triples as necessary
without the entire Fragrep message exceeding the minimum IPv6 MTU of
1280 bytes.After the destination has assembled the Fragrep message, it transmits
the message to the IPv6 source. When the source receives the message, it
examines each ordered triple to determine the (Identification, Ordinal)
pairs that require retransmission. For example, if the source receives
an Ordinal bitmap for Identification 0x12345678 with bits 0, 1, 3, 4, 6
and 8 set to '1', it would retransmit Ordinal fragments (0x12345678, 3),
(0x12345678, 6) and (0x12345678, 8).This implies that the source should maintain a cache of recently
transmitted fragments for a time period known as the "link persistence
interval". Then, if the source receives a Fragrep that requests
retransmission of one or more Ordinals, it can retransmit if it still
holds the Ordinal in its cache. Otherwise, the Ordinal will incur a
cache miss and the original source will eventually retransmit the
original packet in its entirety.Note: The maximum-sized IPv6 packet that can undergo fragmentation is
64KB, and the minimum IPv6 path MTU is 1280B. Assuming the minimum IPv6
path MTU as the nominal size for non-final fragments, the number of
Ordinals for each IPv6 packet should be significantly less than the
allotted 64 bitmap bits.TBD.A new ICMPv6 Message Type code for "Fragmentation Report (Fragrep)"
is requested.Communications networking security is necessary to preserve
confidentiality, integrity and availability.This work was inspired by ongoing AERO/OMNI/DTN investigations..Fragmentation Considered Harmful, ACM Sigcomm 1987Digial Equipment CorporationDigial Equipment CorporationHow to Receive a Million Packets Per Second,
https://blog.cloudflare.com/how-to-receive-a-million-packets/CloudfareAccelerating UDP Packet Transmission for QUIC,
https://calendar.perfplanet.com/2019/accelerating-udp-packet-transmission-for-quic/Cloudfare