To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
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
replaying MPLS echo reply messages are unlikely to be effective.
These replies would have to match the Sender’s Handle and Sequence
Number of an outstanding MPLS echo request message. A non-matching
replay would be discarded as the sequence has moved on, thus a spoof
has only a small window of opportunity. However, to provide a
stronger defense, an implementation MAY also validate the TimeStamp
Sent by requiring and exact match on this field.
To protect against unauthorized sources using MPLS echo request
messages to obtain network information, it is RECOMMENDED that
implementations provide a means of checking the source addresses of
MPLS echo request messages against an access list before accepting
the message.
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 is not working as it should.
It does not seem vital (at this point) to secure the data carried in
MPLS echo requests and replies, although knowledge of the state of
the MPLS data plane may be considered confidential by some.
Implementations 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. Furthermore, these
packets are only processed by routers. All other hosts MUST treat
all packets with a destination address in the range 127/8 in
accordance to RFC 1122. 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 RFC 1812. In particular,
the default behavior is to treat packets destined to a 127/8 address
as "martians".
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
defined in [IANA]), "Specification Required", and "Vendor Private
Use".
Values from "Specification Required" ranges MUST be registered with
IANA. The request MUST be made via an Experimental RFC that
describes the format and procedures for using the code point; the
actual assignment is made during the IANA actions for the RFC.
Values from "Vendor Private" ranges MUST NOT be registered with IANA;
however, the message MUST contain an enterprise code as registered
with the IANA SMI Private Network Management Private Enterprise
Numbers. For each name space that has a Vendor Private range, it
must be specified where exactly the SMI Private Enterprise Number
resides; see below for examples. In this way, several enterprises
(vendors) can use the same code point without fear of collision.
7.1. Message Types, Reply Modes, Return Codes
The IANA has created and will maintain registries for Message Types,
Reply Modes, and Return Codes. Each of these can take values in the
range 0-255. Assignments in the range 0-191 are via Standards
Action; assignments in the range 192-251 are made via "Specification
Required"; values in the range 252-255 are for Vendor Private Use,
and MUST NOT be allocated.
If any of these fields fall in the Vendor Private range, a top-level
Vendor Enterprise Number TLV MUST be present in the message.
Message Types defined in this document are the following:
Value Meaning
----- -------
1 MPLS echo request
2 MPLS echo reply
Reply Modes defined in this document are the following:
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel
Return Codes defined in this document are listed in section 3.1.
7.2. TLVs
The IANA has created and will maintain a registry for the Type field
of top-level TLVs as well as for any associated sub-TLVs. Note the
meaning of a sub-TLV is scoped by the TLV. The number spaces for the
sub-TLVs of various TLVs are independent.
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
defined in [IANA]; assignments in the range 16384-31743 and
49162-64511 are made via "Specification Required" as defined above;
values in the range 31744-32767 and 64512-65535 are for Vendor
Private Use, and MUST NOT be allocated.
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
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 and sub-TLVs defined in this document are the following:
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack
1 LDP IPv4 prefix
2 LDP IPv6 prefix
3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Not Assigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated)
10 "FEC 128" Pseudowire
11 "FEC 129" Pseudowire
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
8. Acknowledgements
This document is the outcome of many discussions among many people,
including Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan,
Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal, and Vanson
Lim.
The description of the Multipath Information sub-field of the
Downstream Mapping TLV was adapted from text suggested by Curtis
Villamizar.
Authors’ Addresses
Kireeti Kompella
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
George Swallow
Cisco Systems
1414 Massachusetts Ave,
Boxborough, MA 01719
Phone: +1 978 936 1398
EMail: swallow@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).