ietf-corpus

rfc-7743

Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping

J. Luo (Editor), L. Jin (Editor), T. Nadeau (Editor), G. Swallow (Editor)
date2016-01 streamIETF areartg wgmpls statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc7743 doi10.17487/RFC7743
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

updates

Extracted elements (26)

design-rationale §2

In inter-AS and inter-area deployments, the replying LSR in one AS may have no routable path back to the Echo Request initiator in another AS, causing Echo Reply messages to be discarded and LSP Ping/Traceroute to fail with false negatives. The Relayed Echo Reply mechanism introduces relay nodes (e.g., ASBRs) to forward the reply hop-by-hop until the initiator is reached.

mpls, multicast

design-rationale §3.2

The K bit in a relay node address entry is introduced to mark addresses that must be preserved throughout the traceroute operation. Without such a flag, intermediate relay nodes at AS boundaries (ASBRs) could be optimized away from the stack, breaking the relay chain on subsequent Echo Requests with higher TTLs.

mpls

interoperability-note §7

The Relay Node Address Stack TLV type (32768) falls in the RFC 4379 optional TLV range that nodes silently ignore if unrecognized. When a non-supporting node is encountered, the initiator will not receive the TLV in the Echo Reply; an indication SHOULD be reported and the TLV from the previous Echo Request SHOULD be copied forward to continue the ping.

mpls

interoperability-note §3

This document is scoped to LSPs using a uniform IP address family across all hops; mixed paths with some IPv4-only and some IPv6-only nodes are explicitly out of scope. All relay addresses in the stack must use the same address family.

mpls, ip

interoperability-note §4.7

Traceroute output must be modified: if a Relay Node Address Stack TLV is present, the displayed hop address MUST be the Source Address of Replying Router field from the TLV (the original responder), not the source IP address of the packet carrying the Echo Reply (which may be a relay node).

mpls

normative-requirement §3.3 MUST

Before sending an Echo Reply, if Best-return-code is 3 (egress for FEC) or 8 (label switched at stack-depth) and the packet size exceeds MTU, Best-return-code MUST be set to 20 (MTU Exceeded). If the full reply would exceed MTU, the Relay Node Address Stack TLV SHOULD still be included while other optional TLVs are excluded.

mpls

normative-requirement §4.6 MUST NOT

During traceroute, the initiator SHOULD copy the Relay Node Address Stack TLV from the received Echo Reply into each subsequent Echo Request. The TLV MUST NOT be modified except: a NIL entry without the K bit MAY be removed; a NIL entry with the K bit MUST be removed only if the initiator decides to continue despite the implied warning.

mpls

normative-requirement §4.2 SHOULD

If an LSR spans two addressing domains (e.g., an ASBR), the final address entry added to the stack SHOULD set the K bit to ensure that entry persists as a relay node across the entire traceroute operation.

mpls

normative-requirement §3.2 MUST

The Relay Node Address Stack TLV MUST be carried in Echo Request, Echo Reply, and Relayed Echo Reply messages when the Echo Reply relay mechanism is required.

mpls

normative-requirement §4.2 MUST

Upon receiving an Echo Request with the TLV, the receiver MUST update the Source Address of Replying Router to match the source IP address of the reply it will send. Address entries with the K bit set MUST be kept in the stack.

mpls

normative-requirement §4.5 MUST

When an intermediate relay node sends the final Echo Reply to the initiator (converting from Relayed Echo Reply to Echo Reply), the destination UDP port MUST be copied from the Initiator Source Port field of the TLV, the source UDP port MUST be 3503, and the Message Type field MUST be updated from Relayed Echo Reply (5) to Echo Reply (2).

mpls

normative-requirement §4.3 MUST

When originating a Relayed Echo Reply (i.e., the first address in the stack is not the next relay), the replying LSR SHOULD send a Relayed Echo Reply (Message Type 5) to the next relay node address. The destination IP is the next relay node address, and both source and destination UDP ports MUST be 3503. The updated Relay Node Address Stack TLV MUST be carried in the Relayed Echo Reply.

mpls

normative-requirement §4.2 MUST

When processing the Relay Node Address Stack TLV on receipt of an Echo Request, the receiver MUST scan from bottom to top for the last K-bit-set entry (or use top-of-stack if none), then scan downward from there to find the first routable IP address; that entry becomes the Destination Address Offset. Address entries below the first routable address MUST be deleted, and at least one address entry for the replying LSR MUST be added at the bottom.

