IPv6 Fragment Retransmission
draft-templin-6man-fragrep-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2021-11-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-templin-6man-fragrep-01
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: RFC8200 (if approved) November 08, 2021
Intended status: Standards Track
Expires: May 12, 2022
IPv6 Fragment Retransmission
draft-templin-6man-fragrep-01
Abstract
Internet 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.
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 May 12, 2022.
Copyright Notice
Copyright (c) 2021 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
Templin Expires May 12, 2022 [Page 1]
Internet-Draft IPv6 Fragment Retransmission November 2021
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 3
4. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 4
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation
and reassembly service similar to that found in IPv4 [RFC0791], 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 [FRAG].
The presumed drawbacks of fragmentation are tempered by the fact that
greater performance can often be realized when the source sends large
packets that exceed the path MTU. This is due to the fact that a
single large IPv6 packet produced by upper layers results in a burst
of multiple fragment packets produced by lower layers with minimal
inter-packet delays. These bursts yield high network utilization for
the burst duration, while modern reassembly implementations have
proven capable of accommodating such 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 in which the source marks each fragment with an "Ordinal"
number, and the destination may request retransmissions of any
ordinal fragments that are lost. 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
Templin Expires May 12, 2022 [Page 2]
Internet-Draft IPv6 Fragment Retransmission November 2021
common data links [RFC3366] 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.
2. Terminology
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.
3. IPv6 Fragmentation
IPv6 fragmentation is specified in Section 4.5 of [RFC8200] and is
based on an IPv6 Fragment extension header formatted as shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this format:
o Next Header is a 1-octet IP protocol version of the next header
following the Fragment Header.
o Reserved is a 1-octet reserved field set to 0 on transmission and
ignored on reception.
o 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.
o Res is a 2-bit field set to 0 on transmission and ignored on
reception.
o M is the "more fragments" bit telling whether additional fragments
follow.
o 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.
Templin Expires May 12, 2022 [Page 3]
Internet-Draft IPv6 Fragment Retransmission November 2021
The fragmentation and reassembly specification in [RFC8200] 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.
4. IPv6 Fragment Retransmission
Fragmentation implementations that obey this specification write an
"Ordinal" value beginning with 0 and monotonically incrementing for
each successive fragment in the (formerly) "Reserved" field of the
IPv6 Fragment Header. The Reserved field is then replaced with a
6-bit "Ordinal" field followed by a 1-bit R(eserved) flag followed by
a 1-bit A(RQ) flag as shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Ordinal |R|A| Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In particular, when a source that obeys this specification fragments
an IPv6 packet it sets the Ordinal value for the first fragment to
'0', the Ordinal value for the second fragment to '1', the Ordinal
value for the third fragment to '2', etc. up to either the final
fragment or the 64th fragment (whichever comes first). The source
also sets the A flag to 1 in each fragment to inform the destination
that fragment retransmission is supported for this packet.
When a destination that obeys this specification receives IPv6
fragments with the A flag set to 1, 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 Ordinals missing after most
other Ordinals for the same Identification have arrived, it can
prepare a Fragmentation Report (FRAGREP) ICMPv6 message [RFC4443] to
send back to the source. The FRAGREP message is formatted as
follows:
Templin Expires May 12, 2022 [Page 4]
Internet-Draft IPv6 Fragment Retransmission November 2021
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ordinal Bitmap (0) (0-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ordinal Bitmap (0) (32-63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ordinal Bitmap (1) (0-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ordinal Bitmap (1) (32-63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| ... |
In this format, the destination prepares the FRAGREP message as a
list of 12-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 8 octets
encode a 64-bit Bitmap of Ordinal fragments received for this
Identification. For example, if the destination receives Ordinals 0,
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 the entire
FRAGREP message exceeding the minimum IPv6 MTU of 1280 bytes. (If
additional pairs are necessary, the destination may prepare and send
multiple FRAGREPs.)
After the destination has assembled the FRAGREP it transmits the
message to the IPv6 source. When the source receives the FRAGREP, 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 maintain a cache of recently
transmitted fragments for a time period known as the "link
persistence interval" [RFC3366]. Then, if the source receives a
FRAGREP requesting 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.
Templin Expires May 12, 2022 [Page 5]
Internet-Draft IPv6 Fragment Retransmission November 2021
Note that the maximum-sized IPv6 packet that a source can submit for
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
therefore fit within the allotted 64 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 candidates for retransmission (i.e., 64).
When the number of IPv6 fragments exceeds 64, the source assigns an
Ordinal value and sets A to 1 in the first 64 fragments, but sets
both Ordinal and A to 0 in all remaining fragments then transmits all
fragments. When the destination receives the fragments, it may
return a FRAGREP to request retransmission of any of the first 64
fragments, but may not request retransmission of any additional
fragments for which the default behavior of best-effort delivery
applies. (However, all fragments are presented equally to the
reassembly cache where successful reassembly is likely.)
For this reason, when an IPv6 tunnel endpoint acting as the source
forwards a fragmented packet with more than 64 fragments it also
returns an ICMPv6 Packet Too Big (PTB) "soft error" to the original
source as specified in [AERO][OMNI]. When the original source
receives the PTB soft error, it should reduce the size of the packets
it sends. Either IPv6 tunnel endpoint may also return PTB soft
errors if the frequency of retransmissions or reassembly failures
exceeds acceptable thresholds.
Finally, transmission of IPv6 fragments over IPv6-only paths can
safely proceed without a fragmentation-layer integrity check since
IPv6 includes a 32-bit Identification value and reassembly
safeguards. On the other hand, 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][OMNI].)
5. Implementation Status
TBD.
Templin Expires May 12, 2022 [Page 6]
Internet-Draft IPv6 Fragment Retransmission November 2021
6. IANA Considerations
A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)"
is requested.
7. Security Considerations
Communications networking security is necessary to preserve
confidentiality, integrity and availability.
8. Acknowledgements
This work was inspired by ongoing AERO/OMNI/DTN investigations.
.
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[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>.
[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>.
[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>.
Templin Expires May 12, 2022 [Page 7]
Internet-Draft IPv6 Fragment Retransmission November 2021
9.2. Informative References
[FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful,
ACM Sigcomm 1987", August 1987.
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
Protocol Version 7", draft-ietf-dtn-bpbis-31 (work in
progress), January 2021.
[I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-49 (work in progress), October 2021.
[MPPS] Majkowski, M., "How to Receive a Million Packets Per
Second, https://blog.cloudflare.com/how-to-receive-a-
million-packets/", June 2015.
[QUIC] Ghedini, A., "Accelerating UDP Packet Transmission for
QUIC, https://calendar.perfplanet.com/2019/accelerating-
udp-packet-transmission-for-quic/", December 2019.
[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>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
Author's Address
Templin Expires May 12, 2022 [Page 8]
Internet-Draft IPv6 Fragment Retransmission November 2021
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires May 12, 2022 [Page 9]