idnits 2.17.1 draft-bonica-internet-icmp-07.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 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 791. ** 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The ICMP Extension Structure MAY NOT be appended to any of the other ICMP messages mentioned in Section 4. -- 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 (August 4, 2006) is 6476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'IPv6' on line 380 ** Obsolete normative reference: RFC 2463 (ref. '3') (Obsoleted by RFC 4443) == 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-05 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: February 5, 2007 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 August 4, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-07 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 February 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 . . . . . . . . . . . . . . . . . 8 82 4.4. ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 9 83 4.5. ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 9 84 4.6. ICMP Messages That Can Be Extended . . . . . . . . . . . . 10 85 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 12 90 5.3. Non-compliant Application Receives ICMP Message With 91 Compliant Extensions . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 14 97 7. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 15 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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. 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 [5] and reference [6] provide 150 sample applications of the ICMP Extension Object. 152 3. Summary of Changes to ICMP 154 The following is a summary of changes to ICMP that are proposed by 155 this memo: 157 An ICMP Extension Structure MAY be appended to ICMPv4 Destination 158 Unreachable, Time Exceeded, and Parameter Problem messages. 160 An ICMP Extension Structure MAY be appended to ICMPv6 Destination 161 Unreachable, and Time Exceeded messages. 163 The above mentioned messages include an "original datagram" field, 164 and the message formats are updated to specify a length attribute 165 for the "original datagram" field. 167 The "original datagram" field MUST include at least 128 octets. 168 If the original datagram did not contain 128 octets, the "original 169 datagram" field MUST be zero padded to 128 octets. 171 The "original datagram" field MUST be zero padded to the nearest 172 32-bit boundary. 174 4. ICMP Extensibility 176 RFC 792 defines the following ICMPv4 message types: 178 - Destination Unreachable 180 - Time Exceeded 182 - Parameter Problem 184 - Source Quench 186 - Redirect 188 - Echo Request/Reply 190 - Timestamp/Timestamp Reply 192 - Information Request/Information Reply 194 Likewise, RFC 2463 defines the following ICMPv6 message types: 196 - Destination Unreachable 198 - Packet Too Big 200 - Time Exceeded 202 - Parameter Problem 204 - Echo Request/Reply 206 Many ICMP messages are extensible as currently defined. Protocol 207 designers can extend ICMP messages by simply appending fields or data 208 structures to them. 210 Many ICMP messages are not extensible as currently defined. These 211 messages contain an "original datagram" field which represents the 212 leading octets of the datagram to which the ICMP message is a 213 response. RFC 792 defines the "original datagram" field for ICMPv4 214 messages. In RFC 792, the "original datagram" field includes the IP 215 header plus the next eight octets of the original datagram. RFC 1812 216 [4] extends the "original datagram" field to contain as many octets 217 as possible without causing the ICMP message to exceed the minimum 218 IPv4 MTU (i.e., 576 octets). RFC 2463 defines the "original 219 datagram" field for ICMPv6 messages. In RFC 2463, the "original 220 datagram" field always contained as many octets as possible without 221 causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 222 octets). 224 Unfortunately, the "original datagram" field lacks a length 225 attribute. Application software infers the length of this field from 226 the total length of the ICMP message. If an extension structure were 227 appended to the message without adding a length attribute for the 228 "original datagram" field, the message would become unparsable. 229 Specifically, application software would not be able to determine 230 where the "original datagram" field ends and where the extension 231 structure begins. 233 In order to solve this problem, this memo introduces an 8-bit length 234 attribute to the following ICMPv4 messages. 236 - Destination Unreachable 238 - Time Exceeded 240 - Parameter Problem 242 It also introduces an 8-bit length attribute to the following ICMPv6 243 messages. 245 - Destination Unreachable 247 - Time Exceeded 249 The length attribute MUST be specified when the ICMP Extension 250 Structure is appended to the above mentioned ICMP messages. 252 The length attribute represents the length of the "original datagram" 253 field, measured in 32-bit words. When the length attribute is 254 specified, the "original datagram" field MUST be zero padded to the 255 nearest 32-bit boundary. Space for the length attribute is claimed 256 from reserved octets, whose value was previously required to be zero. 257 Because the sixth octet of each of the impacted ICMPv4 messages was 258 reserved for future use, this octet was selected as the location of 259 the length attribute in ICMPv4. Likewise, because the fifth octet of 260 each of the impacted ICMPv6 messages was reserved for future use, 261 this octet was selected as the location of the length attribute in 262 ICMPv6. 264 In order the achieve backwards compatibility, when the ICMP Extension 265 Structure is appended to an ICMP message and that ICMP message 266 contains an "original datagram" field, the "original datagram" field 267 MUST contain at least 128 octets. If the original datagram did not 268 contain 128 octets, the "original datagram" field MUST be zero padded 269 to 128 octets. (See Section 5.1 for rationale.) 271 The following sub-sections depict length attribute as it has been 272 introduced to selected ICMP messages. 274 4.1. ICMPv4 Destination Unreachable 276 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Code | Checksum | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | unused | Length | Next-Hop MTU | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Internet Header + leading octets of original datagram | 286 | | 287 | // | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 1: ICMPv4 Destination Unreachable 292 The syntax and semantics of all fields are unchanged from RFC 792. 293 However, a length attribute is added to the second word. The length 294 attribute represents length of the padded "original datagram" field, 295 measured in 32-bit words. 297 4.2. ICMPv4 Time Exceeded 299 Figure 2 depicts the ICMPv4 Time Exceeded Message. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Code | Checksum | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | unused | Length | unused | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Internet Header + leading octets of original datagram | 309 | | 310 | // | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 2: ICMPv4 Time Exceeded 316 The syntax and semantics of all fields are unchanged from RFC 792, 317 except for a length attribute which is added to the second word. The 318 length attribute represents length of the padded "original datagram" 319 field, measured in 32-bit words. 321 4.3. ICMPv4 Parameter Problem 323 Figure 3 depicts the ICMPv4 Parameter Problem Message. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Code | Checksum | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Pointer | Length | unused | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Internet Header + leading octets of original datagram | 333 | | 334 | // | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 3: ICMPv4 Parameter Problem 340 The syntax and semantics of all fields are unchanged from RFC 792, 341 except for a length attribute which is added to the second word. The 342 length attribute represents length of the padded "original datagram" 343 field, measured in 32-bit words. 345 4.4. ICMPv6 Destination Unreachable 347 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Code | Checksum | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Length | Unused | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | As much of invoking packet | 357 + as will fit without the ICMPv6 packet + 358 | exceeding the minimum IPv6 MTU [IPv6] | 360 Figure 4: ICMPv6 Destination Unreachable 362 The syntax and semantics of all fields are unchanged from RFC 2463. 363 However, a length attribute is added to the second word. The length 364 attribute represents length of the padded "original datagram" field, 365 measured in 32-bit words. 367 4.5. ICMPv6 Time Exceeded 369 Figure 5 depicts the ICMPv6 Time Exceeded Message. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Code | Checksum | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Length | Unused | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | As much of invoking packet | 379 + as will fit without the ICMPv6 packet + 380 | exceeding the minimum IPv6 MTU [IPv6] | 382 Figure 5: ICMPv6 Time Exceeded 384 The syntax and semantics of all fields are unchanged from RFC 2463, 385 except for a length attribute which is added to the second word. The 386 length attribute represents length of the padded "original datagram" 387 field, measured in 32-bit words. 389 4.6. ICMP Messages That Can Be Extended 391 The ICMP Extension Structure MAY be appended to messages of the 392 following types: 394 - ICMPv4 Destination Unreachable 396 - ICMPv4 Time Exceeded 398 - ICMPv4 Parameter Problem 400 - ICMPv6 Destination Unreachable 402 - ICMPv6 Time Exceeded 404 The ICMP Extension Structure MAY NOT be appended to any of the other 405 ICMP messages mentioned in Section 4. 407 ICMP messages defined in the future SHOULD indicate whether or not 408 they support the extension mechanism defined in this specification. 409 It is recommended that all new messages support extensions. 411 5. Backwards Compatibility 413 ICMP messages can be categorized as follows: 415 - Messages that do not include any ICMP extensions 417 - Messages that include non-compliant ICMP extensions 419 - Messages that includes compliant ICMP extensions 421 Any ICMP implementation can send a message that does not include 422 extensions. ICMP implementations produced prior to 1999 are not 423 known to send ICMP extensions. 425 Some ICMP implementations, produced between 1999 and the present, may 426 send a non-compliant version of ICMP extensions described in this 427 memo. Specifically, these implementations may append the ICMP 428 Extension Structure to the Time Exceeded and Destination Unreachable 429 messages. When they do this, they send exactly 128 octets 430 representing the original datagram, zero padding if required. They 431 also calculate checksums as described in this document. However, 432 they do not specify a length attribute to be associated with the 433 "original datagram" field. 435 It is assumed that ICMP implementations produced in the future will 436 send ICMP extensions that are compliant with this specification. 438 Likewise, applications that consume ICMP messages can be categorized 439 as follows: 441 - Classic applications 443 - Non-compliant applications 445 - Compliant applications 447 Classic applications do not parse extensions defined in this memo. 448 They are insensitive to the length attribute that is associated with 449 the "original datagram" field. 451 Non-compliant implementations parse the extensions defined in this 452 memo, but only in conjunction with the Time Expired and Destination 453 Unreachable messages. They require the "original datagram" field to 454 contain exactly 128 octets and are insensitive to the length 455 attribute that is associated with the "original datagram" field. 456 Non-compliant applications were produced between 1999 and the 457 present. 459 Compliant applications comply fully with the specifications of this 460 document. 462 In order to demonstrate backwards compatibility, Table 1 describes 463 how members of each application category would parse each category of 464 ICMP message. 466 +----------------+----------------+----------------+----------------+ 467 | | No Extensions | Non-compliant | Compliant | 468 | | | Extensions | Extensions | 469 +----------------+----------------+----------------+----------------+ 470 | Classic | - | Section 5.1 | Section 5.1 | 471 | Application | | | | 472 | | | | | 473 | Non-compliant | Section 5.2 | - | Section 5.3 | 474 | Application | | | | 475 | | | | | 476 | Compliant | Section 5.4 | Section 5.5 | - | 477 | Application | | | | 478 +----------------+----------------+----------------+----------------+ 480 Table 1 482 In the table above, cells that contain a dash represent the nominal 483 case and require no explanation. In the following sections, we 484 assume that the ICMP message type is "Time Exceeded". 486 5.1. Classic Application Receives ICMP Message With Extensions 488 When a classic application receives an ICMP message that includes 489 extensions, it will incorrectly interpret those extensions as being 490 part of the "original datagram" field. Fortunately, the extensions 491 are guaranteed to begin at least 128 octets beyond the beginning of 492 the "original datagram" field. So, only those ICMP applications that 493 process the 129th octet of the "original datagram" field will be 494 adversely effected. To date, no such applications have been 495 identified. 497 5.2. Non-compliant Application Receives ICMP Message With No Extensions 499 When a non-compliant ICMPv4 application receives a message that 500 contains no extensions, the application examines the total length of 501 the ICMPv4 message. If the total ICMPv4 message length is less than 502 the length of its IP header plus 144 octets, the application 503 correctly determines that the message does not contain any 504 extensions. 506 The 144 octet sum is derived from 8 octets for the first two words of 507 the ICMPv4 Time Exceeded message, 128 octets for the "original 508 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 509 for a single ICMP Object header. All of these octets would be 510 required if extensions were present. 512 If the ICMPv4 payload contains 144 octets or more, the application 513 must examine the 137th octet to determine whether it represents a 514 valid ICMPv4 Extension Header. In order to represent a valid 515 Extension Header, it must contain a valid version number and 516 checksum. If it does not contain a valid version number and 517 checksum, the application correctly determines that the message does 518 not contain any extensions. 520 Non-compliant applications assume that the ICMPv4 Extension Structure 521 begins on the 137th octet of the Time Exceeded message, after a 128 522 octet field representing the padded "original datagram" message. 524 It is possible that a non-compliant application will parse an ICMPv4 525 message incorrectly under the following conditions: 527 - the message does not contain extensions 529 - the original datagram field contains 144 octets or more 531 - selected octets of the original datagram field represent the 532 correct values for an extension header version number and checksum 534 Although this is possible, it is very unlikely. 536 A similar analysis can be performed for ICMPv6. However, the numeric 537 constants would change as appropriate. 539 5.3. Non-compliant Application Receives ICMP Message With Compliant 540 Extensions 542 When a non-compliant application receives a message that contains 543 compliant ICMP extensions, it will parse those extensions correctly 544 only if the "original datagram" field contains exactly 128 octets. 545 This is because non-compliant applications are insensitive to the 546 length attribute that is associated with the "original datagram" 547 field. (They assume its value to be 128.) 549 Provided that the entire ICMP messages does not exceed the minimum 550 MTU (576 octets for ICMPv4 or 1280 octets for ICMPv6), there is no 551 upper limit upon the length of the "original datagram" field. 552 However, each vendor will decide how many octets to include. Those 553 wishing to be backward compatible with non-compliant TRACEROUTE 554 implementations will include exactly 128 octets. Those not requiring 555 compatibility with non-compliant TRACEROUTE applications may include 556 more octets. 558 5.4. Compliant Application Receives ICMP Message with No Extensions 560 When a compliant application receives an ICMP message, it examines 561 the length attribute that is associated with the "original datagram" 562 field. If the length attribute is zero, the compliant application 563 MUST determine that the message contains no extensions. 565 5.5. Compliant Application Receives ICMP Message with Non-compliant 566 Extensions 568 When a compliant application receives an ICMP message, it examines 569 the length attribute that is associated with the "original datagram" 570 field. If the length attribute is zero, the compliant application 571 MUST determine that the message contains no extensions. In this 572 case, that determination is technically correct, but not backwards 573 compatible with the non-compliant implementation that originated the 574 ICMP message. 576 So, to ease transition yet encourage compliant implementation, 577 compliant TRACEROUTE implementations MAY include a non-default 578 operation mode to also interpret non-compliant responses. 579 Specifically, when a TRACEROUTE application operating in non- 580 compliant mode receives a sufficiently long ICMP message that does 581 not specify a length attribute, it will parse for a valid extension 582 header at a fixed location, assuming a 128 octet "original datagram" 583 field. If the application detects a valid version and checksum, it 584 will treat the following octets as an extension structure. 586 6. The ICMP Extension Structure 588 This memo proposes an optional ICMP Extension Structure that can be 589 appended to the ICMP messages referenced in Section 4.6 of this 590 document. 592 The Extension Structure contains exactly one Extension Header 593 followed by one or more objects. Having received an ICMP message 594 with extensions, application software MAY process selected objects 595 while ignoring others. The presence of an unrecognized object does 596 not imply that an ICMP message is malformed. 598 As stated above, the total length of the ICMP message, including 599 extensions, MUST NOT exceed the minimum protocol MTU. Figure 6 600 depicts the ICMP Extension Header. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |Version| (Reserved) | Checksum | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 6: ICMP Extension Header 610 The fields of the ICMP Extension Header are as follows: 612 Version: 4 bits 614 ICMP extension version number. This is version 2. 616 Reserved: 12 bits 618 Must be set to 0. 620 Checksum: 16 bits 622 The one's complement of the one's complement sum of the data 623 structure, with the checksum field replaced by zero for the 624 purpose of computing the checksum. An all-zero value means that 625 no checksum was transmitted. 627 7. ICMP Extension Objects 629 Each extension object contains one or more 32-bit words, representing 630 an object header and payload. All object headers share a common 631 format. Figure 7 depicts the Object Header and payload. 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Length | Class-Num | C-Type | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | 639 | // (Object payload) // | 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 7: Object Header and Payload 645 An object header has the following fields: 647 Length: 16 bits 648 Length of the object, measured in octets, including the object 649 header and object payload. 651 Class-Num: 8 bits 653 Identifies object class. 655 C-Type: 8 bits 657 Identifies object sub-type. 659 8. Security Considerations 661 Upon receipt of an ICMP message, application software must check it 662 for syntactic correctness. The extension checksum must be verified. 663 Improperly specified length attributes and other syntax problems may 664 result in buffer overruns. 666 This memo does not define the conditions under which a router sends 667 an ICMP message. Therefore, it does not expose routers to any new 668 denial of service attacks. Routers may need to limit the rate at 669 which ICMP messages are sent. 671 9. IANA Considerations 673 The ICMP Extension Object header contains two 8-bit fields: The 674 Class-Num identifies the object class, and the C-Type identifies the 675 class sub-type. Sub-type values are defined relative to a specific 676 object class value, and are defined per-class. 678 IANA should establish a registry of ICMP extension objects classes 679 and class sub-types. There are no values assigned within this 680 document to maintain. Object classes 0xF7 - 0xFF are reserved for 681 private use. Object class values are assignable on a first-come- 682 first-serve. The policy for assigning sub-type values should be 683 defined in the document defining new class values. 685 10. Acknowledgments 687 Thanks to Joe Touch for his comments regarding this draft. 689 11. References 690 11.1. Normative References 692 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 693 Levels", BCP 14, RFC 2119, March 1997. 695 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 696 September 1981. 698 [3] Conta, A. and S. Deering, "Internet Control Message Protocol 699 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 700 Specification", RFC 2463, December 1998. 702 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 703 June 1995. 705 11.2. Informative References 707 [5] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 708 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 710 [6] Bonica, R., "ICMP Extensions for MultiProtocol Label Switching", 711 draft-ietf-mpls-icmp-05 (work in progress), March 2006. 713 Authors' Addresses 715 Ronald P. Bonica 716 Juniper Networks 717 2251 Corporate Park Drive 718 Herndon, VA 20171 719 US 721 Email: rbonica@juniper.net 723 Der-Hwa Gan 724 Juniper Networks 725 1194 N. Mathilda Ave. 726 Sunnyvale, CA 94089 727 US 729 Email: dhg@juniper.net 730 Pekka Nikander 731 Ericsson Research Nomadic Lab 732 JORVAS FIN-02420 733 Finland 735 Email: pekka.nikander@nomadiclab.com 737 Daniel C. Tappan 738 Cisco Systems, Inc. 739 250 Apollo Drive 740 Chelmsford, MA 01824 741 US 743 Email: tappan@cisco.com 745 Carlos Pignataro 746 Cisco Systems, Inc. 747 7025 Kit Creek Road 748 Research Triangle Park, N.C. 27709 749 US 751 Email: cpignata@cisco.com 753 Full Copyright Statement 755 Copyright (C) The Internet Society (2006). 757 This document is subject to the rights, licenses and restrictions 758 contained in BCP 78, and except as set forth therein, the authors 759 retain all their rights. 761 This document and the information contained herein are provided on an 762 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 763 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 764 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 765 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 766 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 767 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 769 Intellectual Property 771 The IETF takes no position regarding the validity or scope of any 772 Intellectual Property Rights or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; nor does it represent that it has 776 made any independent effort to identify any such rights. Information 777 on the procedures with respect to rights in RFC documents can be 778 found in BCP 78 and BCP 79. 780 Copies of IPR disclosures made to the IETF Secretariat and any 781 assurances of licenses to be made available, or the result of an 782 attempt made to obtain a general license or permission for the use of 783 such proprietary rights by implementers or users of this 784 specification can be obtained from the IETF on-line IPR repository at 785 http://www.ietf.org/ipr. 787 The IETF invites any interested party to bring to its attention any 788 copyrights, patents or patent applications, or other proprietary 789 rights that may cover technology that may be required to implement 790 this standard. Please address the information to the IETF at 791 ietf-ipr@ietf.org. 793 Acknowledgment 795 Funding for the RFC Editor function is provided by the IETF 796 Administrative Support Activity (IASA).