Skip to content
Permalink
master
Switch branches/tags
Go to file
 
 
Cannot retrieve contributors at this time
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<?rfc strict="yes"?>
<rfc category="std" docName="draft-ytti-intarea-proxy-trace-00">
<front>
<title abbrev="Proxy Trace">
Proxy Trace: A Utility for Programmatic Discovery of Forward and Reverse Path
</title>
<author fullname="Saku Ytti" initials="S." surname="Ytti">
<organization abbrev="NTT">NTT Communications</organization>
<address>
<email>ytti@ntt.net</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>intarea</workgroup>
<keyword>ProxyTrace</keyword>
<abstract>
<t>
This document describes a network diagnostic tool called Proxy Trace.
Proxy Trace has similarities with PING and TRACEROUTE in that it uses PING style ICMP request to ask the remote host to trigger a single packet TRACEROUTE query and deliver the reply in PING style ICMP reply.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Network operators use TRACEROUTE to discover the path between the client host and a target host.
An Operator does this by running the traceroute software on the client host and giving as an argument target host to which operator wants to discover the network path.
This information helps network operator to understand and troubleshoot issues on the network.
</t>
<t>
This document describes a network diagnostic tool called Proxy Trace.
Proxy Trace is similar to TRACEROUTE in that it can be used to discover path between two hosts, but it differs from TRACEROUTE in that it can discover the path between two arbitrary hosts, allowing operator not only discover the reverse path but also removes the requirement that the operator must have access to a host in the path.
</t>
<t>
Further unlike alternative solutions such as looking glasses, Proxy Trace replies are formal and machine parseable.
This enables programmatic discovery of both directions of the path.
Motivation for Proxy Trace is to reduce outage times by reducing the time it takes to identify the issue, while also enabling programmatic identification and recovery of an outage.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>
This document uses the following terms:
<list style="hanging">
<t hangText="Proxy Trace Request:">
An ICMP packet Proxy Trace Client sends to a Proxy Trace Server.
</t>
<t></t>
<t hangText="Proxy Trace Reply:">
An ICMP packet Proxy Trace Server sends to a Proxy Trace Client.
</t>
<t></t>
<t hangText="Proxy Trace Client:">
Client host requesting for a Proxy Trace
</t>
<t></t>
<t hangText="Proxy Trace Server:">
Server listening to a Proxy Trace Requests, sending Proxy Trace Probe Request, receiving Proxy Trace Probe Reply and sending Proxy Trace Reply
</t>
<t></t>
<t hangText="Proxy Trace Target:">
Destination address of the Proxy Trace Probe Request
</t>
<t></t>
<t hangText="Proxy Trace Probe Request:">
Packet Proxy Trace Server sends towards the Proxy Trace Target.
Equivalent to the packet generated by TRACEROUTE
</t>
<t></t>
<t hangText="Proxy Trace Probe Reply:">
Packet received from the network as a reply to the Proxy Trace Probe Request, usually ICMP TTL Exceeded or ICMP Host Unreachable message
</t>
</list>
</t>
</section>
<section anchor="operation" title="Operation">
<figure anchor="topology" align="center"><artwork><![CDATA[
+-----------+
| PT Client |
+-----------+
|
~~~~~~~~~~~~
~ internet ~
~~~~~~~~~~~~
|
+-----------+ +------+ +------+ +-------+ +-----------+
| PT Server |----| Hop1 |----| Hop2 |----| Hop3 |---| PT Target |
+-----------+ +------+ +------+ +-------+ +-----------+
]]></artwork></figure>
<t>
In the attached diagram PT Client wants to discover the path from PT Server to a PT Target.
The same process is repeated for each Hop:
<list style="hanging">
<t hangText="Send Proxy Trace Request:">
PT Client sends Proxy Trace Request to PT Server with Hop-Limit '1' and Destination Address 'PT Target'.
</t>
<t></t>
<t hangText="Receive Proxy Trace Request:">
PT Server receives Proxy Trace Request, verifies its size and TLVs.
</t>
<t></t>
<t hangText="Send Proxy Trace Probe Request:">
PT Server sends Proxy Trace Probe Request towards PT Target out from the Interface where FIB informs PT Target to be located. PT Server SHOULD use the same FIB for Proxy Trace Probe Request as where it received the Proxy Trace Request.
</t>
<t></t>
<t hangText="Receive Proxy Trace Probe Request:">
Hop1 received the Proxy Trace Probe Request, because TTL has expired it punts the packet from data-plane to control-plane.
</t>
<t></t>
<t hangText="Send Proxy Trace Probe Reply:">
Hop1 sends ICMP TTL Exceeded message to the PT Server
</t>
<t></t>
<t hangText="Receive Proxy Trace Probe Reply:">
PT Server received the Proxy Trace Probe Reply and relates it to the open Proxy Trace Request.
</t>
<t></t>
<t hangText="Send Proxy Trace Reply:">
PT Server generates Proxy Trace Reply message and adds Proxy Trace Probe Reply packet as TLV 0 to the Proxy Trace Reply message.
PT Server sends the Proxy Trace Reply message to the PT Client.
</t>
<t></t>
<t hangText="Receive Proxy Trace Reply:">
PT Client receives the Proxy Trace Reply from PT Server learning that Hop Limit 1 in the path between PT Server and PT Target it Hop1
</t>
</list>
</t>
<t>
PT Client is free to send multiple Proxy Trace Request messages without waiting for a Proxy Trace Reply message.
</t>
</section>
<section anchor="request" title="ICMP Proxy Trace Request">
<t>
The ICMP Proxy Trace Request is defined for both ICMPv4 and ICMPv6.
Like any ICMP message, the ICMP Proxy Trace Request is encapsulated in an IP header.
The ICMPv4 version of the ICMP Proxy Trace Request message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
ICMP Proxy Trace Request message's minimum size on IPv4 level is 576B and on IPv6 level 1280B.
</t>
<t>
Figure 2. depicts the ICMP Proxy Trace Request message.
</t>
<figure anchor="requestencoding" align="center"><artwork><![CDATA[
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Proxy Trace Request TLV Structure
]]></artwork></figure>
<t>
IP Header fields:
<list style="hanging">
<t hangText="Source Address:">
The Source Address identifies the Proxy Trace Client.
It MUST be a valid IPv4 or IPv6 unicast address.
</t>
<t></t>
<t hangText="Destination Address:">
The Destination Address identifies the Proxy Trace Server.
It MUST be a valid IPv4 or IPv6 unicast address.
</t>
</list>
</t>
<t></t>
<t>
ICMP fields:
<list style="hanging">
<t hangText="Type:">
Proxy Trace Request.
The value for ICMPv4 is FIX44.
The value for ICMPv6 is FIX162.
</t>
<t></t>
<t hangText="Code:">
MUST be set to 0 and MUST be ignored upon receipt.
</t>
<t></t>
<t hangText="Checksum:">
For ICMPv4, see <xref target="RFC0792" />. For ICMPv6, see <xref target="RFC4443" />.
</t>
<t></t>
<t hangText="Identifier:">
And Identifier to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests.
May be 0.
See <xref target="RFC0792" /> Echo/Echo Reply.
</t>
<t></t>
<t hangText="Sequence Number:">
A Sequence Number to aid in matching ICMP Proxy Trace Replies to ICMP PRoxy Trace Requests.
May be 0.
See <xref target="RFC0792" /> Echo/Echo Reply.
</t>
<t></t>
</list>
</t>
<t>
TLVs:
<list style="hanging">
<t hangText="Padding:">
Client added padding to reach the desired Proxy Trace Request mesages size.
Padding Length is set to 0 both to remove possibility of using it as a packet size verification method and to remove possibility of adding TLV after it.
Length field may be omitted if 2 byte of padding is sufficient.
Implementation being aware of packet size can stop reading after it has read Type value.
<list style="hanging">
<t hangText="Type:">0</t>
<t hangText="Length:">0</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Honor:">Yes</t>
<t hangText="Location:">Last</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Source Address:">
Source Address of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">1</t>
<t hangText="Length:">4 for IPv4 and 16 for IPv6</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">Destination Address of ICMP Proxy Trace Request</t>
</list>
</t>
<t></t>
<t hangText="Destination Address:">
Destination Address of the Proxy Trace Probe Request mesasge.
<list style="hanging">
<t hangText="Type:">2</t>
<t hangText="Length:">4 for IPv4 and 16 for IPv6</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Honor:">Opt-Out</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">Source Address of ICMP Proxy Trace Request</t>
</list>
</t>
<t></t>
<t hangText="Hop Limit:">
Hop Limit of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">3</t>
<t hangText="Length:">1 Byte</t>
<t hangText="Value:">1-255, NOT 0</t>
<t hangText="Times:">1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Honor:">Yes</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="IP Protocol:">
IP Protocol number of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">4</t>
<t hangText="Length:">1 Byte</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">17 (UDP)</t>
</list>
</t>
<t></t>
<t hangText="Source Port:">
L4 Source Port number of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">5</t>
<t hangText="Length:">2 Bytes</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">49200 from the Ephemeral Port Range (<xref target="RFC6056" />)</t>
</list>
</t>
<t></t>
<t hangText="Destination Port:">
L4 Destination Port number of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">6</t>
<t hangText="Length:">2 Bytes</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">33688 + hop-limit (33689-33943)</t>
</list>
</t>
<t></t>
<t hangText="Payload Length:">
Payload Length in bytes of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">7</t>
<t hangText="Length:">2 Bytes</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">26 for IPv4 and 38 for IPv6</t>
</list>
</t>
<t></t>
<t hangText="Traffic Class:">
Traffic Class byte of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">8</t>
<t hangText="Length:">1 Byte</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">Local choice</t>
</list>
</t>
<t></t>
<t hangText="Bit Pattern:">
Bit Pattern of a payload of the Proxy Trace Probe Request message.
<list style="hanging">
<t hangText="Type:">9</t>
<t hangText="Length:">Any, the implementation MAY choose to limit arbitrarily what it accepts</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">See Proxy Trace Probe Request Payload section</t>
</list>
</t>
<t></t>
<t hangText="Flow Label:">
IPv6 20b Flow Label
<list style="hanging">
<t hangText="Type:">10</t>
<t hangText="Length:">3 Bytes</t>
<t hangText="Value:">Any, four most significant bits are ignored</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Honor:">Opt-In</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">0</t>
</list>
</t>
<t></t>
<t hangText="Future Use:">
<list style="hanging">
<t hangText="Type:">11-59999</t>
</list>
</t>
<t></t>
<t hangText="Local Use:">
<list style="hanging">
<t hangText="Type:">60000-65535</t>
</list>
</t>
<t></t>
</list>
</t>
</section>
<section anchor="reply" title="ICMP Proxy Trace Reply">
<t>
The ICMP Proxy Trace Reply is defined for both ICMPv4 and ICMPv6.
Like any ICMP message, the ICMP Proxy Trace Reply is encapsulated in an IP header.
The ICMPv4 version of the ICMP Proxy Trace Reply message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
</t>
<t>
Figure 3. depicts the ICMP Proxy Trace Reply message.
</t>
<figure anchor="replyencoding" align="center"><artwork><![CDATA[
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Proxy Trace Reply TLV Structure
]]></artwork></figure>
<t>
IP Header fields:
<list style="hanging">
<t hangText="Source Address:">
The Source Address identifies the Proxy Trace Server.
It MUST be a valid IPv4 or IPv6 unicast address.
</t>
<t></t>
<t hangText="Destination Address:">
The Destination Address identifies the Proxy Trace Client.
It MUST be a valid IPv4 or IPv6 unicast address.
</t>
</list>
</t>
<t></t>
<t>
ICMP fields:
<list style="hanging">
<t hangText="Type:">
Proxy Trace Reply.
The value for ICMPv4 is FIX45.
The value for ICMPv6 is FIX163.
</t>
<t></t>
<t hangText="Code:">
MUST be set to 0 and MUST be ignored upon receipt.
</t>
<t></t>
<t hangText="Checksum:">
For ICMPv4, see <xref target="RFC0792" />.
For ICMPv6, see <xref target="RFC4443" />.
</t>
<t></t>
<t hangText="Identifier:">
And Identifier to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests.
May be 0.
See <xref target="RFC0792" /> Echo/Echo Reply.
</t>
<t></t>
<t hangText="Sequence Number:">
A Sequence Number to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests.
May be 0.
See <xref target="RFC0792" /> Echo/Echo Reply.
</t>
<t></t>
</list>
</t>
<t>
TLVs:
<list style="hanging">
<t hangText="Proxy Trace Probe Reply message:">
The ICMP TTL exceeded or Unreachable Message Server received, verbatim.
Includes extension objects such as <xref target="RFC4950" /> and <xref target="RFC5837" />.
<list style="hanging">
<t hangText="Type:">0</t>
<t hangText="Length:">Any</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Proxy Trace Probe Request Timestamp:">
Timestamp of Proxy Trace Probe Request leaving the Proxy Trace Server
<list style="hanging">
<t hangText="Type:">1</t>
<t hangText="Length:">6 Bytes</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Proxy Trace Probe Reply Timestamp:">
Timestamp of Proxy Trace Probe Reply arriving at the Proxy Trace Server
<list style="hanging">
<t hangText="Type:">2</t>
<t hangText="Length:">6 Bytes</t>
<t hangText="Value:">Any</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Optional</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Honored TLV:">
If Proxy Trace Request contains one or more TLVs which implementations does not support or does not honor, implementation responds with list of honored TLVs
<list style="hanging">
<t hangText="Type:">401</t>
<t hangText="Length:">Any</t>
<t hangText="Value:">2 bytes per Honored TLV</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Bad TLV Count:">
List of TLV type numbers occurring more or less time than expected
<list style="hanging">
<t hangText="Type:">402</t>
<t hangText="Length:">Any</t>
<t hangText="Value:">2 bytes per Bad TLV</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Bad TLV Length:">
List of TLV type numbers having Length implementation rejects as valid
<list style="hanging">
<t hangText="Type:">403</t>
<t hangText="Length:">Any</t>
<t hangText="Value:">2 bytes per Bad TLV</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Bad TLV Value:">
List of TLV type numbers having Value implementation rejects as valid
<list style="hanging">
<t hangText="Type:">404</t>
<t hangText="Length:">Any</t>
<t hangText="Value:">2 bytes per Bad TLV</t>
<t hangText="Times:">0 or 1</t>
<t hangText="Implementation:">Mandatory</t>
<t hangText="Location:">Any</t>
<t hangText="Default:">None</t>
</list>
</t>
<t></t>
<t hangText="Future Use:">
<list style="hanging">
<t hangText="Type:">7-59999</t>
</list>
</t>
<t></t>
<t hangText="Local Use:">
<list style="hanging">
<t hangText="Type:">60000-65535</t>
</list>
</t>
<t></t>
</list>
</t>
</section>
<section anchor="proberequestpayload" title="Proxy Trace Probe Request Payload">
<t>
<figure anchor="proxytraceproberequestpayload" align="center"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Payload Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Hash | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
]]></artwork></figure>
</t>
<t>
Proxy Trace Probe Request Payload Fields:
<list style="hanging">
<t hangText="Timestamp:">6B timestamp, as documented in the TIMESTAMP section</t>
<t hangText="Identifier:">2B Identifier from the Proxy Trace Request Message</t>
<t hangText="Sequence Number:">2B Sequence Number from the Proxy Trace Request Message</t>
<t hangText="Payload Hash:">4B hash of the Proxy Trace Probe Request Payload Fields + Local Secret</t>
<t hangText="Source Address">4B or 16B Source Address from the Proxy Trace Request</t>
</list>
</t>
</section>
<section anchor="stateless" title="Stateless Operation">
<t>
Implementation MAY choose to do an entirely stateless Proxy Trace Server implementation.
The benefit of stateless implementation is that it is friendly towards implementation in the hardware.
Stateless implementation MUST use Payload Hash to verify Proxy Trace Probe Reply for correctness, otherwise an unsolicited Proxy Trace Probe Reply message may create 52B amplification, with hash verification there is 1:4294967296 attenuation for the unsolicited Proxy Trace Probe Reply messages.
Implication of stateless operation is that the Proxy Trace Probe Reply message must contain the original Proxy Trace Probe Request up-to the Source Address, otherwise payload hash verification will fail.
This further implies that for IPv4 the host sending the Proxy Trace Probe Reply message needs to support <xref target="RFC4884"/> for stateless operation to function.
Proxy Trace Server using stateless operation has no obligation to function when Proxy Trace Probe Reply message does not facilitate stateless operation, more specifically there is no requirement for stateful operation as a fallback.
</t>
</section>
<section anchor="timestamp" title="Timestamp format">
<t>
The timestamp should be 6 bytes or 48 bits wide, most significant bit is a flag called 'non-canonical epoch'.
If 'non-canonical epoch' flag is not set timestamp's epoch is UTC midnight, if 'non-canonical epoch' flag is set then epoch is unspecified but not UTC midnight.
Timestamp unit is nanoseconds.
</t>
</section>
<section anchor="icmp" title="ICMP Message Processing">
<t>
When a host receives an ICMP Proxy Trace Request message and any of the following conditions apply, the node MUST silently discard the incoming message:
</t>
<t>
<list style="symbols">
<t>
The node does not recognize ICMP Proxy Trace Request messages.
</t>
<t>
The node has disabled the ICMP Proxy Trace Request functionality.
</t>
<t>
The incoming ICMP Proxy Trace Request message is too small.
</t>
<t>
The Source Address of the incoming message is not a unicast address.
</t>
<t>
The Destination Address of the incoming message is a multicast address.
</t>
</list>
</t>
<t>
Discard SHOULD happen in the date-plane
</t>
<t>
Otherwise, when a node receives an ICMPv4 Proxy Trace Request, it MUST format an ICMPv4 Proxy Trace Reply as follows:
</t>
<t>
<list style="hanging">
<t hangText="Don't Fragment (DF) flag:">1</t>
<t hangText="More Fragments flag:">0</t>
<t hangText="Fragment Offset:">0</t>
<t hangText="TTL:">255</t>
<t hangText="Protocol:">ICMP</t>
</list>
</t>
<t>
When a node receives an ICMPv6 Proxy Trace Request, it MUST format an ICMPv6 Proxy Trace Reply as follows:
</t>
<t>
<list style="hanging">
<t hangText="Hop Limit:">255</t>
<t hangText="Next Header:">ICMPv6</t>
</list>
</t>
<t>
In either case, the responding node MUST do the following:
</t>
<t>
<list style="symbols">
<t>
Copy the Source Address from the Proxy Trace Request message to the Destination Address of the Proxy Trace Reply message.
</t>
<t>
Copy the Destination Address from the Proxy Trace Request message to the Source Address of the Proxy Trace Reply message.
</t>
<t>
Set the ICMP Type to Proxy Trace Reply.
</t>
<t>
Copy the Identifier from the Proxy Trace Request message to the Proxy Trace Reply message.
</t>
<t>
Copy the Sequence Number from the Proxy Trace Request message to the Proxy Trace Reply message.
</t>
<t>
Set the Code field to 0.
</t>
<t>
Set the Checksum appropriately.
</t>
<t>
Set the TLVs appropriately.
</t>
<t>
Forward the Proxy Trace Reply to the Proxy Trace Client.
</t>
</list>
</t>
</section>
<section anchor="implementation" title="Implementation Considerations">
<t>
A host implementing Proxy Trace SHOULD have it turned on by default in all interfaces and MUST allow turning it off/on per interface.
The implementation MUST police rate of received Proxy Trace Request messages at the data-plane to 1000 pps, implementation SHOULD allow policer to be configured.
</t>
<t>
Proxy Trace Server SHOULD timeout after 1 second of waiting for a Proxy Trace Probe Reply message and MAY timeout earlier.
Proxy Trace Server SHOULD NOT send Proxy Trace Reply message if it timed out.
</t>
</section>
<section anchor="errorhandling" title="Error Handling">
<t>
Proxy Trace Server encountering any problem in the Proxy Trace Request message MUST not send any Proxy Trace Probe Reqeust message out and SHOULD send Proxy Trace Reply message to the Proxy Trace Client informing of the issue.
Proxy Trace Server may give up parsing the Proxy Trace Request message after one or more problems.
</t>
<t>
Proxy Trace Server receiving too small Proxy Trace Request message should silently discard it in the data-plane.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
Per this document, IANA is requested to reference this document in the "Internet Control Message Control (ICMP) Parameters" and the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registries under the "Code Fields" group.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Allowing the client to set arbitrary Payload will create amplification potential.
</t>
<t>
Allowing the client to define Protocol, Port and Bit Pattern allows client to craft arbitrary packets enabling it to perform port knocking and trigger packet-of-death bugs.
</t>
<t>
Opt-In Request TLVs should only be honored in trusted networks.
</t>
<t>
By default, unlike ICMP Echo, there is bps attenuation because the Proxy Request messages are much larger than the Proxy Trace Probe Request and the Proxy Trace Probe Reply messages.
</t>
<t>
By default there is potentially 2 x pps amplification, however this is a minor concern as other more common vectors, such as TCP SYN spoofing allow for much higher pps amplification.
</t>
<t>
There is no way for the Client to cause the Server to send more than two packets per each packet the Client sends.
</t>
<t>
Other than gleaning information about UDP TRACEROUTE ports, there are no security implications identified in setting the destination address TLV.
Attacker setting the destination address TLV will necessarily create less traffic towards the victim compared to not setting the destination address TLV and spoofing the source address.
Without setting the destination address TLV Attacker will be able to send two packets to a single Victim, whereas by setting the destination address TLV Attacker can only send one packet per victim.
</t>
<t>
Precedent exists in <xref target="RFC8335"/> where we can ask the server to return information to us which would normally not be visible to us.
Like every packet received on control-plane there are always risks involved in software defects, however we need to balance the cost of those risks with the cost savings afforded by diagnostic tools due to reduced outage times.
Historically we have had security issues in ICMP Echo, including f00fc7c8 and +++ATH, but we continue to utilize ICMP Echo because the perceived diagnostic value in reducing outage times exceeds the perceived risk carried.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4443"?>
<?rfc include="reference.RFC.8174"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4884"?>
<?rfc include="reference.RFC.4950"?>
<?rfc include="reference.RFC.5837"?>
<?rfc include="reference.RFC.6056"?>
<?rfc include="reference.RFC.8335"?>
</references>
<section anchor="acknowledgments" title="Acknowledgments">
<t>
</t>
</section>
</back>
</rfc>