idnits 2.17.00 (12 Aug 2021) /tmp/idnits60828/draft-ietf-mpls-lsp-ping-relay-reply-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- 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 (October 5, 2015) is 2413 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Luo, Ed. 3 Internet-Draft ZTE 4 Updates: 4379 (if approved) L. Jin, Ed. 5 Intended status: Standards Track Individual 6 Expires: April 7, 2016 T. Nadeau, Ed. 7 Lucidvision 8 G. Swallow, Ed. 9 Cisco 10 October 5, 2015 12 Relayed Echo Reply mechanism for LSP Ping 13 draft-ietf-mpls-lsp-ping-relay-reply-11 15 Abstract 17 In some inter autonomous system (AS) and inter-area deployment 18 scenarios for RFC 4379 "Label Switched Path (LSP) Ping and 19 Traceroute", a replying Label Switching Router (LSR) may not have the 20 available route to an initiator, and the Echo Reply message sent to 21 the initiator would be discarded resulting in false negatives or 22 complete failure of operation of LSP Ping and Traceroute. This 23 document describes extensions to LSP Ping mechanism to enable the 24 replying LSR to have the capability to relay the Echo Response by a 25 set of routable intermediate nodes to the initiator. This document 26 updates RFC 4379. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 7, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 67 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 68 3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8 69 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 9 71 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9 72 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10 73 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 11 74 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11 75 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 12 76 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12 77 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 15 82 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 16 84 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 11.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 This document describes extensions to the Label Switched Path (LSP) 94 Ping as specified in [RFC4379], by adding a relayed echo reply 95 mechanism which could be used to report data plane failures for inter 96 autonomous system (AS) and inter-area LSPs. Without these 97 extensions, the ping functionality provided by [RFC4379] would fail 98 in many deployed inter-AS scenarios, since the replying Label 99 Switching Router (LSR) in one AS may not have an available route to 100 the initiator in the other AS. The mechanism in this document 101 defines a new message type referred as "Relayed Echo Reply message", 102 and a new TLV referred as "Relay Node Address Stack TLV". 104 This document is also to update [RFC4379], include updating of Echo 105 Request sending procedure in section 4.3 of [RFC4379], Echo Request 106 receiving procedure in section 4.4 of [RFC4379], Echo Reply sending 107 procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure 108 in section 4.6 of [RFC4379]. 110 1.1. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Motivation 118 LSP Ping [RFC4379] defines a mechanism to detect data plane failures 119 and localize faults. The mechanism specifies that the Echo Reply 120 should be sent back to the initiator using an UDP packet with the 121 IPv4/IPv6 destination address set to an address of the LSR that 122 originated the Echo Request. This works in administrative domains 123 where IP address reachability is allowed among LSRs, and every LSR is 124 able to route back to the originating LSR. However, in practice, 125 this is often not the case due to intra-provider routing policy, 126 route hiding, and network address translation at autonomous system 127 border routers (ASBR). In fact, it is almost always the case that in 128 inter-AS scenarios the only node in one AS to which direct routing is 129 allowed from the other AS is the ASBR, and routing information from 130 within one AS is not distributed into another AS. 132 Figure 1 demonstrates a case where an LSP is set up between PE1 and 133 PE2. If PE1's IP address is not distributed to AS2, a traceroute 134 from PE1 directed towards PE2 can result in a failure because an LSR 135 in AS2 may not be able to send the Echo Reply message. E.g., P2 136 cannot forward packets back to PE1 given that it is an routable IP 137 address in AS1 but not routable in AS2. In this case, PE1 would 138 detect a path break, as the Echo Reply messages would not be 139 received. Then localization of the actual fault would not be 140 possible. 142 Note that throughout the document, routable address means that it is 143 possible to route an IP packet to this address using the normal 144 information exchanged by the IGP and BGP (or EGP) operating in the 145 AS. 147 +-------+ +-------+ +------+ +------+ +------+ +------+ 148 | | | | | | | | | | | | 149 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 150 | | | | | | | | | | | | 151 +-------+ +-------+ +------+ +------+ +------+ +------+ 152 <---------------AS1-------------><---------------AS2------------> 153 <---------------------------- LSP ------------------------------> 155 Figure 1: Simple Inter-AS LSP Configuration 157 A second example that illustrates how [RFC4379] would be insufficient 158 would be the inter-area situation in a seamless MPLS architecture 159 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this 160 example LSRs in the core network would not have IP reachable route to 161 any of the access nodes (AN). When tracing an LSP from one AN to the 162 remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like 163 the P2 node in the inter-AS scenario in Figure 1. 165 +-------+ +-------+ +------+ +------+ 166 | | | | | | | | 167 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 168 / | | /| | | | | | 169 +----+/ +-------+\/ +-------+ +------+ /+------+ 170 | AN | /\ \/ 171 +----+\ +-------+ \+-------+ +------+/\ +------+ 172 \ | | | | | | \| | 173 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 174 | | | | | | | | 175 +-------+ +-------+ +------+ +------+ 176 static route ISIS L1 LDP ISIS L2 LDP 177 <-Access-><--Aggregation Domain--><---------Core---------> 179 Figure 2: Seamless MPLS Architecture 181 This document describes extensions to the LSP Ping mechanism to 182 facilitate a response from the replying LSR, by defining a mechanism 183 that uses a relay node (e.g, ASBR) to relay the message back to the 184 initiator. Every designated or learned relay node must be reachable 185 to the next relay node or to the initiator. Using a recursive 186 approach, relay node could relay the message to the next relay node 187 until the initiator is reached. 189 The LSP Ping relay mechanism in this document is defined for unicast 190 case. How to apply the LSP Ping relay mechanism in multicast case is 191 out of the scope. 193 3. Extensions 195 [RFC4379] defines two message types, Echo Request and Echo Reply. 196 This document defines a new message type, Relayed Echo Reply. The 197 Relayed Echo Reply message is used in place of the Echo Reply message 198 when an LSR is replying LSR to a relay node. 200 A new TLV named Relay Node Address Stack TLV is defined in this 201 document, to carry the IP addresses of the relay nodes for the 202 replying LSR. 204 In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is 205 defined to indicate to the initiator that one or more TLVs will not 206 be returned due to MTU size. 208 It should be noted that this document focuses only on detecting the 209 LSP which is set up using a uniform IP address family type. That is, 210 all hops between the source and destination node use the same address 211 family type for their LSP ping control planes. This does not 212 preclude nodes that support both IPv6 and IPv4 addresses 213 simultaneously, but the entire path must be addressable using only 214 one address family type. Supporting for mixed IPv4-only and 215 IPv6-only is beyond the scope of this document. 217 3.1. Relayed Echo Reply message 219 The Relayed Echo Reply message is a UDP packet, and the UDP payload 220 has the same format with Echo Request/Reply message. A new message 221 type is requested from IANA. 223 New Message Type: 224 Value Meaning 225 ----- ------- 226 TBD1 MPLS Relayed Echo Reply 228 The use of TCP and UDP port number 3503 is described in [RFC4379] and 229 has been allocated by IANA for LSP Ping messages. The Relayed Echo 230 Reply message will use the same port number. 232 3.2. Relay Node Address Stack 234 The Relay Node Address Stack TLV is an optional TLV. It MUST be 235 carried in the Echo Request, Echo Reply and Relayed Echo Reply 236 messages if the echo reply relayed mechanism described in this 237 document is required. Figure 3 illustrates the TLV format. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Initiator Source Port | Reply Add Type| Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Source Address of Replying Router (0, 4, or 16 octets) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Destination Address Offset | Number of Relayed Addresses | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ Stack of Relayed Addresses ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: Relay Node Address Stack TLV 257 - Type: value is TBD2. The value should be assigned by IANA from 258 32768-49161 as suggested by [RFC4379] Section 3. 260 - Length: the length of the value field in octets. 262 - Initiator Source Port: the source UDP port that the initiator uses 263 in the Echo Request message, and also the port that is expected to 264 receive the Echo Reply message. 266 - Reply Address Type: address type of replying router. This value 267 also implies the length of the address field as shown below. 269 Type# Address Type Address Length 270 ---- ------------ ------------ 271 0 Null 0 272 1 IPv4 4 273 2 IPv6 16 274 - Reserved: This field is reserved and MUST be set to zero. 276 - Source Address of Replying Router: source IP address of the 277 originator of Echo Reply or Replay Echo Reply message. 279 - Destination Address Offset: the offset in octets from the top-of- 280 stack to the destination address entry. Each entry size has been 281 listed in this section. Please also refer to section 4.2 for more 282 detail of the operation. 284 - Number of Relayed Addresses: an integer indicating the number of 285 relayed addresses in the stack. 287 - Stack of Relayed Addresses: a list of relay node address entries. 288 This stack grows downward, with relay nodes address further along 289 the LSP appearing lower down in the stack. Please refer to 290 section 4.2 for the relay node discovery mechanism. 292 The format of each relay node address entry is as below: 294 0 1 2 3 295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Address Type |K| Reserved | Reserved | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ Relayed Address (0, 4, or 16 octets) ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 4: Relay Node Address Entry 304 Type# Address Type Address Length Size of the Entry 305 ---- ------------ ------------ ----------------- 306 0 Null 0 4 307 1 IPv4 4 8 308 2 IPv6 16 20 310 Reserved: The two fields are reserved and MUST be set to zero. 312 K bit: if the K bit is set to 1, then this address stack entry MUST 313 NOT be stripped from the Relay Node Address Stack during processing 314 described in Section 4.2. If the K bit is clear, the entry might be 315 stripped according to the processing described in Section 4.2. 317 Having the K bit set in the relay node address entry causes that 318 entry to be preserved in the Relay Node Address Stack TLV for the 319 entire traceroute operation. A responder node MAY set the K bit to 320 ensure its relay node address entry remains as one of the relay nodes 321 in the Relay Node Address Stack TLV. The address with K bit set will 322 always be a relay node address for the Relayed Echo Reply, see 323 section 4.3. 325 Relayed Address: this field specifies the node address, either IPv4 326 or IPv6. 328 3.3. MTU Exceeded Return Code 330 Return Code is defined to indicate that one or more TLVs were omitted 331 from the Echo Reply or Relayed Echo Reply message to avoid exceeding 332 the message's effective MTU size. These TLVs MAY be included in an 333 Errored TLV's Object with their lengths set to 0 and no value. The 334 return sub-code MUST be set to the value that otherwise would have 335 been sent. For more detail, please refer to section 4.2. 337 MTU Exceeded Return Code: 338 Value Meaning 339 ----- ------- 340 TBD2 One or more TLVs not returned due to MTU size 342 Then section 4.4 of [RFC4379], step 7 will be updated to integrate 343 the processing of MTU Exceeded Return Code.The following text will be 344 added: 346 Before sending Echo Reply, the new packet size should be checked. If 347 Best-return-code is 3 ("Replying router is an egress for the FEC at 348 stack depth"), or 8 ("Label switched at stack-depth"), and if the 349 packet size exceeds MTU size, then Best-return-code is TBD3 ("One or 350 more TLVs not returned due to MTU size") 352 4. Procedures 354 To preform a ping operation, the initiator first discovers the relay 355 nodes. Once those nodes have been discovered, the initiator includes 356 the Relay Node Address Stack TLV into any Echo Request message. The 357 node can then ping as normal. Note that in some cases, the repeated 358 lack of replies to Echo Request messages may be due to a route change 359 that has impacted the necessary stack of relay nodes. In this case 360 the initiator may need to re-discover the relay nodes. The following 361 sections describe the procedures for sending and receiving Echo 362 Request messages with the the Relay Node Address Stack TLV. These 363 procedures can be used in "trace route" mode to discover the relay 364 nodes. 366 4.1. Sending an Echo Request 368 In addition to the procedures described in section 4.3 of [RFC4379], 369 a Relay Node Address Stack TLV MUST be carried in the Echo Request 370 message if the relay functionality is required. The relay function 371 initiation is out of the scope of this document, one possible way is 372 that the operator will explicitly add an option to the ping command. 374 When the initiator sends the first Echo Request with a Relay Node 375 Address Stack TLV, the TLV MUST contain the initiator address as the 376 first entry of the stack of relayed addresses, the Destination 377 Address Offset set to this entry, and the source address of the 378 replying router set to null. The Initiator Source Port field MUST be 379 set to the source UDP port. Note that the first relay node address 380 in the stack will always be the initiator's address. 382 When sending subsequent Echo Request message, refer to section 4.6. 384 4.2. Receiving an Echo Request 386 The Type of the Relay Node Address Stack TLV is chosen from the range 387 defined in [RFC4379] as "optional TLVs that can be silently dropped 388 if not recognized. An LSR that does not recognize the TLV SHOULD 389 ignore it. 391 In addition to the processes in section 4.4 of [RFC4379], the 392 procedures of the Relay Node Address Stack TLV are defined here. 394 Upon receiving a Relay Node Address Stack TLV in an Echo Request 395 message, the receiver updates the "Source Address of Replying 396 Router". The address MUST be same as the source IP address of Relay 397 Echo Reply (section 4.3) or Echo Reply message (section 4.5) being 398 sent. 400 Those address entries with K bit set to 1 MUST be kept in the stack. 401 The receiver MUST check the addresses of the stack in sequence from 402 bottom to top to find the last address in the stack with the K bit 403 set (or the top of the stack if no K bit was found). The receiver 404 then checks the stack beginning with this entry, proceeding towards 405 the bottom to find the first routable address IP address. The 406 Destination Address Offset MUST be set to this entry which is also 407 the resolved destination address. Address entries below the first 408 routable IP address MUST be deleted. At least one address entries of 409 the replying LSR MUST be added at the bottom of the stack. A second 410 or more address entries MAY also be added if necessary, depending on 411 implementation. The final address added MUST be an address that is 412 reachable through the interface that the Echo Request Message would 413 have been forwarded if it had not TTL expired at this node. The 414 updated Relay Node Address Stack TLV MUST be carried in the response 415 message. 417 If the replying LSR is configured to hide its routable address 418 information, the address entry added in the stack MUST be a NIL entry 419 with Address Type set to NULL. 421 If a node spans two addressing domains (with respect to this message) 422 where nodes on either side may not be able to reach nodes in the 423 other domain, then the final address added SHOULD set the K bit. One 424 example of spanning two address domains is the ASBR node. Other 425 cases are also possible, and out of the scope of this document. 427 K bit applies in the case of a NULL address, to serve as a warning to 428 the initiator that further Echo Request messages may not result in 429 receiving Echo Reply messages. 431 If the full reply message would exceed the MTU size, the Relay Node 432 Address Stack TLV SHOULD be included in the Echo Reply message (i.e., 433 other optional TLVs are excluded). 435 4.3. Originating an Relayed Echo Reply 437 The destination address determined in section 4.2 is used as the next 438 relay node address. If the resolved next relay node address is not 439 routable, then sending of Relayed Echo Reply or Echo Reply will fail. 441 If the first IP address in the Relay Node Address Stack TLV is not 442 the next relay node address, the replying LSR SHOULD send a Relayed 443 Echo Reply message to the next relay node. The processing of Relayed 444 Echo Reply is the same with the procedure of the Echo Reply described 445 in Section 4.5 of [RFC4379], except the destination IP address and 446 the destination UDP port. The destination IP address of the Relayed 447 Echo Reply is set to the next relay node address from the Relay Node 448 Address Stack TLV, and both the source and destination UDP port are 449 set to 3503. The updated Relay Node Address Stack TLV described in 450 section 4.2 MUST be carried in the Relayed Echo Reply message. The 451 Source Address of Replying Router field is kept unmodified, and 452 Source IP address field of the IP header is set to an address of the 453 sending node. 455 When the next relay node address is the first one in the address 456 list, please refer to section 4.5. 458 4.4. Relaying an Relayed Echo Reply 460 Upon receiving an Relayed Echo Reply message with its own address as 461 the destination address in the IP header, the relay node MUST 462 determine the next relay node address as described in section 4.2, 463 with the modification that the location of the received destination 464 address is used instead of the bottom of stack in the algorithm. The 465 Destination Address Offset in Relay Node Address Stack TLV will be 466 set to the next relay node address. Note that unlike section 4.2 no 467 changes are made to the Stack of Relayed Addresses. 469 If the next relay node address is not the first one in the address 470 list, i.e., another intermediate relay node, the relay node MUST send 471 an Relayed Echo Reply message to the determined upstream node with 472 the payload unchanged other than the Relay Node Address Stack TLV. 473 The TTL SHOULD be copied from the received Relay Echo Reply and 474 decremented by 1. The Source Address of Replying Router field is 475 kept unmodified, and Source IP address field of the IP header is set 476 to an address of the sending node. 478 When the next relay node address is the first one in the address 479 list, please refer to section 4.5. 481 4.5. Sending an Echo Reply 483 The Echo Reply is sent in two cases: 485 1. When the replying LSR receives an Echo Request, and the first IP 486 address in the Relay Node Address Stack TLV is the next relay node 487 address (section 4.3), the replying LSR would send an Echo Reply to 488 the initiator. In addition to the procedure of the Echo Reply 489 described in Section 4.5 of [RFC4379], the updated Relay Node Address 490 Stack TLV described in section 4.2 MUST be carried in the Echo Reply. 492 If the receiver does not recognize the Relay Node Address Stack TLV, 493 as per section 3 and 4.5 of [RFC4379], it will send an Echo Reply 494 without including the TLV. 496 2. When the intermediate relay node receives a Relayed Echo Reply, 497 and the first IP address in the Relay Node Address Stack TLV is the 498 next relay node address (section 4.4), the intermediate relay node 499 would send the Echo Reply to the initiator, and update the Message 500 Type field from type of Relayed Echo Reply to Echo Reply. The 501 updated Relay Node Address Stack TLV described in section 4.4 MUST be 502 carried in the Echo Reply. The destination IP address of the Echo 503 Reply is set to the first IP address in the stack, and the 504 destination UDP port would be copied from the Initiator Source Port 505 field of the Relay Node Address Stack TLV. The source UDP port 506 should be 3503. The TTL of the Echo Reply SHOULD be copied from the 507 received Relay Echo Reply and decremented by 1. The Source Address 508 of Replying Router field is kept unmodified, and Source IP address 509 field of the IP header is set to an address of the sending node. 511 4.6. Sending Subsequent Echo Requests 513 During a traceroute operation, multiple Echo Request messages are 514 sent. Each time the TTL is increased, the initiator SHOULD copy the 515 Relay Node Address Stack TLV received in the previous Echo Reply to 516 the next Echo Request. The Relay Node Address Stack TLV MUST NOT be 517 modified except as follows. A NIL entry with K bit unset MAY be 518 removed. A NIL entry with K bit serves as a warning that further 519 Echo Request messages are likely to not result in a reply. If, 520 however, the initiator decides to continue a traceroute operation, 521 the NIL entry with the K bit set MUST be removed. The Source Address 522 of Replying Router and Destination Address Offset fields may be 523 preserved or reset since these fields are ignored in received MPLS 524 Echo Request. 526 4.7. Impact to Traceroute 528 Source IP address in Echo Reply and Relay Echo Reply is to be of the 529 address of the node sending those packets, not the original 530 responding node. Then the traceroute address output module will 531 print the source IP address as below: 533 if (Relay Node Address Stack TLV exists) { 534 Print the Source Address of Replying Router in 535 Relay Node Address Stack TLV; 536 } else { 537 Print the source IP address of Echo Reply message; 538 } 540 5. LSP Ping Relayed Echo Reply Example 542 Considering the inter-AS scenario in Figure 5 below. AS1 and AS2 are 543 two independent address domains. In the example, an LSP has been 544 created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in 545 AS2. 547 +-------+ +-------+ +------+ +------+ +------+ +------+ 548 | | | | | | | | | | | | 549 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 550 | | | | | | | | | | | | 551 +-------+ +-------+ +------+ +------+ +------+ +------+ 552 <---------------AS1-------------><---------------AS2------------> 553 <--------------------------- LSP -------------------------------> 555 Figure 5: Example Inter-AS LSP 557 When performing LSP traceroute on the LSP, the first Echo Request 558 sent by PE1 with outer-most label TTL=1, contains the Relay Node 559 Address Stack TLV with PE1's address as the first relayed address. 561 After processed by P1, P1's interface address facing ASBR1 without 562 the K bit set will be added in the Relay Node Address Stack TLV 563 address list following PE1's address in the Echo Reply. 565 PE1 copies the Relay Node Address Stack TLV into the next Echo 566 Request when receiving the Echo Reply. 568 Upon receiving the Echo Request, ASBR1 checks the address list in the 569 Relay Node Address Stack TLV, and determines that PE1's address is 570 the next relay address. Then deletes P1's address, and adds its 571 interface address facing ASBR2 with the K bit set. As a result, 572 there would be PE1's address followed by ASBR1's interface address 573 facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply 574 sent by ASBR1. 576 PE1 then sends an Echo Request with outer-most label TTL=3, 577 containing the Relay Node Address Stack TLV copied from the received 578 Echo Reply message. Upon receiving the Echo Request message, ASBR2 579 checks the address list in the Relay Node Address Stack TLV, and 580 determines ASBR1's interface address is the next relay address in the 581 stack TLV. ASBR2 adds its interface address facing P2 with the K bit 582 set. Then ASBR2 sets the next relay address as the destination 583 address of the Relayed Echo Reply, and sends the Relayed Echo Reply 584 to ASBR1. 586 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 587 address list in the Relay Node Address Stack TLV, and determines that 588 PE1's address is the next relay node. Then ASBR1 sends an Echo Reply 589 to PE1. 591 For the Echo Request with outer-most label TTL=4, P2 checks the 592 address list in the Relay Node Address Stack TLV, and determines that 593 ASBR2's interface address is the next relay address. Then P2 sends 594 an Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV 595 containing four addresses, PE1's, ASBR1's interface address, ASBR2's 596 interface address and P2's interface address facing PE2 in sequence. 598 Then according to the process described in section 4.4, ASBR2 sends 599 the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo 600 Reply, ASBR1 sends an Echo Reply to PE1. And as relayed by ASBR2 and 601 ASBR1, the Echo Reply would finally be sent to the initiator PE1. 603 For the Echo Request with outer-most label TTL=5, the Echo Reply 604 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 605 TTL=4. 607 The Echo Reply from the replying node which has no IP reachable route 608 to the initiator is thus transmitted to the initiator by multiple 609 relay nodes. 611 6. Security Considerations 613 The Relayed Echo Reply mechanism for LSP Ping creates an increased 614 risk of DoS by putting the IP address of a target router in the Relay 615 Node Address Stack. These messages then could be used to attack the 616 control plane of an LSR by overwhelming it with these packets. A 617 rate limiter SHOULD be applied to the well-known UDP port on the 618 relay node as suggested in [RFC4379]. The node which acts as a relay 619 node SHOULD validate the relay reply against a set of valid source 620 addresses and discard packets from untrusted border router addresses. 621 An implementation SHOULD provide such filtering capabilities. 623 If an operator wants to obscure their nodes, it is RECOMMENDED that 624 they may replace the replying node address that originated the Echo 625 Reply with NIL address entry in Relay Node Address Stack TLV. 627 A receiver of an MPLS Echo Request could verify that the first 628 address in the Relay Node Address Stack TLV is the same address as 629 the source IP address field of the received IP header. 631 The Relay Node Address Stack TLV has the path information of the LSP, 632 and such information may be maliciously used by any uncontrolled LSR/ 633 LER. We have two ways to reduce the path information in the TLV: 635 1. it is recommended to clear the K bit in the relay address entry 636 unless you have to. 638 2. it is encouraged to use NIL address entry to hide node information 639 if possible. 641 Other security considerations discussed in [RFC4379], are also 642 applicable to this document. 644 7. Backward Compatibility 646 When one of the nodes along the LSP does not support the mechanism 647 specified in this document, the node will ignore the Relay Node 648 Address Stack TLV as described in section 4.2. Then the initiator 649 may not receive the Relay Node Address Stack TLV in Echo Reply 650 message from that node. In this case, an indication should be 651 reported to the operator, and the Relay Node Address Stack TLV in the 652 next Echo Request message should be copied from the previous Echo 653 Request, and continue the ping process. If the node described above 654 is located between the initiator and the first relay node, the ping 655 process could continue without interruption. 657 8. IANA Considerations 659 IANA is requested to assign one new Message Type, one new TLV and one 660 Return Code. 662 8.1. New Message Type 664 This document requires allocation of one new message type from 665 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 666 Ping Parameters" registry, the "Message Type" registry: 668 Value Meaning 669 ----- ------- 670 TBD1 MPLS Relayed Echo Reply 672 The value should be assigned from the "Standards Action" range 673 (0-191), and using the lowest free value within this range. 675 8.2. New TLV 677 This document requires allocation of one new TLV from "Multi-Protocol 678 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 679 registry, the "TLVs" registry: 681 Type Meaning 682 ---- -------- 683 TBD2 Relay Node Address Stack TLV 685 A value should be assigned from "Standards Action" range 686 (32768-49161) as suggested by [RFC4379] Section 3, using the first 687 free value within this range. 689 8.3. MTU Exceeded Return Code 691 This document requires allocation of MTU Exceeded return code from 692 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 693 Ping Parameters" registry, the "Return Codes" registry: 695 Value Meaning 696 ----- ------- 697 TBD3 One or more TLVs not returned due to MTU size 699 The value should be assigned from the "Standards Action" range 700 (0-191), and using the lowest free value within this range. 702 9. Acknowledgement 704 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 705 Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory 706 Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments 707 and suggestions. 709 10. Contributors 711 Ryan Zheng 712 JSPTPD 713 371, Zhongshan South Road 714 Nanjing, 210006, China 715 Email: ryan.zhi.zheng@gmail.com 717 11. References 719 11.1. Normative References 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 727 Label Switched (MPLS) Data Plane Failures", RFC 4379, 728 DOI 10.17487/RFC4379, February 2006, 729 . 731 11.2. Informative References 733 [I-D.ietf-mpls-seamless-mpls] 734 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 735 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 736 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 738 Authors' Addresses 740 Jian Luo (editor) 741 ZTE 742 50, Ruanjian Avenue 743 Nanjing, 210012, China 745 Email: luo.jian@zte.com.cn 747 Lizhong Jin (editor) 748 Individual 749 Shanghai, China 751 Email: lizho.jin@gmail.com 753 Thomas Nadeau (editor) 754 Lucidvision 756 Email: tnadeau@lucidvision.com 758 George Swallow (editor) 759 Cisco 760 300 Beaver Brook Road 761 Boxborough , MASSACHUSETTS 01719, USA 763 Email: swallow@cisco.com