idnits 2.17.1 draft-templin-6man-fragrep-07.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 (29 March 2022) is 758 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: 'RFCXXXX' is mentioned on line 419, but not defined == Outdated reference: A later version (-63) exists of draft-templin-6man-aero-40 == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-55 == Outdated reference: A later version (-99) exists of draft-templin-intarea-parcels-09 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: RFC8200, RFC8201, RFC4443, RFC1191 (if 29 March 2022 5 approved) 6 Intended status: Standards Track 7 Expires: 30 September 2022 9 IPv6 Fragment Retransmission and Path MTU Discovery Soft Errors 10 draft-templin-6man-fragrep-07 12 Abstract 14 Internet Protocol version 6 (IPv6) provides a fragmentation and 15 reassembly service for end systems allowing for the transmission of 16 packets that exceed the path MTU. However, loss of individual 17 fragments requires retransmission of original packets in their 18 entirety leading to cascading reassembly failures. This document 19 specifies an IPv6 fragment retransmission scheme that matches the 20 loss unit to the retransmission unit. The document further specifies 21 an update to Path MTU Discovery that distinguishes hard link size 22 restrictions from reassembly congestion events. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 30 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Common Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 60 4. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 4 61 5. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 5 62 6. Packet Too Big (PTB) Soft Errors . . . . . . . . . . . . . . 8 63 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 11.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation 75 and reassembly service similar to that found in IPv4 [RFC0791], with 76 the exception that only the source host (i.e., and not routers on the 77 path) may perform fragmentation. When an IPv6 packet is fragmented, 78 the loss unit (i.e., a single IPv6 fragment) becomes smaller than the 79 retransmission unit (i.e., the entire packet) which even under 80 moderate loss conditions could result in cascading reassembly 81 failures that degrade forward progress [RFC8900]. 83 The presumed drawbacks of fragmentation are tempered by the fact that 84 performance increases can often be realized when the source sends 85 packets larger than the path MTU. This is due to the fact that 86 larger packets result in fewer application system calls, plus 87 transmission of a single large packet results in a burst of multiple 88 IPv6 fragments separated by minimal inter-packet delays. These 89 bursts yield high network utilization for the burst duration, while 90 modern reassembly implementations have proven capable of 91 accommodating the bursts. If the loss unit can somehow be made to 92 match the retransmission unit, the performance benefits of IPv6 93 fragmentation can be realized. 95 This document therefore proposes an IPv6 fragment retransmission 96 service where the source marks fragments as retransmission-eligible 97 while the destination may request retransmission of lost fragments. 98 The service provides opportunistic best-effort retransmissions over 99 an imaginary "link" extending from the source to the destination 100 consistent with the Automatic Repeat Request (ARQ) function of common 101 data links [RFC3366]. The service does not attempt to replace true 102 end-to-end reliability, but instead often allows the destination to 103 recover missing individual fragments of partial reassemblies before 104 true end-to-end timers would cause retransmission of the entire 105 packet. 107 The original packet source may be either co-located with or many IP 108 network hops before the IPv6 fragmentation source. In the same 109 fashion, the IPv6 reassembly destination may be either co-located 110 with or many IP network hops before the final destination. When 111 conditions suggest that an original source should begin sending 112 smaller packets, the fragmentation source and/or reassembly 113 destination can return a new type of ICMPv6/ICMPv4 Packet Too Big 114 (PTB) message termed a PTB "soft error". 116 PTB "soft errors" are distinguished from classic "hard errors" by a 117 non-zero PTB Code (ICMPv6) or unused (ICMPv4) field value. The 118 fragmentation source can return rate-limited soft errors to recommend 119 smaller packet sizes to the original source while fragmentation of 120 large packets is producing excessive numbers of fragments. 121 Similarly, the reassembly destination can return rate-limited soft 122 errors (i.e., via the fragmentation source to the original source) 123 while reassembly of large packets is causing excessive reassembly 124 congestion. Original sources that receive these soft errors should 125 reduce their packet sizes until the errors subside, but can begin to 126 increase packet sizes again without delay until further soft or hard 127 errors arrive. 129 The following sections discuss common use cases and operational 130 considerations for applying IPv6 fragment retransmission and path MTU 131 discovery soft errors. They further specify new codings for the IPv6 132 fragment header Reserved field, a new ICMPv6 message type and updates 133 to ICMPv6/ICMPv4 PTB messages. This document therefore updates 134 existing standards where necessary. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119][RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Common Use Cases 146 A common use case of interest is to improve the state of affairs for 147 IPv6 encapsulation (i.e., "tunneling") [RFC2473] when the original 148 source may be many IP hops away from the tunnel ingress, and the 149 tunnel packet may be fragmented following encapsulation. The tunnel 150 is seen as a "link" on the path from the original source to the final 151 destination, and the goal is to increase link reliability in order to 152 minimize wasteful end-to-end retransmissions. 154 When the original source and IPv6 fragmentation source are co-located 155 on the same platform (physical or virtual) the window of opportunity 156 for successful retransmission of individual fragments may be narrow 157 unless the link persistence timeframe is carefully coordinated with 158 upper layer retransmission timers. (In an uncoordinated case, upper 159 layers may retransmit the entire packet before or at roughly the same 160 time the IPv6 fragmentation source retransmits individual fragments, 161 leading to increased congestion and wasted retransmissions.) 162 However, the same retransmission facility can be applied to both the 163 tunneled and end system source models. 165 Upper layer protocols of the original source can further assign a 166 "Parcel ID" to groups of packets eligible for delivery to final 167 destination applications as a larger aggregate instead of smaller 168 individual packets (see: [I-D.templin-intarea-parcels]). The upper 169 layer protocols supply the Parcel ID to lower layers which insert the 170 value as discussed in Section 4, while the destination lower layer 171 protocols deliver the Parcel ID to upper layers. Further details on 172 parcel grouping are out of scope for this document. 174 4. IPv6 Fragmentation 176 IPv6 fragmentation is specified in Section 4.5 of [RFC8200] and is 177 based on the IPv6 Fragment extension header formatted as shown below: 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Next Header | Reserved | Fragment Offset |Res|M| 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Identification | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 In this format: 187 * Next Header is a 1-octet IP protocol version of the next header 188 following the Fragment Header. 190 * Reserved is a 1-octet reserved field set to 0 on transmission and 191 ignored on reception. 193 * Fragment Offset is a 13-bit field that provides the offset (in 194 8-octet units) of the data portion that follows from the beginning 195 of the packet. 197 * Res is a 2-bit field set to 0 on transmission and ignored on 198 reception. 200 * M is the "More Fragments" bit telling whether additional fragments 201 follow. 203 * Identification is a 32 bit numerical identification value for the 204 entire IPv6 packet. The value is copied into each fragment of the 205 same IPv6 packet. 207 The fragmentation and reassembly specification in [RFC8200] can be 208 considered as the standard method which adheres to the details of 209 that RFC. This document presents an enhanced method that allows for 210 retransmissions of individual fragments. 212 5. IPv6 Fragment Retransmission 214 Fragmentation implementations that follow this specification reuse 215 the (formerly) Reserved field of the IPv6 Fragment Header. For first 216 fragments (i.e., those with zero Fragment Offset) the 8-bit Reserved 217 field is replaced with a 7-bit Parcel ID followed by a 1-bit A(RQ) 218 flag, and the 2-bit Res field is replaced with a 1-bit P(arcel) flag 219 followed by a 1-bit S(ub-parcels) flag as shown below: 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Next Header | Parcel ID |A| Fragment Offset |P|S|M| 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Identification | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 For non-first fragments (i.e., those with non-zero Fragment Offset), 228 the Reserved field is replaced with a 7-bit "Ordinal" field followed 229 by a 1-bit A(RQ) flag as shown below: 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Next Header | Ordinal |A| Fragment Offset |Res|M| 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Identification | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 When a source that follows this specification fragments an IPv6 238 packet it sets the first fragment A flag to 1, then for IP parcels 239 sets Parcel ID, P and S according to the processing and transmission 240 procedures found in [I-D.templin-intarea-parcels] and 241 [I-D.templin-6man-omni]. For non-parcels, the source instead sets 242 Parcel ID, P and S to 0. 244 The source then sets the Ordinal value for each successive non-first 245 fragment to a monotonically-increasing value beginning with 1, i.e., 246 it sets Ordinal to '1' for the first non-first fragment, '2' for the 247 second non-first fragment, '3' for the third non-first fragment, etc. 248 up to either Ordinal '127' or the final fragment (whichever comes 249 first) while also setting the A flag to 1. (If there are additional 250 non-first fragments beyond Ordinal '127', the source instead sets 251 their Ordinals to '0' to indicate that the fragment is not eligible 252 for retransmission.) 254 When a destination that follows this specification receives IPv6 255 fragments with the A flag set, it infers that the source participates 256 in the protocol and maintains a checklist of all Ordinal fragments 257 received for a specific Identification number. (Note that receipt of 258 any IPv6 fragments with the A flag set provides an implicit assertion 259 that any lost Ordinals of the same packet are also eligible for 260 retransmission.) 262 If the destination notices one or more Ordinals missing after most 263 other Ordinals for the same Identification have arrived, it can 264 prepare an ICMPv6 Fragmentation Report (FRAGREP) message [RFC4443] to 265 send back to the source. The message is formatted as follows: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Code | Checksum | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Identification (0) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ~ Ordinal Bitmap (0) (0-127) ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Identification (1) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 ~ Ordinal Bitmap (1) (0-127) ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | ... | 281 | ... | 283 In this format, the destination prepares the FRAGREP message as a 284 list of 20-octet (Identification(i), Bitmap(i)) pairs. The first 4 285 octets in each pair encode the Identification value for the IPv6 286 packet that is subject of the report, while the remaining 16 octets 287 encode a 128-bit Bitmap of Ordinal fragments received for this 288 Identification. For example, if the destination receives the first 289 fragment (i.e., Ordinal number 0) plus non-first fragment Ordinals 1, 290 3, 4, 6, and 8 it sets Bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and 291 sets all other bits to '0'. The destination may include as many 292 (Identification, Bitmap) pairs as necessary without causing the 293 entire message to exceed the minimum IPv6 MTU (i.e., 1280 octets); if 294 additional pairs are necessary, the destination may prepare and send 295 multiple messages. 297 The destination next transmits the FRAGREP message to the IPv6 298 fragment source. When the source receives the message, it examines 299 each entry to determine the per-Identification Ordinal fragments that 300 require retransmission. For example, if the source receives a Bitmap 301 for Identification 0x12345678 with bits 0, 1, 3, 4, 6 and 8 set to 302 '1', it would retransmit Ordinal fragments (0x12345678, 2), 303 (0x12345678, 5) and (0x12345678, 7). 305 This implies that the source should retain a cache of recently 306 transmitted fragments for a time that determines "link persistence" 307 [RFC3366]. The link persistence should be at least as long as the 308 round-trip time from the fragmentation source to the reassembly 309 destination, plus an additional small delay to allow for processing 310 overhead and/or delay variance. Then, if the source receives a 311 FRAGREP message requesting retransmission of one or more Ordinals, it 312 can retransmit any still in its cache. Otherwise, the Ordinal will 313 incur a cache miss and the original source will eventually retransmit 314 the original packet in its entirety. After processing all entries in 315 the FRAGREP, the source discards the message. 317 The maximum-sized IPv6 packet that a source can submit for 318 fragmentation is 65535 octets, and the minimum IPv6 path MTU is 1280 319 octets. Assuming the minimum IPv6 path MTU as the nominal size for 320 non-final fragments, the number of Ordinals for each IPv6 packet 321 should therefore easily fit within the available Bitmap bits when the 322 fragments are transmitted over IPv6-only network paths. However, 323 when the path may traverse one or more IPv4 networks (e.g., via 324 tunneling) the path MTU may be significantly smaller. In that case, 325 the number of IPv6 fragments needed may exceed the maximum number of 326 Ordinal retransmission candidates. 328 When the number of IPv6 fragments exceeds 128, the source assigns an 329 Ordinal value in the first 127 non-first fragments, but sets Ordinal 330 to 0 in any remaining non-first fragments then transmits all 331 fragments. When the destination receives the fragments, it may 332 return a FRAGREP to request retransmission of the first fragment and/ 333 or any missing Ordinal non-first fragments, but may not request 334 retransmission of non-first fragments with zero Ordinals for which 335 the default behavior of best-effort delivery applies. However, all 336 fragments are presented equally to the reassembly cache regardless of 337 the (formerly) Reserved field settings, where the Reserved values are 338 ignored and successful reassembly is likely. 340 Finally, transmission of IPv6 fragments over IPv6-only paths can be 341 safely conducted without a fragmentation-layer integrity check since 342 IPv6 includes reassembly safeguards and a 32-bit Identification 343 value. Conversely, transmission of IPv6 fragments over IPv4-only or 344 mixed IPv6/IPv4 paths requires a fragmentation-layer integrity check 345 inserted by the source before fragmentation and verified by the 346 destination following reassembly since IPv4 provides only a 16-bit 347 Identification and no reassembly safeguards. (In cases where the 348 full path cannot be determined a priori, an integrity check should 349 always be included as specified in AERO [I-D.templin-6man-aero] and 350 OMNI [I-D.templin-6man-omni].) 352 6. Packet Too Big (PTB) Soft Errors 354 When an IPv6 fragmentation source forwards packets that produce what 355 it considers as excessive numbers fragments (e.g., 32, 48, 64, more), 356 the fragmentation source can also return PTB "soft errors" to the 357 original source (subject to rate limiting). Either the fragmentation 358 source or reassembly destination may also return PTB soft errors if 359 the frequency of retransmissions or reassembly failures exceeds 360 acceptable thresholds. 362 PTB soft errors are distinguished from ordinary "hard errors" through 363 non-zero values in the ICMPv6 "Code" [RFC8201][RFC4443] or ICMPv4 364 "unused" [RFC1191] fields. The following values are currently 365 defined: 367 * 0 - "PTB hard error" - Original sources that receive these 368 messages obey the classic Path MTU Discovery (PMTUD) 369 specifications found in [RFC8201][RFC1191]. 371 * 1 - "PTB soft error (packet lost)" - Original sources that receive 372 these messages should reduce their packet sizes while 373 retransmitting the lost packet data, but need not wait the 374 prescribed 10 minutes before attempting to again increase packet 375 sizes. 377 * 2 - "PTB soft error (packet forwarded)" - Original sources that 378 receive these messages should reduce their packet sizes without 379 invoking retransmission, and also need not wait the prescribed 10 380 minutes before attempting to again increase packet sizes. 382 * 3-255 - reserved for future use. 384 PTB soft errors include as much of the invoking packet as possible 385 without the message exceeding the minimum MTU (i.e., 1280 octets for 386 IPv6 or 576 octets for IPv4). Original sources that recognize PTB 387 soft errors should follow common logic to dynamically tune their 388 packet sizes to obtain the best performance. In particular, an 389 original source can gradually increase its packet sizes while PTB 390 soft errors are suppressed then again reduce packet sizes when 391 excessive soft errors arrive. 393 Original sources that do not recognize PTB soft errors (i.e., that do 394 not examine the Code/unused field value) follow the same standards as 395 for hard errors as described above and may therefore miss performance 396 improvement opportunities. 398 7. Implementation Status 400 TBD. 402 8. IANA Considerations 404 A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)" 405 is requested. The registration procedure is "IETF Review" and the 406 reference is this document [RFCXXXX]. 408 The IANA is instructed to create new registries for "ICMPv6 Packet 409 Too Big Code field" and "ICMPv4 Fragmentation Needed unused field" 410 values. Both registries should have the following initial values: 412 Value Sub-Type name Reference 413 ----- ------------- ---------- 414 0 PTB hard error [RFCXXXX] 415 1 PTB soft error (loss) [RFCXXXX] 416 2 PTB soft error (no loss) [RFCXXXX] 417 3-252 Unassigned 418 253-254 Reserved for Experimentation [RFCXXXX] 419 255 Reserved by IANA [RFCXXXX] 421 Figure 1: Packet Too Big Code/unused Values 423 9. Security Considerations 425 Communications networking security is necessary to preserve 426 confidentiality, integrity and availability. 428 10. Acknowledgements 430 This work was inspired by ongoing AERO/OMNI/DTN investigations along 431 with recent innovations with IP Parcels. 433 . 435 11. References 437 11.1. Normative References 439 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 440 DOI 10.17487/RFC0791, September 1981, 441 . 443 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 444 DOI 10.17487/RFC1191, November 1990, 445 . 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 453 Control Message Protocol (ICMPv6) for the Internet 454 Protocol Version 6 (IPv6) Specification", STD 89, 455 RFC 4443, DOI 10.17487/RFC4443, March 2006, 456 . 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 463 (IPv6) Specification", STD 86, RFC 8200, 464 DOI 10.17487/RFC8200, July 2017, 465 . 467 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 468 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 469 DOI 10.17487/RFC8201, July 2017, 470 . 472 11.2. Informative References 474 [I-D.templin-6man-aero] 475 Templin, F. L., "Automatic Extended Route Optimization 476 (AERO)", Work in Progress, Internet-Draft, draft-templin- 477 6man-aero-40, 7 March 2022, 478 . 481 [I-D.templin-6man-omni] 482 Templin, F. L., "Transmission of IP Packets over Overlay 483 Multilink Network (OMNI) Interfaces", Work in Progress, 484 Internet-Draft, draft-templin-6man-omni-55, 7 March 2022, 485 . 488 [I-D.templin-intarea-parcels] 489 Templin, F. L., "IP Parcels", Work in Progress, Internet- 490 Draft, draft-templin-intarea-parcels-09, 10 February 2022, 491 . 494 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 495 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 496 December 1998, . 498 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 499 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 500 DOI 10.17487/RFC3366, August 2002, 501 . 503 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 504 and F. Gont, "IP Fragmentation Considered Fragile", 505 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 506 . 508 Author's Address 510 Fred L. Templin (editor) 511 Boeing Research & Technology 512 P.O. Box 3707 513 Seattle, WA 98124 514 United States of America 515 Email: fltemplin@acm.org