idnits 2.17.00 (12 Aug 2021) /tmp/idnits61716/draft-zzhang-mpls-icmp-bier-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3032, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- 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 (June 30, 2015) is 2510 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) == Missing Reference: 'TBD' is mentioned on line 149, but not defined == Unused Reference: 'RFC2119' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC4884' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'RFC4950' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'I-D.kumarzheng-bier-ping' is defined on line 256, but no explicit reference was found in the text == Outdated reference: draft-ietf-bier-architecture has been published as RFC 8279 == Outdated reference: A later version (-03) exists of draft-kumarzheng-bier-ping-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Zhang 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 3032 (if approved) June 30, 2015 5 Intended status: Standards Track 6 Expires: January 1, 2016 8 MPLS ICMP for BIER Payload 9 draft-zzhang-mpls-icmp-bier-01.txt 11 Abstract 13 This document specifies an optional extension to generate ICMP 14 messages for BIER packets transported over LSPs. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC2119. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 1, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 6.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 RFC3032 specifies that an LSR may generate ICMP messages if the 69 payload is IPv4 or IPv6. Normally the ICMP messages are label 70 switched using the original label stack, and the egress LSR will then 71 forward the the messages to the source of the packet. 73 BIER [wijnands-bier-architecture] is a new multicast forwarding 74 architecture and [kumarzheng-bier-ping] specifies ping/traceroute 75 procedures for BIER. BIER traceroute uses the same TTL-expiration 76 principle of IPv4/IPv6 unicast traceroute. A BFR (a router that 77 supports BIER) may get a traceroute probe message whose TTL just 78 expired at this hop and may send back a response, allowing a BFIR 79 (ingress BFR) to gather the paths that a BIER packet traverses. 81 It's possible that a BIER packet is transported over an LSP between 82 two BFRs. If Uniform Model for TTL is used for the LSP, when the 83 ingress LER for the LSP put the BIER packet with a preceeding BIER 84 label into the tunnel, the TTL from the BIER label is copied to the 85 outgoing label for the LSP. As a result, the TTL expiration may 86 happen on an LSR on the LSP, who will silently drop the packet. This 87 TTL expiration could easily happen with traceroute, because the BFR 88 that initiates the tracing will increase the TTL to be used one by 89 one to discover the path. The silent drop by an LSR is therefore 90 undesired. 92 If the LSR can generate an ICMP message for the TTL expiration, label 93 switch it to the LER that advertised the inner most label just like 94 in the IPv4/IPv6 case, that LER, which is is a BFR, will be able to 95 process the TTL expiration for BIER traceroute purpose. 97 Note that in IPv4/IPv6 case, the generated ICMP message is addressed 98 to the packet's source address and the message will be transparently 99 routed back to the source of the packet by the LER that advertised 100 the inner most label in the stack. For BIER, the ICMP message is to 101 be processed by the LER that advertised the inner most label. 102 Therefore, the destination address of the ICMP message is set to 103 local host address 127.0.0.1 or ::1, depending on if the MPLS 104 infrastructure is based on IPv4 or IPv6. 106 In the following example diagram, there is an ingress BFR (BFIR), an 107 egress BFR (BFER), and two transit BFRs (BFR1/BFR2) separated by two 108 non-BFRs. When BFIR sends a BIER packet, BFR1 will put the BIER 109 packets into a tunnel between BFR1 and BFR2. If Uniform model is 110 used on BFR1, the tunneled packet could have TTL expiration on non- 111 BFR1. When that happens, non-BFR1 will generate an ICMP message 112 addressed to local host address 127.0.0.1 or ::1, and label switch to 113 BFR2. BFR2 will then process the ICMP message and may send 114 appropriate response to the BFIR. 116 BFIR --- BFR1 --- non-BFR1 --- non-BFR2 --- BFR2 --- BFER 117 \...........tunnel................../ 118 ^ 119 | 120 ttl-expiration on non-BFR1; 121 generated ICMP message label switched to, 122 and processed by BFR2 124 Figure 1 126 In theory, it is possible that the outer LSP for which the LSR is 127 having TTL expiration is the base LSP for a stacked LSP and the 128 latter uses a differently versioned IP infrastructure, so the version 129 of the ICMP message may be chosen incorrectly. In reality, this is 130 unlikely to happen because the label stack is to transport BIER 131 packets between two BFRs that are in the same IGP domain. Even if it 132 does happen, it is likely that the LER is able to process both ICMP 133 and ICMPv6 messages, and even if the LER is not able to process the 134 incoming ICMP/ICMPv6 message it can discard the message silently - 135 not much different from the LSR not generating the message the first 136 place. 138 It is expected that the BIER encapsulation header will start with a 139 4-bit nibble with a unique value that suggests that it is a BIER 140 packet. 142 This specification focuses on ICMP message generated for TTL 143 expiration. Other types of ICMP messages are out of the scope at 144 this time. 146 2. Speficications 148 When an LSR experiences a TTL expiration for a labeled packet and the 149 first 4-bit nibble is X [TBD], the LSR MAY generate an ICMP message 150 if the MPLS infrastructure is IPv4 based, or an ICMPv6 message if the 151 MPLS infrastructure is IPv6 based. The destination of the message is 152 127.0.0.1 in case of IPv4 or ::1 in case of IPv6. The source of the 153 message is a routable address of the LSR. 155 The LSR, if it supports BIER, MAY further check the BIER payload 156 type. If the "proto" field of the BIER header is "BIER OAM", the LSR 157 SHOULD generate an ICMP or ICMPv6 message. 159 To differentiate from ICMP/ICMPv6 messages generated for IPv4/IPv6 160 playloads, the following message types are defined: 162 ICMP messages: 163 Type TBD1: TTL expired in tunnel 164 ICMPV6 messages: 165 Type TBD2: TTL expired in tunnel 167 Alternatively, same message types but different code could be used to 168 differentiate from IPv4/IPv6 payload triggered messages. [This will 169 be decided based on WG input] 171 Except for the differences mentioned above in message type/code, 172 destination address, and ICMP/ICMPv6 choice based on MPLS 173 infrastructure type, the ICMP/ICMPv6 messages are constructed 174 following existing procedures for IPv4/IPv6 payload. The generated 175 messages are label switched using the invoking packet's original 176 label stack minus the inner most label. The original inner most 177 label for a BIER packet is a BIER label indicating that the payload 178 type is BIER, so it must not be used for switching the generated 179 ICMP/ICMPv6 messages, which are not BIER packets. For a true BIER 180 packet, the next inner most label is for the LSP terminating at the 181 BFR that advertised the inner most label, so the original label stack 182 minus the inner most label should get the generated ICMP/ICMPv6 183 message to the right place for further processing. For the example 184 in Figure 1, when non-BRF1 experiences a TTL-expriation for a 185 tunneled BIER packet, the label stack could be , where the tunnel label is advertised by non-BFR2 and the BIER 187 label is advertised by BFR2. With the BIER label removed, the 188 resulting label stack will get the generated ICMP 189 message to BFR2 for further processing. 191 The LER that originated the inner most label for the generated 192 messages will receive the ICMP/ICMPv6 messages, which is addressed to 193 the local host, and process the messages locally. 195 How the messages are processed is outside of the scope of this 196 document, but in general the new ICMP message type/code causes the 197 LER to examine the original packet header that is enclosed in the 198 ICMP/ICMPv6 message and act accordingly, e.g., forward to BIER OAM 199 module for further processing. Because a non-BIER packet may be 200 mistaken as a BIER packet (if the first nibble happens to be match), 201 the receiving BFR MUST check the label stack included in the ICMP/ 202 ICMPv6 message to make sure that the inner most label is a BIER label 203 that it advertised. 205 It's possible that an IPv4 LER cannot process an incoming ICMPv6 206 message, or vice versa. It is also possible that an LER cannot 207 recognize the new message type/code. In these cases, it simply 208 discard the message. 210 3. IANA Considerations 212 This document requests IANA to assigna a new message type in ICMP and 213 ICMPv6 Parameters registries respectively. 215 4. Security Considerations 217 This document does not introduce new security risks, compared to 218 generating ICMP messages for labeled IP packets. 220 5. Acknowledgements 222 The author thanks Eric Rosen, Ronald Bonica for their review, 223 comments, and suggestions. 225 6. References 227 6.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 233 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 234 Encoding", RFC 3032, January 2001. 236 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 237 Message Protocol (ICMPv6) for the Internet Protocol 238 Version 6 (IPv6) Specification", RFC 4443, March 2006. 240 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 241 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 242 April 2007. 244 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 245 Extensions for Multiprotocol Label Switching", RFC 4950, 246 August 2007. 248 6.2. Informative References 250 [I-D.ietf-bier-architecture] 251 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 252 S. Aldrin, "Multicast using Bit Index Explicit 253 Replication", draft-ietf-bier-architecture-00 (work in 254 progress), April 2015. 256 [I-D.kumarzheng-bier-ping] 257 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 258 and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- 259 bier-ping-00 (work in progress), March 2015. 261 Author's Address 263 Zhaohui Zhang 264 Juniper Networks, Inc. 265 10 Technology Park Drive 266 Westford, MA 01886 268 EMail: zzhang@juniper.net