RFC 7743
Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
RFC 7743: Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping 🎀
okay bestie, this is an IETF document (Internet Engineering Task Force 🦋), and it's RFC number 7743. It's a Standards Track doc, so it's an actual Internet standard, no cap 👑 It's dated January 2016 and has ISSN 2070-1721.
The authors are J. Luo, Ed. (ZTE), L. Jin, Ed. (no affiliation listed in the header), T. Nadeau, Ed. (Brocade), and G. Swallow, Ed. (Cisco). 💜
It updates RFC 4379, which is the LSP Ping and Traceroute spec 🌸 There's no Obsoletes line in the header, so it doesn't replace anything.
Abstract
okay so in some inter-AS (Autonomous System) and inter-area setups for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), the replying Label Switching Router (LSR) might not have a route back to the initiator 😭 Then the Echo Reply gets tossed, and you get false negatives, or LSP Ping and Traceroute just totally fail to work 💀
This doc adds extensions to LSP Ping so the replying LSR can relay the Echo Response through a set of routable intermediate nodes back to the initiator 🫶 It's giving rescue mission. This document updates RFC 4379.
Status of This Memo
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🎀
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7743. 🔗
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stand on the date this document was published. Please read those carefully, because they spell out your rights and restrictions for this document. 🧚
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License. 🌈
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Motivation ......................................................3
3. Extensions ......................................................5
3.1. Relayed Echo Reply Message .................................5
3.2. Relay Node Address Stack ...................................6
3.3. MTU Exceeded Return Code ...................................8
4. Procedures ......................................................8
4.1. Sending an Echo Request ....................................9
4.2. Receiving an Echo Request ..................................9
4.3. Originating a Relayed Echo Reply ..........................10
4.4. Relaying a Relayed Echo Reply .............................11
4.5. Sending an Echo Reply .....................................11
4.6. Sending Subsequent Echo Requests ..........................12
4.7. Impact on Traceroute ......................................12
5. LSP Ping Relayed Echo Reply Example ............................13
6. Security Considerations ........................................14
7. Backward Compatibility .........................................15
8. IANA Considerations ............................................15
8.1. MPLS Relayed Echo Reply ...................................15
8.2. Relay Node Address Stack TLV ..............................16
8.3. MTU Exceeded Return Code ..................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
Acknowledgements ..................................................17
Contributors ......................................................17
Authors' Addresses ................................................181. Introduction ✨
This doc extends the Label Switched Path (LSP) Ping spec from [RFC4379] by adding a Relayed Echo Reply mechanism. It can report data-plane failures for inter-AS (Autonomous System) and inter-area LSPs 🦋 Without these extensions, the ping functionality from [RFC4379] would break in lots of real deployed inter-AS setups, because the replying Label Switching Router (LSR) in one AS might not have an available route to the initiator in the other AS 😭
The mechanism introduces a new Message Type called the "Relayed Echo Reply message" and a new TLV called the "Relay Node Address Stack TLV" 💅
This document updates [RFC4379]. Specifically, it changes the Echo Request sending procedure in Section 4.3 of [RFC4379], the Echo Request receiving procedure in Section 4.4 of [RFC4379], the Echo Reply sending procedure in Section 4.5 of [RFC4379], and the Echo Reply receiving procedure in Section 4.6 of [RFC4379]. 🎀
1.1. Conventions Used in This Document
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. 🤓📖
2. Motivation 🌸
LSP Ping [RFC4379] is the tool for detecting data-plane failures and localizing faults 🔍 The mechanism says the Echo Reply should go back to the initiator in a UDP packet, with the IPv4/IPv6 destination address set to an address of the LSR that sent the Echo Request. That works fine in administrative domains where IP-address reachability is allowed among LSRs and every LSR can route back to the originating LSR 🫶
Here's the problem, though: in practice that's often not the case, thanks to intra-provider routing policy, route hiding, and network address translation at Autonomous System Border Routers (ASBRs) 😬 In fact, it's almost always true in inter-AS scenarios that the only node in one AS that the other AS can route to directly is the ASBR. Routing info from inside one AS also doesn't get distributed into another AS. Major main-character drama 👑
Figure 1 shows an LSP set up between PE1 and PE2. If PE1's IP address isn't distributed to AS2, a traceroute from PE1 toward PE2 can fail, because an LSR in AS2 might not be able to send the Echo Reply 💔 For example, P2 can't forward packets back to PE1, since it's a routable IP address in AS1 but not routable in AS2. Then PE1 would think the path is broken, since the Echo Reply messages never arrive, and figuring out the actual fault wouldn't be possible 🙈
Quick note: throughout the document, "routable address" means you can route an IP packet to that address using the normal information exchanged by the IGP and BGP (or EGP) operating in the AS. 📌
+-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------>
<---------------------------- LSP ------------------------------>
Figure 1: Simple Inter-AS LSP ConfigurationA second example where [RFC4379] falls short is the inter-area situation in a seamless MPLS architecture [MPLSARCH], shown in Figure 2 🦋 Here the LSRs in the core network don't have an IP-reachable route to any of the access nodes (ANs). When you trace an LSP from one AN to the remote AN, the LSR1/LSR2 node can't send the Echo Reply either, just like P2 in the inter-AS scenario in Figure 1 😭
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route IS-IS L1 LDP IS-IS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
AGN: aggregation node
Figure 2: Seamless MPLS ArchitectureThis doc describes LSP Ping extensions that let the replying LSR get its response back through a relay node (like an ASBR) that relays the message to the initiator 🌈 Every designated or learned relay node must be reachable from the next relay node or from the initiator. Relay nodes can work recursively: each one relays the message to the next, until the initiator is reached. Chain reaction, bestie 🔗
The LSP Ping relay mechanism in this document is defined for unicast. Applying it to multicast is out of scope. 🚫
3. Extensions 💖
[RFC4379] defines two Message Types: Echo Request and Echo Reply. This document adds a new one: Relayed Echo Reply 🎀 The Relayed Echo Reply message is used in place of the Echo Reply message when an LSR is the replying LSR talking to a relay node.
A new TLV named the "Relay Node Address Stack TLV" carries the IP addresses of the relay nodes for the replying LSR 🧚
The Maximum Transmission Unit (MTU) Exceeded Return Code is also defined, to tell the initiator that one or more TLVs won't be returned because of the MTU size. ✨
It should be noted that this document only focuses on detecting LSPs set up with a uniform IP address family type 🦋 In other words, all hops between the source and destination node use the same address family type for their LSP Ping control planes. This doesn't rule out nodes that support both IPv6 and IPv4 at the same time, but the whole path must be addressable with only one address family type. Mixed IPv4-only and IPv6-only support is beyond the scope of this document 🙅♀️
3.1. Relayed Echo Reply Message
The Relayed Echo Reply message is a UDP packet, and its UDP payload has the same format as the Echo Request/Reply message. A new Message Type has been requested from IANA 🌸
New Message Type:
Value Meaning
----- -------
5 MPLS Relayed Echo ReplyThe use of TCP and UDP port number 3503 is described in [RFC4379] and has been allocated by IANA for LSP Ping messages. The Relayed Echo Reply message uses the same port number. 🔥
3.2. Relay Node Address Stack 🧚✨
okay so the Relay Node Address Stack TLV is an optional TLV 🎀 but if you need the Echo Reply relayed mechanism from this doc, it MUST show up in the Echo Request, Echo Reply, and Relayed Echo Reply messages 💅 here's what it looks like (Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Offset | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Stack of Relayed Addresses ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Relay Node Address Stack TLV- Type: the value is 32768 🍓 IANA assigned it out of the 32768-49161 range, as suggested by [RFC4379], Section 3.
- Length: the length of the value field, in octets 📏
- Initiator Source Port: the source UDP port the initiator uses in the Echo Request message, and the port that's expected to receive the Echo Reply message 🦋
- Reply Address Type: the address type of the replying router. This value also tells you how long the address field is, as shown below 👀
Type# Address Type Address Length
---- ------------ ------------
0 Null 0
1 IPv4 4
2 IPv6 16- Reserved: this field is reserved and MUST be set to zero 🫶
- Source Address of Replying Router: the source IP address of whoever originated the Echo Reply or Relay Echo Reply message 🌸
- Destination Address Offset: the offset in octets from the top-of-stack to the destination address entry. Each entry size is listed in this section. Also check out Section 4.2 for more detail on how this works 🧠
- Number of Relayed Addresses: an integer that tells you how many relayed addresses are in the stack 🔢
- Stack of Relayed Addresses: a list of relay node address entries. The stack grows downward, and relay node addresses that are further along the LSP sit lower in the stack 🪜 For the relay node discovery mechanism, go to Section 4.2 ✨
The format of each relay node address entry looks like this (Figure 4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Relay Node Address EntryType# Address Type Address Length Size of the Entry
---- ------------ ------------ -----------------
0 Null 0 4
1 IPv4 4 8
2 IPv6 16 20- Reserved: the two fields are reserved and MUST be set to zero 🙅♀️
- K bit: if the K bit is set to 1, then this address stack entry MUST NOT be stripped from the Relay Node Address Stack during the processing described in Section 4.2. If the K bit is clear, the entry might be stripped according to the processing described in Section 4.2 🔐
Having the K bit set in a relay node address entry means that entry stays in the Relay Node Address Stack TLV for the entire traceroute operation 🗺️ A responder node MAY set the K bit so its relay node address entry remains as one of the relay nodes in the Relay Node Address Stack TLV 💜 The address with the K bit set will always be a relay node address for the Relayed Echo Reply. See Section 4.3 ✨
- Relayed Address: this field specifies the node address, either IPv4 or IPv6 🌈
3.3. MTU Exceeded Return Code 🚨
okay this Return Code is for when one or more TLVs got left out of the Echo Reply or Relayed Echo Reply message so it doesn't go over the message's effective MTU size 😭 those TLVs MAY be included in an 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 been sent. For more detail, go to Section 4.2 🫶
MTU Exceeded Return Code:
Value Meaning
----- -------
20 One or more TLVs not returned due to MTU sizeThis document updates step 7 in Section 4.4 of [RFC4379] so it includes the processing of the MTU Exceeded Return Code. It does this by adding the following text:
Before sending Echo Reply, the new packet size should be checked. If Best-return-code is 3 ("Replying router is an egress for the FEC at stack depth"), or 8 ("Label switched at stack-depth"), and if the packet size exceeds MTU size, then Best-return-code is 20 ("One or more TLVs not returned due to MTU size").
4. Procedures 🎀
okay so to do a ping operation, the initiator first discovers the relay nodes 🔍 once those are found, the initiator puts the Relay Node Address Stack TLV into any Echo Request message, and then the node can ping as normal 🦋 heads up, though: if you keep getting no replies to Echo Request messages, it could be a route change that messed with the relay node stack. In that case the initiator may need to rediscover the relay nodes 😬 The next sections walk through the procedures for sending and receiving Echo Request messages with the Relay Node Address Stack TLV. These procedures can also be used in traceroute mode to discover the relay nodes 🗺️✨
4.1. Sending an Echo Request 📤
so in addition to the procedures in Section 4.3 of [RFC4379], a Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required. How the relay function gets started is out of scope for this document. One possible way is for the operator to add an option to the ping command 💅
When the initiator sends its first Echo Request with a Relay Node Address Stack TLV, the TLV MUST contain the initiator address as the first entry of the stack of relayed addresses. The Destination Address Offset is set to this entry, and the source address of the replying router is set to null. The Initiator Source Port field MUST be set to the source UDP port. Note that the first relay node address in the stack will always be the initiator's address 🫶
For a subsequent Echo Request message, go to Section 4.6 ✨
4.2. Receiving an Echo Request 📥
the Type of the Relay Node Address Stack TLV (32768) falls in the range that [RFC4379] calls "optional TLVs". Those can be silently dropped if they aren't recognized. So an LSR that doesn't recognize the TLV SHOULD ignore it 🙈
In addition to the processes in Section 4.4 of [RFC4379], the procedures for the Relay Node Address Stack TLV are defined here 🧚
When a receiver gets a Relay Node Address Stack TLV in an Echo Request message, it updates the "Source Address of Replying Router". That address MUST be the same as the source IP address of the Relay Echo Reply (Section 4.3) or Echo Reply message (Section 4.5) that's being sent 💖
Address entries with the K bit set to 1 MUST be kept in the stack. The receiver MUST check the addresses in the stack in sequence from 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). Then the receiver checks the stack starting at this entry and works towards the bottom, looking for the first routable IP address. The Destination Address Offset MUST be set to this entry, which is also the resolved destination address. Address entries below the first routable IP address MUST be deleted. At least one address entry of the replying LSR MUST be added at the bottom of the stack. A second address entry (or more) MAY also be added if necessary, depending on implementation. The final address added MUST be an address that's reachable through the interface the Echo Request message would have been forwarded to if its TTL hadn't expired at this node. The updated Relay Node Address Stack TLV MUST be carried in the response message 🔥
If the replying LSR is configured to hide its routable address information, the address entry added to the stack MUST be a NIL entry with Address Type set to NULL 🙈
If a node spans two addressing domains (with respect to this message), where nodes on either side may not be able to reach nodes in the other domain, then the final address added SHOULD set the K bit. An ASBR node is one example of spanning two address domains 🌉
The K bit applies in the case of a NULL address. It serves as a warning to the initiator that further Echo Request messages may not result in receiving Echo Reply messages ⚠️
If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV SHOULD be included in the Echo Reply message. Other optional TLVs are excluded in that case 🫧
4.3. Originating a Relayed Echo Reply 🦋
The destination address determined as described in Section 4.2 is used as the next relay node address. If the resolved next relay node address isn't routable, then sending the Relayed Echo Reply or Echo Reply will fail 💀
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 Echo Reply message to the next relay node. Processing a Relayed Echo Reply works the same as the Echo Reply procedure in Section 4.5 of [RFC4379], except for the destination IP address and 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 Address Stack TLV. Both the source and destination UDP port are set to 3503. The updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Relayed Echo Reply message. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node 🌸
When the next relay node address is the first one in the address list, please refer to Section 4.5 💖
4.4. Relaying a Relayed Echo Reply 🦋
Okay so, when a relay node gets a Relayed Echo Reply and its OWN address is the destination in the IP header, it MUST work out the next relay node address the same way Section 4.2 describes. The one twist is that it uses the location of the received destination address instead of the bottom of the stack. 🧚 The Destination Address Offset in the Relay Node Address Stack TLV then gets set to that next relay node address. Unlike Section 4.2, the Stack of Relayed Addresses stays exactly as it is, no changes at all 💅
If the next relay node address is not the first one in the address list (so it's another intermediate relay node), the relay node MUST send a Relayed Echo Reply to that upstream node. The payload stays the same apart from the Relay Node Address Stack TLV. The TTL SHOULD be copied from the received Relay Echo Reply and then decremented by 1. The Source Address of the Replying Router field is kept unmodified, while the Source IP address field of the IP header gets set to an address of the sending node ✨
When the next relay node address is the first one in the address list, go check out Section 4.5 👑
4.5. Sending an Echo Reply 💖
The Echo Reply is sent in two cases:
- 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 (Section 4.3), the replying LSR would send an Echo Reply to the initiator. In addition to the procedure of the Echo Reply described in Section 4.5 of [RFC4379], the updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Echo Reply. 🫶
If the receiver does not recognize the Relay Node Address Stack TLV, as per Sections 3 and 4.5 of [RFC4379], it will send an Echo Reply without including the TLV. 🙈
- When the intermediate relay node receives a Relayed Echo Reply, 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 will send the Echo Reply to the initiator, and update the Message 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 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 destination UDP port will be copied from the Initiator Source 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 received Relay Echo Reply and decremented by 1. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node. 🔥
4.6. Sending Subsequent Echo Requests 🌸
During a traceroute operation, multiple Echo Request messages are sent. Each time the TTL is increased, the initiator SHOULD copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. The Relay Node Address Stack TLV MUST NOT be modified except as follows. A NIL entry that does not have the K bit set MAY be removed. A NIL entry with the K bit serves as a warning that further Echo Request messages are likely not to result in a reply. If, however, the initiator decides to continue a traceroute operation, the NIL entry with the K bit set MUST be removed. The Source Address of the Replying Router and Destination Address Offset fields may be preserved or reset since these fields are ignored in the received MPLS Echo Request. 🍓
4.7. Impact on Traceroute 🔍
The Source IP address in Echo Reply and Relay Echo Reply should be the address of the node sending those packets, not the original responding node. Then the traceroute address output module will print the source IP address as below:
if (Relay Node Address Stack TLV exists) {
Print the Source Address of Replying Router in
Relay Node Address Stack TLV;
} else {
Print the source IP address of Echo Reply message;
}5. LSP Ping Relayed Echo Reply Example 🎀
Considering the inter-AS scenario in Figure 5 below, AS1 and AS2 are two independent address domains. In the example, an LSP has been created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in AS2. 🌈
+-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------>
<--------------------------- LSP ------------------------------->
Figure 5: Example Inter-AS LSPWhen performing LSP traceroute on the LSP, the first Echo Request sent by PE1 with outermost label TTL=1 contains the Relay Node Address Stack TLV with PE1's address as the first relayed address. 🧁
After being processed by P1, P1's interface address facing ASBR1 without the K bit set will be added in the Relay Node Address Stack TLV address list following PE1's address in the Echo Reply. 🌷
PE1 copies the Relay Node Address Stack TLV into the next Echo Request when receiving the Echo Reply. 💜
Upon receiving the Echo Request, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay address. Then it deletes P1's address, and adds its interface address facing ASBR2 with the K bit set. As a result, there will be PE1's address followed by ASBR1's interface address facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply sent by ASBR1. 🦋
PE1 then sends an Echo Request with outermost label TTL=3, containing the Relay Node Address Stack TLV copied from the received Echo Reply message. Upon receiving the Echo Request message, ASBR2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR1's interface address is the next relay address in the stack TLV. ASBR2 adds its interface address facing P2 with the K bit set. Then ASBR2 sets the next relay address as the destination address of the Relayed Echo Reply and sends the Relayed Echo Reply to ASBR1. 🚀
Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay node. Then ASBR1 sends an Echo Reply to PE1. ✨
For the Echo Request with outermost label TTL=4, P2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR2's interface address is the next relay address. Then P2 sends a Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV containing four addresses: PE1's, ASBR1's interface address, ASBR2's interface address, and P2's interface address facing PE2 in sequence. 🫧
Then, according to the process described in Section 4.4, ASBR2 sends the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo Reply, ASBR1 sends an Echo Reply to PE1. And, as relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to the initiator PE1. 💅
For the Echo Request with outermost label TTL=5, the Echo Reply would relayed to PE1 by ASBR2 and ASBR1, similar to the case of TTL=4. 👑
The Echo Reply from the replying node that has no IP reachable route to the initiator is thus transmitted to the initiator by multiple relay nodes. 🌈
6. Security Considerations 🚨
Okay bestie, this part is SERIOUS. Read it like it's your group chat's most important message 😭
The Relayed Echo Reply mechanism for LSP Ping creates an increased risk of DoS by putting the IP address of a target router in the Relay Node Address Stack. These messages could then be used to attack the 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 relay node as suggested in [RFC4379]. The node that acts as a relay node SHOULD validate the relay reply against a set of valid source addresses and discard packets from untrusted border router addresses. An implementation SHOULD provide such filtering capabilities. 💀
If an operator wants to obscure their nodes, it is RECOMMENDED that they replace the replying node address that originated the Echo Reply with the NIL address entry in the 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. 🔐
The Relay Node Address Stack TLV has the path information of the LSP, and such information may be maliciously used by any uncontrolled LSR/ LER. We have two ways to reduce the path information in the TLV:
- It is recommended to clear the K bit in the relay address entry unless it must be set (e.g., as listed in Section 4.2).
- It is recommended to use the NIL address entry to hide node information, if possible.
Other security considerations discussed in [RFC4379] are also applicable to this document. 🛡️
7. Backward Compatibility 🌙
When one of the nodes along the LSP does not support the mechanism specified in this document, the node will ignore the Relay Node Address Stack TLV as described in Section 4.2. Then the initiator may not receive the Relay Node Address Stack TLV in Echo Reply message from that node. In this case, an indication should be reported to the operator, and the Relay Node Address Stack TLV in the next Echo Request message should be copied from the previous Echo Request, and continue the ping process. If the node described above is located between the initiator and the first relay node, the ping process could continue without interruption. 🍰
8. IANA Considerations 🏳️🌈
IANA has assigned one new Message Type, one new TLV, and one Return Code. ✨
8.1. MPLS Relayed Echo Reply 🧚
One new Message Type from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Message Type" subregistry has been allocated:
Value Meaning
----- -------
5 MPLS Relayed Echo ReplyThe value has been assigned from the "Standards Action" [RFC5226] range (0-191) using the lowest free value within this range.
8.2. Relay Node Address Stack TLV 🎀
One new TLV from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "TLVs" subregistry has been allocated:
Type TLV Name
---- --------
32768 Relay Node Address Stack TLVThe value has been assigned from the "Standards Action" range (32768-49161) as suggested by [RFC4379] Sections 3 and 7.2 using the first free value within this range.
8.3. MTU Exceeded Return Code 📏
The MTU Exceeded return code from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Return Codes"subregistry has been allocated:
Value Meaning
----- -------
20 One or more TLVs not returned due to MTU sizeThe value has been assigned from the "Standards Action" range (0-191) using the lowest free value within this range.
9. References 📚
9.1. Normative References
okay bestie, these are the must-reads 📚✨ the stuff you NEED before you touch anything else, no cap 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.RFC 2119 is the one that explains what the capital-letter key words actually mean, so it's the foundation for the whole thing 🌸
9.2. Informative References
these ones are more like background reading 🦋 — helpful for the bigger picture, not required to get the core stuff working 🧚
[MPLSARCH] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", Work
in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.Acknowledgements 🙏
the authors gave a massive shoutout to the people who gave valuable comments and suggestions 🫶 Carlos Pignataro, Xinwen Jiao, Manuel Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory Mirsky, Nobo Akiya, and Joel M. Halpern. iconic group of legends 👑
Contributors 💅
Ryan Zheng
JSPTPD
371, Zhongshan South Road
Nanjing 210006
China
Email: ryan.zhi.zheng@gmail.comAuthors' Addresses 🎀
the people who actually wrote this, with their contact details 💖
Jian Luo (editor)
ZTE
50, Ruanjian Avenue
Nanjing 210012
China
Email: luo.jian@zte.com.cn
Lizhong Jin (editor)
Shanghai
China
Email: lizho.jin@gmail.com
Thomas Nadeau (editor)
Brocade
Email: tnadeau@lucidvision.com
George Swallow (editor)
Cisco Systems
Email: swallow@cisco.comand that's a wrap on the whole RFC 🌈✨ you made it, bestie, we literally read the entire thing 😭🫶
📦 where this page comes from
- ietf: rfc7743 2016-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms