idnits 2.17.1 draft-atlas-icmp-unnumbered-01.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 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6643 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 (-16) exists of draft-bonica-internet-icmp-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet A. Atlas 3 Internet-Draft Google, Inc. 4 Expires: August 5, 2006 JR. Rivers 5 Nuova Systems 6 R. Bonica 7 Juniper Networks 8 N. Shen 9 E. Chen 10 Cisco Systems 11 February 2006 13 ICMP Extensions for Unnumbered Interfaces 14 draft-atlas-icmp-unnumbered-01 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 August 5, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This memo defines extensions to ICMP that permit identification of 48 unnumbered interfaces. The interface the triggering IPv4 packet was 49 received upon can be identified by appending an ifIndex and/or a 50 string describing the interface. These extensions are defined to 51 facilitate troubleshooting in network with unnumbered interfaces. 52 Additionally, to facilitate debugging of numbered interfaces, the 53 IPv4 address of the interface the triggering IPv4 packet was received 54 upon can be identified by appending the IPv4 address. 56 Table of Contents 58 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 4 61 4. Interface ID Object . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Interface Description Object . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Conventions Used In This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC2119 [RFC2119]. 78 2. Introduction 80 IP routers use the Internet Control Message Protocol (ICMP) [RFC0792] 81 to convey control information to source hosts. Network operators use 82 this information to diagnose routing problems. 84 When a router generates an ICMP message, the source IP address, as 85 specified in RFC1812 [RFC1812], MUST be either one of the IP 86 addresses associated with the transmitting interface or, for 87 unnumbered interfaces, the router's router-id. When the transmitting 88 interface is the same as the incoming interface of the packet that 89 triggered the ICMP message and that interface is numbered, this 90 allows easy identification of specific interface and is very useful 91 for troubleshooting connectivity issues. The transmitting and 92 incoming interfaces may be different due to an asymmetric return 93 path, which can occur due to asymmetric link costs or ECMP. This 94 specification provides an extension so that the IPv4 address of the 95 incoming interface can be explicitly reported. 97 When a network uses unnumbered interfaces and parallel links, it is 98 not currently possible to identify the specific incoming interface of 99 a packet based upon the responding ICMP message. This memo defines 100 two additional extensions to ICMP that permit an operator to identify 101 the specific incoming interface traversed by a packet that triggered 102 an ICMP message. 104 These two extensions are motivated by the desire for similar 105 information to that for numbered interfaces. In the case of 106 traceroute, the ICMP message contains the interfaces's IP address; 107 then that IP address is commonly resolved via DNS to provide a 108 meaningful name for the interface that is easier for humans. One 109 extension permits a router to include the interface's ifIndex; this 110 can be used in combination with the source IP address for management 111 tasks. The second extension permits a router to include an interface 112 description string. 114 The inclusion of an interface description may also be useful for 115 numbered interfaces that use a private IP address that DNS cannot 116 resolve for supported users of traceroute and other ICMP message 117 triggers. 119 The ICMP message MUST include the IP header and leading payload 120 octets of the original datagram. As described in [I-D.bonica- 121 internet-icmp], an ICMP Extension Structure Header MUST follow the 122 octets from the original datagram and come before any ICMP Extension 123 Objects. 125 3. Application to TRACEROUTE 127 ICMP extensions defined in this memo support enhancements to 128 TRACEROUTE (the reasons are discussed in [I-D.bonica-internet-icmp]). 129 The enhanced TRACEROUTE application, like older implementations, 130 indicates which nodes the original datagram visited en route to its 131 destination. It differs from older implementations in that it also 132 reflects the incoming interface on which the original triggering 133 packet arrived, even when that interface is unnumbered. 135 4. Interface ID Object 137 This section defines an ICMP extension object that can be appended to 138 the ICMP Time Exceeded and Destination Unreachable messages. An 139 Interface ID Object of c-type 1 can be appended to these messages. 140 The incoming interface is the one upon which the packet which 141 triggered the ICMP message was received. If the incoming interface 142 is unnumbered, then an Interface ID Object of c-type 1 SHOULD be 143 included in the ICMP Time Exceeded or Destination Unreachable 144 message. If the incoming interface has an IPv4 address, then an 145 Interface ID Object of c-type 1 MAY be included in the ICMP Time 146 Exceeded and Destination Unreachable messages; additionally, one or 147 Interface ID Objects of c-type 2 MAY be included in those messages. 149 Figure 1 depicts the Interface ID Object. It must be preceded by an 150 ICMP Extension Structure Header and an ICMP Object Header. Both are 151 defined in [I-D.bonica-internet-icmp]. The ifIndex included is that 152 assigned to the interface by the router in as specified by the 153 Interfaces Group MIB [RFC2863]. 155 Class-Num = 2, 156 C-Type = 1 (Specifies ifIndex of incoming interface) 157 Length = 8 159 0 1 2 3 160 +-------------+-------------+-------------+-------------+ 161 | Interface ifIndex | 162 +-------------+-------------+-------------+-------------+ 164 Figure 1: Interface ID Object - ifIndex 166 Class-Num = 2, 167 C-Type = 2 168 Specifies an IPv4 address of the incoming interface. 169 Length = 8 171 0 1 2 3 172 +-------------+-------------+-------------+-------------+ 173 | an IPv4 address of the incoming interface | 174 +-------------+-------------+-------------+-------------+ 176 Figure 2: Interface ID Object - IPv4 address 178 5. Interface Description Object 180 This section defines an ICMP extention object that can be appended to 181 the ICMP Time Exceeded and Destination Unreachable messages. An 182 Interface Description Object with c-type 1 or 2 can be appended to 183 these messages. If the incoming interface is unnumbered, then an 184 Interface ID Object of C-type 1 MAY be included in the ICMP Time 185 Exceeded message and Destination Unreachable messages. 187 Figure 3 depicts the Interface Description Object. It must be 188 preceded by an ICMP Extension Structure Header and an ICMP Object 189 Header. Both are defined in [I-D.bonica-internet-icmp]. 191 Interface Class-Num = 3, 192 C-Type = 1 or 2 194 0 1 2 3 195 +-------------+-------------+-------------+-------------+ 196 | Interface Description | 197 +-------------+-------------+-------------+-------------+ 198 // Interface Description, continued // 199 +-------------+-------------+-------------+-------------+ 200 | Interface Description, continued | 201 +-------------+-------------+-------------+-------------+ 203 Figure 3: Interface Description Object 205 C-Type 1: This contains the description of the incoming interface. 206 Human-readable text for this c-type MUST be provided in the US-ASCII 207 charset [US-ASCII] using the Default Language [RFC2277]. 209 C-Type 2: This contains the description of the incoming interface. 210 Human-readable text for this c-type MUST be provided in the UTF-8 211 charset [RFC3629] using the Default Language [RFC2277]. 213 Interface Description: This field MUST have a length that is a 214 multiple of 4 bytes; the string should be padded with zeroes as 215 necessary. The description SHOULD be the MIB-II ifName [RFC2863] but 216 MAY be some other human-meaningful description of the interface. 218 6. Security Considerations 220 These extensions can provide the user of traceroute with additional 221 network information that is not currently available. It may be 222 desirable to provide this information to a particular network's 223 operators and not to others. If such policy controls are desirable, 224 then an implementation could determine what extensions to include 225 based upon the destination IP address of the ICMP message. For 226 instance, the ifIndex might be appropriate for all potential 227 recipients; the description could be included as well if the 228 destination IP address is a management address of the network that 229 has administrative control of the router. 231 7. IANA Considerations 233 IANA should should reserve from the ICMP Extension Object registry: 2 234 for the Interface ID Object and 3 for the Interface Description 235 Object. IANA should reserve from the Interface ID Object's c-type 236 the value 1 for Incoming Interface ifIndex and the value 2 for the 237 Incoming Interface IPv4 address. IANA should reserve from the 238 Interface Description Object's c-type the value 1 for the incoming 239 interface description in ASCII and the value 2 for the incoming 240 interface description in UTF-8. 242 8. Acknowledgements 244 The authors would like to thank Carlos Pignataro and Sasha Vainshtein 245 for their comments and suggestions. 247 9. References 249 9.1. Normative References 251 [I-D.bonica-internet-icmp] 252 Bonica, R., "Extending the Internet Control Message 253 Protocol (ICMP)", draft-bonica-internet-icmp-01 (work in 254 progress), January 2006. 256 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 257 RFC 792, September 1981. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 263 MIB", RFC 2863, June 2000. 265 9.2. Informative References 267 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 268 RFC 1812, June 1995. 270 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 271 Languages", BCP 18, RFC 2277, January 1998. 273 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 274 10646", STD 63, RFC 3629, November 2003. 276 [US-ASCII] 277 "Coded Character Set -- 7-bit American Standard Code for 278 Information Interchange, ANSI X3.4-1986". 280 Authors' Addresses 282 Alia K. Atlas 283 Google, Inc. 284 1600 Amphitheatre Parkway 285 Mountain View, CA 94043 286 USA 288 Email: akatlas@google.com 290 J.R. Rivers 291 Nuova Systems 293 Email: jrrivers@nuovasystems.com 295 Ronald P. Bonica 296 Juniper Networks 297 2251 Corporate Park Drive 298 Herndon, VA 20171 299 USA 301 Email: rbonica@juniper.net 303 Naiming Shen 304 Cisco Systems 305 225 West Tasman Drive 306 San Jose, CA 95134 307 USA 309 Email: naiming@cisco.com 311 Enke Chen 312 Cisco Systems 313 170 West Tasman Drive 314 San Jose, CA 95134 315 USA 317 Email: enkechen@cisco.com 319 Intellectual Property Statement 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Disclaimer of Validity 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Copyright Statement 355 Copyright (C) The Internet Society (2006). This document is subject 356 to the rights, licenses and restrictions contained in BCP 78, and 357 except as set forth therein, the authors retain all their rights. 359 Acknowledgment 361 Funding for the RFC Editor function is currently provided by the 362 Internet Society.