idnits 2.17.1 draft-templin-intarea-seal-65.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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == 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 date (October 21, 2013) is 3839 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3971' is defined on line 1714, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: 'RFC0768' is defined on line 1758, but no explicit reference was found in the text == Unused Reference: 'RFC1063' is defined on line 1766, but no explicit reference was found in the text == Unused Reference: 'RFC1146' is defined on line 1773, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 1828, but no explicit reference was found in the text == Unused Reference: 'RFC4987' is defined on line 1849, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1856, but no explicit reference was found in the text == Unused Reference: 'RFC5445' is defined on line 1862, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 1878, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-taylor-v6ops-fragdrop-01 == Outdated reference: A later version (-16) exists of draft-templin-ironbis-15 -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) -- Obsolete informational reference (is this intentional?): RFC 1146 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 8 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 Research & Technology 4 Obsoletes: rfc5320 (if approved) October 21, 2013 5 Updates: rfc2460 (if approved) 6 Intended status: Standards Track 7 Expires: April 24, 2014 9 The Subnetwork Encapsulation and Adaptation Layer (SEAL) 10 draft-templin-intarea-seal-65.txt 12 Abstract 14 This document specifies a Subnetwork Encapsulation and Adaptation 15 Layer (SEAL). SEAL operates over virtual topologies configured over 16 connected IP network routing regions bounded by encapsulating border 17 nodes. These virtual topologies are manifested by tunnels that may 18 span multiple IP and/or sub-IP layer forwarding hops, where they may 19 incur packet duplication, packet reordering, source address spoofing 20 and traversal of links with diverse Maximum Transmission Units 21 (MTUs). SEAL addresses these issues through the encapsulation and 22 messaging mechanisms specified in this document. 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 http://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 April 24, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.3. Differences with RFC5320 . . . . . . . . . . . . . . . . . 7 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 10 65 5. SEAL Specification . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. SEAL Tunnel Model . . . . . . . . . . . . . . . . . . . . 11 67 5.2. SEAL Model of Operation . . . . . . . . . . . . . . . . . 12 68 5.3. SEAL Encapsulation Format . . . . . . . . . . . . . . . . 14 69 5.4. ITE Specification . . . . . . . . . . . . . . . . . . . . 16 70 5.4.1. Tunnel MTU . . . . . . . . . . . . . . . . . . . . . . 16 71 5.4.2. Tunnel Neighbor Soft State . . . . . . . . . . . . . . 17 72 5.4.3. SEAL Layer Pre-Processing . . . . . . . . . . . . . . 18 73 5.4.4. SEAL Encapsulation and Segmentation . . . . . . . . . 19 74 5.4.5. Outer Encapsulation . . . . . . . . . . . . . . . . . 21 75 5.4.6. Path Probing and ETE Reachability Verification . . . . 21 76 5.4.7. Processing ICMP Messages . . . . . . . . . . . . . . . 22 77 5.4.8. IPv4 Middlebox Reassembly Testing . . . . . . . . . . 24 78 5.4.9. Stateful MTU Determination . . . . . . . . . . . . . . 25 79 5.4.10. Detecting Path MTU Changes . . . . . . . . . . . . . . 25 80 5.5. ETE Specification . . . . . . . . . . . . . . . . . . . . 25 81 5.5.1. Reassembly Buffer Requirements . . . . . . . . . . . . 25 82 5.5.2. Tunnel Neighbor Soft State . . . . . . . . . . . . . . 26 83 5.5.3. IP-Layer Reassembly . . . . . . . . . . . . . . . . . 26 84 5.5.4. Decapsulation, SEAL-Layer Reassembly, and 85 Re-Encapsulation . . . . . . . . . . . . . . . . . . . 27 86 5.6. The SEAL Control Message Protocol (SCMP) . . . . . . . . . 28 87 5.6.1. Generating SCMP Messages . . . . . . . . . . . . . . . 29 88 5.6.2. Processing SCMP Messages . . . . . . . . . . . . . . . 31 89 6. Link Requirements . . . . . . . . . . . . . . . . . . . . . . 33 90 7. End System Requirements . . . . . . . . . . . . . . . . . . . 33 91 8. Router Requirements . . . . . . . . . . . . . . . . . . . . . 33 92 9. Nested Encapsulation Considerations . . . . . . . . . . . . . 34 93 10. Reliability Considerations . . . . . . . . . . . . . . . . . . 34 94 11. Integrity Considerations . . . . . . . . . . . . . . . . . . . 34 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 96 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 97 14. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 36 99 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 100 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 101 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 102 17.2. Informative References . . . . . . . . . . . . . . . . . . 38 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 105 1. Introduction 107 As Internet technology and communication has grown and matured, many 108 techniques have developed that use virtual topologies (manifested by 109 tunnels of one form or another) over an actual network that supports 110 the Internet Protocol (IP) [RFC0791][RFC2460]. Those virtual 111 topologies have elements that appear as one network layer hop, but 112 are actually multiple IP or sub-IP layer hops. These multiple hops 113 often have quite diverse properties that are often not even visible 114 to the endpoints of the virtual hop. This introduces failure modes 115 that are not dealt with well in current approaches. 117 The use of IP encapsulation (also known as "tunneling") has long been 118 considered as the means for creating such virtual topologies (e.g., 119 see [RFC2003][RFC2473]). Tunnels serve a wide variety of purposes, 120 including mobility, security, routing control, traffic engineering, 121 multihoming, etc., and will remain an integral part of the 122 architecture moving forward. However, the encapsulation headers 123 often include insufficiently provisioned per-packet identification 124 values. IP encapsulation also allows an attacker to produce 125 encapsulated packets with spoofed source addresses even if the source 126 address in the encapsulating header cannot be spoofed. A denial-of- 127 service vector that is not possible in non-tunneled subnetworks is 128 therefore presented. 130 Additionally, the insertion of an outer IP header reduces the 131 effective path MTU visible to the inner network layer. When IPv6 is 132 used as the encapsulation protocol, original sources expect to be 133 informed of the MTU limitation through IPv6 Path MTU discovery 134 (PMTUD) [RFC1981]. When IPv4 is used, this reduced MTU can be 135 accommodated through the use of IPv4 fragmentation, but unmitigated 136 in-the-network fragmentation has been found to be harmful through 137 operational experience and studies conducted over the course of many 138 years [FRAG][FOLK][RFC4963]. Additionally, classical IPv4 PMTUD 139 [RFC1191] has known operational issues that are exacerbated by in- 140 the-network tunnels [RFC2923][RFC4459]. 142 The following subsections present further details on the motivation 143 and approach for addressing these issues. 145 1.1. Motivation 147 Before discussing the approach, it is necessary to first understand 148 the problems. In both the Internet and private-use networks today, 149 IP is ubiquitously deployed as the Layer 3 protocol. The primary 150 functions of IP are to provide for routing, addressing, and a 151 fragmentation and reassembly capability used to accommodate links 152 with diverse MTUs. While it is well known that the IP address space 153 is rapidly becoming depleted, there is also a growing awareness that 154 other IP protocol limitations have already or may soon become 155 problematic. 157 First, the Internet historically provided no means for discerning 158 whether the source addresses of IP packets are authentic. This 159 shortcoming is being addressed more and more through the deployment 160 of site border router ingress filters [RFC2827], however the use of 161 encapsulation provides a vector for an attacker to circumvent 162 filtering for the encapsulated packet even if filtering is correctly 163 applied to the encapsulation header. Secondly, the IP header does 164 not include a well-behaved identification value unless the source has 165 included a fragment header for IPv6 or unless the source permits 166 fragmentation for IPv4. These limitations preclude an efficient 167 means for routers to detect duplicate packets and packets that have 168 been re-ordered within the subnetwork. Additionally, recent studies 169 have shown that the arrival of fragments at high data rates can cause 170 denial-of-service (DoS) attacks on performance-sensitive networking 171 gear, prompting some administrators to configure their equipment to 172 drop fragments unconditionally [I-D.taylor-v6ops-fragdrop]. 174 For IPv4 encapsulation, when fragmentation is permitted the header 175 includes a 16-bit Identification field, meaning that at most 2^16 176 unique packets with the same (source, destination, protocol)-tuple 177 can be active in the network at the same time [RFC6864]. (When 178 middleboxes such as Network Address Translators (NATs) re-write the 179 Identification field to random values, the number of unique packets 180 is even further reduced.) Due to the escalating deployment of high- 181 speed links, however, these numbers have become too small by several 182 orders of magnitude for high data rate packet sources such as tunnel 183 endpoints [RFC4963]. 185 Furthermore, there are many well-known limitations pertaining to IPv4 186 fragmentation and reassembly - even to the point that it has been 187 deemed "harmful" in both classic and modern-day studies (see above). 188 In particular, IPv4 fragmentation raises issues ranging from minor 189 annoyances (e.g., in-the-network router fragmentation [RFC1981]) to 190 the potential for major integrity issues (e.g., mis-association of 191 the fragments of multiple IP packets during reassembly [RFC4963]). 193 As a result of these perceived limitations, a fragmentation-avoiding 194 technique for discovering the MTU of the forward path from a source 195 to a destination node was devised through the deliberations of the 196 Path MTU Discovery Working Group (MTUDWG) during the late 1980's 197 through early 1990's which resulted in the publication of [RFC1191]. 198 In this negative feedback-based method, the source node provides 199 explicit instructions to routers in the path to discard the packet 200 and return an ICMP error message if an MTU restriction is 201 encountered. However, this approach has several serious shortcomings 202 that lead to an overall "brittleness" [RFC2923]. 204 In particular, site border routers in the Internet have been known to 205 discard ICMP error messages coming from the outside world. This is 206 due in large part to the fact that malicious spoofing of error 207 messages in the Internet is trivial since there is no way to 208 authenticate the source of the messages [RFC5927]. Furthermore, when 209 a source node that requires ICMP error message feedback when a packet 210 is dropped due to an MTU restriction does not receive the messages, a 211 path MTU-related black hole occurs. This means that the source will 212 continue to send packets that are too large and never receive an 213 indication from the network that they are being discarded. This 214 behavior has been confirmed through documented studies showing clear 215 evidence of PMTUD failures for both IPv4 and IPv6 in the Internet 216 today [TBIT][WAND][SIGCOMM][RIPE]. 218 The issues with both IP fragmentation and this "classical" PMTUD 219 method are exacerbated further when IP tunneling is used [RFC4459]. 220 For example, an ingress tunnel endpoint (ITE) may be required to 221 forward encapsulated packets into the subnetwork on behalf of 222 hundreds, thousands, or even more original sources. If the ITE 223 allows IP fragmentation on the encapsulated packets, persistent 224 fragmentation could lead to undetected data corruption due to 225 Identification field wrapping and/or reassembly congestion at the 226 ETE. If the ITE instead uses classical IP PMTUD it must rely on ICMP 227 error messages coming from the subnetwork that may be suspect, 228 subject to loss due to filtering middleboxes, or insufficiently 229 provisioned for translation into error messages to be returned to the 230 original sources. 232 Although recent works have led to the development of a positive 233 feedback-based end-to-end MTU determination scheme [RFC4821], they do 234 not excuse tunnels from accounting for the encapsulation overhead 235 they add to packets. Moreover, in current practice existing 236 tunneling protocols mask the MTU issues by selecting a "lowest common 237 denominator" MTU that may be much smaller than necessary for most 238 paths and difficult to change at a later date. Therefore, a new 239 approach to accommodate tunnels over links with diverse MTUs is 240 necessary. 242 1.2. Approach 244 This document concerns subnetworks manifested through a virtual 245 topology configured over a connected network routing region and 246 bounded by encapsulating border nodes. Example connected network 247 routing regions include Mobile Ad hoc Networks (MANETs), enterprise 248 networks and the global public Internet itself. Subnetwork border 249 nodes forward unicast and multicast packets over the virtual topology 250 across multiple IP and/or sub-IP layer forwarding hops that may 251 introduce packet duplication and/or traverse links with diverse 252 Maximum Transmission Units (MTUs). 254 This document introduces a Subnetwork Encapsulation and Adaptation 255 Layer (SEAL) for tunneling inner network layer protocol packets over 256 IP subnetworks that connect Ingress and Egress Tunnel Endpoints 257 (ITEs/ETEs) of border nodes. It provides a modular specification 258 designed to be tailored to specific associated tunneling protocols. 259 (A transport-mode of operation is also possible but out of scope for 260 this document.) 262 SEAL provides a mid-layer encapsulation that accommodates links with 263 diverse MTUs, and allows routers in the subnetwork to perform 264 efficient duplicate packet and packet reordering detection. The 265 encapsulation further ensures message origin authentication, packet 266 header integrity and anti-replay in environments in which these 267 functions are necessary. 269 SEAL treats tunnels that traverse the subnetwork as ordinary links 270 that must support network layer services. Moreover, SEAL provides 271 dynamic mechanisms (including limited segmentation and reassembly) to 272 ensure a maximal path MTU over the tunnel. This is in contrast to 273 static approaches which avoid MTU issues by selecting a lowest common 274 denominator MTU value that may be overly conservative for the vast 275 majority of tunnel paths and difficult to change even when larger 276 MTUs become available. 278 1.3. Differences with RFC5320 280 This specification of SEAL is descended from an experimental 281 independent RFC publication of the same name [RFC5320]. However, 282 this specification introduces a number of fundamental differences 283 from the earlier publication. This specification therefore obsoletes 284 (i.e., and does not update) [RFC5320]. 286 First, this specification includes a protocol version field in the 287 SEAL header whereas [RFC5320] does not, and therefore cannot be 288 updated by future revisions. Secondly, [RFC5320] forms a 32-bit 289 Identification value by concatenating the 16-bit IPv4 Identification 290 field with a 16-bit Identification "extension" field in the SEAL 291 header. This means that [RFC5320] can only operate over IPv4 292 networks (since IPv6 headers do not include a 16-bit version number) 293 and that the SEAL Identification value can be corrupted if the 294 Identification in the outer IPv4 header is rewritten. In contrast, 295 this specification includes a 32-bit Identification value that is 296 independent of any identification fields found in the inner or outer 297 IP headers, and is therefore compatible with any inner and outer IP 298 protocol version combinations. 300 Additionally, the SEAL segmentation and reassembly procedures defined 301 in [RFC5320] differ significantly from those found in this 302 specification. In particular, this specification defines an 13-bit 303 Offset field that allows for finer-grained segment sizes when SEAL 304 segmentation is necessary. In contrast, [RFC5320] includes only a 305 3-bit Segment field and performs reassembly through concatenation of 306 consecutive segments. 308 This version of SEAL also includes an optional Integrity Check Vector 309 (ICV) that can be used to digitally sign the SEAL header and the 310 leading portion of the encapsulated inner packet. This allows for a 311 lightweight integrity check and a loose message origin authentication 312 capability. The header further includes new control bits as well as 313 a link identification field for additional control capabilities. 315 Finally, this version of SEAL includes a new messaging protocol known 316 as the SEAL Control Message Protocol (SCMP), whereas [RFC5320] 317 performs signalling through the use of SEAL-encapsulated ICMP 318 messages. The use of SCMP allows SEAL-specific departures from ICMP, 319 as well as a control messaging capability that extends to other 320 specifications, including Virtual Enterprise Traversal (VET) 321 [I-D.templin-intarea-vet]. 323 2. Terminology 325 The following terms are defined within the scope of this document: 327 subnetwork 328 a virtual topology configured over a connected network routing 329 region and bounded by encapsulating border nodes. 331 IP 332 used to generically refer to either Internet Protocol (IP) 333 version, i.e., IPv4 or IPv6. 335 Ingress Tunnel Endpoint (ITE) 336 a portal over which an encapsulating border node (host or router) 337 sends encapsulated packets into the subnetwork. 339 Egress Tunnel Endpoint (ETE) 340 a portal over which an encapsulating border node (host or router) 341 receives encapsulated packets from the subnetwork. 343 SEAL Path 344 a subnetwork path from an ITE to an ETE beginning with an 345 underlying link of the ITE as the first hop. Note that, if the 346 ITE's interface connection to the underlying link assigns multiple 347 IP addresses, each address represents a separate SEAL path. 349 inner packet 350 an unencapsulated network layer protocol packet (e.g., IPv4 351 [RFC0791], OSI/CLNP [RFC0994], IPv6 [RFC2460], etc.) before any 352 outer encapsulations are added. Internet protocol numbers that 353 identify inner packets are found in the IANA Internet Protocol 354 registry [RFC3232]. SEAL protocol packets that incur an 355 additional layer of SEAL encapsulation are also considered inner 356 packets. 358 outer IP packet 359 a packet resulting from adding an outer IP header (and possibly 360 other outer headers) to a SEAL-encapsulated inner packet. 362 packet-in-error 363 the leading portion of an invoking data packet encapsulated in the 364 body of an error control message (e.g., an ICMPv4 [RFC0792] error 365 message, an ICMPv6 [RFC4443] error message, etc.). 367 Packet Too Big (PTB) message 368 a control plane message indicating an MTU restriction (e.g., an 369 ICMPv6 "Packet Too Big" message [RFC4443], an ICMPv4 370 "Fragmentation Needed" message [RFC0792], etc.). 372 Don't Fragment (DF) bit 373 a bit that indicates whether the packet may be fragmented by the 374 network. The DF bit is explicitly included in the IPv4 header 375 [RFC0791] and may be set to '0' to allow fragmentation or '1' to 376 disallow further in-network fragmentation. The bit is absent from 377 the IPv6 header [RFC2460], but implicitly set to '1' because 378 fragmentation can occur only at IPv6 sources. 380 The following abbreviations correspond to terms used within this 381 document and/or elsewhere in common Internetworking nomenclature: 383 HLEN - the length of the SEAL header plus outer headers 385 ICV - Integrity Check Vector 387 MAC - Message Authentication Code 389 MTU - Maximum Transmission Unit 390 SCMP - the SEAL Control Message Protocol 392 SDU - SCMP Destination Unreachable message 394 SPP - SCMP Parameter Problem message 396 SPTB - SCMP Packet Too Big message 398 SEAL - Subnetwork Encapsulation and Adaptation Layer 400 TE - Tunnel Endpoint (i.e., either ingress or egress) 402 VET - Virtual Enterprise Traversal 404 3. Requirements 406 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 407 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 408 document are to be interpreted as described in [RFC2119]. When used 409 in lower case (e.g., must, must not, etc.), these words MUST NOT be 410 interpreted as described in [RFC2119], but are rather interpreted as 411 they would be in common English. 413 4. Applicability Statement 415 SEAL was originally motivated by the specific case of subnetwork 416 abstraction for Mobile Ad hoc Networks (MANETs), however the domain 417 of applicability also extends to subnetwork abstractions over 418 enterprise networks, mobile networks, ISP networks, SO/HO networks, 419 the global public Internet itself, and any other connected network 420 routing region. 422 SEAL provides a network sublayer for encapsulation of an inner 423 network layer packet within outer encapsulating headers. SEAL can 424 also be used as a sublayer within a transport layer protocol data 425 payload, where transport layer encapsulation is typically used for 426 Network Address Translator (NAT) traversal as well as operation over 427 subnetworks that give preferential treatment to certain "core" 428 Internet protocols, e.g., TCP, UDP, etc. (However, note that TCP 429 encapsulation may not be appropriate for all use cases; particularly 430 those that require low delay and/or delay variance.) The SEAL header 431 is processed in the same manner as for IPv6 extension headers, i.e., 432 it is not part of the outer IP header but rather allows for the 433 creation of an arbitrarily extensible chain of headers in the same 434 way that IPv6 does. 436 To accommodate MTU diversity, the Ingress Tunnel Endpoint (ITE) may 437 need to perform limited segmentation which the Egress Tunnel Endpoint 438 (ETE) reassembles. The ETE further acts as a passive observer that 439 informs the ITE of any packet size limitations. This allows the ITE 440 to return appropriate PMTUD feedback even if the network path between 441 the ITE and ETE filters ICMP messages. 443 SEAL further provides mechanisms to ensure message origin 444 authentication, packet header integrity, and anti-replay. The SEAL 445 framework is therefore similar to the IP Security (IPsec) 446 Authentication Header (AH) [RFC4301][RFC4302], however it provides 447 only minimal hop-by-hop authenticating services while leaving full 448 data integrity, authentication and confidentiality services as an 449 end-to-end consideration. 451 In many aspects, SEAL also very closely resembles the Generic Routing 452 Encapsulation (GRE) framework [RFC1701]. SEAL can therefore be 453 applied in the same use cases that are traditionally addressed by 454 GRE, but goes beyond GRE to also provide additional capabilities 455 (e.,g., path MTU accommodation, message origin authentication, etc.) 456 as described in this document. The SEAL header is also exactly 457 analogous to the IPv6 Fragment Header, and in fact shares the same 458 format. SEAL can therefore re-use most existing code that implements 459 IPv6 fragmentation and reassembly. 461 In practice, SEAL is typically used as an encapsulation sublayer in 462 conjunction with existing tunnel types such as IPsec, GRE, IP-in-IPv6 463 [RFC2473], IP-in-IPv4 [RFC4213][RFC2003], etc. When used with 464 existing tunnel types that insert mid-layer headers between the inner 465 and outer IP headers (e.g., IPsec, GRE, etc.), the SEAL header is 466 inserted between the mid-layer headers and outer IP header. 468 5. SEAL Specification 470 The following sections specify the operation of SEAL: 472 5.1. SEAL Tunnel Model 474 SEAL is an encapsulation sublayer used within point-to-point, point- 475 to-multipoint, and non-broadcast, multiple access (NBMA) tunnels. 476 Each SEAL path is configured over one or more underlying interfaces 477 attached to subnetwork links. The SEAL tunnel connects an ITE to one 478 or more ETE "neighbors" via encapsulation across an underlying 479 subnetwork, where the tunnel neighbor relationship may be 480 bidirectional, partially unidirectional or fully unidirectional. 482 A bidirectional tunnel neighbor relationship is one over which both 483 TEs can exchange both data and control messages. A partially 484 unidirectional tunnel neighbor relationship allows the near end ITE 485 to send data packets forward to the far end ETE, while the far end 486 only returns control messages when necessary. Finally, a fully 487 unidirectional mode of operation is one in which the near end ITE can 488 receive neither data nor control messages from the far end ETE. 490 Implications of the SEAL bidirectional and unidirectional models are 491 the same as discussed in [I-D.templin-intarea-vet]. 493 5.2. SEAL Model of Operation 495 SEAL-enabled ITEs encapsulate each inner packet in any ancillary 496 tunnel protocol headers, a SEAL header, any outer header 497 encapsulations and in some instances a SEAL trailer as shown in 498 Figure 1: 500 +--------------------+ 501 ~ outer IP header ~ 502 +--------------------+ 503 ~ other outer hdrs ~ 504 +--------------------+ 505 ~ SEAL Header ~ 506 +--------------------+ 507 ~ tunnel headers ~ 508 +--------------------+ +--------------------+ 509 | | --> | | 510 ~ Inner ~ --> ~ Inner ~ 511 ~ Packet ~ --> ~ Packet ~ 512 | | --> | | 513 +--------------------+ +--------------------+ 514 ~ SEAL Trailer ~ 515 +--------------------+ 517 Figure 1: SEAL Encapsulation 519 The ITE inserts the SEAL header according to the specific tunneling 520 protocol. For simple encapsulation of an inner network layer packet 521 within an outer IP header, the ITE inserts the SEAL header following 522 the outer IP header and before the inner packet as: IP/SEAL/{inner 523 packet}. 525 For encapsulations over transports such as UDP, the ITE inserts the 526 SEAL header following the outer transport layer header and before the 527 inner packet, e.g., as IP/UDP/SEAL/{inner packet}. In that case, the 528 UDP header is seen as an "other outer header" as depicted in Figure 1 529 and the outer IP and transport layer headers are together seen as the 530 outer encapsulation headers. (Note that outer transport layer 531 headers such as UDP must sometimes be included to ensure that SEAL 532 packets will traverse the path to the ETE without loss due filtering 533 middleboxes. The ETE MUST accept both IP/SEAL and IP/UDP/SEAL as 534 equivalent packets so that the ITE can discontinue outer transport 535 layer encapsulation if the path supports raw IP/SEAL encapsulation.) 537 For SEAL encapsulations that involve tunnel types that include 538 ancillary tunnel headers (e.g., GRE, IPsec, etc.) the ITE inserts the 539 SEAL header as a leading extension to the tunnel headers, i.e., the 540 SEAL encapsulation appears as part of the same tunnel and not a 541 separate tunnel. For example, for GRE the ITE iserts the SEAL header 542 as IP/SEAL/GRE/{inner packet}, and for IPsec the ITE inserts the SEAL 543 header as IP/SEAL/IPsec-header/{inner packet}/IPsec-trailer. In such 544 cases, SEAL considers the length of the inner packet only (i.e., and 545 not the other tunnel headers and trailers) when performing its packet 546 size calculations. 548 SEAL supports both "nested" tunneling and "re-encapsulating" 549 tunneling. Nested tunneling occurs when a first tunnel is 550 encapsulated within a second tunnel, which may then further be 551 encapsulated within additional tunnels. Nested tunneling can be 552 useful, and stands in contrast to "recursive" tunneling which is an 553 anomalous condition incurred due to misconfiguration or a routing 554 loop. Considerations for nested tunneling and avoiding recursive 555 tunneling are discussed in Section 4 of [RFC2473] as well as in 556 Section 9 of this document. 558 Re-encapsulating tunneling occurs when a packet arrives at a first 559 ETE, which then acts as an ITE to re-encapsulate and forward the 560 packet to a second ETE connected to the same subnetwork. In that 561 case each ITE/ETE transition represents a segment of a bridged path 562 between the ITE nearest the source and the ETE nearest the 563 destination. Considerations for re-encapsulating tunneling are 564 discussed in[I-D.templin-ironbis]. Combinations of nested and re- 565 encapsulating tunneling are also naturally supported by SEAL. 567 The SEAL ITE considers each underlying interface as the ingress 568 attachment point to a separate SEAL path to the ETE. The ITE 569 therefore may experience different path MTUs on different SEAL paths. 571 Finally, the SEAL ITE ensures that the inner network layer protocol 572 will see a minimum MTU of 1500 bytes over each SEAL path regardless 573 of the outer network layer protocol version, i.e., even if a small 574 amount of segmentation and reassembly are necessary. This is to 575 avoid path MTU "black holes" for the minimum MTU configured by the 576 vast majority of links in the Internet. Note that in some scenarios, 577 however, reassembly may place a heavy burden on the ETE. In that 578 case, the ITE can avoid invoking segmentation and instead report an 579 MTU smaller than 1500 bytes to the original source. 581 5.3. SEAL Encapsulation Format 583 SEAL encapsulates each inner packet within any ancillary tunneling 584 protocol headers and a SEAL header. The SEAL header shares the same 585 format as the IPv6 Fragment Header [RFC2460] and is identified by the 586 same IP protocol number assigned for the IPv6 Fragment Header (type 587 '44') [I-D.ietf-6man-ext-transmit]. The SEAL header is 588 differentiated from the IPv6 Fragment Header by including a non-zero 589 value in the most significant two bits of the IPv6 Fragment Header 590 "Reserved" field; these two bits will heretofore serve as a SEAL 591 protocol version number. SEAL therefore updates the IPv6 Fragment 592 Header specification found in [RFC2460]. 594 The SEAL header is formatted as shown in Figure 2: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Next Header |VER|LINK |I|R|Z| Fragment Offset |C|P|M| 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Identification | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 2: SEAL Encapsulation Format 606 The fields of the SEAL header are formatted as follows: 608 Next Header (8) an 8-bit field that encodes the next header Internet 609 Protocol number the same as for the IPv4 protocol and IPv6 next 610 header fields. 612 VER (2) 613 a 2-bit version field. This document specifies Version 1 of the 614 SEAL protocol, i.e., the VER field encodes the value '01'. 616 LINK (3) 617 a 3-bit link identification value, set to a unique value by the 618 ITE for each SEAL path over which it will send encapsulated 619 packets to the ETE (up to 8 SEAL paths per ETE are therefore 620 supported). Note that, if the ITE's interface connection to the 621 underlying link assigns multiple IP addresses, each address 622 represents a separate SEAL path that must be assigned a separate 623 link ID. 625 I (1) 626 the "Integrity Check Vector (ICV) included" bit. 628 R (1) 629 the "Redirects Permitted" bit when used by VET (see: 630 [I-D.templin-intarea-vet]); reserved for future use in other 631 contexts. 633 Z (1) 634 a 1-bit Reserved field. Initialized to zero for transmission; 635 ignored on reception. 637 Fragment Offset (13) a 13-bit Offset field. The offset, in 8-octet 638 units, of the data following this header. 640 C (1) 641 the "Control/Data" bit. Set to 1 by the ITE in SEAL Control 642 Message Protocol (SCMP) control messages, and set to 0 in ordinary 643 data packets. 645 P (1) 646 The "Probe" bit when C=0; set to 1 by the ITE in SEAL probe data 647 packets for which it wishes to receive an explicit acknowledgement 648 from the ETE. The "Pass" bit when C=1; set to 1 by the ETE in 649 SCMP messages it relays to the ITE on behalf of another SEAL path. 651 M (1) the "More Segments" bit. Set to 1 in a non-final segment and 652 set to 0 in the final segment of the SEAL packet. 654 Identification (32) 655 a 32-bit per-packet identification field. Set to a randomly- 656 initialized 32-bit value that is monotonically-incremented for 657 each SEAL packet transmitted to this ETE. 659 When an IIntegrity Check Vector (ICV) is included, it is added as a 660 trailing field at the end of the SEAL packet. The ICV is formatted 661 as shown in Figure 3: 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |F|Key|Algorithm| Message Authentication Code (MAC) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 667 Figure 3: Integrity Check Vector (ICV) Format 669 As shown in the figure, the ICV begins with a 1-octet control field 670 with a 1-bit (F)lag, a 2-bit Key identifier and a 5-bit Algorithm 671 identifier. The control octet is followed by a variable-length 672 Message Authentication Code (MAC). The ITE maintains a per ETE 673 algorithm and secret key to calculate the MAC in each packet it will 674 send to this ETE. (By default, the ITE sets the F bit and Algorithm 675 fields to 0 to indicate use of the HMAC-SHA-1 algorithm with a 160 676 bit shared secret key to calculate an 80 bit MAC per [RFC2104] over 677 the leading 128 bytes of the packet. Other values for F and 678 Algorithm are out of scope.) 680 5.4. ITE Specification 682 5.4.1. Tunnel MTU 684 The tunnel must present a stable MTU value to the inner network layer 685 as the size for admission of inner packets into the tunnel. Since 686 tunnels may support a large set of SEAL paths that accept widely 687 varying maximum packet sizes, however, a number of factors should be 688 taken into consideration when selecting a tunnel MTU. 690 Due to the ubiquitous deployment of standard Ethernet and similar 691 networking gear, the nominal Internet cell size has become 1500 692 bytes; this is the de facto size that end systems have come to expect 693 will either be delivered by the network without loss due to an MTU 694 restriction on the path or a suitable ICMP Packet Too Big (PTB) 695 message returned. When large packets sent by end systems incur 696 additional encapsulation at an ITE, however, they may be dropped 697 silently within the tunnel since the network may not always deliver 698 the necessary PTBs [RFC2923]. The ITE SHOULD therefore set a tunnel 699 MTU of at least 1500 bytes and provide accommodations to ensure that 700 packets up to that size are successfully conveyed to the ETE. 702 The inner network layer protocol consults the tunnel MTU when 703 admitting a packet into the tunnel. For non-SEAL inner IPv4 packets 704 with the IPv4 Don't Fragment (DF) bit cleared (i.e, DF==0), if the 705 packet is larger than the tunnel MTU the inner IPv4 layer uses IPv4 706 fragmentation to break the packet into fragments no larger than the 707 MTU. The ITE then admits each fragment into the tunel as an 708 independent packet. 710 For all other inner packets, the inner network layer admits the 711 packet if it is no larger than the tunnel MTU; otherwise, it drops 712 the packet and sends a PTB error message to the source with the MTU 713 value set to the MTU. The message contains as much of the invoking 714 packet as possible without the entire message exceeding the network 715 layer minimum MTU size. 717 The ITE can alternatively set an indefinite tunnel MTU such that all 718 inner packets are admitted into the tunnel regardless of their size 719 (theoretical maximums are 64KB for IPv4 and 4GB for IPv6 [RFC2675]). 720 For ITEs that host applications that use the tunnel directly, this 721 option must be carefully coordinated with protocol stack upper layers 722 since some upper layer protocols (e.g., TCP) derive their packet 723 sizing parameters from the MTU of the outgoing interface and as such 724 may select too large an initial size. This is not a problem for 725 upper layers that use conservative initial maximum segment size 726 estimates and/or when the tunnel can reduce the upper layer's maximum 727 segment size, e.g., by reducing the size advertised in the MSS option 728 of outgoing TCP messages (sometimes known as "MSS clamping"). 730 In light of the above considerations, the ITE SHOULD configure an 731 indefinite MTU on *router* tunnels so that SEAL performs all 732 subnetwork adaptation from within the tunnel as specified in the 733 following sections. The ITE MAY instead set a smaller MTU on *host* 734 tunnels; in that case, the RECOMMENDED MTU is the maximum of 1500 735 bytes and the smallest MTU among all of the underlying links minus 736 the size of the encapsulation headers. 738 5.4.2. Tunnel Neighbor Soft State 740 The ITE maintains a number of soft state variables for each ETE and 741 for each SEAL path. 743 The ITE maintains a per ETE window of Identification values for the 744 packets it has recently sent to this ETE as welll as a per ETE window 745 of Identification values for the packets it has recently received 746 from this ETE. The ITE then includes an Identification in each 747 packet it sends to this ETE. 749 When message origin authentication and integrity checking is 750 required, the ITE sets a variable "USE_ICV" to TRUE, and includes a 751 trailing ICV in each packet it sends to this ETE; otherwise, it sets 752 USE_ICV to FALSE. 754 For each SEAL path, the ITE must also account for encapsulation 755 header lengths. The ITE therefore maintains the per SEAL path 756 constant values "SHLEN" set to the length of the SEAL header and 757 trailer, "THLEN" set to the length of the outer encapsulating 758 transport layer headers (or 0 if outer transport layer encapsulation 759 is not used), "IHLEN" set to the length of the outer IP layer header, 760 and "HLEN" set to (SHLEN+THLEN+IHLEN). (The ITE must include the 761 length of the uncompressed headers even if header compression is 762 enabled when calculating these lengths.) When SEAL is used in 763 conjunction with another tunnel type such as GRE or IPsec, the length 764 of the headers associated with those tunnels is also included in the 765 HLEN calculation for the first segment only and the length of the 766 associated trailers is included in the HLEN calculation for the final 767 segment only. 769 The ITE maintains a per SEAL path variable "MAXMTU" initialized to 770 the maximum of (1500+HLEN) bytes and the MTU of the underlying link. 771 The ITE further sets a variable 'MINMTU' to the minimum MTU for the 772 SEAL path over which encapsulated packets will travel. For IPv6 773 paths, the ITE sets MINMTU=1280 per [RFC2460]. For IPv4 paths, the 774 ITE sets MINMTU=576 based on practical interpretation of [RFC1122] 775 even though the theoretical MINMTU for IPv4 is only 68 bytes 776 [RFC0791]. 778 The ITE can also set MINMTU to a larger value if there is reason to 779 believe that the minimum path MTU is larger, or to a smaller value if 780 there is reason to believe the MTU is smaller, e.g., if there may be 781 additional encapsulations on the path. If this value proves too 782 large, the ITE will receive PTB message feedback either from the ETE 783 or from a router on the path and will be able to reduce its MINMTU to 784 a smaller value. (Note that since IPv4 links with MTUs smaller than 785 1280 are presumably peformance-constrained, the ITE can instead 786 initialize MINMTU to 1280 the same as for IPv6. If this value proves 787 too large, standard IPv4 fragmentation and reassembly will provide 788 short term accommodation for the sizing constraints while the ITE 789 readjusts its MINMTU estimate.) 791 The ITE may instead maintain the packet sizing variables and 792 constants as per ETE (rather than per SEAL path) values. In that 793 case, the values reflect the smallest MTU size across all of the SEAL 794 paths associated with this ETE. 796 5.4.3. SEAL Layer Pre-Processing 798 The SEAL layer is logically positioned between the inner and outer 799 network protocol layers, where the inner layer is seen as the (true) 800 network layer and the outer layer is seen as the (virtual) data link 801 layer. Each packet to be processed by the SEAL layer is either 802 admitted into the tunnel by the inner network layer protocol as 803 described in Section 5.4.1 or is undergoing re-encapsulation from 804 within the tunnel. The SEAL layer sees the former class of packets 805 as inner packets that include inner network and transport layer 806 headers, and sees the latter class of packets as transitional SEAL 807 packets that include the outer and SEAL layer headers that were 808 inserted by the previous hop SEAL ITE. For these transitional 809 packets, the SEAL layer re-encapsulates the packet with new outer and 810 SEAL layer headers when it forwards the packet to the next hop SEAL 811 ITE. 813 We now discuss the SEAL layer pre-processing actions for these two 814 classes of packets. 816 5.4.3.1. Inner Packet Pre-Processing 818 For each for non-SEAL IPv4 inner packet with DF==0 in the IP header 819 and IPv6 inner packet with a fragment header and with (MF=0; 820 Offset=0), if the packet is larger than (MINMTU-HLEN) the ITE uses IP 821 fragmentation to fragment the packet into N pieces, where N is 822 minimized. (For IPv6 as the inner protocol, the first fragment MUST 823 be at least as large as the IPv6 minimum of 1280 bytes so that the 824 entire IPv6 header chain is likely to fit within the first segment.) 825 The ITE then submits each fragment for SEAL encapsulation as 826 specified in Section 5.4.4. 828 For all other inner packets, if the packet is no larger than (MAXMTU- 829 HLEN) for the corresponding SEAL path the ITE submits it for SEAL 830 encapsulation as specified in Section 5.4.4. Otherwise, the ITE 831 drops the packet and sends an ordinary PTB message appropriate to the 832 inner protocol version (subject to rate limiting) with the MTU field 833 set to (MAXMTU-HLEN). (For IPv4 SEAL packets with DF==0, the ITE 834 SHOULD set DF=1 and re-calculate the IPv4 header checksum before 835 generating the PTB message in order to avoid bogon filters.) After 836 sending the PTB message, the ITE discards the inner packet. 838 5.4.3.2. Transitional SEAL Packet Pre-Processing 840 For each transitional packet that is to be processed by the SEAL 841 layer from within the tunnel, if the packet is larger than MAXMTU 842 bytes for the next hop SEAL path the ITE sends an SCMP Packet Too Big 843 (SPTB) message to the previous hop subject to rate limiting with the 844 MTU field set to MAXMTU and with (C=1; P=1) in the SEAL header (see: 845 Section 5.6.1.1). After sending the SPTB message, the ITE discards 846 the packet. Otherwise, the ITE sets aside the encapsulating SEAL and 847 outer headers and submits the inner packet for SEAL re-encapsulation 848 as specified in Section 5.4.4. (Note that in the calculation for 849 MAXMTU, HLEN for the next hop SEAL path may be different than HLEN 850 for the previous hop. In that case, MAXMTU must reflect the smaller 851 of the two HLEN values.) 853 5.4.4. SEAL Encapsulation and Segmentation 855 For each inner packet/fragment submitted for SEAL encapsulation, the 856 ITE next encapsulates the packet in a SEAL header formatted as 857 specified in Section 5.3. The ITE next sets (C=0; P=0), sets LINK to 858 the value assigned to the underlying SEAL path, and sets the Next 859 Header field to the protocol number corresponding to the address 860 family of the encapsulated inner packet. For example, the ITE sets 861 the Next Header field to the value '4' for encapsulated IPv4 packets 862 [RFC2003], '41' for encapsulated IPv6 packets [RFC2473][RFC4213], 863 '47' for GRE [RFC1701], '80' for encapsulated OSI/CLNP packets 865 [RFC1070], etc. 867 Next, if the inner packet is no larger than (MINMTU-HLEN) or larger 868 than 1500, the ITE sets (M=0; Fragment Offset=0). Otherwise, the ITE 869 breaks the inner packet into N non-overlapping segments, where N is 870 minimized. For IPv6 as the inner protocol, the resulting 871 encapsulated SEAL packet containing the first segment MUST be at 872 least as large as the IPv6 minimum of 1280 bytes so that the entire 873 IPv6 header chain is likely to fit within the first segment. (Since 874 the Fragment Offset field indicates the number of 8 byte units, 875 however, if HLEN is not an integer multiple of 8 bytes the 876 encapsulated SEAL packet MAY contain up to 7 bytes less than 1280 so 877 that the IPv6 minimum MTU is not exceeded.) 879 The ITE then appends a clone of the SEAL header from the first 880 segment onto the head of each additional segment. The ITE then sets 881 (M=1; Fragment Offset=0) in the first segment, sets (M=0/1; Fragment 882 Offset=O(1)) in the second segment, sets (M=0/1; Fragment 883 Offset=O(2)) in the third segment (if needed), etc., then finally 884 sets (M=0; Fragment Offset=O(n)) in the final segment (where O(i) is 885 the number of 256 byte blocks that preceded this segment). 887 The ITE then writes a monotonically-incrementing integer value for 888 this ETE in the Identification field beginning with a randomly- 889 initialized value in the first packet transmitted. (For SEAL packets 890 that have been split into multiple pieces, the ITE writes the same 891 Identification value in each piece.) The monotonically-incrementing 892 requirement is to satisfy ETEs that use this value for anti-replay 893 purposes. The value is incremented modulo 2^32, i.e., it wraps back 894 to 0 when the previous value was (2^32 - 1). 896 When USE_ICV is FALSE, the ITE next sets I=0. Otherwise, the ITE 897 sets I=1, includes a trailing ICV and calculates the MAC using HMAC- 898 SHA-1 with a 160 bit secret key and 80 bit MAC field. Beginning with 899 the SEAL header, the ITE calculates the MAC over the leading 128 900 bytes of the packet (or up to the end of the packet if there are 901 fewer than 128 bytes) and places the result in the MAC field. (For 902 SEAL packets that have been split into multiple pieces, each piece 903 calculates its own MAC.) The ITE then writes the value 0 in the F 904 flag and 0x00 in the Algorithm field of the ICV control octet (other 905 values for these fields, and other MAC calculation disciplines, are 906 outside the scope of this document and may be specified in future 907 documents.) 909 If the packet is undergoing SEAL re-encapsulation, the ITE then 910 copies the R value from the SEAL header of the packet to be re- 911 encapsulated. Otherwise, it sets R=0 unless otherwise specified in 912 other documents that employ SEAL. The ITE then adds the outer 913 encapsulating headers as specified in Section 5.4.5. 915 5.4.5. Outer Encapsulation 917 Following SEAL encapsulation, the ITE next encapsulates each segment 918 in the requisite outer transport (when necessary) and IP layer 919 headers. When a transport layer header such as UDP or TCP is 920 included, the ITE writes the port number for SEAL in the transport 921 destination service port field. 923 When UDP encapsulation is used, the ITE sets the UDP checksum field 924 to zero for IPv4 packets and also sets the UDP checksum field to zero 925 for IPv6 packets even though IPv6 generally requires UDP checksums. 926 Further considerations for setting the UDP checksum field for IPv6 927 packets are discussed in [RFC6935][RFC6936]. 929 The ITE then sets the outer IP layer headers the same as specified 930 for ordinary IP encapsulation (e.g., [RFC1070][RFC2003], [RFC2473], 931 [RFC4213], etc.) except that for ordinary SEAL packets the ITE copies 932 the "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 933 Experienced" values in the inner network layer header into the 934 corresponding fields in the outer IP header. For transitional SEAL 935 packets undergoing re-encapsulation, the ITE instead copies the "TTL/ 936 Hop Limit", "Type of Service/Traffic Class" and "Congestion 937 Experienced" values in the original outer IP header of the 938 transitional packet into the corresponding fields in the new outer IP 939 header of the packet to be forwarded (i.e., the values are 940 transferred between outer headers and *not* copied from the inner 941 network layer header). 943 The ITE also sets the IP protocol number to the appropriate value for 944 the first protocol layer within the encapsulation (e.g., UDP, TCP, 945 SEAL, etc.). When IPv6 is used as the outer IP protocol, the ITE 946 then sets the flow label value in the outer IPv6 header the same as 947 described in [RFC6438]. When IPv4 is used as the outer IP protocol, 948 the ITE sets DF=0 in the IPv4 header to allow the packet to be 949 fragmented if it encounters a restricting link (for IPv6 SEAL paths, 950 the DF bit is absent but implicitly set to 1). 952 The ITE finally sends each outer packet via the underlying link 953 corresponding to LINK. 955 5.4.6. Path Probing and ETE Reachability Verification 957 All SEAL data packets sent by the ITE are considered implicit probes 958 that detect MTU limitations on the SEAL path, while explicit probe 959 packets can be constructed to probe the path MTU and/or verify ETE 960 reachability. These probes will elicit an SCMP message from the ETE 961 if it needs to send an acknowledgement and/or report an error 962 condition. The probe packets may also be dropped by either the ETE 963 or a router on the path, which may or may not result in an ICMP 964 message being returned to the ITE. 966 To generate an explicit probe packet, the ITE creates a duplicate of 967 an actual data packet and uses the duplicate as a probe. 968 (Alternatively, the ITE can create a packet buffer beginning with the 969 same outer headers, SEAL header and inner network layer headers that 970 would appear in an ordinary data packet, then pad the packet with 971 random data.) The ITE then sets (C=0; P=1) in the SEAL header of the 972 probe packet, and also sets DF=1 in the outer IP header when IPv4 is 973 used. 975 The ITE sends periodic explicit probes to determine whether SEAL 976 segmentation is still necessary (see Section 5.4.4). In particular, 977 if a probe packet of 1500 bytes (i.e., a packet that becomes (1500+ 978 HLEN) bytes after encapsulation) succeeds without incurring 979 fragmentation the ITE is assured that the path MTU is large enough so 980 that the segmentation/reassembly process can be suspended. This 981 probing discipline can therefore be considered as Packetization Layer 982 Path MTU Discovery (PLPMTUD) [RFC4821] applied to tunnels, which 983 operates independently of any application of PLPMTUD between end 984 systems. Note that the explicit probe size of 1500 bytes is chosen 985 since probe packets smaller than this size may be fragmented by a 986 nested ITE further down the path. For example, a successful probe 987 for a packet size of 1400 bytes does not guarantee that fragmentation 988 is not occurring at another ITE. 990 The ITE can also send probes to detect whether an outer transport 991 layer header is no longer necessary to reach this ETE. For example, 992 if the ITE sends its initial packets as IP/UDP/SEAL/*, it can send 993 probes constructed as IP/SEAL/* to determine whether the ETE is 994 reachable without the added layer of encapsulation. If so, the ITE 995 should also re-probe the path MTU since switching to a new 996 encapsulation type may result in a path change. 998 While probing, the ITE processes ICMP messages as specified in 999 Section 5.4.7 and processes SCMP messages as specified in Section 1000 5.6.2. 1002 5.4.7. Processing ICMP Messages 1004 When the ITE sends SEAL packets, it may receive ICMP error messages 1005 [RFC0792][RFC4443] from a router on the path to the ETE. Each ICMP 1006 message includes an outer IP header, followed by an ICMP header, 1007 followed by a portion of the SEAL data packet that generated the 1008 error (also known as the "packet-in-error"). Note that the ITE may 1009 receive an ICMP message from another ITE that is at the head end of a 1010 nested level of encapsulation. The ITE has no security associations 1011 with this nested ITE, hence it should consider the message the same 1012 as if it originated from an ordinary router on the path to the ETE. 1014 The ITE should process ICMPv4 Protocol Unreachable messages and 1015 ICMPv6 Parameter Problem messages with Code "Unrecognized Next Header 1016 type encountered" as a hint that the ETE does not implement SEAL. 1017 The ITE can optionally ignore other ICMP messages that do not include 1018 sufficient information in the packet-in-error, or process them as a 1019 hint that the SEAL path to the ETE may be failing. The ITE then 1020 discards these types of messages. 1022 For other ICMP messages, the ITE first examines the SEAL data packet 1023 within the packet-in-error field. If the IP source and/or 1024 destination addresses are invalid, or if the value in the SEAL header 1025 Identification field (if present) is not within the window of packets 1026 the ITE has recently sent to this ETE, or if the MAC value in the ICV 1027 field (if present) is incorrect, the ITE discards the message. 1029 Next, if the received ICMP message is a PTB the ITE sets the 1030 temporary variable "PMTU" for this SEAL path to the MTU value in the 1031 PTB message. If the outer IP length value in the packet-in-error is 1032 no larger than (1500+HLEN) bytes the ITE sets MAXMTU=(1500+HLEN) and 1033 discards the message. If the outer IP length value in the packet-in- 1034 error is larger than (1500+HLEN) bytes and PMTU is no smaller than 1035 MINMTU the ITE sets MAXMTU to the maximum of (1500+HLEN) and PMTU; 1036 otherwise the ITE consults a plateau table (e.g., as described in 1037 [RFC1191]) to determine a new value for MAXMTU. For example, if the 1038 ITE receives a PTB message with small PMTU and packet-in-error length 1039 8KB, it can set MAXMTU=4KB. If the ITE subsequently receives a PTB 1040 message with small PMTU and length 4KB, it can set MAXMTU=2KB, etc., 1041 to a minimum value of MAXMTU=(1500+HLEN). Next, if the packet-in- 1042 error was an explicit probe (i.e., one with P=1 in the SEAL header), 1043 the ITE discards the message. Finally, if the ITE is using a MINMTU 1044 value larger than 1280 for IPv6 or 576 for IPv4, it may need to 1045 reduce MINMTU if the PMTU value is small. 1047 If the ICMP message was not discarded, the ITE transcribes it into a 1048 message appropriate for the SEAL data packet within the packet-in- 1049 error. If the previous hop toward the inner source address within 1050 the SEAL data packet is reached via the same SEAL tunnel, the ITE 1051 transcribes the message into an SCMP message the same as described 1052 for ETE generation of SCMP messages in Section 5.6.1, i.e., it copies 1053 the SEAL data packet within the packet-in-error into the packet-in- 1054 error field of the new message. (In this process, the ETE also sets 1055 (C=1; P=1) in the SEAL header of the SCMP message.) Otherwise, the 1056 ITE seeks beyond the SEAL header within the packet-in-error and 1057 transcribes the inner packet into a message appropriate for the inner 1058 protocol version (e.g., ICMPv4 for IPv4, ICMPv6 for IPv6, etc.). 1060 The ITE finally forwards the transcribed message to the previous hop 1061 toward the inner source address. 1063 5.4.8. IPv4 Middlebox Reassembly Testing 1065 The ITE can perform a qualification exchange to ensure that the 1066 subnetwork correctly delivers fragments to the ETE. This procedure 1067 can be used, e.g., to determine whether there are middleboxes on the 1068 path that violate the [RFC1812], Section 5.2.6 requirement that: "A 1069 router MUST NOT reassemble any datagram before forwarding it". 1070 Examples of middleboxes that may perform reassembly include stateful 1071 NATs and firewalls. Such devices could still allow for stateless MTU 1072 determination if they gather the fragments of a fragmented SEAL data 1073 packet for packet analysis purposes but then forward the fragments on 1074 to the final destination rather than forwarding the reassembled 1075 packet. (This process is often referred to as "Virtual Fragmentation 1076 Reassembly" (VFR)). 1078 The ITE should use knowledge of its topological arrangement as an aid 1079 in determining when middlebox reassembly testing is necessary. For 1080 example, if the ITE is aware that the ETE is located somewhere in the 1081 public Internet, middlebox reassembly testing should not be 1082 necessary. If the ITE is aware that the ETE is located behind a NAT 1083 or a firewall, however, then reassembly testing can be used to detect 1084 middleboxes that do not conform to specifications. 1086 The ITE can perform a middlebox reassembly test by sending explicit 1087 probe packets. The ITE should only send probe packets that are 1088 smaller than (576-HLEN) before encapsulation since the least an 1089 ordinary node can be expected to reassemble is 576 bytes. To 1090 generate a probe, the ITE either creates a clone of an ordinary data 1091 packet or creates a packet buffer beginning with the same outer 1092 headers, SEAL header and inner network layer header that would appear 1093 in an ordinary data packet. The ITE then pads the probe packet with 1094 random data to a length that is at least 128 bytes but smaller than 1095 (576-HLEN) bytes. 1097 The ITE then sets (C=0; P=1) in the SEAL header of the probe packet 1098 and sets the Next Header field to the inner network layer protocol 1099 type. Next, the ITE sets LINK to the appropriate value for this SEAL 1100 path, sets the Identification field, then finally calculates the ICV 1101 and sets I=1 (when USE_ICV is TRUE). 1103 The ITE then encapsulates the probe packet in the appropriate outer 1104 headers, splits it into two outer IP fragments, then sends both 1105 fragments over the same SEAL path. 1107 The ITE should send a series of probe packets (e.g., 3-5 probes with 1108 1sec intervals between tests) instead of a single isolated probe in 1109 case of packet loss. If the ETE returns an SCMP PTB message with the 1110 original first fragment in the packet-in-error, then the SEAL path 1111 correctly supports fragmentation; otherwise, the ITE enables stateful 1112 MTU determination for this SEAL path as specified in Section 5.4.9. 1114 5.4.9. Stateful MTU Determination 1116 SEAL supports a stateless MTU determination capability, however the 1117 ITE may in some instances wish to impose a stateful MTU limit on a 1118 particular SEAL path. For example, when the ETE is situated behind a 1119 middlebox that performs reassembly in violation of the specs (see: 1120 Section 5.4.8) it is imperative that fragmentation be avoided. In 1121 other instances (e.g., when the SEAL path includes performance- 1122 constrained links), the ITE may deem it necessary to cache a 1123 conservative static MTU in order to avoid sending large packets that 1124 would only be dropped due to an MTU restriction somewhere on the 1125 path. 1127 To determine a static MTU value, the ITE can send a series of probe 1128 packets of various sizes to the ETE with (C=0; P=1) in the SEAL 1129 header and DF=1 in the outer IP header. The ITE then caches the size 1130 'S' of the largest packet for which it receives a probe reply from 1131 the ETE by setting MAXMTU=MAX((S, (1500+HLEN)) for this SEAL path. 1133 For example, the ITE could send probe packets of 8KB, followed by 1134 4KB, followed by 2KB, etc. While probing, the ITE processes any ICMP 1135 PTB message it receives as a potential indication of probe failure 1136 then discards the message. 1138 5.4.10. Detecting Path MTU Changes 1140 When stateful MTU determination is used, the ITE SHOULD periodically 1141 reset MAXMTU and/or re-probe the path to determine whether MAXMTU has 1142 increased. If the path still has a too-small MTU, the ITE will 1143 receive a PTB message that reports a smaller size. 1145 5.5. ETE Specification 1147 5.5.1. Reassembly Buffer Requirements 1149 For IPv6, the ETE MUST configure a minimum reassembly buffer size of 1150 (1500 + HLEN) bytes for the reassembly of outer IPv6 packets, i.e., 1151 even though the true minimum reassembly size for IPv6 is only 1500 1152 bytes [RFC2460]. For IPv4, the ETE also MUST configure a minimum 1153 reassembly buffer size of (1500 + HLEN) bytes for the reassembly of 1154 outer IPv4 packets, i.e., even though the true minimum reassembly 1155 size for IPv4 is only 576 bytes [RFC1122]. 1157 In addition to this outer reassembly buffer requirement, the ETE 1158 further MUST configure a minimum SEAL reassembly buffer size of (1500 1159 + HLEN) bytes for the reassembly of segmented SEAL packets (see: 1160 Section 5.5.4). 1162 Note that the value "HLEN" may be variable and initially unknown to 1163 the ETE, and would typically range from a few bytes to a few tens of 1164 bytes or even more. It is therefore RECOMMENDED that the ETE 1165 configure slightly larger minimum IP/SEAL reassembly buffer sizes of 1166 2048 bytes (2KB). 1168 5.5.2. Tunnel Neighbor Soft State 1170 When message origin authentication and integrity checking is 1171 required, the ETE maintains a per-ITE MAC calculation algorithm and a 1172 symmetric secret key to verify the MAC. The ETE also maintains a 1173 window of Identification values for the packets it has recently 1174 received from this ITE as well as a window of Identification values 1175 for the packets it has recently sent to this ITE. 1177 When the tunnel neighbor relationship is bidirectional, the ETE 1178 further maintains a per SEAL path mapping of outer IP and transport 1179 layer addresses to the LINK value that appears in packets received 1180 from the ITE. 1182 5.5.3. IP-Layer Reassembly 1184 The ETE reassembles fragmented IP packets that are explicitly 1185 addressed to itself. For IP fragments that are received via a SEAL 1186 tunnel, the ETE SHOULD maintain conservative reassembly cache high- 1187 and low-water marks. When the size of the reassembly cache exceeds 1188 this high-water mark, the ETE SHOULD actively discard stale 1189 incomplete reassemblies (e.g., using an Active Queue Management (AQM) 1190 strategy) until the size falls below the low-water mark. The ETE 1191 SHOULD also actively discard any pending reassemblies that clearly 1192 have no opportunity for completion, e.g., when a considerable number 1193 of new fragments have arrived before a fragment that completes a 1194 pending reassembly arrives. 1196 The ETE processes non-SEAL IP packets as specified in the normative 1197 references, i.e., it performs any necessary IP reassembly then 1198 discards the packet if it is larger than the reassembly buffer size 1199 or delivers the (fully-reassembled) packet to the appropriate upper 1200 layer protocol module. 1202 For SEAL packets, the ETE performs any necessary IP reassembly then 1203 submits the packet for SEAL decapsulation as specified in Section 1204 5.5.4. (Note that if the packet is larger than the reassembly buffer 1205 size, the ETE still examines the leading portion of the (partially) 1206 reassembled packet during decapsulation.) 1208 5.5.4. Decapsulation, SEAL-Layer Reassembly, and Re-Encapsulation 1210 For each SEAL packet accepted for decapsulation, the ETE first 1211 examines the Identification field. If the Identification is not 1212 within the window of acceptable values for this ITE, the ETE silently 1213 discards the packet. 1215 Next, if I==1 the ETE SHOULD verify the MAC value and silently 1216 discard the packet if the value is incorrect. (Note that this means 1217 that the ETE would need to receive all IP fragments if the packet was 1218 fragmented at the outer IP layer, since the MAC is included as a 1219 trailing field.) 1221 Next, if the packet arrived as multiple IP fragments, the ETE sends 1222 an SPTB message back to the ITE with MTU set to the size of the 1223 largest fragment received (see: Section 5.6.1.1). 1225 Next, if the packet arrived as multiple IP fragments and the inner 1226 packet is larger than 1500 bytes, the ETE silently discards the 1227 packet; otherwise, it continues to process the packet. 1229 Next, if there is an incorrect value in a SEAL header field (e.g., an 1230 incorrect "VER" field value), the ETE discards the packet. If the 1231 SEAL header has C==0, the ETE also returns an SCMP "Parameter 1232 Problem" (SPP) message (see Section 5.6.1.2). 1234 Next, if the SEAL header has C==1, the ETE processes the packet as an 1235 SCMP packet as specified in Section 5.6.2. Otherwise, the ETE 1236 continues to process the packet as a SEAL data packet. 1238 Next, if the SEAL header has (M==1 || Fragment Offset!=0) the ETE 1239 checks to see if the other segments of this already-segmented SEAL 1240 packet have arrived, i.e., by looking for additional segments that 1241 have the same outer IP source address, destination address, source 1242 port number and SEAL Identification value. If all other segments 1243 have already arrived, the ETE discards the SEAL header and other 1244 outer headers from the non-initial segments and appends the segments 1245 onto the end of the first segment according to their offset value. 1246 Otherwise, the ETE caches the new segment for at most 60 seconds 1247 while awaiting the arrival of its partners. During this process, the 1248 ETE discards any segments that are overlapping with respect to 1249 segments that have already been received, and also discards any 1250 segments that have M==1 in the SEAL header but do not contain an 1251 integer multiple of 8 bytes. The ETE further SHOULD manage the SEAL 1252 reassembly cache the same as described for the IP-Layer Reassembly 1253 cache in Section 5.5.3, i.e., it SHOULD perform an early discard for 1254 any pending reassemblies that have low probability of completion. 1256 Next, if the SEAL header in the (reassembled) packet has P==1, the 1257 ETE drops the packet unconditionally and sends an SPTB message back 1258 to the ITE (see: Section 5.6.1.1) if it has not already sent an SPTB 1259 message based on IP fragmentation. (Note that the ETE therefore 1260 sends only a single SPTB message for a probe packet that also 1261 experienced IP fragmentation, i.e., it does not send multiple SPTB 1262 messages.) 1264 Finally, the ETE discards the outer headers and processes the inner 1265 packet according to the header type indicated in the SEAL Next Header 1266 field. If the next hop toward the inner destination address is via a 1267 different interface than the SEAL packet arrived on, the ETE discards 1268 the SEAL header and delivers the inner packet either to the local 1269 host or to the next hop if the packet is not destined to the local 1270 host. 1272 If the next hop is on the same tunnel the SEAL packet arrived on, 1273 however, the ETE submits the packet for SEAL re-encapsulation 1274 beginning with the specification in Section 5.4.3 above and without 1275 decrementing the value in the inner (TTL / Hop Limit) field. 1277 5.6. The SEAL Control Message Protocol (SCMP) 1279 SEAL provides a companion SEAL Control Message Protocol (SCMP) that 1280 uses the same message types and formats as for the Internet Control 1281 Message Protocol for IPv6 (ICMPv6) [RFC4443]. The SCMP messaging 1282 protocol operates over bidirectional and partially unidirectional 1283 tunnels. (For fully unidirectional tunnels, SEAL must operate 1284 without the benefit of SCMP meaning that steady-state fragmentation 1285 and reassembly may be necessary in extreme cases. In that case, the 1286 ITE must select a conservative MINMTU to ensure that IPv4 1287 fragmentation is avoided in order to avoid reassembly errors at high 1288 data rates [RFC4963].) 1290 As for ICMPv6, each SCMP message includes a 32-bit header and a 1291 variable-length body. The ITE encapsulates the SCMP message in a 1292 SEAL header and outer headers as shown in Figure 4: 1294 +--------------------+ 1295 ~ outer IP header ~ 1296 +--------------------+ 1297 ~ other outer hdrs ~ 1298 +--------------------+ 1299 ~ SEAL Header ~ 1300 +--------------------+ +--------------------+ 1301 | SCMP message header| --> | SCMP message header| 1302 +--------------------+ +--------------------+ 1303 | | --> | | 1304 ~ SCMP message body ~ --> ~ SCMP message body ~ 1305 | | --> | | 1306 +--------------------+ +--------------------+ 1308 SCMP Message SCMP Packet 1309 before encapsulation after encapsulation 1311 Figure 4: SCMP Message Encapsulation 1313 The following sections specify the generation, processing and 1314 relaying of SCMP messages. 1316 5.6.1. Generating SCMP Messages 1318 ETEs generate SCMP messages in response to receiving certain SEAL 1319 data packets using the format shown in Figure 5: 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Type | Code | Checksum | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Type-Specific Data | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | As much of the invoking SEAL data packet as possible | 1329 ~ (beginning with the SEAL header) without the SCMP ~ 1330 | packet exceeding MINMTU bytes (*) | 1332 (*) also known as the "packet-in-error" 1334 Figure 5: SCMP Message Format 1336 The error message includes the 32-bit SCMP message header, followed 1337 by a 32-bit Type-Specific Data field, followed by the leading portion 1338 of the invoking SEAL data packet beginning with the SEAL header as 1339 the "packet-in-error". The packet-in-error includes as much of the 1340 invoking packet as possible extending to a length that would not 1341 cause the entire SCMP packet following outer encapsulation to exceed 1342 MINMTU bytes. 1344 When the ETE processes a SEAL data packet for which the 1345 Identification and ICV values are correct but an error must be 1346 returned, it prepares an SCMP message as shown in Figure 5. The ETE 1347 sets the Type and Code fields to the same values that would appear in 1348 the corresponding ICMPv6 message [RFC4443], but calculates the 1349 Checksum beginning with the SCMP message header using the algorithm 1350 specified for ICMPv4 in [RFC0792]. 1352 The ETE next encapsulates the SCMP message in the requisite SEAL and 1353 outer headers as shown in Figure 4. During encapsulation, the ETE 1354 sets the outer destination address/port numbers of the SCMP packet to 1355 the values associated with the ITE and sets the outer source address/ 1356 port numbers to its own outer address/port numbers. 1358 The ETE then sets (C=1; M=0; Fragment Offset=0) in the SEAL header, 1359 then sets I, Next Header and LINK to the same values that appeared in 1360 the SEAL header of the data packet. The ETE next sets the 1361 Identification field to the next Identification value scheduled for 1362 this ITE, then increments the next Identification value. When I==1, 1363 the ETE then prepares the ICV field the same as specified for SEAL 1364 data packet encapsulation in Section 5.4.4. If this message is in 1365 direct response to a SEAL data packet sent by the ITE, the ETE next 1366 sets P=0 and sends the resulting SCMP packet to the ITE the same as 1367 specified for SEAL data packets in Section 5.4.5. 1369 If the message is in response to an SCMP message received from a next 1370 hop ETE or to an ICMP message received from a router on the path to a 1371 next hop ETE, the ETE instead sets P=1 and passes the message to the 1372 ITE in a "reverse re-encapsulation" process. In particular, when the 1373 previous hop toward the source of the inner packet within the packet- 1374 in-error in a received SCMP/ICMP message is reached via the same 1375 tunnel as the message arrived on, the ETE replaces the outer headers 1376 of the message (up to and including the SEAL header) with headers 1377 that will be recognized and accepted by the previous hop and sends 1378 the resulting packet to the previous hop. 1380 The following sections describe additional considerations for various 1381 SCMP error messages: 1383 5.6.1.1. Generating SCMP Packet Too Big (SPTB) Messages 1385 An ETE generates an SPTB message when it receives a SEAL probe packet 1386 (i.e., one with C=0; P=1 in the SEAL header) or when it receives a 1387 SEAL packet that arrived as multiple outer IP fragments. The ETE 1388 prepares the SPTB message the same as for the corresponding ICMPv6 1389 PTB message, and writes the length of the largest outer IP fragment 1390 received in the MTU field of the message (or the full length of the 1391 outer IP packet if the packet was unfragmented). In that case, the 1392 ETE sets (C=1; P=0) in the SEAL header. 1394 An ETE also generates an SPTB message when it attempts to forward a 1395 SEAL data packet to a next hop ETE via the same tunnel the data 1396 packet arrived on, but for which MAXMTU for that SEAL path is 1397 insufficient to accommodate the packet (See Section 5.4.3.2). In 1398 that case, the ETE sets (C=1; P=1) in the SEAL header. 1400 An ETE finally generates an SPTB message when it receives an ICMP PTB 1401 message from a router on the path to a next hop ETE (See Section 1402 5.4.7). In that case, the ETE also sets (C=1; P=1) in the SEAL 1403 header. 1405 5.6.1.2. Generating Other SCMP Messages 1407 An ETE generates an SCMP "Destination Unreachable" (SDU) message 1408 under the same conditions that an IPv6 system would generate an 1409 ICMPv6 Destination Unreachable message. 1411 An ETE generates an SCMP "Parameter Problem" (SPP) message when it 1412 receives a SEAL packet with an incorrect value in the SEAL header. 1414 TEs generate other SCMP message types using methods and procedures 1415 specified in other documents. For example, SCMP message types used 1416 for tunnel neighbor coordinations are specified in VET 1417 [I-D.templin-intarea-vet]. 1419 5.6.2. Processing SCMP Messages 1421 An ITE may receive SCMP messages with C==1 in the SEAL header after 1422 sending packets to an ETE. The ITE first verifies that the outer 1423 addresses of the SCMP packet are correct, and that the Identification 1424 field contains an acceptable value. The ITE next verifies that the 1425 SEAL header fields are set correctly as specified in Section 5.6.1. 1426 When I==1, the ITE then verifies the ICV. The ITE next verifies the 1427 Checksum value in the SCMP message header. If any of these values 1428 are incorrect, the ITE silently discards the message; otherwise, it 1429 processes the message as follows: 1431 5.6.2.1. Processing SCMP PTB Messages 1433 After an ITE sends a SEAL packet to an ETE, it may receive an SPTB 1434 message with a packet-in-error containing the leading portion of the 1435 packet (see: Section 5.6.1.1). If the SEAL header has P==1 the ITE 1436 consults its forwarding information base to pass the message to the 1437 previous hop toward the source address of the encapsulated inner 1438 packet. When the previous hop is reached via the same SEAL tunnel, 1439 the ITE passes the SPTB message to the previous hop as specified in 1440 Section 5.6.1. Otherwise, the ITE transcribes the inner packet 1441 within the packet-in-error into a message appropriate for the inner 1442 protocol version (e.g., ICMPv4 for IPv4, ICMPv6 for IPv6, etc.). 1444 If the SEAL header has P==0, the ITE instead processes the message as 1445 an MTU limitation on the SEAL path to this ETE. In that case, the 1446 ITE first sets the temporary variable "PMTU" for this SEAL path to 1447 the MTU value in the SPTB message and processes the message as 1448 follows: 1450 o If PMTU is no smaller than (1500+HLEN), the ITE suspends the SEAL 1451 segmentation/reassembly process for this SEAL path so that whole 1452 (unfragmented) SEAL packets can be used. If the packet is a probe 1453 being used to establish a stateful MTU for this SEAL path (see: 1454 section 5.4.9), the ITE also sets MAXMTU=PMTU. 1456 o If PMTU is smaller than (1500+HLEN) but no smaller than MINMTU the 1457 ITE sets MAXMTU to (1500+HLEN) and resumes the SEAL segmentation/ 1458 reassembly process for this SEAL path. 1460 o If PMTU is smaller than MINMTU and the packet-in-error is a probe 1461 used for the purpose of middlebox reassembly detection (see: 1462 section 5.4.8), the ITE notes the results of the probe. 1463 Otherwise, the ITE consults a plateau table to determine a new 1464 value for MAXMTU. For example, if the ITE receives a PTB message 1465 with small PMTU and packet-in-error length 8KB, it can set 1466 MAXMTU=4KB. If the ITE subsequently receives a PTB message with 1467 small PMTU and length 4KB, it can set MAXMTU=2KB, etc., to a 1468 minimum value of MAXMTU=(1500+HLEN). Finally, if the ITE is using 1469 a MINMTU value larger than 1280 for IPv6 or 576 for IPv4, it may 1470 need to reduce MINMTU if the PMTU value is small. 1472 Next, if the packet-in-error was no larger than (1500+HLEN) or the 1473 packet-in-error was an explicit probe (i.e., one with (C==0; P==1 in 1474 the SEAL header of the packet-in-error), the ITE discards the SPTB 1475 message. 1477 5.6.2.2. Processing Other SCMP Error Messages 1479 An ITE may receive an SDU message with an appropriate code under the 1480 same circumstances that an IPv6 node would receive an ICMPv6 1481 Destination Unreachable message. The ITE transcribes the message and 1482 forwards it toward the source address of the inner packet within the 1483 packet-in-error the same as specified for SPTB messages with P==1 in 1484 Section 5.6.2.1. 1486 An ITE may receive an SPP message when the ETE receives a SEAL packet 1487 with an incorrect value in the SEAL header. The ITE should examine 1488 the SEAL header within the packet-in-error to determine whether 1489 different settings should be used in subsequent packets, but does not 1490 relay the message further. 1492 TEs process other SCMP message types using methods and procedures 1493 specified in other documents. For example, SCMP message types used 1494 for tunnel neighbor coordinations are specified in VET 1495 [I-D.templin-intarea-vet]. 1497 6. Link Requirements 1499 Subnetwork designers are expected to follow the recommendations in 1500 Section 2 of [RFC3819] when configuring link MTUs. 1502 7. End System Requirements 1504 End systems are encouraged to implement end-to-end MTU assurance 1505 (e.g., using Packetization Layer Path MTU Discovery (PLPMTUD) per 1506 [RFC4821]) even if the subnetwork is using SEAL. 1508 When end systems use PLPMTUD, SEAL will ensure that the tunnel 1509 behaves as a link in the path that assures an MTU of at least 1500 1510 bytes while not precluding discovery of larger MTUs. The PLPMTUD 1511 mechanism will therefore be able to function as designed in order to 1512 discover and utilize larger MTUs. 1514 8. Router Requirements 1516 Routers within the subnetwork are expected to observe the standard IP 1517 router requirements, including the implementation of IP fragmentation 1518 and reassembly as well as the generation of ICMP messages 1519 [RFC0792][RFC1122][RFC1812][RFC2460][RFC4443][RFC6434]. 1521 Note that, even when routers support existing requirements for the 1522 generation of ICMP messages, these messages are often filtered and 1523 discarded by middleboxes on the path to the original source of the 1524 message that triggered the ICMP. It is therefore not possible to 1525 assume delivery of ICMP messages even when routers are correctly 1526 implemented. 1528 9. Nested Encapsulation Considerations 1530 SEAL supports nested tunneling - an example would be a recursive 1531 nesting of mobile networks, where the first network receives service 1532 from an ISP, the second network receives service from the first 1533 network, the third network receives service from the second network, 1534 etc. It is imperative that such nesting not extend indefinitely; 1535 SEAL tunnels therefore honor the Encapsulation Limit option defined 1536 in [RFC2473]. 1538 In such nested arrangements, the SEAL ITE has a tunnel neighbor 1539 relationship only with ETEs at its own nesting level, i.e., it does 1540 not have a tunnel neighbor relationship with TEs at other nesting 1541 levels.Therefore, when an ITE 'A' within an outer nesting level needs 1542 to return an error message to an ITE 'B' within an inner nesting 1543 level, it generates an ordinary ICMP error message the same as if it 1544 were an ordinary router within the subnetwork. 'B' can then perform 1545 message validation as specified in Section 5.4.7, but full message 1546 origin authentication is not possible. 1548 (Note that the SCMP protocol could instead be extended to allow an 1549 outer nesting level ITE 'A' to return an SCMP message to an inner 1550 nesting level ITE 'B' rather than return an ICMP message. This would 1551 conceptually allow the control messages to pass through firewalls and 1552 NATs, however it would give no more message origin authentication 1553 assurance than for ordinary ICMP messages. It was therefore 1554 determined that the complexity of extending the SCMP protocol was of 1555 little value within the context of the anticipated use cases for 1556 nested encapsulations.) 1558 10. Reliability Considerations 1560 Although a SEAL tunnel may span an arbitrarily-large subnetwork 1561 expanse, the IP layer sees the tunnel as a simple link that supports 1562 the IP service model. Links with high bit error rates (BERs) (e.g., 1563 IEEE 802.11) use Automatic Repeat-ReQuest (ARQ) mechanisms [RFC3366] 1564 to increase packet delivery ratios, while links with much lower BERs 1565 typically omit such mechanisms. Since SEAL tunnels may traverse 1566 arbitrarily-long paths over links of various types that are already 1567 either performing or omitting ARQ as appropriate, it would therefore 1568 be inefficient to require the tunnel endpoints to also perform ARQ. 1570 11. Integrity Considerations 1572 The SEAL header includes an integrity check field that covers the 1573 SEAL header and at least the inner packet headers. This provides for 1574 header integrity verification on a segment-by-segment basis for a 1575 segmented re-encapsulating tunnel path. 1577 Fragmentation and reassembly schemes must also consider packet- 1578 splicing errors, e.g., when two fragments from the same packet are 1579 concatenated incorrectly, when a fragment from packet X is 1580 reassembled with fragments from packet Y, etc. The primary sources 1581 of such errors include implementation bugs and wrapping IPv4 ID 1582 fields. 1584 In particular, the IPv4 16-bit ID field can wrap with only 64K 1585 packets with the same (src, dst, protocol)-tuple alive in the system 1586 at a given time [RFC4963]. When the IPv4 ID field is re-written by a 1587 middlebox such as a NAT or Firewall, ID field wrapping can occur with 1588 even fewer packets alive in the system. It is therefore essential 1589 that IPv4 fragmentation and reassembly be detected early and tuned 1590 out through proper application of SEAL segmentation and reassembly. 1592 12. IANA Considerations 1594 The IANA is requested to allocate a User Port number for "SEAL" in 1595 the 'port-numbers' registry. The Service Name is "SEAL", and the 1596 Transport Protocols are TCP and UDP. The Assignee is the IESG 1597 (iesg@ietf.org) and the Contact is the IETF Chair (chair@ietf.org). 1598 The Description is "Subnetwork Encapsulation and Adaptation Layer 1599 (SEAL)", and the Reference is the RFC-to-be currently known as 1600 'draft-templin-intarea-seal'. 1602 13. Security Considerations 1604 SEAL provides a segment-by-segment message origin authentication, 1605 integrity and anti-replay service. The SEAL header is sent in-the- 1606 clear the same as for the outer IP and other outer headers. In this 1607 respect, the threat model is no different than for IPv6 extension 1608 headers. Unlike IPv6 extension headers, however, the SEAL header can 1609 be protected by an integrity check that also covers the inner packet 1610 headers. 1612 An amplification/reflection/buffer overflow attack is possible when 1613 an attacker sends IP fragments with spoofed source addresses to an 1614 ETE in an attempt to clog the ETE's reassembly buffer and/or cause 1615 the ETE to generate a stream of SCMP messages returned to a victim 1616 ITE. The SCMP message ICV, Identification, as well as the inner 1617 headers of the packet-in-error, provide mitigation for the ETE to 1618 detect and discard SEAL segments with spoofed source addresses. 1620 Security issues that apply to tunneling in general are discussed in 1621 [RFC6169]. 1623 14. Related Work 1625 Section 3.1.7 of [RFC2764] provides a high-level sketch for 1626 supporting large tunnel MTUs via a tunnel-level segmentation and 1627 reassembly capability to avoid IP level fragmentation. 1629 Section 3 of [RFC4459] describes inner and outer fragmentation at the 1630 tunnel endpoints as alternatives for accommodating the tunnel MTU. 1632 Section 4 of [RFC2460] specifies a method for inserting and 1633 processing extension headers between the base IPv6 header and 1634 transport layer protocol data. The SEAL header is inserted and 1635 processed in exactly the same manner. 1637 IPsec/AH is [RFC4301][RFC4301] is used for full message integrity 1638 verification between tunnel endpoints, whereas SEAL only ensures 1639 integrity for the inner packet headers. The AYIYA proposal 1640 [I-D.massar-v6ops-ayiya] uses similar means for providing message 1641 authentication and integrity. 1643 SEAL, along with the Virtual Enterprise Traversal (VET) 1644 [I-D.templin-intarea-vet] tunnel virtual interface abstraction, are 1645 the functional building blocks for the Interior Routing Overlay 1646 Network (IRON) [I-D.templin-ironbis] and Routing and Addressing in 1647 Networks with Global Enterprise Recursion (RANGER) [RFC5720][RFC6139] 1648 architectures. 1650 The concepts of path MTU determination through the report of 1651 fragmentation and extending the IPv4 Identification field were first 1652 proposed in deliberations of the TCP-IP mailing list and the Path MTU 1653 Discovery Working Group (MTUDWG) during the late 1980's and early 1654 1990's. An historical analysis of the evolution of these concepts, 1655 as well as the development of the eventual PMTUD mechanism, appears 1656 in [RFC5320]. 1658 15. Implementation Status 1660 An early implementation of the first revision of SEAL [RFC5320] is 1661 available at: http://isatap.com/seal. 1663 16. Acknowledgments 1665 The following individuals are acknowledged for helpful comments and 1666 suggestions: Jari Arkko, Fred Baker, Iljitsch van Beijnum, Oliver 1667 Bonaventure, Teco Boot, Bob Braden, Brian Carpenter, Steve Casner, 1668 Ian Chakeres, Noel Chiappa, Remi Denis-Courmont, Remi Despres, Ralph 1669 Droms, Aurnaud Ebalard, Gorry Fairhurst, Washam Fan, Dino Farinacci, 1670 Joel Halpern, Brian Haberman, Sam Hartman, John Heffner, Thomas 1671 Henderson, Bob Hinden, Christian Huitema, Eliot Lear, Darrel Lewis, 1672 Joe Macker, Matt Mathis, Erik Nordmark, Dan Romascanu, Dave Thaler, 1673 Joe Touch, Mark Townsley, Ole Troan, Margaret Wasserman, Magnus 1674 Westerlund, Robin Whittle, James Woodyatt, and members of the Boeing 1675 Research & Technology NST DC&NT group. 1677 Discussions with colleagues following the publication of [RFC5320] 1678 have provided useful insights that have resulted in significant 1679 improvements to this, the Second Edition of SEAL. 1681 This document received substantial review input from the IESG and 1682 IETF area directorates in the February 2013 timeframe. IESG members 1683 and IETF area directorate representatives who contributed helpful 1684 comments and suggestions are gratefully acknowledged. Discussions on 1685 the IETF IPv6 and Intarea mailing lists in the summer 2013 timeframe 1686 also stimulated several useful ideas. 1688 Path MTU determination through the report of fragmentation was first 1689 proposed by Charles Lynn on the TCP-IP mailing list in 1987. 1690 Extending the IP identification field was first proposed by Steve 1691 Deering on the MTUDWG mailing list in 1989. Steve Deering also 1692 proposed the IPv6 minimum MTU of 1280 bytes on the IPng mailing list 1693 in 1997. 1695 17. References 1697 17.1. Normative References 1699 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1700 September 1981. 1702 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1703 RFC 792, September 1981. 1705 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1706 Communication Layers", STD 3, RFC 1122, October 1989. 1708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1709 Requirement Levels", BCP 14, RFC 2119, March 1997. 1711 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1712 (IPv6) Specification", RFC 2460, December 1998. 1714 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1715 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1717 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1718 Message Protocol (ICMPv6) for the Internet Protocol 1719 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1721 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1722 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1723 September 2007. 1725 17.2. Informative References 1727 [FOLK] Shannon, C., Moore, D., and k. claffy, "Beyond Folklore: 1728 Observations on Fragmented Traffic", December 2002. 1730 [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 1731 October 1987. 1733 [I-D.ietf-6man-ext-transmit] 1734 Carpenter, B. and S. Jiang, "Transmission and Processing 1735 of IPv6 Extension Headers", 1736 draft-ietf-6man-ext-transmit-05 (work in progress), 1737 October 2013. 1739 [I-D.massar-v6ops-ayiya] 1740 Massar, J., "AYIYA: Anything In Anything", 1741 draft-massar-v6ops-ayiya-02 (work in progress), July 2004. 1743 [I-D.taylor-v6ops-fragdrop] 1744 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 1745 M., and T. Taylor, "Why Operators Filter Fragments and 1746 What It Implies", draft-taylor-v6ops-fragdrop-01 (work in 1747 progress), June 2013. 1749 [I-D.templin-intarea-vet] 1750 Templin, F., "Virtual Enterprise Traversal (VET)", 1751 draft-templin-intarea-vet-40 (work in progress), May 2013. 1753 [I-D.templin-ironbis] 1754 Templin, F., "The Interior Routing Overlay Network 1755 (IRON)", draft-templin-ironbis-15 (work in progress), 1756 May 2013. 1758 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1759 August 1980. 1761 [RFC0994] International Organization for Standardization (ISO) and 1762 American National Standards Institute (ANSI), "Final text 1763 of DIS 8473, Protocol for Providing the Connectionless- 1764 mode Network Service", RFC 994, March 1986. 1766 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 1767 MTU discovery options", RFC 1063, July 1988. 1769 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1770 a subnetwork for experimentation with the OSI network 1771 layer", RFC 1070, February 1989. 1773 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 1774 options", RFC 1146, March 1990. 1776 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1777 November 1990. 1779 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1780 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1782 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1783 RFC 1812, June 1995. 1785 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1786 for IP version 6", RFC 1981, August 1996. 1788 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1789 October 1996. 1791 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1792 Hashing for Message Authentication", RFC 2104, 1793 February 1997. 1795 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1796 IPv6 Specification", RFC 2473, December 1998. 1798 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1799 RFC 2675, August 1999. 1801 [RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G., and A. 1802 Malis, "A Framework for IP Based Virtual Private 1803 Networks", RFC 2764, February 2000. 1805 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1806 Values In the Internet Protocol and Related Headers", 1807 BCP 37, RFC 2780, March 2000. 1809 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1810 Defeating Denial of Service Attacks which employ IP Source 1811 Address Spoofing", BCP 38, RFC 2827, May 2000. 1813 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1814 RFC 2923, September 2000. 1816 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1817 an On-line Database", RFC 3232, January 2002. 1819 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 1820 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 1821 August 2002. 1823 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1824 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1825 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1826 RFC 3819, July 2004. 1828 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1829 More-Specific Routes", RFC 4191, November 2005. 1831 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1832 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1834 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1835 Internet Protocol", RFC 4301, December 2005. 1837 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1838 December 2005. 1840 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1841 Network Tunneling", RFC 4459, April 2006. 1843 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1844 Discovery", RFC 4821, March 2007. 1846 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1847 Errors at High Data Rates", RFC 4963, July 2007. 1849 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1850 Mitigations", RFC 4987, August 2007. 1852 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1853 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1854 May 2008. 1856 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1857 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1859 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 1860 Layer (SEAL)", RFC 5320, February 2010. 1862 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 1863 Schemes", RFC 5445, March 2009. 1865 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1866 Global Enterprise Recursion (RANGER)", RFC 5720, 1867 February 2010. 1869 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 1871 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 1872 Addressing in Networks with Global Enterprise Recursion 1873 (RANGER) Scenarios", RFC 6139, February 2011. 1875 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1876 Concerns with IP Tunneling", RFC 6169, April 2011. 1878 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1879 Cheshire, "Internet Assigned Numbers Authority (IANA) 1880 Procedures for the Management of the Service Name and 1881 Transport Protocol Port Number Registry", BCP 165, 1882 RFC 6335, August 2011. 1884 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1885 Requirements", RFC 6434, December 2011. 1887 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1888 for Equal Cost Multipath Routing and Link Aggregation in 1889 Tunnels", RFC 6438, November 2011. 1891 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1892 RFC 6864, February 2013. 1894 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1895 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1897 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1898 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1899 RFC 6936, April 2013. 1901 [RIPE] De Boer, M. and J. Bosma, "Discovering Path MTU Black 1902 Holes on the Internet using RIPE Atlas", July 2012. 1904 [SIGCOMM] Luckie, M. and B. Stasiewicz, "Measuring Path MTU 1905 Discovery Behavior", November 2010. 1907 [TBIT] Medina, A., Allman, M., and S. Floyd, "Measuring 1908 Interactions Between Transport Protocols and Middleboxes", 1909 October 2004. 1911 [WAND] Luckie, M., Cho, K., and B. Owens, "Inferring and 1912 Debugging Path MTU Discovery Failures", October 2005. 1914 Author's Address 1916 Fred L. Templin (editor) 1917 Boeing Research & Technology 1918 P.O. Box 3707 1919 Seattle, WA 98124 1920 USA 1922 Email: fltemplin@acm.org