idnits 2.17.1 draft-ietf-mpls-lsp-ping-relay-reply-10.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 (July 6, 2015) is 3189 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: January 7, 2016 T. Nadeau, Ed. 7 Lucidvision 8 G. Swallow, Ed. 9 Cisco 10 July 6, 2015 12 Relayed Echo Reply mechanism for LSP Ping 13 draft-ietf-mpls-lsp-ping-relay-reply-10 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 January 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 . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 10 74 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11 75 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11 76 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12 77 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14 82 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15 84 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 11.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 operating in the AS. 146 +-------+ +-------+ +------+ +------+ +------+ +------+ 147 | | | | | | | | | | | | 148 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 149 | | | | | | | | | | | | 150 +-------+ +-------+ +------+ +------+ +------+ +------+ 151 <---------------AS1-------------><---------------AS2------------> 152 <---------------------------- LSP ------------------------------> 154 Figure 1: Simple Inter-AS LSP Configuration 156 A second example that illustrates how [RFC4379] would be insufficient 157 would be the inter-area situation in a seamless MPLS architecture 158 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this 159 example LSRs in the core network would not have IP reachable route to 160 any of the ANs. When tracing an LSP from one access node (AN) to the 161 remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like 162 the P2 node in the inter-AS scenario in Figure 1. 164 +-------+ +-------+ +------+ +------+ 165 | | | | | | | | 166 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 167 / | | /| | | | | | 168 +----+/ +-------+\/ +-------+ +------+ /+------+ 169 | AN | /\ \/ 170 +----+\ +-------+ \+-------+ +------+/\ +------+ 171 \ | | | | | | \| | 172 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 173 | | | | | | | | 174 +-------+ +-------+ +------+ +------+ 175 static route ISIS L1 LDP ISIS L2 LDP 176 <-Access-><--Aggregation Domain--><---------Core---------> 178 Figure 2: Seamless MPLS Architecture 180 This document describes extensions to the LSP Ping mechanism to 181 facilitate a response from the replying LSR, by defining a mechanism 182 that uses a relay node (e.g, ASBR) to relay the message back to the 183 initiator. Every designated or learned relay node must be reachable 184 to the next relay node or to the initiator. Using a recursive 185 approach, relay node could relay the message to the next relay node 186 until the initiator is reached. 188 The LSP Ping relay mechanism in this document is defined for unicast 189 case. How to apply the LSP Ping relay mechanism in multicast case is 190 out of the scope. 192 3. Extensions 194 [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines 195 two message types, Echo Request and Echo Reply message. This 196 document defines a new message, Relayed Echo Reply message. This new 197 message is used to replace Echo Reply message which is sent from the 198 replying LSR to a relay node or from a relay node to another relay 199 node. 201 A new TLV named Relay Node Address Stack TLV is defined in this 202 document, to carry the IP addresses of the relay nodes for the 203 replying LSR. 205 In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is 206 defined to indicate to the initiator that one or more TLVs will not 207 be returned due to MTU size. 209 It should be noted that this document focuses only on detecting the 210 LSP which is set up using a uniform IP address family type. That is, 211 all hops between the source and destination node use the same address 212 family type for their LSP ping control planes. This does not 213 preclude nodes that support both IPv6 and IPv4 addresses 214 simultaneously, but the entire path must be addressable using only 215 one address family type. Supporting for mixed IPv4-only and 216 IPv6-only is beyond the scope of this document. 218 3.1. Relayed Echo Reply message 220 The Relayed Echo Reply message is a UDP packet, and the UDP payload 221 has the same format with Echo Request/Reply message. A new message 222 type is requested from IANA. 224 New Message Type: 225 Value Meaning 226 ----- ------- 227 TBD1 MPLS Relayed Echo Reply 229 The use of TCP and UDP port number 3503 is described in [RFC4379] and 230 has been allocated by IANA for LSP Ping messages. The Relayed Echo 231 Reply message will use the same port number. 233 3.2. Relay Node Address Stack 235 The Relay Node Address Stack TLV is an optional TLV. It MUST be 236 carried in the Echo Request, Echo Reply and Relayed Echo Reply 237 messages if the echo reply relayed mechanism described in this 238 document is required. Figure 3 illustrates the TLV format. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Initiator Source Port | Reply Add Type| Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Source Address of Replying Router (0, 4, or 16 octects) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Destination Address Offset | Number of Relayed Addresses | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 ~ Stack of Relayed Addresses ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 3: Relay Node Address Stack TLV 258 - Type: value is TBD2. The value should be assigned by IANA from 259 32768-49161 as suggested by [RFC4379] Section 3. 261 - Length: the length of the value field in octets. 263 - Initiator Source Port: the source UDP port that the initiator uses 264 in the Echo Request message, and also the port that is expected to 265 receive the Echo Reply message. 267 - Reply Address Type: address type of replying router. This value 268 also implies the length of the address field as shown below. 270 Type# Address Type Address Length 271 ---- ------------ ------------ 272 0 Null 0 273 1 IPv4 4 274 2 IPv6 16 275 - Reserved: This field is reserved and MUST be set to zero. 277 - Source Address of Replying Router: source IP address of the 278 originator of Echo Reply or Replay Echo Reply message. 280 - Destination Address Offset: an offset (octets) to indicate the 281 position of the destination address of the Reply or Relayed Reply 282 message. The entry on the top of the Stack of Relayed Addresses 283 will have offset of 0. 285 - Number of Relayed Addresses: an integer indicating the number of 286 relayed addresses in the stack. 288 - Stack of Relayed Addresses: a list of relay node addresses. 290 The format of each relay node address is as below: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Address Type |K| Reserved | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ Relayed Address (0, 4, or 16 octects) ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type# Address Type Address Length 301 ---- ------------ ------------ 302 0 Null 0 303 1 IPv4 4 304 2 IPv6 16 306 Reserved: The two fields are reserved and MUST be set to zero. 308 K bit: if the K bit is set to 1, then this address stack entry MUST 309 NOT be stripped from the Relay Node Address Stack during processing 310 described in Section 4.2. If the K bit is clear, the entry might be 311 stripped according to the processing described in Section 4.2. 313 Having the K bit set in the relay node address entry causes that 314 entry to be preserved in the Relay Node Address Stack TLV for the 315 entire traceroute operation. A responder node MAY set the K bit to 316 ensure its relay node address entry remains as one of the relay nodes 317 in the Relay Node Address Stack TLV. The address with K bit set will 318 always be a relay node address for the Relayed Echo Reply, see 319 section 4.3. 321 Relayed Address: this field specifies the node address, either IPv4 322 or IPv6. 324 3.3. MTU Exceeded Return Code 326 Return Code is defined to indicate that one or more TLVs were omitted 327 from the Echo Reply or Relayed Echo Reply message to avoid exceeding 328 the message's effective MTU size. These TLVs MAY be included in an 329 Errored TLV's Object with their lengths set to 0 and no value. The 330 return sub-code MUST be set to the value that otherwise would have 331 been sent. For more detail, please refer to section 4.2. 333 MTU Exceeded Return Code: 334 Value Meaning 335 ----- ------- 336 TBD2 One or more TLVs not returned due to MTU size 338 Then section 4.4 of [RFC4379], step 7 will be updated to integrate 339 the processing of MTU Exceeded Return Code.The following text will be 340 added: 342 Before sending Echo Reply, the new packet size should be checked. If 343 Best-return-code is 3 ("Replying router is an egress for the FEC at 344 stack depth"), or 8 ("Label switched at stack-depth"), and if the 345 packet size exceeds MTU size, then Best-return-code is TBD3 ("One or 346 more TLVs not returned due to MTU size") 348 4. Procedures 350 In the following section, we describe the relay reply procedures with 351 traceroute operation. If operator has knowledge of the relay nodes, 352 the initiator could do LSP Ping by directly sending Echo Request with 353 Relay Node Address Stack TLV containing the already known relay 354 nodes. 356 4.1. Sending an Echo Request 358 In addition to the procedures described in section 4.3 of [RFC4379], 359 a Relay Node Address Stack TLV MUST be carried in the Echo Request 360 message if the relay functionality is required. 362 When the initiator sends the first Echo Request with a Relay Node 363 Address Stack TLV, the TLV MUST contain the initiator address as the 364 first entry of the stack of relayed addresses, the Destination 365 Address Offset set to this entry, and the source address of the 366 replying router set to null. The Initiator Source Port field MUST be 367 set to the source UDP port. Note that the first relay node address 368 in the stack will always be the initiator's address. 370 When sending subsequent Echo Request message, refer to section 4.6. 372 4.2. Receiving an Echo Request 374 The Type of the Relay Node Address Stack TLV is chosen from the range 375 32768 to 49161 so that (per section 3 of [RFC4379]) an LSR that does 376 not recognize the TLV knows that the TLV is optional and can safely 377 ignore it. 379 In addition to the processes in section 4.4 of [RFC4379], the 380 procedures of the Relay Node Address Stack TLV are defined here. 382 Upon receiving a Relay Node Address Stack TLV in an Echo Request 383 message, the receiver updates the "Source Address of Replying 384 Router". The address MUST be same as the source IP address of Relay 385 Echo Reply (section 4.3) or Echo Reply message (section 4.5) being 386 sent. 388 Those address entries with K bit set to 1 MUST be kept in the stack. 389 The receiver MUST check the addresses of the stack in sequence from 390 bottom to top to find the last address in the stack with the K bit 391 set (or the top of the stack if no K bit was found). The receiver 392 then checks the stack beginning with this entry, proceeding towards 393 the bottom to find the first routable address IP address. The 394 Destination Address Offset MUST be set to this entry which is also 395 the resolved destination address. Address entries below the first 396 routable IP address MUST be deleted. At least one address entries of 397 the replying LSR MUST be added at the bottom of the stack. A second 398 or more address entries MAY also be added if necessary, depending on 399 implementation. The final address added MUST be an address that is 400 reachable through the interface that the Echo Request Message would 401 have been forwarded if it had not TTL expired at this node. The 402 updated Relay Node Address Stack TLV MUST be carried in the response 403 message. 405 If the replying LSR is configured to hide its routable address 406 information, the address entry added in the stack MUST be a NIL entry 407 with Address Type set to NULL. 409 If a node spans two addressing domains (with respect to this message) 410 where nodes on either side may not be able to reach nodes in the 411 other domain, then the final address added SHOULD set the K bit. One 412 example of spanning two address domains is the ASBR node. Other 413 cases are also possible, and out of the scope of this document. 415 K bit applies in the case of a NULL address, to serve as a warning to 416 the initiator that further Echo Request messages may not result in 417 receiving Echo Reply messages. 419 If the full reply message would exceed the MTU size, the Relay Node 420 Address Stack TLV SHOULD be included in the Echo Reply message (i.e., 421 other optional TLVs are excluded). 423 4.3. Originating an Relayed Echo Reply 425 The destination address determined in section 4.2 is used as the next 426 relay node address. If the resolved next relay node address is not 427 routable, then sending of Relayed Echo Reply or Echo Reply will fail. 429 If the first IP address in the Relay Node Address Stack TLV is not 430 the next relay node address, the replying LSR SHOULD send a Relayed 431 Echo Reply message to the next relay node. The processing of Relayed 432 Echo Reply is the same with the procedure of the Echo Reply described 433 in Section 4.5 of [RFC4379], except the destination IP address and 434 the destination UDP port. The destination IP address of the Relayed 435 Echo Reply is set to the next relay node address from the Relay Node 436 Address Stack TLV, and both the source and destination UDP port are 437 set to 3503. The updated Relay Node Address Stack TLV described in 438 section 4.2 MUST be carried in the Relayed Echo Reply message. The 439 Source Address of Replying Router field is kept unmodified, and 440 Source IP address field of the IP header is set to an address of the 441 sending node. 443 When the next relay node address is the first one in the address 444 list, please refer to section 4.5. 446 4.4. Relaying an Relayed Echo Reply 448 Upon receiving an Relayed Echo Reply message with its own address as 449 the destination address in the IP header, the relay node MUST 450 determine the next relay node address as described in section 4.2, 451 with the modification that the location of the received destination 452 address is used instead of the bottom of stack in the algorithm. The 453 Destination Address Offset in Relay Node Address Stack TLV will be 454 set to the next relay node address. Note that unlike section 4.2 no 455 changes are made to the Stack of Relayed Addresses. 457 If the next relay node address is not the first one in the address 458 list, i.e., another intermediate relay node, the relay node MUST send 459 an Relayed Echo Reply message to the determined upstream node with 460 the payload unchanged other than the Relay Node Address Stack TLV. 461 The TTL SHOULD be copied from the received Relay Echo Reply and 462 decremented by 1. The Source Address of Replying Router field is 463 kept unmodified, and Source IP address field of the IP header is set 464 to an address of the sending node. 466 When the next relay node address is the first one in the address 467 list, please refer to section 4.5. 469 4.5. Sending an Echo Reply 471 The Echo Reply is sent in two cases: 473 1. When the replying LSR receives an Echo Request, and the first IP 474 address in the Relay Node Address Stack TLV is the next relay node 475 address (section 4.3), the replying LSR would send an Echo Reply to 476 the initiator. In addition to the procedure of the Echo Reply 477 described in Section 4.5 of [RFC4379], the updated Relay Node Address 478 Stack TLV described in section 4.2 MUST be carried in the Echo Reply. 480 If the receiver does not recognize the Relay Node Address Stack TLV, 481 as per section 3 and 4.5 of [RFC4379], it will send an Echo Reply 482 without including the TLV. 484 2. When the intermediate relay node receives a Relayed Echo Reply, 485 and the first IP address in the Relay Node Address Stack TLV is the 486 next relay node address (section 4.4), the intermediate relay node 487 would send the Echo Reply to the initiator, and update the Message 488 Type field from type of Relayed Echo Reply to Echo Reply. The 489 updated Relay Node Address Stack TLV described in section 4.4 MUST be 490 carried in the Echo Reply. The destination IP address of the Echo 491 Reply is set to the first IP address in the stack, and the 492 destination UDP port would be copied from the Initiator Source Port 493 field of the Relay Node Address Stack TLV. The source UDP port 494 should be 3503. The TTL of the Echo Reply SHOULD be copied from the 495 received Relay Echo Reply and decremented by 1. The Source Address 496 of Replying Router field is kept unmodified, and Source IP address 497 field of the IP header is set to an address of the sending node. 499 4.6. Sending Subsequent Echo Requests 501 During a traceroute operation, multiple Echo Request messages are 502 sent. Each time the TTL is increased, the initiator SHOULD copy the 503 Relay Node Address Stack TLV received in the previous Echo Reply to 504 the next Echo Request. The Relay Node Address Stack TLV MUST NOT be 505 modified except as follows. A NIL entry with K bit unset MAY be 506 removed. A NIL entry with K bit serves as a warning that further 507 Echo Request messages are likely to not result in a reply. If, 508 however, the initiator decides to continue a traceroute operation, 509 the NIL entry with the K bit set MUST be removed. The Source Address 510 of Replying Router and Destination Address Offset fields may be 511 preserved or reset since these fields are ignored in received MPLS 512 Echo Request. 514 4.7. Impact to Traceroute 516 Source IP address in Echo Reply and Relay Echo Reply is to be of the 517 address of the node sending those packets, not the original 518 responding node. Then the traceroute address output module will 519 print the source IP address as below: 521 if (Relay Node Address Stack TLV exists) { 522 Print the Source Address of Replying Router in 523 Relay Node Address Stack TLV; 524 } else { 525 Print the source IP address of Echo Reply message; 526 } 528 5. LSP Ping Relayed Echo Reply Example 530 Considering the inter-AS scenario in Figure 4 below. AS1 and AS2 are 531 two independent address domains. In the example, an LSP has been 532 created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in 533 AS2. 535 +-------+ +-------+ +------+ +------+ +------+ +------+ 536 | | | | | | | | | | | | 537 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 538 | | | | | | | | | | | | 539 +-------+ +-------+ +------+ +------+ +------+ +------+ 540 <---------------AS1-------------><---------------AS2------------> 541 <--------------------------- LSP -------------------------------> 543 Figure 4: Example Inter-AS LSP 545 When performing LSP traceroute on the LSP, the first Echo Request 546 sent by PE1 with outer-most label TTL=1, contains the Relay Node 547 Address Stack TLV with PE1's address as the first relayed address. 549 After processed by P1, P1's interface address facing ASBR1 without 550 the K bit set will be added in the Relay Node Address Stack TLV 551 address list following PE1's address in the Echo Reply. 553 PE1 copies the Relay Node Address Stack TLV into the next Echo 554 Request when receiving the Echo Reply. 556 Upon receiving the Echo Request, ASBR1 checks the address list in the 557 Relay Node Address Stack TLV, and determines that PE1's address is 558 the next relay address. Then deletes P1's address, and adds its 559 interface address facing ASBR2 with the K bit set. As a result, 560 there would be PE1's address followed by ASBR1's interface address 561 facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply 562 sent by ASBR1. 564 PE1 then sends an Echo Request with outer-most label TTL=3, 565 containing the Relay Node Address Stack TLV copied from the received 566 Echo Reply message. Upon receiving the Echo Request message, ASBR2 567 checks the address list in the Relay Node Address Stack TLV, and 568 determines ASBR1's interface address is the next relay address in the 569 stack TLV. ASBR2 adds its interface address facing P2 with the K bit 570 set. Then ASBR2 sets the next relay address as the destination 571 address of the Relayed Echo Reply, and sends the Relayed Echo Reply 572 to ASBR1. 574 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 575 address list in the Relay Node Address Stack TLV, and determines that 576 PE1's address is the next relay node. Then ASBR1 sends an Echo Reply 577 to PE1. 579 For the Echo Request with outer-most label TTL=4, P2 checks the 580 address list in the Relay Node Address Stack TLV, and determines that 581 ASBR2's interface address is the next relay address. Then P2 sends 582 an Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV 583 containing four addresses, PE1's, ASBR1's interface address, ASBR2's 584 interface address and P2's interface address facing PE2 in sequence. 586 Then according to the process described in section 4.4, ASBR2 sends 587 the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo 588 Reply, ASBR1 sends an Echo Reply to PE1. And as relayed by ASBR2 and 589 ASBR1, the Echo Reply would finally be sent to the initiator PE1. 591 For the Echo Request with outer-most label TTL=5, the Echo Reply 592 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 593 TTL=4. 595 The Echo Reply from the replying node which has no IP reachable route 596 to the initiator is thus transmitted to the initiator by multiple 597 relay nodes. 599 6. Security Considerations 601 The Relayed Echo Reply mechanism for LSP Ping creates an increased 602 risk of DoS by putting the IP address of a target router in the Relay 603 Node Address Stack. These messages then could be used to attack the 604 control plane of an LSR by overwhelming it with these packets. A 605 rate limiter SHOULD be applied to the well-known UDP port on the 606 relay node as suggested in [RFC4379]. The node which acts as a relay 607 node SHOULD validate the relay reply against a set of valid source 608 addresses and discard packets from untrusted border router addresses. 609 An implementation SHOULD provide such filtering capabilities. 611 If an operator wants to obscure their nodes, it is RECOMMENDED that 612 they may replace the replying node address that originated the Echo 613 Reply with NIL address entry in Relay Node Address Stack TLV. 615 A receiver of an MPLS Echo Request could verify that the first 616 address in the Relay Node Address Stack TLV is the same address as 617 the source IP address field of the received IP header. 619 The Relay Node Address Stack TLV has the path information of the LSP, 620 and such information may be maliciously used by any uncontrolled LSR/ 621 LER. We have two ways to reduce the path information in the TLV: 623 1. it is recommended to clear the K bit in the relay address entry 624 unless you have to. 626 2. it is encouraged to use NIL address entry to hide node information 627 if possible. 629 Other security considerations discussed in [RFC4379], are also 630 applicable to this document. 632 7. Backward Compatibility 634 When one of the nodes along the LSP does not support the mechanism 635 specified in this document, the node will ignore the Relay Node 636 Address Stack TLV as described in section 4.2. Then the initiator 637 may not receive the Relay Node Address Stack TLV in Echo Reply 638 message from that node. In this case, an indication should be 639 reported to the operator, and the Relay Node Address Stack TLV in the 640 next Echo Request message should be copied from the previous Echo 641 Request, and continue the ping process. If the node described above 642 is located between the initiator and the first relay node, the ping 643 process could continue without interruption. 645 8. IANA Considerations 647 IANA is requested to assign one new Message Type, one new TLV and one 648 Return Code. 650 8.1. New Message Type 652 This document requires allocation of one new message type from 653 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 654 Ping Parameters" registry, the "Message Type" registry: 656 Value Meaning 657 ----- ------- 658 TBD1 MPLS Relayed Echo Reply 660 The value should be assigned from the "Standards Action" range 661 (0-191), and using the lowest free value within this range. 663 8.2. New TLV 665 This document requires allocation of one new TLV from "Multi-Protocol 666 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 667 registry, the "TLVs" registry: 669 Type Meaning 670 ---- -------- 671 TBD2 Relay Node Address Stack TLV 673 A suggested value should be assigned from "Standards Action" range 674 (32768-49161) as suggested by [RFC4379] Section 3, using the first 675 free value within this range. 677 8.3. MTU Exceeded Return Code 679 This document requires allocation of MTU Exceeded return code from 680 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 681 Ping Parameters" registry, the "Return Codes" registry: 683 Value Meaning 684 ----- ------- 685 TBD3 One or more TLVs not returned due to MTU size 687 The value should be assigned from the "Standards Action" range 688 (0-191), and using the lowest free value within this range. 690 9. Acknowledgement 692 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 693 Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory 694 Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments 695 and suggestions. 697 10. Contributors 698 Ryan Zheng 699 JSPTPD 700 371, Zhongshan South Road 701 Nanjing, 210006, China 702 Email: ryan.zhi.zheng@gmail.com 704 11. References 706 11.1. Normative References 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, March 1997. 711 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 712 Label Switched (MPLS) Data Plane Failures", RFC 4379, 713 February 2006. 715 11.2. Informative References 717 [I-D.ietf-mpls-seamless-mpls] 718 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 719 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 720 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 722 Authors' Addresses 724 Jian Luo (editor) 725 ZTE 726 50, Ruanjian Avenue 727 Nanjing, 210012, China 729 Email: luo.jian@zte.com.cn 731 Lizhong Jin (editor) 732 Individual 733 Shanghai, China 735 Email: lizho.jin@gmail.com 737 Thomas Nadeau (editor) 738 Lucidvision 740 Email: tnadeau@lucidvision.com 741 George Swallow (editor) 742 Cisco 743 300 Beaver Brook Road 744 Boxborough , MASSACHUSETTS 01719, USA 746 Email: swallow@cisco.com