mpls

normative-requirement §4.4 MUST

When relaying a Relayed Echo Reply, the relay node MUST determine the next relay address using the Destination Address Offset as the starting position (not the bottom of stack). If the next relay is not the initiator, the relay node MUST forward the Relayed Echo Reply with payload unchanged except for the updated TLV. The TTL SHOULD be copied from the received message and decremented by 1.

mpls

normative-requirement §4.1 MUST

When the initiator sends the first Echo Request with a Relay Node Address Stack TLV, the TLV MUST contain the initiator's address as the first stack entry with the Destination Address Offset pointing to that entry, the source address of the replying router set to null, and the Initiator Source Port field MUST be set to the source UDP port.

mpls

protocol-element §3.1

A new Message Type 5 (MPLS Relayed Echo Reply) is defined. It is a UDP packet using port 3503 (same as RFC 4379 LSP Ping), with the same payload format as Echo Request/Reply, used by a replying LSR when sending to an intermediate relay node rather than directly to the initiator.

mpls

protocol-element §3.3

The MTU Exceeded Return Code (value 20) indicates that one or more TLVs were omitted from an Echo Reply or Relayed Echo Reply to avoid exceeding the effective MTU. Omitted TLVs MAY appear in an Errored TLV object with length set to 0; the return sub-code MUST be set to the value that would otherwise have been sent.

mpls

protocol-element §3.2

The Relay Node Address Stack TLV (Type 32768, assigned from the 32768–49161 optional range) carries the ordered list of relay node IP addresses plus the initiator source port, the replying router source address, and a Destination Address Offset indicating the current next-hop relay. It is optional but MUST be present whenever the relay mechanism is in use.

mpls

registry §8.1

IANA assigned Message Type value 5 (MPLS Relayed Echo Reply) in the 'Message Type' subregistry of the 'Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters' registry, allocated from the Standards Action range 0–191.

mpls, registry

registry §8.3

IANA assigned Return Code value 20 ('One or more TLVs not returned due to MTU size') in the 'Return Codes' subregistry of the 'MPLS LSPs Ping Parameters' registry, allocated from the Standards Action range 0–191.

mpls, registry

registry §8.2

IANA assigned TLV Type 32768 (Relay Node Address Stack TLV) in the 'TLVs' subregistry of the 'MPLS LSPs Ping Parameters' registry, allocated from the Standards Action range 32768–49161 as suggested by RFC 4379.

mpls, registry

security-consideration §6 MAY

A receiver of an MPLS Echo Request MAY verify that the first address in the Relay Node Address Stack TLV matches the source IP address of the received IP header as an integrity check against spoofed or malformed relay stacks.

mpls, security

security-consideration §6 SHOULD

The Relay Node Address Stack TLV exposes the LSP path topology. To mitigate this, the K bit SHOULD only be set when required (e.g., at AS boundaries), and NIL address entries SHOULD be used to hide node identities where possible. Operators wishing to obscure their nodes SHOULD replace the originating Echo Reply node's address with a NIL entry.

mpls, security, privacy

security-consideration §6 SHOULD

The Relayed Echo Reply mechanism increases DoS risk because an attacker can place a target router's IP in the Relay Node Address Stack, causing it to be overwhelmed with relay traffic. A rate limiter SHOULD be applied to the well-known UDP port 3503 on relay nodes, and relay nodes SHOULD validate source addresses against a set of trusted border router addresses.

mpls, security

wire-format §3.2

Each relay node address entry in the stack contains: Address Type (1 octet, 0=Null/1=IPv4/2=IPv6), K flag bit and Reserved (1 octet), Reserved (2 octets, MUST be zero), and the Relayed Address (0, 4, or 16 octets). Entry sizes are 4 bytes (Null), 8 bytes (IPv4), or 20 bytes (IPv6).

mpls

wire-format §3.2

The Relay Node Address Stack TLV header contains: Type (2 octets, value 32768), Length (2 octets), Initiator Source Port (2 octets), Reply Address Type (1 octet, 0=Null/1=IPv4/2=IPv6), Reserved (1 octet, MUST be zero), Source Address of Replying Router (0, 4, or 16 octets), Destination Address Offset (2 octets), Number of Relayed Addresses (2 octets), followed by the Stack of Relayed Addresses.

mpls