draft-ietf-mpls-lsp-ping-09.txt   draft-ietf-mpls-lsp-ping-10.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks, Inc. Internet Draft Juniper Networks, Inc.
Category: Standards Track Category: Standards Track
Expiration Date: November 2005 Expiration Date: March 2006
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
May 2005 September 2005
Detecting MPLS Data Plane Failures Detecting MPLS Data Plane Failures
draft-ietf-mpls-lsp-ping-09.txt draft-ietf-mpls-lsp-ping-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with Internet-Drafts are working documents of the Internet Engineering
all provisions of Section 5 of RFC3667. Internet-Drafts are working Task Force (IETF), its areas, and its working groups. Note that
documents of the Internet Engineering Task Force (IETF), its areas, other groups may also distribute working documents as Internet-
and its working groups. Note that other groups may also distribute Drafts.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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.
Changes since last revision Changes since last revision
(This section to be removed before publication.) (This section to be removed before publication.)
o fixed the optional vs. mandatory TLV wording o Corrected Length of Nil Fec in the summary table at the beginning
o Removed the Error TLV (which never found use and was undefined) of Sec 3.2
o Removed an extraneous paragraph from the processing rules and did
some further word-smithing o Aligned the FEC 129 sub-tlv with draft-ietf-pwe3-control-
o Removed Appendix A on CR-LDP protocol-17
o Added an Address Type field to the Address and Interface Object;
combined the IPv4 & IPv6 formats into a single TLV o Removed the duplicated Interface field from the Interface and
o Modified example TLV / Sub-TLV to be more instructive on Label Stack object and removed the adjective "Downstream" from the
determining (Sub-)TLV lengths field descriptions in the text. (Sec. 3.6)
o Removed the BGP Next Hop field from the BGP Labeled IPv4 FEC
o Added the BGP Labeled IPv6 FEC o Updated the Security section
o Corrected the length calculation for the Downsteam Mapping TLV
o Added two special values for the Downstream Router ID
o Added an error code for upstream Interface Index Unknown
o Added all requested allocations to the IANA section
o Spelling and Word-smithing
Contents Contents
1 Introduction .............................................. 4 1 Introduction .............................................. 4
1.1 Conventions ............................................... 4 1.1 Conventions ............................................... 4
1.2 Structure of this document ................................ 4 1.2 Structure of this document ................................ 4
1.3 Contributors .............................................. 4 1.3 Contributors .............................................. 4
2 Motivation ................................................ 5 2 Motivation ................................................ 5
3 Packet Format ............................................. 6 3 Packet Format ............................................. 6
3.1 Return Codes .............................................. 10 3.1 Return Codes .............................................. 10
skipping to change at page 3, line 51 skipping to change at page 3, line 51
4.3 Sending an MPLS Echo Request .............................. 31 4.3 Sending an MPLS Echo Request .............................. 31
4.4 Receiving an MPLS Echo Request ............................ 32 4.4 Receiving an MPLS Echo Request ............................ 32
4.5 Sending an MPLS Echo Reply ................................ 35 4.5 Sending an MPLS Echo Reply ................................ 35
4.6 Receiving an MPLS Echo Reply .............................. 36 4.6 Receiving an MPLS Echo Reply .............................. 36
4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36
4.8 Non-compliant Routers ..................................... 37 4.8 Non-compliant Routers ..................................... 37
5 References ................................................ 37 5 References ................................................ 37
6 Security Considerations ................................... 38 6 Security Considerations ................................... 38
7 IANA Considerations ....................................... 38 7 IANA Considerations ....................................... 38
7.1 Message Types, Reply Modes, Return Codes .................. 39 7.1 Message Types, Reply Modes, Return Codes .................. 39
7.2 TLVs ...................................................... 39 7.2 TLVs ...................................................... 40
8 Acknowledgments ........................................... 40 8 Acknowledgments ........................................... 41
1. Introduction 1. Introduction
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 MPLS LSPs. There are two parts used to detect data plane failures in MPLS LSPs. There are two parts
to this document: information carried in an MPLS "echo request" and to this document: information carried in an MPLS "echo request" and
"echo reply"; and mechanisms for transporting the echo reply. The "echo reply"; and mechanisms for transporting the echo reply. The
first part aims at providing enough information to check correct first part aims at providing enough information to check correct
operation of the data plane, as well as a mechanism to verify the operation of the data plane, as well as a mechanism to verify the
data plane against the control plane, and thereby localize faults. data plane against the control plane, and thereby localize faults.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Note 1 Note 1
The Return Subcode contains the point in the label stack where pro- The Return Subcode contains the point in the label stack where pro-
cessing was terminated. If the RSC is 0, no labels were processed. cessing was terminated. If the RSC is 0, no labels were processed.
Otherwise the packet would have been label switched at depth RSC. Otherwise the packet would have been label switched at 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 the 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
11 13+ "FEC 129" Pseudowire 11 16+ "FEC 129" Pseudowire
12 5 BGP labeled IPv4 prefix 12 5 BGP labeled IPv4 prefix
13 17 BGP labeled IPv6 prefix 13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix 14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix 15 17 Generic IPv6 prefix
16 4*N Nil FEC 16 4 Nil FEC
Other FEC Types will be defined as needed. Other FEC Types will be defined as needed.
Note that this TLV defines a stack of FECs, the first FEC element Note that this TLV defines a stack of FECs, the first FEC element
corresponding to the top of the label stack, etc. corresponding to the top of the label stack, etc.
An MPLS echo request MUST have a Target FEC Stack that describes the An MPLS echo request MUST have a Target FEC Stack that describes the
FEC stack being tested. For example, if an LSR X has an LDP mapping FEC stack being tested. For example, if an LSR X has an LDP mapping
for 192.168.1.1 (say label 1001), then to verify that label 1001 does for 192.168.1.1 (say label 1001), then to verify that label 1001 does
indeed reach an egress LSR that announced this prefix via LDP, X can indeed reach an egress LSR that announced this prefix via LDP, X can
skipping to change at page 16, line 18 skipping to change at page 16, line 18
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID | | VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC will be deprecated, and is retained only for backward com- This FEC will be deprecated, and is retained only for backward com-
patibility. Implementations of LSP ping SHOULD accept and process patibility. Implementations of LSP ping SHOULD accept and process
this TLV, but SHOULD send LSP ping echo requests with the new TLV this TLV, but SHOULD send LSP ping echo requests with the new TLV
(see next section), unless explicitly asked by configuration to use (see next section), unless explicitly configured to use the old TLV.
the old TLV.
An LSR receiving this TLV SHOULD use the source IP address of the LSP An LSR receiving this TLV SHOULD use the source IP address of the LSP
echo request to infer the Sender's PE Address. echo request to infer the Sender's PE Address.
3.2.9. FEC 128 Pseudowire (Current) 3.2.9. FEC 128 Pseudowire (Current)
The value field consists of the sender's PE address (the source The value field consists of the sender's PE address (the source
address of the targeted LDP session), the remote PE address (the des- address of the targeted LDP session), the remote PE address (the des-
tination address of the targeted LDP session), a VC ID and an encap- tination address of the targeted LDP session), a VC ID and an encap-
sulation type, as follows: sulation type, as follows:
skipping to change at page 16, line 45 skipping to change at page 16, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID | | VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire 3.2.10. FEC 129 Pseudowire
The Length of this TLV is 13 + AGI length + SAII length + TAII 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; 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. the length of the padding is not included in the Length field.
0 1 2 3 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 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 | | Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Length | SAII Length | | PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII Length | AGI Value ... SAII Value ... TAII Value ... | ~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... . | AII Type | SAII Length | Value |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 0-3 octets of zero padding | ~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.)| 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix 3.2.11. BGP Labeled IPv4 Prefix
The value field consists the IPv4 prefix (with trailing 0 bits to The value field consists the IPv4 prefix (with trailing 0 bits to
make 32 bits in all), and the prefix length, as follows: make 32 bits in all), and the prefix length, as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 30 skipping to change at page 27, line 30
the label stack which was on the packet when it was received. Only the label stack which was on the packet when it was received. Only
one such object may appear. The purpose of the object is to allow one such object may appear. The purpose of the object is to allow
the upstream router to obtain the exact interface and label stack the upstream router to obtain the exact interface and label stack
information as it appears at the replying LSR. information as it appears at the replying LSR.
The Length is K + 4*N octets, N is the number of labels in the Label The Length is K + 4*N octets, N is the number of labels in the Label
Stack. Values for K are found in the description of Address Type Stack. Values for K are found in the description of Address Type
below. The Value field of a Downstream Mapping has the following below. The Value field of a Downstream Mapping has the following
format: format:
The value field of a Interface and Label Stack TLV has the following
format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must be Zero | | Address Type | Must be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) | | IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) | | Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. Label Stack . . Label Stack .
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
The Address Type indicates if the interface is numbered or unnum- The Address Type indicates if the interface is numbered or unnum-
bered. It also determines the length of the Downstream IP Address bered. It also determines the length of the IP Address and Interface
and Downstream Interface fields. The resulting total for the initial fields. The resulting total for the initial part of the TLV is
part of the TLV is listed in the table below as "K Octets". The listed in the table below as "K Octets". The Address Type is set to
Address Type is set to one of the following values: 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
skipping to change at page 38, line 7 skipping to change at page 38, line 7
Informative References Informative References
[ICMP] Postel, J., "Internet Control Message Protocol", [ICMP] Postel, J., "Internet Control Message Protocol",
RFC 792. RFC 792.
[LDP] Andersson, L., et al, "LDP Specification", RFC 3036, [LDP] Andersson, L., et al, "LDP Specification", RFC 3036,
January 2001. January 2001.
6. Security Considerations 6. Security Considerations
Overall, the security needs for LSP Ping are are similar to those of
ICMP Ping.
There are at least two approaches to attacking LSRs using the mecha- There are at least two approaches to attacking LSRs using the mecha-
nisms defined here. One is a Denial of Service attack, by sending nisms defined here. One is a Denial of Service attack, by sending
MPLS echo requests/replies to LSRs and thereby increasing their work- MPLS echo requests/replies to LSRs and thereby increasing their work-
load. The other is obfuscating the state of the MPLS data plane load. The other is obfuscating the state of the MPLS data plane
liveness by spoofing, hijacking, replaying or otherwise tampering liveness by spoofing, hijacking, replaying or otherwise tampering
with MPLS echo requests and replies. with MPLS echo requests and replies.
Authentication will help reduce the number of seemingly valid MPLS To avoid potential Denial of Service attacks, it is RECOMMENDED that
echo requests, and thus cut down the Denial of Service attacks; implementations regulate the LSP ping traffic going to the control
beyond that, each LSR must protect itself. To avoid potential Denial plane. A rate limiter SHOULD be applied to the well-known UDP port
of Service attacks, it is RECOMMENDED that implementations regulate defined below.
the LSP ping traffic going to the control plane. A rate limiter
SHOULD be applied to the well-known UDP port defined below.
Authentication sufficiently addresses spoofing, replay and most tam- Replay and spoofing attacks are unlikely to be effective given that
pering attacks; one hopes to use some mechanism devised or suggested the Sender's Handle and Sequence Number need to be valid. Thus a
by the RPSec WG. It is not clear how to prevent hijacking (non- replay would be discarded as the sequence has moved on. A spoof has
delivery) of echo requests or replies; however, if these messages are only a small window of opportunity, however an implementation MAY
indeed hijacked, LSP ping will report that the data plane isn't work- provide a validation on the TimeStamp Sent to limit the window to the
ing as it should. resolution of the system clock.
It is not clear how to prevent hijacking (non-delivery) of echo
requests or replies; however, if these messages are indeed hijacked,
LSP ping will report that the data plane isn't working as it should.
It doesn't seem vital (at this point) to secure the data carried in It doesn't seem vital (at this point) to secure the data carried in
MPLS echo requests and replies, although knowledge of the state of MPLS echo requests and replies, although knowledge of the state of
the MPLS data plane may be considered confidential by some. 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.
7. IANA Considerations 7. IANA Considerations
The TCP and UDP port number 3503 has been allocated by IANA for LSP The TCP and UDP port number 3503 has been allocated by IANA for LSP
echo requests and replies. echo requests and replies.
The following sections detail the new name spaces to be managed by The following sections detail the new name spaces to be managed by
IANA. For each of these name spaces, the space is divided into IANA. For each of these name spaces, the space is divided into
assignment ranges; the following terms are used in describing the assignment ranges; the following terms are used in describing the
procedures by which IANA allocates values: "Standards Action" (as procedures by which IANA allocates values: "Standards Action" (as
skipping to change at page 41, line 28 skipping to change at page 42, line 28
Email: swallow@cisco.com Email: swallow@cisco.com
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Expiration Date Expiration Date
November 2005 March 2006
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 25 change blocks. 
61 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/