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