idnits 2.17.1 draft-ietf-mpls-icmp-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 439. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (August 2, 2005) is 6841 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: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Expires: February 3, 2006 Juniper Networks 5 D. Tappan 6 Cisco Systems, Inc. 7 August 2, 2005 9 ICMP Extensions for MultiProtocol Label Switching 10 draft-ietf-mpls-icmp-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 3, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo proposes extensions to ICMP that permit Label Switching 44 Routers to append MPLS information to ICMP messages. 46 Table of Contents 48 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . 5 51 4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 8 54 5.2 Object Header . . . . . . . . . . . . . . . . . . . . . . 8 55 5.3 MPLS Stack Entry Object Class . . . . . . . . . . . . . . 9 56 5.4 Extended Payload Object Class . . . . . . . . . . . . . . 10 57 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 62 Intellectual Property and Copyright Statements . . . . . . . . 15 64 1. Conventions Used In This Document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC2119 [1]. 70 2. Introduction 72 IP routers use the Internet Control Message Protocol (ICMP) [2] to 73 convey control information to source hosts. Network operators use 74 this information to diagnose routing problems. 76 When a router receives an undeliverable IP datagram, it can send an 77 ICMP message to the host that originated the datagram. The ICMP 78 message indicates why the datagram could not be delivered. It also 79 contains the IP header and leading payload octets of the "original 80 datagram". 82 In this document, the term "original datagram" refers to the datagram 83 to which the ICMP message is a response. 85 MPLS Label Switching Routers (LSR) also use ICMP to convey control 86 information to source hosts. Sections 2.3 and 2.4 of RFC 3032 [3] 87 describe the interaction between MPLS and ICMP. 89 When an LSR receives an undeliverable MPLS encapsulated datagram, it 90 removes the entire MPLS label stack, exposing the previously 91 encapsulated IP datagram. The LSR then submits the IP datagram to an 92 error processing module. Error processing can include ICMP message 93 generation. 95 The ICMP message indicates why the original datagram could not be 96 delivered. It also contains the IP header and leading octets of the 97 original datagram. 99 The ICMP message, however, contains no information regarding the MPLS 100 label stack that encapsulated the original datagram when it arrived 101 at the LSR. This omission is significant because the LSR would have 102 routed the original datagram based upon information contained by the 103 MPLS label stack. 105 This memo proposes extensions to ICMP that permit an LSR to append 106 MPLS label stack information to ICMP messages. ICMP messages 107 regarding MPLS encapsulated datagrams SHOULD include the MPLS label 108 stack, as it arrived at the router that is sending the ICMP message. 109 The ICMP message MUST also include the IP header and leading payload 110 octets of the original datagram. 112 3. Application to TRACEROUTE 114 ICMP extensions defined in this memo support enhancements to 115 TRACEROUTE. The enhanced TRACEROUTE, like older implementations, 116 indicates which nodes the original datagram visited en route to its 117 destination. It differs from older implementations in that it also 118 indicates the original datagrams MPLS encapsulation status as it 119 arrived at each node. 121 Figure 1 contains sample output from an enhanced TRACEROUTE 122 implementation. 124 > traceroute 100.100.6.1 126 traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 128 1 10.1.1.2 (10.1.1.2) 0.661 ms 0.618 ms 0.579 ms 130 2 10.1.12.2 (10.1.12.2) 0.861 ms 0.718 ms 0.679 ms 132 MPLS Label=100048 Exp=0 TTL=1 S=1 134 3 10.1.24.2 (10.1.24.2) 0.822 ms 0.731 ms 0.708 ms 136 MPLS Label=100016 Exp=0 TTL=1 S=1 138 4 10.100.6.1 (10.100.6.1) 0.961 ms 8.676 ms 0.875 ms 140 Figure 1: Enhanced TRACEROUTE Sample Output 142 4. Disclaimer 144 This memo does not define the general relationship between ICMP and 145 MPLS. Sections 2.3 and 2.4 of RFC3032 define this relationship. 147 Specifically, this document defers to RFC3032 with respect to the 148 following issues: 150 - conditions upon which an LSR emits ICMP messages 152 - handling of ICMP messages bound for hosts that are identified by 153 private addresses 155 The current memo does not define encapsulation specific TTL 156 manipulation procedures. It defers to Section 5.4 of RFC 3034 [4] 157 and Section 10 of RFC 3035 [5] in this matter. 159 When encapsulation specific TTL manipulation procedures defeat the 160 basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE 161 implementations. 163 The current memo does not address extensions to ICMPv6. These should 164 be addressed in a separate draft. 166 5. Syntax 168 This section defines a data structure that an LSR can append to 169 selected ICMP messages. The data structure contains the MPLS label 170 stack that encapsulated the original datagram when it arrived at the 171 LSR. 173 In theory, the data structure defined herein can be appended to the 174 following ICMP message types: 176 Destination Unreachable 178 Time Exceeded 180 Parameter Problem 182 Source Quench 184 Redirect 186 However, in practice, it would only be useful when appended to the 187 Destination Unreachable and Time Exceeded messages. 189 According to RFC-792, bytes 0 through 19 of any ICMP message contain 190 a header whose format is analogous to that of the IP datagram. Bytes 191 20 through 23 contain an ICMP message type, code and checksum. Bytes 192 24 through 27 contain message specific data. 194 Also according to RFC-792, the final field contained by each of the 195 ICMP message types listed above begins at byte 28. It reflects the 196 IP header and leading 64 bits of the original datagram. RFC 1812 [6] 197 recommends that this final field be extended to include as much of 198 the original datagram as possible. 200 When an LSR appends the data structure defined herein to an ICMP 201 message, the final field of the ICMP message body MUST contain the 202 first 128 octets of the original datagram. At least 20 of these 128 203 octets represent the IP header of the original datagram. 205 If the original datagram was shorter than 128 octets, the final field 206 MUST be padded with 0's. 208 When an LSR appends the data structure defined herein to an ICMP 209 message, the ICMP "total length" MUST be adjusted appropriately to 210 include the data structure. 212 The data structure defined in this section consists of a common 213 header followed by object instances. Each object instance consists 214 of an object header plus contents. 216 Currently, two object classes are defined. One object class contains 217 an entire MPLS label stack, formatted exactly as it was when it 218 arrived at the LSR that sends the ICMP message. The other contains 219 some portion of the original datagram that could not be included in 220 the final field of the ICMP message body (i.e., the octet 129 and 221 beyond). 223 Both object classes are optional. 225 In the future, additional object classes may be defined. 227 5.1 Common Header 229 0 1 2 3 230 +-------------+-------------+-------------+-------------+ 231 | Vers | (Reserved) | Checksum | 232 +-------------+-------------+-------------+-------------+ 234 Figure 2: Common Header 236 The fields in the common header are as follows: 238 Vers: 4 bits 240 ICMP extension version number. This is version 2. 242 Checksum: 16 bits 244 The one's complement of the one's complement sum of the data 245 structure, with the checksum field replaced by zero for the 246 purpose of computing the checksum. An all-zero value means that 247 no checksum was transmitted. 249 If the checksum field contains a value other than described above, 250 the ICMP message does not include the extensions described in this 251 memo. This, however, does not imply that the ICMP message is 252 malformed. It may be in strict compliance with RFC-1812. 254 Reserved: Must be set to 0. 256 5.2 Object Header 258 Every object consists of one or more 32-bit words with a one-word 259 header. The following is the format of the one-word header: 261 +-------------+-------------+-------------+-------------+ 262 | Length | Class-Num | C-Type | 263 +-------------+-------------+-------------+-------------+ 264 | | 265 | // (Object contents) // | 266 | | 267 +-------------+-------------+-------------+-------------+ 269 Figure 3: Object Header 271 An object header has the following fields: 273 Length: 16 bits 275 Length of the object, measured in octets, including the object 276 header and object contents. 278 Class-Num: 8 bits 280 Identifies object class. 282 C-Type: 8 bits 284 Identifies object sub-type. 286 5.3 MPLS Stack Entry Object Class 288 A single instance of the MPLS Entry Object class represents the 289 entire MPLS label stack, formatted exactly as it was when it arrived 290 at the LSR that sends the ICMP message 292 In the illustration below, octets 0-3 depict the first member of the 293 MPLS label stack. Each remaining member of the MPLS label stack is 294 represented by another 4 octets that share the same format. 296 Syntax follows: 298 MPLS Stack Entry Class = 1, C-Type = 1. 300 0 1 2 3 301 +-------------+-------------+-------------+-------------+ 302 | Label |EXP |S| TTL | 303 +-------------+-------------+-------------+-------------+ 304 | | 305 | // Remaining MPLS Stack Entries // | 306 | | 307 +-------------+-------------+-------------+-------------+ 309 Figure 4: MPLS Stack Entry Object Class 311 Label: 20 bits 313 Exp: Experimental Use, 3 bits 315 S: Bottom of Stack, 1 bit 317 TTL: Time to Live, 8 bits 319 5.4 Extended Payload Object Class 321 An instance of the Extended Payload Object class represents some 322 portion of the original datagram that could not be fit in the final 323 field of the ICMP message body (i.e., octets beyond 128). 325 Syntax follows: 327 MPLS Stack Entry Class = 2, C-Type = 1. 329 0 1 2 3 330 +-------------+-------------+-------------+-------------+ 331 | | 332 | // Additional bytes of original datagram // | 333 | | 334 +-------------+-------------+-------------+-------------+ 336 Figure 5: Extended Payload Object Class 338 6. Backward Compatibility 340 ICMP extensions proposed in this document MUST be backward compatible 341 with the syntax described in RFC-792. Extensions proposed in this 342 memo MUST NOT change or deprecate any field defined in RFC-792. 344 The extensions defined herein are in keeping with the spirit, if not 345 the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- 346 1812 extends the final field of selected ICMP messages to include a 347 greater portion of the original datagram. Unfortunately, it extends 348 this field to a variable length without adding a length attribute. 350 This memo binds the length of that final field to an arbitrarily 351 large value (128 octets). Fixing the length of that field 352 facilitates extension of the ICMP message. An additional object is 353 provided through which octets 129 and beyond can be appended to the 354 ICMP message. 356 As few datagrams contain L3 or L4 header information beyond octet 357 128, it is unlikely that the extensions described herein will disable 358 any applications that rely upon RFC-1812 style ICMP messages. 360 7. Security Considerations 362 This memo presents no security considerations beyond those already 363 presented by current ICMP applications (e.g., traceroute). 365 8. IANA Considerations 367 IANA should establish a registry of ICMP extention classes and class- 368 sub-types. 370 9. Normative References 372 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 373 Levels", BCP 14, RFC 2119, March 1997. 375 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 376 September 1981. 378 [3] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., 379 Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, 380 January 2001. 382 [4] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on 383 Frame Relay Networks Specification", RFC 3034, January 2001. 385 [5] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., 386 Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC 387 Switching", RFC 3035, January 2001. 389 [6] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 390 June 1995. 392 Authors' Addresses 394 Ronald P. Bonica 395 Juniper Networks 396 2251 Corporate Park Drive 397 Herndon, VA 20171 398 US 400 Email: rbonica@juniper.net 402 Der-Hwa Gan 403 Juniper Networks 404 1194 N. Mathilda Ave. 405 Sunnyvale, CA 94089 406 US 408 Email: dhg@juniper.net 409 Daniel C. Tappan 410 Cisco Systems, Inc. 411 250 Apollo Drive 412 Chelmsford, MA 01824 413 US 415 Email: tappan@cisco.com 417 Intellectual Property Statement 419 The IETF takes no position regarding the validity or scope of any 420 Intellectual Property Rights or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; nor does it represent that it has 424 made any independent effort to identify any such rights. Information 425 on the procedures with respect to rights in RFC documents can be 426 found in BCP 78 and BCP 79. 428 Copies of IPR disclosures made to the IETF Secretariat and any 429 assurances of licenses to be made available, or the result of an 430 attempt made to obtain a general license or permission for the use of 431 such proprietary rights by implementers or users of this 432 specification can be obtained from the IETF on-line IPR repository at 433 http://www.ietf.org/ipr. 435 The IETF invites any interested party to bring to its attention any 436 copyrights, patents or patent applications, or other proprietary 437 rights that may cover technology that may be required to implement 438 this standard. Please address the information to the IETF at 439 ietf-ipr@ietf.org. 441 Disclaimer of Validity 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 446 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 447 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 448 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 Copyright Statement 453 Copyright (C) The Internet Society (2005). This document is subject 454 to the rights, licenses and restrictions contained in BCP 78, and 455 except as set forth therein, the authors retain all their rights. 457 Acknowledgment 459 Funding for the RFC Editor function is currently provided by the 460 Internet Society.