idnits 2.17.1 draft-atlas-icmp-unnumbered-09.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 6, 2010) is 5223 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: July 10, 2010 Juniper Networks 6 C. Pignataro, Ed. 7 Cisco Systems 8 JR. Rivers 10 N. Shen 11 Cisco Systems 12 January 6, 2010 14 Extending ICMP for Interface and Next-hop Identification 15 draft-atlas-icmp-unnumbered-09 17 Abstract 19 This memo defines a data structure that can be appended to selected 20 ICMP messages. The ICMP extension defined herein can be used to 21 identify any combination of the following: the IP interface upon 22 which a datagram arrived, the sub-IP component of an IP interface 23 upon which a datagram arrived, the IP interface through which the 24 datagram would have been forwarded had it been forwardable, the IP 25 next hop to which the datagram would have been forwarded. 27 Devices can use this ICMP extension to identify interfaces and their 28 components by any combination of the following: ifIndex, IPv4 29 address, IPv6 address, name and MTU. ICMP-aware devices can use 30 these extensions to identify both numbered and unnumbered interfaces. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on July 10, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3.1. Application to Traceroute . . . . . . . . . . . . . . . . 6 88 3.2. Policy and MTU Detection . . . . . . . . . . . . . . . . . 6 89 4. Interface Information Object . . . . . . . . . . . . . . . . . 6 90 4.1. C-type meaning in an Interface Information Object . . . . 8 91 4.2. Interface IP Address Sub-Object . . . . . . . . . . . . . 9 92 4.3. Interface Name Sub-Object . . . . . . . . . . . . . . . . 10 93 4.4. Interface Information Object Examples . . . . . . . . . . 11 94 4.5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5. Network Address Translation Considerations . . . . . . . . . . 14 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 104 1. Conventions Used In This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [RFC2119]. 110 2. Introduction 112 IP devices use the Internet Control Message Protocol (ICMPv4) 113 [RFC0792] (ICMPv6) [RFC4443] to convey control information. In 114 particular, when an IP device receives a datagram that it cannot 115 process, it may send an ICMP message to the datagram's originator. 116 Network operators and higher level protocols use these ICMP messages 117 to detect and diagnose network issues. 119 In the simplest case, the source address of the ICMP message 120 identifies the interface upon which the datagram arrived. However, 121 in many cases, the incoming interface is not identified by the ICMP 122 message at all. Details follow: 124 According to [RFC1812], when a router generates an ICMPv4 message, 125 the source address of that message MUST be one of the following: 127 o one of the IP addresses associated with the physical interface 128 over which the ICMPv4 message is transmitted 129 o if that interface has no IP addresses associated with it, the 130 device's router-id or host-id is used instead. 132 If all of the following conditions are true, the source address of 133 the ICMPv4 message identifies the interface upon which the original 134 datagram arrived: 136 o the device sends an ICMPv4 message through the same interface upon 137 which the original datagram was received 138 o that interface is numbered 140 However, the incoming and outgoing interfaces may be different due to 141 an asymmetric return path, which can occur due to asymmetric link 142 costs, parallel links or Equal Cost Multipath (ECMP). 144 Similarly, [RFC1122] provides guidance for source address selection 145 for multihomed IPv4 hosts. These recommendations, like those stated 146 above, do not always cause the source address of an ICMPv4 message to 147 identify the incoming interface. 149 ICMPv6 is somewhat more flexible. [RFC4443] states that for 150 responses to messages sent to a non-local interface, the source 151 address must be chosen as follows: 153 o the Source Address of the ICMPv6 packet MUST be a unicast address 154 belonging to the node. The address SHOULD be chosen according to 155 the rules that would be used to select the source address for any 156 other packet originated by the node, given the destination address 157 of the packet. However, it MAY be selected in an alternative way 158 if this would lead to a more informative choice of address 159 reachable from the destination of the ICMPv6 packet. 161 When a datagram that cannot be processed arrives on an unnumbered 162 interface, neither ICMP nor ICMPv6 is currently capable of 163 identifying the incoming interface. Even when an ICMP message is 164 generated such that the ICMP source address identifies the incoming 165 interface, the receiver of that ICMP message has no way of knowing if 166 this is the case. ICMP extensions are required to explicitly 167 identify the incoming interface. 169 Using the extension defined herein, a device can explicitly identify 170 the incoming IP interface or its sub-IP components by any combination 171 of the following: 173 o ifIndex 174 o IPv4 address 175 o IPv6 address 176 o name 177 o MTU 179 The interface name SHOULD be identical to the first 63 octets of the 180 ifName, as defined in [RFC2863]. The ifIndex is also defined in 181 [RFC2863]. 183 Using the same extension, an IP device can explicitly identify by the 184 above the outgoing interface over which a datagram would have been 185 forwarded if that datagram had been deliverable. 187 The next-hop IP address, to which the datagram would have been 188 forwarded, can also be identified using this same extension. This 189 information can be used for creating a downstream map. The next-hop 190 information may not always be available. There are corner-cases 191 where it doesn't exist and there may be implementations where it is 192 not practical to provide this information. This specification 193 provides an encoding for providing the next-hop IP address when it is 194 available. 196 The extension defined herein use the ICMP multi-part message 197 framework defined in [RFC4884]. The same backward compatibility 198 issues that apply to [RFC4884] apply to this extension. 200 3. Applications 202 3.1. Application to Traceroute 204 ICMP extensions defined in this memo provide additional capability to 205 traceroute. An enhanced traceroute application, like older 206 implementations, identifies nodes that a datagram visited en route to 207 its destination. It differs from older implementations in that it 208 can explicitly identify the following at each node: 210 o the IP interface upon which a datagram arrived 211 o the sub-IP component of an IP interface upon which a datagram 212 arrived 213 o the IP interface through which the datagram would have been 214 forwarded had it been forwardable 215 o the IP next hop to which the datagram would have been forwarded 217 Enhanced traceroute applications can identify the above listed 218 entities by: 220 o ifIndex 221 o IPv4 address 222 o IPv6 address 223 o name 224 o MTU 226 The ifIndex can be utilized within a management domain to map to an 227 actual interface, but it is also valuable in public applications. 228 The ifIndex can be used as an opaque token to discern whether two 229 ICMP messages generated from the same router involve the same 230 interface or not. 232 3.2. Policy and MTU Detection 234 A general application would be to identify which outgoing interface 235 triggered a given function for the original packet. For example, if 236 an access control list (ACL) drops the packet and Dest Unreachable/ 237 Admin Prohibited denies the packet, being able to identify the 238 outgoing interface might be useful. Another example would be to 239 support PMTU, since this would allow identification of which outgoing 240 interface can't support a given MTU size. For example, knowledge of 241 the problematic interface would allow an informed request for 242 reconfiguration of the MTU of that interface. 244 4. Interface Information Object 246 This section defines the Interface Information Object, an ICMP 247 extension object with a Class-Num of 2 (pending IANA assignment) that 248 can be appended to the following messages: 250 o ICMPv4 Time Exceeded 251 o ICMPv4 Destination Unreachable 252 o ICMPv4 Parameter Problem 253 o ICMPv6 Time Exceeded 254 o ICMPv6 Destination Unreachable 256 For reasons described in [RFC4884], this extension cannot be appended 257 to any of the currently defined ICMPv4 or ICMPv6 messages other than 258 those listed above. 260 The extension defined herein MAY be appended to any of the above 261 listed messages and SHOULD be appended whenever required to identify 262 an unnumbered interface and when local policy or security 263 considerations do not supersede this requirement. 265 A single ICMP message can contain as few as zero and as many as four 266 instances of the Interface Information Object. It is illegal if it 267 contains more than four instances, because it means that an interface 268 role is used more than once (see Section 4.5). 270 A single instance of the Interface Information object can provide 271 information regarding any one of the following interface roles: 273 o the IP interface upon which a datagram arrived 274 o the sub-IP component of an IP interface upon which a datagram 275 arrived 276 o the IP interface through which the datagram would have been 277 forwarded had it been forwardable 278 o the IP next hop to which the datagram would have been forwarded 280 The following are examples of sub-IP components of IP interfaces upon 281 which a datagram might arrive: 283 o Ethernet Link Aggregation Group Member 284 o Multilink PPP bundle member 285 o Multilink frame relay bundle member 287 To minimize the number of octets required for this extension, there 288 are four different pieces of information that can appear in an 289 Interface Information Object. 291 1. The ifIndex of the interface of interest MAY be included. This 292 is the 32-bit ifIndex assigned to the interface by the device as 293 specified by the Interfaces Group MIB [RFC2863]. 295 2. An IP Address Sub-Object MAY be included if either of the 296 following conditions is true: a) the eliciting datagram is IPv4 297 and the identified interface has at least one IPv4 address 298 associated with it, or b) the eliciting datagram is IPv6 and the 299 identified interface has at least one IPv6 address associated 300 with it. The IP Address Sub-Object is described in Section 4.2 301 of this memo. 302 3. An Interface Name Sub-Object, containing a string of no more than 303 63 octets, MAY be included. That string, as specified in 304 Section 4.3, is the interface name and SHOULD be the MIB-II 305 ifName [RFC2863], but MAY be some other human-meaningful name of 306 the interface. 307 4. A 32-bit unsigned integer reflecting the MTU MAY be included. 309 4.1. C-type meaning in an Interface Information Object 311 For this object, the c-type [RFC4884] is used to indicate both the 312 role of the interface and the information that is included. This is 313 illustrated in Figure 1. 315 Bit 0 1 2 3 4 5 6 7 316 +-------+-------+-------+-------+-------+-------+-------+-------+ 317 | Interface Role| Rsvd1 | Rsvd2 |ifIndex| IPAddr| name | MTU | 318 +-------+-------+-------+-------+-------+-------+-------+-------+ 320 Figure 1: C-Type for the Interface Information Object 322 The following are bit-field definitions for C-type: 324 Interface Role (bits 0-1): These bits indicates the role of the 325 interface being identified. The enumerated values are given below: 327 0: This object describes the IP interface upon which a datagram 328 arrived 329 1: This object describes the sub-IP component of an IP interface 330 upon which a datagram arrived 331 2: This object describes the IP interface through which the 332 datagram would have been forwarded had it been forwardable 333 3: This object describes the IP next hop to which the datagram 334 would have been forwarded 336 Reserved 1 (bit 2): This bit is reserved for future use and MUST be 337 set to 0 and MUST be ignored on receipt. 339 Reserved 2 (bit 3): This bit is reserved for future use and MUST be 340 set to 0 and MUST be ignored on receipt. 342 ifIndex (bit 4) : When set, the 32-bit ifIndex of the interface is 343 included. When clear, the ifIndex is not included. 345 IP Addr (bit 5) : When set, an IP Address Sub-Object is present. 346 When clear, an IP Address Sub-Object is not present. The IP Address 347 Sub-Object is described in Section 4.2 of this memo. 349 Interface Name (bit 6): When set, an Interface Name Sub-object is 350 included. When clear, it is not included. The Name Sub-object is 351 described in Section 4.3 of this memo. 353 MTU (bit 7): When set, a 32-bit integer representing the MTU is 354 present. When clear, this 32-bit integer is not present. 356 The information included does not self-identify, so this 357 specification defines a specific ordering for sending the information 358 which must be followed. 360 If bit 4 (ifIndex) is set, then the 32-bit ifIndex MUST be sent 361 first. If bit 5 (IP Address) is set, an IP Address Sub-Object MUST 362 be sent next. If bit 6 (Name) is set, an Interface Name Sub-object 363 MUST be sent next. If bit 7 is set, an MTU MUST be sent next. The 364 information order is thus: ifIndex, IP Address Sub-Object, Interface 365 Name Sub-Object and MTU. Any or all pieces of information may be 366 present or absent, as indicated by the c-type. Any data that follows 367 these optional pieces of information MUST be ignored. 369 It is valid (though pointless until additional bits are assigned by 370 IANA) to receive an Interface Information Object where bits 4, 5, 6 371 and 7 are all 0; this MUST NOT generate a warning or error. 373 4.2. Interface IP Address Sub-Object 375 Figure 2 depicts the Interface Address Sub-Object: 377 0 31 378 +-------+-------+-------+-------+ 379 | AFI | Reserved | 380 +-------+-------+-------+-------+ 381 | IP Address .... 383 Figure 2: Interface Address Sub-Object 385 The IP Address Sub-Object contains the following fields: 387 o Address Family Identifier (AFI): This 16-bit bit field identifies 388 the type of address represented by the IP Address field. It also 389 determines the length of that field and the length of the entire 390 sub-object. Values for this field represent a subset of values 391 found in the IANA registry of Address Family Numbers (reachable at 392 ). Valid 393 values are 1 (representing a 32-bit IPv4 address) and 2 394 (representing a 128-bit IPv6 address). 395 o Reserved: This 16-bit field MUST be set to zero and ignored upon 396 receipt. 397 o IP Address: This variable length field represents and IP address 398 associated with the identified interface. 400 If the eliciting datagram was IPv4, the IP Interface Sub-object MUST 401 represent an IPv4 address. Likewise, if the eliciting datagram was 402 IPv6, the IP Interface Sub-object MUST represent an IPv6 address. 404 4.3. Interface Name Sub-Object 406 Figure 3 depicts the Interface Name Sub-Object: 408 octet 0 1 63 409 +--------+-----------................-----------------+ 410 | length | interface name octets 1-63 | 411 +--------+-----------................-----------------+ 413 Figure 3: Interface Name Sub-Object 415 The Interface Name Sub-Object MUST have a length that is a multiple 416 of 4 octets and MUST NOT exceed 64 octets. 418 The Length field represents the length of the Interface Name Sub- 419 object, including the length and the interface name in octets. The 420 maximum valid length is 64 octets. The length is constrained to 421 ensure there is space for the start of the original packet and 422 additional information. 424 The second field contains the human-readable interface name. The 425 interface name SHOULD be the full MIB-II ifName [RFC2863], if less 426 than 64 octets, or the first 63 octets of the ifName, if the ifName 427 is longer. The interface name MAY be some other human-meaningful 428 name of the interface. It is useful to provide the ifName for cross- 429 correlation with other MIB information and for human-reader 430 familiarity. The interface name MUST be padded with ASCII NULL 431 characters if the object would not otherwise terminate on a 4-octet 432 boundary. 434 The interface name MUST be represented in the UTF-8 charset [RFC3629] 435 using the Default Language [RFC2277]. 437 4.4. Interface Information Object Examples 439 Figure 4 shows a full ICMPv4 Time Exceeded message, including the 440 Interface Information Object, which must be preceded by an ICMP 441 Extension Structure Header and an ICMP Object Header. Both are 442 defined in [RFC4884]. 444 Although examples show an Interface Name Sub-object of length 64, 445 this is only for illustration and depicts the maximum allowable 446 length. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Code | Checksum | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | unused | Length | unused | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Internet Header + leading octets of original datagram | 456 | | 457 | // | 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Ver=2 | (Reserved) | Checksum | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Length |Class-Num=2 | C-Type=00001010b | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Interface ifIndex | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Interface Name Sub-Object, 32-bit word 1 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 ... ... 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Interface Name Sub-Object, 32-bit word 16 | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 4: ICMPv4 Time Exceeded message with Interface Information 474 Object 476 Figure 5 depicts an Interface Information Object representing an 477 incoming interface identified by iFIndex and Name. 479 Class-Num = 2 480 C-Type = 00001010b // Indicates incoming interface 481 Length = 72 (4 + 4 + 64) 483 0 1 2 3 484 +--------------+--------------+--------------+--------------+ 485 | Interface ifIndex | 486 +--------------+--------------+--------------+--------------+ 487 | Length | Name, word 1 | 488 +--------------+--------------+--------------+--------------+ 489 ... ... 490 +--------------+--------------+--------------+--------------+ 491 | Name , word 16 | 492 +--------------+--------------+--------------+--------------+ 494 Figure 5: Incoming Interface: By IfIndex and Name 496 Figure 6 depicts an Interface Information Object representing an 497 incoming interface identified by iFIndex, IPv4 Address and Name. 499 Class-Num = 2 500 C-Type = 00001110b // Indicates incoming interface 501 Length = 80 (4 + 4 + 8 + 64) 503 0 1 2 3 504 +--------------+--------------+--------------+--------------+ 505 | Interface ifIndex | 506 +--------------+--------------+--------------+--------------+ 507 | AFI | Reserved | 508 +--------------+--------------+--------------+--------------+ 509 | IPv4 address | 510 +--------------+--------------+--------------+--------------+ 511 | Length | Name, word 1 | 512 +--------------+--------------+--------------+--------------+ 513 ... ... 514 +--------------+--------------+--------------+--------------+ 515 | Name , word 16 | 516 +--------------+--------------+--------------+--------------+ 518 Figure 6: Incoming Interface: by IfIndex, IPv4 Address and Name 520 Figure 7 depicts an Interface Information Object representing an 521 incoming interface identified by iFIndex and IPv6 Address. 523 Class-Num = 2 524 C-Type = 00001100b // Indicates incoming interface 525 Length = 28 (4 + 4 + 20) 527 0 1 2 3 528 +--------------+--------------+--------------+--------------+ 529 | Interface ifIndex | 530 +--------------+--------------+--------------+--------------+ 531 | AFI | Reserved | 532 +--------------+--------------+--------------+--------------+ 533 | IPv6 address, 32-bit word 1 | 534 +--------------+--------------+--------------+--------------+ 535 | IPv6 address, 32-bit word 2 | 536 +--------------+--------------+--------------+--------------+ 537 | IPv6 address, 32-bit word 3 | 538 +--------------+--------------+--------------+--------------+ 539 | IPv6 address, 32-bit word 4 | 540 +--------------+--------------+--------------+--------------+ 542 Figure 7: Incoming Interface: By Index and IPv6 Address 544 Figure 8 depicts an Interface Information Object representing an 545 outgoing interface identified by iFIndex and Name. 547 Class-Num = 2 548 C-Type = 10001010b // Indicates outgoing interface 549 Length = 72 (4 + 4 + 64) 551 0 1 2 3 552 +--------------+--------------+--------------+--------------+ 553 | Interface ifIndex | 554 +--------------+--------------+--------------+--------------+ 555 | Length | Name, word 1 | 556 +--------------+--------------+--------------+--------------+ 557 ... ... 558 +--------------+--------------+--------------+--------------+ 559 | Name , word 16 | 560 +--------------+--------------+--------------+--------------+ 562 Figure 8: Outgoing Interface: By IfIndex and Name 564 4.5. Usage 566 Multiple Interface Information Objects MAY be included within a 567 single ICMP message, provided that each Interface Information Object 568 specifies a unique role. A single ICMP message MUST NOT contain two 569 Interface Information Objects that specify the same role. 571 IfIndex, MTU and name information MAY be included whenever it is 572 available; more than one instance of each of these three information 573 elements MUST NOT be included per Interface Information Object. 575 A single instance of IP Address information MAY be included in an 576 Interface Information Object under the following circumstances: 578 o if the eliciting datagram is IPv4 and an IPv4 address is 579 associated with the identified interface. In this case, if an IP 580 Address Sub-Object is included, it must specify an IPv4 address. 581 o if the eliciting datagram is IPv6 and an IPv6 address is 582 associated with the identified interface. In this case, if an IP 583 Address Sub-Object is included, it must specify an IPv6 address. 585 In all other circumstances, IP address information MUST NOT be 586 included. 588 An ICMP message that does not conform to these rules and contains 589 multiple instances of the same information is considered illegal; 590 specifically, an ICMP message containing more than one Interface 591 Information Object with the same role, as well as an ICMP message 592 containing a duplicate information element in a given role are 593 considered illegal. If such illegal ICMP message is received, it 594 MUST be silently discarded. 596 5. Network Address Translation Considerations 598 [RFC5508] encourages Traditional IP Network Address Translators 599 (Traditional NATs, see [RFC3022]) to support ICMP extension objects. 600 This document defines an ICMP extension that includes IP addresses 601 and therefore contains realm specific information, and consequently 602 describes possible NAT behaviors in presence of these extensions. 604 NAT devices MUST NOT translate or overwrite the ICMP extensions 605 described herein. That is, they MUST either remove the extension 606 entirely or pass it unchanged. 608 It is conceivable that a NAT device might translate an ICMP header 609 without translating the extension defined herein. In this case, the 610 ICMP message might contain two instances of the same address, one 611 translated and the other untranslated. Therefore, application 612 developers should not assume addresses in the extension are of the 613 same realm as the addresses in the datagram's header. 615 It also is conceivable that a NAT device might translate an ICMPv4 616 message into ICMPv6 or vice versa. If that were to occur, 617 applications might receive ICMPv6 messages that contain IP Address 618 Sub-Objects that specify IPv4 addresses. Likewise, applications 619 might receive ICMPv4 messages that contain IP Address Sub-Objects 620 that specify IPv6 addresses. 622 6. Security Considerations 624 This extension can provide the user of traceroute with additional 625 network information that is not currently available. Implementations 626 SHOULD provide configuration switches that suppress the generation of 627 this extension based upon role (i.e., incoming interface, outgoing 628 interface, sub-ip data). Implementations SHOULD also provide 629 configuration switches that conceal various types of information 630 (e.g., ifIndex, interface name). 632 It may be desirable to provide this information to a particular 633 network's operators and not to others. If such policy controls are 634 desirable, then an implementation could determine what sub-objects to 635 include based upon the destination IP address of the ICMP message 636 that will contain the sub-objects. The implementation of policy 637 controls could also be based upon the mechanisms described in 638 [I-D.shen-udp-traceroute-ext] for those limited cases supported. 640 For instance, the IP address may be included for all potential 641 recipients. The ifIndex and interface name could be included as well 642 if the destination IP address is a management address of the network 643 that has administrative control of the router. 645 Another example use case would be where the detailed information in 646 these extensions may be provided to ICMP destinations within the 647 local administrative domain, but only traditional information is 648 provided to 'external' or untrusted ICMP destinations. 650 The intended field of use for the extensions defined in this document 651 is administrative debugging and troubleshooting. The extensions 652 herein defined supply additional information in ICMP responses. 653 These mechanisms are not intended to be used in non-debugging 654 applications. 656 This document does not specify an authentication mechanism for the 657 extension that it defines. Application developers should be aware 658 that ICMP messages and their contents are easily spoofed. 660 7. IANA Considerations 662 IANA should reserve from the ICMP Extension Object Classes registry 663 reachable at : 2 for 664 the Interface Information Object. 666 From the Interface ID Object's c-type, IANA should reserve as 667 follows: 669 o Bit 0-1: Interface Role field 670 o Bit 2: Unallocated - allocatable with Standards Action 671 o Bit 3: Unallocated - allocatable with Standards Action 672 o Bit 4: ifIndex included 673 o Bit 5: IP Address Sub-object included 674 o Bit 6: Name Sub-object included 675 o Bit 7: MTU included 677 IANA should reserve the following values for Interface Role: 679 o Value 0: Incoming IP Interface 680 o Value 1: Sub-IP Component of Incoming IP Interface 681 o Value 2: Outgoing IP Interface 682 o Value 3: IP Next-hop 684 8. Acknowledgments 686 The authors would like to thank Sasha Vainshtein, Enke Chen and Joe 687 Touch for their comments and suggestions. They would also like to 688 thank Dr. Ali Assefi. 690 9. References 692 9.1. Normative References 694 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 695 RFC 792, September 1981. 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 701 MIB", RFC 2863, June 2000. 703 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 704 10646", STD 63, RFC 3629, November 2003. 706 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 707 Message Protocol (ICMPv6) for the Internet Protocol 708 Version 6 (IPv6) Specification", RFC 4443, March 2006. 710 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 711 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 712 April 2007. 714 9.2. Informative References 716 [I-D.shen-udp-traceroute-ext] 717 Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP 718 Traceroute Message Extension", 719 draft-shen-udp-traceroute-ext-01 (work in progress), 720 June 2008. 722 [RFC1122] Braden, R., "Requirements for Internet Hosts - 723 Communication Layers", STD 3, RFC 1122, October 1989. 725 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 726 RFC 1812, June 1995. 728 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 729 Languages", BCP 18, RFC 2277, January 1998. 731 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 732 Address Translator (Traditional NAT)", RFC 3022, 733 January 2001. 735 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 736 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 737 April 2009. 739 Authors' Addresses 741 Alia K. Atlas (editor) 742 BT 744 Email: alia.atlas@bt.com 746 Ronald P. Bonica (editor) 747 Juniper Networks 748 2251 Corporate Park Drive 749 Herndon, VA 20171 750 USA 752 Email: rbonica@juniper.net 753 Carlos Pignataro (editor) 754 Cisco Systems 755 7200-12 Kit Creek Road 756 PO Box 14987 757 Research Triangle Park, NC 27709 758 USA 760 Email: cpignata@cisco.com 762 J.R. Rivers 764 Email: jrrivers@yahoo.com 766 Naiming Shen 767 Cisco Systems 768 225 West Tasman Drive 769 San Jose, CA 95134 770 USA 772 Email: naiming@cisco.com