idnits 2.17.1 draft-bonica-internet-icmp-06.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 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 763. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2006) is 6502 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '8') (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '9') (Obsoleted by RFC 6918) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet R. Bonica 3 Internet-Draft D. Gan 4 Expires: December 11, 2006 Juniper Networks 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 June 9, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 11, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document redefines selected ICMPv4 messages to support multi- 47 part operation. A multi-part ICMP message carries all of the 48 information that ICMP messages carried previously, as well as 49 additional information that applications may require. 51 Multi-part messages are supported by an ICMP extension structure. 52 The extension structure is situated at the end of the ICMP message. 53 It includes an extension header followed by one or more extension 54 objects. Each extension object contains an object header and object 55 payload. All object headers share a common format. 57 This document further redefines a subset of the above mentioned ICMP 58 messages by specifying a length attribute. Many of the ICMP messages 59 to which an extension structure can be appended include and "original 60 datagram" field. The "original datagram" field contains the initial 61 octets of the datagram to which the ICMP message is a response. 62 Although the original datagram field is of variable length, the ICMP 63 message does not include a field that specifies its length. 64 Therefore, in order to facilitate message parsing, this draft 65 allocates eight previously reserved bits to reflect the length of the 66 "original datagram" field. 68 The proposed modifications change the requirements for ICMPv4 69 compliance. The impact of these changes on compliant implementations 70 is discussed, and new requirements for future implementations are 71 presented. 73 Table of Contents 75 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Summary of Changes to ICMP . . . . . . . . . . . . . . . . . . 5 78 4. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. Destination Unreachable . . . . . . . . . . . . . . . . . 7 80 4.2. Source Quench . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. Time Exceeded . . . . . . . . . . . . . . . . . . . . . . 9 82 4.4. Parameter Problem . . . . . . . . . . . . . . . . . . . . 9 83 4.5. ICMP Messages That Can Be Extended . . . . . . . . . . . . 10 84 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 85 5.1. Classic Application Receives ICMP Message With 86 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2. Non-compliant Application Receives ICMP Message With 88 No Extensions . . . . . . . . . . . . . . . . . . . . . . 12 89 5.3. Non-compliant Application Receives ICMP Message With 90 Compliant Extensions . . . . . . . . . . . . . . . . . . . 13 91 5.4. Compliant Application Receives ICMP Message with No 92 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 93 5.5. Compliant Application Receives ICMP Message with 94 Non-compliant Extensions . . . . . . . . . . . . . . . . . 13 95 6. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 14 96 7. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 14 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 104 Intellectual Property and Copyright Statements . . . . . . . . . . 19 106 1. Conventions Used In This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC2119 [1]. 112 2. Introduction 114 This document redefines selected ICMP [2] messages to include an 115 extension structure and a length attribute. In this document, the 116 term ICMP refers exclusively to ICMPv4. Unless explicitly noted, 117 ICMPv6 is NOT discussed in this memo. 119 The extension structure supports multi-part ICMP operation. Protocol 120 designers can make an ICMP message carry additional information by 121 encoding that information in an extension. 123 This document also addresses a fundamental problem in ICMP 124 extensibility. Many of the ICMP messages addressed by this memo 125 include an "original datagram" field. The "original datagram" field 126 contains the initial octets of the datagram to which the ICMP message 127 is a response. Although the "original datagram" field is of variable 128 length, the ICMP message does not include a field that specifies its 129 length. 131 Application software infers the length of the "original datagram" 132 field from the total length of the ICMP message. If an extension 133 structure were appended to the message without adding a length 134 attribute for the "original datagram" field, the message would become 135 unparsable. Specifically, application software would not be able to 136 determine where the "original datagram" field ends and where the 137 extension structure begins. Therefore, this document proposes a 138 length attribute as well as an extension structure that is appended 139 to the ICMP message. 141 The current memo also addresses backwards compatibility with existing 142 ICMP implementations that either do not implement the extensions 143 defined herein or implement them without adding the required length 144 attributes. In particular, this draft addresses backwards 145 compatibility with certain, widely deployed, MPLS-aware ICMP 146 implementations that send the extensions defined herein without 147 adding the required length attribute. 149 The current memo does not define any ICMP extension objects. It 150 defines only the extension header and a common header that all 151 extension objects share. Reference [5] provides a sample application 152 of the ICMP Extension Object. 154 3. Summary of Changes to ICMP 156 The following is a summary of changes to ICMP that are proposed by 157 this memo: 159 An ICMP Extension Structure MAY be appended to ICMP Destination 160 Unreachable, Source Quench, Time Exceeded, and Parameter Problem 161 messages. 163 These messages include an "original datagram" field, and the 164 message formats are updated to specify a length attribute for the 165 "original datagram" field. 167 The "original datagram" field MUST include at least 128 octets. 168 If the original datagram did not contain 128 octets, the "original 169 datagram" field MUST be zero padded to 128 octets. 171 The "original datagram" field MUST be zero padded to the nearest 172 32-bit boundary. 174 4. ICMP Extensibility 176 RFC 792 defines the following ICMP message types: 178 - Destination Unreachable 180 - Time Exceeded 182 - Parameter Problem 184 - Source Quench 186 - Redirect 188 - Echo Request/Reply 190 - Timestamp/Timestamp Reply 192 - Information Request/Information Reply 194 RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination 195 Unreachable message. Subsequent RFCs define the following messages: 197 - Address Mask Request/Reply [6] 198 - Router Solicitation/Advertisement [7] 200 - Traceroute [8] 202 - Domain Name Request/Reply [9] 204 - Security Failure [10] 206 - Experimental Mobility [11] 208 Many ICMP messages are extensible as currently defined. Protocol 209 designers can extend ICMP messages by simply appending fields or data 210 structures to them. 212 The following ICMP messages are not extensible as currently defined: 214 - Destination Unreachable 216 - Source Quench 218 - Time Exceeded 220 - Parameter Problem 222 - Redirect 224 - Echo Request 226 - Echo Reply 228 - Domain Name Reply 230 These ICMP messages contain an "original datagram" field which 231 represents a portion of the original datagram to which the ICMP 232 messages is a response. As originally defined, this field includes 233 the IP header plus the next eight octets of the original datagram. 234 RFC 1812 [4] extends this field to contain as many octets as 235 possible, without exceeding a limit of 576 octets for the entire ICMP 236 message. 238 Unfortunately, the "original datagram" field lacks a length 239 attribute. Application software infers the length of this field from 240 the total length of the ICMP message. If an extension structure were 241 appended to the message without adding a length attribute for the 242 "original datagram" field, the message would become unparsable. 243 Specifically, application software would not be able to determine 244 where the "original datagram" field ends and where the extension 245 structure begins. 247 In order to solve this problem, this memo introduces an 8-bit length 248 attribute to the following ICMP messages. 250 - Destination Unreachable 252 - Source Quench 254 - Time Exceeded 256 - Parameter Problem 258 The length attribute MUST be specified when the ICMP Extension 259 Structure is appended to the above mentioned ICMP messages. 261 The length attribute represents the length of the "original datagram" 262 field, measured in 32-bit words. When the length attribute is 263 specified, the "original datagram" field MUST be zero padded to the 264 nearest 32-bit boundary. Space for the length attribute is claimed 265 from reserved octets, whose value was previously required to be zero. 266 Because the sixth octet of each of the impacted ICMP messages was 267 reserved for future use, this octet was selected as the location of 268 the length attribute. 270 In order the achieve backwards compatibility, when the ICMP Extension 271 Structure is appended to an ICMP message and that ICMP message 272 contains an "original datagram" field, the "original datagram" field 273 MUST contain at least 128 octets. If the original datagram did not 274 contain 128 octets, the "original datagram" field MUST be zero padded 275 to 128 octets. (See Section 5.1 for rationale.) 277 The following sub-sections depict length attribute as it has been 278 introduced to selected ICMP messages. 280 4.1. Destination Unreachable 282 Figure 1 depicts the Destination Unreachable Message. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Code | Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | unused | Length | Next-Hop MTU | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Internet Header + leading octets of original datagram | 292 | | 293 | // | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 1: Destination Unreachable 299 The syntax and semantics of all fields are unchanged from RFC 792 and 300 RFC 1191. However, a length attribute is added to the second word. 301 The length attribute represents length of the padded "original 302 datagram" field, measured in 32-bit words. 304 4.2. Source Quench 306 Figure 2 depicts the Source Quench Message. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Code | Checksum | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | unused | Length | unused | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Internet Header + leading octets of original datagram | 316 | | 317 | // | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2: Source Quench 323 The syntax and semantics of all fields are unchanged from RFC 792, 324 except for a length attribute which is added to the second word. The 325 length attribute represents length of the padded "original datagram" 326 field, measured in 32-bit words. 328 4.3. Time Exceeded 330 Figure 3 depicts the Time Exceeded Message. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Code | Checksum | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | unused | Length | unused | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Internet Header + leading octets of original datagram | 340 | | 341 | // | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 3: Time Exceeded 347 The syntax and semantics of all fields are unchanged from RFC 792, 348 except for a length attribute which is added to the second word. The 349 length attribute represents length of the padded "original datagram" 350 field, measured in 32-bit words. 352 4.4. Parameter Problem 354 Figure 4 depicts the Parameter Problem Message. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Code | Checksum | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Pointer | Length | unused | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Internet Header + leading octets of original datagram | 364 | | 365 | // | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 4: Parameter Problem 371 The syntax and semantics of all fields are unchanged from RFC 792, 372 except for a length attribute which is added to the second word. The 373 length attribute represents length of the padded "original datagram" 374 field, measured in 32-bit words. 376 4.5. ICMP Messages That Can Be Extended 378 An ICMP Extension Structure MAY be appended to ICMP Destination 379 Unreachable, Source Quench, Time Exceeded, and Parameter Problem 380 messages. The ICMP Extension Structure cannot be appended to any of 381 the other ICMP messages mentioned in Section 4. 383 ICMP messages defined in the future should indicate whether or not 384 they support the extension mechanism defined in this specification. 385 It is recommended that all new messages employ some mechanism that 386 allows later extensions. 388 5. Backwards Compatibility 390 ICMP messages can be categorized as follows: 392 - Messages that do not include any ICMP extensions 394 - Messages that include non-compliant ICMP extensions 396 - Messages that includes compliant ICMP extensions 398 Any ICMP implementation can send a message that does not include 399 extensions. ICMP implementations produced prior to 1999 are not 400 known to send ICMP extensions. 402 Some ICMP implementations, produced between 1999 and the present, may 403 send a non-compliant version of ICMP extensions described in this 404 memo. Specifically, these implementations may append the ICMP 405 Extension Structure to the Time Exceeded and Destination Unreachable 406 messages. When they do this, they send exactly 128 octets 407 representing the original datagram, zero padding if required. They 408 also calculate checksums as described in this document. However, 409 they do not specify a length attribute to be associated with the 410 "original datagram" field. 412 It is assumed that ICMP implementations produced in the future will 413 send ICMP extensions that are compliant with this specification. 415 Likewise, applications that consume ICMP messages can be categorized 416 as follows: 418 - Classic applications 420 - Non-compliant applications 422 - Compliant applications 424 Classic applications do not parse extensions defined in this memo. 425 They are insensitive to the length attribute that is associated with 426 the "original datagram" field. 428 Non-compliant implementations parse the extensions defined in this 429 memo, but only in conjunction with the Time Expired and Destination 430 Unreachable messages. They require the "original datagram" field to 431 contain exactly 128 octets and are insensitive to the length 432 attribute that is associated with the "original datagram" field. 433 Non-compliant applications were produced between 1999 and the 434 present. 436 Compliant applications comply fully with the specifications of this 437 document. 439 In order to demonstrate backwards compatibility, Table 1 describes 440 how members of each application category would parse each category of 441 ICMP message. 443 +----------------+----------------+----------------+----------------+ 444 | | No Extensions | Non-compliant | Compliant | 445 | | | Extensions | Extensions | 446 +----------------+----------------+----------------+----------------+ 447 | Classic | - | Section 5.1 | Section 5.1 | 448 | Application | | | | 449 | | | | | 450 | Non-compliant | Section 5.2 | - | Section 5.3 | 451 | Application | | | | 452 | | | | | 453 | Compliant | Section 5.4 | Section 5.5 | - | 454 | Application | | | | 455 +----------------+----------------+----------------+----------------+ 457 Table 1 459 In the table above, cells that contain a dash represent the nominal 460 case and require no explanation. In the following sections, we 461 assume that the ICMP message type is "Time Exceeded". 463 5.1. Classic Application Receives ICMP Message With Extensions 465 When a classic application receives an ICMP message that includes 466 extensions, it will incorrectly interpret those extensions as being 467 part of the "original datagram" field. Fortunately, the extensions 468 are guaranteed to begin at least 128 octets beyond the beginning of 469 the "original datagram" field. So, only those ICMP applications that 470 process the 129th octet of the "original datagram" field will be 471 adversely effected. To date, no such applications have been 472 identified. 474 5.2. Non-compliant Application Receives ICMP Message With No Extensions 476 When a non-compliant application receives a message that contains no 477 extensions, the application examines the total length of the ICMP 478 message. If the total ICMP message length is less than the length of 479 its IP header plus 144 octets, the application correctly determines 480 that the message does not contain any extensions. 482 The 144 octet sum is derived from 8 octets for the first two words of 483 the ICMP Time Exceeded message, 128 octets for the "original 484 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 485 for a single ICMP Object header. All of these octets would be 486 required if extensions were present. 488 If the ICMP payload contains 144 octets or more, the application must 489 examine the 137th octet to determine whether it represents a valid 490 ICMP Extension Header. In order to represent a valid Extension 491 Header, it must contain a valid version number and checksum. If it 492 does not contain a valid version number and checksum, the application 493 correctly determines that the message does not contain any 494 extensions. 496 Non-compliant applications assume that the ICMP Extension Structure 497 begins on the 137th octet of the Time Exceeded message, after a 128 498 octet field representing the padded "original datagram" message. 500 It is possible that a non-compliant application will parse an ICMP 501 message incorrectly under the following conditions: 503 - the message does not contain extensions 505 - the original datagram field contains 144 octets or more 507 - selected octets of the original datagram field represent the 508 correct values for an extension header version number and checksum 510 Although this is possible, it is very unlikely. 512 5.3. Non-compliant Application Receives ICMP Message With Compliant 513 Extensions 515 When a non-compliant application receives a message that contains 516 compliant ICMP extensions, it will parse those extensions correctly 517 only if the "original datagram" field contains exactly 128 octets. 518 This is because non-compliant applications are insensitive to the 519 length attribute that is associated with the "original datagram" 520 field. (They assume its value to be 128.) 522 Provided that the entire ICMP messages does not exceed 576 octets, 523 there is no upper limit upon the length of the "original datagram" 524 field. However, each vendor will decide how many octets to include. 525 Those wishing to be backward compatible with non-compliant TRACEROUTE 526 implementations will include exactly 128 octets. Those not requiring 527 compatibility with non-compliant TRACEROUTE applications may include 528 more octets. 530 5.4. Compliant Application Receives ICMP Message with No Extensions 532 When a compliant application receives an ICMP message, it examines 533 the length attribute that is associated with the "original datagram" 534 field. If the length attribute is zero, the compliant application 535 MUST determine that the message contains no extensions. 537 5.5. Compliant Application Receives ICMP Message with Non-compliant 538 Extensions 540 When a compliant application receives an ICMP message, it examines 541 the length attribute that is associated with the "original datagram" 542 field. If the length attribute is zero, the compliant application 543 MUST determine that the message contains no extensions. In this 544 case, that determination is technically correct, but not backwards 545 compatible with the non-compliant implementation that originated the 546 ICMP message. 548 So, to ease transition yet encourage compliant implementation, 549 compliant TRACEROUTE implementations MAY include a non-default 550 operation mode to also interpret non-compliant responses. 551 Specifically, when a TRACEROUTE application operating in non- 552 compliant mode receives an ICMP message that contains 144 octets or 553 more in its payload and does not specify a length attribute, it will 554 parse for a valid extension header beginning at octet 137. If the 555 application detects a valid version and checksum, it will treat the 556 following octets as an extension structure. 558 6. The ICMP Extension Structure 560 This memo proposes an optional ICMP Extension Structure that can be 561 appended to any ICMP message, except for those that are disqualified 562 in Section 4.5 of this document. 564 The Extension Structure contains exactly one Extension Header 565 followed by one or more objects. Having received an ICMP message 566 with extensions, application software MAY process selected objects 567 while ignoring others. The presence of an unrecognized object does 568 not imply that an ICMP message is malformed. 570 As stated in RFC 792, the total length of the ICMP message, including 571 extensions, MUST NOT exceed 576 octets. Figure 5 depicts the ICMP 572 Extension Header. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Version| (Reserved) | Checksum | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 5: ICMP Extension Header 582 The fields of the ICMP Extension Header are as follows: 584 Version: 4 bits 586 ICMP extension version number. This is version 2. 588 Reserved: 12 bits 590 Must be set to 0. 592 Checksum: 16 bits 594 The one's complement of the one's complement sum of the data 595 structure, with the checksum field replaced by zero for the 596 purpose of computing the checksum. An all-zero value means that 597 no checksum was transmitted. 599 7. ICMP Extension Objects 601 Each extension object contains one or more 32-bit words, representing 602 an object header and payload. All object headers share a common 603 format. Figure 6 depicts the Object Header and payload. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Length | Class-Num | C-Type | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 | // (Object payload) // | 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 6: Object Header and Payload 617 An object header has the following fields: 619 Length: 16 bits 621 Length of the object, measured in octets, including the object 622 header and object payload. 624 Class-Num: 8 bits 626 Identifies object class. 628 C-Type: 8 bits 630 Identifies object sub-type. 632 8. Security Considerations 634 Upon receipt of an ICMP message, application software must check it 635 for syntactic correctness. The extension checksum must be verified. 636 Improperly specified length attributes and other syntax problems may 637 result in buffer overruns. 639 This memo does not define the conditions under which a router sends 640 an ICMP message. Therefore, it does not expose routers to any new 641 denial of service attacks. Routers may need to limit the rate at 642 which ICMP messages are sent. 644 9. IANA Considerations 646 The ICMP Extension Object header contains two 8-bit fields: The 647 Class-Num identifies the object class, and the C-Type identifies the 648 class sub-type. Sub-type values are defined relative to a specific 649 object class value, and are defined per-class. 651 IANA should establish a registry of ICMP extension objects classes 652 and class sub-types. There are no values assigned within this 653 document to maintain. Object classes 0xF7 - 0xFF are reserved for 654 private use. Object class values are assignable on a first-come- 655 first-serve. The policy for assigning sub-type values should be 656 defined in the document defining new class values. 658 10. Acknowledgments 660 Thanks to Joe Touch for his comments regarding this draft. 662 11. References 664 11.1. Normative References 666 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 667 Levels", BCP 14, RFC 2119, March 1997. 669 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 670 September 1981. 672 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 673 November 1990. 675 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 676 June 1995. 678 11.2. Informative References 680 [5] Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 681 draft-atlas-icmp-unnumbered-01 (work in progress), March 2006. 683 [6] Mogul, J. and J. Postel, "Internet Standard Subnetting 684 Procedure", STD 5, RFC 950, August 1985. 686 [7] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 687 September 1991. 689 [8] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 690 January 1993. 692 [9] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 694 [10] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 695 RFC 2521, March 1999. 697 [11] Kempf, J., "Instructions for Seamoby and Experimental Mobility 698 Protocol IANA Allocations", RFC 4065, July 2005. 700 Authors' Addresses 702 Ronald P. Bonica 703 Juniper Networks 704 2251 Corporate Park Drive 705 Herndon, VA 20171 706 US 708 Email: rbonica@juniper.net 710 Der-Hwa Gan 711 Juniper Networks 712 1194 N. Mathilda Ave. 713 Sunnyvale, CA 94089 714 US 716 Email: dhg@juniper.net 718 Pekka Nikander 719 Ericsson Research Nomadic Lab 720 JORVAS FIN-02420 721 Finland 723 Email: pekka.nikander@nomadiclab.com 725 Daniel C. Tappan 726 Cisco Systems, Inc. 727 250 Apollo Drive 728 Chelmsford, MA 01824 729 US 731 Email: tappan@cisco.com 733 Carlos Pignataro 734 Cisco Systems, Inc. 735 7025 Kit Creek Road 736 Research Triangle Park, N.C. 27709 737 US 739 Email: cpignata@cisco.com 741 Intellectual Property Statement 743 The IETF takes no position regarding the validity or scope of any 744 Intellectual Property Rights or other rights that might be claimed to 745 pertain to the implementation or use of the technology described in 746 this document or the extent to which any license under such rights 747 might or might not be available; nor does it represent that it has 748 made any independent effort to identify any such rights. Information 749 on the procedures with respect to rights in RFC documents can be 750 found in BCP 78 and BCP 79. 752 Copies of IPR disclosures made to the IETF Secretariat and any 753 assurances of licenses to be made available, or the result of an 754 attempt made to obtain a general license or permission for the use of 755 such proprietary rights by implementers or users of this 756 specification can be obtained from the IETF on-line IPR repository at 757 http://www.ietf.org/ipr. 759 The IETF invites any interested party to bring to its attention any 760 copyrights, patents or patent applications, or other proprietary 761 rights that may cover technology that may be required to implement 762 this standard. Please address the information to the IETF at 763 ietf-ipr@ietf.org. 765 Disclaimer of Validity 767 This document and the information contained herein are provided on an 768 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 769 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 770 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 771 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 772 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 773 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 775 Copyright Statement 777 Copyright (C) The Internet Society (2006). This document is subject 778 to the rights, licenses and restrictions contained in BCP 78, and 779 except as set forth therein, the authors retain all their rights. 781 Acknowledgment 783 Funding for the RFC Editor function is currently provided by the 784 Internet Society.