idnits 2.17.1 draft-bonica-internet-icmp-05.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 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** 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 (June 8, 2006) is 6503 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: December 10, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 June 8, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-05 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 December 10, 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 . . . . . . . . . . . . . . . . . . . . 15 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 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 The ICMP Extension Structure MAY be appended to any ICMP message 385 listed in Section 4 with the following exceptions. 387 Due to a lack of reserved octets from which to allocate space, a 388 length attribute could not be added to the following ICMP messages: 390 - Redirect 392 - Echo Request 394 - Echo Reply 396 - Domain Name Reply 398 Therefore, the ICMP Extension Structure cannot be used in conjunction 399 with the those ICMP messages. 401 Furthermore, the ICMP Extension Structure cannot be used in 402 conjunction with the Experimental Mobility message, because that 403 message already contains an extensible "options" field. 405 ICMP messages defined in the future SHOULD either support the ICMP 406 Extension Structure or state explicitly that they do not. 408 5. Backwards Compatibility 410 ICMP messages can be categorized as follows: 412 - Messages that do not include any ICMP extensions 414 - Messages that include non-compliant ICMP extensions 416 - Messages that includes compliant ICMP extensions 418 Any ICMP implementation can send a message that does not include 419 extensions. ICMP implementations produced prior to 1999 are not 420 known to send ICMP extensions. 422 Some ICMP implementations, produced between 1999 and the present, may 423 send a non-compliant version of ICMP extensions described in this 424 memo. Specifically, these implementations may append the ICMP 425 Extension Structure to the Time Exceeded and Destination Unreachable 426 messages. When they do this, they send exactly 128 octets 427 representing the original datagram, zero padding if required. They 428 also calculate checksums as described in this document. However, 429 they do not specify a length attribute to be associated with the 430 "original datagram" field. 432 It is assumed that ICMP implementations produced in the future will 433 send ICMP extensions that are compliant with this specification. 435 Likewise, applications that consume ICMP messages can be categorized 436 as follows: 438 - Classic applications 440 - Non-compliant applications 442 - Compliant applications 444 Classic applications do not parse extensions defined in this memo. 445 They are insensitive to the length attribute that is associated with 446 the "original datagram" field. 448 Non-compliant implementations parse the extensions defined in this 449 memo, but only in conjunction with the Time Expired and Destination 450 Unreachable messages. They require the "original datagram" field to 451 contain exactly 128 octets and are insensitive to the length 452 attribute that is associated with the "original datagram" field. 453 Non-compliant applications were produced between 1999 and the 454 present. 456 Compliant applications comply fully with the specifications of this 457 document. 459 In order to demonstrate backwards compatibility, Table 1 describes 460 how members of each application category would parse each category of 461 ICMP message. 463 +----------------+----------------+----------------+----------------+ 464 | | No Extensions | Non-compliant | Compliant | 465 | | | Extensions | Extensions | 466 +----------------+----------------+----------------+----------------+ 467 | Classic | - | Section 5.1 | Section 5.1 | 468 | Application | | | | 469 | | | | | 470 | Non-compliant | Section 5.2 | - | Section 5.3 | 471 | Application | | | | 472 | | | | | 473 | Compliant | Section 5.4 | Section 5.5 | - | 474 | Application | | | | 475 +----------------+----------------+----------------+----------------+ 477 Table 1 479 In the table above, cells that contain a dash represent the nominal 480 case and require no explanation. In the following sections, we 481 assume that the ICMP message type is "Time Exceeded". 483 5.1. Classic Application Receives ICMP Message With Extensions 485 When a classic application receives an ICMP message that includes 486 extensions, it will incorrectly interpret those extensions as being 487 part of the "original datagram" field. Fortunately, the extensions 488 are guaranteed to begin at least 128 octets beyond the beginning of 489 the "original datagram" field. So, only those ICMP applications that 490 process the 129th octet of the "original datagram" field will be 491 adversely effected. To date, no such applications have been 492 identified. 494 5.2. Non-compliant Application Receives ICMP Message With No Extensions 496 When a non-compliant application receives a message that contains no 497 extensions, the application examines the total length of the ICMP 498 message. If the total ICMP message length is less than the length of 499 its IP header plus 144 octets, the application correctly determines 500 that the message does not contain any extensions. 502 The 144 octet sum is derived from 8 octets for the first two words of 503 the ICMP Time Exceeded message, 128 octets for the "original 504 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 505 for a single ICMP Object header. All of these octets would be 506 required if extensions were present. 508 If the ICMP payload contains 144 octets or more, the application must 509 examine the 137th octet to determine whether it represents a valid 510 ICMP Extension Header. In order to represent a valid Extension 511 Header, it must contain a valid version number and checksum. If it 512 does not contain a valid version number and checksum, the application 513 correctly determines that the message does not contain any 514 extensions. 516 Non-compliant applications assume that the ICMP Extension Structure 517 begins on the 137th octet of the Time Exceeded message, after a 128 518 octet field representing the padded "original datagram" message. 520 It is possible that a non-compliant application will parse an ICMP 521 message incorrectly under the following conditions: 523 - the message does not contain extensions 525 - the original datagram field contains 144 octets or more 527 - selected octets of the original datagram field represent the 528 correct values for an extension header version number and checksum 530 Although this is possible, it is very unlikely. 532 5.3. Non-compliant Application Receives ICMP Message With Compliant 533 Extensions 535 When a non-compliant application receives a message that contains 536 compliant ICMP extensions, it will parse those extensions correctly 537 only if the "original datagram" field contains exactly 128 octets. 538 This is because non-compliant applications are insensitive to the 539 length attribute that is associated with the "original datagram" 540 field. (They assume its value to be 128.) 542 Provided that the entire ICMP messages does not exceed 576 octets, 543 there is no upper limit upon the length of the "original datagram" 544 field. However, each vendor will decide how many octets to include. 545 Those wishing to be backward compatible with non-compliant TRACEROUTE 546 implementations will include exactly 128 octets. Those not requiring 547 compatibility with non-compliant TRACEROUTE applications may include 548 more octets. 550 5.4. Compliant Application Receives ICMP Message with No Extensions 552 When a compliant application receives an ICMP message, it examines 553 the length attribute that is associated with the "original datagram" 554 field. If the length attribute is zero, the compliant application 555 MUST determine that the message contains no extensions. 557 5.5. Compliant Application Receives ICMP Message with Non-compliant 558 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. In this 564 case, that determination is technically correct, but not backwards 565 compatible with the non-compliant implementation that originated the 566 ICMP message. 568 So, to ease transition yet encourage compliant implementation, 569 compliant TRACEROUTE implementations MAY include a non-default 570 operation mode to also interpret non-compliant responses. 571 Specifically, when a TRACEROUTE application operating in non- 572 compliant mode receives an ICMP message that contains 144 octets or 573 more in its payload and does not specify a length attribute, it will 574 parse for a valid extension header beginning at octet 137. If the 575 application detects a valid version and checksum, it will treat the 576 following octets as an extension structure. 578 6. The ICMP Extension Structure 580 This memo proposes an optional ICMP Extension Structure that can be 581 appended to any ICMP message, except for those that are disqualified 582 in Section 4.5 of this document. 584 The Extension Structure contains exactly one Extension Header 585 followed by one or more objects. Having received an ICMP message 586 with extensions, application software MAY process selected objects 587 while ignoring others. The presence of an unrecognized object does 588 not imply that an ICMP message is malformed. 590 As stated in RFC 792, the total length of the ICMP message, including 591 extensions, MUST NOT exceed 576 octets. Figure 5 depicts the ICMP 592 Extension Header. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |Version| (Reserved) | Checksum | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 5: ICMP Extension Header 602 The fields of the ICMP Extension Header are as follows: 604 Version: 4 bits 606 ICMP extension version number. This is version 2. 608 Reserved: 12 bits 610 Must be set to 0. 612 Checksum: 16 bits 613 The one's complement of the one's complement sum of the data 614 structure, with the checksum field replaced by zero for the 615 purpose of computing the checksum. An all-zero value means that 616 no checksum was transmitted. 618 7. ICMP Extension Objects 620 Each extension object contains one or more 32-bit words, representing 621 an object header and payload. All object headers share a common 622 format. Figure 6 depicts the Object Header and payload. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Length | Class-Num | C-Type | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | 630 | // (Object payload) // | 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 6: Object Header and Payload 636 An object header has the following fields: 638 Length: 16 bits 640 Length of the object, measured in octets, including the object 641 header and object payload. 643 Class-Num: 8 bits 645 Identifies object class. 647 C-Type: 8 bits 649 Identifies object sub-type. 651 8. Security Considerations 653 Upon receipt of an ICMP message, application software must check it 654 for syntactic correctness. The extension checksum must be verified. 655 Improperly specified length attributes and other syntax problems may 656 result in buffer overruns. 658 This memo does not define the conditions under which a router sends 659 an ICMP message. Therefore, it does not expose routers to any new 660 denial of service attacks. Routers may need to limit the rate at 661 which ICMP messages are sent. 663 9. IANA Considerations 665 The ICMP Extension Object header contains two 8-bit fields: The 666 Class-Num identifies the object class, and the C-Type identifies the 667 class sub-type. Sub-type values are defined relative to a specific 668 object class value, and are defined per-class. 670 IANA should establish a registry of ICMP extension objects classes 671 and class sub-types. There are no values assigned within this 672 document to maintain. Object classes 0xF7 - 0xFF are reserved for 673 private use. Object class values are assignable on a first-come- 674 first-serve. The policy for assigning sub-type values should be 675 defined in the document defining new class values. 677 10. Acknowledgments 679 Thanks to Joe Touch for his comments regarding this draft. 681 11. References 683 11.1. Normative References 685 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 686 Levels", BCP 14, RFC 2119, March 1997. 688 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 689 September 1981. 691 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 692 November 1990. 694 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 695 June 1995. 697 11.2. Informative References 699 [5] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 700 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 702 [6] Mogul, J. and J. Postel, "Internet Standard Subnetting 703 Procedure", STD 5, RFC 950, August 1985. 705 [7] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 706 September 1991. 708 [8] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 709 January 1993. 711 [9] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 713 [10] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 714 RFC 2521, March 1999. 716 [11] Kempf, J., "Instructions for Seamoby and Experimental Mobility 717 Protocol IANA Allocations", RFC 4065, July 2005. 719 Authors' Addresses 721 Ronald P. Bonica 722 Juniper Networks 723 2251 Corporate Park Drive 724 Herndon, VA 20171 725 US 727 Email: rbonica@juniper.net 729 Der-Hwa Gan 730 Juniper Networks 731 1194 N. Mathilda Ave. 732 Sunnyvale, CA 94089 733 US 735 Email: dhg@juniper.net 737 Pekka Nikander 738 Ericsson Research Nomadic Lab 739 JORVAS FIN-02420 740 Finland 742 Email: pekka.nikander@nomadiclab.com 744 Daniel C. Tappan 745 Cisco Systems, Inc. 746 250 Apollo Drive 747 Chelmsford, MA 01824 748 US 750 Email: tappan@cisco.com 752 Carlos Pignataro 753 Cisco Systems, Inc. 754 7025 Kit Creek Road 755 Research Triangle Park, N.C. 27709 756 US 758 Email: cpignata@cisco.com 760 Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Disclaimer of Validity 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Copyright Statement 796 Copyright (C) The Internet Society (2006). This document is subject 797 to the rights, licenses and restrictions contained in BCP 78, and 798 except as set forth therein, the authors retain all their rights. 800 Acknowledgment 802 Funding for the RFC Editor function is currently provided by the 803 Internet Society.