idnits 2.17.1 draft-ietf-mpls-lsp-ping-relay-reply-08.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2015) is 3285 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: October 30, 2015 T. Nadeau, Ed. 7 Lucidvision 8 G. Swallow, Ed. 9 Cisco 10 April 28, 2015 12 Relayed Echo Reply mechanism for LSP Ping 13 draft-ietf-mpls-lsp-ping-relay-reply-08 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 LSR may not have the available route to the 20 initiator, and the Echo Reply message sent to the initiator would be 21 discarded resulting in false negatives or complete failure of 22 operation of LSP Ping and Traceroute. This document describes 23 extensions to LSP Ping mechanism to enable the replying Label 24 Switching Router (LSR) to have the capability to relay the Echo 25 Response by a set of routable intermediate nodes to the initiator. 26 This document 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 October 30, 2015. 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 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 76 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 6 79 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 80 3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8 81 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 83 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9 84 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10 85 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10 86 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 87 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11 88 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 11 89 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14 94 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15 96 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 100 11.2. Informative References . . . . . . . . . . . . . . . . . 15 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 This document describes the extensions to the Label Switched Path 106 (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply 107 mechanism which could be used to detect data plane failures for the 108 inter autonomous system (AS) and inter-area LSPs. The extensions are 109 to update the [RFC4379]. Without these extensions, the ping 110 functionality provided by [RFC4379] would fail in many deployed 111 inter-AS scenarios, since the replying LSR in one AS may not have the 112 available route to the initiator in the other AS. The mechanism in 113 this document defines a new message type referred as "Relayed Echo 114 Reply message", and a new TLV referred as "Relay Node Address Stack 115 TLV". 117 This document is also to update [RFC4379], include updating of Echo 118 Request sending procedure in section 4.3 of [RFC4379], Echo Request 119 receiving procedure in section 4.4 of [RFC4379], Echo Reply sending 120 procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure 121 in section 4.6 of [RFC4379]. 123 1.1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Motivation 131 LSP Ping [RFC4379] defines a mechanism to detect the data plane 132 failures and localize faults. The mechanism specifies that the Echo 133 Reply should be sent back to the initiator using an UDP packet with 134 the IPv4/IPv6 address of the originating LSR. This works in 135 administrative domains where IP addresses reachability are allowed 136 among LSRs, and every LSR is able to route back to the originating 137 LSR. However, in practice, this is often not the case due to intra- 138 provider routing policy, route hiding, and network address 139 translation at autonomous system border routers (ASBR). In fact, it 140 is almost uniformly the case that in inter-AS scenarios, it is not 141 allowed the distribution or direct routing to the IP addresses of any 142 of the nodes other than the ASBR in another AS. 144 Figure 1 demonstrates a case where one LSP is set up between PE1 and 145 PE2. If PE1's IP address is not distributed to AS2, a traceroute 146 from PE1 directed towards PE2 can result in a failure because an LSR 147 in AS2 may not be able to send the Echo Reply message. E.g., P2 148 cannot forward packets back to PE1 given that it is an routable IP 149 address in AS1 but not routable in AS2. In this case, PE1 would 150 detect a path break, as the Echo Reply messages would not be 151 received. Then localization of the actual fault would not be 152 possible. 154 Note that throughout the document, routable address means that it is 155 possible to route an IP packet to this address using the normal 156 information exchanged by the IGP operating in the AS. 158 +-------+ +-------+ +------+ +------+ +------+ +------+ 159 | | | | | | | | | | | | 160 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 161 | | | | | | | | | | | | 162 +-------+ +-------+ +------+ +------+ +------+ +------+ 163 <---------------AS1-------------><---------------AS2------------> 164 <---------------------------- LSP ------------------------------> 166 Figure 1: Simple Inter-AS LSP Configuration 168 A second example that illustrates how [RFC4379] would be insufficient 169 would be the inter-area situation in a seamless MPLS architecture 170 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this 171 example LSRs in the core network would not have IP reachable route to 172 any of the ANs. When tracing an LSP from one AN to the remote AN, 173 the LSR1/LSR2 node cannot send the Echo Reply either, like the P2 174 node in the inter-AS scenario in Figure 1. 176 +-------+ +-------+ +------+ +------+ 177 | | | | | | | | 178 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 179 / | | /| | | | | | 180 +----+/ +-------+\/ +-------+ +------+ /+------+ 181 | AN | /\ \/ 182 +----+\ +-------+ \+-------+ +------+/\ +------+ 183 \ | | | | | | \| | 184 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 185 | | | | | | | | 186 +-------+ +-------+ +------+ +------+ 187 static route ISIS L1 LDP ISIS L2 LDP 188 <-Access-><--Aggregation Domain--><---------Core---------> 190 Figure 2: Seamless MPLS Architecture 192 This document describes extensions to the LSP Ping mechanism to 193 facilitate a response from the replying LSR, by defining a mechanism 194 that uses a relay node (e.g, ASBR) to relay the message back to the 195 initiator. Every designated or learned relay node must be reachable 196 to the next relay node or to the initiator. Using a recursive 197 approach, relay node could relay the message to the next relay node 198 until the initiator is reached. 200 The LSP Ping relay mechanism in this document is defined for unicast 201 case. How to apply the LSP Ping relay mechanism in multicast case is 202 out of the scope. 204 3. Extensions 206 [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines 207 two message types, Echo Request and Echo Reply message. This 208 document defines a new message, Relayed Echo Reply message. This new 209 message is used to replace Echo Reply message which is sent from the 210 replying LSR to a relay node or from a relay node to another relay 211 node. 213 A new TLV named Relay Node Address Stack TLV is defined in this 214 document, to carry the IP addresses of the possible relay nodes for 215 the replying LSR. 217 In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is 218 defined to indicate to the initiator that one or more TLVs will not 219 be returned due to MTU size. 221 It should be noted that this document focuses only on detecting the 222 LSP which is set up using a uniform IP address family type. That is, 223 all hops between the source and destination node use the same address 224 family type for their LSP ping control planes. This does not 225 preclude nodes that support both IPv6 and IPv4 addresses 226 simultaneously, but the entire path must be addressable using only 227 one address family type. Supporting for mixed IPv4-only and 228 IPv6-only is beyond the scope of this document. 230 3.1. Relayed Echo Reply message 232 The Relayed Echo Reply message is a UDP packet, and the UDP payload 233 has the same format with Echo Request/Reply message. A new message 234 type is requested from IANA. 236 New Message Type: 237 Value Meaning 238 ----- ------- 239 TBD MPLS Relayed Echo Reply 241 The use of TCP and UDP port number 3503 is described in [RFC4379] and 242 has been allocated by IANA for LSP Ping messages. The Relayed Echo 243 Reply message will use the same port number. 245 3.2. Relay Node Address Stack 247 The Relay Node Address Stack TLV is an optional TLV. It MUST be 248 carried in the Echo Request, Echo Reply and Relayed Echo Reply 249 messages if the echo reply relayed mechanism described in this 250 document is required. Figure 3 illustrates the TLV format. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Initiator Source Port | Reply Add Type| Reserved | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Source Address of Replying Router (0, 4, or 16 octects) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Destination Address Pointer | Number of Relayed Addresses | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 ~ Stack of Relayed Addresses ~ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: Relay Node Address Stack TLV 270 - Type: to be assigned by IANA. A value should be assigned from 271 32768-49161 as suggested by [RFC4379] Section 3. 273 - Length: the length of the value field in octets. 275 - Initiator Source Port: the source UDP port that the initiator uses 276 in the Echo Request message, and also the port that is expected to 277 receive the Echo Reply message. 279 - Reply Address Type: address type of replying router. This value 280 also implies the length of the address field as shown below. 282 Type# Address Type Address Length 283 ---- ------------ ------------ 284 0 Null 0 285 1 IPv4 4 286 2 IPv6 16 288 - Reserved: This field is reserved and MUST be set to zero. 290 - Source Address of Replying Router: source IP address of the 291 originator of Echo Reply or Replay Echo Reply message. 293 - Destination Address Pointer: an integer entry number used as the 294 destination address of the Reply or Relayed Reply message. The 295 entry on the top of the Stack of Relayed Addresses will have value 296 1. 298 - Number of Relayed Addresses: an integer indicating the number of 299 relayed addresses in the stack. 301 - Stack of Relayed Addresses: a list of relay node addresses. 303 The format of each relay node address is as below: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Address Type |K| Reserved | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ~ Relayed Address (0, 4, or 16 octects) ~ 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Type# Address Type Address Length 314 ---- ------------ ------------ 315 0 Null 0 316 1 IPv4 4 317 2 IPv6 16 318 Reserved: The two fields are reserved and MUST be set to zero. 320 K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in 321 Relay Node Address Stack during TLV compress process described in 322 section 4.2. 324 Having the K bit set in the relay node address entry causes that 325 entry to be preserved in the Relay Node Address Stack TLV for the 326 entire traceroute operation. A responder node MAY set the K bit to 327 ensure its relay node address entry remains as one of the relay nodes 328 in the Relay Node Address Stack TLV. The address with K bit set will 329 always be a relay node address for the Relayed Echo Reply, see 330 section 4.3. 332 Relayed Address: this field specifies the node address, either IPv4 333 or IPv6. 335 3.3. MTU Exceeded Return Code 337 Return Code is defined to indicate that one or more TLVs were omitted 338 from the Echo Reply or Relayed Echo Reply message to avoid exceeding 339 the message's effective MTU size. These TLVs MAY be included in an 340 Errored TLV's Object with their lengths set to 0 and no value. The 341 return sub-code MUST be set to the value that otherwise would have 342 been sent. 344 MTU Exceeded Return Code: 345 Value Meaning 346 ----- ------- 347 TBD One or more TLVs not returned due to MTU size 349 4. Procedures 351 4.1. Sending an Echo Request 353 In addition to the procedures described in section 4.3 of [RFC4379], 354 a Relay Node Address Stack TLV MUST be carried in the Echo Request 355 message to facilitate the relay functionality. 357 When the initiator sends the first Echo Request with a Relay Node 358 Address Stack TLV, the TLV MUST contain the initiator address as the 359 first entry of the stack of relayed addresses, the destination 360 address pointer set to this entry, and the source address of the 361 replying router set to null. The source UDP port field MUST be set 362 to the source UDP port. Note that the first relay node address in 363 the stack will always be the initiator's address. 365 4.2. Receiving an Echo Request 367 An LSR that does not recognize the Relay Node Address Stack TLV, 368 SHOULD ignore it as per section 3 of [RFC4379]. 370 In addition to the processes in section 4.4 of [RFC4379], the 371 procedures of the Relay Node Address Stack TLV are defined here. 373 Upon receiving a Relay Node Address Stack TLV in an Echo Request 374 message, the receiver updates the "Source Address of Replying 375 Router". The address MUST be same as the source IP address of Relay 376 Echo Reply (section 4.3) or Echo Reply message (section 4.5) being 377 sent. 379 Those address entries with K bit set to 1 MUST be kept in the stack. 380 The receiver MUST check the addresses of the stack in sequence from 381 bottom to top to find the last address in the stack with the K bit 382 set (or the top of the stack if no K bit was found). The receiver 383 then checks the stack beginning with this entry, proceeding towards 384 the bottom to find the first routable address IP address. The 385 Destination Address Pointer MUST be set to this entry which is also 386 the Destination Address. Address entries below the first routable IP 387 address MUST be deleted. At least one address entries of the 388 replying LSR MUST be added at the bottom of the stack. A second or 389 more address entries MAY also be added if necessary, depending on 390 implementation. The final address added MUST be an address that is 391 reachable through the interface that the Echo Request Message would 392 have been forwarded if it had not TTL expired at this node. The 393 updated Relay Node Address Stack TLV MUST be carried in the response 394 message. 396 If the replying LSR is configured to hide its routable address 397 information, the address entry added in the stack MUST be a NIL entry 398 with Address Type set to NULL. 400 If a node spans two addressing domains (with respect to this message) 401 where nodes on either side may not be able to reach nodes in the 402 other domain, then the final address added SHOULD set the K bit. K 403 bit applies in the case of a NULL address, to serve as a warning to 404 the initiator that further Echo Request messages may not result in 405 receiving Echo Reply messages. 407 If the full reply message would exceed the MTU size, the Relay Node 408 Address Stack TLV SHOULD be included in the Echo Reply message (i.e., 409 other optional TLVs are excluded). 411 4.3. Originating an Relayed Echo Reply 413 The Destination Address determined in section 4.2 is used as the next 414 relay node address. If the resolved next relay node address is not 415 routable, then sending of Relayed Echo Reply or Echo Reply will fail. 417 If the first IP address in the Relay Node Address Stack TLV is not 418 the next relay node address, the replying LSR SHOULD send a Relayed 419 Echo Reply message to the next relay node. The processing of Relayed 420 Echo Reply is the same with the procedure of the Echo Reply described 421 in Section 4.5 of [RFC4379], except the destination IP address and 422 the destination UDP port. The destination IP address of the Relayed 423 Echo Reply is set to the next relay node address from the Relay Node 424 Address Stack TLV, and both the source and destination UDP port are 425 set to 3503. The updated Relay Node Address Stack TLV described in 426 section 4.2 MUST be carried in the Relayed Echo Reply message. The 427 Source Address of Replying Router field is kept unmodified, and 428 Source IP address field of the IP header is set to an address of the 429 sending node. 431 4.4. Relaying an Relayed Echo Reply 433 Upon receiving an Relayed Echo Reply message with its own address as 434 the destination address in the IP header, the relay node MUST 435 determine the next relay node address as described in section 4.2, 436 with the modification that the location of the received Destination 437 Address is used instead of the bottom of stack in the algorithm. The 438 Destination Address Pointer in Relay Node Address Stack TLV will be 439 set to the next relay node address. Note that unlike section 4.2 no 440 changes are made to the Stack of Relayed Addresses. 442 If the next relay node address is not the first one in the address 443 list, i.e., another intermediate relay node, the relay node MUST send 444 an Relayed Echo Reply message to the determined upstream node with 445 the payload unchanged other than the Relay Node Address Stack TLV. 446 The TTL SHOULD be copied from the received Relay Echo Reply and 447 decremented by 1. The Source Address of Replying Router field is 448 kept unmodified, and Source IP address field of the IP header is set 449 to an address of the sending node. 451 4.5. Sending an Echo Reply 453 The Echo Reply is sent in two cases: 455 1. When the replying LSR receives an Echo Request, and the first IP 456 address in the Relay Node Address Stack TLV is the next relay node 457 address (section 4.3), the replying LSR would send an Echo Reply to 458 the initiator. In addition to the procedure of the Echo Reply 459 described in Section 4.5 of [RFC4379], the updated Relay Node Address 460 Stack TLV described in section 4.2 MUST be carried in the Echo Reply. 462 2. When the intermediate relay node receives a Relayed Echo Reply, 463 and the first IP address in the Relay Node Address Stack TLV is the 464 next relay node address (section 4.4), the intermediate relay node 465 would send the Echo Reply to the initiator, and update the Message 466 Type field from type of Relayed Echo Reply to Echo Reply. The 467 updated Relay Node Address Stack TLV described in section 4.4 MUST be 468 carried in the Echo Reply. The destination IP address of the Echo 469 Reply is set to the first IP address in the stack, and the 470 destination UDP port would be copied from the Initiator Source Port 471 field of the Relay Node Address Stack TLV. The source UDP port 472 should be 3503. The TTL of the Echo Reply SHOULD be copied from the 473 received Relay Echo Reply and decremented by 1. The Source Address 474 of Replying Router field is kept unmodified, and Source IP address 475 field of the IP header is set to an address of the sending node. 477 4.6. Sending Subsequent Echo Requests 479 During a traceroute operation, multiple Echo Request messages are 480 sent. Each time the TTL is increased, the initiator could copy the 481 Relay Node Address Stack TLV received in the previous Echo Reply to 482 the next Echo Request.Some modifications could also be made to the 483 stack TLV. The NIL entry with K bit set SHOULD be deleted, otherwise 484 the Echo Reply message will not be returned. The fields of Source 485 Address of Replying Router and Destination Address Pointer may be 486 preserved or may be reset for subsequent MPLS Echo Request, and to be 487 ignored in received MPLS Echo Request. 489 4.7. Impact to Traceroute 491 Source IP address in Echo Reply and Relay Echo Reply is to be of the 492 address of the node sending those packets, not the original 493 responding node. Then the traceroute address output module will 494 print the source IP address as below: 496 if (Relay Node Address Stack TLV exists) { 497 Print the Source Address of Replying Router in 498 Relay Node Address Stack TLV; 499 } else { 500 Print the source IP address of Echo Reply message; 501 } 503 5. LSP Ping Relayed Echo Reply Example 505 Considering the inter-AS scenario in Figure 4 below. AS1 and AS2 are 506 two independent address domains. In the example, an LSP has been 507 created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in 508 AS2. 510 +-------+ +-------+ +------+ +------+ +------+ +------+ 511 | | | | | | | | | | | | 512 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 513 | | | | | | | | | | | | 514 +-------+ +-------+ +------+ +------+ +------+ +------+ 515 <---------------AS1-------------><---------------AS2------------> 516 <--------------------------- LSP -------------------------------> 518 Figure 4: Example Inter-AS LSP 520 When performing LSP traceroute on the LSP, the first Echo Request 521 sent by PE1 with outer-most label TTL=1, contains the Relay Node 522 Address Stack TLV with PE1's address as the first relayed address. 524 After processed by P1, P1's interface address facing ASBR1 without 525 the K bit set will be added in the Relay Node Address Stack TLV 526 address list following PE1's address in the Echo Reply. 528 PE1 copies the Relay Node Address Stack TLV into the next Echo 529 Request when receiving the Echo Reply. 531 Upon receiving the Echo Request, ASBR1 checks the address list in the 532 Relay Node Address Stack TLV, and determines that PE1's address is 533 the next relay address. Then deletes P1's address, and adds its 534 interface address facing ASBR2 with the K bit set. As a result, 535 there would be PE1's address followed by ASBR1's interface address 536 facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply 537 sent by ASBR1. 539 PE1 then sends an Echo Request with outer-most label TTL=3, 540 containing the Relay Node Address Stack TLV copied from the received 541 Echo Reply message. Upon receiving the Echo Request message, ASBR2 542 checks the address list in the Relay Node Address Stack TLV, and 543 determines ASBR1's interface address is the next relay address in the 544 stack TLV. ASBR2 adds its interface address facing P2 with the K bit 545 set. Then ASBR2 sets the next relay address as the destination 546 address of the Relayed Echo Reply, and sends the Relayed Echo Reply 547 to ASBR1. 549 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 550 address list in the Relay Node Address Stack TLV, and determines that 551 PE1's address is the next relay node. Then ASBR1 sends an Echo Reply 552 to PE1. 554 For the Echo Request with outer-most label TTL=4, P2 checks the 555 address list in the Relay Node Address Stack TLV, and determines that 556 ASBR2's interface address is the next relay address. Then P2 sends 557 an Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV 558 containing four addresses, PE1's, ASBR1's interface address, ASBR2's 559 interface address and P2's interface address facing PE2 in sequence. 561 Then according to the process described in section 4.4, ASBR2 sends 562 the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo 563 Reply, ASBR1 sends an Echo Reply to PE1. And as relayed by ASBR2 and 564 ASBR1, the Echo Reply would finally be sent to the initiator PE1. 566 For the Echo Request with outer-most label TTL=5, the Echo Reply 567 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 568 TTL=4. 570 The Echo Reply from the replying node which has no IP reachable route 571 to the initiator is thus transmitted to the initiator by multiple 572 relay nodes. 574 6. Security Considerations 576 The Relayed Echo Reply mechanism for LSP Ping creates an increased 577 risk of DoS by putting the IP address of a target router in the Relay 578 Node Address Stack. These messages then could be used to attack the 579 control plane of an LSR by overwhelming it with these packets. A 580 rate limiter SHOULD be applied to the well-known UDP port on the 581 relay node as suggested in [RFC4379]. The node which acts as a relay 582 node SHOULD validate the relay reply against a set of valid source 583 addresses and discard packets from untrusted border router addresses. 584 An implementation SHOULD provide such filtering capabilities. 586 If an operator wants to obscure their nodes, it is RECOMMENDED that 587 they may replace the replying node address that originated the Echo 588 Reply with NIL address entry in Relay Node Address Stack TLV. 590 A receiver of an MPLS Echo Request could verify that the first 591 address in the Relay Node Address Stack TLV is the same address as 592 the source IP address field of the received IP header. 594 Other security considerations discussed in [RFC4379], are also 595 applicable to this document. 597 7. Backward Compatibility 599 When one of the nodes along the LSP does not support the mechanism 600 specified in this document, the node will ignore the Relay Node 601 Address Stack TLV as described in section 4.2. Then the initiator 602 may not receive the Relay Node Address Stack TLV in Echo Reply 603 message from that node. In this case, an indication should be 604 reported to the operator, and the Relay Node Address Stack TLV in the 605 next Echo Request message should be copied from the previous Echo 606 Request, and continue the ping process. If the node described above 607 is located between the initiator and the first relay node, the ping 608 process could continue without interruption. 610 8. IANA Considerations 612 IANA is requested to assign one new Message Type, one new TLV and one 613 Return Code. 615 8.1. New Message Type 617 This document requires allocation of one new message type from 618 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 619 Ping Parameters" registry, the "Message Type" registry: 621 Value Meaning 622 ----- ------- 623 TBD MPLS Relayed Echo Reply 625 The value should be assigned from the "Standards Action" range 626 (0-191), and using the lowest free value within this range. 628 8.2. New TLV 630 This document requires allocation of one new TLV from "Multi-Protocol 631 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 632 registry, the "TLVs" registry: 634 Type Meaning 635 ---- -------- 636 TBD Relay Node Address Stack TLV 638 A suggested value should be assigned from "Standards Action" range 639 (32768-49161) as suggested by [RFC4379] Section 3, using the first 640 free value within this range. 642 8.3. MTU Exceeded Return Code 644 This document requires allocation of MTU Exceeded return code from 645 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 646 Ping Parameters" registry, the "Return Codes" registry: 648 Value Meaning 649 ----- ------- 650 TBD One or more TLVs not returned due to MTU size 652 The value should be assigned from the "Standards Action" range 653 (0-191), and using the lowest free value within this range. 655 9. Acknowledgement 657 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 658 Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory 659 Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments 660 and suggestions. 662 10. Contributors 664 Ryan Zheng 665 JSPTPD 666 371, Zhongshan South Road 667 Nanjing, 210006, China 668 Email: ryan.zhi.zheng@gmail.com 670 11. References 672 11.1. Normative References 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 678 Label Switched (MPLS) Data Plane Failures", RFC 4379, 679 February 2006. 681 11.2. Informative References 683 [I-D.ietf-mpls-seamless-mpls] 684 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 685 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 686 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 688 Authors' Addresses 690 Jian Luo (editor) 691 ZTE 692 50, Ruanjian Avenue 693 Nanjing, 210012, China 695 Email: luo.jian@zte.com.cn 697 Lizhong Jin (editor) 698 Individual 699 Shanghai, China 701 Email: lizho.jin@gmail.com 703 Thomas Nadeau (editor) 704 Lucidvision 706 Email: tnadeau@lucidvision.com 708 George Swallow (editor) 709 Cisco 710 300 Beaver Brook Road 711 Boxborough , MASSACHUSETTS 01719, USA 713 Email: swallow@cisco.com