idnits 2.17.1 draft-templin-seal-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1027. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 28, 2008) is 5802 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-manet-smf' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-autoconf-dhcp' is defined on line 848, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-07 == Outdated reference: A later version (-38) exists of draft-templin-autoconf-dhcp-14 -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). 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 Phantom Works 4 Intended status: Informational May 28, 2008 5 Expires: November 29, 2008 7 The Subnetwork Encapsulation and Adaptation Layer (SEAL) 8 draft-templin-seal-14.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 29, 2008. 35 Abstract 37 Subnetworks are connected network regions bounded by border nodes 38 that forward unicast and multicast packets over a virtual topology, 39 often manifested by encapsulation and/or tunneling. This virtual 40 topology may span multiple IP- and/or sub-IP layer forwarding hops, 41 and can introduce failure modes due to packet duplication and/or 42 links with diverse Maximum Transmission Units (MTUs). This document 43 specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that 44 accommodates such virtual topologies over diverse underlying link 45 technologies. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology and Requirements . . . . . . . . . . . . . . . . . 4 51 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 52 4. SEAL Protocol Specification - Tunnel Mode . . . . . . . . . . 6 53 4.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 54 4.2. ITE Specification . . . . . . . . . . . . . . . . . . . . 7 55 4.2.1. Tunnel Interface MTU . . . . . . . . . . . . . . . . . 7 56 4.2.2. Segmentation and Encapsulation . . . . . . . . . . . . 8 57 4.2.3. Packet Identification . . . . . . . . . . . . . . . . 11 58 4.2.4. Sending SEAL Protocol Packets . . . . . . . . . . . . 11 59 4.2.5. Sending S-MSS Probes . . . . . . . . . . . . . . . . . 12 60 4.2.6. Processing Raw ICMPv4 Messages . . . . . . . . . . . . 12 61 4.2.7. Processing SEAL-Encapsulated ICMPv4 Messages . . . . . 12 62 4.3. ETE Specification . . . . . . . . . . . . . . . . . . . . 13 63 4.3.1. Reassembly Buffer Requirements . . . . . . . . . . . . 13 64 4.3.2. IPv4-Layer Reassembly . . . . . . . . . . . . . . . . 14 65 4.3.3. Generating SEAL-Encapsulated ICMPv4 Fragmentation 66 Needed Messages . . . . . . . . . . . . . . . . . . . 14 67 4.3.4. SEAL-Layer Reassembly . . . . . . . . . . . . . . . . 15 68 4.3.5. Decapsulation and Generating ICMPv4 Errors . . . . . . 16 69 5. SEAL Protocol Specification - Transport Mode . . . . . . . . . 16 70 6. Link Requirements . . . . . . . . . . . . . . . . . . . . . . 17 71 7. End System Requirements . . . . . . . . . . . . . . . . . . . 17 72 8. Router Requirements . . . . . . . . . . . . . . . . . . . . . 17 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 79 Appendix A. Historic Evolution of PMTUD (written 10/30/2002) . . 20 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 Intellectual Property and Copyright Statements . . . . . . . . . . 23 83 1. Introduction 85 As Internet technology and communication has grown and matured, many 86 techniques have developed that use virtual topologies (frequently 87 tunnels of one form or another) over an actual IP network. Those 88 virtual topologies have elements which appear as one hop in the 89 virtual topology, but are actually multiple IP or sub-IP layer hops. 90 These multiple hops often have quite diverse properties which are 91 often not even visible to the end-points of the virtual hop. This 92 introduces many failure modes that are not dealt with well in current 93 approaches. 95 The use of IP encapsulation has long been considered as an 96 alternative for creating such virtual topologies. However, the 97 insertion of an outer IP header reduces the effective path MTU as- 98 seen by the IP layer. When IPv4 is used, this reduced MTU can be 99 accommodated through the use of IPv4 fragmentation, but unmitigated 100 in-the-network fragmentation has been shown to be harmful through 101 operational experience and studies conducted over the course of many 102 years [FRAG][FOLK][RFC4963]. Additionally, classical path MTU 103 discovery [RFC1191] has known operational issues that are exacerbated 104 by in-the-network tunnels [RFC2923][RFC4459]. 106 For the purpose of this document, subnetworks are defined as virtual 107 topologies that span connected network regions bounded by 108 encapsulating border nodes. Examples include the global Internet 109 interdomain routing core, Mobile Ad hoc Networks (MANETs) and 110 enterprise networks. Subnetwork border nodes support the Internet 111 protocols [RFC0791][RFC2460] and forward unicast and multicast IP 112 packets over the virtual topology across multiple IP- and/or sub-IP 113 layer forwarding hops which may introduce packet duplication and/or 114 traverse links with diverse Maximum Transmission Units (MTUs). 116 This document proposes a Subnetwork Encapsulation and Adaptation 117 Layer (SEAL) for the operation of IP over subnetworks that connect 118 the Ingress- and Egress Tunnel Endpoints (ITEs/ETEs) of border nodes. 119 SEAL accommodates links with diverse MTUs and supports efficient 120 duplicate packet detection by introducing a minimal mid-layer 121 encapsulation. The SEAL encapsulation introduces an extended 122 Identification field for packet identification and a mid-layer 123 segmentation and reassembly capability that allows simplified cutting 124 and pasting of packets without invoking in-the-network IPv4 125 fragmentation. The SEAL encapsulation layer and protocol is 126 specified in the following sections. 128 2. Terminology and Requirements 130 The term "subnetwork" in this document refers to a virtual topology 131 that is configured over a connected network region bounded by border 132 nodes. 134 The terms "inner", "mid-layer" and "outer" respectively refer to the 135 innermost IP {layer, protocol, header, packet, etc.} before any 136 encapsulation, the mid-layer IP {protocol, header, packet, etc.) 137 after any mid-layer '*' encapsulation and the outermost IP {layer, 138 protocol, header, packet etc.} after SEAL/*/IPv4 encapsulation. 140 The notation IPvX/*/SEAL/*IPvY refers to an inner IPvX packet 141 encapsulated in any mid-layer '*' encapsulations followed by the SEAL 142 header followed by any outer '*' encapsulations followed by an outer 143 IPvY header. The notation "IP" means either IP protocol version 144 (IPv4 or IPv6). 146 The following abbreviations correspond to terms used within this 147 document and elsewhere in common Internetworking nomenclature: 149 Subnetwork - a connected network region bounded by border nodes 151 SEAL - Subnetwork Encapsulation and Adaptation Layer 153 ITE - Ingress Tunnel Endpoint 155 ETE - Egress Tunnel Endpoint 157 MTU - Maximum Transmission Unit 159 MLEN - the length of any mid-layer '*' headers and traliers 161 ENCAPS - the length of the outer encapsulating SEAL/*/IPv4 headers 163 S_MSS - the per-ETE SEAL Maximum Segment Size 165 S_MRU- the per-ETE SEAL Maximum Reassembly Unit 167 PTB - an ICMPv6 "Packet Too Big" or an ICMPv4 "Fragmentation 168 Needed" message 170 FLEN - the MTU value included in an ICMPv4 "Fragmentation Needed" 171 message 172 DF - the IPv4 header "Don't Fragment" flag 174 SEAL-ID - a 32-bit Identification value; randomly initialized and 175 monotonically incremented for each SEAL protocol packet 177 SEAL_PROTO - an IPv4 protocol number used for SEAL 179 SEAL_PORT - a TCP/UDP service port number used for SEAL 181 SEAL_OPTION - a TCP option number used for (transport-mode) SEAL 183 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 184 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 185 document, are to be interpreted as described in [RFC2119]. 187 3. Applicability Statement 189 SEAL was motivated by the specific use case of subnetwork abstraction 190 for Mobile Ad-hoc Networks (MANETs), however the domain of 191 applicability also extends to subnetwork abstractions of enterprise 192 networks, the interdomain routing core, etc. The domain of 193 application therefore also includes the map-and-encaps architecture 194 proposals in the IRTF Routing Research Group (RRG) (see: http:// 195 www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup). 197 SEAL introduces a minimal new sublayer for IPvX in IPvY encapsulation 198 (e.g., as IPv6/SEAL/IPv4), and appears as a subnetwork encapsulation 199 as seen by the inner IP layer. SEAL can also be used as a sublayer 200 for encapsulating inner IP packets within outer UDP/IPv4 header 201 (e.g., as IP/SEAL/UDP/IPv4) such as for the Teredo domain of 202 applicability [RFC4380]. When it appears immediately after the outer 203 IPv4 header, the SEAL header is processed exactly as for IPv6 204 extension headers. 206 SEAL can also be used in "transport-mode", e.g., when the inner layer 207 includes upper layer protocol data rather than an encapsulated IP 208 packet. For instance, TCP peers can negotiate the use of SEAL for 209 the carriage of protocol data encapsulated as TCP/SEAL/IPv4. In this 210 sense, the "subnetwork" becomes the entire end-to-end path between 211 the TCP peers and may potentially span the entire Internet. 213 The current document version is specific to the use of IPv4 as the 214 outer encapsulation layer, however the same principles apply when 215 IPv6 is used as the outer layer. 217 4. SEAL Protocol Specification - Tunnel Mode 219 4.1. Model of Operation 221 SEAL supports the encapsulation of inner IP packets in mid-layer and 222 outer encapsulating headers/trailers. For example, an inner IP 223 packet would appear as IP/*/SEAL/*/IPv4 after mid-layer and outer 224 encapsulations, where '*' denotes zero or more additional 225 encapsulation sublayers. Ingres Tunnel Endpoints (ITEs) add mid- 226 layer '*' and outer SEAL/*/IPv4 encapsulations to the inner packets 227 they inject into a subnetwork, where the outermost IPv4 header 228 contains the source and destination addresses of the subnetwork 229 entry/exit points (i.e., the ITE/ETE), respectively. SEAL defines a 230 new IP protocol type and a new encapsulation sublayer for both 231 unicast and multicast. The ITE encapsulates an inner IP packet in 232 mid-layer and outer encapsulations as shown in Figure 1: 234 +-------------------------+ 235 | | 236 ~ Outer */IPv4 headers ~ 237 | | 238 I +-------------------------+ 239 n | SEAL Header | 240 n +-------------------------+ +-------------------------+ 241 e ~ Any mid-layer * headers ~ ~ Any mid-layer * headers ~ 242 r +-------------------------+ +-------------------------+ 243 | | | | 244 I --> ~ Inner IP ~ --> ~ Inner IP ~ 245 P --> ~ Packet ~ --> ~ Packet ~ 246 | | | | 247 P +-------------------------+ +-------------------------+ 248 a ~ Any mid-layer trailers ~ ~ Any mid-layer trailers ~ 249 c +-------------------------+ +-------------------------+ 250 k ~ Any outer trailers ~ 251 e +-------------------------+ 252 t 253 (After mid-layer encaps.) (After SEAL/*/IPv4 encaps.) 255 Figure 1: SEAL Encapsulation 257 where the SEAL header is inserted as follows: 259 o For simple IP/IPv4 encapsulations (e.g., 260 [RFC2003][RFC2004][RFC4213]), the SEAL header is inserted between 261 the inner IP and outer IPv4 headers as: IP/SEAL/IPv4. 263 o For tunnel-mode IPsec encapsulations over IPv4, [RFC4301], the 264 SEAL header is inserted between the {AH,ESP} header and outer IPv4 265 headers as: IP/*/{AH,ESP}/SEAL/IPv4. 267 o For IP encapsulations over transports such as UDP, the SEAL header 268 is inserted immediately after the outer transport layer header, 269 e.g., as IP/*/SEAL/UDP/IPv4. 271 SEAL-encapsulated packets include a 32-bit SEAL-ID formed from the 272 concatenation of the 16-bit ID Extension field in the SEAL header as 273 the most-significant bits, and with the 16-bit ID value in the outer 274 IPv4 header as the least-significant bits. (For tunnels that 275 traverse IPv4 Network Address Translators, the SEAL-ID is instead 276 maintained only within the 16-bit ID Extension field in the SEAL 277 header.) Routers within the subnetwork use the SEAL-ID for duplicate 278 packet detection, and ITEs/ETEs use the SEAL-ID for SEAL segmentation 279 and reassembly. 281 SEAL enables a multi-level segmentation and reassembly capability. 282 First, the ITE can use IPv4 fragmentation to fragment inner IPv4 283 packets with DF=0 before SEAL encapsulation to avoid lower-level 284 segmentation and reassembly. Secondly, the SEAL layer itself 285 provides a simple mid-layer cutting-and-pasting of mid-layer packets 286 to avoid IPv4 fragmentation on the outer packet. Finally, ordinary 287 IPv4 fragmentation is permitted on the outer packet after SEAL 288 encapsulation and used to detect and dampen any in-the-network 289 fragmentation as quickly as possible. 291 The following sections specifiy the SEAL-related operations of the 292 ITE and ETE, respectively: 294 4.2. ITE Specification 296 4.2.1. Tunnel Interface MTU 298 The ITE configures a tunnel virtual interface over one or more 299 underlying links that connect the border node to the subnetwork. The 300 tunnel interface must present a fixed MTU to the inner IP layer 301 (i.e., Layer 3) as the size for admission of inner IP packets into 302 the tunnel. Since the tunnel interface may support a potentially 303 large set of ETEs, however, care must be taken in setting a greatest- 304 common-denominator MTU for all ETEs while still upholding end system 305 expectations. 307 Due to the ubiquitous deployment of standard Ethernet and similar 308 networking gear, the nominal Internet cell size has become 1500 309 bytes; this is the de facto size that end systems have come to expect 310 will either be delivered by the network without loss due to an MTU 311 restriction on the path or a suitable PTB message returned. However, 312 the network may not always deliver the necessary PTBs, leading to 313 MTU-related black holes [RFC2923]. The ITE therefore requires a 314 means for conveying 1500 byte (or smaller) packets to the ETE without 315 loss due to MTU restrictions and without dependence on PTB messages 316 from within the subnetwork. 318 In common deployments, there may be many forwarding hops between the 319 original source and the ITE. Within those hops, there may be 320 additional encapsulations (IPSec, L2TP, etc.) such that a 1500 byte 321 packet sent by the original source might grow to a larger size by the 322 time it reaches the ITE for encapsulation as an inner IP packet. 323 Similarly, additional encapsulations on the path from the ITE to the 324 ETE could cause the encapsulated packet to become larger still and 325 trigger in-the-network fragmentation. In order to preserve the end 326 system expectations, the ITE therefore requires a means for conveying 327 these larger packets to the ETE even though there may be links within 328 the subnetwork that configure a smaller MTU. 330 The ITE should therefore set a tunnel virtual interface MTU of 1500 331 bytes plus extra room to accommodate any additional encapsulations 332 that may occur on the path from the original source (i.e., even if 333 the underlying links do not support an MTU of this size). The ITE 334 can set larger MTU values still (up to the maximum MTU size of the 335 underlying links), but should select a value that is not so large as 336 to cause excessive PTBs coming from within the tunnel interface (see: 337 Sections 4.2.2 and 4.2.6). The ITE can also set smaller MTU values, 338 however care must be taken not to set so small a value that original 339 sources would experience an MTU underflow. In particular, IPv6 340 sources must see a minimum path MTU of 1280 bytes, and IPv4 sources 341 should see a minimum path MTU of 576 bytes. 343 The inner IP layer consults the tunnel interface MTU when admitting a 344 packet into the interface. For inner IPv4 packets larger than the 345 tunnel interface MTU and with the IPv4 Don't Fragment (DF) bit set to 346 0, the inner IP layer uses IPv4 fragmentation to break the packet 347 into IPv4 fragments no larger than the tunnel interface MTU then 348 admits each fragment into the tunnel as an independent packet. For 349 all other inner packets (IPv4 or IPv6), the ITE admits the packet if 350 it is no larger than the tunnel interface MTU; otherwise, it drops 351 the packet and sends an PTB message with an MTU value of the tunnel 352 interface MTU to the source. 354 4.2.2. Segmentation and Encapsulation 356 The ITE performs segmentation and encapsulation on inner packets that 357 have been admitted into the tunnel interface. The ITE sets 'ENCAPS' 358 to the length of the SEAL/*/IPv4 encapsulating headers and maintains 359 a SEAL Maximum Segment Size (S_MSS) value for each ETE as soft state 360 within the tunnel interface (e.g., in the IPv4 destination cache). 362 The ITE initializes S_MSS to (MTU of the underlying link minus 363 ENCAPS), and decreases or increases S_MSS based on any ICMPv4 364 Fragmentation Needed messages received (see: Section 4.2.6). The ITE 365 additionally maintains a SEAL Maximum Reassembly Unit (S_MRU) value 366 for each ETE. The ITE initializes S_MRU to a value no larger than 367 (2KB -ENCAPS) and uses this value to determine when to set the "Dont 368 Reassemble" bit (see below). 370 The ITE first calculates the length 'MLEN' of any mid-layer '*' 371 headers and trailers (e.g., for '*' = AH, ESP, NULL, etc.) to be 372 added to the inner packet before SEAL/*/IPv4 encapsulation. Next, 373 for inner IPv4 packets with the DF bit set to 0, if the length of the 374 inner packet is larger than (MIN(S_MSS, S_MRU) - MLEN) the ITE uses 375 IPv4 fragmentation to break the packet into IPv4 fragments no larger 376 than (MIN(S_MSS, S_MRU) - MLEN). For unfragmentable inner packets, 377 if the length of the inner packet is larger than (MAX(S_MSS, S_MRU) - 378 MLEN) the ITE drops the packet and sends an PTB message with an MTU 379 value of (MAX(S_MSS, S_MRU) - MLEN) back to the original source. 381 The ITE then encapsulates each inner packet/fragment in any mid-layer 382 '*' headers and trailers. For each such resulting mid-layer packet, 383 if the packet is no larger than S_MRU but is larger than S_MSS, the 384 ITE breaks it into N segments (N <= 16) that are no larger than S_MSS 385 bytes each. Each segment except the final one MUST be of equal 386 length, while the final segment MUST be no larger than the initial 387 segment. The first byte of each segment MUST begin immediately after 388 the final byte of the previous segment, i.e., the segments MUST NOT 389 overlap. 391 Note that this SEAL segmentation is used only for packets that are no 392 larger than S_MRU; packets that are larger than S_MRU (and also no 393 larger than S_MSS) are instead encapsulated as a single SEAL packet. 394 Note also that this SEAL segmentation ignores the DF bit in the inner 395 IPv4 header or (in the case of IPv6) ignores the fact that the 396 network is not permitted to perform IPv6 fragmentation. This 397 segmentation process is a mid-layer (not an IP layer) operation 398 employed by the ITE to adapt the mid-layer packet to the subnetwork 399 path characteristics, and the ETE will restore the inner packet to 400 its original form during decapsulation. Therefore, the fact that the 401 packet may have been segmented within the subnetwork is not 402 observable after decapsulation. 404 The ITE next encapsulates each segment in a SEAL header formatted as 405 follows: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | ID Extension |P|R|D|M|Segment| Next Header | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 2: SEAL Header Format 415 where the header fields are defined as follows: 417 ID Extension (16) 418 a 16-bit extension of the ID field in the outer IPv4 header; 419 encodes the most-significant 16 bits of a 32 bit SEAL-ID value. 421 P (1) 422 the "Probe" bit. Set to 1 if the ITE wishes to receive an 423 explicit acknowledgement from the ETE. 425 R (1) 426 the "Report Fragmentation" bit. Set to 1 if the ITE wishes to 427 receive a report from the ETE if any IPv4 fragmentation occurs. 429 D (1) 430 the "Dont Reassemble" bit. Set to 1 if the reassembled SEAL 431 protocol packet is to be discarded by the ETE if any IPv4 432 reassemly is required. 434 M (1) 435 the "More Segments" bit. Set to 1 if this SEAL protocol packet 436 contains a non-final segment of a multi-segment mid-layer packet. 438 Segment (4) 439 a 4-bit Segment number. Encodes a segment number between 0 - 15. 441 Next Header (8) an 8-bit field that encodes an IP protocol number 442 the same as for the IPv4 protocol and IPv6 next header fields. 444 For single-segment mid-layer packets, the ITE encapsulates the 445 segment in a SEAL header with (M=0; Segment=0). For N-segment mid- 446 layer packets (N <= 16), the ITE encapsulates each segment in a SEAL 447 header with (M=1; Segment=0) for the first segment, (M=1; Segment=1) 448 for the second segment, etc., with the final segment setting (M=0; 449 Segment=N-1). For each SEAL-encapsulated packet with Segment=0, the 450 ITE sets D=0 in the SEAL header if the ETE is permitted to reassemble 451 the packet if it arrives as multiple IPv4 fragments and/or SEAL 452 segments; in particular, the ITE sets D=0 in the SEAL header for all 453 mid-layer packets no larger than S_MRU. The ITE instead sets D=1 in 454 the SEAL header if the ETE is to discard the packet if it arrives as 455 multiple IPv4 fragments and/or SEAL segments; in particular, the ITE 456 sets D=1 in the SEAL header for all mid-layer packets larger than 457 S_MRU. 459 The ITE next sets the P and R bits in the SEAL header of each segment 460 as specified in Section 4.2.5, then writes the IP protocol number 461 corresponding to the mid-layer packet in the SEAL 'Next Header' 462 field. Next, the ITE encapsulates the segment in the requisite 463 */IPv4 outer headers according to the specific encapsulation format 464 (e.g., [RFC2003], [RFC4213], [RFC4380], etc.), except that it writes 465 'SEAL_PROTO' in the protocol field of the outer IPv4 header (when 466 simple IPv4 encapsualtion is used) or writes 'SEAL_PORT' in the outer 467 destination service port field (e.g., when UDP/IPv4 encapsulation is 468 used). The ITE finally sets packet identification values and sends 469 the packets as described in the following sections. 471 4.2.3. Packet Identification 473 For the purpose of packet identification, the ITE maintains a 32-bit 474 SEAL-ID value as per-ETE soft state, e.g. in the IPv4 destination 475 cache. The ITE randomly-initializes SEAL-ID when the soft state is 476 created and monotonically increments it (modulo 2^32) for each 477 successive SEAL protocol packet it sends to the ETE. For each 478 packet, the ITE writes the least-significant 16 bits of the SEAL-ID 479 value in the ID field in the outer IPv4 header, and writes the most- 480 significant 16 bits in the ID Extension field in the SEAL header. 482 For tunnels that may traverse an IPv4 Network Address Translator 483 (NAT), the ITE instead maintains SEAL-ID as a 16-bit value that it 484 randomly-initializes when the soft state is created and monotonically 485 increments (modulo 2^16) for each successive SEAL protocol packet. 486 For each packet, the ITE writes SEAL-ID in the ID extension field of 487 the SEAL header and writes a random 16-bit value in the ID field in 488 the outer IPv4 header. This requires that both the ITE and ETE 489 participate in this alternate scheme. 491 4.2.4. Sending SEAL Protocol Packets 493 Following SEAL segmentation and encapsulation, the ITE sets DF=0 in 494 the outer IPv4 header of every outer packet it sends. 496 The ITE then sends each outer packet that encapsulates a segment of 497 the same mid-layer packet into the tunnel in canonical order, i.e., 498 Segment 0 first, then Segment 1, etc. and finally Segment N-1. 500 4.2.5. Sending S-MSS Probes 502 When S_MSS is larger than 128, the ITE sends SEAL packets as implicit 503 probes to detect in-the-network IPv4 fragmentation. The ITE sets R=1 504 in the SEAL header and DF=0 in the outer IPv4 header of each segment 505 of a SEAL-segmented packet to be used as an implicit probe, and will 506 receive ICMPv4 Fragmentation Needed messages from the ETE if any IPv4 507 fragmentation occurs. When S_MSS=128, the ITE instead sets R=0 in 508 the SEAL header to avoid generating fragmentation reports for 509 unavoidable in-the-network fragmentation. 511 The ITE additionally sends explicit probes periodically to manage a 512 window of SEAL-IDs of outstanding probes that allows the ITE to 513 validate any ICMPv4 Fragmentation Needed messages it receives. The 514 ITE sets P=1 in the SEAL header and DF=0 in the IPv4 header of each 515 segment of a SEAL-segmented packet to be used as an explicit probe, 516 where the probe can be either an ordinary data packet or a NULL 517 packet created by setting the 'Next Header' field in the SEAL header 518 to a value of "No Next Header". 520 The ITE should periodically probe to detect increases in the path MTU 521 to the ETE. The ITE can 1) reset S_MSS to the MTU of the underlying 522 link minus ENCAPS, and/or 2) send probes that are larger than S_MSS 523 using either a NULL packet or an ordinary data packet that is padded 524 at the end by setting the outer IPv4 length field to a larger value 525 than the packet's true length. 527 4.2.6. Processing Raw ICMPv4 Messages 529 The ITE may receive "raw" ICMPv4 messages from routers within the 530 subnetwork that comprise an outer IPv4 header followed by an ICMPv4 531 header followed by the (IPv4 header, SEAL header and inner packet 532 portion) from the packet-in-error. For such messages, the ITE can 533 use the 32-bit SEAL ID encoded in the packet-in-error as a nonce to 534 confirm that the ICMP message came from an on-path router within the 535 subnetwork. The ITE MAY process raw ICMPv4 messages other than 536 ICMPv4 Fragmentation Needed as soft errors indicating that the path 537 to the ETE may be failing. The ITE discards any raw ICMPv4 538 Fragmentation Needed messages, since all SEAL-encapsulated packets 539 set DF=0 in the outer IPv4 header and hence no router within the 540 subnetwork should return such an error. 542 4.2.7. Processing SEAL-Encapsulated ICMPv4 Messages 544 In addition to any raw ICMPv4 messages, the ITE may receive SEAL- 545 encapsulated ICMPv4 messages from subnetwork border nodes that 546 comprise outer ICMPv4/*/SEAL/*/IPv4 headers followed by the (IPv4 547 header, SEAL header and inner packet portion) from the packet-in- 548 error. The ITE can use the 32-bit SEAL ID encoded in the packet-in- 549 error as well as the outer IPv4 and SEAL headers as nonces to confirm 550 that the ICMP message came from the correct ETE. The ITE then 551 discards the outer headers and verifies that the SEAL-ID embedded in 552 the ICMPv4-encapsulated packet-in-error is within the current window 553 of outstanding probes for this ETE. If the SEAL-ID is outside of the 554 window, the ITE discards the message; otherwise, it advances the 555 window and processes the message. 557 The ITE processes SEAL-encapsulated ICMPv4 messages other than ICMPv4 558 Fragmentation Needed exactly as specified in [RFC0792]. For SEAL- 559 encapsulated ICMPv4 Fragmentation Needed messages, the ITE first 560 verifies that the message was formatted correctly per Section 4.3.3. 561 Next, the ITE sets a variable 'FLEN' to the value encoded in the MTU 562 field of the ICMPv4 Fragmentation Needed message. If (FLEN-ENCAPS) 563 is smaller than S_MSS and the packet-in-error did not undergo IPv4 564 fragmentation, the ITE discards the message; otherwise, it re- 565 calculates S_MSS as follows: 567 if (FLEN-ENCAPS) is more than S_MSS or FLEN is at least 576 568 set S_MSS to (FLEN-ENCAPS) 569 else 570 set S_MSS to the maximum of S_MSS/2 and 128 571 endif 573 The "576" in the S_MSS calculation above is the nominal minimum MTU 574 for common IPv4 links and accounts for normal-case IPv4 first 575 fragments, while the "else" clause institutes a "limited halving" 576 factor that accounts for unusual cases in which the ETE receives a 577 small IPv4 first-fragment [RFC1812]. This limited halving may 578 require multiple iterations of sending probes and receiving ICMPv4 579 Fragmentation Needed messages, but will soon converge to a stable 580 value for S_MSS. 582 After deterimining a new value for S_MSS, if the IPv4 header of the 583 packet-in-error has M=1 and its SEAL header has D=1, the ITE discards 584 the SEAL/*/IPv4 and any mid-layer '*' headers/trailers (of length 585 MLEN) and encapsulates the remaining inner IP packet portion in an 586 PTB messsage to send back to the original source, with the MTU field 587 set to (MAX(S_MRU, S_MSS) - MLEN). 589 4.3. ETE Specification 591 4.3.1. Reassembly Buffer Requirements 593 ETEs MUST be capable of using IPv4-layer reassembly to reassemble 594 SEAL protocol outer packets of at least 2KB bytes, and MUST also be 595 capable of using SEAL-layer reassembly to reassemble mid-layer 596 packets of (2KB-ENCAPS). 598 4.3.2. IPv4-Layer Reassembly 600 The ETE performs IPv4 reassembly as-normal, and should maintain a 601 conservative high- and low-water mark for the number of outstanding 602 reassemblies pending for each ITE. When the size of the reassembly 603 buffer exceeds this high-water mark, the ETE actively discards 604 incomplete reassemblies (e.g., using an Active Queue Management (AQM) 605 strategy) until the size falls below the low-water mark. The ETE 606 should also use a reduced IPv4 maximum segment lifetime value (e.g., 607 15 seconds), i.e., the time after which it will discard an incomplete 608 IPv4 reassembly for a SEAL protocol packet. 610 After reassembly, the ETE either accepts or discards the reassembled 611 packet based on the current status of the IPv4 reassembly cache 612 (congested vs uncongested). The SEAL-ID included in the IPv4 first- 613 fragment can also provide an additional level of reassembly 614 assurance, since it can record a distinct arrival timestamp useful 615 for associating the first-fragment with its corresponding non-initial 616 fragments. The choice of accepting/discarding a reassembly may also 617 depend on the strength of the upper-layer integrity check if known 618 (e.g., IPSec/ESP provides a strong upper-layer integrity check) 619 and/or the corruption tolerance of the data (e.g., multicast 620 streaming audio/video may be more corruption-tolerant than file 621 transfer, etc.). In the limiting case, the ETE may choose to discard 622 all IPv4 reassemblies and process only the IPv4 first-fragment for 623 SEAL-encapsulated error generation purposes (see the following 624 sections). 626 4.3.3. Generating SEAL-Encapsulated ICMPv4 Fragmentation Needed 627 Messages 629 During IPv4-layer reassembly, the ETE determines whether the packet 630 belongs to the SEAL protocol by checking for SEAL_PROTO in the outer 631 IPv4 header (i.e., for simple IPv4 encapsulation) or for SEAL_PORT in 632 the outer */IPv4 header (e.g., for '*'=UDP). 634 When the ETE receives the IPv4 first-fragment of a SEAL protocol 635 packet that was delivered as multiple IPv4 fragments and with (R=1; 636 Segment=0) in the SEAL header, it sends a SEAL-encapsulated ICMPv4 637 Fragmentation Needed message back to the ITE. The ETE also sends a 638 SEAL-encapsulated ICMPv4 Fragmentation Needed message for any SEAL 639 packet with (P=1; Segment=0), i.e., even if the packet was not 640 fragmented and while treating the unfragmented packet the same as a 641 first-fragment. Note that ICMPv4 Fragmentation Needed messages are 642 therefore generated only for SEAL packets with Segment=0; they are 643 not generated for any other SEAL packets. 645 The ETE prepares the ICMPv4 Fragmentation Needed message by 646 encapsulating as much of the IPv4 first fragment as possible in outer 647 */SEAL/*/IPv4 headers without the length of the message exceeding 576 648 bytes as shown in Figure 3: 650 +-------------------------+ - 651 | | \ 652 ~ Outer */SEAL/*/IPv4 hdrs~ | 653 | | | 654 +-------------------------+ | 655 | ICMPv4 Header | | 656 |(Dest Unreach; Frag Need)| | 657 +-------------------------+ | 658 | | > Up to 576 bytes 659 ~ IP/*/SEAL/*/IPv4 ~ | 660 ~ hdrs of first-fragment ~ | 661 | | | 662 +-------------------------+ | 663 | | | 664 ~ Data of first-fragment ~ | 665 | | / 666 +-------------------------+ - 668 Figure 3: SEAL-encapsulated ICMPv4 Fragmentation Needed Message 670 The ETE next sets D=0, P=0, R=0, M=0 and Segment=0 in the outer SEAL 671 header, sets the SEAL-ID the same as for any SEAL packet, then sets 672 the SEAL Next Header field and the fields of the outer */IPv4 headers 673 the same as for ordinay SEAL encapsulation (see: Sections 4.2.2 and 674 4.2.3). The ETE then sets outer IPv4 destination address to the 675 source address of the first-fragment and sets the outer IPv4 source 676 address to the destination address of the first-fragment. If the 677 destination address in the first-fragment was multicast, the ETE 678 instead sets the outer IPv4 source address to an address assigned to 679 the underlying IPv4 interface. The ETE finally sends the SEAL- 680 encapsulated ICMPv4 message to the ITE the same as specified in 681 Section 4.2.4. 683 4.3.4. SEAL-Layer Reassembly 685 Following IPv4 reassembly of a SEAL protocol packet and (if 686 necessary) generation of a ICMPv4 Fragmentation Needed message, the 687 ETE adds the SEAL packet to a SEAL-Layer pending-reassembly queue (if 688 necessary). If the packet arrived as multiple IPv4 fragments and 689 with D=1 in the SEAL header, the ETE marks the packet as "discard 690 following reassembly". The ETE also marks the packet as "discard 691 following reassembly" if the (Next Header, P, R, D) fields of the 692 packet's SEAL header differ from their respective values in other 693 SEAL segments already in the queue, i.e., the (Next Header, P, R, 694 D)-tuple serves as a reassembly nonce. 696 The ETE performs SEAL-layer reassembly for multi-segment mid-layer 697 packets through simple in-order concatenation of the encapsulated 698 segments from N consecutive SEAL protocol packets from the same mid- 699 layer packet. SEAL-layer reassembly requires the ETE to maintain a 700 cache of recently received SEAL packet segments for a hold time that 701 would allow for reasonable inter-segment delays. The ETE uses a SEAL 702 maximum segment lifetime of 15 seconds for this purpose, i.e., the 703 time after which it will discard an incomplete reassembly. However, 704 the ETE should also actively discard any pending reassemblies that 705 clearly have no opportunity for completion, e.g., when a considerable 706 number of new SEAL packets have been received before a packet that 707 completes a pending reassembly has arrived. 709 The ETE reassembles the mid-layer packet segments in SEAL protocol 710 packets that contain Segment numbers 0 through N-1, with M=1/0 in 711 non-final/final segments, respectively, and with consecutive SEAL-ID 712 values. That is, for an N-segment mid-layer packet, reassembly 713 entails the concatenation of the SEAL-encapsulated segments with 714 (Segment 0, SEAL-ID i), followed by (Segment 1, SEAL-ID ((i + 1) mod 715 2^32)), etc. up to (Segment N-1, SEAL-ID ((i + N-1) mod 2^32)). (For 716 tunnels that may traverse an IPv4 NAT, the ETE instead uses only a 717 16-bit SEAL-ID value, and uses mod 2^16 arithmetic to associate the 718 segments of the same packet.) 720 4.3.5. Decapsulation and Generating ICMPv4 Errors 722 Following SEAL-layer reassembly, if the packet had the value "No Next 723 Header" in the SEAL header's Next Header field, or if the packet was 724 marked "discard following reassembly" the ETE silently discards the 725 reassembled mid-layer packet; otherwise, the ETE decapsulates the 726 inner packet and processes it as normal. If the ETE determines that 727 the decapsulated inner packet cannot be processed further, it drops 728 the packet and prepares an appropriate SEAL-encapsulated ICMPv4 error 729 message. The ETE then sends the SEAL-encapsulated ICMPv4 error 730 message back to the ITE exactly as for ICMPv4 Fragmentation Needed 731 messages (See: Section 4.3.3). 733 5. SEAL Protocol Specification - Transport Mode 735 Section 4 specifies the operation of SEAL in "tunnel mode", i.e., 736 when there is both an inner and outer IP layer and with a SEAL 737 encapsulation layer between. However, SEAL also can be used in a 738 "transport mode" of operation in which the inner layer corresponds to 739 an upper layer protocol (e.g., UDP, TCP, etc.) instead of an 740 additional IP layer. 742 For example, two TCP endpoints connected to the same subnetwork 743 region can negotiate the use of transport-mode SEAL for a connection 744 by inserting a 'SEAL_OPTION' TCP option during the connection 745 establishment phase. If both TCPs agree on the use of SEAL, their 746 protocol messages will be carriaged as TCP/SEAL/IPv4 and will 747 otherwise utilize the same specifications as for Section 4. 749 6. Link Requirements 751 Subnetwork designers are strongly encouraged to follow the 752 recommendations in [RFC3819] when configuring link MTUs, where all 753 IPv4 links SHOULD configure a minimum MTU of 576 bytes. Links that 754 cannot configure an MTU of at least 576 bytes (e.g., due to 755 performance characteristics) SHOULD implement transparent link-layer 756 segmentation and reassembly such that an MTU of at least 576 can 757 still be presented to the IP layer. 759 7. End System Requirements 761 SEAL provides robust mechanisms for returning PTB messages to the 762 original source, however end systems that send unfragmentable IP 763 packets larger than 1500 bytes are strongly encouraged to use 764 Packetization Layer Path MTU Discovery per [RFC4821]. 766 8. Router Requirements 768 IPv4 routers within the subnetwork observe the requirements in 769 [RFC1812], and are strongly encouraged to implement IPv4 770 fragmentation such that the first fragment is the largest and 771 approximately the size of the underlying link MTU. 773 9. IANA Considerations 775 SEAL_PROTO, SEAL_PORT and SEAL_OPTION are taken from their respective 776 range of experimental values documented in [RFC3692][RFC4727]. These 777 values are for experimentation purposes only, and not to be used for 778 any kind of deployments (i.e., they are not to be shipped in any 779 products). This document therefore has no actions for IANA. 781 10. Security Considerations 783 Unlike IPv4 fragmentation, overlapping fragment attacks are not 784 possible due to the requirement that SEAL segments be non- 785 overlapping. 787 An amplification/reflection attack is possible when an attacker sends 788 IPv4 first-fragments with spoofed source addresses to an ETE, 789 resulting in a stream of ICMPv4 Fragmentation Needed messages 790 returned to a victim ITE. The encapsulated segment of the spoofed 791 IPv4 first-fragment provides mitigation for the ITE to detect and 792 discard spurious ICMPv4 Fragmentation Needed messages. 794 The SEAL header is sent in-the-clear (outside of any IPsec/ESP 795 encapsulations) the same as for the IPv4 header. As for IPv6 796 extension headers, the SEAL header is protected only by L2 integrity 797 checks and is not covered under any L3 integrity checks. 799 11. Acknowledgments 801 Path MTU determination through the report of fragmentation 802 experienced by the final destination was first proposed by Charles 803 Lynn of BBN on the TCP-IP mailing list in May 1987. An historical 804 analysis of the evolution of path MTU discovery appears in 805 http://www.tools.ietf.org/html/draft-templin-v6v4-ndisc-01 and is 806 reproduced in Appendix A of this document. 808 The following individuals are acknowledged for helpful comments and 809 suggestions: Jari Arkko, Fred Baker, Teco Boot, Iljitsch van Beijnum, 810 Brian Carpenter, Steve Casner, Ian Chakeres, Remi Denis-Courmont, 811 Aurnaud Ebalard, Gorry Fairhurst, Joel Halpern, John Heffner, Bob 812 Hinden, Christian Huitema, Joe Macker, Matt Mathis, Dan Romascanu, 813 Dave Thaler, Joe Touch, Magnus Westerlund, Robin Whittle, James 814 Woodyatt and members of the Boeing PhantomWorks DC&NT group. 816 12. References 818 12.1. Normative References 820 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 821 September 1981. 823 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 824 RFC 792, September 1981. 826 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 827 RFC 1812, June 1995. 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 833 (IPv6) Specification", RFC 2460, December 1998. 835 12.2. Informative References 837 [FOLK] C, C., D, D., and k. k, "Beyond Folklore: Observations on 838 Fragmented Traffic", December 2002. 840 [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 841 October 1987. 843 [I-D.ietf-manet-smf] 844 Macker, J. and S. Team, "Simplified Multicast Forwarding 845 for MANET", draft-ietf-manet-smf-07 (work in progress), 846 February 2008. 848 [I-D.templin-autoconf-dhcp] 849 Templin, F., Russert, S., and S. Yi, "The MANET Virtual 850 Ethernet (VET) Abstraction", 851 draft-templin-autoconf-dhcp-14 (work in progress), 852 April 2008. 854 [MTUDWG] "IETF MTU Discovery Working Group mailing list, 855 gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log, November 856 1989 - February 1995.". 858 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 859 MTU discovery options", RFC 1063, July 1988. 861 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 862 November 1990. 864 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 865 for IP version 6", RFC 1981, August 1996. 867 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 868 October 1996. 870 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 871 October 1996. 873 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 874 RFC 2923, September 2000. 876 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 877 Considered Useful", BCP 82, RFC 3692, January 2004. 879 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 880 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 881 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 882 RFC 3819, July 2004. 884 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 885 for IPv6 Hosts and Routers", RFC 4213, October 2005. 887 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 888 Internet Protocol", RFC 4301, December 2005. 890 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 891 Network Address Translations (NATs)", RFC 4380, 892 February 2006. 894 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 895 Network Tunneling", RFC 4459, April 2006. 897 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 898 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 900 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 901 Discovery", RFC 4821, March 2007. 903 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 904 Errors at High Data Rates", RFC 4963, July 2007. 906 [TCP-IP] "TCP-IP mailing list archives, 907 http://www-mice.cs.ucl.ac.uk/multimedia/mist/tcpip, May 908 1987 - May 1990.". 910 Appendix A. Historic Evolution of PMTUD (written 10/30/2002) 912 The topic of Path MTU discovery (PMTUD) saw a flurry of discussion 913 and numerous proposals in the late 1980's through early 1990. The 914 initial problem was posed by Art Berggreen on May 22, 1987 in a 915 message to the TCP-IP discussion group [TCP-IP]. The discussion that 916 followed provided significant reference material for [FRAG]. An IETF 917 Path MTU Discovery Working Group [MTUDWG] was formed in late 1989 918 with charter to produce an RFC. Several variations on a very few 919 basic proposals were entertained, including: 921 1. Routers record the PMTUD estimate in ICMP-like path probe 922 messages (proposed in [FRAG] and later [RFC1063]) 924 2. The destination reports any fragmentation that occurs for packets 925 received with the "RF" (Report Fragmentation) bit set (Steve 926 Deering's 1989 adaptation of Charles Lynn's Nov. 1987 proposal) 928 3. A hybrid combination of 1) and Charles Lynn's Nov. 1987 proposal 929 (straw RFC draft by McCloughrie, Fox and Mogul on Jan 12, 1990) 931 4. Combination of the Lynn proposal with TCP (Fred Bohle, Jan 30, 932 1990) 934 5. Fragmentation avoidance by setting "IP_DF" flag on all packets 935 and retransmitting if ICMPv4 "fragmentation needed" messages 936 occur (Geof Cooper's 1987 proposal; later adapted into [RFC1191] 937 by Mogul and Deering). 939 Option 1) seemed attractive to the group at the time, since it was 940 believed that routers would migrate more quickly than hosts. Option 941 2) was a strong contender, but repeated attempts to secure an "RF" 942 bit in the IPv4 header from the IESG failed and the proponents became 943 discouraged. 3) was abandoned because it was perceived as too 944 complicated, and 4) never received any apparent serious 945 consideration. Proposal 5) was a late entry into the discussion from 946 Steve Deering on Feb. 24th, 1990. The discussion group soon 947 thereafter seemingly lost track of all other proposals and adopted 948 5), which eventually evolved into [RFC1191] and later [RFC1981]. 950 In retrospect, the "RF" bit postulated in 2) is not needed if a 951 "contract" is first established between the peers, as in proposal 4) 952 and a message to the MTUDWG mailing list from jrd@PTT.LCS.MIT.EDU on 953 Feb 19. 1990. These proposals saw little discussion or rebuttal, and 954 were dismissed based on the following the assertions: 956 o routers upgrade their software faster than hosts 958 o PCs could not reassemble fragmented packets 960 o Proteon and Wellfleet routers did not reproduce the "RF" bit 961 properly in fragmented packets 963 o Ethernet-FDDI bridges would need to perform fragmentation (i.e., 964 "translucent" not "transparent" bridging) 966 o the 16-bit IP_ID field could wrap around and disrupt reassembly at 967 high packet arrival rates 969 The first four assertions, although perhaps valid at the time, have 970 been overcome by historical events leaving only the final to 971 consider. But, [FOLK] has shown that IP_ID wraparound simply does 972 not occur within several orders of magnitude the reassembly timeout 973 window on high-bandwidth networks. 975 (Authors 2/11/08 note: this final point was based on a loose 976 interpretation of [FOLK], and is more accurately addressed in 977 [RFC4963].) 979 Author's Address 981 Fred L. Templin (editor) 982 Boeing Phantom Works 983 P.O. Box 3707 984 Seattle, WA 98124 985 USA 987 Email: fltemplin@acm.org 989 Full Copyright Statement 991 Copyright (C) The IETF Trust (2008). 993 This document is subject to the rights, licenses and restrictions 994 contained in BCP 78, and except as set forth therein, the authors 995 retain all their rights. 997 This document and the information contained herein are provided on an 998 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 999 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1000 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1001 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1002 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1003 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1005 Intellectual Property 1007 The IETF takes no position regarding the validity or scope of any 1008 Intellectual Property Rights or other rights that might be claimed to 1009 pertain to the implementation or use of the technology described in 1010 this document or the extent to which any license under such rights 1011 might or might not be available; nor does it represent that it has 1012 made any independent effort to identify any such rights. Information 1013 on the procedures with respect to rights in RFC documents can be 1014 found in BCP 78 and BCP 79. 1016 Copies of IPR disclosures made to the IETF Secretariat and any 1017 assurances of licenses to be made available, or the result of an 1018 attempt made to obtain a general license or permission for the use of 1019 such proprietary rights by implementers or users of this 1020 specification can be obtained from the IETF on-line IPR repository at 1021 http://www.ietf.org/ipr. 1023 The IETF invites any interested party to bring to its attention any 1024 copyrights, patents or patent applications, or other proprietary 1025 rights that may cover technology that may be required to implement 1026 this standard. Please address the information to the IETF at 1027 ietf-ipr@ietf.org.