Relaxing IP TTL setting in MPLS Ping and traceroute

RFC 4379 suggests to set IP TTL as 1 in MPLS echo request packet for MPLS ping and traceroute. However packets with IP TTL 1 may be dropped by TTL filtering access control list deployed to mitigate TTL expiry attacks, with the assumption that legitimate packets unlikely have low TTL values. Then MPLS ping and traceroute will be inoperable in these networks. RFC 4379 suggests " The IP TTL is set to 1.", and requires that "The Router Alert option MUST be set in the IP header", and "sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or the destination address in the 127/8 address range.". Setting IP TTL as 1 isn't necessary for sending an MPLS echo request to the control plane because it's mandatory to include Router Alert option in the IP header. And it makes MPLS echo request susceptible to TTL filtering thus render it inoperable.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

For MPLS ping, the MPLS echo request will eventually be fowarded to the egress node if the fowarding path is normal. And sending the MPLS echo request to control plane at the egress node will be triggered by the Router Alert option in the IP header. And this is regardless whether IP TTL is 1 or not. For MPLS traceroute, the MPLS echo request will arrive at the transit or egress node depending on the MPLS TTL if the forwarding path is working correctly. The transit or egress nodes will send the MPLS echo request to their control plane when MPLS TTL expires. This works regardless whether IP TTL is 1 or not. If the fowarding path isn't normal, the MPLS echo request may be received by routers or hosts outside of the normal forarding path. But since the destination address is in 127/8 address range, the packet won't be forwarded according to RFC 1112 and RFC 1812, regardless whether IP TTL is 1 or not. In summary, MPLS echo request packet will get either received or discarded properly regardless IP TTL settings, as long as it has a valid value.

It's proposed that IP TTL MAY be set to non-zero values other than 1. For example, it could be set to 255 by default. Routers SHOULD NOT expect IP TTL to be a specific value on receving MPLS echo request packet. And routers SHOULD process MPLS echo request packet according to RFC 4379 as long as IP TTL is not zero.

While sending MPLS echo request, IP TTL MAY be set to any non-zero value. It's RECOMMENDED to set IP TTL to a larger value (e.g. 255) to avoid the MPLS echo request being filtered by TTL-filtering access control lists deployed to mitigate TTL expiry attacks.

On receiving MPLS echo request, fowarding plane SHOULD NOT expect a specific value of IP TTL as long as it's not zero. Routers MAY choose to discard MPLS echo request packet with IP TTL 0 according to their general IP TTL processing rules.

This memo includes no request to IANA.

Setting IP TTL to non-zero values other than 1 in MPLS echo request doesn't introduce new security concerns. The MPLS echo request will be received or discarded properly for both normal and abnormal forwarding paths. Setting IP TTL to non-zero values other than 1 allows MPLS ping and traceroute to function properly even if there are TTL-filtering rules deployed to mitigate TTL expiry attacks.