idnits 2.17.1 draft-bonica-internet-icmp-04.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 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 776. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (April 20, 2006) is 6578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '8') (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '9') (Obsoleted by RFC 6918) Summary: 3 errors (**), 0 flaws (~~), 3 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 Expires: October 22, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 April 20, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-04 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 October 22, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document redefines selected ICMPv4 messages to support multi- 47 part operation. A multi-part ICMP message carries all of the 48 information that ICMP messages carried previously, as well as 49 additional 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 and "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 ICMPv4 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. Destination Unreachable . . . . . . . . . . . . . . . . . 7 80 4.2. Source Quench . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. Time Exceeded . . . . . . . . . . . . . . . . . . . . . . 9 82 4.4. Parameter Problem . . . . . . . . . . . . . . . . . . . . 9 83 4.5. ICMP Messages That Cannot Be Extended . . . . . . . . . . 10 84 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 85 5.1. Classic Application Receives ICMP Message With 86 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.2. Non-compliant Application Receives ICMP Message With 88 No Extensions . . . . . . . . . . . . . . . . . . . . . . 12 89 5.3. Non-compliant Application Receives ICMP Message With 90 Compliant Extensions . . . . . . . . . . . . . . . . . . . 13 91 5.4. Compliant Application Receives ICMP Message with No 92 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 93 5.5. Compliant Application Receives ICMP Message with 94 Non-compliant Extensions . . . . . . . . . . . . . . . . . 13 95 6. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 14 96 7. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 14 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 104 Intellectual Property and Copyright Statements . . . . . . . . . . 19 106 1. Conventions Used In This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC2119 [1]. 112 2. Introduction 114 This document redefines selected ICMP [2] messages to include an 115 extension structure and a length attribute. In this document, the 116 term ICMP refers exclusively to ICMPv4. Unless explicitly noted, 117 ICMPv6 is NOT discussed in this memo. 119 The extension structure supports multi-part ICMP operation. Protocol 120 designers can make an ICMP message carry additional information by 121 encoding that information in an extension. 123 This document also addresses a fundamental problem in ICMP 124 extensibility. Many of the ICMP messages addressed by this memo 125 include an "original datagram" field. The "original datagram" field 126 contains the initial octets of the datagram to which the ICMP message 127 is a response. Although the "original datagram" field is of variable 128 length, the ICMP message does not include a field that specifies its 129 length. 131 Application software infers the length of the "original datagram" 132 field from the total length of the ICMP message. If an extension 133 structure were appended to the message without adding a length 134 attribute for the "original datagram" field, the message would become 135 unparsable. Specifically, application software would not be able to 136 determine where the "original datagram" field ends and where the 137 extension structure begins. Therefore, this document proposes a 138 length attribute as well as an extension structure that is appended 139 to the ICMP message. 141 The current memo also addresses backwards compatibility with existing 142 ICMP implementations that either do not implement the extensions 143 defined herein or implement them without adding the required length 144 attributes. In particular, this draft addresses backwards 145 compatibility with certain, widely deployed, MPLS-aware ICMP 146 implementations that send the extensions defined herein without 147 adding the required length attribute. 149 The current memo does not define any ICMP extension objects. It 150 defines only the extension header and a common header that all 151 extension objects share. Reference [5] provides a sample application 152 of the ICMP Extension Object. 154 3. Summary of Changes to ICMP 156 The following is a summary of changes to ICMP that are proposed by 157 this memo: 159 - An ICMP Extension Structure MAY be appended to any ICMP message 160 except for those excluded below. 162 - The ICMP Extension Structure MUST NOT be appended to the 163 Redirect, Echo Request, Echo Reply and Domain Name Reply messages. 165 - When ICMP Extensions are appended to a message that includes an 166 "original datagram" field, the ICMP message MUST specify a length 167 attribute for the "original datagram" field. 169 - When ICMP Extensions are appended to a message that includes an 170 "original datagram" field, the "original datagram" field MUST 171 include at least 128 octets. If the original datagram did not 172 contain 128 octets, the "original datagram" field MUST be zero 173 padded to 128 octets. 175 - When ICMP Extensions are appended to a message that includes an 176 "original datagram" field, the "original datagram" field MUST be 177 zero padded to the nearest 32-bit boundary. 179 4. ICMP Extensibility 181 RFC 792 defines the following ICMP message types: 183 - Destination Unreachable 185 - Time Exceeded 187 - Parameter Problem 189 - Source Quench 191 - Redirect 193 - Echo Request/Reply 195 - Timestamp/Timestamp Reply 197 - Information Request/Information Reply 199 RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination 200 Unreachable message. Subsequent RFCs define the following messages: 202 - Address Mask Request/Reply [6] 204 - Router Solicitation/Advertisement [7] 206 - Traceroute [8] 208 - Domain Name Request/Reply [9] 210 - Security Failure [10] 212 - Experimental Mobility [11] 214 Many ICMP messages are extensible as currently defined. Protocol 215 designers can extend ICMP messages by simply appending fields or data 216 structures to them. 218 The following ICMP messages are not extensible as currently defined: 220 - Destination Unreachable 222 - Source Quench 224 - Time Exceeded 226 - Parameter Problem 228 - Redirect 230 - Echo Request 232 - Echo Reply 234 - Domain Name Reply 236 These ICMP messages contain an "original datagram" field which 237 represents a portion of the original datagram to which the ICMP 238 messages is a response. As originally defined, this field includes 239 the IP header plus the next eight octets of the original datagram. 240 RFC 1812 [4] extends this field to contain as many octets as 241 possible, without exceeding a limit of 576 octets for the entire ICMP 242 message. 244 Unfortunately, the "original datagram" field lacks a length 245 attribute. Application software infers the length of this field from 246 the total length of the ICMP message. If an extension structure were 247 appended to the message without adding a length attribute for the 248 "original datagram" field, the message would become unparsable. 249 Specifically, application software would not be able to determine 250 where the "original datagram" field ends and where the extension 251 structure begins. 253 In order to solve this problem, this memo introduces an 8-bit length 254 attribute to the following ICMP messages. 256 - Destination Unreachable 258 - Source Quench 260 - Time Exceeded 262 - Parameter Problem 264 The length attribute MUST be specified when the ICMP Extension 265 Structure is appended to the above mentioned ICMP messages. 267 The length attribute represents the length of the "original datagram" 268 field, measured in 32-bit words. When the length attribute is 269 specified, the "original datagram" field MUST be zero padded to the 270 nearest 32-bit boundary. Space for the length attribute is claimed 271 from reserved octets, whose value was previously required to be zero. 272 Because the sixth octet of each of the impacted ICMP messages was 273 reserved for future use, this octet was selected as the location of 274 the length attribute. 276 In order the achieve backwards compatibility, when the ICMP Extension 277 Structure is appended to an ICMP message and that ICMP message 278 contains an "original datagram" field, the "original datagram" field 279 MUST contain at least 128 octets. If the original datagram did not 280 contain 128 octets, the "original datagram" field MUST be zero padded 281 to 128 octets. (See Section 5.1 for rationale.) 283 The following sub-sections depict length attribute as it has been 284 introduced to selected ICMP messages. 286 4.1. Destination Unreachable 288 Figure 1 depicts the Destination Unreachable Message. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Code | Checksum | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | unused | Length | Next-Hop MTU | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Internet Header + leading octets of original datagram | 298 | | 299 | // | 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 1: Destination Unreachable 305 The syntax and semantics of all fields are unchanged from RFC 792 and 306 RFC 1191. However, a length attribute is added to the second word. 307 The length attribute represents length of the padded "original 308 datagram" field, measured in 32-bit words. 310 4.2. Source Quench 312 Figure 2 depicts the Source Quench Message. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Code | Checksum | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | unused | Length | unused | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Internet Header + leading octets of original datagram | 322 | | 323 | // | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: Source Quench 329 The syntax and semantics of all fields are unchanged from RFC 792, 330 except for a length attribute which is added to the second word. The 331 length attribute represents length of the padded "original datagram" 332 field, measured in 32-bit words. 334 4.3. Time Exceeded 336 Figure 3 depicts the Time Exceeded Message. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Code | Checksum | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | unused | Length | unused | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Internet Header + leading octets of original datagram | 346 | | 347 | // | 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 3: Time Exceeded 353 The syntax and semantics of all fields are unchanged from RFC 792, 354 except for a length attribute which is added to the second word. The 355 length attribute represents length of the padded "original datagram" 356 field, measured in 32-bit words. 358 4.4. Parameter Problem 360 Figure 4 depicts the Parameter Problem Message. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Code | Checksum | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Pointer | Length | unused | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Internet Header + leading octets of original datagram | 370 | | 371 | // | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 4: Parameter Problem 377 The syntax and semantics of all fields are unchanged from RFC 792, 378 except for a length attribute which is added to the second word. The 379 length attribute represents length of the padded "original datagram" 380 field, measured in 32-bit words. 382 4.5. ICMP Messages That Cannot Be Extended 384 Due to a lack of reserved octets from which to allocate space, a 385 length attribute could not be added to the following ICMP messages: 387 - Redirect 389 - Echo Request 391 - Echo Reply 393 - Domain Name Reply 395 Therefore, the ICMP Extension Structure described in this memo cannot 396 be used in conjunction with the above mentioned ICMP messages. 398 5. Backwards Compatibility 400 ICMP messages can be categorized as follows: 402 - Messages that do not include any ICMP extensions 404 - Messages that include non-compliant ICMP extensions 406 - Messages that includes compliant ICMP extensions 408 Any ICMP implementation can send a message that does not include 409 extensions. ICMP implementations produced prior to 1999 are not 410 known to send ICMP extensions. 412 Some ICMP implementations, produced between 1999 and the present, may 413 send a non-compliant version of ICMP extensions described in this 414 memo. Specifically, these implementations may append the ICMP 415 Extension Structure to the Time Exceeded and Destination Unreachable 416 messages. When they do this, they send exactly 128 octets 417 representing the original datagram, zero padding if required. They 418 also calculate checksums as described in this document. However, 419 they do not specify a length attribute to be associated with the 420 "original datagram" field. 422 It is assumed that ICMP implementations produced in the future will 423 send ICMP extensions that are compliant with this specification. 425 Likewise, applications that consume ICMP messages can be categorized 426 as follows: 428 - Classic applications 430 - Non-compliant applications 432 - Compliant applications 434 Classic applications do not parse extensions defined in this memo. 435 They are insensitive to the length attribute that is associated with 436 the "original datagram" field. 438 Non-compliant implementations parse the extensions defined in this 439 memo, but only in conjunction with the Time Expired and Destination 440 Unreachable messages. They require the "original datagram" field to 441 contain exactly 128 octets and are insensitive to the length 442 attribute that is associated with the "original datagram" field. 443 Non-compliant applications were produced between 1999 and the 444 present. 446 Compliant applications comply fully with the specifications of this 447 document. 449 In order to demonstrate backwards compatibility, Table 1 describes 450 how members of each application category would parse each category of 451 ICMP message. 453 +----------------+----------------+----------------+----------------+ 454 | | No Extensions | Non-compliant | Compliant | 455 | | | Extensions | Extensions | 456 +----------------+----------------+----------------+----------------+ 457 | Classic | - | Section 5.1 | Section 5.1 | 458 | Application | | | | 459 | | | | | 460 | Non-compliant | Section 5.2 | - | Section 5.3 | 461 | Application | | | | 462 | | | | | 463 | Compliant | Section 5.4 | Section 5.5 | - | 464 | Application | | | | 465 +----------------+----------------+----------------+----------------+ 467 Table 1 469 In the table above, cells that contain a dash represent the nominal 470 case and require no explanation. In the following sections, we 471 assume that the ICMP message type is "Time Exceeded". 473 5.1. Classic Application Receives ICMP Message With Extensions 475 When a classic application receives an ICMP message that includes 476 extensions, it will incorrectly interpret those extensions as being 477 part of the "original datagram" field. Fortunately, the extensions 478 are guaranteed to begin at least 128 octets beyond the beginning of 479 the "original datagram" field. So, only those ICMP applications that 480 process the 129th octet of the "original datagram" field will be 481 adversely effected. To date, no such applications have been 482 identified. 484 5.2. Non-compliant Application Receives ICMP Message With No Extensions 486 When a non-compliant application receives a message that contains no 487 extensions, the application examines the total length of the ICMP 488 message. If the total ICMP message length is less than the length of 489 its IP header plus 144 octets, the application correctly determines 490 that the message does not contain any extensions. 492 The 144 octet sum is derived from 8 octets for the first two words of 493 the ICMP Time Exceeded message, 128 octets for the "original 494 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 495 for a single ICMP Object header. All of these octets would be 496 required if extensions were present. 498 If the ICMP payload contains 144 octets or more, the application must 499 examine the 137th octet to determine whether it represents a valid 500 ICMP Extension Header. In order to represent a valid Extension 501 Header, it must contain a valid version number and checksum. If it 502 does not contain a valid version number and checksum, the application 503 correctly determines that the message does not contain any 504 extensions. 506 Non-compliant applications assume that the ICMP Extension Structure 507 begins on the 137th octet of the Time Exceeded message, after a 128 508 octet field representing the padded "original datagram" message. 510 It is possible that a non-compliant application will parse an ICMP 511 message incorrectly under the following conditions: 513 - the message does not contain extensions 515 - the original datagram field contains 144 octets or more 517 - selected octets of the original datagram field represent the 518 correct values for an extension header version number and checksum 520 Although this is possible, it is very unlikely. 522 5.3. Non-compliant Application Receives ICMP Message With Compliant 523 Extensions 525 When a non-compliant application receives a message that contains 526 compliant ICMP extensions, it will parse those extensions correctly 527 only if the "original datagram" field contains exactly 128 octets. 528 This is because non-compliant applications are insensitive to the 529 length attribute that is associated with the "original datagram" 530 field. (They assume its value to be 128.) 532 Provided that the entire ICMP messages does not exceed 576 octets, 533 there is no upper limit upon the length of the "original datagram" 534 field. However, each vendor will decide how many octets to include. 535 Those wishing to be backward compatible with non-compliant TRACEROUTE 536 implementations will include exactly 128 octets. Those not requiring 537 compatibility with non-compliant TRACEROUTE applications may include 538 more octets. 540 5.4. Compliant Application Receives ICMP Message with No Extensions 542 When a compliant application receives an ICMP message, it examines 543 the length attribute that is associated with the "original datagram" 544 field. If the length attribute is zero, the compliant application 545 MUST determine that the message contains no extensions. 547 5.5. Compliant Application Receives ICMP Message with Non-compliant 548 Extensions 550 When a compliant application receives an ICMP message, it examines 551 the length attribute that is associated with the "original datagram" 552 field. If the length attribute is zero, the compliant application 553 MUST determine that the message contains no extensions. In this 554 case, that determination will be incorrect because the non-compliant 555 ICMP message contains extensions but does not specify a length 556 attribute. 558 For this reason, vendors may choose to implement TRACEROUTE in a 559 manner that is not compliant. Specifically, when a non-compliant 560 TRACEROUTE application receives an ICMP message that contains 144 561 octets or more in its payload and does not specify a length 562 attribute, it will parse for a valid extension header beginning at 563 octet 137. If the application detects a valid version and checksum, 564 it will treat the following octets as an extension structure. 566 Vendors should not implement or distribute any non-compliant 567 implementations other than TRACEROUTE. As non-compliant ICMP 568 implementations are upgraded to compliant implementations, the need 569 for non-compliant TRACEROUTE applications should be eliminated. 571 6. The ICMP Extension Structure 573 This memo proposes an optional ICMP Extension Structure that can be 574 appended to any ICMP message, except for those that are disqualified 575 in Section 4.5 of this document. 577 The Extension Structure contains exactly one Extension Header 578 followed by one or more objects. Having received an ICMP message 579 with extensions, application software MAY process selected objects 580 while ignoring others. The presence of an unrecognized object does 581 not imply that an ICMP message is malformed. 583 As stated in RFC 792, the total length of the ICMP message, including 584 extensions, MUST NOT exceed 576 octets. Figure 5 depicts the ICMP 585 Extension Header. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |Version| (Reserved) | Checksum | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 5: ICMP Extension Header 595 The fields of the ICMP Extension Header are as follows: 597 Version: 4 bits 599 ICMP extension version number. This is version 2. 601 Reserved: 12 bits 603 Must be set to 0. 605 Checksum: 16 bits 607 The one's complement of the one's complement sum of the data 608 structure, with the checksum field replaced by zero for the 609 purpose of computing the checksum. An all-zero value means that 610 no checksum was transmitted. 612 7. ICMP Extension Objects 614 Each extension object contains one or more 32-bit words, representing 615 an object header and payload. All object headers share a common 616 format. Figure 6 depicts the Object Header and payload. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Length | Class-Num | C-Type | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 | // (Object payload) // | 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Figure 6: Object Header and Payload 630 An object header has the following fields: 632 Length: 16 bits 634 Length of the object, measured in octets, including the object 635 header and object payload. 637 Class-Num: 8 bits 639 Identifies object class. 641 C-Type: 8 bits 643 Identifies object sub-type. 645 8. Security Considerations 647 Upon receipt of an ICMP message, application software must check it 648 for syntactic correctness. The extension checksum must be verified. 649 Improperly specified length attributes and other syntax problems may 650 result in buffer overruns. 652 This memo does not define the conditions under which a router sends 653 an ICMP message. Therefore, it does not expose routers to any new 654 denial of service attacks. Routers may need to limit the rate at 655 which ICMP messages are sent. 657 9. IANA Considerations 659 The ICMP Extension Object header contains two 8-bit fields: The 660 Class-Num identifies the object class, and the C-Type identifies the 661 class sub-type. Sub-type values are defined relative to a specific 662 object class value, and are defined per-class. 664 IANA should establish a registry of ICMP extension objects classes 665 and class sub-types. There are no values assigned within this 666 document to maintain. Object classes 0xF7 - 0xFF are reserved for 667 private use. Object class values are assignable on a first-come- 668 first-serve. The policy for assigning sub-type values should be 669 defined in the document defining new class values. 671 10. Acknowledgments 673 Thanks to Joe Touch for his comments regarding this draft. 675 11. References 677 11.1. Normative References 679 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 680 Levels", BCP 14, RFC 2119, March 1997. 682 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 683 September 1981. 685 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 686 November 1990. 688 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 689 June 1995. 691 11.2. Informative References 693 [5] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 694 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 696 [6] Mogul, J. and J. Postel, "Internet Standard Subnetting 697 Procedure", STD 5, RFC 950, August 1985. 699 [7] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 700 September 1991. 702 [8] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 703 January 1993. 705 [9] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 707 [10] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 708 RFC 2521, March 1999. 710 [11] Kempf, J., "Instructions for Seamoby and Experimental Mobility 711 Protocol IANA Allocations", RFC 4065, July 2005. 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 731 Pekka Nikander 732 Ericsson Research Nomadic Lab 733 JORVAS FIN-02420 734 Finland 736 Email: pekka.nikander@nomadiclab.com 738 Daniel C. Tappan 739 Cisco Systems, Inc. 740 250 Apollo Drive 741 Chelmsford, MA 01824 742 US 744 Email: tappan@cisco.com 746 Carlos Pignataro 747 Cisco Systems, Inc. 748 7025 Kit Creek Road 749 Research Triangle Park, N.C. 27709 750 US 752 Email: cpignata@cisco.com 754 Intellectual Property Statement 756 The IETF takes no position regarding the validity or scope of any 757 Intellectual Property Rights or other rights that might be claimed to 758 pertain to the implementation or use of the technology described in 759 this document or the extent to which any license under such rights 760 might or might not be available; nor does it represent that it has 761 made any independent effort to identify any such rights. Information 762 on the procedures with respect to rights in RFC documents can be 763 found in BCP 78 and BCP 79. 765 Copies of IPR disclosures made to the IETF Secretariat and any 766 assurances of licenses to be made available, or the result of an 767 attempt made to obtain a general license or permission for the use of 768 such proprietary rights by implementers or users of this 769 specification can be obtained from the IETF on-line IPR repository at 770 http://www.ietf.org/ipr. 772 The IETF invites any interested party to bring to its attention any 773 copyrights, patents or patent applications, or other proprietary 774 rights that may cover technology that may be required to implement 775 this standard. Please address the information to the IETF at 776 ietf-ipr@ietf.org. 778 Disclaimer of Validity 780 This document and the information contained herein are provided on an 781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 783 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 784 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 785 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Copyright Statement 790 Copyright (C) The Internet Society (2006). This document is subject 791 to the rights, licenses and restrictions contained in BCP 78, and 792 except as set forth therein, the authors retain all their rights. 794 Acknowledgment 796 Funding for the RFC Editor function is currently provided by the 797 Internet Society.