idnits 2.17.1 draft-atlas-icmp-unnumbered-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 IETF Trust and authors 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 4, 2009) is 5257 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet A. Atlas, Ed. 3 Internet-Draft BT 4 Intended status: Standards Track R. Bonica, Ed. 5 Expires: June 7, 2010 Juniper Networks 6 C. Pignataro, Ed. 7 JR. Rivers 8 N. Shen 9 Cisco Systems 10 December 4, 2009 12 Extending ICMP for Interface and Next-hop Identification 13 draft-atlas-icmp-unnumbered-08 15 Abstract 17 This memo defines a data structure that can be appended to selected 18 ICMP messages. The ICMP extension defined herein can be used 19 identify any combination of the following: the IP interface upon 20 which a datagram arrived, the sub-IP component of an IP interface 21 upon which a datagram arrived, the IP interface through which the 22 datagram would have been for forwarded had it been forwardable, the 23 IP next hop to which the datagram would have been forwarded. 25 Devices can use this ICMP extension to identify interfaces and their 26 components by any combination of the following: ifIndex, IPv4 27 address, IPv6 address, name and MTU. ICMP-aware devices can use 28 these extensions to identify both numbered and unnumbered interfaces. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on June 7, 2010. 53 Copyright Notice 55 Copyright (c) 2009 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the BSD License. 68 Table of Contents 70 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Application to Traceroute . . . . . . . . . . . . . . . . 6 74 3.2. Policy and MTU Detection . . . . . . . . . . . . . . . . . 6 75 4. Interface Information Object . . . . . . . . . . . . . . . . . 6 76 4.1. C-type meaning in an Interface Information Object . . . . 8 77 4.2. Interface IP Address Sub-Object . . . . . . . . . . . . . 9 78 4.3. Interface Name Sub-Object . . . . . . . . . . . . . . . . 10 79 4.4. Interface Information Object Examples . . . . . . . . . . 11 80 4.5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5. Network Address Translation Considerations . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Conventions Used In This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119]. 96 2. Introduction 98 IP devices use the Internet Control Message Protocol (ICMPv4) 99 [RFC0792] (ICMPv6) [RFC4443] to convey control information. In 100 particular, when an IP device receives a datagram that it cannot 101 process, it may send an ICMP message to the datagram's originator. 102 Network operators and higher level protocols use these ICMP messages 103 to detect and diagnose network issues. 105 In the nominal case, the source address of the ICMP message 106 identifies the interface upon which the datagram arrived. However, 107 in many cases, the incoming interface is not identified by the ICMP 108 message at all. Details follow: 110 According to [RFC1812], when a router generates an ICMPv4 message, 111 the source address of that message MUST be one of the following: 113 o one of the IP addresses associated with the physical interface 114 over which the ICMPv4 message is transmitted 115 o if that interface has no IP addresses associated with it, the 116 device's router-id or host-id is used instead. 118 If all of the following conditions are true, the source address of 119 the ICMPv4 message identifies the interface upon which the original 120 datagram arrived: 122 o the device sends an ICMPv4 message through the same interface upon 123 which the original datagram was received 124 o that interface is numbered 126 However, the incoming and outgoing interfaces may be different due to 127 an asymmetric return path, which can occur due to asymmetric link 128 costs, parallel links or Equal Cost Multipath (ECMP). 130 Similarly, [RFC1122] provides guidance for source address selection 131 for multihomed IPv4 hosts. These recommendations, like those stated 132 above, do not always cause the source address of an ICMPv4 message to 133 identify the incoming interface. 135 ICMPv6 is somewhat more flexible. [RFC4443] states that for 136 responses to messages sent to non-local interface, the source address 137 must be chosen as follows: 139 o the Source Address of the ICMPv6 packet MUST be a unicast address 140 belonging to the node. The address SHOULD be chosen according to 141 the rules that would be used to select the source address for any 142 other packet originated by the node, given the destination address 143 of the packet. However, it MAY be selected in an alternative way 144 if this would lead to a more informative choice of address 145 reachable from the destination of the ICMPv6 packet. 147 When a datagram that cannot be processed arrives on an unnumbered 148 interface, neither ICMP nor ICMPv6 currently are capable of 149 identifying the incoming interface. Even when an ICMP message is 150 generated such that the ICMP source address identifies the incoming 151 interface, the receiver of that ICMP message has no way of knowing if 152 this is the case. ICMP extensions are required to explicitly 153 identify the incoming interface. 155 Using the extension defined herein, a device can explicitly identify 156 the incoming IP interface or its sub-IP components by any combination 157 of the following: 159 o ifIndex 160 o IPv4 address 161 o IPv6 address 162 o name 163 o MTU 165 The interface name SHOULD be identical to the first 63 octets of the 166 ifName, as defined in [RFC2863]. The ifIndex is also defined in 167 [RFC2863]. 169 Using the same extension, an IP device can explicitly identify by the 170 above the outgoing interface over which a datagram would have been 171 forwarded if that datagram had been deliverable. 173 The next-hop IP address, to which the datagram would have been 174 forwarded, can also be identified using this same extension. This 175 information can be used for creating a downstream map. The next-hop 176 information may not always be available. There are corner-cases 177 where it doesn't exist and there may be implementations where it is 178 not practical to provide this information. This specification 179 provides an encoding for providing the next-hop IP address when it is 180 available. 182 The extension defined herein use the ICMP multi-part message 183 framework defined in [RFC4884]. The same backward compatibility 184 issues that apply to [RFC4884] apply to this extension. 186 3. Applications 188 3.1. Application to Traceroute 190 ICMP extensions defined in this memo provide additional capability to 191 traceroute. An enhanced traceroute application, like older 192 implementations, identifies nodes that a datagram visited en route to 193 its destination. It differs from older implementations in that it 194 can explicitly identify the following at each node: 196 o the IP interface upon which a datagram arrived 197 o the sub-IP component of an IP interface upon which a datagram 198 arrived 199 o the IP interface through which the datagram would have been for 200 forwarded had it been forwardable 201 o the IP next hop to which the datagram would have been forwarded 203 Enhanced traceroute applications can identify the above listed 204 entities by: 206 o ifIndex 207 o IPv4 address 208 o IPv6 address 209 o name 210 o MTU 212 3.2. Policy and MTU Detection 214 A general application would be to identify which outgoing interface 215 triggered a given function for the original packet. For example, if 216 an access control list (ACL) drops the packet and Dest Unreachable/ 217 Admin Prohibited denies the packet, being able to identify the 218 outgoing interface might be useful. Another example would be to 219 support PMTU, since this would allow identification of which outgoing 220 interface can't support a given MTU size. For example, knowledge of 221 the problematic interface would allow an informed request for 222 reconfiguration of the MTU of that interface. 224 4. Interface Information Object 226 This section defines the Interface Information Object, an ICMP 227 extension object with a Class-Num of 2 (pending IANA assignment) that 228 can be appended to the following messages: 230 o ICMPv4 Time Exceeded 231 o ICMPv4 Destination Unreachable 232 o ICMPv4 Parameter Problem 233 o ICMPv6 Time Exceeded 234 o ICMPv6 Destination Unreachable 236 For reasons described in [RFC4884], this extension cannot be appended 237 to any of the currently defined ICMPv4 or ICMPv6 messages other than 238 those listed above. 240 The extension defined herein MAY be appended to any of the above 241 listed messages and SHOULD be appended whenever required to identify 242 an unnumbered interface and when local policy or security 243 considerations do not supersede this requirement. 245 A single ICMP message can contain as few as zero and as many as four 246 instances of the Interface Information Object. A single instance of 247 the Interface Information object can provide information regarding 248 any one of the following interface roles: 250 o the IP interface upon which a datagram arrived 251 o the sub-IP component of an IP interface upon which a datagram 252 arrived 253 o the IP interface through which the datagram would have been for 254 forwarded had it been forwardable 255 o the IP next hop to which the datagram would have been forwarded 257 The following are examples of sub-IP components of IP interfaces upon 258 which a datagram might arrive: 260 o Ethernet Link Aggregation Group Member 261 o Multilink PPP bundle member 262 o Multilink frame relay bundle member 264 To minimize the number of octets required for this extension, there 265 are four different pieces of information that can appear in an 266 Interface Information Object. 268 1. The ifIndex of the interface of interest MAY be included. This 269 is the 32-bit ifIndex assigned to the interface by the device as 270 specified by the Interfaces Group MIB [RFC2863]. 271 2. An IP Address Sub-Object MAY be included if either of the 272 following conditions are true: a) the eliciting datagram is IPv4 273 and the identified interface has at least one IPv4 address 274 associated with it, or b) the eliciting datagram is IPv6 and the 275 identified interface has at least one IPv6 address associated 276 with it. The IP Address Sub-Object is described in Section 4.2 277 of this memo. 279 3. An Interface Name Sub-Object, containing a string of no more than 280 63 octets, MAY be included. That string, as specified in Section 281 Section 4.3, is the interface name and SHOULD be the MIB-II 282 ifName [RFC2863], but MAY be some other human-meaningful name of 283 the interface. 284 4. A 32-bit unsigned integer reflecting the MTU MAY be included. 286 4.1. C-type meaning in an Interface Information Object 288 For this object, the c-type is used to indicate both the role of the 289 interface and the information that is included. This is illustrated 290 below. 292 Bit 0 1 2 3 4 5 6 7 293 +-------+-------+-------+-------+-------+-------+---------+-------+ 294 | Interface Role| Rsvd1 | Rsvd2 | index | IPAddr| name | MTU | 295 +-------+-------+-------+-------+-------+-------+---------+-------+ 297 Figure 1: C-Type for the Interface Information Object 299 The following are bit-field definitions for C-type: 301 Interface Role (bits 0-1): These bits indicates the role of the 302 interface being identified. The enumerated values are given below: 304 0: This object describes the IP interface upon which a datagram 305 arrived 306 1: This object describes the sub-IP component of an IP interface 307 upon which a datagram arrived 308 2: This object describes the IP interface through which the 309 datagram would have been for forwarded had it been forwardable 310 3: This object describes the IP next hop to which the datagram 311 would have been forwarded 313 Reserved 1 (bit 2): This bit is reserved for future use and MUST be 314 set to 0 and MUST be ignored on receipt. 316 Reserved 2 (bit 3): This bit is reserved for future use and MUST be 317 set to 0 and MUST be ignored on receipt. 319 ifIndex (bit 4) : When set, the 32-bit ifIndex of the interface is 320 included. When clear, the ifIndex is not included. 322 IP Addr (bit 5) : When set, an IP Address Sub-Object is present. 323 When clear, an IP Address Sub-Object is not present. The IP Address 324 Sub-Object is described in Section 4.2 of this memo. 326 Interface Name (bit 6): When set, an Interface Name Sub-object is 327 included. When clear, it is not included. The Name Sub-object is 328 described in Section 4.3 of this memo. 330 MTU (bit 7): When set, a 32-bit integer representing the MTU is 331 present. When clear, this 32-bit integer is not present. 333 The information included does not self-identify, so this 334 specification defines a specific ordering for sending the information 335 which must be followed. 337 If bit 4 (ifIndex) is set, then the 32-bit ifIndex MUST be sent 338 first. If bit 5 (IP Address) is set, an IP Address Sub-Object MUST 339 be sent next. If bit 6 (Name) is set, an Interface Name Sub-object 340 MUST be sent next. If bit 7 is set, an MTU MUST be sent next. The 341 information order is thus: ifIndex, IP Address Sub-Object, Interface 342 Name Sub-Object and MTU. Any or all pieces of information may be 343 present or absent, as indicated by the c-type. Any data that follows 344 these optional pieces of information MUST be ignored. 346 It is valid (though pointless until additional bits are assigned by 347 IANA) to receive an Interface Information Object where bits 4, 5, 6 348 and 7 are all 0; this MUST NOT generate a warning or error. 350 4.2. Interface IP Address Sub-Object 352 The figure below depicts the Interface Address Sub-Object: 354 0 31 355 +-------+-------+-------+-------+ 356 | AFI | Reserved | 357 +-------+-------+-------+-------+ 358 | IP Address .... 360 Figure 2: Interface Address Sub-Object 362 The IP Address Sub-Object contains the following fields: 364 o Address Family Identifier (AFI): This 16-bit bit field identifies 365 the type of address represented by the IP Address field. It also 366 determines the length of that field and the length of the entire 367 sub-object. Values for this field represent a subset of values 368 found in the IANA registry of Address Family Numbers 369 ("http://www.iana.org/assignments/address-family-numbers"). Valid 370 values are 1 (representing a 32-bit IPv4 address) and 2 371 (representing a 128-bit IPv6 address). 372 o Reserved: This 16-bit field MUST be set to zero and ignored upon 373 receipt. 374 o IP Address: This variable length field represents and IP address 375 associated with the identified interface. 377 If the eliciting datagram was IPv4, the IP Interface Sub-object MUST 378 represent an IPv4 address. Likewise, if the eliciting datagram was 379 IPv6, the IP Interface Sub-object MUST represent an IPv6 address. 381 4.3. Interface Name Sub-Object 383 The figure below depicts the Interface Name Sub-Object: 385 octet 0 1 63 386 +---------+-----------................-----------------+ 387 | length | interface name octets 1-63 | 388 +---------+-----------................-----------------+ 390 Figure 3: Interface Name Sub-Object 392 The Interface Name Sub-Object MUST have a length that is a multiple 393 of 4 octets and MUST NOT exceed 64 octets. 395 The Length field represents the length of the Interface Name Sub- 396 object, including the length and the interface name in octets. The 397 maximum valid length is 64 octets. The length is constrained to 398 ensure there is space for the start of the original packet and 399 additional information. 401 The second field contains the human-readable interface name. The 402 interface name SHOULD be the full MIB-II ifName [RFC2863], if less 403 than 64 octets, or the first 63 octets of the ifName, if the ifName 404 is longer. The interface name MAY be some other human-meaningful 405 name of the interface. It is useful to provide the ifName for cross- 406 correlation with other MIB information and for human-reader 407 familiarity. The interface name MUST be padded with ASCII NULL 408 characters if the object would not otherwise terminate on a 4-octet 409 boundary. 411 The interface name MUST be represented in the UTF-8 charset [RFC3629] 412 using the Default Language [RFC2277]. 414 4.4. Interface Information Object Examples 416 Figure 4 shows a full ICMPv4 Time Exceeded message, including the 417 Interface Information Object, which must be preceded by an ICMP 418 Extension Structure Header and an ICMP Object Header. Both are 419 defined in [RFC4884]. 421 Although examples show an Interface Name Sub-object of length 64, 422 this is only for illustration and depicts the maximum allowable 423 length. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Code | Checksum | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | unused | Length | unused | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Internet Header + leading octets of original datagram | 433 | | 434 | // | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Ver=2 | (Reserved) | Checksum | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Length |Class-Num=2 | C-Type=00001010b | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Interface ifIndex | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Interface Name Sub-Object, 32-bit word 1 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 ... ... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Interface Name Sub-Object, 32-bit word 16 | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 4: ICMPv4 Time Exceeded message with Interface Information 451 Object 453 Figure 5 depicts an Interface Information Object representing an 454 incoming interface identified by iFIndex and Name. 456 Class-Num = 2 457 C-Type = 00001010b // Indicates incoming interface 458 Length = 72 (4 + 4 + 64) 460 0 1 2 3 461 +--------------+--------------+--------------+--------------+ 462 | Interface ifIndex | 463 +--------------+--------------+--------------+--------------+ 464 | Length | Name, word 1 | 465 +--------------+--------------+--------------+--------------+ 466 ... ... 467 +--------------+--------------+--------------+--------------+ 468 | Name , word 16 | 469 +--------------+--------------+--------------+--------------+ 471 Figure 5: Incoming Interface: By IfIndex and Name 473 Figure 6 depicts an Interface Information Object representing an 474 incoming interface identified by iFIndex, IPv4 Address and Name. 476 C-Type = 00001110b // Indicates incoming interface 477 Length = 80 (4 + 4 + 8 + 64) 479 0 1 2 3 480 +--------------+--------------+--------------+--------------+ 481 | Interface ifIndex | 482 +--------------+--------------+--------------+--------------+ 483 | AFI | Reserved | 484 +--------------+--------------+--------------+--------------+ 485 | IPv4 address | 486 +--------------+--------------+--------------+--------------+ 487 | Length | Name, word 1 | 488 +--------------+--------------+--------------+--------------+ 489 ... ... 490 +--------------+--------------+--------------+--------------+ 491 | Name , word 16 | 492 +--------------+--------------+--------------+--------------+ 494 Figure 6: Incoming Interface: by IfIndex, IPv4 Address and Name 496 Figure 7 depicts an Interface Information Object representing an 497 incoming interface identified by iFIndex and IPv6 Address. 499 C-Type = 00001100b // Indicates incoming interface 500 Length = 28 (4 + 4 + 20) 502 0 1 2 3 503 +--------------+--------------+--------------+--------------+ 504 | Interface ifIndex | 505 +--------------+--------------+--------------+--------------+ 506 | AFI | Reserved | 507 +--------------+--------------+--------------+--------------+ 508 | IPv6 address, 32-bit word 1 | 509 +--------------+--------------+--------------+--------------+ 510 | IPv6 address, 32-bit word 2 | 511 +--------------+--------------+--------------+--------------+ 512 | IPv6 address, 32-bit word 3 | 513 +--------------+--------------+--------------+--------------+ 514 | IPv6 address, 32-bit word 4 | 515 +--------------+--------------+--------------+--------------+ 517 Figure 7: Incoming Interface: By Index and IPv6 Address 519 Figure 8 depicts an Interface Information Object representing an 520 outgoing interface identified by iFIndex and Name. 522 Class-Num = 2 523 C-Type = 10001010b // Indicates outgoing interface 524 Length = 72 (4 + 4 + 64) 526 0 1 2 3 527 +--------------+--------------+--------------+--------------+ 528 | Interface ifIndex | 529 +--------------+--------------+--------------+--------------+ 530 | Length | Name, word 1 | 531 +--------------+--------------+--------------+--------------+ 532 ... ... 533 +--------------+--------------+--------------+--------------+ 534 | Name , word 16 | 535 +--------------+--------------+--------------+--------------+ 537 Figure 8: Outgoing Interface: By IfIndex and Name 539 4.5. Usage 541 Multiple Interface Information Objects MAY be included within a 542 single ICMP message, provided that each Interface Information Object 543 specifies a unique role. A single ICMP message MUST NOT contain two 544 Interface Information Objects that specify the same role. 546 IfIndex, MTU and name information MAY be included whenever it is 547 available; more than one instance of each of these three information 548 elements MUST NOT be included per Interface Information Object. 550 A single instance of IP Address information MAY be included only in 551 the following circumstances: 553 o if the eliciting datagram is IPv4 and an IPv4 address is 554 associated with the identified interface. In this case, if an IP 555 Address Sub-Object is included, it must specify an IPv4 address. 556 o if the eliciting datagram is IPv6 and an IPv6 address is 557 associated with the identified interface. In this case, if an IP 558 Address Sub-Object is included, it must specify an IPv6 address. 560 An ICMP message that does not conform to these rules and contains 561 multiple instances of the same information is considered illegal; 562 specifically, an ICMP message containing more than one Interface 563 Information Object with the same role, as well as an ICMP message 564 containing a duplicate information element in a given role are 565 considered illegal. If such illegal ICMP message is received, it 566 MUST be silently discarded. 568 5. Network Address Translation Considerations 570 [RFC5508] encourages Traditional IP Network Address Translators 571 (Traditional NATs, see [RFC3022]) to support ICMP extension objects. 572 This document defines an ICMP extension that includes IP addresses 573 and therefore contains realm specific information, and consequently 574 describes possible NAT behaviors in presence of these extensions. 576 NAT devices MUST NOT translate or overwrite the ICMP extensions 577 described herein. They MAY either remove the extension entirely or 578 pass it unchanged. 580 It is conceivable that a NAT device might translate an ICMP header 581 without translating the extension defined herein. In this case, the 582 ICMP message might contain two instances of the same address, one 583 translated and the other untranslated. Therefore, application 584 developers should not assume addresses in the extension are of the 585 same realm as the addresses in the datagram's header. 587 It also is conceivable that a NAT device might translate an ICMPv4 588 message into ICMPv6 or vice versa. If that were to occur, 589 applications might receive ICMPv6 messages that contain IP Address 590 Sub-Objects that specify IPv4 addresses. Likewise, applications 591 might receive ICMPv4 messages that contain IP Address Sub-Objects 592 that specify IPv6 addresses. 594 6. Security Considerations 596 This extension can provide the user of traceroute with additional 597 network information that is not currently available. Implementations 598 SHOULD provide configuration switches that suppress generation this 599 extension based upon role (i.e., incoming interface, outgoing 600 interface, sub-ip data). Implementations SHOULD also provide 601 configuration switches that conceal various types of information 602 (e.g., ifIndex, interface name). 604 It may be desirable to provide this information to a particular 605 network's operators and not to others. If such policy controls are 606 desirable, then an implementation could determine what sub-objects to 607 include based upon the destination IP address of the ICMP message 608 that will contain the sub-objects. The implementation of policy 609 controls could also be based upon the mechanisms described in 610 [I-D.shen-udp-traceroute-ext] for those limited cases supported. 612 For instance, the IP address may be included for all potential 613 recipients. The ifIndex and interface name could be included as well 614 if the destination IP address is a management address of the network 615 that has administrative control of the router. 617 Another example use case would be where the detailed information in 618 these extensions may be provided to ICMP destinations within the 619 local administrative domain, but only traditional information is 620 provided to 'external' or untrusted ICMP destinations. 622 The intended field of use for the extensions defined in this document 623 is administrative debugging and troubleshooting. The extensions 624 herein define supply additional information in ICMP responses. These 625 mechanisms are not intended to be used in non-debugging applications. 627 This document does not specify an authentication mechanism for the 628 extension that it defines. Application developers should be aware 629 that ICMP messages and their contents are easily spoofed. 631 7. IANA Considerations 633 IANA should reserve from the ICMP Extension Object Classes registry 634 reachable at http://www.iana.org/assignments/icmp-parameters: 2 for 635 the Interface Information Object. 637 From the Interface ID Object's c-type, IANA should reserve as 638 follows: 640 o Bit 0-1: Interface Role field 641 o Bit 2: Unallocated - allocatable with Standards Action 642 o Bit 3: Unallocated - allocatable with Standards Action 643 o Bit 4: ifIndex included 644 o Bit 5: IP Address Sub-object included 645 o Bit 6: Name Sub-object included 646 o Bit 7: MTU included 648 IANA should reserve the following values for Interface Role: 650 o Value 0: Incoming IP Interface 651 o Value 1: Sub-IP Component of Incoming IP Interface 652 o Value 2: Outgoing IP Interface 653 o Value 3: IP Next-hop 655 8. Acknowledgments 657 The authors would like to thank Sasha Vainshtein, Enke Chen and Joe 658 Touch for their comments and suggestions. They would also like to 659 thank Dr. Ali Assefi. 661 9. References 663 9.1. Normative References 665 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 666 RFC 792, September 1981. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 672 MIB", RFC 2863, June 2000. 674 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 675 10646", STD 63, RFC 3629, November 2003. 677 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 678 Message Protocol (ICMPv6) for the Internet Protocol 679 Version 6 (IPv6) Specification", RFC 4443, March 2006. 681 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 682 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 683 April 2007. 685 9.2. Informative References 687 [I-D.shen-udp-traceroute-ext] 688 Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP 689 Traceroute Message Extension", 690 draft-shen-udp-traceroute-ext-01 (work in progress), 691 June 2008. 693 [RFC1122] Braden, R., "Requirements for Internet Hosts - 694 Communication Layers", STD 3, RFC 1122, October 1989. 696 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 697 RFC 1812, June 1995. 699 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 700 Languages", BCP 18, RFC 2277, January 1998. 702 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 703 Address Translator (Traditional NAT)", RFC 3022, 704 January 2001. 706 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 707 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 708 April 2009. 710 Authors' Addresses 712 Alia K. Atlas (editor) 713 BT 715 Email: alia.atlas@bt.com 717 Ronald P. Bonica (editor) 718 Juniper Networks 719 2251 Corporate Park Drive 720 Herndon, VA 20171 721 USA 723 Email: rbonica@juniper.net 724 Carlos Pignataro (editor) 725 Cisco Systems 726 7200-12 Kit Creek Road 727 PO Box 14987 728 Research Triangle Park, NC 27709 729 USA 731 Email: cpignata@cisco.com 733 J.R. Rivers 734 Cisco Systems 735 225 West Tasman Drive 736 San Jose, CA 95134 737 USA 739 Email: jrrivers@cisco.com 741 Naiming Shen 742 Cisco Systems 743 225 West Tasman Drive 744 San Jose, CA 95134 745 USA 747 Email: naiming@cisco.com