idnits 2.17.1 draft-templin-6man-fragrep-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 25, 2021) is 911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5326' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'FRAG' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dtn-bpbis' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-omni' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'MPPS' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'QUIC' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC4963' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC6864' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC8899' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC8900' is defined on line 311, but no explicit reference was found in the text == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-48 Summary: 0 errors (**), 0 flaws (~~), 13 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 Intended status: Informational October 25, 2021 5 Expires: April 28, 2022 7 IPv6 Fragment Retransmission 8 draft-templin-6man-fragrep-00 10 Abstract 12 Internet Protocol version 6 (IPv6) provides a fragmentation and 13 reassembly service for end systems allowing for the transmission of 14 packets that exceed the path MTU. However, loss of just a single 15 fragment requires retransmission of the original packet in its 16 entirety, with the potential for devastating effects on performance. 17 This document specifies an IPv6 fragment retransmission scheme that 18 matches the loss unit to the retransmission unit. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 28, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 3 57 4. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 3 58 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation 70 and reassembly service similar to that found in IPv4 [RFC0791], with 71 the exception that only the source host (i.e., and not routers on the 72 path) may perform fragmentation. When an IPv6 packet is fragmented, 73 the loss unit (i.e., a single IPv6 fragment) becomes smaller than the 74 retransmission unit (i.e., the entire packet) which under 75 intermittent loss conditions could result in sustained retransmission 76 storms with little or no forward progress. 78 This document proposes IPv6 fragment retransmission service in which 79 the source marks each fragment with an "Ordinal" number, and the 80 destination may request retransmissions of any ordinal fragments not 81 received. This retransmission request service is intended only for 82 short-duration and opportunistic best-effort recovery (i.e., and not 83 true end-to-end reliability). In this way, the service mirrors the 84 Automatic Repeat Request (ARQ) function of common data links by 85 considering an imaginary virtual link that extends from the IPv6 86 source to destination. The goal therefore is for the destination to 87 quickly obtain missing individual fragments of partial reassemblies 88 before true end-to-end timers would cause retransmission of the 89 entire packet. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119][RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 3. IPv6 Fragmentation 101 IPv6 fragmentation is specified in Section 4.5 of [RFC8200] and is 102 based on an IPv6 Fragment extension header formatted as shown below: 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Next Header | Reserved | Fragment Offset |Res|M| 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Identification | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 In this format: 112 o Next Header is a 1-octet IP protocol version of the next header 113 following the Fragment Header. 115 o Reserved is a 1-octet reserved field set to 0 on transmission and 116 ignored on reception. 118 o Fragment Offset is a 13-bit field that provides the offset (in 119 8-octet units) of the data portion that follows from the beginning 120 of the packet. 122 o Res is a 2-bit field set to 0 on transmission and ignored on 123 reception. 125 o M is the "more fragments" bit telling whether additional fragments 126 follow. 128 o Identification is a 32 bit numerical identification value for the 129 entire IPv6 packet. The value is copied into each fragment of the 130 same IPv6 packet. 132 The fragmentation and reassembly specification in [RFC8200] can be 133 considered as the default method which adheres to the details of that 134 RFC. This document presents an enhanced method that allows for 135 retransmissions of individual fragments. 137 4. IPv6 Fragment Retransmission 139 Fragmentation implementations that obey this specification write an 140 "Ordinal Number" beginning with 1 and monotonically incrementing for 141 each successive fragment in the one-octet "Reserved" field of the 142 IPv6 Fragment Header. The Reserved field is then renamed as 143 "Ordinal" as shown below: 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Next Header | Ordinal | Fragment Offset |Res|M| 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Identification | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 In particular, when a source that obeys this specification fragments 152 an IPv6 packet it sets the Ordinal value for the first fragment to 153 '1', the Ordinal value for the second fragment to '2', the Ordinal 154 value for the third fragment to '3', etc. up to the total number of 155 IPv6 fragments. When a destination that obeys this specification 156 receives an IPv6 fragment with the Reserved/Ordinal field set to non- 157 zero, it infers that the source participates in the protocol and 158 maintains a checklist of all Ordinal numbered fragments received for 159 a specific Identification number. 161 If the destination notices one or more Ordinal numbers missing after 162 most other Ordinals for the same Identification have arrived, it can 163 prepare a Fragmentation Report (Fragrep) ICMPv6 message [RFC4443] to 164 send back to the source. The Fragrep message is formatted as 165 follows: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Code | Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Identification (0) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Ordinal Map (0) (0-31) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Ordinal Map (0) (32-63) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Identification (1) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Ordinal Map (1) (0-31) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Ordinal Map (1) (32-63) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | ... | 185 | ... | 187 In this format, the destination prepares the Fragrep message as a 188 list of ordered-triples of 4-octet fields. The first field in each 189 triple includes the Identification value for the IPv6 packet that is 190 subject of the report, while the second and third fields include a 191 64-bit bitmap of the Ordinal values received for this Identification. 192 For example, if the destination receives Ordinals 1, 2, 4, 5, 7, 9, 193 then it sets bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and sets all 194 other bits to '0'. The destination may include as many ordered 195 triples as necessary without the entire Fragrep message exceeding the 196 minimum IPv6 MTU of 1280 bytes. 198 After the destination has assembled the Fragrep message, it transmits 199 the message to the IPv6 source. When the source receives the 200 message, it examines each ordered triple to determine the 201 (Identification, Ordinal) pairs that require retransmission. For 202 example, if the source receives an Ordinal bitmap for Identification 203 0x12345678 with bits 0, 1, 3, 4, 6 and 8 set to '1', it would 204 retransmit Ordinal fragments (0x12345678, 3), (0x12345678, 6) and 205 (0x12345678, 8). 207 This implies that the source should maintain a cache of recently 208 transmitted fragments for a time period known as the "link 209 persistence interval". Then, if the source receives a Fragrep that 210 requests retransmission of one or more Ordinals, it can retransmit if 211 it still holds the Ordinal in its cache. Otherwise, the Ordinal will 212 incur a cache miss and the original source will eventually retransmit 213 the original packet in its entirety. 215 Note: The maximum-sized IPv6 packet that can undergo fragmentation is 216 64KB, and the minimum IPv6 path MTU is 1280B. Assuming the minimum 217 IPv6 path MTU as the nominal size for non-final fragments, the number 218 of Ordinals for each IPv6 packet should be significantly less than 219 the allotted 64 bitmap bits. 221 5. Implementation Status 223 TBD. 225 6. IANA Considerations 227 A new ICMPv6 Message Type code for "Fragmentation Report (Fragrep)" 228 is requested. 230 7. Security Considerations 232 Communications networking security is necessary to preserve 233 confidentiality, integrity and availability. 235 8. Acknowledgements 237 This work was inspired by ongoing AERO/OMNI/DTN investigations. 239 . 241 9. References 243 9.1. Normative References 245 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 246 DOI 10.17487/RFC0791, September 1981, 247 . 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 255 Control Message Protocol (ICMPv6) for the Internet 256 Protocol Version 6 (IPv6) Specification", STD 89, 257 RFC 4443, DOI 10.17487/RFC4443, March 2006, 258 . 260 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 261 Transmission Protocol - Specification", RFC 5326, 262 DOI 10.17487/RFC5326, September 2008, 263 . 265 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 266 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 267 May 2017, . 269 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 270 (IPv6) Specification", STD 86, RFC 8200, 271 DOI 10.17487/RFC8200, July 2017, 272 . 274 9.2. Informative References 276 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful, 277 ACM Sigcomm 1987", August 1987. 279 [I-D.ietf-dtn-bpbis] 280 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle 281 Protocol Version 7", draft-ietf-dtn-bpbis-31 (work in 282 progress), January 2021. 284 [I-D.templin-6man-omni] 285 Templin, F. L. and T. Whyman, "Transmission of IP Packets 286 over Overlay Multilink Network (OMNI) Interfaces", draft- 287 templin-6man-omni-48 (work in progress), October 2021. 289 [MPPS] Majkowski, M., "How to Receive a Million Packets Per 290 Second, https://blog.cloudflare.com/how-to-receive-a- 291 million-packets/", June 2015. 293 [QUIC] Ghedini, A., "Accelerating UDP Packet Transmission for 294 QUIC, https://calendar.perfplanet.com/2019/accelerating- 295 udp-packet-transmission-for-quic/", December 2019. 297 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 298 Errors at High Data Rates", RFC 4963, 299 DOI 10.17487/RFC4963, July 2007, 300 . 302 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 303 RFC 6864, DOI 10.17487/RFC6864, February 2013, 304 . 306 [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 307 T. Voelker, "Packetization Layer Path MTU Discovery for 308 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 309 September 2020, . 311 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 312 and F. Gont, "IP Fragmentation Considered Fragile", 313 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 314 . 316 Author's Address 318 Fred L. Templin (editor) 319 Boeing Research & Technology 320 P.O. Box 3707 321 Seattle, WA 98124 322 USA 324 Email: fltemplin@acm.org