idnits 2.17.1 draft-bonica-internet-icmp-01.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 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. ** 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 (January 26, 2006) is 6664 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) -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '7') (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '8') (Obsoleted by RFC 6918) Summary: 3 errors (**), 0 flaws (~~), 2 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: July 30, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 January 26, 2006 12 Extending the Internet Control Message Protocol (ICMP) 13 draft-bonica-internet-icmp-01 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 July 30, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document defines a syntax that can be used to extend ICMPv4. 47 The syntax is characterized by an extension structure that is 48 appended to selected ICMP messages. The extension structure contains 49 an header followed by one or more objects. Each object contains a 50 header and a payload. All object headers share a common format. 52 Table of Contents 54 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 4 57 4. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 5 58 5. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Destination Unreachable . . . . . . . . . . . . . . . . . 8 60 5.2. Source Quench . . . . . . . . . . . . . . . . . . . . . . 8 61 5.3. Time Exceeded . . . . . . . . . . . . . . . . . . . . . . 9 62 5.4. Parameter Problem . . . . . . . . . . . . . . . . . . . . 10 63 5.5. ICMP Messages That Cannot Be Extended . . . . . . . . . . 10 64 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 65 6.1. Classic Application Receives ICMP Message With 66 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.2. Partially Compliant Application Receives ICMP Message 68 With No Extensions . . . . . . . . . . . . . . . . . . . . 12 69 6.3. Partially Compliant Application Receives ICMP Message 70 With Fully Compliant Extensions . . . . . . . . . . . . . 13 71 6.4. Fully Compliant Application Receives ICMP Message With 72 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 73 6.5. Fully Compliant Application Receives ICMP Message With 74 Partially Compliant Extensions . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Intellectual Property and Copyright Statements . . . . . . . . . . 17 83 1. Conventions Used In This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC2119 [1]. 89 2. Introduction 91 This document defines a syntax that can be used to extend ICMPv4 [2]. 92 In this document, the term ICMP refers exclusively to ICMPv4. Unless 93 explicitly noted, ICMPv6 is NOT discussed in this memo. 95 The syntax defined in this document MUST NOT be used to extend 96 ICMPv6. This syntax was designed to be backwards compatible with 97 currently deployed, MPLS-aware ICMPv4 implementations. Consequently, 98 the syntax is not as clean as would be desirable. For ICMPv6, where 99 there are no similarly deployed implementations, a better format 100 should be created. However, other than this note, ICMPv6 is beyond 101 the scope of this memo. 103 The syntax defined herein is characterized by an extension structure 104 that is appended to selected ICMP messages. The extension structure 105 contains an extension header followed by one or more objects. Each 106 object contains an object header and a payload. All object headers 107 share a common format. 109 This document addresses a fundamental problem in ICMP extensibility. 110 Many ICMP messages, as currently defined, end with a variable-length 111 field that lacks a length attribute. Application software infers the 112 length of this final field from the total length of the ICMP message. 113 If an extension structure were appended to these messages, without 114 adding a length attribute for the variable-length field, application 115 software would not be able to parse the ICMP message. Specifically, 116 application software would not be able to determine where the 117 variable-length field ends and where the extension structure begins. 119 The current memo also addresses backwards compatibility with existing 120 ICMP implementations that either do not implement the extensions 121 defined herein or implement them without adding the required length 122 attributes. In particular, this draft addresses backwards 123 compatibility with certain, widely deployed, MPLS-aware ICMP 124 implementations that send the extensions defined herein without 125 adding the required length attribute. 127 However, the current memo does not define any ICMP extension objects. 128 It defines only the extension header and a common header that all 129 objects share. 131 3. The ICMP Extension Structure 133 This memo proposes an optional ICMP Extension Structure that can be 134 appended to any ICMP message, except for those that are disqualified 135 in Section 5.5 of this document. 137 The Extension Structure contains exactly one Extension Header 138 followed by one or more objects. Having received an ICMP message 139 with extensions, application software MAY process selected objects 140 while ignoring others. The presence of an unrecognized object does 141 not imply that an ICMP message is malformed. 143 As stated in RFC 792, the total length of the ICMP message, including 144 extensions, MUST NOT exceed 576 octets. Figure 1 depicts the ICMP 145 Extension Header. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |Version| (Reserved) | Checksum | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: ICMP Extension Header 155 The fields of the ICMP Extension Header are as follows: 157 Version: 4 bits 159 ICMP extension version number. This is version 2. 161 Reserved: 12 bits 163 Must be set to 0. 165 Checksum: 16 bits 167 The one's complement of the one's complement sum of the data 168 structure, with the checksum field replaced by zero for the 169 purpose of computing the checksum. An all-zero value means that 170 no checksum was transmitted. 172 If the checksum field contains a value other than described above, 173 the ICMP message does not include the extensions described in this 174 memo. However, due to backwards compatibility, this does not 175 imply that the ICMP message is malformed. See for Section 6 176 details. 178 4. ICMP Extension Objects 180 Each extension object contains one or more 32-bit words, representing 181 an object header and payload. All object headers share a common 182 format. Figure 2 depicts the Object Header and payload. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Length | Class-Num | C-Type | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 | // (Object payload) // | 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2: Object Header and Payload 196 An object header has the following fields: 198 Length: 16 bits 200 Length of the object, measured in octets, including the object 201 header and object payload. 203 Class-Num: 8 bits 205 Identifies object class. 207 C-Type: 8 bits 209 Identifies object sub-type. 211 5. ICMP Extensibility 213 RFC 792 defines the following ICMP message types: 215 - Destination Unreachable 217 - Time Exceeded 219 - Parameter Problem 220 - Source Quench 222 - Redirect 224 - Echo Request/Reply 226 - Timestamp/Timestamp Reply 228 - Information Request/Information Reply 230 RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination 231 Unreachable message. Subsequent RFCs define the following messages: 233 - Address Mask Request/Reply [5] 235 - Router Solicitation/Advertisement [6] 237 - Traceroute [7] 239 - Domain Name Request/Reply [8] 241 - Security Failure [9] 243 - Experimental Mobility [10] 245 Many ICMP messages are extensible as currently defined. Protocol 246 designers can extend ICMP messages by simply appending fields or data 247 structures to them. 249 The following ICMP messages are not extensible as currently defined: 251 - Destination Unreachable 253 - Source Quench 255 - Time Exceeded 257 - Parameter Problem 259 - Redirect 261 - Echo Request 263 - Echo Reply 264 - Domain Name Reply 266 These ICMP messages contain a field which represents a portion of the 267 original datagram to which the ICMP messages is a response. As 268 originally defined, this field includes the IP header plus the next 269 eight octets of the original datagram. RFC 1812 [4] extends this 270 field to contain as many octets as possible, without exceeding a 271 limit of 576 octets for the entire ICMP message. 273 Unfortunately, the above mentioned field lacks a length attribute. 274 Application software infers the length of this field from the total 275 length of the ICMP message. If an extension structure were appended 276 to the ICMP message, without adding a length attribute for the 277 variable-length field, application software would not be able to 278 parse the ICMP message. Specifically, application software would not 279 be able to determine where the variable-length field ends and where 280 the extension structure begins. 282 In order to solve this problem, this memo introduces an 8-bit length 283 attribute to the following ICMP messages. 285 - Destination Unreachable 287 - Source Quench 289 - Time Exceeded 291 - Parameter Problem 293 The length attribute MUST be specified when the ICMP Extension 294 Structure is appended to the above mentioned ICMP messages. It 295 SHOULD be specified when the ICMP Extension Structure is not appended 296 to the above mentioned ICMP messages. 298 The length attribute represents the size of the associated variable- 299 length field, measured in 32-bit words. When the length attribute is 300 specified, the associated variable-length field MUST be zero padded 301 to the nearest 32-bit boundary. Space for the length attribute is 302 claimed from reserved octets, whose value was previously required to 303 be zero. 305 In order the achieve backwards compatibility, when the ICMP Extension 306 Structure is appended to the Time Exceeded or Destination Unreachable 307 messages, the variable-length field MUST contain at least 128 octets. 308 If the orignal datagram that the variable-length field represents did 309 not contain 128 octets, the variable-length field MUST be zero padded 310 to 128 octets. (See Section 6 for rationale.) 311 The following sub-sections depict length attribute as it has been 312 introduced to selected ICMP messages. 314 5.1. Destination Unreachable 316 Figure 3 depicts the Destination Unreachable Message. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Code | Checksum | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | unused | Length | Next-Hop MTU | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Internet Header + leading octets of original datagram | 326 | | 327 | // | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 3: Destination Unreachable 333 The syntax and semantics of all fields are unchanged from RFC 792 and 334 RFC 1191. However, a length attribute is added to the second word. 335 The length attribute represents length of the padded "original 336 datagram" field, measured in 32-bit words. 338 When the ICMP Extension Structure is appended to this message, the 339 "original datagram" field MUST contain at least 128 octets (32 340 words). 342 5.2. Source Quench 344 Figure 4 depicts the Source Quench Message. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Code | Checksum | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | unused | Length | unused | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Internet Header + leading octets of original datagram | 354 | | 355 | // | 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 4: Source Quench 361 The syntax and semantics of all fields are unchanged from RFC 792, 362 except for a length attribute which is added to the second word. The 363 length attribute represents length of the padded "original datagram" 364 field, measured in 32-bit words. 366 5.3. Time Exceeded 368 Figure 5 depicts the Time Exceeded Message. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Code | Checksum | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | unused | Length | unused | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Internet Header + leading octets of original datagram | 378 | | 379 | // | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 5: Time Exceeded 385 The syntax and semantics of all fields are unchanged from RFC 792, 386 except for a length attribute which is added to the second word. The 387 length attribute represents length of the padded "original datagram" 388 field, measured in 32-bit words. 390 When the ICMP Extension Structure is appended to this message, the 391 "original datagram" field MUST contain at least 128 octets (32 392 words). 394 5.4. Parameter Problem 396 Figure 6 depicts the Parameter Problem Message. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Code | Checksum | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Pointer | Length | unused | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Internet Header + leading octets of original datagram | 406 | | 407 | // | 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 6: Parameter Problem 413 The syntax and semantics of all fields are unchanged from RFC 792, 414 except for a length attribute which is added to the second word. The 415 length attribute represents length of the padded "original datagram" 416 field, measured in 32-bit words. 418 5.5. ICMP Messages That Cannot Be Extended 420 Due to a lack of reserved octets from which to allocate space, a 421 length attribute could not be added to the following ICMP messages: 423 - Redirect 425 - Echo Request 427 - Echo Reply 429 - Domain Name Reply 431 Therefore, the ICMP Extension Structure described in this memo cannot 432 be used in conjunction with the above mentioned ICMP messages. 434 6. Backwards Compatibility 436 ICMP messages can be categorized as follows: 438 - Messages that do not include any ICMP extensions 440 - Messages that include partially compliant ICMP extensions 442 - Messages that includes fully compliant ICMP extensions 444 Any ICMP implementation can send a message that does not include 445 extensions. ICMP implementations produced prior to 1999 never send 446 ICMP extensions. 448 Some ICMP implementations, produced between 1999 and the present, may 449 send a partially compliant version of ICMP extensions described in 450 this memo. Specifically, these implementations may append the ICMP 451 Extension Structure to the Time Exceeded and Destination Unreachable 452 messages. When they do this, they send exactly 128 octets 453 representing the original datagram, zero padding if required. 454 However, they do not specify a length attribute to be associated with 455 the "original datagram" field. 457 It is assumed that ICMP implementations produced in the future will 458 send ICMP extensions that are fully compliant with this 459 specification. 461 Likewise, applications that consume ICMP messages can be categorized 462 as follows: 464 - Classic applications 466 - Partially compliant applications 468 - Fully compliant applications 470 Classic applications do not parse extensions defined in this memo. 471 Partially compliant implementations parse the extensions defined in 472 this memo, but only in conjuntion with the Time Expired and 473 Destination Unreachable messages. They require the "original 474 datagram" field to contain exactly 128 octets and are insensitive to 475 the length attribute that is associated with that field. Partially 476 compliant applications were produced between 1999 and the present. 478 Fully compliant applications comply fully with the specifications of 479 this document. 481 In order to demonstrate backwards compatibility, Table 1 describes 482 how members of each application catagory would parse each category of 483 ICMP message. 485 +----------------+----------------+----------------+----------------+ 486 | | No Extentions | Partially | Fully | 487 | | | Compliant | Compliant | 488 | | | Extentions | Extentions | 489 +----------------+----------------+----------------+----------------+ 490 | Classic | - | Section 6.1 | Section 6.1 | 491 | Application | | | | 492 | | | | | 493 | Partially | Section 6.2 | - | Section 6.3 | 494 | Compliant | | | | 495 | Application | | | | 496 | | | | | 497 | Fully | Section 6.4 | Section 6.5 | - | 498 | Compliant | | | | 499 | Application | | | | 500 +----------------+----------------+----------------+----------------+ 502 Table 1 504 In the table above, cells that are left blank represent the nominal 505 case and require no explanation. In the following sections, we 506 assume that the ICMP message type is "Time Exceeded". 508 6.1. Classic Application Receives ICMP Message With Extensions 510 When a classic application receives an ICMP message that includes 511 extensions, it will incorrectly interpret those extensions as being 512 part of the "original datagram" field. Fortunately, the extensions 513 are guaranteed to begin at least 128 octets beyond the begining of 514 the "original datagram" field. So, only those ICMP applications that 515 process the 129th octet of the "original datagram" field will be 516 adversely effected. To date, no such applications have been 517 identified. 519 6.2. Partially Compliant Application Receives ICMP Message With No 520 Extensions 522 When a partially compliant application receives a message that 523 contains no extensions, the application examines the total length of 524 the ICMP message. If the total ICMP message length is less than the 525 length of its IP header plus 144 octets, the application correctly 526 determines that the message does not contain any extensions. 528 The 144 octet sum is derived from 8 octets for the first two words of 529 the ICMP Time Exceeded message, 128 octets for the "original 530 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 531 for a single ICMP Object header. All of these octets would be 532 required if extensions were present. 534 If the ICMP payload contains 144 octets or more, the application must 535 examine the 137th octet to determine whether it represents a valid 536 ICMP Extension Header. In order to represent a valid Extension 537 Header, it must contain a valid version number and checksum. If it 538 does not contain a valid version number and checksum, the application 539 correctly determines that the message does not contain any 540 extensions. 542 Partially compliant applications assume that the ICMP Extension 543 Structure begins on the 137th octet of the Time Exceeded message, 544 after a 128 octet field representing the padded "original datagram" 545 message. 547 6.3. Partially Compliant Application Receives ICMP Message With Fully 548 Compliant Extensions 550 When a partially compliant application receives a message that 551 contains fully compliant ICMP extensions, it will parse those 552 extensions correctly only if the "original datagram" field contains 553 exactly 128 octets. This is because partially compliant applications 554 are insensitive to the length attribute that is associated with the 555 "original datagram" field. (They assume its value to be 128.) 557 Therefore, when fully compliant ICMP implementations append 558 extensions to the ICMP Destination Unreachable and Time Expired 559 Messages, they SHOULD restrict the "original datagram" field to its 560 minimum length, 128 octets. 562 6.4. Fully Compliant Application Receives ICMP Message With No 563 Extensions 565 When a fully compliant application receives a message that contains 566 no extensions, it first examines the length attribute that is 567 associated with the "original datagram" field. If that length 568 attribute is not specified, the application examines the total length 569 of the ICMP message. If the total ICMP message length is less than 570 the length of the IP header plus 144 octets, the application can 571 correctly determine that the message does not contain any extensions. 573 The 144 octet sum is derived from 8 octets for the first two words of 574 the ICMP Time Exceeded message, 128 octets for the "original 575 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 576 for a single ICMP Object header. All of these octets would be 577 required if extensions were present. 579 If the ICMP payload contains 144 octets or more, the application must 580 examine the 137th octet to determine whether it represents a valid 581 ICMP Extension Header. In order to represent a valid Extension 582 Header, it must contain a valid version number and checksum. If it 583 does not contain a valid version number and checksum, the application 584 correctly determines that the message does not contain any 585 extensions. 587 6.5. Fully Compliant Application Receives ICMP Message With Partially 588 Compliant Extensions 590 When a fully compliant application receives a message that contains 591 partially compliant extensions, it first examines the length 592 attribute that is associated with the "original datagram" field. 593 Because length attribute is not specified, it examines the total 594 length of the ICMP message. 596 Because the ICMP payload contains 144 octets or more, the application 597 must examine the 137th octet to determine whether it represents a 598 valid ICMP Extension Header. In order to represent a valid Extension 599 Header, it must contain a valid version number and checksum. If it 600 does not contain a valid version number and checksum, the application 601 correctly determines that the message does not contain any 602 extensions. 604 7. Security Considerations 606 Upon receipt of an ICMP message, application software must check it 607 for syntactic correctness. Improperly specified length attributes 608 and other syntax problems may result in buffer overruns. 610 This memo does not define the conditions under which a router sends 611 an ICMP message. Therefore, it does not expose routers to any new 612 denial of service attacks. 614 8. IANA Considerations 616 The ICMP Extension Object header contains two 8-bit fields: The 617 Class-Num identifies the object class, and the C-Type identifies the 618 class sub-type. Sub-type values are defined relative to a specific 619 object class value, and are defined per-class. 621 IANA should establish a registry of ICMP extention objects classes 622 and class sub-types. There are no values assigned within this 623 document to maintain. Object classes 0xF7 - 0xFF are reserved for 624 private use. Object class values are assignable on a first-come- 625 first-serve. The policy for assigning sub-type values should be 626 defined in the document defining new class values. 628 9. References 630 9.1. Normative References 632 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 633 Levels", BCP 14, RFC 2119, March 1997. 635 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 636 September 1981. 638 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 639 November 1990. 641 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 642 June 1995. 644 9.2. Informative References 646 [5] Mogul, J. and J. Postel, "Internet Standard Subnetting 647 Procedure", STD 5, RFC 950, August 1985. 649 [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 650 September 1991. 652 [7] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 653 January 1993. 655 [8] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 657 [9] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 658 RFC 2521, March 1999. 660 [10] Kempf, J., "Instructions for Seamoby and Experimental Mobility 661 Protocol IANA Allocations", RFC 4065, July 2005. 663 Authors' Addresses 665 Ronald P. Bonica 666 Juniper Networks 667 2251 Corporate Park Drive 668 Herndon, VA 20171 669 US 671 Email: rbonica@juniper.net 673 Der-Hwa Gan 674 Juniper Networks 675 1194 N. Mathilda Ave. 676 Sunnyvale, CA 94089 677 US 679 Email: dhg@juniper.net 681 Pekka Nikander 682 Ericsson Research Nomadic Lab 683 JORVAS FIN-02420 684 Finland 686 Email: pekka.nikander@nomadiclab.com 688 Daniel C. Tappan 689 Cisco Systems, Inc. 690 250 Apollo Drive 691 Chelmsford, MA 01824 692 US 694 Email: tappan@cisco.com 696 Carlos Pignataro 697 Cisco Systems, Inc. 698 7025 Kit Creek Road 699 Research Triangle Park, N.C. 27709 700 US 702 Email: cpignata@cisco.com 704 Intellectual Property Statement 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Disclaimer of Validity 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 733 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 734 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 735 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Copyright Statement 740 Copyright (C) The Internet Society (2006). This document is subject 741 to the rights, licenses and restrictions contained in BCP 78, and 742 except as set forth therein, the authors retain all their rights. 744 Acknowledgment 746 Funding for the RFC Editor function is currently provided by the 747 Internet Society.