idnits 2.17.1 draft-atlas-icmp-unnumbered-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. 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 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 (November 3, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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 5 Expires: May 7, 2009 Juniper Networks 6 JR. Rivers 7 Nuova Systems 8 N. Shen 9 E. Chen 10 Cisco Systems 11 November 3, 2008 13 Extending ICMP for Interface and Next-hop Identification 14 draft-atlas-icmp-unnumbered-06 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 7, 2009. 41 Abstract 43 This memo defines ICMP extensions, using ICMP multi-part messages, 44 through which a router or host can explicitly identify an interface 45 by ifIndex, name, and/or address, as already used in MIBs and by 46 OSPF. The interfaces so identified can be the interface upon which 47 an undeliverable datagram arrived, a sub-IP member of that interface, 48 and the interface through which the datagram would have been sent. 50 The nexthop IP address can also be provided as part of the outgoing 51 interface information. The extensions defined herein are 52 particularly useful when troubleshooting networks with unnumbered 53 interfaces, parallel interfaces and/or asymmetric routing. 55 Table of Contents 57 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Application to Traceroute . . . . . . . . . . . . . . . . 4 61 3.2. Policy and MTU Detection . . . . . . . . . . . . . . . . . 5 62 4. Interface Information Object . . . . . . . . . . . . . . . . . 5 63 4.1. C-type meaning in an Interface Information Object . . . . 6 64 4.2. Interface Name Sub-Object . . . . . . . . . . . . . . . . 8 65 4.3. Interface Information Object Examples . . . . . . . . . . 9 66 4.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5. Network Address Translation Considerations . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . . . . 17 77 1. Conventions Used In This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC2119 [RFC2119]. 83 2. Introduction 85 IP devices use the Internet Control Message Protocol (ICMP) [RFC0792] 86 (ICMPv6) [RFC4443] to convey control information. In particular, 87 when an IP device receives a datagram that it cannot forward, it may 88 send an ICMP message to the datagram's originator. Network operators 89 and higher level protocols use these ICMP messages to detect and 90 diagnose network issues. 92 In the nominal case, the source address of the ICMP message 93 identifies the interface upon which the non-forwardable datagram 94 arrived. However, in many cases, the incoming interface is not 95 identified by the ICMP message at all. Details follow: 97 According to RFC1812 [RFC1812], when a router generates an ICMP 98 message, the source address of that ICMP message MUST be one of the 99 following: 101 o one of the IP addresses associated with the physical interface 102 over which the ICMP message is transmitted 103 o if that interface has no IP addresses associated with it, the 104 device's router-id or host-id is used instead. 106 If the following conditions are true, the source address of the ICMP 107 message identifies the interface upon which the non-forwardable 108 datagram arrived: 110 o the device originates an ICMP message through the same interface 111 upon which the non-forwardable datagram was received. 112 o that interface is numbered. 114 However, the transmitting and incoming interfaces may be different 115 due to an asymmetric return path, which can occur due to asymmetric 116 link costs, parallel links or ECMP. 118 For ICMPv6, the asymmetric issues need not be an issue, since there 119 is more flexibility for ICMPv6, as defined in RFC4443 [RFC4443]. For 120 responses to messages sent to addresses that aren't the router's, the 121 source address must be chosen as follows: 123 o the Source Address of the ICMPv6 packet MUST be a unicast address 124 belonging to the node. The address SHOULD be chosen according to 125 the rules that would be used to select the source address for any 126 other packet originated by the node, given the destination address 127 of the packet. However, it MAY be selected in an alternative way 128 if this would lead to a more informative choice of address 129 reachable from the destination of the ICMPv6 packet. 131 For both ICMP and ICMPv6, when a network uses unnumbered interfaces, 132 it is not possible to identify the incoming interface. The extension 133 defined in this memo permit an ICMP originator to identify the 134 interface through which the datagram that elicited the ICMP message 135 arrived. 137 Using the extension defined herein, an IP device can explicitly 138 identify the incoming interface by any or all of the following: 140 o IPv4 address 141 o IPv6 address 142 o name 143 o ifIndex 145 Using the same extension, an IP device can explicitly identify by the 146 above the outgoing interface over which a datagram would have been 147 forwarded if that datagram had been deliverable. 149 The next-hop IP address, over which the datagram would have been 150 forwarded, can also be provided via this same extension. This 151 information can be used for creating a downstream map. The next-hop 152 information may not always be available. There are corner-cases, 153 such as point-to-point unnumbered links, where it doesn't exist. 154 There may be implementations where it is not practical to provide 155 this information. This specification provides an encoding for 156 providing the next-hop IP address when it is available. 158 The extension defined herein use the ICMP multi-part message 159 framework defined in [RFC4884]. The same backward compatibility 160 issues that apply to [RFC4884] apply to this extension. 162 3. Applications 164 3.1. Application to Traceroute 166 ICMP extensions defined in this memo require enhancements ([RFC4884]) 167 and provide additional capability to traceroute. The enhanced 168 traceroute application, like older implementations, indicates which 169 nodes the original datagram visited en route to its destination. It 170 differs from older implementations in that it also reflects the 171 incoming interface on which the original triggering packet arrived, 172 even when that interface is unnumbered. 174 3.2. Policy and MTU Detection 176 A general application would be to identify which outgoing interface 177 triggered a given function for the original packet. For example, if 178 an ACL drops the packet and Dest Unreachable/Admin Prohibited denies 179 the packet, being able to identify the outgoing interface might be 180 useful. Another example would be to support PMTU, since this would 181 allow identification of which outgoing interface can't support a 182 given MTU size. For example, knowledge of the problematic interface 183 would allow an informed request for reconfiguration of the MTU of 184 that interface. 186 4. Interface Information Object 188 This section defines an ICMP extension object that can be appended to 189 the ICMPv4 Time Exceeded, ICMPv4 Destination Unreachable, ICMPv4 190 Parameter Problem, ICMPv6 Time Exceeded, and ICMPv6 Destination 191 Unreachable messages, as described in [RFC4884]. For the description 192 of the Interface Information Object, the incoming interface is the 193 one upon which the packet which triggered the ICMP message was 194 received. If desired, information about a sub-IP member of the 195 incoming interface can be included. An example of such a sub-IP 196 member would be a member of an Ethernet Link Aggregation Group that 197 forms the incoming interface. To minimize the use of extra octets 198 required for this extension, there are four different pieces of 199 information that can appear in an Interface Information Object. 201 1. If the interface of interest has at least one IPv4 address and 202 the triggering packet was IPv4, then one of the interface's IPv4 203 addresses MAY be included. Alternately, if the interface of 204 interest has at least one IPv6 address and the triggering packet 205 was IPv6, then one of the interface's IPv6 addresses MAY be 206 included. 207 2. The ifIndex of the interface of interest MAY be included. This 208 is the 32-bit ifIndex assigned to the interface by the router as 209 specified by the Interfaces Group MIB [RFC2863]. 210 3. An Interface Name Sub-Object, containing a string of no more than 211 62 octets, MAY be included. That string, as specified in Section 212 Section 4.2, is the interface name and SHOULD be the MIB-II 213 ifName [RFC2863], but MAY be some other human-meaningful name of 214 the interface. 216 4. If the interface of interest is the outgoing interface, then if 217 the triggering packet was IPv4, a next-hop IPv4 address MAY be 218 included. If the triggering packet was IPv6, a next-hop IPv6 219 address MAY be included. 221 4.1. C-type meaning in an Interface Information Object 223 For this object, the c-type is used to indicate both the role of the 224 interface and the information that is included. This is illustrated 225 below. 227 Bit 7 6 5 4 3 2 1 0 228 +-------+-------+-------+-------+-------+-------+---------+-------+ 229 | Interface Role| Rsvd1 | Rsvd2 | index | IP | nexthop | name | 230 +-------+-------+-------+-------+-------+-------+---------+-------+ 232 Interface Role: This 2-bit field [6:7] indicates the role of the 233 interface being identified. The enumerated values 234 are given below. 235 0 : This object describes the incoming interface. 236 1 : This object describes the outgoing interface. 237 2 : This object describes a sub-IP member of the 238 incoming interface. 239 3 : Reserved 241 bit : Field Name : description 243 5 : Reserved 1 : This bit is reserved for future use and MUST be 244 set to 0 and MUST be ignored on receipt. 246 4 : Reserved 2 : This bit is reserved for future use and MUST be 247 set to 0 and MUST be ignored on receipt. 249 3 : ifIndex : When set, this bit indicates the 32-bit ifIndex of 250 the interface is included. When clear, the ifIndex 251 is not included. 253 2 :IP address : When set, this indicates an IP address of the 254 interface is included. When clear, no IP address 255 is included. The version of the IP packet 256 containing the ICMP message will indicate the type 257 of IP address. An IPv4 packet will have an IPv4 258 address; an IPv6 packet will have an IPv6 address. 260 1 : Next-hop : This MUST be clear unless the Interface Role is 3, 261 indicating an outgoing interface. When this flag is 262 set, this indicates that the next-hop IP address is 263 included. When clear, no IP address is included. The 264 version of the IP packet containing the ICMP message 265 will indicate the type of IP address. An IPv4 packet 266 will include an IPv4 address and an IPv6 packet will 267 include an IPv6 address. 269 0 : Interface Name: When set, this indicates an Interface Name 270 Sub-object for the interface is included. When 271 clear, it is not included. 273 Figure 1: C-Type for the Interface Information Object 275 With the exception of the Interface Name sub-object, the information 276 included does not self-identify, so this specification defines a 277 specific ordering for sending the information which must be followed. 279 If bit 3 (ifIndex) is set, then the 32-bit ifIndex MUST be sent 280 first. If bit 2 (IP address) is set, then either an IPv4 address or 281 an IPv6 address, depending on packet version, MUST be sent next. If 282 bit 0 (Interface Name) is set, then an Interface Name Sub-object MUST 283 be sent next. If bit 1 (Next-hop) is set, then the next-hop is given 284 in either an IPv4 address or an IPv6 address, depending on the packet 285 version. The information order is thus: ifIndex, IP address, 286 Interface Name sub-object, next-hop; any or all pieces of information 287 may be present or absent, as indicated by the c-type. Any data that 288 follows these optional pieces of information MUST be ignored. 290 The sender of an Interface Information Object MUST NOT set the 291 Interface Role to 3 and an Interface Role value of 3 MUST be ignored 292 on receipt and the Interface Information Object discarded. It is 293 valid (though pointless until additional bits are assigned by IANA) 294 to receive an Interface Information Object where bits 3, 2, 1 and 0 295 are all 0; this MUST NOT generate a warning or error. 297 4.2. Interface Name Sub-Object 299 The Interface Name Sub-Object MUST have a length that is a multiple 300 of 4 octets and MUST NOT exceed 64 octets. A one octet "charset 301 type" and a one octet "length" are required and the interface name 302 can be at most 62 octets long. The interface name SHOULD be the full 303 MIB-II ifName [RFC2863], if less than 63 octets, or the first 62 304 octets of the ifName, if the ifName is longer. The interface name 305 MAY be some other human-meaningful name of the interface. It is 306 useful to provide the ifName for cross-correlation with other MIB 307 information and for human-reader familiarity. 309 The Interface Name Sub-Object consists of three fields. The first 310 1-octet field indicates the character set type used by the second 311 field. The second field contains the length of the Interface name 312 Sub-object, including the charset type, the length, and the human- 313 readable name in octets. The maximum valid length is 64 octets. The 314 length is constrained to ensure there is space for the start of the 315 original packet and additional information. The third field contains 316 the human-readable name. 318 octet 0 1 2 63 319 +--------------+--------+---..............-----------------+ 320 | charset type | length | interface name octets 1-62 | 321 +--------------+--------+---..............-----------------+ 323 Figure 2: Interface Name Sub-Object 325 charset type 0 : This indicates that the human-readable interface 326 name MUST be provided in the US-ASCII charset [US-ASCII] using the 327 Default Language [RFC2277]. 329 charset type 1 : This indicates that the human-readable interface 330 name MUST be provided in the UTF-8 charset [RFC3629] using the 331 Default Language [RFC2277]. 333 4.3. Interface Information Object Examples 335 Figure 3 shows a full ICMPv4 Time Exceeded message, including the 336 Interface Information Object, which must be preceded by an ICMP 337 Extension Structure Header and an ICMP Object Header. Both are 338 defined in [RFC4884]. 340 Figure 4 depicts the Interface Information Object, with four of the 341 valid permutations. 343 Although all examples show an Interface Name Sub-object of length 64, 344 this is only for illustration and depicts the maximum allowable 345 length. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type | Code | Checksum | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | unused | Length | unused | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Internet Header + leading octets of original datagram | 355 | | 356 | // | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Ver=2 | (Reserved) | Checksum | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Length |Class-Num=2 | C-Type=00001001b | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Interface ifIndex | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Interface Name, 32-bit word 1 | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ... ... 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Interface Name , 32-bit word 16 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 3: ICMPv4 Time Exceeded message with Interface Information 373 Object 375 Class-Num = 2 377 Example 1: Unnumbered Interface with ifIndex and interface name 379 C-Type = 00001001b // Indicates incoming interface 380 Length = 40 (4 + 4 + 32) 382 0 1 2 3 383 +--------------+--------------+--------------+--------------+ 384 | Interface ifIndex | 385 +--------------+--------------+--------------+--------------+ 386 | Interface Name, 32-bit word 1 | 387 +--------------+--------------+--------------+--------------+ 388 ... ... 389 +--------------+--------------+--------------+--------------+ 390 | Interface Name , 32-bit word 16 | 391 +--------------+--------------+--------------+--------------+ 393 Example 2: IPv4 interface with IPv4 address, 394 ifIndex and interface name 396 C-Type = 00001101b // Indicates incoming interface 397 Length = 44 (4 + 4 + 4 + 32) 399 0 1 2 3 400 +--------------+--------------+--------------+--------------+ 401 | Interface ifIndex | 402 +--------------+--------------+--------------+--------------+ 403 | IPv4 address | 404 +--------------+--------------+--------------+--------------+ 405 | Interface Name, 32-bit word 1 | 406 +--------------+--------------+--------------+--------------+ 407 ... ... 408 +--------------+--------------+--------------+--------------+ 409 | Interface Name, 32-bit word 16 | 410 +--------------+--------------+--------------+--------------+ 412 Example 3: IPv6 interface with IPv6 address and ifIndex 414 C-Type = 00001100b // Indicates incoming interface 415 Length = 24 (4 + 4 + 16) 417 0 1 2 3 418 +--------------+--------------+--------------+--------------+ 419 | Interface ifIndex | 420 +--------------+--------------+--------------+--------------+ 421 | IPv6 address, 32-bit word 1 | 422 +--------------+--------------+--------------+--------------+ 423 | IPv6 address, 32-bit word 2 | 424 +--------------+--------------+--------------+--------------+ 425 | IPv6 address, 32-bit word 3 | 426 +--------------+--------------+--------------+--------------+ 427 | IPv6 address, 32-bit word 4 | 428 +--------------+--------------+--------------+--------------+ 430 Example 4: outgoing IPv4 interface with IPv4 address, 431 next-hop IPv4 address 433 C-Type = 10000110b // Indicates incoming interface 434 Length = 44 (4 + 4) 436 0 1 2 3 437 +--------------+--------------+--------------+--------------+ 438 | outgoing interface's IPv4 address | 439 +--------------+--------------+--------------+--------------+ 440 | next-hop IPv4 address | 441 +--------------+--------------+--------------+--------------+ 443 Figure 4: Interface Information Object 445 4.4. Usage 447 For each interface described by an included Interface Information 448 Object, these are the rules for the information to be included. If 449 the interface in question is unnumbered, then the Interface 450 Information Object SHOULD include the ifIndex and MUST NOT include an 451 IP address. If the interface in question is numbered, then the 452 Interface Information Object SHOULD include the IP address. Other 453 fields MAY be included in the Interface Information Object. 455 In an ICMP message, more than one Interface Information Object with a 456 given interface role MUST NOT be included. Multiple Interface 457 Information Objects, each with a different interface role, MAY be 458 included. 460 5. Network Address Translation Considerations 462 [I-D.ietf-behave-nat-icmp] encourages Traditional IP Network Address 463 Translators (Traditional NATs, see [RFC3022]) to support ICMP 464 extension objects. This document defines an ICMP extension that 465 includes IP addresses and therefore contain realm specific 466 information, and consequently describes possible NAT behaviors in 467 presence of these extensions. 469 In the most general case, a NAT device may choose to transparently 470 pass, remove or overwrite this extension. The action may be 471 different for the different fields: The ifIndex can either be 472 transparently passed or removed, the Description can be transparently 473 passed, removed or re-written (adding some text to the effect that a 474 NAT was crossed and the description was removed, as a matter of 475 policy or other), and IP addresses can either be passed, removed or 476 translated. 478 When translating IP address-related fields of the extension defined 479 in this document, the behavior should be equivalent to that of the 480 treatment of Router-x and Router-y source IP address in Sections 481 4.2.1 and 4.2.2 of [I-D.ietf-behave-nat-icmp](respectively). That 482 is: 484 o For ICMP Error Packets received from an External Realm: IP 485 Addresses included in this extension remain unchanged because they 486 correspond to the external domain (e.g., correspond to a router 487 that generated the ICMP in the external realm). 488 o For ICMP Error Packets received from a Private Realm: This 489 extension includes an IP address corresponding to the Private 490 realm, let's refer to it as IP-Private, and its translation 491 depends on whether Basic NAT or NAPT function ([RFC3022]) is 492 enforced by the NAT: 493 o 494 * Basic NAT: If the NAT has an active mapping for IP-Private, the 495 NAT translate it within the extension with the IP-Public in 496 said mapping. If not, the NAT translates the IP-Private 497 address using its own IP address on the external domain. 498 * NAPT: the NAT translates the IP-Private address in the 499 extension to its own IP address on the external domain. 501 These recommendations allow for the improved troubleshooting offered 502 by this extension while not leaking private-realm addresses outside. 503 A NAT SHOULD follow the recommendations in this section; it MAY 504 choose to pass the extension unaltered. 506 6. Security Considerations 508 This extension can provide the user of traceroute with additional 509 network information that is not currently available. It may be 510 desirable to provide this information to a particular network's 511 operators and not to others. If such policy controls are desirable, 512 then an implementation could determine what sub-objects to include 513 based upon the destination IP address of the ICMP message that will 514 contain the sub-objects. The implementation of policy controls could 515 also be based upon the mechanisms described in 516 [I-D.shen-udp-traceroute-ext] for those limited cases supported. 518 For instance, the IP address may be included for all potential 519 recipients. The ifIndex and interface name could be included as well 520 if the destination IP address is a management address of the network 521 that has administrative control of the router. 523 Another example use case would be where the detailed information in 524 these extensions may be provided to ICMP destinations within the 525 local administrative domain, but only traditional information is 526 provided to 'external' or untrusted ICMP destinations. 528 7. IANA Considerations 530 IANA should reserve from the ICMP Extension Object registry: 2 for 531 the Interface Information Object. 533 From the Interface ID Object's c-type, IANA should reserve as 534 follows: 536 o Bit 0: Interface Name Sub-Object included 537 o Bit 1: IP next-hop address included 538 o Bit 2: IP address included 539 o Bit 3: ifIndex included 540 o Bit 4: Unallocated - allocatable with Standards Action 541 o Bit 5: Unallocated - allocatable with Standards Action 542 o Bit 6-7: Interface Role field 543 * Value 0: Incoming Interface 544 * Value 1: Outgoing Interface 545 * Value 2: Incoming Interface - Sub-IP Member 546 * Value 3: Unallocated - allocatable with Standards Action 548 Additionally, the Interface Name Sub-Object has a 1 octet charset 549 type field. IANA should create a registry for it and allocate as 550 follows: 552 o 0 : encoded in ASCII 553 o 1 : encoded in UTF-8 554 o 2-127: Unallocated - allocatable with Standards Action 555 o 128-255: Unallocated - allocated on first come basis. 557 8. Acknowledgements 559 The authors would like to thank Carlos Pignataro, Sasha Vainshtein, 560 and Joe Touch for their comments and suggestions. 562 9. References 564 9.1. Normative References 566 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 567 RFC 792, September 1981. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 573 MIB", RFC 2863, June 2000. 575 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 576 Message Protocol (ICMPv6) for the Internet Protocol 577 Version 6 (IPv6) Specification", RFC 4443, March 2006. 579 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 580 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 581 April 2007. 583 9.2. Informative References 585 [I-D.ietf-behave-nat-icmp] 586 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 587 Behavioral Requirements for ICMP protocol", 588 draft-ietf-behave-nat-icmp-10 (work in progress), 589 October 2008. 591 [I-D.shen-udp-traceroute-ext] 592 Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP 593 Traceroute Message Extension", 594 draft-shen-udp-traceroute-ext-01 (work in progress), 595 June 2008. 597 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 598 RFC 1812, June 1995. 600 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 601 Languages", BCP 18, RFC 2277, January 1998. 603 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 604 Address Translator (Traditional NAT)", RFC 3022, 605 January 2001. 607 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 608 10646", STD 63, RFC 3629, November 2003. 610 [US-ASCII] 611 "Coded Character Set -- 7-bit American Standard Code for 612 Information Interchange, ANSI X3.4-1986". 614 Authors' Addresses 616 Alia K. Atlas (editor) 617 BT 619 Email: alia.atlas@bt.com 620 Ronald P. Bonica 621 Juniper Networks 622 2251 Corporate Park Drive 623 Herndon, VA 20171 624 USA 626 Email: rbonica@juniper.net 628 J.R. Rivers 629 Nuova Systems 631 Email: jrrivers@nuovasystems.com 633 Naiming Shen 634 Cisco Systems 635 225 West Tasman Drive 636 San Jose, CA 95134 637 USA 639 Email: naiming@cisco.com 641 Enke Chen 642 Cisco Systems 643 170 West Tasman Drive 644 San Jose, CA 95134 645 USA 647 Email: enkechen@cisco.com 649 Full Copyright Statement 651 Copyright (C) The IETF Trust (2008). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 660 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 661 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Intellectual Property 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org.