idnits 2.17.1 draft-ietf-mpls-icmp-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 393 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2000) is 8654 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) == Unused Reference: 'ARCH' is defined on line 333, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ENCODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSFRAME' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group R.Bonica 2 Internet Draft MCIWorldCom 3 Document: draft-ietf-mpls-icmp-02.txt D.Tappan 4 Cisco Systems 5 D.Gan 6 Juniper Networks 7 August 2000 9 ICMP Extensions for MultiProtocol Label Switching 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC-2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 The current memo proposes extensions to ICMP that permit Label 33 Switching Routers to append MPLS information to ICMP messages. 35 2. Conventions used in this document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 39 this document are to be interpreted as described in [RFC-2119]. 41 3. Introduction 43 Routers and destination hosts use the Internet Control Message 44 Protocol (ICMP) [RFC-792] to convey control information to source 45 hosts. Network operators use this information to diagnose routing 46 problems. 48 Bonica, Tappan, Hwa Draft-Expires February 2001 1 49 When a router receives an undeliverable IP datagram, it can send an 50 ICMP message to the host that originated the datagram. The ICMP 51 message indicates why the datagram could not be delivered. It also 52 contains the IP header and leading payload octets of the "original 53 datagram". 55 In this document, the term "original datagram" refers to the 56 datagram to which the ICMP message is a response. 58 MPLS Label Switching Routers (LSR) also use ICMP to convey control 59 information to source hosts. Sections 2.3 and 2.4 of [ENCODE] 60 describe the interaction between MPLS and ICMP. 62 When an LSR receives an undeliverable MPLS encapsulated datagram, it 63 removes the entire MPLS label stack, exposing the previously 64 encapsulated IP datagram. The LSR then submits the IP datagram to a 65 network-forwarding module for error processing. Error processing can 66 include ICMP message generation. 68 The ICMP message indicates why the original datagram could not be 69 delivered. It also contains the IP header and leading octets of the 70 original datagram. 72 The ICMP message, however, includes no information regarding the 73 MPLS label stack that encapsulated the original datagram when it 74 arrived at the LSR. This omission is significant because the LSR 75 would have routed the original datagram based upon information 76 contained by the MPLS label stack. 78 The current memo proposes extensions to ICMP that permit an LSR to 79 append MPLS label stack information to ICMP messages. ICMP messages 80 regarding MPLS encapsulated datagrams SHOULD include the MPLS label 81 stack, as it arrived at the router that is sending the ICMP message. 82 The ICMP message MUST also include the IP header and leading payload 83 octets of the original datagram. 85 Network operators will use this information to diagnose routing 86 problems. 88 4. Motivation 90 ICMP extensions defined in the current memo support enhancements to 91 TRACEROUTE. The enhanced TRACEROUTE, like older implementations, 92 indicates which nodes the original datagram visited en route to its 93 ultimate destination. It differs from older implementations in that 94 it also indicates the original datagrams MPLS encapsulation status 95 as it arrived at each node. 97 Figure 1 contains sample output from an enhanced TRACEROUTE 98 implementation. 100 Bonica,Tappan,Gan Draft-Expires February 2001 2 101 >Traceroute 166.45.2.74 102 traceroute to 166.45.2.74, 30 hops max, 40 byte packets 103 1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms 104 2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2001 105 mplsExpBits1=0 106 3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2002 107 mplsExpBits1=0 108 4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2003 109 mplsExpBits1=0 110 5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms 111 6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms 113 Figure 1. Enhanced TRACEROUTE sample output 115 5. Disclaimer 117 The current memo does not define the general relationship between 118 ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this 119 relationship. 121 Specifically, this document defers to [ENCODE] with respect to the 122 following issues: 124 - conditions upon which an LSR emits ICMP messages 125 - handling of ICMP messages bound for hosts that are identified 126 by private addresses 128 The current memo does not define encapsulation specific TTL 129 manipulation procedures. It defers to Section 10 of [MPLSATM] and 130 Section 5.4 of [MPLSFRAME] in this matter. 132 When encapsulation specific TTL manipulation procedures defeat the 133 basic TRACEROUTE mechanism, they will also defeat enhanced 134 TRACEROUTE implementations. 136 The current memo does not address extensions to ICMPv6. These should 137 be addressed in a separate draft. 139 6. Formal Syntax 141 This section defines a data structure that an LSR can append to 142 selected ICMP messages. The data structure contains the MPLS label 143 stack that encapsulated the original datagram when it arrived at the 144 LSR. 146 The data structure defined herein can be appended to the following 147 ICMP message types: 149 Bonica,Tappan,Gan Draft-Expires February 2001 3 150 1) Destination Unreachable 151 2) Time Exceeded 152 3) Parameter Problem 153 4) Source Quench 154 5) Redirect 156 According to RFC-792, bytes 0 through 19 of any ICMP message contain 157 a header whose format is analogous to that of the IP datagram. Bytes 158 20 through 23 contain an ICMP message type, code and checksum. Bytes 159 24 through 27 contain message specific data. 161 Also according to RFC-792, the final field contained by each of the 162 ICMP message types listed above begins at byte 28. It reflects the 163 IP header and leading 64 bits of the original datagram. [RFC-1812] 164 recommends that this final field be extended to include as much of 165 the original datagram as possible. 167 When an LSR appends the data structure defined herein to an ICMP 168 message, the final field of the ICMP message body MUST contain the 169 first 128 octets of the original datagram. At least 20 of these 128 170 octets represent the IP header of the original datagram. 172 If the original datagram was shorter than 128 octets, the final 173 field MUST be padded with 0's. 175 When an LSR appends the data structure defined herein to an ICMP 176 message, the ICMP "total length" MUST be equal to the data structure 177 length plus 156. The first octet of the data structure must be 178 displaced 156 octets from the beginning of the ICMP message. 180 The data structure defined in this section consists of a common 181 header followed by object instances. Each object instance consists 182 of an object header plus contents. 184 Currently, two object classes are defined. One object class contains 185 an entire MPLS label stack, formatted exactly as it was when it 186 arrived at the LSR that sends the ICMP message. The other contains 187 some portion of the original datagram that could not be included in 188 the final field of the ICMP message body (i.e., the octet 129 and 189 beyond). 191 Both object classes are optional. 193 In the future, additional object classes may be defined. 195 Bonica,Tappan,Gan Draft-Expires February 2001 4 196 6.1 Common Header 198 0 1 2 3 199 +-------------+-------------+-------------+-------------+ 200 | Vers | (Reserved) | Checksum | 201 +-------------+-------------+-------------+-------------+ 203 The fields in the common header are as follows: 205 Vers: 4 bits 207 ICMP extension version number. 209 This is version 2. 211 Checksum: 16 bits 213 The one's complement of the one's complement sum of the data 214 structure, with the checksum field replaced by zero for the purpose 215 of computing the checksum. An all-zero value means that no checksum 216 was transmitted. 218 If the checksum field contains a value other than described above, 219 the ICMP message does not include the extensions described in this 220 memo. This, however, does not imply that the ICMP message is 221 malformed. It may be in strict compliance with RFC-1812. 223 Reserved: Must be set to 0. 225 6.2 Object Header 227 Every object consists of one or more 32-bit words with a one-word 228 header, with the following format: 230 +-------------+-------------+-------------+-------------+ 231 | Length | Class-Num | C-Type | 232 +-------------+-------------+-------------+-------------+ 233 | | 234 | // (Object contents) // | 235 | | 236 +-------------+-------------+-------------+-------------+ 238 An object header has the following fields: 240 Length: 16 bits 242 Length of the object, measured in octets, including the object 243 header and object contents. 244 Bonica,Tappan,Gan Draft-Expires February 2001 5 245 Class-Num: 8 bits 247 Identifies object class. 249 C-Type: 8 bits 251 Identifies object sub-type. 253 6.3 MPLS Stack Entry Object Class 255 A single instance of the MPLS Entry Object class represents the 256 entire MPLS label stack, formatted exactly as it was when it arrived 257 at the LSR that sends the ICMP message 259 In the illustration below, octets 0-3 depict the first member of the 260 MPLS label stack. Each remaining member of the MPLS label stack is 261 represented by another 4 octets that share the same format. 263 Syntax follows: 265 MPLS Stack Entry Class = 1, C-Type = 1. 267 0 1 2 3 268 +-------------+-------------+-------------+-------------+ 269 | Label |EXP |S| TTL | 270 +-------------+-------------+-------------+-------------+ 271 | | 272 | // Remaining MPLS Stack Entries // | 273 | | 274 +-------------+-------------+-------------+-------------+ 276 Label: 20 bits 278 Exp: Experimental Use, 3 bits 280 S: Bottom of Stack, 1 bit 282 TTL: Time to Live, 8 bits 284 6.4 Extended Payload Object Class 286 An instance of the Extended Payload Object class represents some 287 portion of the original datagram that could not be fit in the final 288 field of the ICMP message body (i.e., octets beyond 128). 290 Bonica,Tappan,Gan Draft-Expires February 2001 6 291 Syntax follows: 293 MPLS Stack Entry Class = 2, C-Type = 1. 295 0 1 2 3 296 +-------------+-------------+-------------+-------------+ 297 | | 298 | // Additional bytes of original datagram // | 299 | | 300 +-------------+-------------+-------------+-------------+ 302 7. Backward Compatibility 304 ICMP extensions proposed in this document MUST be backward 305 compatible with the syntax described in RFC-792. Extensions proposed 306 in this memo MUST NOT change or deprecate any field defined in RFC- 307 792. 309 The extensions defined herein are in keeping with the spirit, if not 310 the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- 311 1812 extends the final field of selected ICMP messages to include a 312 greater portion of the original datagram. Unfortunately, it extends 313 this field to a variable length without adding a length attribute. 315 This memo binds the length of that final field to an arbitrarily 316 large value (128 octets). Fixing the length of that field 317 facilitates extension of the ICMP message. An additional object is 318 provided through which octets 129 and beyond can be appended to the 319 ICMP message. 321 As few datagrams contain L3 or L4 header information beyond octet 322 128, it is unlikely that the extensions described herein will 323 disable any applications that rely upon RFC-1812 style ICMP 324 messages. 326 8. Security Considerations 328 This memo presents no security considerations beyond those already 329 presented by current ICMP applications (e.g., traceroute). 331 9. References 333 [ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 334 Label Switching Architecture", Internet Draft , August, 1999 337 Bonica,Tappan,Gan Draft-Expires February 2001 7 339 [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., 340 Fedorkow, G., Li, T., Conta, A., "MPLS Stack Encoding", Internet 341 Draft, , September 1999. 343 [MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., 344 Rosen, E., Swallow, G, "MPLS using LDP and ATM VC Switching", 345 , June 2000. 347 [MPLSFRAME], Conta, A., Doolan, P., Malis, A., "Use of Label 348 Switching on Frame Relay Networks", , 349 June, 2000. 351 [RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792, 352 ISI, September 1981. 354 [RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC 355 1812, June 1995. 357 [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", 358 RFC 2026, Harvard University, October 1996. 360 [RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate 361 Requirement Levels", RFC 2119, Harvard University, March 1997 363 10. Acknowledgments 365 Thanks to Yakov Rekhter and Mike Heard for their contributions to 366 this memo. 368 11. Author's Addresses 370 Ronald P. Bonica 371 MCI WorldCom 372 22001 Loudoun County Pkwy 373 Ashburn, Virginia, 20147 374 Phone: 703 886 1681 375 Email: rbonica@mci.net 377 Daniel C. Tappan 378 Cisco Systems 379 250 Apollo Drive 380 Chelmsford, Massachusetts, 01824 381 Email: tappan@cisco.com 383 Der-Hwa Gan 384 Juniper Networks 385 385 Ravendale Drive 386 Mountain View, California 94043 387 Bonica,Tappan,Gan Draft-Expires February 2001 8 388 Email: dhg@juniper.net 390 Bonica,Tappan,Gan Draft-Expires February 2001 9 391 Full Copyright Statement 393 "Copyright (C) The Internet Society (date). All Rights Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain it 396 or assist in its implmentation may be prepared, copied, published 397 and distributed, in whole or in part, without restriction of any 398 kind, provided that the above copyright notice and this paragraph 399 are included on all such copies and derivative works. However, this 400 document itself may not be modified in any way, such as by removing 401 the copyright notice or references to the Internet Society or other 402 Internet organizations, except as needed for the purpose of 403 developing Internet standards in which case the procedures for 404 copyrights defined in the Internet Standards process must be 405 followed, or as required to translate it into 407 Bonica,Tappan,Gan Draft-Expires February 2001 10