idnits 2.17.1 draft-bonica-internet-icmp-09.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 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. ** 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 (September 26, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'IPv6' on line 383 == 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: 3 errors (**), 0 flaws (~~), 3 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: March 30, 2007 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 September 26, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-09 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 March 30, 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 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 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 RFC 1191 [4] adds a "Next-Hop MTU" field to the Destination 195 Unreachable message. 197 RFC 4443 defines the following ICMPv6 message types: 199 - Destination Unreachable 201 - Packet Too Big 203 - Time Exceeded 205 - Parameter Problem 207 - Echo Request/Reply 209 Many ICMP messages are extensible as currently defined. Protocol 210 designers can extend ICMP messages by simply appending fields or data 211 structures to them. 213 Many ICMP messages are not extensible as currently defined. These 214 messages contain an "original datagram" field which represents the 215 leading octets of the datagram to which the ICMP message is a 216 response. RFC 792 defines the "original datagram" field for ICMPv4 217 messages. In RFC 792, the "original datagram" field includes the IP 218 header plus the next eight octets of the original datagram. RFC 1812 219 [5] extends the "original datagram" field to contain as many octets 220 as possible without causing the ICMP message to exceed the minimum 221 IPv4 MTU (i.e., 576 octets). RFC 4443 defines the "original 222 datagram" field for ICMPv6 messages. In RFC 4443, the "original 223 datagram" field always contained as many octets as possible without 224 causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 225 octets). 227 Unfortunately, the "original datagram" field lacks a length 228 attribute. Application software infers the length of this field from 229 the total length of the ICMP message. If an extension structure were 230 appended to the message without adding a length attribute for the 231 "original datagram" field, the message would become unparsable. 232 Specifically, application software would not be able to determine 233 where the "original datagram" field ends and where the extension 234 structure begins. 236 In order to solve this problem, this memo introduces an 8-bit length 237 attribute to the following ICMPv4 messages. 239 - Destination Unreachable 241 - Time Exceeded 243 - Parameter Problem 245 It also introduces an 9-bit length attribute to the following ICMPv6 246 messages. 248 - Destination Unreachable 250 - Time Exceeded 252 The length attribute MUST be specified when the ICMP Extension 253 Structure is appended to the above mentioned ICMP messages. 255 The length attribute represents the length of the "original datagram" 256 field, measured in 32-bit words. When the length attribute is 257 specified, the "original datagram" field MUST be zero padded to the 258 nearest 32-bit boundary. Space for the length attribute is claimed 259 from reserved octets, whose value was previously required to be zero. 260 Because the sixth octet of each of the impacted ICMPv4 messages was 261 reserved for future use, this octet was selected as the location of 262 the length attribute in ICMPv4. Likewise, because the seventh and 263 eighth octets of each of the impacted ICMPv6 messages were reserved 264 for future use, these octets were selected as the location of the 265 length attribute in ICMPv6. 267 In order the achieve backwards compatibility, when the ICMP Extension 268 Structure is appended to an ICMP message and that ICMP message 269 contains an "original datagram" field, the "original datagram" field 270 MUST contain at least 128 octets. If the original datagram did not 271 contain 128 octets, the "original datagram" field MUST be zero padded 272 to 128 octets. (See Section 5.1 for rationale.) 274 The following sub-sections depict length attribute as it has been 275 introduced to selected ICMP messages. 277 4.1. ICMPv4 Destination Unreachable 279 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Code | Checksum | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | unused | Length | Next-Hop MTU | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Internet Header + leading octets of original datagram | 289 | | 290 | // | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 1: ICMPv4 Destination Unreachable 295 The syntax and semantics of all fields are unchanged from RFC 792. 296 However, a length attribute is added to the second word. The length 297 attribute represents length of the padded "original datagram" field, 298 measured in 32-bit words. 300 4.2. ICMPv4 Time Exceeded 302 Figure 2 depicts the ICMPv4 Time Exceeded Message. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Code | Checksum | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | unused | Length | unused | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Internet Header + leading octets of original datagram | 312 | | 313 | // | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2: ICMPv4 Time Exceeded 319 The syntax and semantics of all fields are unchanged from RFC 792, 320 except for a length attribute which is added to the second word. The 321 length attribute represents length of the padded "original datagram" 322 field, measured in 32-bit words. 324 4.3. ICMPv4 Parameter Problem 326 Figure 3 depicts the ICMPv4 Parameter Problem Message. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Code | Checksum | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Pointer | Length | unused | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Internet Header + leading octets of original datagram | 336 | | 337 | // | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3: ICMPv4 Parameter Problem 343 The syntax and semantics of all fields are unchanged from RFC 792, 344 except for a length attribute which is added to the second word. The 345 length attribute represents length of the padded "original datagram" 346 field, measured in 32-bit words. 348 4.4. ICMPv6 Destination Unreachable 350 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Code | Checksum | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Unused | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | As much of invoking packet | 360 + as will fit without the ICMPv6 packet + 361 | exceeding the minimum IPv6 MTU [IPv6] | 363 Figure 4: ICMPv6 Destination Unreachable 365 The syntax and semantics of all fields are unchanged from RFC 4443. 366 However, a length attribute is added to the second word. The length 367 attribute represents length of the padded "original datagram" field, 368 measured in 32-bit words. 370 4.5. ICMPv6 Time Exceeded 372 Figure 5 depicts the ICMPv6 Time Exceeded Message. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Code | Checksum | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Unused | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | As much of invoking packet | 382 + as will fit without the ICMPv6 packet + 383 | exceeding the minimum IPv6 MTU [IPv6] | 385 Figure 5: ICMPv6 Time Exceeded 387 The syntax and semantics of all fields are unchanged from RFC 4443, 388 except for a length attribute which is added to the second word. The 389 length attribute represents length of the padded "original datagram" 390 field, measured in 32-bit words. 392 4.6. ICMP Messages That Can Be Extended 394 The ICMP Extension Structure MAY be appended to messages of the 395 following types: 397 - ICMPv4 Destination Unreachable 399 - ICMPv4 Time Exceeded 401 - ICMPv4 Parameter Problem 403 - ICMPv6 Destination Unreachable 405 - ICMPv6 Time Exceeded 407 The ICMP Extension Structure MUST NOT be appended to any of the other 408 ICMP messages mentioned in Section 4. 410 ICMP messages defined in the future SHOULD indicate whether or not 411 they support the extension mechanism defined in this specification. 412 It is recommended that all new messages support extensions. 414 5. Backwards Compatibility 416 ICMP messages can be categorized as follows: 418 - Messages that do not include any ICMP extensions 420 - Messages that include non-compliant ICMP extensions 422 - Messages that includes compliant ICMP extensions 424 Any ICMP implementation can send a message that does not include 425 extensions. ICMP implementations produced prior to 1999 are not 426 known to send ICMP extensions. 428 Some ICMP implementations, produced between 1999 and the present, may 429 send a non-compliant version of ICMP extensions described in this 430 memo. Specifically, these implementations may append the ICMP 431 Extension Structure to the Time Exceeded and Destination Unreachable 432 messages. When they do this, they send exactly 128 octets 433 representing the original datagram, zero padding if required. They 434 also calculate checksums as described in this document. However, 435 they do not specify a length attribute to be associated with the 436 "original datagram" field. 438 It is assumed that ICMP implementations produced in the future will 439 send ICMP extensions that are compliant with this specification. 441 Likewise, applications that consume ICMP messages can be categorized 442 as follows: 444 - Classic applications 446 - Non-compliant applications 448 - Compliant applications 450 Classic applications do not parse extensions defined in this memo. 451 They are insensitive to the length attribute that is associated with 452 the "original datagram" field. 454 Non-compliant implementations parse the extensions defined in this 455 memo, but only in conjunction with the Time Expired and Destination 456 Unreachable messages. They require the "original datagram" field to 457 contain exactly 128 octets and are insensitive to the length 458 attribute that is associated with the "original datagram" field. 459 Non-compliant applications were produced between 1999 and the 460 present. 462 Compliant applications comply fully with the specifications of this 463 document. 465 In order to demonstrate backwards compatibility, Table 1 describes 466 how members of each application category would parse each category of 467 ICMP message. 469 +----------------+----------------+----------------+----------------+ 470 | | No Extensions | Non-compliant | Compliant | 471 | | | Extensions | Extensions | 472 +----------------+----------------+----------------+----------------+ 473 | Classic | - | Section 5.1 | Section 5.1 | 474 | Application | | | | 475 | | | | | 476 | Non-compliant | Section 5.2 | - | Section 5.3 | 477 | Application | | | | 478 | | | | | 479 | Compliant | Section 5.4 | Section 5.5 | - | 480 | Application | | | | 481 +----------------+----------------+----------------+----------------+ 483 Table 1 485 In the table above, cells that contain a dash represent the nominal 486 case and require no explanation. In the following sections, we 487 assume that the ICMP message type is "Time Exceeded". 489 5.1. Classic Application Receives ICMP Message With Extensions 491 When a classic application receives an ICMP message that includes 492 extensions, it will incorrectly interpret those extensions as being 493 part of the "original datagram" field. Fortunately, the extensions 494 are guaranteed to begin at least 128 octets beyond the beginning of 495 the "original datagram" field. So, only those ICMP applications that 496 process the 129th octet of the "original datagram" field will be 497 adversely effected. To date, no such applications have been 498 identified. 500 5.2. Non-compliant Application Receives ICMP Message With No Extensions 502 When a non-compliant ICMPv4 application receives a message that 503 contains no extensions, the application examines the total length of 504 the ICMPv4 message. If the total ICMPv4 message length is less than 505 the length of its IP header plus 144 octets, the application 506 correctly determines that the message does not contain any 507 extensions. 509 The 144 octet sum is derived from 8 octets for the first two words of 510 the ICMPv4 Time Exceeded message, 128 octets for the "original 511 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 512 for a single ICMP Object header. All of these octets would be 513 required if extensions were present. 515 If the ICMPv4 payload contains 144 octets or more, the application 516 must examine the 137th octet to determine whether it represents a 517 valid ICMPv4 Extension Header. In order to represent a valid 518 Extension Header, it must contain a valid version number and 519 checksum. If it does not contain a valid version number and 520 checksum, the application correctly determines that the message does 521 not contain any extensions. 523 Non-compliant applications assume that the ICMPv4 Extension Structure 524 begins on the 137th octet of the Time Exceeded message, after a 128 525 octet field representing the padded "original datagram" message. 527 It is possible that a non-compliant application will parse an ICMPv4 528 message incorrectly under the following conditions: 530 - the message does not contain extensions 532 - the original datagram field contains 144 octets or more 534 - selected octets of the original datagram field represent the 535 correct values for an extension header version number and checksum 537 Although this is possible, it is very unlikely. 539 A similar analysis can be performed for ICMPv6. However, the numeric 540 constants would change as appropriate. 542 5.3. Non-compliant Application Receives ICMP Message With Compliant 543 Extensions 545 When a non-compliant application receives a message that contains 546 compliant ICMP extensions, it will parse those extensions correctly 547 only if the "original datagram" field contains exactly 128 octets. 548 This is because non-compliant applications are insensitive to the 549 length attribute that is associated with the "original datagram" 550 field. (They assume its value to be 128.) 552 Provided that the entire ICMP messages does not exceed the minimum 553 reassembly buffer size (576 octets for ICMPv4 or 1280 octets for 554 ICMPv6), there is no upper limit upon the length of the "original 555 datagram" field. However, each vendor will decide how many octets to 556 include. Those wishing to be backward compatible with non-compliant 557 TRACEROUTE implementations will include exactly 128 octets. Those 558 not requiring compatibility with non-compliant TRACEROUTE 559 applications may include more octets. 561 5.4. Compliant Application Receives ICMP Message with No Extensions 563 When a compliant application receives an ICMP message, it examines 564 the length attribute that is associated with the "original datagram" 565 field. If the length attribute is zero, the compliant application 566 MUST determine that the message contains no extensions. 568 5.5. Compliant Application Receives ICMP Message with Non-compliant 569 Extensions 571 When a compliant application receives an ICMP message, it examines 572 the length attribute that is associated with the "original datagram" 573 field. If the length attribute is zero, the compliant application 574 MUST determine that the message contains no extensions. In this 575 case, that determination is technically correct, but not backwards 576 compatible with the non-compliant implementation that originated the 577 ICMP message. 579 So, to ease transition yet encourage compliant implementation, 580 compliant TRACEROUTE implementations MAY include a non-default 581 operation mode to also interpret non-compliant responses. 582 Specifically, when a TRACEROUTE application operating in non- 583 compliant mode receives a sufficiently long ICMP message that does 584 not specify a length attribute, it will parse for a valid extension 585 header at a fixed location, assuming a 128 octet "original datagram" 586 field. If the application detects a valid version and checksum, it 587 will treat the following octets as an extension structure. 589 6. The ICMP Extension Structure 591 This memo proposes an optional ICMP Extension Structure that can be 592 appended to the ICMP messages referenced in Section 4.6 of this 593 document. 595 The Extension Structure contains exactly one Extension Header 596 followed by one or more objects. Having received an ICMP message 597 with extensions, application software MAY process selected objects 598 while ignoring others. The presence of an unrecognized object does 599 not imply that an ICMP message is malformed. 601 As stated above, the total length of the ICMP message, including 602 extensions, MUST NOT exceed the minimum reassembly buffer size. 603 Figure 6 depicts the ICMP Extension Header. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |Version| (Reserved) | Checksum | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 6: ICMP Extension Header 613 The fields of the ICMP Extension Header are as follows: 615 Version: 4 bits 617 ICMP extension version number. This is version 2. 619 Reserved: 12 bits 621 Must be set to 0. 623 Checksum: 16 bits 625 The one's complement of the one's complement sum of the data 626 structure, with the checksum field replaced by zero for the 627 purpose of computing the checksum. An all-zero value means that 628 no checksum was transmitted. See Section 5.2 for a description of 629 how this field is used. 631 7. ICMP Extension Objects 633 Each extension object contains one or more 32-bit words, representing 634 an object header and payload. All object headers share a common 635 format. Figure 7 depicts the Object Header and payload. 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Length | Class-Num | C-Type | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | | 643 | // (Object payload) // | 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Figure 7: Object Header and Payload 649 An object header has the following fields: 651 Length: 16 bits 653 Length of the object, measured in octets, including the object 654 header and object payload. 656 Class-Num: 8 bits 658 Identifies object class. 660 C-Type: 8 bits 662 Identifies object sub-type. 664 8. Security Considerations 666 Upon receipt of an ICMP message, application software must check it 667 for syntactic correctness. The extension checksum must be verified. 668 Improperly specified length attributes and other syntax problems may 669 result in buffer overruns. 671 This memo does not define the conditions under which a router sends 672 an ICMP message. Therefore, it does not expose routers to any new 673 denial of service attacks. Routers may need to limit the rate at 674 which ICMP messages are sent. 676 9. IANA Considerations 678 The ICMP Extension Object header contains two 8-bit fields: The 679 Class-Num identifies the object class, and the C-Type identifies the 680 class sub-type. Sub-type values are defined relative to a specific 681 object class value, and are defined per-class. 683 IANA should establish a registry of ICMP extension objects classes 684 and class sub-types. There are no values assigned within this 685 document to maintain. Object classes 0xF7 - 0xFF are reserved for 686 private use. Object class values are assignable on a first-come- 687 first-serve. The policy for assigning sub-type values should be 688 defined in the document defining new class values. 690 10. Acknowledgments 692 Thanks to Joe Touch and Fernando Gont for their comments regarding 693 this draft. 695 11. References 697 11.1. Normative References 699 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 700 Levels", BCP 14, RFC 2119, March 1997. 702 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 703 September 1981. 705 [3] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 706 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 707 Specification", RFC 4443, March 2006. 709 [4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 710 November 1990. 712 [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 713 June 1995. 715 11.2. Informative References 717 [6] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 718 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 720 [7] Bonica, R., "ICMP Extensions for MultiProtocol Label Switching", 721 draft-ietf-mpls-icmp-05 (work in progress), March 2006. 723 Authors' Addresses 725 Ronald P. Bonica 726 Juniper Networks 727 2251 Corporate Park Drive 728 Herndon, VA 20171 729 US 731 Email: rbonica@juniper.net 733 Der-Hwa Gan 734 Juniper Networks 735 1194 N. Mathilda Ave. 736 Sunnyvale, CA 94089 737 US 739 Email: dhg@juniper.net 740 Pekka Nikander 741 Ericsson Research Nomadic Lab 742 JORVAS FIN-02420 743 Finland 745 Email: pekka.nikander@nomadiclab.com 747 Daniel C. Tappan 748 Cisco Systems, Inc. 749 250 Apollo Drive 750 Chelmsford, MA 01824 751 US 753 Email: tappan@cisco.com 755 Carlos Pignataro 756 Cisco Systems, Inc. 757 7025 Kit Creek Road 758 Research Triangle Park, N.C. 27709 759 US 761 Email: cpignata@cisco.com 763 Full Copyright Statement 765 Copyright (C) The Internet Society (2006). 767 This document is subject to the rights, licenses and restrictions 768 contained in BCP 78, and except as set forth therein, the authors 769 retain all their rights. 771 This document and the information contained herein are provided on an 772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 774 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 775 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 776 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Intellectual Property 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org. 803 Acknowledgment 805 Funding for the RFC Editor function is provided by the IETF 806 Administrative Support Activity (IASA).