idnits 2.17.1 draft-bonica-internet-icmp-13.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 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 931. ** 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 issues found here. 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 (December 7, 2006) is 6350 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) ** Downref: Normative reference to an Informational RFC: RFC 3022 == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-icmp-06 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Intended status: Standards Track Juniper Networks 5 Expires: June 10, 2007 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 December 7, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-13 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 June 10, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document redefines selected ICMP messages to support multi-part 47 operation. A multi-part ICMP message carries all of the information 48 that ICMP messages carried previously, as well as additional 49 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 the above mentioned ICMP messages by 58 specifying a length attribute. All of the currently defined ICMP 59 messages to which an extension structure can be appended include an 60 "original datagram" field. The "original datagram" field contains 61 the initial octets of the datagram that elicited the ICMP error 62 message. Although the original datagram field is of variable length, 63 the ICMP 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 ICMP 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. ICMPv4 Destination Unreachable . . . . . . . . . . . . . . 8 80 4.2. ICMPv4 Time Exceeded . . . . . . . . . . . . . . . . . . . 8 81 4.3. ICMPv4 Parameter Problem . . . . . . . . . . . . . . . . . 9 82 4.4. ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 9 83 4.5. ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 10 84 4.6. ICMP Messages That Can Be Extended . . . . . . . . . . . . 10 85 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 86 5.1. Classic Application Receives ICMP Message With 87 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.2. Non-compliant Application Receives ICMP Message With 89 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 90 5.3. Non-compliant Application Receives ICMP Message With 91 Compliant Extensions . . . . . . . . . . . . . . . . . . . 14 92 5.4. Compliant Application Receives ICMP Message with No 93 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.5. Compliant Application Receives ICMP Message with 95 Non-compliant Extensions . . . . . . . . . . . . . . . . . 15 96 6. Interaction with Network Address Translation . . . . . . . . . 15 97 7. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 16 98 8. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 17 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 102 12. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 Intellectual Property and Copyright Statements . . . . . . . . . . 22 109 1. Conventions Used In This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Introduction 117 This document redefines selected ICMPv4 [RFC0792] and ICMPv6 118 [RFC4443] messages to include an extension structure and a length 119 attribute. The extension structure supports multi-part ICMP 120 operation. Protocol designers can make an ICMP message carry 121 additional information by encoding that information in the extension 122 structure. 124 This document also addresses a fundamental problem in ICMP 125 extensibility. All of the ICMP messages addressed by this memo 126 include an "original datagram" field. The "original datagram" field 127 contains the initial octets of the datagram that elicited the ICMP 128 error message. Although the "original datagram" field is of variable 129 length, the ICMP message does not include a field that specifies its 130 length. 132 Application software infers the length of the "original datagram" 133 field from the total length of the ICMP message. If an extension 134 structure were appended to the message without adding a length 135 attribute for the "original datagram" field, the message would become 136 unparsable. Specifically, application software would not be able to 137 determine where the "original datagram" field ends and where the 138 extension structure begins. Therefore, this document proposes a 139 length attribute as well as an extension structure that is appended 140 to the ICMP message. 142 The current memo also addresses backwards compatibility with existing 143 ICMP implementations that either do not implement the extensions 144 defined herein or implement them without adding the required length 145 attributes. In particular, this draft addresses backwards 146 compatibility with certain, widely deployed, MPLS-aware ICMPv4 147 implementations that send the extensions defined herein without 148 adding the required length attribute. 150 The current memo does not define any ICMP extension objects. It 151 defines only the extension header and a common header that all 152 extension objects share. [I-D.atlas-icmp-unnumbered], 153 [I-D.shen-icmp-routing-inst] and [I-D.ietf-mpls-icmp] provide sample 154 applications of the ICMP Extension Object. 156 The above mentioned memos share a common characteristic. They all 157 append information to the ICMP Time Expired message for consumption 158 by TRACEROUTE. In this case, as in many others, appending 159 information to the existing ICMP Time Expired Message is preferable 160 to defining a new message and emitting two messages whenever a packet 161 is dropped to to TTL expiration. 163 3. Summary of Changes to ICMP 165 The following is a summary of changes to ICMP that are proposed by 166 this memo: 168 An ICMP Extension Structure MAY be appended to ICMPv4 Destination 169 Unreachable, Time Exceeded, and Parameter Problem messages. 171 An ICMP Extension Structure MAY be appended to ICMPv6 Destination 172 Unreachable, and Time Exceeded messages. 174 The above mentioned messages include an "original datagram" field, 175 and the message formats are updated to specify a length attribute 176 for the "original datagram" field. 178 The "original datagram" field MUST include at least 128 octets. 179 If the original datagram did not contain 128 octets, the "original 180 datagram" field MUST be zero padded to 128 octets. 182 For ICMPv4 messages, the "original datagram" field MUST be zero 183 padded to the nearest 32-bit boundary. 185 For ICMPv6 messages, the "original datagram" field MUST be zero 186 padded to the nearest 64-bit boundary. 188 4. ICMP Extensibility 190 RFC 792 defines the following ICMPv4 message types: 192 - Destination Unreachable 194 - Time Exceeded 196 - Parameter Problem 198 - Source Quench 199 - Redirect 201 - Echo Request/Reply 203 - Timestamp/Timestamp Reply 205 - Information Request/Information Reply 207 [RFC1191] reserves bits for the "Next-Hop MTU" field in the 208 Destination Unreachable message. 210 RFC 4443 defines the following ICMPv6 message types: 212 - Destination Unreachable 214 - Packet Too Big 216 - Time Exceeded 218 - Parameter Problem 220 - Echo Request/Reply 222 Many ICMP messages are extensible as currently defined. Protocol 223 designers can extend ICMP messages by simply appending fields or data 224 structures to them. 226 Many ICMP messages are not extensible as currently defined. These 227 messages contain an "original datagram" field which represents the 228 leading octets of the datagram to which the ICMP message is a 229 response. RFC 792 defines the "original datagram" field for ICMPv4 230 messages. In RFC 792, the "original datagram" field includes the IP 231 header plus the next eight octets of the original datagram. 232 [RFC1812] extends the "original datagram" field to contain as many 233 octets as possible without causing the ICMP message to exceed the 234 minimum IPv4 reassembly buffer size (i.e., 576 octets). RFC 4443 235 defines the "original datagram" field for ICMPv6 messages. In RFC 236 4443, the "original datagram" field always contained as many octets 237 as possible without causing the ICMP message to exceed the minimum 238 IPv6 reassembly buffer size (i.e., 1280 octets). 240 Unfortunately, the "original datagram" field lacks a length 241 attribute. Application software infers the length of this field from 242 the total length of the ICMP message. If an extension structure were 243 appended to the message without adding a length attribute for the 244 "original datagram" field, the message would become unparsable. 245 Specifically, application software would not be able to determine 246 where the "original datagram" field ends and where the extension 247 structure begins. 249 In order to solve this problem, this memo introduces an 8-bit length 250 attribute to the following ICMPv4 messages. 252 - Destination Unreachable (type = 3) 254 - Time Exceeded (type = 11) 256 - Parameter Problem (type = 12) 258 It also introduces an 8-bit length attribute to the following ICMPv6 259 messages. 261 - Destination Unreachable (type = 1) 263 - Time Exceeded (type = 3) 265 The length attribute MUST be specified when the ICMP Extension 266 Structure is appended to the above mentioned ICMP messages. 268 The length attribute represents the length of the "original datagram" 269 field. Space for the length attribute is claimed from reserved 270 octets, whose value was previously required to be zero. 272 For ICMPv4 messages, the length attribute represents 32-bit words. 273 When the length attribute is specified, the "original datagram" field 274 MUST be zero padded to the nearest 32-bit boundary. Because the 275 sixth octet of each of the impacted ICMPv4 messages was reserved for 276 future use, this octet was selected as the location of the length 277 attribute in ICMPv4. 279 For ICMPv6 messages, the length attribute represents 64-bit words. 280 When the length attribute is specified, the "original datagram" field 281 MUST be zero padded to the nearest 64-bit boundary. Because the 282 fifth octet of each of the impacted ICMPv6 messages was reserved for 283 future use, this octet was selected as the location of the length 284 attribute in ICMPv6. 286 In order the achieve backwards compatibility, when the ICMP Extension 287 Structure is appended to an ICMP message and that ICMP message 288 contains an "original datagram" field, the "original datagram" field 289 MUST contain at least 128 octets. If the original datagram did not 290 contain 128 octets, the "original datagram" field MUST be zero padded 291 to 128 octets. (See Section 5.1 for rationale.) 293 The following sub-sections depict length attribute as it has been 294 introduced to selected ICMP messages. 296 4.1. ICMPv4 Destination Unreachable 298 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Code | Checksum | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | unused | Length | Next-Hop MTU* | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Internet Header + leading octets of original datagram | 308 | | 309 | // | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 1: ICMPv4 Destination Unreachable 315 The syntax and semantics of all fields are unchanged from RFC 792. 316 However, a length attribute is added to the second word. The length 317 attribute represents length of the padded "original datagram" field, 318 measured in 32-bit words. 320 * The Next-Hop MTU field is not required in all cases. It is 321 depicted only to demonstrate that those bits are not available for 322 assignment in this memo. 324 4.2. ICMPv4 Time Exceeded 326 Figure 2 depicts the ICMPv4 Time Exceeded Message. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Code | Checksum | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | unused | Length | unused | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Internet Header + leading octets of original datagram | 336 | | 337 | // | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: ICMPv4 Time Exceeded 342 The syntax and semantics of all fields are unchanged from RFC 792, 343 except for a length attribute which is added to the second word. The 344 length attribute represents length of the padded "original datagram" 345 field, measured in 32-bit words. 347 4.3. ICMPv4 Parameter Problem 349 Figure 3 depicts the ICMPv4 Parameter Problem Message. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Code | Checksum | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Pointer | Length | unused | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Internet Header + leading octets of original datagram | 359 | | 360 | // | 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 3: ICMPv4 Parameter Problem 366 The syntax and semantics of all fields are unchanged from RFC 792, 367 except for a length attribute which is added to the second word. The 368 length attribute represents length of the padded "original datagram" 369 field, measured in 32-bit words. 371 4.4. ICMPv6 Destination Unreachable 373 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Code | Checksum | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Length | Unused | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | As much of invoking packet | 383 + as will fit without the ICMPv6 packet + 384 | exceeding the minimum IPv6 reassembly | 385 | buffer size | 387 Figure 4: ICMPv6 Destination Unreachable 389 The syntax and semantics of all fields are unchanged from RFC 4443. 390 However, a length attribute is added to the second word. The length 391 attribute represents length of the padded "original datagram" field, 392 measured in 64-bit words. 394 4.5. ICMPv6 Time Exceeded 396 Figure 5 depicts the ICMPv6 Time Exceeded Message. 398 0 1 2 3 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Code | Checksum | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Length | Unused | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | As much of invoking packet | 406 + as will fit without the ICMPv6 packet + 407 | exceeding the minimum IPv6 reassembly buffer | 408 | size | 410 Figure 5: ICMPv6 Time Exceeded 412 The syntax and semantics of all fields are unchanged from RFC 4443, 413 except for a length attribute which is added to the second word. The 414 length attribute represents length of the padded "original datagram" 415 field, measured in 64-bit words. 417 4.6. ICMP Messages That Can Be Extended 419 The ICMP Extension Structure MAY be appended to messages of the 420 following types: 422 - ICMPv4 Destination Unreachable 424 - ICMPv4 Time Exceeded 426 - ICMPv4 Parameter Problem 428 - ICMPv6 Destination Unreachable 430 - ICMPv6 Time Exceeded 432 The ICMP Extension Structure MUST NOT be appended to any of the other 433 ICMP messages mentioned in Section 4. Extensions were not defined 434 for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages 435 because these messages lack space for a length attribute. 437 ICMP messages defined in the future SHOULD indicate whether or not 438 they support the extension mechanism defined in this specification. 439 It is recommended that all new messages support extensions. 441 5. Backwards Compatibility 443 ICMP messages can be categorized as follows: 445 - Messages that do not include any ICMP extensions 447 - Messages that include non-compliant ICMP extensions 449 - Messages that includes compliant ICMP extensions 451 Any ICMP implementation can send a message that does not include 452 extensions. ICMP implementations produced prior to 1999 are not 453 known to send ICMP extensions. 455 Some ICMP implementations, produced between 1999 and the present, may 456 send a non-compliant version of ICMP extensions described in this 457 memo. Specifically, these implementations may append the ICMP 458 Extension Structure to the Time Exceeded and Destination Unreachable 459 messages. When they do this, they send exactly 128 octets 460 representing the original datagram, zero padding if required. They 461 also calculate checksums as described in this document. However, 462 they do not specify a length attribute to be associated with the 463 "original datagram" field. 465 It is assumed that ICMP implementations produced in the future will 466 send ICMP extensions that are compliant with this specification. 468 Likewise, applications that consume ICMP messages can be categorized 469 as follows: 471 - Classic applications 473 - Non-compliant applications 475 - Compliant applications 477 Classic applications do not parse extensions defined in this memo. 478 They are insensitive to the length attribute that is associated with 479 the "original datagram" field. 481 Non-compliant implementations parse the extensions defined in this 482 memo, but only in conjunction with the Time Expired and Destination 483 Unreachable messages. They require the "original datagram" field to 484 contain exactly 128 octets and are insensitive to the length 485 attribute that is associated with the "original datagram" field. 486 Non-compliant applications were produced between 1999 and the 487 present. 489 Compliant applications comply fully with the specifications of this 490 document. 492 In order to demonstrate backwards compatibility, Table 1 describes 493 how members of each application category would parse each category of 494 ICMP message. 496 +----------------+----------------+----------------+----------------+ 497 | | No Extensions | Non-compliant | Compliant | 498 | | | Extensions | Extensions | 499 +----------------+----------------+----------------+----------------+ 500 | Classic | - | Section 5.1 | Section 5.1 | 501 | Application | | | | 502 | | | | | 503 | Non-compliant | Section 5.2 | - | Section 5.3 | 504 | Application | | | | 505 | | | | | 506 | Compliant | Section 5.4 | Section 5.5 | - | 507 | Application | | | | 508 +----------------+----------------+----------------+----------------+ 510 Table 1 512 In the table above, cells that contain a dash represent the nominal 513 case and require no explanation. In the following sections, we 514 assume that the ICMP message type is "Time Exceeded". 516 5.1. Classic Application Receives ICMP Message With Extensions 518 When a classic application receives an ICMP message that includes 519 extensions, it will incorrectly interpret those extensions as being 520 part of the "original datagram" field. Fortunately, the extensions 521 are guaranteed to begin at least 128 octets beyond the beginning of 522 the "original datagram" field. So, only those ICMP applications that 523 process the 129th octet of the "original datagram" field will be 524 adversely effected. To date, only two applications falling into this 525 catagory have been identified and the degree to which they are 526 effected is minimal. 528 Some TCP stacks, when they receive an ICMP message, verify the 529 checksum in the original datagram field [I-D.ietf-tcpm-icmp-attacks]. 530 If the checksum is incorrect, the TCP stack discards the ICMP message 531 for security reasons. If the trailing octets of the original 532 datagram field are overwritten by ICMP extensions, the TCP stack will 533 discard an ICMP message that it would not otherwise have discarded. 534 The impact of this issue is considered to be minimal because many 535 ICMP messages are discarded for other reasons (e.g., ICMP filtering, 536 network congestion, checksum was incorrect because original datagram 537 field was truncated.) 539 Another theoretically possible, but highly improbably scenario occurs 540 when ICMP extensions overwrite the portion of the original datagram 541 field that represents the TCP header, causing the TCP stack to 542 operate upon the wrong TCP connection. This scenario is highly 543 unlikely because it occurs only when the TCP header appears at or 544 beyond the 128th octet of the original datagram field and then only 545 when the extensions approximate a valid TCP header. 547 5.2. Non-compliant Application Receives ICMP Message With No Extensions 549 When a non-compliant ICMPv4 application receives a message that 550 contains no extensions, the application examines the total length of 551 the ICMPv4 message. If the total ICMPv4 message length is less than 552 the length of its IP header plus 144 octets, the application 553 correctly determines that the message does not contain any 554 extensions. 556 The 144 octet sum is derived from 8 octets for the first two words of 557 the ICMPv4 Time Exceeded message, 128 octets for the "original 558 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 559 for a single ICMP Object header. All of these octets would be 560 required if extensions were present. 562 If the ICMPv4 payload contains 144 octets or more, the application 563 must examine the 137th octet to determine whether it represents a 564 valid ICMPv4 Extension Header. In order to represent a valid 565 Extension Header, it must contain a valid version number and 566 checksum. If it does not contain a valid version number and 567 checksum, the application correctly determines that the message does 568 not contain any extensions. 570 Non-compliant applications assume that the ICMPv4 Extension Structure 571 begins on the 137th octet of the Time Exceeded message, after a 128 572 octet field representing the padded "original datagram" message. 574 It is possible that a non-compliant application will parse an ICMPv4 575 message incorrectly under the following conditions: 577 - the message does not contain extensions 579 - the original datagram field contains 144 octets or more 581 - selected octets of the original datagram field represent the 582 correct values for an extension header version number and checksum 584 Although this is possible, it is very unlikely. 586 A similar analysis can be performed for ICMPv6. However, the numeric 587 constants would change as appropriate. 589 5.3. Non-compliant Application Receives ICMP Message With Compliant 590 Extensions 592 When a non-compliant application receives a message that contains 593 compliant ICMP extensions, it will parse those extensions correctly 594 only if the "original datagram" field contains exactly 128 octets. 595 This is because non-compliant applications are insensitive to the 596 length attribute that is associated with the "original datagram" 597 field. (They assume its value to be 128.) 599 Provided that the entire ICMP messages does not exceed the minimum 600 reassembly buffer size (576 octets for ICMPv4 or 1280 octets for 601 ICMPv6), there is no upper limit upon the length of the "original 602 datagram" field. However, each vendor will decide how many octets to 603 include. Those wishing to be backward compatible with non-compliant 604 TRACEROUTE implementations will include exactly 128 octets. Those 605 not requiring compatibility with non-compliant TRACEROUTE 606 applications may include more octets. 608 5.4. Compliant Application Receives ICMP Message with No Extensions 610 When a compliant application receives an ICMP message, it examines 611 the length attribute that is associated with the "original datagram" 612 field. If the length attribute is zero, the compliant application 613 MUST determine that the message contains no extensions. 615 5.5. Compliant Application Receives ICMP Message with Non-compliant 616 Extensions 618 When a compliant application receives an ICMP message, it examines 619 the length attribute that is associated with the "original datagram" 620 field. If the length attribute is zero, the compliant application 621 MUST determine that the message contains no extensions. In this 622 case, that determination is technically correct, but not backwards 623 compatible with the non-compliant implementation that originated the 624 ICMP message. 626 So, to ease transition yet encourage compliant implementation, 627 compliant TRACEROUTE implementations MAY include a non-default 628 operation mode to also interpret non-compliant responses. 629 Specifically, when a TRACEROUTE application operating in non- 630 compliant mode receives a sufficiently long ICMP message that does 631 not specify a length attribute, it will parse for a valid extension 632 header at a fixed location, assuming a 128 octet "original datagram" 633 field. If the application detects a valid version and checksum, it 634 will treat the following octets as an extension structure. 636 6. Interaction with Network Address Translation 638 The ICMP extensions defined in this memo do not interfere with 639 Network Address Translation. [RFC3022] permits traditional NAT 640 devices to modify selected fields within ICMP messages. These fields 641 include the "original datagram" field mentioned above. However, if a 642 NAT device modifies the "original datagram" field, it should modify 643 only the leading octets of that field which represent the outermost 644 IP header. Because the outermost IP header is guaranteed to be 645 contained by the first 128 octets of the "original datagram" field, 646 ICMP extensions and NAT will not interact with one another. 648 It is conceivable that a NAT implementation might overstep the 649 restrictions of RFC 3022 and overwrite the length attribute specified 650 by this memo. If a NAT implementation were to overwrite the length 651 attribute with zeros, the resulting packet will be indistinguishable 652 from a packet that was generated by a non-compliant ICMP 653 implementation. See Section 5.5 for packet details and a discussion 654 of backwards compatibility. 656 7. The ICMP Extension Structure 658 This memo proposes an optional ICMP Extension Structure that can be 659 appended to the ICMP messages referenced in Section 4.6 of this 660 document. 662 The Extension Structure contains exactly one Extension Header 663 followed by one or more objects. Having received an ICMP message 664 with extensions, application software MAY process selected objects 665 while ignoring others. The presence of an unrecognized object does 666 not imply that an ICMP message is malformed. 668 As stated above, the total length of the ICMP message, including 669 extensions, MUST NOT exceed the minimum reassembly buffer size. 670 Figure 6 depicts the ICMP Extension Header. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 |Version| (Reserved) | Checksum | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 6: ICMP Extension Header 680 The fields of the ICMP Extension Header are as follows: 682 Version: 4 bits 684 ICMP extension version number. This is version 2. 686 Reserved: 12 bits 688 Must be set to 0. 690 Checksum: 16 bits 692 The one's complement of the one's complement sum of the data 693 structure, with the checksum field replaced by zero for the 694 purpose of computing the checksum. An all-zero value means that 695 no checksum was transmitted. See Section 5.2 for a description of 696 how this field is used. 698 8. ICMP Extension Objects 700 Each extension object contains one or more 32-bit words, representing 701 an object header and payload. All object headers share a common 702 format. Figure 7 depicts the Object Header and payload. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Length | Class-Num | C-Type | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 | // (Object payload) // | 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 7: Object Header and Payload 716 An object header has the following fields: 718 Length: 16 bits 720 Length of the object, measured in octets, including the object 721 header and object payload. 723 Class-Num: 8 bits 725 Identifies object class. 727 C-Type: 8 bits 729 Identifies object sub-type. 731 9. Security Considerations 733 Upon receipt of an ICMP message, application software must check it 734 for syntactic correctness. The extension checksum must be verified. 735 Improperly specified length attributes and other syntax problems may 736 result in buffer overruns. 738 This memo does not define the conditions under which a router sends 739 an ICMP message. Therefore, it does not expose routers to any new 740 denial of service attacks. Routers may need to limit the rate at 741 which ICMP messages are sent. 743 10. IANA Considerations 745 The ICMP Extension Object header contains two 8-bit fields: The 746 Class-Num identifies the object class, and the C-Type identifies the 747 class sub-type. Sub-type values are defined relative to a specific 748 object class value, and are defined per-class. 750 IANA should establish a registry of ICMP extension objects classes 751 and class sub-types. There are no values assigned within this 752 document to maintain. Object classes 0xF7 - 0xFF are reserved for 753 private use. Object class values are assignable on a first-come- 754 first-serve. The policy for assigning sub-type values should be 755 defined in the document defining new class values. 757 11. Acknowledgments 759 Thanks to Mark Doll, Fernando Gont, Joe Touch and Christian Voiqt and 760 for their comments regarding this draft. 762 12. Testing 764 [RFC Editor: Please remove this section before publication] 766 In order to demonstrate that the ICMP extensions defined herein do 767 not adversely impact classic ICMP applications, the authors performed 768 the following experiments: 770 Experiment 1: Ping a device that sends non-compliant ICMP 771 extensions. Also ping through a devices that sends non-compliant 772 ICMP extensions. 774 Experiment 2: Traceroute to device that sends non-compliant ICMP 775 extensions. Also traceroute through a devices that sends non- 776 compliant ICMP extensions. 778 Experiment 3: Cause a TCP implementation to receive a non- 779 compliant ICMP messages with extensions that is classified as a 780 soft error. 782 Experiment 4: Cause a TCP implementation to receive a non- 783 compliant ICMP messages with extensions that is classified as a 784 hard error. 786 As defined in Section 5, a non-compliant ICMP extension is identical 787 to a fully compliant extension in every way excpet that it lacks a 788 length attribute. 790 In all cases, the classic application behaved as if the ICMP 791 extension was not present. 793 Classic applications ran under the following operating systems: 795 Windows XP 797 Macintosh OS X, OS 9 799 Solaris 801 Linux 803 Cisco IOS 805 Juniper JUNOS 807 13. References 809 13.1. Normative References 811 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 812 RFC 792, September 1981. 814 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 815 November 1990. 817 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 818 RFC 1812, June 1995. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, March 1997. 823 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 824 Address Translator (Traditional NAT)", RFC 3022, 825 January 2001. 827 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 828 Message Protocol (ICMPv6) for the Internet Protocol 829 Version 6 (IPv6) Specification", RFC 4443, March 2006. 831 13.2. Informative References 833 [I-D.atlas-icmp-unnumbered] 834 Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 835 draft-atlas-icmp-unnumbered-01 (work in progress), 836 March 2006. 838 [I-D.ietf-mpls-icmp] 839 Bonica, R., "ICMP Extensions for MultiProtocol Label 840 Switching", draft-ietf-mpls-icmp-06 (work in progress), 841 September 2006. 843 [I-D.ietf-tcpm-icmp-attacks] 844 Gont, F., "ICMP attacks against TCP", 845 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 846 October 2006. 848 [I-D.shen-icmp-routing-inst] 849 Shen, N. and E. Chen, "ICMP Extensions for Routing 850 Instances", draft-shen-icmp-routing-inst-00 (work in 851 progress), November 2006. 853 Authors' Addresses 855 Ronald P. Bonica 856 Juniper Networks 857 2251 Corporate Park Drive 858 Herndon, VA 20171 859 US 861 Email: rbonica@juniper.net 863 Der-Hwa Gan 864 Juniper Networks 865 1194 N. Mathilda Ave. 866 Sunnyvale, CA 94089 867 US 869 Email: dhg@juniper.net 871 Pekka Nikander 872 Ericsson Research Nomadic Lab 873 JORVAS FIN-02420 874 Finland 876 Email: pekka.nikander@nomadiclab.com 877 Daniel C. Tappan 878 Cisco Systems, Inc. 879 250 Apollo Drive 880 Chelmsford, MA 01824 881 US 883 Email: dan.tappan@gmail.com 885 Carlos Pignataro 886 Cisco Systems, Inc. 887 7025 Kit Creek Road 888 Research Triangle Park, N.C. 27709 889 US 891 Email: cpignata@cisco.com 893 Full Copyright Statement 895 Copyright (C) The Internet Society (2006). 897 This document is subject to the rights, licenses and restrictions 898 contained in BCP 78, and except as set forth therein, the authors 899 retain all their rights. 901 This document and the information contained herein are provided on an 902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 904 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 905 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 906 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 909 Intellectual Property 911 The IETF takes no position regarding the validity or scope of any 912 Intellectual Property Rights or other rights that might be claimed to 913 pertain to the implementation or use of the technology described in 914 this document or the extent to which any license under such rights 915 might or might not be available; nor does it represent that it has 916 made any independent effort to identify any such rights. Information 917 on the procedures with respect to rights in RFC documents can be 918 found in BCP 78 and BCP 79. 920 Copies of IPR disclosures made to the IETF Secretariat and any 921 assurances of licenses to be made available, or the result of an 922 attempt made to obtain a general license or permission for the use of 923 such proprietary rights by implementers or users of this 924 specification can be obtained from the IETF on-line IPR repository at 925 http://www.ietf.org/ipr. 927 The IETF invites any interested party to bring to its attention any 928 copyrights, patents or patent applications, or other proprietary 929 rights that may cover technology that may be required to implement 930 this standard. Please address the information to the IETF at 931 ietf-ipr@ietf.org. 933 Acknowledgment 935 Funding for the RFC Editor function is provided by the IETF 936 Administrative Support Activity (IASA).