draft-smack-mpls-rfc4379bis-04.txt   draft-smack-mpls-rfc4379bis-05.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Network Working Group C. Pignataro Network Working Group C. Pignataro
Internet-Draft N. Kumar Internet-Draft N. Kumar
Obsoletes: 4379 (if approved) Cisco Obsoletes: 4379 (if approved) Cisco
Intended status: Standards Track S. Aldrin Intended status: Standards Track S. Aldrin
Expires: April 5, 2016 Google Expires: April 5, 2016 Google
M. Chen M. Chen
Huawei Huawei
October 3, 2015 October 3, 2015
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
draft-smack-mpls-rfc4379bis-04 draft-smack-mpls-rfc4379bis-05
Abstract Abstract
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this (MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation, and reply" for the purposes of fault detection and isolation, and
mechanisms for reliably sending the echo reply. mechanisms for reliably sending the echo reply.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
This section should be empty, and removed, prior to publication. This section should be empty, and removed, prior to publication.
ToDos: ToDos:
1. Evaluation of which of the RFCs that updated RFC 4379 need to be 1. Evaluation of which of the RFCs that updated RFC 4379 need to be
incorporated into this 4379bis document. Specifically, these incorporated into this 4379bis document. Specifically, these
RFCs updated RFC 4379: 6424, 6425, 6426, 6829, 7506, and 7537. RFCs updated RFC 4379: 6424, 6425, 6426, 6829, 7506, and 7537.
RFCs that updated RFC 4379 and are incorporated into this RFCs that updated RFC 4379 and are incorporated into this
4379bis, will be Obsoleted by 4379bis. 4379bis, will be Obsoleted by 4379bis.
2. Review IANA Allocations 2. Review IANA Allocations
3. Fix pending figure mis-alignments
2. Motivation 2. Motivation
When an LSP fails to deliver user traffic, the failure cannot always When an LSP fails to deliver user traffic, the failure cannot always
be detected by the MPLS control plane. There is a need to provide a be detected by the MPLS control plane. There is a need to provide a
tool that would enable users to detect such traffic "black holes" or tool that would enable users to detect such traffic "black holes" or
misrouting within a reasonable period of time, and a mechanism to misrouting within a reasonable period of time, and a mechanism to
isolate faults. isolate faults.
In this document, we describe a mechanism that accomplishes these In this document, we describe a mechanism that accomplishes these
skipping to change at page 6, line 32 skipping to change at page 6, line 31
network faults. In particular, LSP ping needs to diagnose situations network faults. In particular, LSP ping needs to diagnose situations
where the control and data planes are out of sync. It performs this where the control and data planes are out of sync. It performs this
by routing an MPLS echo request packet based solely on its label by routing an MPLS echo request packet based solely on its label
stack. That is, the IP destination address is never used in a stack. That is, the IP destination address is never used in a
forwarding decision. In fact, the sender of an MPLS echo request forwarding decision. In fact, the sender of an MPLS echo request
packet may not know, a priori, the address of the router at the end packet may not know, a priori, the address of the router at the end
of the LSP. of the LSP.
Providers of MPLS-based services also need the ability to trace all Providers of MPLS-based services also need the ability to trace all
of the possible paths that an LSP may take. Since most MPLS services of the possible paths that an LSP may take. Since most MPLS services
are based on IP unicast forwarding, these paths are subject to are based on IP unicast forwarding, these paths are subject to equal-
equal-cost multi-path (ECMP) load sharing. cost multi-path (ECMP) load sharing.
This leads to the following requirements: This leads to the following requirements:
1. Although the LSP in question may be broken in unknown ways, the 1. Although the LSP in question may be broken in unknown ways, the
likelihood of a diagnostic packet being delivered to a user of an likelihood of a diagnostic packet being delivered to a user of an
MPLS service MUST be held to an absolute minimum. MPLS service MUST be held to an absolute minimum.
2. If an LSP is broken in such a way that it prematurely terminates, 2. If an LSP is broken in such a way that it prematurely terminates,
the diagnostic packet MUST NOT be IP forwarded. the diagnostic packet MUST NOT be IP forwarded.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... | | TLVs ... |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Version Number is currently 1. (Note: the version number is to The Version Number is currently 1. (Note: the version number is to
be incremented whenever a change is made that affects the ability of be incremented whenever a change is made that affects the ability of
an implementation to correctly parse or process an MPLS echo an implementation to correctly parse or process an MPLS echo request/
request/reply. These changes include any syntactic or semantic reply. These changes include any syntactic or semantic changes made
changes made to any of the fixed fields, or to any Type-Length-Value to any of the fixed fields, or to any Type-Length-Value (TLV) or sub-
(TLV) or sub-TLV assignment or format that is defined at a certain TLV assignment or format that is defined at a certain version number.
version number. The version number may not need to be changed if an The version number may not need to be changed if an optional TLV or
optional TLV or sub-TLV is added.) sub-TLV is added.)
The Global Flags field is a bit vector with the following format: The Global Flags field is a bit vector with the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V| | MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the V bit; the rest MUST be set to zero One flag is defined for now, the V bit; the rest MUST be set to zero
when sending and ignored on receipt. when sending and ignored on receipt.
The V (Validate FEC Stack) flag is set to 1 if the sender wants the The V (Validate FEC Stack) flag is set to 1 if the sender wants the
receiver to perform FEC Stack validation; if V is 0, the choice is receiver to perform FEC Stack validation; if V is 0, the choice is
left to the receiver. left to the receiver.
The Message Type is one of the following: The Message Type is one of the following:
Value Meaning Value Meaning
----- ------- ----- -------
1 MPLS echo request 1 MPLS echo request
2 MPLS echo reply 2 MPLS echo reply
The Reply Mode can take one of the following values: The Reply Mode can take one of the following values:
Value Meaning Value Meaning
----- ------- ----- -------
1 Do not reply 1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet 2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel 4 Reply via application level control channel
An MPLS echo request with 1 (Do not reply) in the Reply Mode field An MPLS echo request with 1 (Do not reply) in the Reply Mode field
may be used for one-way connectivity tests; the receiving router may may be used for one-way connectivity tests; the receiving router may
log gaps in the Sequence Numbers and/or maintain delay/jitter log gaps in the Sequence Numbers and/or maintain delay/jitter
statistics. An MPLS echo request would normally have 2 (Reply via an statistics. An MPLS echo request would normally have 2 (Reply via an
IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP
return path is deemed unreliable, one may use 3 (Reply via an IPv4/ return path is deemed unreliable, one may use 3 (Reply via an IPv4/
IPv6 UDP packet with Router Alert). Note that this requires that all IPv6 UDP packet with Router Alert). Note that this requires that all
intermediate routers understand and know how to forward MPLS echo intermediate routers understand and know how to forward MPLS echo
replies. The echo reply uses the same IP version number as the replies. The echo reply uses the same IP version number as the
received echo request, i.e., an IPv4 encapsulated echo reply is sent received echo request, i.e., an IPv4 encapsulated echo reply is sent
in response to an IPv4 encapsulated echo request. in response to an IPv4 encapsulated echo request.
Some applications support an IP control channel. One such example is Some applications support an IP control channel. One such example is
the associated control channel defined in Virtual Circuit the associated control channel defined in Virtual Circuit
Connectivity Verification (VCCV) [RFC5085]. Any application that Connectivity Verification (VCCV) [RFC5085]. Any application that
skipping to change at page 11, line 29 skipping to change at page 11, line 29
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of the Types and Values of the top-level TLVs for LSP A description of the Types and Values of the top-level TLVs for LSP
ping are given below: ping are given below:
Type # Value Field Type # Value Field
------ ----------- ------ -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping
3 Pad 3 Pad
4 Not Assigned 4 Not Assigned
5 Vendor Enterprise Number 5 Vendor Enterprise Number
6 Not Assigned 6 Not Assigned
7 Interface and Label Stack 7 Interface and Label Stack
8 Not Assigned 8 Not Assigned
9 Errored TLVs 9 Errored TLVs
skipping to change at page 12, line 13 skipping to change at page 12, line 13
implementation does not understand or support them. implementation does not understand or support them.
3.1. Return Codes 3.1. Return Codes
The Return Code is set to zero by the sender. The receiver can set The Return Code is set to zero by the sender. The receiver can set
it to one of the values listed below. The notation <RSC> refers to it to one of the values listed below. The notation <RSC> refers to
the Return Subcode. This field is filled in with the stack-depth for the Return Subcode. This field is filled in with the stack-depth for
those codes that specify that. For all other codes, the Return those codes that specify that. For all other codes, the Return
Subcode MUST be set to zero. Subcode MUST be set to zero.
Value Meaning Value Meaning
----- ------- ----- -------
0 No return code 0 No return code
1 Malformed echo request received 1 Malformed echo request received
2 One or more of the TLVs was not understood 2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at stack- 3 Replying router is an egress for the FEC at stack-
depth <RSC> depth <RSC>
4 Replying router has no mapping for the FEC at stack- 4 Replying router has no mapping for the FEC at stack-
depth <RSC> depth <RSC>
5 Downstream Mapping Mismatch (See Note 1) 5 Downstream Mapping Mismatch (See Note 1)
6 Upstream Interface Index Unknown (See Note 1) 6 Upstream Interface Index Unknown (See Note 1)
7 Reserved 7 Reserved
8 Label switched at stack-depth <RSC> 8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth 9 Label switched but no MPLS forwarding at stack-depth
<RSC> <RSC>
10 Mapping for this FEC is not the given label at stack- 10 Mapping for this FEC is not the given label at stack-
depth <RSC> depth <RSC>
11 No label entry at stack-depth <RSC> 11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC stack- 12 Protocol not associated with interface at FEC stack-
depth <RSC> depth <RSC>
13 Premature termination of ping due to label stack 13 Premature termination of ping due to label stack
shrinking to a single label shrinking to a single label
Note 1 Note 1
The Return Subcode contains the point in the label stack where The Return Subcode contains the point in the label stack where
processing was terminated. If the RSC is 0, no labels were processing was terminated. If the RSC is 0, no labels were
processed. Otherwise the packet would have been label switched at processed. Otherwise the packet would have been label switched at
depth RSC. depth RSC.
3.2. Target FEC Stack 3.2. Target FEC Stack
A Target FEC Stack is a list of sub-TLVs. The number of elements is A Target FEC Stack is a list of sub-TLVs. The number of elements is
determined by looking at the sub-TLV length fields. determined by looking at the sub-TLV length fields.
Sub-Type Length Value Field Sub-Type Length Value Field
-------- ------ ----------- -------- ------ -----------
1 5 LDP IPv4 prefix 1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix 2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP 3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP 4 56 RSVP IPv6 LSP
5 Not Assigned 5 Not Assigned
6 13 VPN IPv4 prefix 6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix 7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint 8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated) 9 10 "FEC 128" Pseudowire (deprecated)
10 14 "FEC 128" Pseudowire 10 14 "FEC 128" Pseudowire
skipping to change at page 23, line 42 skipping to change at page 23, line 42
label stack) that fits on the interface to the Downstream LSR. label stack) that fits on the interface to the Downstream LSR.
Address Type Address Type
The Address Type indicates if the interface is numbered or The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the Downstream IP unnumbered. It also determines the length of the Downstream IP
Address and Downstream Interface fields. The resulting total for Address and Downstream Interface fields. The resulting total for
the initial part of the TLV is listed in the table below as "K the initial part of the TLV is listed in the table below as "K
Octets". The Address Type is set to one of the following values: Octets". The Address Type is set to one of the following values:
Type # Address Type K Octets Type # Address Type K Octets
------ ------------ -------- ------ ------------ --------
1 IPv4 Numbered 16 1 IPv4 Numbered 16
2 IPv4 Unnumbered 16 2 IPv4 Unnumbered 16
3 IPv6 Numbered 40 3 IPv6 Numbered 40
4 IPv6 Unnumbered 28 4 IPv6 Unnumbered 28
DS Flags DS Flags
The DS Flags field is a bit vector with the following format: The DS Flags field is a bit vector with the following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N| | Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Two flags are defined currently, I and N. The remaining flags MUST Two flags are defined currently, I and N. The remaining flags MUST
be set to zero when sending and ignored on receipt. be set to zero when sending and ignored on receipt.
Flag Name and Meaning Flag Name and Meaning
---- ---------------- ---- ----------------
I Interface and Label Stack Object Request I Interface and Label Stack Object Request
When this flag is set, it indicates that the replying When this flag is set, it indicates that the replying
router SHOULD include an Interface and Label Stack router SHOULD include an Interface and Label Stack
Object in the echo reply message. Object in the echo reply message.
N Treat as a Non-IP Packet N Treat as a Non-IP Packet
Echo request messages will be used to diagnose non-IP Echo request messages will be used to diagnose non-IP
flows. However, these messages are carried in IP flows. However, these messages are carried in IP
packets. For a router that alters its ECMP algorithm packets. For a router that alters its ECMP algorithm
based on the FEC or deep packet examination, this flag based on the FEC or deep packet examination, this flag
requests that the router treat this as it would if the requests that the router treat this as it would if the
determination of an IP payload had failed. determination of an IP payload had failed.
Downstream IP Address and Downstream Interface Address Downstream IP Address and Downstream Interface Address
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets. addresses are encoded in 16 octets.
skipping to change at page 25, line 23 skipping to change at page 25, line 23
set to FF02::2. In both cases, the interface index MUST be set to set to FF02::2. In both cases, the interface index MUST be set to
0. If an LSR receives an Echo Request packet with the all-routers 0. If an LSR receives an Echo Request packet with the all-routers
multicast address, then this indicates that it MUST bypass both multicast address, then this indicates that it MUST bypass both
interface and label stack validation, but return Downstream interface and label stack validation, but return Downstream
Mapping TLVs using the information provided. Mapping TLVs using the information provided.
Multipath Type Multipath Type
The following Multipath Types are defined: The following Multipath Types are defined:
Key Type Multipath Information Key Type Multipath Information
--- ---------------- --------------------- --- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0) 0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses 2 IP address IP addresses
4 IP address range low/high address pairs 4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask 8 Bit-masked IP IP address prefix and bit mask
address set address set
9 Bit-masked label set Label prefix and bit mask 9 Bit-masked label set Label prefix and bit mask
Type 0 indicates that all packets will be forwarded out this one Type 0 indicates that all packets will be forwarded out this one
interface. interface.
Types 2, 4, 8, and 9 specify that the supplied Multipath Information Types 2, 4, 8, and 9 specify that the supplied Multipath
will serve to exercise this path. Information will serve to exercise this path.
Depth Limit Depth Limit
The Depth Limit is applicable only to a label stack and is the The Depth Limit is applicable only to a label stack and is the
maximum number of labels considered in the hash; this SHOULD be maximum number of labels considered in the hash; this SHOULD be
set to zero if unspecified or unlimited. set to zero if unspecified or unlimited.
Multipath Length Multipath Length
The length in octets of the Multipath Information. The length in octets of the Multipath Information.
skipping to change at page 26, line 21 skipping to change at page 26, line 21
A Downstream Label is 24 bits, in the same format as an MPLS label A Downstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the minus the TTL field, i.e., the MSBit of the label is bit 0, the
LSBit is bit 19, the Traffic Class (TC) bits are bits 20-22, and LSBit is bit 19, the Traffic Class (TC) bits are bits 20-22, and
bit 23 is the S bit. The replying router SHOULD fill in the TC bit 23 is the S bit. The replying router SHOULD fill in the TC
and S bits; the LSR receiving the echo reply MAY choose to ignore and S bits; the LSR receiving the echo reply MAY choose to ignore
these bits. Protocol these bits. Protocol
The Protocol is taken from the following table: The Protocol is taken from the following table:
Protocol # Signaling Protocol Protocol # Signaling Protocol
---------- ------------------ ---------- ------------------
0 Unknown 0 Unknown
1 Static 1 Static
2 BGP 2 BGP
3 LDP 3 LDP
4 RSVP-TE 4 RSVP-TE
3.3.1. Multipath Information Encoding 3.3.1. Multipath Information Encoding
The Multipath Information encodes labels or addresses that will The Multipath Information encodes labels or addresses that will
exercise this path. The Multipath Information depends on the exercise this path. The Multipath Information depends on the
Multipath Type. The contents of the field are shown in the table Multipath Type. The contents of the field are shown in the table
above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses
are drawn from the range 0:0:0:0:0:FFFF:7F00/104. Labels are treated are drawn from the range 0:0:0:0:0:FFFF:7F00/104. Labels are treated
as numbers, i.e., they are right justified in the field. For Type 4, 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 ranges indicated by Address pairs MUST NOT overlap and MUST be in
skipping to change at page 29, line 15 skipping to change at page 29, line 15
alternatives. alternatives.
3.4. Pad TLV 3.4. Pad TLV
The value part of the Pad TLV contains a variable number (>= 1) of The value part of the Pad TLV contains a variable number (>= 1) of
octets. The first octet takes values from the following table; all octets. The first octet takes values from the following table; all
the other octets (if any) are ignored. The receiver SHOULD verify the other octets (if any) are ignored. The receiver SHOULD verify
that the TLV is received in its entirety, but otherwise ignores the that the TLV is received in its entirety, but otherwise ignores the
contents of this TLV, apart from the first octet. contents of this TLV, apart from the first octet.
Value Meaning Value Meaning
----- ------- ----- -------
1 Drop Pad TLV from reply 1 Drop Pad TLV from reply
2 Copy Pad TLV to reply 2 Copy Pad TLV to reply
3-255 Reserved for future use 3-255 Reserved for future use
3.5. Vendor Enterprise Number 3.5. Vendor Enterprise Number
SMI Private Enterprise Numbers are maintained by IANA. The Length is SMI Private Enterprise Numbers are maintained by IANA. The Length is
always 4; the value is the SMI Private Enterprise code, in network always 4; the value is the SMI Private Enterprise code, in network
octet order, of the vendor with a Vendor Private extension to any of octet order, of the vendor with a Vendor Private extension to any of
the fields in the fixed part of the message, in which case this TLV the fields in the fixed part of the message, in which case this TLV
skipping to change at page 30, line 30 skipping to change at page 30, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
The Address Type indicates if the interface is numbered or The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the IP Address and unnumbered. It also determines the length of the IP Address and
Interface fields. The resulting total for the initial part of the Interface fields. The resulting total for the initial part of the
TLV is listed in the table below as "K Octets". The Address Type TLV is listed in the table below as "K Octets". The Address Type
is set to one of the following values: is set to one of the following values:
Type # Address Type K Octets Type # Address Type K Octets
------ ------------ -------- ------ ------------ --------
1 IPv4 Numbered 12 1 IPv4 Numbered 12
2 IPv4 Unnumbered 12 2 IPv4 Unnumbered 12
3 IPv6 Numbered 36 3 IPv6 Numbered 36
4 IPv6 Unnumbered 24 4 IPv6 Unnumbered 24
IP Address and Interface IP Address and Interface
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets. addresses are encoded in 16 octets.
If the interface upon which the echo request message was received If the interface upon which the echo request message was received
is numbered, then the Address Type MUST be set to IPv4 or IPv6, is numbered, then the Address Type MUST be set to IPv4 or IPv6,
the IP Address MUST be set to either the LSR's Router ID or the the IP Address MUST be set to either the LSR's Router ID or the
interface address, and the Interface MUST be set to the interface interface address, and the Interface MUST be set to the interface
skipping to change at page 43, line 24 skipping to change at page 43, line 24
Overall, the security needs for LSP ping are similar to those of ICMP Overall, the security needs for LSP ping are similar to those of ICMP
ping. ping.
There are at least three approaches to attacking LSRs using the There are at least three approaches to attacking LSRs using the
mechanisms defined here. One is a Denial-of-Service attack, by mechanisms defined here. One is a Denial-of-Service attack, by
sending MPLS echo requests/replies to LSRs and thereby increasing sending MPLS echo requests/replies to LSRs and thereby increasing
their workload. The second is obfuscating the state of the MPLS data their workload. The second is obfuscating the state of the MPLS data
plane liveness by spoofing, hijacking, replaying, or otherwise plane liveness by spoofing, hijacking, replaying, or otherwise
tampering with MPLS echo requests and replies. The third is an tampering with MPLS echo requests and replies. The third is an
unauthorized source using an LSP ping to obtain information about the unauthorized source using an LSP ping to obtain information about the
network. To avoid potential Denial-of-Service attacks, it is network.
RECOMMENDED that implementations regulate the LSP ping traffic going
to the control plane. A rate limiter SHOULD be applied to the well- To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
known UDP port defined below. implementations regulate the LSP ping traffic going to the control
plane. A rate limiter SHOULD be applied to the well-known UDP port
defined below.
Unsophisticated replay and spoofing attacks involving faking or Unsophisticated replay and spoofing attacks involving faking or
replaying MPLS echo reply messages are unlikely to be effective. replaying MPLS echo reply messages are unlikely to be effective.
These replies would have to match the Sender's Handle and Sequence These replies would have to match the Sender's Handle and Sequence
Number of an outstanding MPLS echo request message. A non-matching Number of an outstanding MPLS echo request message. A non-matching
replay would be discarded as the sequence has moved on, thus a spoof replay would be discarded as the sequence has moved on, thus a spoof
has only a small window of opportunity. However, to provide a has only a small window of opportunity. However, to provide a
stronger defense, an implementation MAY also validate the TimeStamp stronger defense, an implementation MAY also validate the TimeStamp
Sent by requiring an exact match on this field. Sent by requiring an exact match on this field.
skipping to change at page 45, line 10 skipping to change at page 45, line 10
range 0-255. Assignments in the range 0-191 are via Standards range 0-255. Assignments in the range 0-191 are via Standards
Action; assignments in the range 192-251 are made via "Specification Action; assignments in the range 192-251 are made via "Specification
Required"; values in the range 252-255 are for Vendor Private Use, Required"; values in the range 252-255 are for Vendor Private Use,
and MUST NOT be allocated. and MUST NOT be allocated.
If any of these fields fall in the Vendor Private range, a top-level If any of these fields fall in the Vendor Private range, a top-level
Vendor Enterprise Number TLV MUST be present in the message. Vendor Enterprise Number TLV MUST be present in the message.
Message Types defined in this document are the following: Message Types defined in this document are the following:
Value Meaning Value Meaning
----- ------- ----- -------
1 MPLS echo request 1 MPLS echo request
2 MPLS echo reply 2 MPLS echo reply
Reply Modes defined in this document are the following: Reply Modes defined in this document are the following:
Value Meaning Value Meaning
----- ------- ----- -------
1 Do not reply 1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet 2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel 4 Reply via application level control channel
Return Codes defined in this document are listed in section 3.1. Return Codes defined in this document are listed in section 3.1.
6.2. TLVs 6.2. TLVs
The IANA has created and will maintain a registry for the Type field The IANA has created and will maintain a registry for the Type field
skipping to change at page 45, line 43 skipping to change at page 45, line 43
The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
range 0-16383 and 32768-49161 are made via Standards Action as range 0-16383 and 32768-49161 are made via Standards Action as
defined in [RFC5226]; assignments in the range 16384-31743 and defined in [RFC5226]; assignments in the range 16384-31743 and
49162-64511 are made via "Specification Required" as defined above; 49162-64511 are made via "Specification Required" as defined above;
values in the range 31744-32767 and 64512-65535 are for Vendor values in the range 31744-32767 and 64512-65535 are for Vendor
Private Use, and MUST NOT be allocated. Private Use, and MUST NOT be allocated.
If a TLV or sub-TLV has a Type that falls in the range for Vendor If a TLV or sub-TLV has a Type that falls in the range for Vendor
Private Use, the Length MUST be at least 4, and the first four octets Private Use, the Length MUST be at least 4, and the first four octets
MUST be that vendor's SMI Private Enterprise Number, in network octet MUST be that vendor's SMI Private Enterprise Number, in network octet
order. The rest of the Value field is private to the vendor. TLVs order. The rest of the Value field is private to the vendor.
and sub-TLVs defined in this document are the following:
Type Sub-Type Value Field TLVs and sub-TLVs defined in this document are the following:
---- -------- -----------
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack 1 Target FEC Stack
1 LDP IPv4 prefix 1 LDP IPv4 prefix
2 LDP IPv6 prefix 2 LDP IPv6 prefix
3 RSVP IPv4 LSP 3 RSVP IPv4 LSP
4 RSVP IPv6 LSP 4 RSVP IPv6 LSP
5 Not Assigned 5 Not Assigned
6 VPN IPv4 prefix 6 VPN IPv4 prefix
7 VPN IPv6 prefix 7 VPN IPv6 prefix
8 L2 VPN endpoint 8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated) 9 "FEC 128" Pseudowire (Deprecated)
 End of changes. 26 change blocks. 
95 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/