idnits 2.17.1 draft-ietf-mpls-lsp-ping-relay-reply-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4379, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: K bit: If the K bit is set to 1, then this sub-TLV SHOULD be kept in Relay Node Address Stack, SHOULD not be deleted in compress process of section 4.2. The K bit may be set by ASBRs which address would be kept in the stack if necessary. (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 (February 14, 2014) is 3723 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 6 Expires: August 18, 2014 T. Nadeau, Ed. 7 Lucidvision 8 G. Swallow, Ed. 9 Cisco 10 February 14, 2014 12 Relayed Echo Reply mechanism for LSP Ping 13 draft-ietf-mpls-lsp-ping-relay-reply-02 15 Abstract 17 In some inter autonomous system (AS) and inter-area deployment 18 scenarios for Label Switched Path (LSP) Ping and Traceroute, a 19 replying LSR may not have the available route to the initiator, and 20 the Echo Reply message sent to the initiator would be discarded 21 resulting in false negatives or complete failure of operation of LSP 22 Ping and Traceroute. This document describes extensions to LSP Ping 23 mechanism to enable the replying Label Switching Router (LSR) to have 24 the capability to relay the Echo Response by a set of routable 25 intermediate nodes to the initiator. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 5 66 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 5 67 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 68 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 7 70 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 7 71 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 8 72 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . . 9 73 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 9 74 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 9 75 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 12 80 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 This document describes the extensions to the Label Switched Path 92 (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply 93 mechanism which could be used to detect data plane failures in inter 94 autonomous system (AS) and inter-area LSPs. Without this extension, 95 the ping functionality provided by [RFC4379] would fail in many 96 deployed inter-AS scenarios, since the replying LSR in one AS may not 97 have the available route to the initiator in the other AS. The 98 mechanism in this draft defines a new message type referred as 99 "Relayed Echo Reply message", and a new TLV referred as "Relay Node 100 Address Stack TLV". 102 1.1. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Motivation 110 LSP Ping [RFC4379] defines a mechanism to detect data plane failures 111 and localize faults. The mechanism specifies that the Echo Reply 112 should be sent back to the initiator usig an UDP packet with the 113 IPv4/ IPv6 address of the originating LSR. This works in 114 administrative domains allowing IP address reachability and routing 115 back to the originating LSR. However, in practice, this is often not 116 the case due to intra-provider routing policy, route hiding, network 117 address translation at autonomous system border routers (ASBR), and 118 etc. In fact, it is almost uniformly the case that in inter-AS 119 scenarios, it is not allowed the distribution or direct routing to 120 the IP addresses of any of the nodes other than the ASBR. 122 Figure 1 demonstrates a case where one LSP is set up between PE1 and 123 PE2. If private addresses were in use within AS2, a traceroute from 124 PE1 directed to PE2 could fail if the fault exists somewhere between 125 ASBR2 and PE2. Because P2 cannot forward packets back to PE1 given 126 that it is a private address within AS1. In this case, PE1 would 127 detect a path break, as the Echo Request messages would not be sent 128 back; however, localization of the actual fault would not be 129 possible. 131 +-------+ +-------+ +------+ +------+ +------+ +------+ 132 | | | | | | | | | | | | 133 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 134 | | | | | | | | | | | | 135 +-------+ +-------+ +------+ +------+ +------+ +------+ 136 <---------------AS1-------------><---------------AS2------------> 137 <---------------------------- LSP ------------------------------> 139 Figure 1: Simple Inter-AS LSP Configuration 141 A second example that illustrates how [RFC4379] would be insufficient 142 would be the inter-area situation in a Seamless MPLS architecture 143 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this 144 example P nodes the in core network would not have IP reachable route 145 to any of the ANs. When tracing an LSP from AN to remote AN, the 146 LSR1/LSR2 node could not make a response to the Echo Request either, 147 like P2 node in the inter-AS scenario in Figure 1. 149 +-------+ +-------+ +------+ +------+ 150 | | | | | | | | 151 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 152 / | | /| | | | | | 153 +----+/ +-------+\/ +-------+ +------+ /+------+ 154 | AN | /\ \/ 155 +----+\ +-------+ \+-------+ +------+/\ +------+ 156 \ | | | | | | \| | 157 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 158 | | | | | | | | 159 +-------+ +-------+ +------+ +------+ 160 static route ISIS L1 LDP ISIS L2 LDP 161 <-Access-><--Aggregation Domain--><---------Core---------> 163 Figure 2: Seamless MPLS Architecture 165 This document describes extensions to the LSP Ping mechanism to 166 facilitate a response from the replying LSR, by defining a simple 167 mechanism that uses the relay node (e.g, ASBR) to relay the message 168 back to the initiator. This approach will work because every 169 designated or learned relay node must have an IP route back to the 170 initiator. Using a recursive approach, relay node could relay the 171 message to the next relay node until the initiator is reached. 173 3. Extensions 175 [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines 176 two message types, Echo Request and Echo Reply message. This draft 177 defines a new message, Relayed Echo Reply message. This new message 178 is used to replace Echo Reply message which is sent from the replying 179 LSR to a relay node or from a relay node to another relay node. 181 A new TLV named Relay Node Address Stack TLV is defined in this 182 draft, to carry the IP addresses of the possible relay nodes for the 183 replying LSR. 185 In addition, a new Return Code is defined to notify the initiator 186 that the packet length was exceeded unexpected by the Relay Node 187 Address Stack TLV. 189 It should be noted that this document focuses only on detecting the 190 LSP which is set up using a uniform type of IP address. That is, all 191 hops between the source and destination use one address type of their 192 control planes. This does not preclude nodes that support both IPv6 193 and IPv4 addresses simultaneously, but the entire path must be 194 addressable using only one address family type. Supporting for mixed 195 IPv4-only and IPv6-only is beyond the scope of this document. 197 3.1. Relayed Echo Reply message 199 The Relayed Echo Reply message is a UDP packet, and the UDP payload 200 has the same format with Echo Request/Reply message. A new message 201 type is requested from IANA. 203 New Message Type: 204 Value Meaning 205 ----- ------- 206 TBD MPLS Relayed Echo Reply 208 The TCP and UDP port number 3503 has been allocated in [RFC4379] by 209 IANA for LSP Ping messages. The Relayed Echo Reply message will use 210 the same port number. 212 3.2. Relay Node Address Stack 214 The Relay Node Address Stack TLV is an optional TLV. It MUST be 215 carried in the Echo Request, Echo Reply and Relayed Echo Reply 216 messages if the echo reply relayed mechanism described in this draft 217 is required. Figure 3 illustrates the TLV format. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Initiator Source Port | Number of Relayed Addresses | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 ~ Stack of Relayed Addresses ~ 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 3: Relay Node Address Stack TLV 233 - Type: to be assigned by IANA. A suggested value is assigned from 234 32768-49161 as suggested by RFC4379 Section 3. 236 - Length: The Length of the Value field in octets. 238 - Initiator Source Port: The port that the initiator sends the Echo 239 Request message, and also the port that expected to receive the 240 Echo Reply message. 242 - Number of Relayed Addresses: An integer indicating the number of 243 relayed addresses in the stack. 245 - Stack of Relayed Addresses: A list of relay node addresses. 247 The format of each relay node address is as below: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Address Type | Address Length| Reserved |K| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ~ Relayed Address (0, 4, or 16 octects) ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Type# Address Type Address Length 258 ---- ------------ ------------ 259 0 Unspecified 0 260 1 IPv4 4 261 2 IPv6 16 263 Reserved: This field is reserved for future use and MUST be set to 264 zero. 266 K bit: If the K bit is set to 1, then this sub-TLV SHOULD be kept in 267 Relay Node Address Stack, SHOULD not be deleted in compress process 268 of section 4.2. The K bit may be set by ASBRs which address would be 269 kept in the stack if necessary. 271 If the K bit is set to 0, then this sub-TLV SHOULD be processed 272 normally according to section 4.2. 274 Relayed Address: This field specifies the node address, either IPv4 275 or IPv6. 277 3.3. New Return Code 279 A new Return Code is used by the replying LSR to notify the initiator 280 that the packet length was exceeded unexpected by the Relay Node 281 Address Stack TLV. 283 New Return Code: 284 Value Meaning 285 ----- ------- 286 TBD Response Packet length was exceeded by the Relay Node 287 Address Stack TLV unexpected 289 4. Procedures 291 4.1. Sending an Echo Request 293 In addition to the procedures described in Section 4.3 of [RFC4379], 294 a Relay Node Address Stack TLV MUST be carried in the Echo Request 295 message for facilitate the relay functionality. 297 When the Echo Request is first sent by initiator supporting these 298 extensions, a Relay Node Address Stack TLV with the initiator address 299 in the stack and its source port MUST be included. That will ensure 300 that the first relay node address in the stack will always be the 301 initiator address. 303 For the subsequent Echo Request messages, the initiator would copy 304 the Relay Node Address Stack TLV from the received Echo Reply 305 message. 307 4.2. Receiving an Echo Request 309 In addition to the processes in Section 4.4 of [RFC4379], the 310 procedures of the Relay Node Address Stack TLV are defined here. 312 Upon receiving a Relay Node Address Stack TLV of the Echo Request 313 message, the receiver MUST check the addresses of the stack in 314 sequence from top to bottom (the first address in the stack ==== will 315 be first one to be checked), to find out the first public routable IP 316 address. Those address entries behind of the first routable IP 317 address in the address list with K bit set to 0 MUST be deleted, and 318 the address entry of the replying LSR MUST be added at the bottom of 319 the stack. Those address entries with K bit set to 1 MUST be kept in 320 the stack. The updated Relay Node Address Stack TLV MUST be carried 321 in the response message. 323 If the replying LSR wishes to hide its routable address information, 324 the address entry added in the stack SHOULD be a blank entry with 325 Address Type set to unspecified. The blank address entry in the 326 receiving Echo Request SHOULD be treated as an unroutable address 327 entry. 329 If the packet length was exceeded unexpectedly by the Relay Node 330 Address Stack TLV, the TLV SHOULD be returned back unchanged in the 331 echo response message. And the new return code SHOULD help to notify 332 the initiator of the situation. 334 If the first routable IP address is the first address in the stack, 335 the replying LSR SHOULD respond an Echo Reply message to the 336 initiator. 338 If the first routable IP address is of an intermediate node, other 339 than the first address in the stack, the replying LSR SHOULD send an 340 Relayed Echo Reply instead of an Echo Reply in response. 342 An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore 343 it according to section 3 of RFC4379. 345 4.3. Originating an Relayed Echo Reply 347 When the replying LSR received an Echo Request with the initiator IP 348 address in the Relay Node Address Stack TLV is IP unroutable, the 349 replying LSR SHOULD send an Relayed Echo Reply message to the first 350 routable intermediate node. The processing of Relayed Echo Reply is 351 the same with the procedure of the Echo Reply described in Section 352 4.5 of RFC4379, except the destination IP address and the destination 353 UDP port of the message part. The destination IP address of the 354 Relayed Echo Reply is set to the first routable IP address from the 355 Relay Node Address Stack TLV, and both the source and destination UDP 356 port is set to 3503. 358 4.4. Relaying an Relayed Echo Reply 360 Upon receiving an Relayed Echo Reply message with its address as the 361 destination address in the IP header, the relay node should check the 362 address items in Relay Node Address Stack TLV in sequence from top to 363 down, and find the first routable node address. 365 If the first routable address is the top one of the address list, 366 e.g, the initiator address, the relay node SHOULD send an Echo Reply 367 message to the initiator containing the same payload with the Relayed 368 Echo Reply message received. See section 4.5 for detail. 370 If the first routable address is not the top one of the address list, 371 e.g, another intermediate relay node, the relay node SHOULD send an 372 Relayed Echo Reply message to this relay node with the payload 373 unchanged. 375 Note, the replying LSR SHOULD send a Relayed Echo Reply message to 376 the first relay node found in Relay Node Address Stack TLV that is 377 routable by the router. The routable address MUST be located before 378 the source IP address of the received Relayed Echo Reply which must 379 be also in the stack, otherwise the Relayed Echo Reply should not be 380 sent, so as to avoid potential loop. 382 4.5. Sending an Echo Reply 384 The Echo Reply is sent in two cases: 386 1. When the replying LSR received an Echo Request with the initiator 387 IP address in the Relay Node Address Stack TLV is IP routable, the 388 replying LSR would send an Echo Reply to the initiator. In addition 389 to the procedure of the Echo Reply described in Section 4.5 of 390 RFC4379, the Relay Node Address Stack TLV would be carried in the 391 Echo Reply. 393 2. When the intermediate relay node received an Relayed Echo Reply 394 with the initiator IP address in the Relay Node Address Stack TLV IP 395 routable, the intermediate relay node would send the Echo Reply to 396 the initiator with the payload unchanged other than the Message Type 397 field. The destination IP address of the Echo Reply is set to the 398 initiator IP address, and the destination UDP port would be copied 399 from the Initiator Source Port field of the Relay Node Address Stack 400 TLV. The source UDP port should be 3503. 402 4.6. Receiving an Echo Reply 404 In addition to the processes in Section 4.6 of [RFC4379], the 405 initiator would copy the Relay Node Address Stack TLV received in the 406 Echo Reply to the next Echo Request. 408 5. LSP Ping Relayed Echo Reply Example 410 Considering the inter-AS scenario in Figure 4 below. 412 +-------+ +-------+ +------+ +------+ +------+ +------+ 413 | | | | | | | | | | | | 414 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 415 | | | | | | | | | | | | 416 +-------+ +-------+ +------+ +------+ +------+ +------+ 417 <---------------AS1-------------><---------------AS2------------> 418 <--------------------------- LSP -------------------------------> 420 Figure 4: Example Inter-AS LSP 422 In the example, an LSP has been created between PE1 to PE2. When 423 performing LSP traceroute on the LSP, the first Echo Request sent by 424 PE1 with outter-most label TTL=1, contains the Relay Node Address 425 Stack TLV with the only address of PE1. 427 After processed by P1, P1's address will be added in the Relay Node 428 Address Stack TLV address list following PE1's address in the Echo 429 Reply. 431 PE1 copies the Relay Node Address Stack TLV into the next Echo 432 Request when receiving the Echo Reply. 434 Upon receiving the Echo Request, ASBR1 checks the address list in the 435 Relay Node Address Stack TLV in sequence, and finds out that PE1 436 address is routable. Then deletes P1 address, and adds its own 437 address following PE1 address. As a result, there would be PE1 438 address followed by ASBR1 address in the Relay Node Address Stack TLV 439 of the Echo Reply sent by ASBR1. 441 PE1 then sends an Echo Request with outer-most label TTL=3, 442 containing the Relay Node Address Stack TLV copied from the received 443 Echo Reply message. Upon receiving the Echo Request message, ASBR2 444 checks the address list in the Relay Node Address Stack TLV in 445 sequence, and finds out that PE1 address is IP route unreachable, and 446 ASBR1 address is the first routable one in the Relay Node Address 447 Stack TLV. ASBR2 adds its address as the last address item following 448 ASBR1 address in Relay Node Address Stack TLV, sets ASBR1 address as 449 the destination address of the Relayed Echo Reply, and sends the 450 Relayed Echo Reply to ASBR1. 452 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 453 address list in the Relay Node Address Stack TLV in sequence, and 454 finds out that PE1 address is first routable one in the address list. 455 Then ASBR1 send an Echo Reply to PE1 with the payload of received 456 Relayed Echo Reply no changes other than the Message Type field. 458 For the Echo Request with outer-most label TTL=4, P2 checks the 459 address list in the Relay Node Address Stack TLV in sequence, and 460 finds out that both PE1 and ASBR1 addresses are not IP routable, and 461 ASBR2 address is the first routable address. And P2 would send an 462 Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV of 463 four addresses, PE1, ASBR1, ASBR2 and P2 address in sequence. 465 Then according to the process described in section 4.4, ASBR2 would 466 send the Relayed Echo Reply to ASBR1. Upon receiving the Relayed 467 Echo Reply, ASBR1 would send an Echo Reply to PE1 as PE1 address is 468 routable. And as relayed by ASBR2 and ASBR1, the echo response would 469 finally be sent to the initiator PE1. 471 For the Echo Request with outer-most label TTL=5, the echo response 472 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 473 TTL=4. 475 The Echo Reply from the replying node which has no reachable route to 476 the initiator is finally transmitted to the initiator by multiple 477 relay nodes. 479 6. Security Considerations 481 The Relayed Echo Reply mechanism for LSP Ping creates an increased 482 risk of DoS by putting the IP address of a target router in the Relay 483 Node Address Stack. These messages then could be used to attack the 484 control plane of an LSR by overwhelming it with these packets. A 485 rate limiter SHOULD be applied to the well-known UDP port on the 486 relay node as suggested in RFC4379. The node which acts as a relay 487 node SHOULD validate the relay reply against a set of valid source 488 addresses and discard packets from untrusted border router addresses. 489 An implementation SHOULD provide such filtering capabilities. 491 If an operator wants to obscure their nodes, it is RECOMMENDED that 492 they may replace the replying node address that originated the Echo 493 Reply with blank address in Relay Node Address Stack TLV. 495 Other security considerations discussed in [RFC4379], are also 496 applicable to this document. 498 7. Backward Compatibility 500 When one of the nodes along the LSP does not support the mechanism 501 specified in this draft, the node will ignore the Relay Node Address 502 Stack TLV as described in section 4.2. Then the initiator may not 503 receive the Relay Node Address Stack TLV in Echo Reply message from 504 that node. In this case, an indication should be reported to the 505 operator, and the Relay Node Address Stack TLV in the next Echo 506 Request message should be copied from the previous Echo Request, and 507 continue the ping process. If the node described above is located 508 between the initiator and the first relay node, the ping process 509 could continue without interruption. 511 8. IANA Considerations 513 IANA is requested to assign one new Message Type, one new TLV and one 514 new Return Code. 516 8.1. New Message Type 518 New Message Type: 519 Value Meaning 520 ----- ------- 521 TBD MPLS Relayed Echo Reply 523 8.2. New TLV 525 New TLV: Routable Relay Node Address TLV 526 Type Meaning 527 ---- -------- 528 TBD Relay Node Address Stack TLV 530 A suggested value is assigned from 32768-49161 as suggested by 531 RFC4379 Section 3. 533 8.3. New Return Code 535 New Return Code: 536 Value Meaning 537 ----- ------- 538 TBD Response Packet length was exceeded by the Relay Node 539 Address Stack TLV unexpected 541 9. Acknowledgement 543 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 544 Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin and 545 Gregory Mirsky for their valuable comments and suggestions. 547 10. Contributors 549 Ryan Zheng 550 JSPTPD 551 371, Zhongshan South Road 552 Nanjing, 210006, China 553 Email: ryan.zhi.zheng@gmail.com 555 11. References 557 11.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 563 Label Switched (MPLS) Data Plane Failures", RFC 4379, 564 February 2006. 566 11.2. Informative References 568 [I-D.ietf-mpls-seamless-mpls] 569 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 570 M., and D. Steinberg, "Seamless MPLS Architecture", 571 draft-ietf-mpls-seamless-mpls-05 (work in progress), 572 January 2014. 574 Authors' Addresses 576 Jian Luo (editor) 577 ZTE 578 50, Ruanjian Avenue 579 Nanjing, 210012, China 581 Email: luo.jian@zte.com.cn 582 Lizhong Jin (editor) 583 Shanghai, China 585 Email: lizho.jin@gmail.com 587 Thomas Nadeau (editor) 588 Lucidvision 590 Email: tnadeau@lucidvision.com 592 George Swallow (editor) 593 Cisco 594 300 Beaver Brook Road 595 Boxborough , MASSACHUSETTS 01719, USA 597 Email: swallow@cisco.com