idnits 2.17.1 draft-ietf-mpls-icmp-00.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. Expected boilerplate is as follows today (2024-04-24) 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 260, but no explicit reference was found in the text == Unused Reference: 'FRAME' is defined on line 268, 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. 'FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSFRAME' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group 2 INTERNET DRAFT Ron Bonica 3 July 1999 MCI WorldCom 4 Expires January 2000 Daniel C. Tappan 5 Cisco Systems 6 Der-Hwa Gan 7 Juniper Networks 9 ICMP Extensions for MultiProtocol Label Switching 10 draft-ietf-mpls-icmp-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC-2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 The current memo proposes extensions to ICMP that permit LSRs to 36 append MPLS information to ICMP messages. 38 2. Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 42 be interpreted as described in [RFC-2119]. 44 3. Introduction 46 Routers and destination hosts use the Internet Control Message 47 Protocol (ICMP) [RFC-792] to convey control information to source 48 hosts. Network operators use this information to detect and diagnose 49 Layer 3 routing problems. 51 When a router receives an undeliverable IP datagram, it can send an 52 ICMP message to the host that originated the datagram. The ICMP 53 message indicates why the datagram could not be delivered. It also 54 contains the IP header and leading payload bytes of the 55 undeliverable datagram. 57 MPLS Label Switching Routers (LSRs) also use ICMP to convey control 58 information to source hosts. Sections 2.3 and 2.4 of [ENCODE] 59 describe the interaction between MPLS and ICMP. 61 When an LSR receives an undeliverable MPLS labeled datagram, it 62 removes the entire MPLS label stack, exposing the encapsulated IP 63 datagram. The router then submits the IP datagram to a network- 64 forwarding module for error processing. Error processing can include 65 ICMP message generation. 67 Although the ICMP message contains the non-delivery reason, IP 68 header and leading payload bytes, it contains no information 69 regarding the MPLS label stack that encapsulated the datagram when 70 it arrived at the LSR. 72 The current memo proposes extensions to ICMP that permit LSRs to 73 append MPLS label stack information to the ICMP message body. Hence, 74 ICMP messages regarding undeliverable MPLS encapsulated datagrams 75 SHOULD include the MPLS label stack, as it arrived at the router 76 that is sending the ICMP message. The ICMP message MUST also include 77 the IP header and leading payload bytes of the undeliverable 78 datagram. 80 Network operators will use this information to detect and diagnose 81 MPLS problems. 83 4. Motivation 85 ICMP extensions defined in the current memo support enhancements to 86 TRACEROUTE. The enhanced TRACEROUTE, like older TRACEROUTE 87 implementations, reports each IP router and LSR that a datagram 88 visits en route to its destination. The enhanced TRACEROUTE differs 89 from older implementations in that it indicates which nodes were 90 visited while traversing a Label Switched Path (LSP). 92 Figure 1 contains sample output from an enhanced TRACEROUTE 93 implementation. 95 >Traceroute 166.45.2.74 96 traceroute to 166.45.2.74, 30 hops max, 40 byte packets 97 1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms 99 2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms 100 mplsLabel1=2001 mplsExpBits1=0 101 3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms 102 mplsLabel1=2002 mplsExpBits1=0 103 4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms 104 mplsLabel1=2003 mplsExpBits1=0 105 5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms 106 6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms 108 Figure 1. Enhanced TRACEROUTE sample output 110 5. Disclaimer 112 The current memo does not define the general relationship between 113 ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this 114 relationship. 116 Specifically, this document defers to [ENCODE] with respect to the 117 following issues: 119 - conditions upon which LSRs emit ICMP messages 120 - handling of ICMP messages bound for hosts that are identified 121 by private addresses 123 The current memo does not define encapsulation specific TTL 124 manipulation procedures. It defers to Section 10 of [MPLSATM] and 125 Section 5.4 of [MPLSFRAME] in this matter. 127 When encapsulation specific TTL manipulation procedures defeat the 128 basic TRACEROUTE mechanism, they will also defeat enhanced 129 TRACEROUTE implementations. 131 6. Backward Compatibility 133 ICMP extensions proposed in this document MUST be backward 134 compatible with the syntax described in RFC-792. Extensions proposed 135 in this memo MUST NOT change or deprecate any field defined in RFC- 136 792. 138 7. Formal Syntax 140 This section describes a data structure that can be appended to the 141 following ICMP message types: 143 1) Destination Unreachable 144 2) Time Exceeded 145 3) Parameter Problem 146 4) Source Quench 147 5) Redirect 149 The above listed ICMP message types specify a fixed length of 56 150 bytes. When the data structure defined in this section is appended 151 to an ICMP message, the ICMP _total length_ field MUST equal the 152 data structure length plus 56. 154 The data structure defined in this section consists of a common 155 header followed by object instances. Each object instance consists 156 of an object header plus contents. 158 Currently, only one object class is defined. This object class 159 contains an entire MPLS label stack, formatted exactly as it was 160 when it arrived at the LSR that sends the ICMP message. 162 In the future, additional object classes may be defined. 164 7.1 Common Header 166 0 1 2 3 167 +-------------+-------------+-------------+-------------+ 168 | Vers | (Reserved) | Checksum | 169 +-------------+-------------+-------------+-------------+ 171 The fields in the common header are as follows: 173 Vers: 4 bits 175 ICMP extension version number. This is version 1. 177 Checksum: 16 bits 179 The one's complement of the one's complement sum of the data 180 structure, with the checksum field replaced by zero for the 181 purpose of computing the checksum. An all-zero value means that 182 no checksum was transmitted. 184 If the checksum field contains a value other than described 185 above, bytes 56 and beyond of the ICMP message do not contain 186 the data structure described by this memo. These bytes may 187 contain an extended ICMP payload as described in Section 4.3.2.3 188 of [RFC-1812]. 190 Reserved: 192 Must be set to 0. 194 7.2 Object Header 196 Every object consists of one or more 32-bit words with a one-word 197 header, with the following format: 199 0 1 2 3 200 +-------------+-------------+-------------+-------------+ 201 | Length | Class-Num | C-Type | 202 +-------------+-------------+-------------+-------------+ 203 | | 204 // (Object contents) // 205 | | 206 +-------------+-------------+-------------+-------------+ 208 An object header has the following fields: 210 Length: 16 bits 212 Length of the object, measured in bytes, including the object 213 header and object contents. 215 Class-Num: 8 bits 217 Identifies object class. Currently, the only one object class 218 is defined. This is the MPLS Stack Entry Object. 220 C-Type: 8 bits 222 Identifies object sub-type. Currently, only one object sub-type 223 is defined. 225 7.3 MPLS Stack Entry Object Class 227 An instance of the MPLS Entry Object class represents the entire 228 MPLS label stack, formatted exactly as it was when it arrived at the 229 LSR that sends the ICMP message. 231 In the illustration below, bytes 0-3 depict the first member of the 232 MPLS label stack. Each remaining member of the MPLS label stack is 233 represented by another 4 bytes that share the same format. 235 Syntax follows: 237 MPLS Stack Entry Class = 1, C-Type = 1. 239 0 1 2 3 240 +-------------+-------------+-------------+-------------+ 241 | Label |EXP |S| TTL | 242 +-------------+-------------+-------------+-------------+ 243 | | 244 // Remaining MPLS Stack Entries // 245 | | 246 +-------------+-------------+-------------+-------------+ 248 Label: 20 bits 249 Exp: Experimental Use, 3 bits 250 S: Bottom of Stack, 1 bit 251 TTL: Time to Live, 8 bits 253 8.Security Considerations 255 This memo presents no security considerations beyond those already 256 presented by current ICMP applications (e.g., traceroute). 258 9. References 260 [ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 261 Label Switching Architecture", Internet Draft , July, 1998 264 [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., 265 Fedorkow, G., Li, T., Conta, A., _MPLS Stack Encoding_, Internet 266 Draft, , September 1998. 268 [FRAME], Callon, R., Doolan, P., Feldman, N., Fredette, A., 269 Swallow, G., and A. Viswanathan, "A Framework for Multiprotocol 270 Label Switching", Internet Draft , 271 November 1997. 273 [MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., 274 Rosen, E., Swallow, G, _MPLS using ATM VC Switching_, , November, 1998. 277 [MPLSFRAME], Conta, A., Doolan, P., Malis, A., _Use of Label 278 Switching on Frame Relay Networks_, , 279 November, 1998. 281 [RFC-792], Postel, J., _Internet Control Message Protocol_, RFC 792, 282 ISI, September 1981. 284 [RFC-1812], Baker, F., _Requirements for IP Version 4 Routers_, RFC 285 1812, June 1995. 287 [RFC-2026], Bradner, S., _Internet Standards Process _ Revision 3_, 288 RFC 2026, Harvard University, October 1996. 290 [RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate 291 Requirement Levels", RFC 2119, Harvard University, March 1997 293 10. Author's Addresses 295 Ronald P. Bonica 296 MCI WorldCom 297 2100 Reston Parkway 298 Reston, Virginia, U.S.A. 20191 299 Phone: +1 703 715 7176 300 Email: rbonica@mci.net 302 Daniel C. Tappan 303 Cisco Systems 304 250 Apollo Drive 305 Chelmsford, Massachusetts, 01824 306 Email: tappan@cisco.com 308 Der-Hwa Gan 309 Juniper Networks 310 385 Ravendale Drive 311 Mountain View, California 94043 312 Email: dhg@juniper.net