idnits 2.17.1 draft-ietf-mpls-interas-lspping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 2007) is 6251 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) ** Downref: Normative reference to an Informational RFC: RFC 4377 ** Downref: Normative reference to an Informational RFC: RFC 4378 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Thomas D. Nadeau 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: September 2007 6 George Swallow 7 Cisco Systems, Inc. 9 March 2007 11 Detecting MPLS Data Plane Failures in 12 Inter-AS and inter-provider Scenarios 14 draft-ietf-mpls-interas-lspping-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This document describes a simple and efficient mechanism that can be 42 used to detect data plane failures in Multi-Protocol Label Switching 43 Label Switched Paths that extend beyond a single Autonomous System 44 and/or across multiple Service Provider network boundaries. This 45 document describes extensions to the existing MPLS LSP Ping protocol 46 to achieve these goals. 48 Contents 50 1 Introduction .............................................. 3 51 2 Terminology ............................................... 3 52 2.1 Conventions used in this document ......................... 3 53 2.2 Terminology ............................................... 3 54 2.3 Acronyms .................................................. 4 55 3 Structure of This Document ................................ 4 56 4 Motivation ................................................ 4 57 5 Inter-AS TLVs ............................................. 5 58 5.1 Inter-AS TLV .............................................. 5 59 5.1.1 IPv4 Inter-AS TLV ......................................... 7 60 5.1.2 IPv6 Inter-AS TLV ......................................... 8 61 5.1.3 Visited ASBR Address Stack ................................ 9 62 6 Error Code(s) ............................................. 11 63 7 Theory of Operation ....................................... 11 64 7.1 Adjustments to Outgoing Labels ............................ 12 65 7.2 Receiving Echo Replies .................................... 12 66 8 Security Considerations ................................... 14 67 9 IANA Considerations ....................................... 14 68 9.1 Message Types, Reply Modes, Return Codes .................. 14 69 9.2 TLVs ...................................................... 15 70 10 References ................................................ 15 71 10.1 Normative References ...................................... 15 72 10.2 Informative References .................................... 15 73 11 Acknowledgments ........................................... 16 74 12 Authors' Addresses ........................................ 16 75 1. Introduction 77 This document describes a simple and efficient mechanism that can be 78 used to detect data plane failures in MPLS LSPs that span across mul- 79 tiple Autonomous System (AS) and service provider boundaries. At 80 present, the existing MPLS LSP Ping protocol cannot handle all but 81 one of these cases. This document first explains the scenarios where 82 the existing protocol is inadequate, then describes information car- 83 ried in extended MPLS "echo request" and "echo reply" messages; and 84 finally describes enhanced mechanisms for transporting the echo 85 reply, as well as processing it at intermediate points (both in an 86 out of the originating AS). 88 An important consideration in this design is that MPLS echo requests 89 follow the same data path that normal MPLS packets would traverse. 90 MPLS echo requests are meant primarily to validate the data plane, 91 and secondarily to verify the data plane against the control plane. 92 Mechanisms to check the control plane are valuable, but are not cov- 93 ered in this document. 95 As is described in [RFC4379], to avoid potential Denial of Service 96 attacks, it is recommended to regulate the LSP ping traffic going to 97 the control plane. A rate limiter should be applied to the well- 98 known UDP port defined below. Furthermore, due to the fact that 99 there are data exchanges between provider networks which may wish to 100 hide the details of their network, it is recommended that the inter- 101 AS border routers provide operators with control over what informa- 102 tion (i.e.: addresses) in these messages. 104 2. Terminology 106 2.1. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2.2. Terminology 114 Definitions of key terms for MPLS OAM are found in [RFC4378] and the 115 reader is assumed to be familiar with those definitions which are not 116 repeated here. 118 The following additional terms are useful to understand this docu- 119 ment. 121 2.3. Acronyms 123 The following list of acronyms is a repeat of common acronyms defined 124 in many other documents, and is provided here for convenience. 126 CE: Customer Edge 127 PE: Provider Edge ASBR: Autonomous System Border Router 128 DoS: Denial of service ECMP: Equal Cost Multipath 129 LDP: Label Distribution Protocol 130 LSP: Label Switch Path 131 LSR: Label Switch Router 132 OAM: Operations and Management OA&M: Operations, Administration and 133 Maintenance. RSVP: Resource reSerVation Protocol 134 SP: Service Provider 136 3. Structure of This Document 138 The body of this memo contains four main parts: motivation, exten- 139 sions to the MPLS echo request/reply packet format, inter-AS LSP ping 140 operation, and a reliable return path. It is suggested that first- 141 time readers skip the actual packet formats and read the Theory of 142 Operation first; the document is structured the way it is to avoid 143 forward references. 145 4. Motivation 147 The requirements specified in [RFC4377] stipulate that data plane OAM 148 functions must be provided as solutions for service providers. These 149 data plane test functions must not only function within an autonomous 150 system (AS), but must also function across ASs. Furthermore, these 151 tests must function correctly across ASs that span multiple Service 152 Provider(SP) domains. At present, the data plane liveliness tools 153 function in these capacities only in the narrow (and rarely used) 154 case where the IP addresses of LSRs involved are known to each other. 155 For example, when the IP addresses from one AS are exchanged through 156 routing with other attached ASs. Another case includes the Layer-3 157 VPN inter-provider interconnection where the PE addresses are dis- 158 tributed between service providers. However, these cases are uncom- 159 mon, and thus the existing LSP Ping [RFC4379] tool is unable to 160 respond under most error condition configurations. For example con- 161 sider the following configuration. Imagine that PE1 and PE2 are in 162 two different provider domains. In this case, it is common for 163 providers to NOT distribute the IP addresses of any of the routers 164 other than the ASBR. 166 {---- AS1 ----} {---- AS2 ----} 167 PE1--P---P--ASBR1----ASBR2--P---P--PE2 169 Now, imagine that the LSP that connects PE1 to PE2 contains a fault 170 somewhere bewteen ASBR2 and PE2 as is indicated by 'X' between the 171 two P routers: 173 {---- AS1 ----} {---- AS2 ----} 174 PE1--P---P--ASBR1----ASBR2--P-X-P--PE2 176 If an LSP Ping is initiated at PE1 with a destination of PE2 and a 177 source of PE1, the packet is label switched correctly until it 178 reaches the first P router within AS2. Here lets imagine that MPLS 179 forwarding is disabled on the link between the two P routers. Upon 180 discovering this while attempting to process the LSP Ping Request 181 packet, the first P router will attempt to reply directly to PE1 with 182 the appropriate error code 5. However, because the address of PE1 is 183 actually private to AS1 by virtue of not being distributed by ASBR1 184 into AS2, the P router cannot correctly forward the reply to PE1. In 185 this case, PE1 may surmise that some failure has occurred, but it 186 cannot determine what the error is or where it exists. This clearly 187 does not meet the requirements stipulted in [RFC4377]. This draft 188 describes extensions to [RFC4379] that overcome the aforementioned 189 limitations, and thus allow for the handling of inter-AS/provider 190 cases. 192 5. Inter-AS TLVs 194 5.1. Inter-AS TLV 196 The Inter-AS TLV Reply Object is an optional TLV that is used to col- 197 lect and report the ASBRs along the path of the LSP under test. Only 198 one such object may appear in a Reply message. The purpose of this 199 object is to allow the downstream router to relay a Reply message 200 from ASBR to ASBR when a failure is detected. A router will use this 201 TLV to look up the last ASBR as indicated as the top-most address on 202 the address stack, that forwarded the Request message into its AS, 203 and then forward the Reply to that router after popping the address 204 from the stack. The Reply message will ultimately be relayed to the 205 original soure of the request. This message has one format that con- 206 tains the true source and destination addresses of the Request mes- 207 sage, as well as a stack of ASBR addresses that were visited while 208 forwarding this message. Type 17 is defined for this TLV (to be 209 assigned by IANA). 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type = 17 (Inter-AS TLV) | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Source Node IP Address (4 or 16 octets) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Source Node AS Number | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Failed Node IP Address (4 or 16 octets) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Failed Node AS Number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Failed Node Contact String | 225 | | 226 | (16 octets) | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | SubType | SubLength | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Visited ASBR Address Stack | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 SubType: 236 Sub-Type # Length Value Field 237 ---------- ------ ------------- 238 1 6 IPv4 Return Stack 239 2 6 IPv4 Trace Stack 240 3 6 Ipv6 Return Stack 241 4 6 IPv6 Trace Stack 243 Note that only combinations of 1+2 or 3+4 may be used. Support of 244 mixed IPv4 and IPv6 ASes is beyond the scope of this document. 246 Failed Node AS Number: 248 This field may contain the AS number in which the node where the 249 failure was detected resides. If no AS number is indicated, this 250 field MUST contain 0s. 252 Failed Node IP Address: 254 This must be a valid IPv4 or IPv6 address assigned to the router. 256 If the interface to the downstream LSR is numbered, then the 257 Address Type MUST be set to IPv4 or IPv6, Failed Node IP Address 258 MUST be set to either the downstream LSR's Router ID or the 259 interface address of the downstream LSR. 261 If the interface to the downstream LSR is unnumbered, the Address 262 Type MUST be Unnumbered, the Downstream IP Address MUST be the 263 downstream LSR's Router ID. 265 Failed Node AS Number: 267 This field may contain the AS number in which the node where the 268 failure was detected resides. If no AS number is indicated, this 269 field MUST contain 0s. 271 Failed Node Contact String: 273 This field may contains a string of ASCII characters inserted by 274 the node where the failure was detected or by its closest ASBR. 275 This field MUST indicate contact information such as a provider's 276 international phone number and other relevant contact information 277 in cases where local policy dictates that a provider will not fill 278 in the Failed Node AS number and/or the Failed Node Address. In 279 all other cases, this field MUST contain 0s. 281 5.1.1. IPv4 Inter-AS TLV 283 The value consists of four octets of an IPv4 prefix followed by one 284 octet of prefix length in bits; the format is given below. The IPv4 285 prefix is in network byte order; if the prefix is shorter than 32 286 bits, trailing bits SHOULD be set to zero. . 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type = 17 (Inter-AS TLV) | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Source Node IPv4 Address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Source Node AS Number | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Failed Node IPv4 Address | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Failed Node AS Number | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Failed Node Contact String | 302 | | 303 | | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SubType | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 5.1.2. IPv6 Inter-AS TLV 311 The value consists of 16 octets of an IPv6 prefix followed by one 312 octet of prefix length in bits; the format is given below. The IPv6 313 prefix is in network byte order; if the prefix is shorter than 128 314 bits, trailing bits SHOULD be set to zero. This FEC is used if the 315 protocol advertising the label is unknown, or may change during the 316 course of the LSP. An example is ani nter-AS LSP that may be sig- 317 naled by LDP in one AS, by RSVP-TE in another AS, and by BGP between 318 the ASs, such as is common for inter-AS VPNs. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type = 17 (Inter-AS TLV) | Length = 5 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Source Node IPv6 Address | 326 | (16 octets) | 327 | | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Source Node AS Number | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Failed Node IPv6 Address | 333 | (16 octets) | 334 | | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Failed Node AS Number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Failed Node Contact String | 340 | | 341 | | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | SubType | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 5.1.3. Visited ASBR Address Stack 349 The term Visited ASBR Address Stack applies to two stacks of IP 350 addresses of the ASBRs along the path of an LSP called the Trace and 351 Return Stacks. The two stacks have the same format; however they 352 have slightly different semantics. Both stack objects are stacks of 353 addresses that denote the list of visited ASBRs. The obeject is a 354 stack either an IPv4 address if the TLV SubType field is set to 1 or 355 2, or an IPv6 address if the TLV SubType field is set to 3 or 4. 357 The Return Stack is to be used in a destructive manner as a means of 358 unwinding the path of ASBRs that were used to originally forward the 359 Request. Each subsequent ASBR along the path that receives the reply 360 should destructively remove itself from the stack. 362 On the other hand, the Trace Stack MUST only be added to (i.e.: ASBR 363 addresses pushed) and items never removed from this stack. This will 364 allow the source to see the trace of the path of ASBRs once the Reply 365 message is returned. In cases where policy dictates that ASBR 366 addresses must be hidden, a value of all 0s MUST be inserted into the 367 stack, or the stack completely removed prior to forwarding the Reply. 368 It is prefered that a blank entry be left, as this will at least 369 indicate that there was one hop without revealing its IP address. 371 IPv4 Trace and Visited Stack Objects 373 The Length is 4*N octets, N is the number of visited ASBRs. 374 This object has the following format: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | ASBR IPv4 Address 1 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | ASBR IPv4 Address 2 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 . . 384 . ... . 385 . . 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ASBR IPv4 Address N | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 ASBR IPv4 Address 1, ASBR IPv4 Address 1, ... contain a valid 391 IPv4 address. 393 IPv6 Trace and Visited Stack Objects 395 The Length is 16*N octets, N is the number of visited ASBRs. 396 This object has the following format: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | ASBR IPv6 Address 1 | 402 | ASBR IPv6 Address (Cont.) | 403 | ASBR IPv6 Address (Cont.) | 404 | ASBR IPv6 Address (Cont.) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 . . 407 . ... . 408 . . 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | ASBR IPv6 Address N | 411 | ASBR IPv6 Address (Cont.) | 412 | ASBR IPv6 Address (Cont.) | 413 | ASBR IPv6 Address (Cont.) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 ASBR IPv6 Address 1, ASBR IPv6 Address 1, ... contain a valid 417 IPv4 address. 418 IPv6 420 6. Error Code(s) 422 TBD 424 7. Theory of Operation 426 hen tracing an LSP which spans multiple AS, an Inter-AS Reply Object 427 s included in the Echo Request. Initially the object contains only 428 he address of the source PE and a Trace stack with that same address. 429 s the tracing progress each ASBR copies the trace stack as a reply 430 tack, it then pushes its address to the trace stack. It includes oth 431 stacks in an Inter-AS Reply object and sends it in an Echo eply mes- 432 sage to the top address in the reply stack. The receiver f the Reply 433 message then verifies that it is included in the reply tack. It then 434 pops its address from the reply stack and e-addresses the Echo Reply 435 message to the (new) top element of the eply stack. This is repeated 436 until the source PE receives the cho Reply. 438 7.1. Adjustments to Outgoing Labels 440 When an LSP request is sent from an originator, some adjustments may 441 need to be made to outgoing labels: 443 Inter-AS cases: 445 A) VRF to VRF 447 The LSP terminates at the ASBR. These procedures do not apply. 449 B) EBGP redistribution of labeled VPN-IPv4 routes from AS to 450 neighboring AS. 452 Tracing is performed by incrementing the VPN label begining at 453 one. 454 If TTL hiding is in effect, then tracing of PSN label is not 455 necessary for these procedures. 457 C) Carrier's Carrier (CsC): 1) TTL Hiding 458 a. Will work as is. 459 b. Verification of the core must be done separately by core own- 460 ers. 461 c. Traceroute can trace both stubs of the 'carried' carrier. 463 2) No TTL hiding 464 a. Set VPN TTL to 1. 465 b. CsC CE or Ps would return to the CsC PE who would relay mes- 466 sages 467 back to originator. 468 c. For traceroute, set VPN TTL=1, and progressively increase the 469 IGP TTL by 1 to probe. 471 7.2. Receiving Echo Replies 473 The existing packet processing algorithm as specified in [RFC4379] is 474 enhanced as follows to support inter-AS/provider LSP ping/trace. 476 When an Echo Reply message is received: 478 1) If the packet is addressed to this router 479 (i.e.: destination address == this router's router ID): 481 a. If the original sender field TLV == this router's address, 482 process normally. // today's functionality for a normal 483 reply received by the src. 485 b. Else this packet has been delivered to this router because it 486 is an ASBR and needs to proxy for a P router in its AS to 487 return the reply. 489 If the inter-AS TLV is present, 491 i. If the last visited AS is empty, set it to the ASBR's 492 primary AS#. 494 ii. If the stack is empty, this is an error case. The TLV 495 SHOULD NOT be present if the stack is empty. 497 iii. Else if the top-most address in the stack is this 498 router's address. 500 1. Pop it from the stack. 501 2. Replace the packet's destination address with the 502 next address in the stack. 503 3. Replace the packet's src address with this ASBR's address. 504 4. Optionally, the ASBR may hide (i.e.: remove) information 505 that its local policy has been configured for. 506 5. Look up the route/next-hop for this address and deliver 507 the packet. The ASBR should be able to resolve the 508 address because at this point unless there has been an 509 error in the return path forwarding, then the packet 510 should be at the border of the originating AS. If the 511 look-up fails, drop the packet and notify the operator 512 of this router that an error condition has occurred. 514 When an LSP ping request is received: 516 2) If this router is an ASBR 517 a. Write the next entry in the Last Seen ASBR stack's address 518 as the destination address of the packet and forward it to 519 that address. 520 b. Otherwise process normally as specified in the LSP ping draft. 522 8. Security Considerations 524 In addition to the Security Considerations from [RFC4379], here are 525 at least two approaches to attacking LSRs using the mecha- nisms 526 defined here. 528 One is a Denial of Service attack, by sending MPLS echo 529 requests/replies to LSRs and thereby increasing their workload. The 530 other is obfuscating the state of the MPLS data plane liveness by 531 spoofing, hijacking, replaying or otherwise tampering with MPLS echo 532 requests and replies. 534 Authentication will help reduce the number of seemingly valid MPLS 535 echo requests, and thus cut down the Denial of Service attacks; 536 beyond that, each LSR must protect itself. 538 Authentication sufficiently addresses spoofing, replay and most tam- 539 pering attacks; one hopes to use some mechanism devised or suggested 540 by the RPSec WG. It is not clear how to prevent hijacking (non- 541 delivery) of echo requests or replies; however, if these messages are 542 indeed hijacked, LSP ping will report that the data plane isn't work- 543 ing as it should. 545 It doesn't seem vital (at this point) to secure the data carried in 546 MPLS echo requests and replies, although knowledge of the state of 547 the MPLS data plane may be considered confidential by some. 549 9. IANA Considerations 551 [need to request some new Message Types, TLV Types, Return Codes] 553 9.1. Message Types, Reply Modes, Return Codes 555 It is requested that IANA maintain registries for Message Types, 556 Reply Modes, Return Codes and Return Subcodes. Each of these can 557 take values in the range 0-255. Assignments in the range 0-191 are 558 via Standards Action; assignments in the range 192-251 are made via 559 Expert Review; values in the range 252-255 are for Vendor Private 560 Use, and MUST NOT be allocated. 562 If any of these fields fall in the Vendor Private range, a top-level 563 Vendor Enterprise Code TLV MUST be present in the message. 565 9.2. TLVs 567 It is requested that IANA maintain registries for the Type field of 568 top-level TLVs as well as for sub-TLVs. The valid range for each of 569 these is 0-65535. Assignments in the range 0-16383 and 32768-49161 570 are made via Standards Action as defined in [RFC2434]; assignments in 571 the range 16384-31743 and 49162-64511 are made via Expert Review (see 572 below); values in the range 31744-32746 and 64512-65535 are for Ven- 573 dor Private Use, and MUST NOT be allocated. 575 If a TLV or sub-TLV has a Type that falls in the range for Vendor 576 Private Use, the Length MUST be at least 4, and the first four octets 577 MUST be that vendor's SMI Enterprise Code, in network octet order. 578 The rest of the Value field is private to the vendor. 580 10. References 582 10.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., 588 Matshushima, S., "Operations and Management (OAM) 589 Requirements for Multi-Protocol Label Switched 590 (MPLS) Networks", RFC 4377, February 2006. 592 [RFC4378] Allan, D., Nadeau, T., "A Framework for 593 Multi-Protocol Label Switching (MPLS) 594 Operations and Management", RFC 4378, 595 February 2006. 597 [RFC4379] Kompella, k., Swallow, G., "Detecting MPLS Data Plane 598 Liveness", RFC 4379, February 2006. 600 10.2. Informative References 602 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 603 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 604 October 1998. 606 11. Acknowledgments 608 The authors wish to acknowledge and thank the following individuals 609 for their valuable comments to this document: Azhar Sayeed, Vanson 610 Lim, and Mike Piecuch. 612 12. Authors' Addresses 614 Thomas D. Nadeau 615 Cisco Systems, Inc. 616 1414 Massachusetts Ave, 617 Boxboro, MA 01719 618 Phone: +1.978.936.1470 619 Email: tnadeau@cisco.com 621 George Swallow 622 Cisco Systems 623 1414 Massachusetts Ave, 624 Boxborough, MA 01719 625 Phone: +1 978 936 1398 626 Email: swallow@cisco.com 628 Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any assur- 640 ances of licenses to be made available, or the result of an attempt 641 made to obtain a general license or permission for the use of such 642 proprietary rights by implementers or users of this specification can 643 be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at ietf- 650 ipr@ietf.org. 652 Full Copyright Notice 654 Copyright (C) The IETF Trust (2007). This document is subject to the 655 rights, licenses and restrictions contained in BCP 78, and except as 656 set forth therein, the authors retain all their rights. 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 661 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 662 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 663 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.