idnits 2.17.1 draft-templin-6man-fragrep-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 08, 2021) is 892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3366' is mentioned on line 226, but not defined == Missing Reference: 'AERO' is mentioned on line 272, but not defined == Missing Reference: 'OMNI' is mentioned on line 272, but not defined == Unused Reference: 'RFC5326' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dtn-bpbis' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-omni' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'MPPS' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'QUIC' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC4963' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC6864' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC8899' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC8900' is defined on line 364, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 5326 == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-49 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: RFC8200 (if approved) November 08, 2021 5 Intended status: Standards Track 6 Expires: May 12, 2022 8 IPv6 Fragment Retransmission 9 draft-templin-6man-fragrep-01 11 Abstract 13 Internet Protocol version 6 (IPv6) provides a fragmentation and 14 reassembly service for end systems allowing for the transmission of 15 packets that exceed the path MTU. However, loss of just a single 16 fragment requires retransmission of the original packet in its 17 entirety, with the potential for devastating effects on performance. 18 This document specifies an IPv6 fragment retransmission scheme that 19 matches the loss unit to the retransmission unit. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 12, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 3 58 4. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 4 59 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation 71 and reassembly service similar to that found in IPv4 [RFC0791], with 72 the exception that only the source host (i.e., and not routers on the 73 path) may perform fragmentation. When an IPv6 packet is fragmented, 74 the loss unit (i.e., a single IPv6 fragment) becomes smaller than the 75 retransmission unit (i.e., the entire packet) which under 76 intermittent loss conditions could result in sustained retransmission 77 storms with little or no forward progress [FRAG]. 79 The presumed drawbacks of fragmentation are tempered by the fact that 80 greater performance can often be realized when the source sends large 81 packets that exceed the path MTU. This is due to the fact that a 82 single large IPv6 packet produced by upper layers results in a burst 83 of multiple fragment packets produced by lower layers with minimal 84 inter-packet delays. These bursts yield high network utilization for 85 the burst duration, while modern reassembly implementations have 86 proven capable of accommodating such bursts. If the loss unit can 87 somehow be made to match the retransmission unit, the performance 88 benefits of IPv6 fragmentation can be realized. 90 This document therefore proposes an IPv6 fragment retransmission 91 service in which the source marks each fragment with an "Ordinal" 92 number, and the destination may request retransmissions of any 93 ordinal fragments that are lost. This retransmission request service 94 is intended only for short-duration and opportunistic best-effort 95 recovery (i.e., and not true end-to-end reliability). In this way, 96 the service mirrors the Automatic Repeat Request (ARQ) function of 97 common data links [RFC3366] by considering an imaginary virtual link 98 that extends from the IPv6 source to destination. The goal therefore 99 is for the destination to quickly obtain missing individual fragments 100 of partial reassemblies before true end-to-end timers would cause 101 retransmission of the entire packet. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119][RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. IPv6 Fragmentation 113 IPv6 fragmentation is specified in Section 4.5 of [RFC8200] and is 114 based on an IPv6 Fragment extension header formatted as shown below: 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Next Header | Reserved | Fragment Offset |Res|M| 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Identification | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 In this format: 124 o Next Header is a 1-octet IP protocol version of the next header 125 following the Fragment Header. 127 o Reserved is a 1-octet reserved field set to 0 on transmission and 128 ignored on reception. 130 o Fragment Offset is a 13-bit field that provides the offset (in 131 8-octet units) of the data portion that follows from the beginning 132 of the packet. 134 o Res is a 2-bit field set to 0 on transmission and ignored on 135 reception. 137 o M is the "more fragments" bit telling whether additional fragments 138 follow. 140 o Identification is a 32 bit numerical identification value for the 141 entire IPv6 packet. The value is copied into each fragment of the 142 same IPv6 packet. 144 The fragmentation and reassembly specification in [RFC8200] can be 145 considered as the default method which adheres to the details of that 146 RFC. This document presents an enhanced method that allows for 147 retransmissions of individual fragments. 149 4. IPv6 Fragment Retransmission 151 Fragmentation implementations that obey this specification write an 152 "Ordinal" value beginning with 0 and monotonically incrementing for 153 each successive fragment in the (formerly) "Reserved" field of the 154 IPv6 Fragment Header. The Reserved field is then replaced with a 155 6-bit "Ordinal" field followed by a 1-bit R(eserved) flag followed by 156 a 1-bit A(RQ) flag as shown below: 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Header | Ordinal |R|A| Fragment Offset |Res|M| 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Identification | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 In particular, when a source that obeys this specification fragments 165 an IPv6 packet it sets the Ordinal value for the first fragment to 166 '0', the Ordinal value for the second fragment to '1', the Ordinal 167 value for the third fragment to '2', etc. up to either the final 168 fragment or the 64th fragment (whichever comes first). The source 169 also sets the A flag to 1 in each fragment to inform the destination 170 that fragment retransmission is supported for this packet. 172 When a destination that obeys this specification receives IPv6 173 fragments with the A flag set to 1, it infers that the source 174 participates in the protocol and maintains a checklist of all Ordinal 175 numbered fragments received for a specific Identification number. 177 If the destination notices one or more Ordinals missing after most 178 other Ordinals for the same Identification have arrived, it can 179 prepare a Fragmentation Report (FRAGREP) ICMPv6 message [RFC4443] to 180 send back to the source. The FRAGREP message is formatted as 181 follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Code | Checksum | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Identification (0) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Ordinal Bitmap (0) (0-31) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Ordinal Bitmap (0) (32-63) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Identification (1) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Ordinal Bitmap (1) (0-31) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Ordinal Bitmap (1) (32-63) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | ... | 201 | ... | 203 In this format, the destination prepares the FRAGREP message as a 204 list of 12-octet (Identification(i), Bitmap(i)) pairs. The first 4 205 octets in each pair encode the Identification value for the IPv6 206 packet that is subject of the report, while the remaining 8 octets 207 encode a 64-bit Bitmap of Ordinal fragments received for this 208 Identification. For example, if the destination receives Ordinals 0, 209 1, 3, 4, 6, and 8 it sets Bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and 210 sets all other bits to '0'. The destination may include as many 211 (Identification, Bitmap) pairs as necessary without the entire 212 FRAGREP message exceeding the minimum IPv6 MTU of 1280 bytes. (If 213 additional pairs are necessary, the destination may prepare and send 214 multiple FRAGREPs.) 216 After the destination has assembled the FRAGREP it transmits the 217 message to the IPv6 source. When the source receives the FRAGREP, it 218 examines each entry to determine the per-Identification Ordinal 219 fragments that require retransmission. For example, if the source 220 receives a Bitmap for Identification 0x12345678 with bits 0, 1, 3, 4, 221 6 and 8 set to '1', it would retransmit Ordinal fragments 222 (0x12345678, 2), (0x12345678, 5) and (0x12345678, 7). 224 This implies that the source should maintain a cache of recently 225 transmitted fragments for a time period known as the "link 226 persistence interval" [RFC3366]. Then, if the source receives a 227 FRAGREP requesting retransmission of one or more Ordinals, it can 228 retransmit if it still holds the Ordinal in its cache. Otherwise, 229 the Ordinal will incur a cache miss and the original source will 230 eventually retransmit the original packet in its entirety. 232 Note that the maximum-sized IPv6 packet that a source can submit for 233 fragmentation is 64KB, and the minimum IPv6 path MTU is 1280B. 234 Assuming the minimum IPv6 path MTU as the nominal size for non-final 235 fragments, the number of Ordinals for each IPv6 packet should 236 therefore fit within the allotted 64 Bitmap bits when the fragments 237 are transmitted over IPv6-only network paths. 239 However, when the path may traverse one or more IPv4 networks (e.g., 240 via tunneling) the path MTU may be significantly smaller. In that 241 case, the number of IPv6 fragments needed may exceed the maximum 242 number of Ordinal candidates for retransmission (i.e., 64). 244 When the number of IPv6 fragments exceeds 64, the source assigns an 245 Ordinal value and sets A to 1 in the first 64 fragments, but sets 246 both Ordinal and A to 0 in all remaining fragments then transmits all 247 fragments. When the destination receives the fragments, it may 248 return a FRAGREP to request retransmission of any of the first 64 249 fragments, but may not request retransmission of any additional 250 fragments for which the default behavior of best-effort delivery 251 applies. (However, all fragments are presented equally to the 252 reassembly cache where successful reassembly is likely.) 254 For this reason, when an IPv6 tunnel endpoint acting as the source 255 forwards a fragmented packet with more than 64 fragments it also 256 returns an ICMPv6 Packet Too Big (PTB) "soft error" to the original 257 source as specified in [AERO][OMNI]. When the original source 258 receives the PTB soft error, it should reduce the size of the packets 259 it sends. Either IPv6 tunnel endpoint may also return PTB soft 260 errors if the frequency of retransmissions or reassembly failures 261 exceeds acceptable thresholds. 263 Finally, transmission of IPv6 fragments over IPv6-only paths can 264 safely proceed without a fragmentation-layer integrity check since 265 IPv6 includes a 32-bit Identification value and reassembly 266 safeguards. On the other hand, transmission of IPv6 fragments over 267 IPv4-only or mixed IPv6/IPv4 paths requires a fragmentation-layer 268 integrity check inserted by the source before fragmentation and 269 verified by the destination following reassembly since IPv4 provides 270 only a 16-bit Identification and no reassembly safeguards. (In cases 271 where the full path cannot be determined a priori, an integrity check 272 should always be included as specified in [AERO][OMNI].) 274 5. Implementation Status 276 TBD. 278 6. IANA Considerations 280 A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)" 281 is requested. 283 7. Security Considerations 285 Communications networking security is necessary to preserve 286 confidentiality, integrity and availability. 288 8. Acknowledgements 290 This work was inspired by ongoing AERO/OMNI/DTN investigations. 292 . 294 9. References 296 9.1. Normative References 298 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 299 DOI 10.17487/RFC0791, September 1981, 300 . 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 308 Control Message Protocol (ICMPv6) for the Internet 309 Protocol Version 6 (IPv6) Specification", STD 89, 310 RFC 4443, DOI 10.17487/RFC4443, March 2006, 311 . 313 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 314 Transmission Protocol - Specification", RFC 5326, 315 DOI 10.17487/RFC5326, September 2008, 316 . 318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 320 May 2017, . 322 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 323 (IPv6) Specification", STD 86, RFC 8200, 324 DOI 10.17487/RFC8200, July 2017, 325 . 327 9.2. Informative References 329 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful, 330 ACM Sigcomm 1987", August 1987. 332 [I-D.ietf-dtn-bpbis] 333 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 334 Protocol Version 7", draft-ietf-dtn-bpbis-31 (work in 335 progress), January 2021. 337 [I-D.templin-6man-omni] 338 Templin, F. L. and T. Whyman, "Transmission of IP Packets 339 over Overlay Multilink Network (OMNI) Interfaces", draft- 340 templin-6man-omni-49 (work in progress), October 2021. 342 [MPPS] Majkowski, M., "How to Receive a Million Packets Per 343 Second, https://blog.cloudflare.com/how-to-receive-a- 344 million-packets/", June 2015. 346 [QUIC] Ghedini, A., "Accelerating UDP Packet Transmission for 347 QUIC, https://calendar.perfplanet.com/2019/accelerating- 348 udp-packet-transmission-for-quic/", December 2019. 350 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 351 Errors at High Data Rates", RFC 4963, 352 DOI 10.17487/RFC4963, July 2007, 353 . 355 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 356 RFC 6864, DOI 10.17487/RFC6864, February 2013, 357 . 359 [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 360 T. Voelker, "Packetization Layer Path MTU Discovery for 361 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 362 September 2020, . 364 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 365 and F. Gont, "IP Fragmentation Considered Fragile", 366 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 367 . 369 Author's Address 370 Fred L. Templin (editor) 371 Boeing Research & Technology 372 P.O. Box 3707 373 Seattle, WA 98124 374 USA 376 Email: fltemplin@acm.org