idnits 2.17.1 draft-bonica-internet-icmp-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 690. ** 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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2005) is 6798 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. '6') (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '7') (Obsoleted by RFC 6918) Summary: 4 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: March 20, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 Cisco Systems, Inc. 9 September 16, 2005 11 Extending the Internet Control Message Protocol (ICMP) 12 draft-bonica-internet-icmp-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 20, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document defines a syntax that can be used to extend ICMPv4. 46 The syntax is characterized by an extension structure that is 47 appended to currently defined ICMP messages. The extension structure 48 contains an extension header followed by one or more objects. Each 49 object contains an object header and a payload. All object headers 50 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 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 64 6.1. Classic Application Receives ICMP Message With 65 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 66 6.2. Partially Compliant Application Receives ICMP Message 67 With No Extensions . . . . . . . . . . . . . . . . . . . . 12 68 6.3. Partially Compliant Application Receives ICMP Message 69 With Fully Compliant Extensions . . . . . . . . . . . . . 12 70 6.4. Fully Compliant Application Receives ICMP Message With 71 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 72 6.5. Fully Compliant Application Receives ICMP Message With 73 Partially Compliant Extensions . . . . . . . . . . . . . . 13 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 16 82 1. Conventions Used In This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC2119 [1]. 88 2. Introduction 90 This document defines a syntax that can be used to extend ICMPv4 [2]. 91 In this document, the term ICMP refers exclusively to ICMPv4. Unless 92 explicitly noted, ICMPv6 is NOT discussed in this memo. 94 The syntax defined in this document MUST NOT be used to extend 95 ICMPv6. This syntax was designed to be backwards compatible with 96 currently deployed, MPLS-aware ICMPv4 implementations. Consequently, 97 the syntax is not as clean as would be desirable. For ICMPv6, where 98 there are no similarly deployed implementations, a better format 99 should be created. However, other than this note, ICMPv6 is beyond 100 the scope if this memo. 102 The syntax defined herein is characterized by an extension structure 103 that is appended to currently defined ICMP messages. The extension 104 structure contains an extension header followed by one or more 105 objects. Each object contains an object header and a payload. All 106 object headers share a common format. 108 This document also addresses a fundamental problem in ICMP 109 extensibility. Many ICMP messages, as currently defined, end with a 110 variable-length field that lacks a length attribute. Application 111 software infers the length of this final field from the total length 112 of the ICMP message. If an extension structure were appended to 113 these messages, without adding a length attribute for the variable- 114 length field, application software would not be able to parse the 115 ICMP message. Specifically, application software would not be able 116 to determine where the variable-length field ends and where the 117 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 will 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 by Section 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 unknown object does not 141 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 221 - Source Quench 223 - Redirect 225 - Echo Request/Reply 227 - Timestamp/Timestamp Reply 229 - Information Request/Information Reply 231 Subsequent RFCs define the following messages: 233 - Address Mask Request/Reply [4] 235 - Router Solicitation/Advertisement [5] 237 - Traceroute [6] 239 - Domain Name Request/Reply [7] 241 - Security Failure [8] 243 Most ICMP messages are extensible as currently defined. Protocol 244 designers can extend ICMP messages by simply appending fields or data 245 structures to them. 247 The following ICMP messages are not extensible as currently defined: 249 - Destination Unreachable 251 - Source Quench 253 - Time Exceeded 255 - Parameter Problem 257 - Redirect 259 - Echo Request 260 - Echo Reply 262 - Domain Name Reply 264 These ICMP messages contain a field which represents a portion of the 265 original datagram to which the ICMP messages is a response. As 266 originally defined, this field includes the IP header plus leading 267 eight payload octets of the original datagram. RFC 1812 [3] extends 268 this field to contain as many payload octets as possible, without 269 exceeding a limit of 576 octets for the entire ICMP message. 271 Unfortunately, the above mentioned field lacks a length attribute. 272 Application software infers the length of this field from the total 273 length of the ICMP message. If an extension structure were appended 274 to the ICMP message, without adding a length attribute for the 275 variable-length field, application software would not be able to 276 parse the ICMP message. Specifically, application software would not 277 be able to determine where the variable-length field ends and where 278 the extension structure begins. 280 In order to solve this problem, this memo introduces an 8-bit length 281 attribute to the following ICMP messages. 283 - Destination Unreachable 285 - Source Quench 287 - Time Exceeded 289 - Parameter Problem 291 The length attribute MUST be specified when the ICMP Extension 292 Structure is appended to the above mentioned ICMP messages. It 293 SHOULD be specified when the ICMP Extension Structure is not appended 294 to the above mentioned ICMP messages. 296 The length attribute represents the size of the associated variable- 297 length field, measured in octets. Space for this field is claimed 298 from reserved octets, whose value was previously required to be zero. 299 When this length attribute is specified, its value MUST be a multiple 300 of four. 302 In order the achieve backwards compatibility, when the ICMP Extension 303 Structure is appended to the Time Exceeded or Destination Unreachable 304 messages, the variable length field MUST contain at least 128 octets. 305 If the orignal datagram that the variable length field represents did 306 not contain 128 octets, the variable length field MUST be zero 307 padded. (See Section 6 for rationale.) 308 Due to a lack of reserved octets from which to allocate space, a 309 length attribute could not be added to the following ICMP messages: 311 - Redirect 313 - Echo Request 315 - Echo Reply 317 - Domain Name Reply 319 Therefore, the ICMP Extension Structure described in this memo cannot 320 be used in conjunction with the above mentioned ICMP messages. 322 The following sub-sections depict length attribute as it has been 323 introduced to selected ICMP messages. 325 5.1. Destination Unreachable 327 Figure 3 depicts the Destination Unreachable Message. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Code | Checksum | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | unused | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Internet Header + leading octets of original datagram | 337 | | 338 | // | 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 3: Destination Unreachable 344 The syntax and semantics of all fields are unchanged from RFC 792, 345 except for a length attribute which is added to the end of the second 346 word. 348 When the ICMP Extension Structure is appended to this message, the 349 "original datagram" field MUST contain at least 128 octets. 351 5.2. Source Quench 353 Figure 4 depicts the Source Quench Message. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Code | Checksum | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | unused | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Internet Header + leading octets of original datagram | 363 | | 364 | // | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 4: Source Quench 370 The syntax and semantics of all fields are unchanged from RFC 792, 371 except for a length attribute which is added to the end of the second 372 word. 374 5.3. Time Exceeded 376 Figure 5 depicts the Time Exceeded Message. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type | Code | Checksum | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | unused | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Internet Header + leading octets of original datagram | 386 | | 387 | // | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 5: Source Time Exceeded 393 The syntax and semantics of all fields are unchanged from RFC 792, 394 except for a length attribute which is added to the end of the second 395 word. 397 When the ICMP Extension Structure is appended to this message, the 398 "original datagram" field MUST contain at least 128 octets. 400 5.4. Parameter Problem 402 Figure 6 depicts the Parameter Problem Message. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Code | Checksum | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Pointer | unused | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Internet Header + leading octets of original datagram | 412 | | 413 | // | 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 6: Parameter Problem 419 The syntax and semantics of all fields are unchanged from RFC 792, 420 except for a length attribute which is added to the end of the second 421 word. 423 6. Backwards Compatibility 425 ICMP messages can be categorized as follows: 427 - Messages that do not include any ICMP extensions 429 - Messages that include partially compliant ICMP extensions 431 - Messages that includes fully compliant ICMP extensions 433 Any ICMP implementation can send a message that does not include 434 extensions. ICMP implementations produced prior to 1999 never send 435 ICMP extensions. 437 Some ICMP implementations, produced between 1999 and the present, may 438 send a partially compliant version of ICMP extensions described in 439 this memo. Specifically, these implementations may append the ICMP 440 Extension Structure to the Time Exceeded and Destination Unreachable 441 messages. When they do this, they send exactly 128 octets 442 representing the original datagram, zero padding if required. They 443 do not specify a length attribute to be associated with the "original 444 datagram" field. 446 It is assumed that ICMP implementations produced in the future will 447 send ICMP extensions that are fully compliant with this 448 specification. 450 Likewise, applications that consume ICMP messages can be categorized 451 as follows: 453 - Classic applications 455 - Partially compliant applications 457 - Fully compliant applications 459 Classic applications do not parse extensions defined in this memo. 460 Partially compliant implementations parse the extensions defined in 461 this memo, but only in conjuntion with the Time Expired and 462 Destination Unreachable messages. They require the "original 463 datagram" field to contain exactly 128 octets and are insensitive to 464 the length attribute that is associated with that field. Partially 465 compliant applications were produced between 1999 and the present. 467 Fully compliant applications comply fully with the specifications of 468 this document. 470 In order to demonstrate backwards compatibility, Table 1 describes 471 how members of each application catagory would parse each category of 472 ICMP message. 474 +-------------------+-------------+------------------+----------------+ 475 | | No | Partially | Fully | 476 | | Extentions | Compliant | Compliant | 477 | | | Extensions | Extensions | 478 +-------------------+-------------+------------------+----------------+ 479 | Classic | | Section 6.1 | Section 6.1 | 480 | Application | | | | 481 | . | | | | 482 | Partially | Section 6.2 | | Section 6.3 | 483 | Compliant | | | | 484 | Application | | | | 485 | . | | | | 486 | Fully Compliant | Section 6.4 | Section 6.5 | | 487 | Application | | | | 488 +-------------------+-------------+------------------+----------------+ 490 Table 1 492 In the table above, cells that are left blank represent the nominal 493 case and require no explanation. In the following sections, we 494 assume that the ICMP message type is "Time Expired". 496 6.1. Classic Application Receives ICMP Message With Extensions 498 When a classic application receives an ICMP message that includes 499 extensions, it will incorrectly interpret those extensions as being 500 part of the "original datagram" field. Fortunately, the extensions 501 are guaranteed to begin at least 128 octets beyond the begining of 502 the "original datagram" field. So, only those ICMP applications that 503 process the 129th octet of the "original datagram" field will be 504 adversely effected. To date, no such applications have been 505 identified. 507 6.2. Partially Compliant Application Receives ICMP Message With No 508 Extensions 510 When a partially compliant application receives a message that 511 contains no extensions, the application examines the total length of 512 the ICMP message. If the total ICMP message length is less than 164 513 octets, the application can correctly determine that the message does 514 not contain any extensions. 516 The 164 octet sum is derived from 20 octets for an IP header, 8 517 octets for the first two words of the ICMP Time Exceeded message, 128 518 octets for the "original datagram" field, 4 octets for the ICMP 519 Extension Header and 4 octets for a single ICMP Object header. All 520 of these octets would be required if extensions were present. 522 If the ICMP message contains 164 octets or more, the application must 523 examine the 157th octet to determine whether it represents a valid 524 ICMP Extension Header. In order to represent a valid Extension 525 Header, it must contain a valid version number and checksum. If it 526 does not contain a valid version number and checksum, the application 527 correctly determines that the message does not contain any 528 extensions. 530 Partially compliant applications assume that the ICMP Extension 531 Structure begins on the 157th octet of the Time Exceeded message, 532 after a 128 octet field representing the "original datagram" message. 534 6.3. Partially Compliant Application Receives ICMP Message With Fully 535 Compliant Extensions 537 When a partially compliant application receives a message that 538 contains fully compliant ICMP extensions, it will parse those 539 extensions correctly only if the "original datagram" field contains 540 exactly 128 octets. This is because partially compliant applications 541 are insensative to the length attribute that is associated with the 542 "original datagram" field. (They assume its value to be 128.) 544 Therefore, fully compliant ICMP implementations SHOULD restrict the 545 "original datagram" field to its minimum length, 128 octets, for the 546 forseeable future, until partially compliant applications have been 547 removed from service. 549 6.4. Fully Compliant Application Receives ICMP Message With No 550 Extensions 552 When a fully compliant application receives a message that contains 553 no extensions, it first examines the length attribute that is 554 associated with the "original datagram" field. If that length 555 attribute is not specified, the application examines the total length 556 of the ICMP message. If the total ICMP message length is less than 557 164 octets, the application can correctly determine that the message 558 does not contain any extensions. 560 The 164 octet sum is derived from 20 octets for an IP header, 8 561 octets for the first two words of the ICMP Time Exceeded message, 128 562 octets for the "original datagram" field, 4 octets for the ICMP 563 Extension Header and 4 octets for a single ICMP Object header. All 564 of these octets would be required if extensions were present. 566 If the ICMP message contains 164 octets or more, the application must 567 examine the 157th octet to determine whether it represents a valid 568 ICMP Extension Header. In order to represent a valid Extension 569 Header, it must contain a valid version number and checksum. If it 570 does not contain a valid version number and checksum, the application 571 correctly determines that the message does not contain any 572 extensions. 574 6.5. Fully Compliant Application Receives ICMP Message With Partially 575 Compliant Extensions 577 When a fully compliant application receives a message that contains 578 partially compliant extensions, it first examines the length 579 attribute that is associated with the "original datagram" field. 580 Because length attribute is not specified, it examines the total 581 length of the ICMP message. 583 Because the ICMP message contains 164 octets or more, the application 584 must examine the 157th octet to determine whether it represents a 585 valid ICMP Extension Header. In order to represent a valid Extension 586 Header, it must contain a valid version number and checksum. If it 587 does not contain a valid version number and checksum, the application 588 correctly determines that the message does not contain any 589 extensions. 591 7. Security Considerations 593 Upon receipt of an ICMP message, application software must check it 594 for syntactic correctness. Improperly specified length attributes 595 and other syntax problems may result in buffer overruns. 597 This memo does not define the conditions under which a router sends 598 an ICMP message. Therefore, it does not expose routers to any new 599 denial of service attacks. 601 8. IANA Considerations 603 IANA should establish a registry of ICMP extention classes and class- 604 sub-types. 606 9. References 608 9.1. Normative References 610 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 611 Levels", BCP 14, RFC 2119, March 1997. 613 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 614 September 1981. 616 [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 617 June 1995. 619 9.2. Informative References 621 [4] Mogul, J. and J. Postel, "Internet Standard Subnetting 622 Procedure", STD 5, RFC 950, August 1985. 624 [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 625 September 1991. 627 [6] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 628 January 1993. 630 [7] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 632 [8] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 633 RFC 2521, March 1999. 635 Authors' Addresses 637 Ronald P. Bonica 638 Juniper Networks 639 2251 Corporate Park Drive 640 Herndon, VA 20171 641 US 643 Email: rbonica@juniper.net 645 Der-Hwa Gan 646 Juniper Networks 647 1194 N. Mathilda Ave. 648 Sunnyvale, CA 94089 649 US 651 Email: dhg@juniper.net 653 Pekka Nikander 654 Ericsson Research Nomadic Lab 655 JORVAS FIN-02420 656 Finland 658 Email: pekka.nikander@nomadiclab.com 660 Daniel C. Tappan 661 Cisco Systems, Inc. 662 250 Apollo Drive 663 Chelmsford, MA 01824 664 US 666 Email: tappan@cisco.com 668 Intellectual Property Statement 670 The IETF takes no position regarding the validity or scope of any 671 Intellectual Property Rights or other rights that might be claimed to 672 pertain to the implementation or use of the technology described in 673 this document or the extent to which any license under such rights 674 might or might not be available; nor does it represent that it has 675 made any independent effort to identify any such rights. Information 676 on the procedures with respect to rights in RFC documents can be 677 found in BCP 78 and BCP 79. 679 Copies of IPR disclosures made to the IETF Secretariat and any 680 assurances of licenses to be made available, or the result of an 681 attempt made to obtain a general license or permission for the use of 682 such proprietary rights by implementers or users of this 683 specification can be obtained from the IETF on-line IPR repository at 684 http://www.ietf.org/ipr. 686 The IETF invites any interested party to bring to its attention any 687 copyrights, patents or patent applications, or other proprietary 688 rights that may cover technology that may be required to implement 689 this standard. Please address the information to the IETF at 690 ietf-ipr@ietf.org. 692 Disclaimer of Validity 694 This document and the information contained herein are provided on an 695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 697 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 698 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 699 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 702 Copyright Statement 704 Copyright (C) The Internet Society (2005). This document is subject 705 to the rights, licenses and restrictions contained in BCP 78, and 706 except as set forth therein, the authors retain all their rights. 708 Acknowledgment 710 Funding for the RFC Editor function is currently provided by the 711 Internet Society.