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