draft-ietf-mpls-lsp-ping-relay-reply-07.txt   draft-ietf-mpls-lsp-ping-relay-reply-08.txt 
Network Working Group J. Luo, Ed. Network Working Group J. Luo, Ed.
Internet-Draft ZTE Internet-Draft ZTE
Updates: 4379 (if approved) L. Jin, Ed. Updates: 4379 (if approved) L. Jin, Ed.
Intended status: Standards Track Individual Intended status: Standards Track Individual
Expires: September 8, 2015 T. Nadeau, Ed. Expires: October 30, 2015 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
March 7, 2015 April 28, 2015
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-07 draft-ietf-mpls-lsp-ping-relay-reply-08
Abstract Abstract
In some inter autonomous system (AS) and inter-area deployment In some inter autonomous system (AS) and inter-area deployment
scenarios for RFC 4379 "Label Switched Path (LSP) Ping and scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
Traceroute", a replying LSR may not have the available route to the Traceroute", a replying LSR may not have the available route to the
initiator, and the Echo Reply message sent to the initiator would be initiator, and the Echo Reply message sent to the initiator would be
discarded resulting in false negatives or complete failure of discarded resulting in false negatives or complete failure of
operation of LSP Ping and Traceroute. This document describes operation of LSP Ping and Traceroute. This document describes
extensions to LSP Ping mechanism to enable the replying Label extensions to LSP Ping mechanism to enable the replying Label
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 8, 2015. This Internet-Draft will expire on October 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6
3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8 3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10
4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11
4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 11 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 11
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 11 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 14 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the extensions to the Label Switched Path This document describes the extensions to the Label Switched Path
(LSP) Ping as specified in [RFC4379], by adding a relayed echo reply (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply
mechanism which could be used to detect data plane failures for the mechanism which could be used to detect data plane failures for the
inter autonomous system (AS) and inter-area LSPs. The extensions are inter autonomous system (AS) and inter-area LSPs. The extensions are
to update the [RFC4379]. Without these extensions, the ping to update the [RFC4379]. Without these extensions, the ping
functionality provided by [RFC4379] would fail in many deployed functionality provided by [RFC4379] would fail in many deployed
inter-AS scenarios, since the replying LSR in one AS may not have the inter-AS scenarios, since the replying LSR in one AS may not have the
skipping to change at page 3, line 45 skipping to change at page 3, line 45
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Motivation 2. Motivation
LSP Ping [RFC4379] defines a mechanism to detect the data plane LSP Ping [RFC4379] defines a mechanism to detect the data plane
failures and localize faults. The mechanism specifies that the Echo failures and localize faults. The mechanism specifies that the Echo
Reply should be sent back to the initiator using an UDP packet with Reply should be sent back to the initiator using an UDP packet with
the IPv4/ IPv6 address of the originating LSR. This works in the IPv4/IPv6 address of the originating LSR. This works in
administrative domains where IP addresses reachability are allowed administrative domains where IP addresses reachability are allowed
among LSRs, and every LSR is able to route back to the originating among LSRs, and every LSR is able to route back to the originating
LSR. However, in practice, this is often not the case due to intra- LSR. However, in practice, this is often not the case due to intra-
provider routing policy, route hiding, and network address provider routing policy, route hiding, and network address
translation at autonomous system border routers (ASBR). In fact, it translation at autonomous system border routers (ASBR). In fact, it
is almost uniformly the case that in inter-AS scenarios, it is not is almost uniformly the case that in inter-AS scenarios, it is not
allowed the distribution or direct routing to the IP addresses of any allowed the distribution or direct routing to the IP addresses of any
of the nodes other than the ASBR in another AS. of the nodes other than the ASBR in another AS.
Figure 1 demonstrates a case where one LSP is set up between PE1 and Figure 1 demonstrates a case where one LSP is set up between PE1 and
PE2. If PE1's IP address is not distributed to AS2, a traceroute PE2. If PE1's IP address is not distributed to AS2, a traceroute
from PE1 directed to PE2 could fail if the fault exists somewhere from PE1 directed towards PE2 can result in a failure because an LSR
between ASBR2 and PE2. Because P2 cannot forward packets back to PE1 in AS2 may not be able to send the Echo Reply message. E.g., P2
given that it is an routable IP address in AS1 but not routable in cannot forward packets back to PE1 given that it is an routable IP
AS2. In this case, PE1 would detect a path break, as the Echo Reply address in AS1 but not routable in AS2. In this case, PE1 would
messages would not be received. Then localization of the actual detect a path break, as the Echo Reply messages would not be
fault would not be possible. received. Then localization of the actual fault would not be
possible.
Note that throughout the document, routable address means that it is Note that throughout the document, routable address means that it is
possible to route an IP packet to this address using the normal possible to route an IP packet to this address using the normal
information exchanged by the IGP operating in the AS information exchanged by the IGP operating in the AS.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<---------------------------- LSP ------------------------------> <---------------------------- LSP ------------------------------>
Figure 1: Simple Inter-AS LSP Configuration Figure 1: Simple Inter-AS LSP Configuration
A second example that illustrates how [RFC4379] would be insufficient A second example that illustrates how [RFC4379] would be insufficient
would be the inter-area situation in a seamless MPLS architecture would be the inter-area situation in a seamless MPLS architecture
[I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this
example LSRs in the core network would not have IP reachable route to example LSRs in the core network would not have IP reachable route to
any of the ANs. When tracing an LSP from one AN to the remote AN, any of the ANs. When tracing an LSP from one AN to the remote AN,
the LSR1/LSR2 node could not make a response to the Echo Request the LSR1/LSR2 node cannot send the Echo Reply either, like the P2
either, like the P2 node in the inter-AS scenario in Figure 1. node in the inter-AS scenario in Figure 1.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ | AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| | \ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
skipping to change at page 6, line 33 skipping to change at page 6, line 33
has been allocated by IANA for LSP Ping messages. The Relayed Echo has been allocated by IANA for LSP Ping messages. The Relayed Echo
Reply message will use the same port number. Reply message will use the same port number.
3.2. Relay Node Address Stack 3.2. Relay Node Address Stack
The Relay Node Address Stack TLV is an optional TLV. It MUST be The Relay Node Address Stack TLV is an optional TLV. It MUST be
carried in the Echo Request, Echo Reply and Relayed Echo Reply carried in the Echo Request, Echo Reply and Relayed Echo Reply
messages if the echo reply relayed mechanism described in this messages if the echo reply relayed mechanism described in this
document is required. Figure 3 illustrates the TLV format. document is required. Figure 3 illustrates the TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Reply Add Type| Reserved | | Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octects) | | Source Address of Replying Router (0, 4, or 16 octects) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Pointer | Number of Relayed Addresses | | Destination Address Pointer | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 7, line 40 skipping to change at page 7, line 40
entry on the top of the Stack of Relayed Addresses will have value entry on the top of the Stack of Relayed Addresses will have value
1. 1.
- Number of Relayed Addresses: an integer indicating the number of - Number of Relayed Addresses: an integer indicating the number of
relayed addresses in the stack. relayed addresses in the stack.
- Stack of Relayed Addresses: a list of relay node addresses. - Stack of Relayed Addresses: a list of relay node addresses.
The format of each relay node address is as below: The format of each relay node address is as below:
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 |K| Reserved | Reserved | | Address Type |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octects) ~ ~ Relayed Address (0, 4, or 16 octects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type# Address Type Address Length Type# Address Type Address Length
---- ------------ ------------ ---- ------------ ------------
0 Null 0 0 Null 0
1 IPv4 4 1 IPv4 4
skipping to change at page 8, line 24 skipping to change at page 8, line 24
in the Relay Node Address Stack TLV. The address with K bit set will in the Relay Node Address Stack TLV. The address with K bit set will
always be a relay node address for the Relayed Echo Reply, see always be a relay node address for the Relayed Echo Reply, see
section 4.3. section 4.3.
Relayed Address: this field specifies the node address, either IPv4 Relayed Address: this field specifies the node address, either IPv4
or IPv6. or IPv6.
3.3. MTU Exceeded Return Code 3.3. MTU Exceeded Return Code
Return Code is defined to indicate that one or more TLVs were omitted Return Code is defined to indicate that one or more TLVs were omitted
from the Reply or Relay-Reply message to avoid exceeding the from the Echo Reply or Relayed Echo Reply message to avoid exceeding
message's effective MTU size. These TLVs MAY be included in an the message's effective MTU size. These TLVs MAY be included in an
Errored TLV's Object with their lengths set to 0 and no value. The Errored TLV's Object with their lengths set to 0 and no value. The
return sub-code MUST be set to the value that otherwise would have return sub-code MUST be set to the value that otherwise would have
been sent. been sent.
MTU Exceeded Return Code: MTU Exceeded Return Code:
Value Meaning Value Meaning
----- ------- ----- -------
TBD One or more TLVs not returned due to MTU size TBD One or more TLVs not returned due to MTU size
4. Procedures 4. Procedures
4.1. Sending an Echo Request 4.1. Sending an Echo Request
In addition to the procedures described in section 4.3 of [RFC4379], In addition to the procedures described in section 4.3 of [RFC4379],
a Relay Node Address Stack TLV MUST be carried in the Echo Request a Relay Node Address Stack TLV MUST be carried in the Echo Request
message to facilitate the relay functionality. message to facilitate the relay functionality.
When the Echo Request is first sent by the initiator included a Relay When the initiator sends the first Echo Request with a Relay Node
Node Address Stack TLV, the TLV MUST contain the initiator address as Address Stack TLV, the TLV MUST contain the initiator address as the
the only entry of the stack of relayed addresses, the destination first entry of the stack of relayed addresses, the destination
address pointer set to this entry, and the source address of the address pointer set to this entry, and the source address of the
replying router set to null. The source UDP port field MUST be set replying router set to null. The source UDP port field MUST be set
to the source UDP port. Note that the first relay node address in to the source UDP port. Note that the first relay node address in
the stack will always be the initiator's address. the stack will always be the initiator's address.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
An LSR that does not recognize the Relay Node Address Stack TLV, An LSR that does not recognize the Relay Node Address Stack TLV,
SHOULD ignore it as per section 3 of [RFC4379]. SHOULD ignore it as per section 3 of [RFC4379].
skipping to change at page 9, line 25 skipping to change at page 9, line 25
Router". The address MUST be same as the source IP address of Relay Router". The address MUST be same as the source IP address of Relay
Echo Reply (section 4.3) or Echo Reply message (section 4.5) being Echo Reply (section 4.3) or Echo Reply message (section 4.5) being
sent. sent.
Those address entries with K bit set to 1 MUST be kept in the stack. Those address entries with K bit set to 1 MUST be kept in the stack.
The receiver MUST check the addresses of the stack in sequence from The receiver MUST check the addresses of the stack in sequence from
bottom to top to find the last address in the stack with the K bit bottom to top to find the last address in the stack with the K bit
set (or the top of the stack if no K bit was found). The receiver set (or the top of the stack if no K bit was found). The receiver
then checks the stack beginning with this entry, proceeding towards then checks the stack beginning with this entry, proceeding towards
the bottom to find the first routable address IP address. The the bottom to find the first routable address IP address. The
Destination Address Pointer MUST be set to this entry. Address Destination Address Pointer MUST be set to this entry which is also
entries below the first routable IP address MUST be deleted. At the Destination Address. Address entries below the first routable IP
least one address entries of the replying LSR MUST be added at the address MUST be deleted. At least one address entries of the
bottom of the stack. A second or more address entries MAY also be replying LSR MUST be added at the bottom of the stack. A second or
added if necessary, depending on implementation. The final address more address entries MAY also be added if necessary, depending on
added MUST be an address that is reachable through the interface that implementation. The final address added MUST be an address that is
the Echo Request Message would have been forwarded if it had not TTL reachable through the interface that the Echo Request Message would
expired at this node. The updated Relay Node Address Stack TLV MUST have been forwarded if it had not TTL expired at this node. The
be carried in the response message. updated Relay Node Address Stack TLV MUST be carried in the response
message.
If the replying LSR is configured to hide its routable address If the replying LSR is configured to hide its routable address
information, the address entry added in the stack MUST be a NIL entry information, the address entry added in the stack MUST be a NIL entry
with Address Type set to NULL. with Address Type set to NULL.
If a node spans two addressing domains (with respect to this message) If a node spans two addressing domains (with respect to this message)
where nodes on either side may not be able to nodes in the other where nodes on either side may not be able to reach nodes in the
domain, then the final address added MUST set the K bit. K bit other domain, then the final address added SHOULD set the K bit. K
applies in the case of a NULL address, to serve as a warning to the bit applies in the case of a NULL address, to serve as a warning to
initiator that further Echo Request messages may not result in the initiator that further Echo Request messages may not result in
receiving Echo Reply messages. receiving Echo Reply messages.
If the full reply message would exceed the MTU size, the Relay Node If the full reply message would exceed the MTU size, the Relay Node
Address Stack TLV MUST be returned back in the Echo Reply message. Address Stack TLV SHOULD be included in the Echo Reply message (i.e.,
Some other TLV(s) MUST be dropped. other optional TLVs are excluded).
4.3. Originating an Relayed Echo Reply 4.3. Originating an Relayed Echo Reply
The Destination Address determined in section 4.2 is used as the next The Destination Address determined in section 4.2 is used as the next
relay node address. If the resolved next relay node address is not relay node address. If the resolved next relay node address is not
routable, then sending of Relayed Echo Reply or Echo Reply will fail. routable, then sending of Relayed Echo Reply or Echo Reply will fail.
If the first IP address in the Relay Node Address Stack TLV is not If the first IP address in the Relay Node Address Stack TLV is not
the next relay node address, the replying LSR SHOULD send a Relayed the next relay node address, the replying LSR SHOULD send a Relayed
Echo Reply message to the next relay node. The processing of Relayed Echo Reply message to the next relay node. The processing of Relayed
Echo Reply is the same with the procedure of the Echo Reply described Echo Reply is the same with the procedure of the Echo Reply described
in Section 4.5 of [RFC4379], except the destination IP address and in Section 4.5 of [RFC4379], except the destination IP address and
the destination UDP port. The destination IP address of the Relayed the destination UDP port. The destination IP address of the Relayed
Echo Reply is set to the next relay node address from the Relay Node Echo Reply is set to the next relay node address from the Relay Node
Address Stack TLV, and both the source and destination UDP port are Address Stack TLV, and both the source and destination UDP port are
set to 3503. The updated Relay Node Address Stack TLV described in set to 3503. The updated Relay Node Address Stack TLV described in
section 4.2 MUST be carried in the Relayed Echo Reply message. section 4.2 MUST be carried in the Relayed Echo Reply message. The
Source Address of Replying Router field is kept unmodified, and
Source IP address field of the IP header is set to an address of the
sending node.
4.4. Relaying an Relayed Echo Reply 4.4. Relaying an Relayed Echo Reply
Upon receiving an Relayed Echo Reply message with its own address as Upon receiving an Relayed Echo Reply message with its own address as
the destination address in the IP header, the relay node MUST the destination address in the IP header, the relay node MUST
determine the next relay node address as described in section 4.3, determine the next relay node address as described in section 4.2,
with the modification that the location of the received Destination with the modification that the location of the received Destination
Address is used instead of the bottom of stack in the algorithm. The Address is used instead of the bottom of stack in the algorithm. The
destination address in Relay Node Address Stack TLV will be updated Destination Address Pointer in Relay Node Address Stack TLV will be
with the next relay node address. Note that unlike section 4.2 no set to the next relay node address. Note that unlike section 4.2 no
changes are made to the Stack of Relayed Addresses. changes are made to the Stack of Relayed Addresses.
If the next relay node address is not the first one in the address If the next relay node address is not the first one in the address
list, i.e., another intermediate relay node, the relay node MUST send list, i.e., another intermediate relay node, the relay node MUST send
an Relayed Echo Reply message to the determined upstream node with an Relayed Echo Reply message to the determined upstream node with
the payload unchanged other than the Relay Node Address Stack TLV. the payload unchanged other than the Relay Node Address Stack TLV.
The TTL SHOULD be copied from the received Relay Echo Reply and The TTL SHOULD be copied from the received Relay Echo Reply and
decremented by 1. decremented by 1. The Source Address of Replying Router field is
kept unmodified, and Source IP address field of the IP header is set
to an address of the sending node.
4.5. Sending an Echo Reply 4.5. Sending an Echo Reply
The Echo Reply is sent in two cases: The Echo Reply is sent in two cases:
1. When the replying LSR receives an Echo Request, and the first IP 1. When the replying LSR receives an Echo Request, and the first IP
address in the Relay Node Address Stack TLV is the next relay node address in the Relay Node Address Stack TLV is the next relay node
address (section 4.3), the replying LSR would send an Echo Reply to address (section 4.3), the replying LSR would send an Echo Reply to
the initiator. In addition to the procedure of the Echo Reply the initiator. In addition to the procedure of the Echo Reply
described in Section 4.5 of [RFC4379], the updated Relay Node Address described in Section 4.5 of [RFC4379], the updated Relay Node Address
skipping to change at page 11, line 13 skipping to change at page 11, line 18
and the first IP address in the Relay Node Address Stack TLV is the and the first IP address in the Relay Node Address Stack TLV is the
next relay node address (section 4.4), the intermediate relay node next relay node address (section 4.4), the intermediate relay node
would send the Echo Reply to the initiator, and update the Message would send the Echo Reply to the initiator, and update the Message
Type field from type of Relayed Echo Reply to Echo Reply. The Type field from type of Relayed Echo Reply to Echo Reply. The
updated Relay Node Address Stack TLV described in section 4.4 MUST be updated Relay Node Address Stack TLV described in section 4.4 MUST be
carried in the Echo Reply. The destination IP address of the Echo carried in the Echo Reply. The destination IP address of the Echo
Reply is set to the first IP address in the stack, and the Reply is set to the first IP address in the stack, and the
destination UDP port would be copied from the Initiator Source Port destination UDP port would be copied from the Initiator Source Port
field of the Relay Node Address Stack TLV. The source UDP port field of the Relay Node Address Stack TLV. The source UDP port
should be 3503. The TTL of the Echo Reply SHOULD be copied from the should be 3503. The TTL of the Echo Reply SHOULD be copied from the
received Relay Echo Reply and decremented by 1. received Relay Echo Reply and decremented by 1. The Source Address
of Replying Router field is kept unmodified, and Source IP address
field of the IP header is set to an address of the sending node.
4.6. Sending Subsequent Echo Requests 4.6. Sending Subsequent Echo Requests
During a traceroute operation, multiple Echo Request messages are During a traceroute operation, multiple Echo Request messages are
sent. Each time the TTL is increased, the initiator MUST copy the sent. Each time the TTL is increased, the initiator could copy the
Relay Node Address Stack TLV received in the previous Echo Reply to Relay Node Address Stack TLV received in the previous Echo Reply to
the next Echo Request. the next Echo Request.Some modifications could also be made to the
stack TLV. The NIL entry with K bit set SHOULD be deleted, otherwise
the Echo Reply message will not be returned. The fields of Source
Address of Replying Router and Destination Address Pointer may be
preserved or may be reset for subsequent MPLS Echo Request, and to be
ignored in received MPLS Echo Request.
4.7. Impact to Traceroute 4.7. Impact to Traceroute
Source IP address in Echo Reply and Relay Echo Reply is to be of the Source IP address in Echo Reply and Relay Echo Reply is to be of the
address of the node sending those packets, not the original address of the node sending those packets, not the original
responding node. Then the traceroute address output module will responding node. Then the traceroute address output module will
print the source IP address as below: print the source IP address as below:
if (Relay Node Address Stack TLV exists) { if (Relay Node Address Stack TLV exists) {
Print the Source Address of Replying Router in Print the Source Address of Replying Router in
skipping to change at page 13, line 35 skipping to change at page 13, line 44
Node Address Stack. These messages then could be used to attack the Node Address Stack. These messages then could be used to attack the
control plane of an LSR by overwhelming it with these packets. A control plane of an LSR by overwhelming it with these packets. A
rate limiter SHOULD be applied to the well-known UDP port on the rate limiter SHOULD be applied to the well-known UDP port on the
relay node as suggested in [RFC4379]. The node which acts as a relay relay node as suggested in [RFC4379]. The node which acts as a relay
node SHOULD validate the relay reply against a set of valid source node SHOULD validate the relay reply against a set of valid source
addresses and discard packets from untrusted border router addresses. addresses and discard packets from untrusted border router addresses.
An implementation SHOULD provide such filtering capabilities. An implementation SHOULD provide such filtering capabilities.
If an operator wants to obscure their nodes, it is RECOMMENDED that If an operator wants to obscure their nodes, it is RECOMMENDED that
they may replace the replying node address that originated the Echo they may replace the replying node address that originated the Echo
Reply with blank address in Relay Node Address Stack TLV. Reply with NIL address entry in Relay Node Address Stack TLV.
A receiver of an MPLS Echo Request could verify that the first
address in the Relay Node Address Stack TLV is the same address as
the source IP address field of the received IP header.
Other security considerations discussed in [RFC4379], are also Other security considerations discussed in [RFC4379], are also
applicable to this document. applicable to this document.
7. Backward Compatibility 7. Backward Compatibility
When one of the nodes along the LSP does not support the mechanism When one of the nodes along the LSP does not support the mechanism
specified in this document, the node will ignore the Relay Node specified in this document, the node will ignore the Relay Node
Address Stack TLV as described in section 4.2. Then the initiator Address Stack TLV as described in section 4.2. Then the initiator
may not receive the Relay Node Address Stack TLV in Echo Reply may not receive the Relay Node Address Stack TLV in Echo Reply
 End of changes. 27 change blocks. 
51 lines changed or deleted 69 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/