idnits 2.17.1 draft-bonica-internet-icmp-10.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2, 2006) is 6416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'IPv6' on line 395 == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-icmp-06 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet R. Bonica 3 Internet-Draft D. Gan 4 Intended status: Informational Juniper Networks 5 Expires: April 5, 2007 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 October 2, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 5, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document redefines selected ICMP messages to support multi-part 47 operation. A multi-part ICMP message carries all of the information 48 that ICMP messages carried previously, as well as additional 49 information that applications may require. 51 Multi-part messages are supported by an ICMP extension structure. 52 The extension structure is situated at the end of the ICMP message. 53 It includes an extension header followed by one or more extension 54 objects. Each extension object contains an object header and object 55 payload. All object headers share a common format. 57 This document further redefines a subset of the above mentioned ICMP 58 messages by specifying a length attribute. Many of the ICMP messages 59 to which an extension structure can be appended include an "original 60 datagram" field. The "original datagram" field contains the initial 61 octets of the datagram to which the ICMP message is a response. 62 Although the original datagram field is of variable length, the ICMP 63 message does not include a field that specifies its length. 64 Therefore, in order to facilitate message parsing, this draft 65 allocates eight previously reserved bits to reflect the length of the 66 "original datagram" field. 68 The proposed modifications change the requirements for ICMP 69 compliance. The impact of these changes on compliant implementations 70 is discussed, and new requirements for future implementations are 71 presented. 73 Table of Contents 75 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Summary of Changes to ICMP . . . . . . . . . . . . . . . . . . 5 78 4. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. ICMPv4 Destination Unreachable . . . . . . . . . . . . . . 7 80 4.2. ICMPv4 Time Exceeded . . . . . . . . . . . . . . . . . . . 8 81 4.3. ICMPv4 Parameter Problem . . . . . . . . . . . . . . . . . 9 82 4.4. ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 9 83 4.5. ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 10 84 4.6. ICMP Messages That Can Be Extended . . . . . . . . . . . . 10 85 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 86 5.1. Classic Application Receives ICMP Message With 87 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.2. Non-compliant Application Receives ICMP Message With 89 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 90 5.3. Non-compliant Application Receives ICMP Message With 91 Compliant Extensions . . . . . . . . . . . . . . . . . . . 14 92 5.4. Compliant Application Receives ICMP Message with No 93 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.5. Compliant Application Receives ICMP Message with 95 Non-compliant Extensions . . . . . . . . . . . . . . . . . 14 96 6. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 15 97 7. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 16 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 105 Intellectual Property and Copyright Statements . . . . . . . . . . 20 107 1. Conventions Used In This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119 [1]. 113 2. Introduction 115 This document redefines selected ICMPv4 [2] and ICMPv6 [3] messages 116 to include an extension structure and a length attribute. The 117 extension structure supports multi-part ICMP operation. Protocol 118 designers can make an ICMP message carry additional information by 119 encoding that information in an extension object. 121 This document also addresses a fundamental problem in ICMP 122 extensibility. Many of the ICMP messages addressed by this memo 123 include an "original datagram" field. The "original datagram" field 124 contains the initial octets of the datagram to which the ICMP message 125 is a response. Although the "original datagram" field is of variable 126 length, the ICMP message does not include a field that specifies its 127 length. 129 Application software infers the length of the "original datagram" 130 field from the total length of the ICMP message. If an extension 131 structure were appended to the message without adding a length 132 attribute for the "original datagram" field, the message would become 133 unparsable. Specifically, application software would not be able to 134 determine where the "original datagram" field ends and where the 135 extension structure begins. Therefore, this document proposes a 136 length attribute as well as an extension structure that is appended 137 to the ICMP message. 139 The current memo also addresses backwards compatibility with existing 140 ICMP implementations that either do not implement the extensions 141 defined herein or implement them without adding the required length 142 attributes. In particular, this draft addresses backwards 143 compatibility with certain, widely deployed, MPLS-aware ICMPv4 144 implementations that send the extensions defined herein without 145 adding the required length attribute. 147 The current memo does not define any ICMP extension objects. It 148 defines only the extension header and a common header that all 149 extension objects share. Reference [6] and reference [7] provide 150 sample applications of the ICMP Extension Object. 152 The above mentioned memos share a common characteristic. They both 153 append information to the ICMP Time Expired message for consumption 154 by TRACEROUTE. In this case, as in many others, appending 155 information to the existing ICMP Time Expired Message is preferable 156 to defining a new message and emitting two messages whenever a packet 157 is dropped to to TTL expiration. 159 3. Summary of Changes to ICMP 161 The following is a summary of changes to ICMP that are proposed by 162 this memo: 164 An ICMP Extension Structure MAY be appended to ICMPv4 Destination 165 Unreachable, Time Exceeded, and Parameter Problem messages. 167 An ICMP Extension Structure MAY be appended to ICMPv6 Destination 168 Unreachable, and Time Exceeded messages. 170 The above mentioned messages include an "original datagram" field, 171 and the message formats are updated to specify a length attribute 172 for the "original datagram" field. 174 The "original datagram" field MUST include at least 128 octets. 175 If the original datagram did not contain 128 octets, the "original 176 datagram" field MUST be zero padded to 128 octets. 178 The "original datagram" field MUST be zero padded to the nearest 179 32-bit boundary. 181 4. ICMP Extensibility 183 RFC 792 defines the following ICMPv4 message types: 185 - Destination Unreachable 187 - Time Exceeded 189 - Parameter Problem 191 - Source Quench 193 - Redirect 195 - Echo Request/Reply 196 - Timestamp/Timestamp Reply 198 - Information Request/Information Reply 200 RFC 1191 [4] reserves bits for the "Next-Hop MTU" field in the 201 Destination Unreachable message. 203 RFC 4443 defines the following ICMPv6 message types: 205 - Destination Unreachable 207 - Packet Too Big 209 - Time Exceeded 211 - Parameter Problem 213 - Echo Request/Reply 215 Many ICMP messages are extensible as currently defined. Protocol 216 designers can extend ICMP messages by simply appending fields or data 217 structures to them. 219 Many ICMP messages are not extensible as currently defined. These 220 messages contain an "original datagram" field which represents the 221 leading octets of the datagram to which the ICMP message is a 222 response. RFC 792 defines the "original datagram" field for ICMPv4 223 messages. In RFC 792, the "original datagram" field includes the IP 224 header plus the next eight octets of the original datagram. RFC 1812 225 [5] extends the "original datagram" field to contain as many octets 226 as possible without causing the ICMP message to exceed the minimum 227 IPv4 MTU (i.e., 576 octets). RFC 4443 defines the "original 228 datagram" field for ICMPv6 messages. In RFC 4443, the "original 229 datagram" field always contained as many octets as possible without 230 causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 231 octets). 233 Unfortunately, the "original datagram" field lacks a length 234 attribute. Application software infers the length of this field from 235 the total length of the ICMP message. If an extension structure were 236 appended to the message without adding a length attribute for the 237 "original datagram" field, the message would become unparsable. 238 Specifically, application software would not be able to determine 239 where the "original datagram" field ends and where the extension 240 structure begins. 242 In order to solve this problem, this memo introduces an 8-bit length 243 attribute to the following ICMPv4 messages. 245 - Destination Unreachable (type = 3) 247 - Time Exceeded (type = 11) 249 - Parameter Problem (type = 12) 251 It also introduces an 9-bit length attribute to the following ICMPv6 252 messages. 254 - Destination Unreachable (type = 1) 256 - Time Exceeded (type = 3) 258 The length attribute MUST be specified when the ICMP Extension 259 Structure is appended to the above mentioned ICMP messages. 261 The length attribute represents the length of the "original datagram" 262 field, measured in 32-bit words. When the length attribute is 263 specified, the "original datagram" field MUST be zero padded to the 264 nearest 32-bit boundary. Space for the length attribute is claimed 265 from reserved octets, whose value was previously required to be zero. 266 Because the sixth octet of each of the impacted ICMPv4 messages was 267 reserved for future use, this octet was selected as the location of 268 the length attribute in ICMPv4. Likewise, because the seventh and 269 eighth octets of each of the impacted ICMPv6 messages were reserved 270 for future use, these octets were selected as the location of the 271 length attribute in ICMPv6. 273 In order the achieve backwards compatibility, when the ICMP Extension 274 Structure is appended to an ICMP message and that ICMP message 275 contains an "original datagram" field, the "original datagram" field 276 MUST contain at least 128 octets. If the original datagram did not 277 contain 128 octets, the "original datagram" field MUST be zero padded 278 to 128 octets. (See Section 5.1 for rationale.) 280 The following sub-sections depict length attribute as it has been 281 introduced to selected ICMP messages. 283 4.1. ICMPv4 Destination Unreachable 285 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Code | Checksum | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | unused | Length | Next-Hop MTU* | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Internet Header + leading octets of original datagram | 295 | | 296 | // | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 1: ICMPv4 Destination Unreachable 302 The syntax and semantics of all fields are unchanged from RFC 792. 303 However, a length attribute is added to the second word. The length 304 attribute represents length of the padded "original datagram" field, 305 measured in 32-bit words. 307 The Next-Hop MTU field is not required in all cases. It is depicted 308 only to demonstrate that those bits are not available for assignment 309 in this memo. 311 4.2. ICMPv4 Time Exceeded 313 Figure 2 depicts the ICMPv4 Time Exceeded Message. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Code | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | unused | Length | unused | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Internet Header + leading octets of original datagram | 323 | | 324 | // | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: ICMPv4 Time Exceeded 330 The syntax and semantics of all fields are unchanged from RFC 792, 331 except for a length attribute which is added to the second word. The 332 length attribute represents length of the padded "original datagram" 333 field, measured in 32-bit words. 335 4.3. ICMPv4 Parameter Problem 337 Figure 3 depicts the ICMPv4 Parameter Problem Message. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Code | Checksum | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Pointer | Length | unused | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Internet Header + leading octets of original datagram | 347 | | 348 | // | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 3: ICMPv4 Parameter Problem 354 The syntax and semantics of all fields are unchanged from RFC 792, 355 except for a length attribute which is added to the second word. The 356 length attribute represents length of the padded "original datagram" 357 field, measured in 32-bit words. 359 4.4. ICMPv6 Destination Unreachable 361 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Code | Checksum | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Unused | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | As much of invoking packet | 371 + as will fit without the ICMPv6 packet + 372 | exceeding the minimum IPv6 MTU [IPv6] | 374 Figure 4: ICMPv6 Destination Unreachable 376 The syntax and semantics of all fields are unchanged from RFC 4443. 378 However, a length attribute is added to the second word. The length 379 attribute represents length of the padded "original datagram" field, 380 measured in 32-bit words. 382 4.5. ICMPv6 Time Exceeded 384 Figure 5 depicts the ICMPv6 Time Exceeded Message. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Code | Checksum | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Unused | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | As much of invoking packet | 394 + as will fit without the ICMPv6 packet + 395 | exceeding the minimum IPv6 MTU [IPv6] | 397 Figure 5: ICMPv6 Time Exceeded 399 The syntax and semantics of all fields are unchanged from RFC 4443, 400 except for a length attribute which is added to the second word. The 401 length attribute represents length of the padded "original datagram" 402 field, measured in 32-bit words. 404 4.6. ICMP Messages That Can Be Extended 406 The ICMP Extension Structure MAY be appended to messages of the 407 following types: 409 - ICMPv4 Destination Unreachable 411 - ICMPv4 Time Exceeded 413 - ICMPv4 Parameter Problem 415 - ICMPv6 Destination Unreachable 417 - ICMPv6 Time Exceeded 419 The ICMP Extension Structure MUST NOT be appended to any of the other 420 ICMP messages mentioned in Section 4. 422 ICMP messages defined in the future SHOULD indicate whether or not 423 they support the extension mechanism defined in this specification. 425 It is recommended that all new messages support extensions. 427 5. Backwards Compatibility 429 ICMP messages can be categorized as follows: 431 - Messages that do not include any ICMP extensions 433 - Messages that include non-compliant ICMP extensions 435 - Messages that includes compliant ICMP extensions 437 Any ICMP implementation can send a message that does not include 438 extensions. ICMP implementations produced prior to 1999 are not 439 known to send ICMP extensions. 441 Some ICMP implementations, produced between 1999 and the present, may 442 send a non-compliant version of ICMP extensions described in this 443 memo. Specifically, these implementations may append the ICMP 444 Extension Structure to the Time Exceeded and Destination Unreachable 445 messages. When they do this, they send exactly 128 octets 446 representing the original datagram, zero padding if required. They 447 also calculate checksums as described in this document. However, 448 they do not specify a length attribute to be associated with the 449 "original datagram" field. 451 It is assumed that ICMP implementations produced in the future will 452 send ICMP extensions that are compliant with this specification. 454 Likewise, applications that consume ICMP messages can be categorized 455 as follows: 457 - Classic applications 459 - Non-compliant applications 461 - Compliant applications 463 Classic applications do not parse extensions defined in this memo. 464 They are insensitive to the length attribute that is associated with 465 the "original datagram" field. 467 Non-compliant implementations parse the extensions defined in this 468 memo, but only in conjunction with the Time Expired and Destination 469 Unreachable messages. They require the "original datagram" field to 470 contain exactly 128 octets and are insensitive to the length 471 attribute that is associated with the "original datagram" field. 473 Non-compliant applications were produced between 1999 and the 474 present. 476 Compliant applications comply fully with the specifications of this 477 document. 479 In order to demonstrate backwards compatibility, Table 1 describes 480 how members of each application category would parse each category of 481 ICMP message. 483 +----------------+----------------+----------------+----------------+ 484 | | No Extensions | Non-compliant | Compliant | 485 | | | Extensions | Extensions | 486 +----------------+----------------+----------------+----------------+ 487 | Classic | - | Section 5.1 | Section 5.1 | 488 | Application | | | | 489 | | | | | 490 | Non-compliant | Section 5.2 | - | Section 5.3 | 491 | Application | | | | 492 | | | | | 493 | Compliant | Section 5.4 | Section 5.5 | - | 494 | Application | | | | 495 +----------------+----------------+----------------+----------------+ 497 Table 1 499 In the table above, cells that contain a dash represent the nominal 500 case and require no explanation. In the following sections, we 501 assume that the ICMP message type is "Time Exceeded". 503 5.1. Classic Application Receives ICMP Message With Extensions 505 When a classic application receives an ICMP message that includes 506 extensions, it will incorrectly interpret those extensions as being 507 part of the "original datagram" field. Fortunately, the extensions 508 are guaranteed to begin at least 128 octets beyond the beginning of 509 the "original datagram" field. So, only those ICMP applications that 510 process the 129th octet of the "original datagram" field will be 511 adversely effected. To date, only two applications falling into this 512 catagory have been identified and the degree to which they are 513 effected is minimal. 515 Some TCP stacks, when they receive an ICMP message, verify the 516 checksum in the original datagram field [8]. If the checksum is 517 incorrect, the TCP stack discards the ICMP message for security 518 reasons. If the trailing octets of the original datagram field are 519 overwritten by ICMP extensions, the TCP stack will discard an ICMP 520 message that it would not otherwise have discarded. The impact of 521 this issue is considered to be minimal because many ICMP messages are 522 discarded for other reasons (e.g., ICMP filtering, network 523 congestion, checksum was incorrect because original datagram field 524 was truncated.) 526 Another theoretically possible, but highly improbably scenario occurs 527 when ICMP extensions overwrite the portion of the original datagram 528 field that represents the TCP header, causing the TCP stack to 529 operate upon the wrong TCP connection. This scenario is highly 530 unlikely because it occurs only when the TCP header appears at or 531 beyond the 128th octet of the original datagram field and then only 532 when the extensions approximate a valid TCP header. 534 5.2. Non-compliant Application Receives ICMP Message With No Extensions 536 When a non-compliant ICMPv4 application receives a message that 537 contains no extensions, the application examines the total length of 538 the ICMPv4 message. If the total ICMPv4 message length is less than 539 the length of its IP header plus 144 octets, the application 540 correctly determines that the message does not contain any 541 extensions. 543 The 144 octet sum is derived from 8 octets for the first two words of 544 the ICMPv4 Time Exceeded message, 128 octets for the "original 545 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 546 for a single ICMP Object header. All of these octets would be 547 required if extensions were present. 549 If the ICMPv4 payload contains 144 octets or more, the application 550 must examine the 137th octet to determine whether it represents a 551 valid ICMPv4 Extension Header. In order to represent a valid 552 Extension Header, it must contain a valid version number and 553 checksum. If it does not contain a valid version number and 554 checksum, the application correctly determines that the message does 555 not contain any extensions. 557 Non-compliant applications assume that the ICMPv4 Extension Structure 558 begins on the 137th octet of the Time Exceeded message, after a 128 559 octet field representing the padded "original datagram" message. 561 It is possible that a non-compliant application will parse an ICMPv4 562 message incorrectly under the following conditions: 564 - the message does not contain extensions 565 - the original datagram field contains 144 octets or more 567 - selected octets of the original datagram field represent the 568 correct values for an extension header version number and checksum 570 Although this is possible, it is very unlikely. 572 A similar analysis can be performed for ICMPv6. However, the numeric 573 constants would change as appropriate. 575 5.3. Non-compliant Application Receives ICMP Message With Compliant 576 Extensions 578 When a non-compliant application receives a message that contains 579 compliant ICMP extensions, it will parse those extensions correctly 580 only if the "original datagram" field contains exactly 128 octets. 581 This is because non-compliant applications are insensitive to the 582 length attribute that is associated with the "original datagram" 583 field. (They assume its value to be 128.) 585 Provided that the entire ICMP messages does not exceed the minimum 586 reassembly buffer size (576 octets for ICMPv4 or 1280 octets for 587 ICMPv6), there is no upper limit upon the length of the "original 588 datagram" field. However, each vendor will decide how many octets to 589 include. Those wishing to be backward compatible with non-compliant 590 TRACEROUTE implementations will include exactly 128 octets. Those 591 not requiring compatibility with non-compliant TRACEROUTE 592 applications may include more octets. 594 5.4. Compliant Application Receives ICMP Message with No Extensions 596 When a compliant application receives an ICMP message, it examines 597 the length attribute that is associated with the "original datagram" 598 field. If the length attribute is zero, the compliant application 599 MUST determine that the message contains no extensions. 601 5.5. Compliant Application Receives ICMP Message with Non-compliant 602 Extensions 604 When a compliant application receives an ICMP message, it examines 605 the length attribute that is associated with the "original datagram" 606 field. If the length attribute is zero, the compliant application 607 MUST determine that the message contains no extensions. In this 608 case, that determination is technically correct, but not backwards 609 compatible with the non-compliant implementation that originated the 610 ICMP message. 612 So, to ease transition yet encourage compliant implementation, 613 compliant TRACEROUTE implementations MAY include a non-default 614 operation mode to also interpret non-compliant responses. 615 Specifically, when a TRACEROUTE application operating in non- 616 compliant mode receives a sufficiently long ICMP message that does 617 not specify a length attribute, it will parse for a valid extension 618 header at a fixed location, assuming a 128 octet "original datagram" 619 field. If the application detects a valid version and checksum, it 620 will treat the following octets as an extension structure. 622 6. The ICMP Extension Structure 624 This memo proposes an optional ICMP Extension Structure that can be 625 appended to the ICMP messages referenced in Section 4.6 of this 626 document. 628 The Extension Structure contains exactly one Extension Header 629 followed by one or more objects. Having received an ICMP message 630 with extensions, application software MAY process selected objects 631 while ignoring others. The presence of an unrecognized object does 632 not imply that an ICMP message is malformed. 634 As stated above, the total length of the ICMP message, including 635 extensions, MUST NOT exceed the minimum reassembly buffer size. 636 Figure 6 depicts the ICMP Extension Header. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |Version| (Reserved) | Checksum | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 6: ICMP Extension Header 646 The fields of the ICMP Extension Header are as follows: 648 Version: 4 bits 650 ICMP extension version number. This is version 2. 652 Reserved: 12 bits 654 Must be set to 0. 656 Checksum: 16 bits 657 The one's complement of the one's complement sum of the data 658 structure, with the checksum field replaced by zero for the 659 purpose of computing the checksum. An all-zero value means that 660 no checksum was transmitted. See Section 5.2 for a description of 661 how this field is used. 663 7. ICMP Extension Objects 665 Each extension object contains one or more 32-bit words, representing 666 an object header and payload. All object headers share a common 667 format. Figure 7 depicts the Object Header and payload. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Length | Class-Num | C-Type | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | | 675 | // (Object payload) // | 676 | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 7: Object Header and Payload 681 An object header has the following fields: 683 Length: 16 bits 685 Length of the object, measured in octets, including the object 686 header and object payload. 688 Class-Num: 8 bits 690 Identifies object class. 692 C-Type: 8 bits 694 Identifies object sub-type. 696 8. Security Considerations 698 Upon receipt of an ICMP message, application software must check it 699 for syntactic correctness. The extension checksum must be verified. 700 Improperly specified length attributes and other syntax problems may 701 result in buffer overruns. 703 This memo does not define the conditions under which a router sends 704 an ICMP message. Therefore, it does not expose routers to any new 705 denial of service attacks. Routers may need to limit the rate at 706 which ICMP messages are sent. 708 9. IANA Considerations 710 The ICMP Extension Object header contains two 8-bit fields: The 711 Class-Num identifies the object class, and the C-Type identifies the 712 class sub-type. Sub-type values are defined relative to a specific 713 object class value, and are defined per-class. 715 IANA should establish a registry of ICMP extension objects classes 716 and class sub-types. There are no values assigned within this 717 document to maintain. Object classes 0xF7 - 0xFF are reserved for 718 private use. Object class values are assignable on a first-come- 719 first-serve. The policy for assigning sub-type values should be 720 defined in the document defining new class values. 722 10. Acknowledgments 724 Thanks to Joe Touch and Fernando Gont for their comments regarding 725 this draft. 727 11. References 729 11.1. Normative References 731 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 732 Levels", BCP 14, RFC 2119, March 1997. 734 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 735 September 1981. 737 [3] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 738 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 739 Specification", RFC 4443, March 2006. 741 [4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 742 November 1990. 744 [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 745 June 1995. 747 11.2. Informative References 749 [6] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 750 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 752 [7] Bonica, R., "ICMP Extensions for MultiProtocol Label Switching", 753 draft-ietf-mpls-icmp-06 (work in progress), September 2006. 755 [8] Gont, F., "ICMP attacks against TCP", 756 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 757 February 2006. 759 Authors' Addresses 761 Ronald P. Bonica 762 Juniper Networks 763 2251 Corporate Park Drive 764 Herndon, VA 20171 765 US 767 Email: rbonica@juniper.net 769 Der-Hwa Gan 770 Juniper Networks 771 1194 N. Mathilda Ave. 772 Sunnyvale, CA 94089 773 US 775 Email: dhg@juniper.net 777 Pekka Nikander 778 Ericsson Research Nomadic Lab 779 JORVAS FIN-02420 780 Finland 782 Email: pekka.nikander@nomadiclab.com 783 Daniel C. Tappan 784 Cisco Systems, Inc. 785 250 Apollo Drive 786 Chelmsford, MA 01824 787 US 789 Email: tappan@cisco.com 791 Carlos Pignataro 792 Cisco Systems, Inc. 793 7025 Kit Creek Road 794 Research Triangle Park, N.C. 27709 795 US 797 Email: cpignata@cisco.com 799 Full Copyright Statement 801 Copyright (C) The Internet Society (2006). 803 This document is subject to the rights, licenses and restrictions 804 contained in BCP 78, and except as set forth therein, the authors 805 retain all their rights. 807 This document and the information contained herein are provided on an 808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 815 Intellectual Property 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed to 819 pertain to the implementation or use of the technology described in 820 this document or the extent to which any license under such rights 821 might or might not be available; nor does it represent that it has 822 made any independent effort to identify any such rights. Information 823 on the procedures with respect to rights in RFC documents can be 824 found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use of 829 such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository at 831 http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org. 839 Acknowledgment 841 Funding for the RFC Editor function is provided by the IETF 842 Administrative Support Activity (IASA).