--- 1/draft-ietf-mpls-lsp-ping-12.txt 2006-02-04 17:01:29.000000000 +0100 +++ 2/draft-ietf-mpls-lsp-ping-13.txt 2006-02-04 17:01:29.000000000 +0100 @@ -1,23 +1,22 @@ - Network Working Group Kireeti Kompella Internet Draft Juniper Networks, Inc. Category: Standards Track -Expiration Date: June 2006 +Expiration Date: July 2006 George Swallow Cisco Systems, Inc. - December 2005 + January 2006 Detecting MPLS Data Plane Failures - draft-ietf-mpls-lsp-ping-12.txt + draft-ietf-mpls-lsp-ping-13.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -56,51 +55,51 @@ 3.1 Return Codes .............................................. 12 3.2 Target FEC Stack .......................................... 13 3.2.1 LDP IPv4 Prefix ........................................... 14 3.2.2 LDP IPv6 Prefix ........................................... 14 3.2.3 RSVP IPv4 LSP ............................................. 15 3.2.4 RSVP IPv6 LSP ............................................. 15 3.2.5 VPN IPv4 Prefix ........................................... 16 3.2.6 VPN IPv6 Prefix ........................................... 17 3.2.7 L2 VPN Endpoint ........................................... 17 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 18 - 3.2.9 FEC 128 Pseudowire (Current) .............................. 18 + 3.2.9 FEC 128 Pseudowire (Current) .............................. 19 3.2.10 FEC 129 Pseudowire ........................................ 19 - 3.2.11 BGP Labeled IPv4 Prefix ................................... 19 - 3.2.12 BGP Labeled IPv6 Prefix ................................... 20 - 3.2.13 Generic IPv4 Prefix ....................................... 20 - 3.2.14 Generic IPv6 Prefix ....................................... 21 - 3.2.15 Nil FEC ................................................... 21 - 3.3 Downstream Mapping ........................................ 22 - 3.3.1 Multipath Information Encoding ............................ 26 - 3.3.2 Downstream Router and Interface ........................... 28 - 3.4 Pad TLV ................................................... 28 - 3.5 Vendor Enterprise Number .................................. 29 - 3.6 Interface and Label Stack ................................. 29 - 3.7 Errored TLVs .............................................. 31 - 3.8 Reply TOS Byte TLV ........................................ 31 - 4 Theory of Operation ....................................... 32 - 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 32 - 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 33 - 4.3 Sending an MPLS Echo Request .............................. 33 - 4.4 Receiving an MPLS Echo Request ............................ 34 - 4.4.1 FEC Validation ............................................ 40 - 4.5 Sending an MPLS Echo Reply ................................ 41 - 4.6 Receiving an MPLS Echo Reply .............................. 42 - 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 42 - 4.8 Non-compliant Routers ..................................... 43 - 5 References ................................................ 43 - 6 Security Considerations ................................... 44 - 7 IANA Considerations ....................................... 45 - 7.1 Message Types, Reply Modes, Return Codes .................. 46 - 7.2 TLVs ...................................................... 47 - 8 Acknowledgments ........................................... 48 + 3.2.11 BGP Labeled IPv4 Prefix ................................... 20 + 3.2.12 BGP Labeled IPv6 Prefix ................................... 21 + 3.2.13 Generic IPv4 Prefix ....................................... 21 + 3.2.14 Generic IPv6 Prefix ....................................... 22 + 3.2.15 Nil FEC ................................................... 22 + 3.3 Downstream Mapping ........................................ 23 + 3.3.1 Multipath Information Encoding ............................ 27 + 3.3.2 Downstream Router and Interface ........................... 29 + 3.4 Pad TLV ................................................... 30 + 3.5 Vendor Enterprise Number .................................. 30 + 3.6 Interface and Label Stack ................................. 31 + 3.7 Errored TLVs .............................................. 32 + 3.8 Reply TOS Byte TLV ........................................ 33 + 4 Theory of Operation ....................................... 33 + 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 33 + 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 34 + 4.3 Sending an MPLS Echo Request .............................. 35 + 4.4 Receiving an MPLS Echo Request ............................ 36 + 4.4.1 FEC Validation ............................................ 41 + 4.5 Sending an MPLS Echo Reply ................................ 42 + 4.6 Receiving an MPLS Echo Reply .............................. 43 + 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 44 + 4.8 Non-compliant Routers ..................................... 44 + 5 References ................................................ 44 + 6 Security Considerations ................................... 46 + 7 IANA Considerations ....................................... 47 + 7.1 Message Types, Reply Modes, Return Codes .................. 47 + 7.2 TLVs ...................................................... 48 + 8 Acknowledgments ........................................... 49 1. Introduction This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSPs. There are two parts to this document: information carried in an MPLS "echo request" and "echo reply"; and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. @@ -231,22 +230,23 @@ The IPv4 link local addresses are more attractive in that scope over which they can be forwarded is limited. However, if one were to use an address from this range, it would still be possible for the first recipient of a diagnostic packet that "escaped" from a broken LSP to have that addressed assigned to the interface on which it arrived and thus could mistakenly receive such a packet. Further, the IPv4 link local address range has only recently been allocated. Many deployed routers would forward a packet with an address from that range toward the default route. - The 127/8 range for IPv4 and that same range embedded in an IPv6 - addresses for IPv6 was chosen for a number of reasons. + The 127/8 range for IPv4 and that same range embedded in as + IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of rea- + sons. RFC1122 allocates the 127/8 as "Internal host loopback address" and states that "Addresses of this form MUST NOT appear outside a host." Thus the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is mis-directed to a host, it will be silently discarded. RFC1812 [RFC1812] states that: A router SHOULD NOT forward, except over a loopback interface, any @@ -659,20 +659,26 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + The Route Distinguisher (RD) is an 8-octect identifier; it does not + contain any inherent information. The purpose of the RD is solely to + allow one to create distinct routes to a common IPv4 address prefix. + The encoding of the RD is not important here. When matching this + field to the local FEC information, it is treated as an opaque value. + 3.2.6. VPN IPv6 Prefix VPN-IPv6 NLRI (Network Layer Routing Information) is defined in [MPLS-L3-VPN]. This document uses the term VPN IPv6 prefix for a VPN-IPv6 NLRI which has been advertised with an MPLS label in BGP. See [BGP-LABEL]. When a VPN IPv6 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 @@ -685,59 +691,79 @@ | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + The Route Distiguisher is identical to the VPN IPv4 Prefix RD, except + that it functions here to allow the creation of distict routes to + IPv6 prefixes. See section 3.2.5. When matching this field to local + FEC information, it is treated as an opaque value. + 3.2.7. L2 VPN Endpoint - VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses - the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. + VPLS stands for Virtual Private Lan Service. The terms VPLS BGP NLRI + and VE ID (VPLS Edge Identifier) are defined in [VPLS-BGP]. This + document uses the simpler term L2 VPN endpoint when referring to a + VPLS BGP NLRI. The Route Distiguisher is 8-octet identifier used to + distinguish information about various L2 VPNs advertised by a node. + The VE ID is 2-octet identifier used to identify a particular node + which serves as the service attachment point within a VPLS. The + structure of these two identifiers is uninportant here; when matching + these fields to local FEC information, they are treated as opaque + values. The encapsulation type is identical to the PW Type in sec- + tion 3.2.8 below. + When an L2 VPN endpoint is encoded in a label stack, the following format is used. The value field consists of a Route Distinguisher (8 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 octets), and an encapsulation type (2 octets), formatted as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's VE ID | Receiver's VE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.8. FEC 128 Pseudowire (Deprecated) - FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC - 128 is encoded in a label stack, the following format is used. The - value field consists of the remote PE address (the destination - address of the targeted LDP session), a VC ID and an encapsulation - type, as follows: + FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID + (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero + 32-bit connection ID. The PW Type is a 15 bit number indicating the + encapsultion type. It is carried right justified in the field below + termed encapsulation type with the high-order bit set to zero. Both + of these fields are treated in this protocol as opaque values. + + When a FEC 128 is encoded in a label stack, the following format is + used. The value field consists of the remote PE address (the desti- + nation address of the targeted LDP session), the PW ID and the encap- + sulation type as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | VC ID | + | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Encapsulation Type | Must Be Zero | + | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - This FEC is deprecated and is retained only for backward compatibil- ity. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see next section), unless explicitly configured to use the old TLV. An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the Sender's PE Address. 3.2.9. FEC 128 Pseudowire (Current) @@ -734,47 +760,66 @@ This FEC is deprecated and is retained only for backward compatibil- ity. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see next section), unless explicitly configured to use the old TLV. An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the Sender's PE Address. 3.2.9. FEC 128 Pseudowire (Current) - FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC - 128 is encoded in a label stack, the following format is used. The - value field consists of the sender's PE address (the source address - of the targeted LDP session), the remote PE address (the destination - address of the targeted LDP session), a VC ID and an encapsulation - type, as follows: + FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID + (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero + 32-bit connection ID. The PW Type is a 15 bit number indicating the + encapsultion type. It is carried right justified in the field below + termed encapsulation type with the high-order bit set to zero. + + Both of these fields are treated in this protocol as opaque values. + When matching these field to the local FEC information, the match + MUST be exact. + + When a FEC 128 is encoded in a label stack, the following format is + used. The value field consists of the sender's PE address (the + source address of the targeted LDP session), the remote PE address + (the destination address of the targeted LDP session), the PW ID and + the encapsulation type as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | VC ID | + | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Encapsulation Type | Must Be Zero | + | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.10. FEC 129 Pseudowire - FEC 129 and the terms AII, AGI, SAII, and TAII are defined in [PW- - CONTROL]. When a FEC 129 is encoded in a label stack, the following - format is used. The Length of this TLV is 16 + AGI length + SAII - length + TAII length. Padding is used to make the total length a - multiple of 4; the length of the padding is not included in the - Length field. + FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier + (AGI), Attachment Group Identifier Type (AGI Type), Attachment Indi- + vidual Identifier Type (AII Type), Source Attachment Individual Iden- + tifier (SAII), Target Attachment Individual Identifier (TAII) are + defined in [PW-CONTROL]. The PW Type is a 15 bit number indicating + the encapsultion type. It is carried right justified in the field + below PW type with the high-order bit set to zero. All the other + fields are treated as opaque values and copied directly from the FEC + 129 format. All of these values together uniquely define the FEC + with in the scope of the LDP session identified by the source and + remote PE addresses. + + When a FEC 129 is encoded in a label stack, the following format is + used. The Length of this TLV is 16 + AGI length + SAII length + TAII + length. Padding is used to make the total length a multiple of 4; + the length of the padding is not included in the Length field. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | AGI Type | AGI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1018,21 +1063,21 @@ Multipath Type The following Multipath Types are defined: Key Type Multipath Information --- ---------------- --------------------- 0 no multipath Empty (Multipath Length = 0) 2 IP address IP addresses 4 IP address range low/high address pairs - 8 Bit-masked IPv4 IP address prefix and bit mask + 8 Bit-masked IP IP address prefix and bit mask address set 9 Bit-masked label set Label prefix and bit mask Type 0 indicates that all packets will be forwarded out this one interface. Types 2, 4, 8 and 9 specify that the supplied Multipath Information will serve to exercise this path. Depth Limit @@ -1073,43 +1118,63 @@ 1 Static 2 BGP 3 LDP 4 RSVP-TE 3.3.1. Multipath Information Encoding The multipath information encodes labels or addresses which will exercise this path. The multipath information depends on the multi- path type. The contents of the field are shown in the table above. - IP addresses are drawn from the range 127/8. Labels are treated as + IPv4 addresses are drawn from the range 127/8; IPv6 addresses are + drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated as numbers, i.e. they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence. - Type 8 allows a denser encoding of IP address. The IPv4 prefix is - formatted as a base IPv4 address with the non-prefix low order bits - set to zero. The maximum prefix length is 27. Following the prefix - is a mask of length 2^(32-prefix length) bits. Each bit set to one - represents a valid address. The address is the base IPv4 address - plus the position of the bit in the mask where the bits are numbered - left to right beginning with zero. For example the IP addresses - 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be - encoded as follows: + Type 8 allows a denser encoding of IP address. The IP prefix is for- + matted as a base IP address with the non-prefix low order bits set to + zero. The maximum prefix length is 27. Following the prefix is a + mask of length 2^(32-prefix length) bits for IPv4 and 2^(128-prefix + length) bits for IPv6. Each bit set to one represents a valid + address. The address is the base IPv4 address plus the position of + the bit in the mask where the bits are numbered left to right begin- + ning with zero. For example the IPv4 addresses 127.2.1.0, + 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded as + follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Those same addresses embedded in IPv6 would be encoded as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Type 9 allows a denser encoding of Labels. The label prefix is for- matted as a base label value with the non-prefix low order bits set to zero. The maximum prefix (including leading zeros due to encod- ing) length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits. Each bit set to one represents a valid Label. The label is the base label plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. Label values of all the odd numbers between 1152 and 1279 would be encoded as follows: @@ -1375,24 +1440,26 @@ penultimate hop popping. Since the receiving router has no means to differentiate whether the IP packet was sent unlabeled or implicitly labeled, the addition of labels shimmed above the MPLS echo request (using the Nil FEC) will prevent a router from forwarding such a packet out unlabeled interfaces. 4.3. Sending an MPLS Echo Request An MPLS echo request is a UDP packet. The IP header is set as fol- lows: the source IP address is a routable address of the sender; the - destination IP address is a (randomly chosen) address from 127/8; the - IP TTL is set to 1. The source UDP port is chosen by the sender; the - destination UDP port is set to 3503 (assigned by IANA for MPLS echo - requests). The Router Alert option MUST be set in the IP header. + destination IP address is a (randomly chosen) IPv4 address from the + range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104. + the IP TTL is set to 1. The source UDP port is chosen by the sender; + the destination UDP port is set to 3503 (assigned by IANA for MPLS + echo requests). The Router Alert option MUST be set in the IP + header. An MPlS Echo Request is sent with a label stack corresponding to the FEC stack being tested. Note that further labels could be applied if, for example, the normal route to the topmost FEC in the stack is via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the stack correspond to Implicit Null Labels the MPLS echo request is considered unlabeled even if further labels will be applied in send- ing the packet. If the echo request is labeled, one MAY (depending on what is being @@ -1554,21 +1621,21 @@ If the label operation is "Swap or Pop and Switch based on Popped Label" { Set Best-return-code to 8 ("Label switched at stack-depth") and Best-rtn-subcode to Label-stack-depth to report transit switching. If a Downstream Mapping TLV is present in the received Echo Request { - If the IP address in the TLV is 127.0.0.1 or 0::1: { + If the IP address in the TLV is 127.0.0.1 or 0::1 { Set Best-return-code to 6 ("Upstream Interface Index Unknown"). An Interface and Label Stack TLV SHOULD be included in the reply and filled with Interface-I and Stack-R. } Else { Verify that the IP address, interface address and label stack in the Downstream Mapping TLV match Interface-I @@ -1643,21 +1713,21 @@ Go to step 7 (Send Reply Packet). } 5. Egress Processing: /* These steps are performed by the LSR that identified itself as the tail-end LSR for an LSP. */ If received Echo Request contains no Downstream Mapping TLV, or - the Downstream IP Address is set to 127.0.0.1 or 0::1: + the Downstream IP Address is set to 127.0.0.1 or 0::1 Go t0 step 6 (Egress FEC Validation). Verify that the IP address, interface address and label stack in the Downstream mapping TLV match Interface-I and Stack-R. If not, set Best-return-code to 5, "Downstream Mapping Mis-match". A Received Interface and Label Stack TLV SHOULD be created for the Echo Response packet. Go to step 7 (Send Reply Packet). 6. Egress FEC Validation: @@ -1882,21 +1953,21 @@ work-in-progress. [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [VCCV] Nadeau, T. & Aggarwal, R., "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV), draft-ietf-pwe3-vccv-07.txt, August 2005, work-in-progress. - [VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN + [VPLS-BGP] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service", draft-ietf-l2vpn-vpls-bgp-05, work-in-progress. 6. Security Considerations Overall, the security needs for LSP Ping are are similar to those of ICMP Ping. There are at least three approaches to attacking LSRs using the mech- anisms defined here. One is a Denial of Service attack, by sending @@ -1935,21 +2006,23 @@ the MPLS data plane may be considered confidential by some. Imple- mentations SHOULD however provide a means of filtering the addresses to which Echo Reply messages may be sent. Although this document makes special use of 127/8 address, these are used only in conjunction with the UDP port 3503. Further these pack- ets are only processed by routers. All other hosts MUST treat all packets with a destination address in the range 127/8 in accordance to RFC1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 - MUST be treated in accordance to RFC1812. + MUST be treated in accordance to RFC1812. In particular, the default + behavior is to treat packets destined to a 127/8 address as "mar- + tians". 7. IANA Considerations The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies. The following sections detail the new name spaces to be managed by IANA. For each of these name spaces, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as @@ -2077,21 +2150,21 @@ Email: swallow@cisco.com Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Expiration Date - June 2006 + July 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.