idnits 2.17.1 draft-ietf-mpls-icmp-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (December 12, 2006) is 6344 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-13 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Bonica 3 Internet-Draft D. Gan 4 Intended status: Standards Track Juniper Networks 5 Expires: June 15, 2007 D. Tappan 6 C. Pignataro 7 Cisco Systems, Inc. 8 December 12, 2006 10 ICMP Extensions for MultiProtocol Label Switching 11 draft-ietf-mpls-icmp-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 June 15, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo defines an extension object that can be appended to 45 selected multi-part ICMP messages. This extension permits Label 46 Switching Routers to append MPLS information to ICMP messages, and 47 has already been widely deployed. 49 Table of Contents 51 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 4 54 4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. MPLS Label Stack Object . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . . . 9 62 1. Conventions Used In This Document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC2119 [RFC2119]. 68 2. Introduction 70 IP routers use the Internet Control Message Protocol, ICMPv4 71 [RFC0792] and ICMPv6 [RFC4443], to convey control information to 72 source hosts. Network operators use this information to diagnose 73 routing problems. 75 When a router receives an undeliverable IP datagram, it can send an 76 ICMP message to the host that originated the datagram. The ICMP 77 message indicates why the datagram could not be delivered. It also 78 contains the IP header and leading payload octets of the "original 79 datagram" to which the ICMP message is a response. 81 MPLS Label Switching Routers (LSR) also use ICMP to convey control 82 information to source hosts. Sections 2.3 and 2.4 of [RFC3032] 83 describe the interaction between MPLS and ICMP. 85 When an LSR receives an undeliverable MPLS encapsulated datagram, it 86 removes the entire MPLS label stack, exposing the previously 87 encapsulated IP datagram. The LSR then submits the IP datagram to an 88 error processing module. Error processing can include ICMP message 89 generation. 91 The ICMP message indicates why the original datagram could not be 92 delivered. It also contains the IP header and leading octets of the 93 original datagram. 95 The ICMP message, however, contains no information regarding the MPLS 96 label stack that encapsulated the original datagram when it arrived 97 at the LSR. This omission is significant because the LSR would have 98 forwarded the original datagram based upon information contained by 99 the MPLS label stack. 101 This memo defines an ICMP extension object that permits an LSR to 102 append MPLS information to ICMP messages. Selected ICMP messages 103 SHOULD include the MPLS label stack, as it arrived at the router that 104 is sending the ICMP message. The ICMP message MUST also include the 105 IP header and leading payload octets of the original datagram. 107 The ICMP extensions defined in this document must be preceded by an 108 ICMP Extension Structure Header and an ICMP Object Header. Both are 109 defined in [I-D.bonica-internet-icmp]. 111 The ICMP extension defined in this document is equally applicable to 112 ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. Throughout this document, 113 unless otherwise specified, the acronym ICMP refers to multi-part 114 ICMP messages, encompassing both ICMPv4 and ICMPv6. 116 3. Application to TRACEROUTE 118 The ICMP extensions defined in this memo support enhancements to 119 TRACEROUTE. Enhanced TRACEROUTE applications, like older 120 implementations, indicate which nodes the original datagram visited 121 en route to its destination. They differ from older implementations 122 in that they also reflect the original datagram's MPLS encapsulation 123 status as it arrived at each node. 125 Figure 1 contains sample output from an enhanced TRACEROUTE 126 implementation. 128 > traceroute 192.0.2.1 130 traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 40 byte packets 132 1 192.0.2.13 (192.0.2.13) 0.661 ms 0.618 ms 0.579 ms 134 2 192.0.2.9 (192.0.2.9) 0.861 ms 0.718 ms 0.679 ms 136 MPLS Label=100048 Exp=0 TTL=1 S=1 138 3 192.0.2.5 (192.0.2.5) 0.822 ms 0.731 ms 0.708 ms 140 MPLS Label=100016 Exp=0 TTL=1 S=1 142 4 192.0.2.1 (192.0.2.1) 0.961 ms 8.676 ms 0.875 ms 144 Figure 1: Enhanced TRACEROUTE Sample Output 146 4. Disclaimer 148 This memo does not define the general relationship between ICMP and 149 MPLS. Section 2.3 of [RFC3032] defines this relationship. 151 The current memo does not define encapsulation specific TTL 152 manipulation procedures. It defers to Section 5.4 of RFC 3034 153 [RFC3034] and Section 10 of [RFC3035] in this matter. 155 When encapsulation specific TTL manipulation procedures defeat the 156 basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE 157 implementations. 159 5. MPLS Label Stack Object 161 The MPLS Label Stack Object can be appended to the ICMP Time Exceeded 162 and Destination Unreachable messages. A single instance of the MPLS 163 Label Stack Object represents the entire MPLS label stack, formatted 164 exactly as it was when it arrived at the LSR that sends the ICMP 165 message. 167 Figure 2 depicts the MPLS Label Stack Object. It must be preceded by 168 an ICMP Extension Structure Header and an ICMP Object Header. Both 169 are defined in [I-D.bonica-internet-icmp]. 171 In the object payload, octets 0-3 depict the first member of the MPLS 172 label stack. Each remaining member of the MPLS label stack is 173 represented by another 4 octets that share the same format. 175 MPLS Label Stack Class = 1, C-Type = 1. 177 0 1 2 3 178 +-------------+-------------+-------------+-------------+ 179 | Label |EXP |S| TTL | 180 +-------------+-------------+-------------+-------------+ 181 | | 182 | // Remaining MPLS Stack Entries // | 183 | | 184 +-------------+-------------+-------------+-------------+ 186 Figure 2: MPLS Label Stack Object 188 Label: 20 bits 190 Exp: Experimental Use, 3 bits 192 S: Bottom of Stack, 1 bit 194 TTL: Time to Live, 8 bits 196 6. Security Considerations 198 This memo does not specify the conditions that trigger the generation 199 of ICMP Messages for Labeled IP Packets. It does not define the 200 interaction between MPLS and ICMP. However, this document defines an 201 extension that allows an MPLS router to append MPLS information to 202 multi-part ICMP messages, and therefore can provide the user of the 203 traceroute application with additional information. Consequently, a 204 network operator may wish to provide this information selectively 205 based on some policy; for example, only include the MPLS extensions 206 in ICMP messages destined to addresses within the network management 207 blocks with administrative control over the router. An 208 implementation could determine whether to include the MPLS Label 209 Stack extensions based upon the destination address of the ICMP 210 message, or based on a global configuration option in the router. 211 Alternativelly, an implementation may determine whether to include 212 these MPLS extensions when TTL expires based on the number of label 213 stack entries (depth of the label stack) of the incoming packet. 214 Finally, an operator can make use of the TTL treatment on MPLS Pipe 215 Model LSPs defined in [RFC3443] for a TTL-transparent mode of 216 operation, that would prevent ICMP Time Exceeded altogether when 217 tunneled over the MPLS LSP. 219 7. IANA Considerations 221 IANA is requested to assign the following object Class-num in the 222 ICMP Extension Object registry: 224 Class-Num Description 225 1 MPLS Label Stack Class 227 IANA is also requested to establish a registry for the corresponding 228 class sub-type (C-Type) space, as follows: 230 MPLS Label Stack Class Sub-types: 232 C-Type Description 233 1 Incoming MPLS Label Stack 234 0xF7-0xFF Reserved for private use 236 C-Type values are assignable on a first-come-first-serve (FCFS) basis 237 [RFC2434]. 239 8. Normative References 241 [I-D.bonica-internet-icmp] 242 Bonica, R., "Modifying ICMP to Support Multi-part 243 Messages", draft-bonica-internet-icmp-13 (work in 244 progress), December 2006. 246 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 247 RFC 792, September 1981. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 253 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 254 October 1998. 256 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 257 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 258 Encoding", RFC 3032, January 2001. 260 [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label 261 Switching on Frame Relay Networks Specification", 262 RFC 3034, January 2001. 264 [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., 265 Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP 266 and ATM VC Switching", RFC 3035, January 2001. 268 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 269 in Multi-Protocol Label Switching (MPLS) Networks", 270 RFC 3443, January 2003. 272 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 273 Message Protocol (ICMPv6) for the Internet Protocol 274 Version 6 (IPv6) Specification", RFC 4443, March 2006. 276 Authors' Addresses 278 Ronald P. Bonica 279 Juniper Networks 280 2251 Corporate Park Drive 281 Herndon, VA 20171 282 US 284 Email: rbonica@juniper.net 285 Der-Hwa Gan 286 Juniper Networks 287 1194 N. Mathilda Ave. 288 Sunnyvale, CA 94089 289 US 291 Email: dhg@juniper.net 293 Daniel C. Tappan 294 Cisco Systems, Inc. 295 250 Apollo Drive 296 Chelmsford, MA 01824 297 US 299 Email: dan.tappan@gmail.com 301 Carlos Pignataro 302 Cisco Systems, Inc. 303 7025 Kit Creek Road 304 Research Triangle Park, N.C. 27709 305 US 307 Email: cpignata@cisco.com 309 Full Copyright Statement 311 Copyright (C) The Internet Society (2006). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 320 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 321 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 322 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Intellectual Property 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the procedures with respect to rights in RFC documents can be 334 found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org. 349 Acknowledgment 351 Funding for the RFC Editor function is provided by the IETF 352 Administrative Support Activity (IASA).