idnits 2.17.1 draft-bonica-internet-icmp-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 766. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2006) is 6579 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '8') (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '9') (Obsoleted by RFC 6918) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet R. Bonica 3 Internet-Draft D. Gan 4 Expires: October 3, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 April 2006 12 Redefining Selected ICMP Messages To Include a Length Attribute and an 13 Extension Structure 14 draft-bonica-internet-icmp-03 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 3, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document redefines selected ICMPv4 messages to include an 48 extension structure. The extension structure is situated at the end 49 of the ICMP message. It includes an extension header followed by one 50 or more extension objects. Each extension object contains an object 51 header and object payload. All object headers share a common format. 53 This document further redefines a subset of the above mentioned ICMP 54 messages by specifying a length attribute. Many of the ICMP messages 55 to which an extension structure can be appended include and "original 56 datagram" field. The "original datagram" field contains the initial 57 octets of the datagram to which the ICMP message is a response. 58 Although the original datagram field is of variable length, the ICMP 59 message does not include a field that specifies its length. 60 Therefore, in order to facilitate message parsing, this draft 61 allocates eight previously reserved bits to reflect the length of the 62 "original datagram" field. 64 Finally, this document addresses backwards compatibility issues. 65 This document requires backwards compatibility with RFC 792 and RFC 66 1812 compliant ICMP implementations. 68 Table of Contents 70 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Destination Unreachable . . . . . . . . . . . . . . . . . 7 74 3.2. Source Quench . . . . . . . . . . . . . . . . . . . . . . 8 75 3.3. Time Exceeded . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4. Parameter Problem . . . . . . . . . . . . . . . . . . . . 9 77 3.5. ICMP Messages That Cannot Be Extended . . . . . . . . . . 9 78 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 79 4.1. Classic Application Receives ICMP Message With 80 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2. Partially Compliant Application Receives ICMP Message 82 With No Extensions . . . . . . . . . . . . . . . . . . . . 12 83 4.3. Partially Compliant Application Receives ICMP Message 84 With Fully Compliant Extensions . . . . . . . . . . . . . 12 85 4.4. Fully Compliant Application Receives ICMP Message with 86 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 87 4.5. Fully Compliant Application Receives ICMP Message with 88 Partially Compliant Extensions . . . . . . . . . . . . . . 13 89 5. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 13 90 6. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 14 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 98 Intellectual Property and Copyright Statements . . . . . . . . . . 19 100 1. Conventions Used In This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC2119 [1]. 106 2. Introduction 108 This document redefines selected ICMPv4 [2] messages to include an 109 extension structure and a length attribute. In this document, the 110 term ICMP refers exclusively to ICMPv4. Unless explicitly noted, 111 ICMPv6 is NOT discussed in this memo. 113 The syntax defined in this document MUST NOT be used to extend 114 ICMPv6. This syntax was designed to be backwards compatible with 115 currently deployed, MPLS-aware ICMPv4 implementations. Consequently, 116 the syntax is not as clean as would be desirable. For ICMPv6, where 117 there are no similarly deployed implementations, a better format 118 should be created. However, other than this note, ICMPv6 is beyond 119 the scope of this memo. 121 This document addresses a fundamental problem in ICMP extensibility. 122 Many of the ICMP messages addressed by this memo include an "original 123 datagram" field. The "original datagram" field contains the initial 124 octets of the datagram to which the ICMP message is a response. 125 Although the "original datagram" field is of variable length, the 126 ICMP message does not include a field that specifies its length. 128 Application software infers the length of the "original datagram" 129 field from the total length of the ICMP message. If an extension 130 structure were appended to the message without adding a length 131 attribute for the "original datagram" field, the message would become 132 unparsable. Specifically, application software would not be able to 133 determine where the "original datagram" field ends and where the 134 extension structure begins. Therefore, this document proposes a 135 length attribute as well as an extension structure that is appended 136 to the ICMP message. 138 The current memo also addresses backwards compatibility with existing 139 ICMP implementations that either do not implement the extensions 140 defined herein or implement them without adding the required length 141 attributes. In particular, this draft addresses backwards 142 compatibility with certain, widely deployed, MPLS-aware ICMP 143 implementations that send the extensions defined herein without 144 adding the required length attribute. 146 The current memo does not define any ICMP extension objects. It 147 defines only the extension header and a common header that all 148 objects share. Reference [5] provides a sample application of the 149 ICMP Extension Object. 151 3. ICMP Extensibility 153 RFC 792 defines the following ICMP message types: 155 - Destination Unreachable 157 - Time Exceeded 159 - Parameter Problem 161 - Source Quench 163 - Redirect 165 - Echo Request/Reply 167 - Timestamp/Timestamp Reply 169 - Information Request/Information Reply 171 RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination 172 Unreachable message. Subsequent RFCs define the following messages: 174 - Address Mask Request/Reply [6] 176 - Router Solicitation/Advertisement [7] 178 - Traceroute [8] 180 - Domain Name Request/Reply [9] 182 - Security Failure [10] 184 - Experimental Mobility [11] 186 Many ICMP messages are extensible as currently defined. Protocol 187 designers can extend ICMP messages by simply appending fields or data 188 structures to them. 190 The following ICMP messages are not extensible as currently defined: 192 - Destination Unreachable 194 - Source Quench 196 - Time Exceeded 198 - Parameter Problem 200 - Redirect 202 - Echo Request 204 - Echo Reply 206 - Domain Name Reply 208 These ICMP messages contain an "original datagram" field which 209 represents a portion of the original datagram to which the ICMP 210 messages is a response. As originally defined, this field includes 211 the IP header plus the next eight octets of the original datagram. 212 RFC 1812 [4] extends this field to contain as many octets as 213 possible, without exceeding a limit of 576 octets for the entire ICMP 214 message. 216 Unfortunately, the "original datagram" field lacks a length 217 attribute. Application software infers the length of this field from 218 the total length of the ICMP message. If an extension structure were 219 appended to the message without adding a length attribute for the 220 "original datagram" field, the message would become unparsable. 221 Specifically, application software would not be able to determine 222 where the "original datagram" field ends and where the extension 223 structure begins. 225 In order to solve this problem, this memo introduces an 8-bit length 226 attribute to the following ICMP messages. 228 - Destination Unreachable 230 - Source Quench 232 - Time Exceeded 234 - Parameter Problem 236 The length attribute MUST be specified when the ICMP Extension 237 Structure is appended to the above mentioned ICMP messages. It also 238 MUST be specified when the original datagram field includes 128 239 octets or more. It MAY be specified in any other case. 241 The length attribute represents the length of the "original datagram" 242 field, measured in 32-bit words. When the length attribute is 243 specified, the "original datagram" field MUST be zero padded to the 244 nearest 32-bit boundary. Space for the length attribute is claimed 245 from reserved octets, whose value was previously required to be zero. 246 Because the sixth octet of each of the impacted ICMP messages was 247 reserved for future use, this octet was selected as the location of 248 the length attribute. 250 In order the achieve backwards compatibility, when the ICMP Extension 251 Structure is appended to an ICMP message and that ICMP message 252 contains an "original datagram" field, the "original datagram" field 253 MUST contain at least 128 octets. If the original datagram did not 254 contain 128 octets, the "original datagram" field MUST be zero padded 255 to 128 octets. (See Section 4.1 for rationale.) 257 The following sub-sections depict length attribute as it has been 258 introduced to selected ICMP messages. 260 3.1. Destination Unreachable 262 Figure 1 depicts the Destination Unreachable Message. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Code | Checksum | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | unused | Length | Next-Hop MTU | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Internet Header + leading octets of original datagram | 272 | | 273 | // | 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 1: Destination Unreachable 279 The syntax and semantics of all fields are unchanged from RFC 792 and 280 RFC 1191. However, a length attribute is added to the second word. 281 The length attribute represents length of the padded "original 282 datagram" field, measured in 32-bit words. 284 When the ICMP Extension Structure is appended to this message, the 285 "original datagram" field MUST contain at least 128 octets (32 286 words). 288 3.2. Source Quench 290 Figure 2 depicts the Source Quench Message. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Code | Checksum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | unused | Length | unused | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Internet Header + leading octets of original datagram | 300 | | 301 | // | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 2: Source Quench 307 The syntax and semantics of all fields are unchanged from RFC 792, 308 except for a length attribute which is added to the second word. The 309 length attribute represents length of the padded "original datagram" 310 field, measured in 32-bit words. 312 3.3. Time Exceeded 314 Figure 3 depicts the Time Exceeded Message. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Code | Checksum | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | unused | Length | unused | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Internet Header + leading octets of original datagram | 324 | | 325 | // | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: Time Exceeded 331 The syntax and semantics of all fields are unchanged from RFC 792, 332 except for a length attribute which is added to the second word. The 333 length attribute represents length of the padded "original datagram" 334 field, measured in 32-bit words. 336 When the ICMP Extension Structure is appended to this message, the 337 "original datagram" field MUST contain at least 128 octets (32 338 words). 340 3.4. Parameter Problem 342 Figure 4 depicts the Parameter Problem Message. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Code | Checksum | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Pointer | Length | unused | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Internet Header + leading octets of original datagram | 352 | | 353 | // | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 4: Parameter Problem 359 The syntax and semantics of all fields are unchanged from RFC 792, 360 except for a length attribute which is added to the second word. The 361 length attribute represents length of the padded "original datagram" 362 field, measured in 32-bit words. 364 3.5. ICMP Messages That Cannot Be Extended 366 Due to a lack of reserved octets from which to allocate space, a 367 length attribute could not be added to the following ICMP messages: 369 - Redirect 371 - Echo Request 373 - Echo Reply 374 - Domain Name Reply 376 Therefore, the ICMP Extension Structure described in this memo cannot 377 be used in conjunction with the above mentioned ICMP messages. 379 4. Backwards Compatibility 381 ICMP messages can be categorized as follows: 383 - Messages that do not include any ICMP extensions 385 - Messages that include partially compliant ICMP extensions 387 - Messages that includes fully compliant ICMP extensions 389 Any ICMP implementation can send a message that does not include 390 extensions. ICMP implementations produced prior to 1999 never send 391 ICMP extensions. 393 Some ICMP implementations, produced between 1999 and the present, may 394 send a partially compliant version of ICMP extensions described in 395 this memo. Specifically, these implementations may append the ICMP 396 Extension Structure to the Time Exceeded and Destination Unreachable 397 messages. When they do this, they send exactly 128 octets 398 representing the original datagram, zero padding if required. 399 However, they do not specify a length attribute to be associated with 400 the "original datagram" field. 402 It is assumed that ICMP implementations produced in the future will 403 send ICMP extensions that are fully compliant with this 404 specification. 406 Likewise, applications that consume ICMP messages can be categorized 407 as follows: 409 - Classic applications 411 - Partially compliant applications 413 - Fully compliant applications 415 Classic applications do not parse extensions defined in this memo. 416 They are insensitive to the length attribute that is associated with 417 the "original datagram" field. 419 Partially compliant implementations parse the extensions defined in 420 this memo, but only in conjunction with the Time Expired and 421 Destination Unreachable messages. They require the "original 422 datagram" field to contain exactly 128 octets and are insensitive to 423 the length attribute that is associated with the "original datagram" 424 field. Partially compliant applications were produced between 1999 425 and the present. 427 Fully compliant applications comply fully with the specifications of 428 this document. 430 In order to demonstrate backwards compatibility, Table 1 describes 431 how members of each application category would parse each category of 432 ICMP message. 434 +----------------+----------------+----------------+----------------+ 435 | | No Extensions | Partially | Fully | 436 | | | Compliant | Compliant | 437 | | | Extensions | Extensions | 438 +----------------+----------------+----------------+----------------+ 439 | Classic | - | Section 4.1 | Section 4.1 | 440 | Application | | | | 441 | | | | | 442 | Partially | Section 4.2 | - | Section 4.3 | 443 | Compliant | | | | 444 | Application | | | | 445 | | | | | 446 | Fully | Section 4.4 | Section 4.5 | - | 447 | Compliant | | | | 448 | Application | | | | 449 +----------------+----------------+----------------+----------------+ 451 Table 1 453 In the table above, cells that contain a dash represent the nominal 454 case and require no explanation. In the following sections, we 455 assume that the ICMP message type is "Time Exceeded". 457 4.1. Classic Application Receives ICMP Message With Extensions 459 When a classic application receives an ICMP message that includes 460 extensions, it will incorrectly interpret those extensions as being 461 part of the "original datagram" field. Fortunately, the extensions 462 are guaranteed to begin at least 128 octets beyond the beginning of 463 the "original datagram" field. So, only those ICMP applications that 464 process the 129th octet of the "original datagram" field will be 465 adversely effected. To date, no such applications have been 466 identified. 468 4.2. Partially Compliant Application Receives ICMP Message With No 469 Extensions 471 When a partially compliant application receives a message that 472 contains no extensions, the application examines the total length of 473 the ICMP message. If the total ICMP message length is less than the 474 length of its IP header plus 144 octets, the application correctly 475 determines that the message does not contain any extensions. 477 The 144 octet sum is derived from 8 octets for the first two words of 478 the ICMP Time Exceeded message, 128 octets for the "original 479 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 480 for a single ICMP Object header. All of these octets would be 481 required if extensions were present. 483 If the ICMP payload contains 144 octets or more, the application must 484 examine the 137th octet to determine whether it represents a valid 485 ICMP Extension Header. In order to represent a valid Extension 486 Header, it must contain a valid version number and checksum. If it 487 does not contain a valid version number and checksum, the application 488 correctly determines that the message does not contain any 489 extensions. 491 Partially compliant applications assume that the ICMP Extension 492 Structure begins on the 137th octet of the Time Exceeded message, 493 after a 128 octet field representing the padded "original datagram" 494 message. 496 It is possible that a partially compliant application will parse an 497 ICMP message incorrectly under the following conditions: 499 - the message does not contain extensions 501 - the original datagram field contains 144 octets or more 503 - selected octets of the original datagram field represent the 504 correct values for an extension header version number and checksum 506 Although this is possible, it is very unlikely. 508 4.3. Partially Compliant Application Receives ICMP Message With Fully 509 Compliant Extensions 511 When a partially compliant application receives a message that 512 contains fully compliant ICMP extensions, it will parse those 513 extensions correctly only if the "original datagram" field contains 514 exactly 128 octets. This is because partially compliant applications 515 are insensitive to the length attribute that is associated with the 516 "original datagram" field. (They assume its value to be 128.) 518 Provided that the entire ICMP messages does not exceed 576 octets, 519 there is no upper limit upon the length of the "original datagram" 520 field. However, each vendor will decide how many octets to include. 521 Those wishing to be backward compatible with partially compliant 522 TRACEROUTE implementations will include exactly 128 octets. Those 523 not requiring compatibility with partially compliant TRACEROUTE 524 applications may include more octets. 526 4.4. Fully Compliant Application Receives ICMP Message with No 527 Extensions 529 When a fully compliant application receives an ICMP message, it 530 examines the length attribute that is associated with the "original 531 datagram" field. If the length attribute is zero, the fully 532 compliant application MUST determine that the message contains no 533 extensions. 535 4.5. Fully Compliant Application Receives ICMP Message with Partially 536 Compliant Extensions 538 When a fully compliant application receives an ICMP message, it 539 examines the length attribute that is associated with the "original 540 datagram" field. If the length attribute is zero, the fully 541 compliant application MUST determine that the message contains no 542 extensions. In this case, that determination will be incorrect 543 because the partially compliant ICMP message contains extensions but 544 does not specify a length attribute. 546 For this reason, vendors may choose to implement TRACEROUTE in a 547 manner that is not fully compliant. Specifically, when TRACEROUTE 548 receives an ICMP message that contains 144 octets or more in its 549 payload and does not specify a length attribute, it will parse for a 550 valid extension header beginning at octet 137. If the application 551 detects a valid version and checksum, it will treat the following 552 octets as an extension structure. 554 Vendors should limit the practice of deploying non-compliant 555 applications to TRACEROUTE. 557 5. The ICMP Extension Structure 559 This memo proposes an optional ICMP Extension Structure that can be 560 appended to any ICMP message, except for those that are disqualified 561 in Section 3.5 of this document. 563 The Extension Structure contains exactly one Extension Header 564 followed by one or more objects. Having received an ICMP message 565 with extensions, application software MAY process selected objects 566 while ignoring others. The presence of an unrecognized object does 567 not imply that an ICMP message is malformed. 569 As stated in RFC 792, the total length of the ICMP message, including 570 extensions, MUST NOT exceed 576 octets. Figure 5 depicts the ICMP 571 Extension Header. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |Version| (Reserved) | Checksum | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 5: ICMP Extension Header 581 The fields of the ICMP Extension Header are as follows: 583 Version: 4 bits 585 ICMP extension version number. This is version 2. 587 Reserved: 12 bits 589 Must be set to 0. 591 Checksum: 16 bits 593 The one's complement of the one's complement sum of the data 594 structure, with the checksum field replaced by zero for the 595 purpose of computing the checksum. An all-zero value means that 596 no checksum was transmitted. 598 If the checksum field contains a value other than described above, 599 the ICMP message does not include the extensions described in this 600 memo. However, due to backwards compatibility, this does not 601 imply that the ICMP message is malformed. See for Section 4 602 details. 604 6. ICMP Extension Objects 606 Each extension object contains one or more 32-bit words, representing 607 an object header and payload. All object headers share a common 608 format. Figure 6 depicts the Object Header and payload. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Length | Class-Num | C-Type | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | | 616 | // (Object payload) // | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 6: Object Header and Payload 622 An object header has the following fields: 624 Length: 16 bits 626 Length of the object, measured in octets, including the object 627 header and object payload. 629 Class-Num: 8 bits 631 Identifies object class. 633 C-Type: 8 bits 635 Identifies object sub-type. 637 7. Security Considerations 639 Upon receipt of an ICMP message, application software must check it 640 for syntactic correctness. Improperly specified length attributes 641 and other syntax problems may result in buffer overruns. 643 This memo does not define the conditions under which a router sends 644 an ICMP message. Therefore, it does not expose routers to any new 645 denial of service attacks. 647 8. IANA Considerations 649 The ICMP Extension Object header contains two 8-bit fields: The 650 Class-Num identifies the object class, and the C-Type identifies the 651 class sub-type. Sub-type values are defined relative to a specific 652 object class value, and are defined per-class. 654 IANA should establish a registry of ICMP extension objects classes 655 and class sub-types. There are no values assigned within this 656 document to maintain. Object classes 0xF7 - 0xFF are reserved for 657 private use. Object class values are assignable on a first-come- 658 first-serve. The policy for assigning sub-type values should be 659 defined in the document defining new class values. 661 9. Acknowledgments 663 Thanks to Joe Touch for his comments regarding this draft. 665 10. References 667 10.1. Normative References 669 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 670 Levels", BCP 14, RFC 2119, March 1997. 672 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 673 September 1981. 675 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 676 November 1990. 678 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 679 June 1995. 681 10.2. Informative References 683 [5] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 684 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 686 [6] Mogul, J. and J. Postel, "Internet Standard Subnetting 687 Procedure", STD 5, RFC 950, August 1985. 689 [7] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 690 September 1991. 692 [8] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 693 January 1993. 695 [9] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 697 [10] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 698 RFC 2521, March 1999. 700 [11] Kempf, J., "Instructions for Seamoby and Experimental Mobility 701 Protocol IANA Allocations", RFC 4065, July 2005. 703 Authors' Addresses 705 Ronald P. Bonica 706 Juniper Networks 707 2251 Corporate Park Drive 708 Herndon, VA 20171 709 US 711 Email: rbonica@juniper.net 713 Der-Hwa Gan 714 Juniper Networks 715 1194 N. Mathilda Ave. 716 Sunnyvale, CA 94089 717 US 719 Email: dhg@juniper.net 721 Pekka Nikander 722 Ericsson Research Nomadic Lab 723 JORVAS FIN-02420 724 Finland 726 Email: pekka.nikander@nomadiclab.com 728 Daniel C. Tappan 729 Cisco Systems, Inc. 730 250 Apollo Drive 731 Chelmsford, MA 01824 732 US 734 Email: tappan@cisco.com 736 Carlos Pignataro 737 Cisco Systems, Inc. 738 7025 Kit Creek Road 739 Research Triangle Park, N.C. 27709 740 US 742 Email: cpignata@cisco.com 744 Intellectual Property Statement 746 The IETF takes no position regarding the validity or scope of any 747 Intellectual Property Rights or other rights that might be claimed to 748 pertain to the implementation or use of the technology described in 749 this document or the extent to which any license under such rights 750 might or might not be available; nor does it represent that it has 751 made any independent effort to identify any such rights. Information 752 on the procedures with respect to rights in RFC documents can be 753 found in BCP 78 and BCP 79. 755 Copies of IPR disclosures made to the IETF Secretariat and any 756 assurances of licenses to be made available, or the result of an 757 attempt made to obtain a general license or permission for the use of 758 such proprietary rights by implementers or users of this 759 specification can be obtained from the IETF on-line IPR repository at 760 http://www.ietf.org/ipr. 762 The IETF invites any interested party to bring to its attention any 763 copyrights, patents or patent applications, or other proprietary 764 rights that may cover technology that may be required to implement 765 this standard. Please address the information to the IETF at 766 ietf-ipr@ietf.org. 768 Disclaimer of Validity 770 This document and the information contained herein are provided on an 771 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 772 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 773 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 774 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 775 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 776 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Copyright Statement 780 Copyright (C) The Internet Society (2006). This document is subject 781 to the rights, licenses and restrictions contained in BCP 78, and 782 except as set forth therein, the authors retain all their rights. 784 Acknowledgment 786 Funding for the RFC Editor function is currently provided by the 787 Internet Society.