]> Arista Networks

5453 Great America Parkway Santa Clara California 95054 USA fenner@fenron.com

Arista Networks

Global Tech Park Bangalore Karnataka 560103 India reji.thomas@arista.com

Verizon

22001 Loudoun County Parkway Ashburn Virginia 20147 USA chris.lenart@verizon.com

Internet Engineering Steering Group int-area Ping This document specifies a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Internet Area Area mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Network operators use PING to test bidirectional connectivity between two interfaces. For the purposes of this document, these interfaces are called the probing and probed interfaces. PING sends an ICMP Echo Request message from the probing interface to the probed interface. The probing interface resides on a probing node while the probed interface resides on a probed node. If the probed interface receives the ICMP Echo Request message, it returns an ICMP Echo Reply. When the probing interface receives the ICMP Echo Reply, it has verified bidirectional connectivity between the probing and probed interfaces. Specifically, it has verified that:

• The probing node can reach the probed interface.
• The probed interface is active.
• The probed node can reach the probing interface.
• The probing interface is active.

This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. A list of use cases for this characteristic can be found in of this document. Like PING, PROBE executes on a probing node. It sends an ICMP Extended Echo Request message from a local interface, called the probing interface, to a proxy interface. The proxy interface resides on a proxy node. The ICMP Extended Echo Request contains an ICMP Extension Structure and the ICMP Extension Structure contains an Interface Identification Object. The Interface Identification Object identifies the probed interface. The probed interface can reside on or be directly connected to the proxy node. When the proxy interface receives the ICMP Extended Echo Request, the proxy node executes access control procedures. If access is granted, the proxy node determines the status of the probed interface and returns an ICMP Extended Echo Reply message. The ICMP Extended Echo Reply indicates the status of the probed interface. If the probed interface resides on the proxy node, PROBE determines the status of the probed interface as it would determine its oper-status. If oper-status is equal to 'up' (1), PROBE reports that the probed interface is active. Otherwise, PROBE reports that the probed interface is inactive. If the probed interface resides on a node that is directly connected to the proxy node, and the probed interface appears in the IPv4 Address Resolution Protocol (ARP) table or IPv6 Neighbor Cache, PROBE reports interface reachability. Otherwise, PROBE reports that the table entry does not exist.

Terminology This document uses the following terms:

• Probing interface: The interface that sends the ICMP Extended Echo Request.
• Probing node: The node upon which the probing interface resides.
• Proxy interface: The interface to which the ICMP Extended Echo Request message is sent.
• Proxy node: The node upon which the proxy interface resides.
• Probed interface: The interface whose status is being queried.
• Probed node: The node upon which the probed interface resides. If the proxy interface and the probed interface reside upon the same node, the proxy node is also the probed node. Otherwise, the proxy node is directly connected to the probed node.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

A note on this document's use of ICMP Extensions This document defines a unique use of ICMP Extensions . Normally, ICMP Extensions are defined to start at a given point and continue to the end of the packet. However, when the extension object is an Interface Identification Object as defined in this memo, the extension structure (including the checksum) consists only of that single ICMP Extension Object. This is done to maintain compatibility with the initial set of implementations of RFC8335, which behave this way. The ICMP Extension Structure checksum covers only the Interface Identification Object. Any data following it is not covered by this checksum but is covered by the ICMP header checksum, which protects the entire ICMP message (see for further discussion). New uses of ICMP Extensions, and in fact uses of Extended Echo using some object other than the Interface Identification Object, SHOULD NOT behave this way. Uses other than defined in this memo SHOULD treat the ICMP Extension Structure as extending to the end of the packet as defines.

ICMP Extended Echo Request The ICMP Extended Echo Request message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Request message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Request message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header. depicts the ICMP Extended Echo Request message.

ICMP Extended Echo Request Message

IP Header fields:

• Source Address: The Source Address identifies the probing interface. It MUST be a valid IPv4 or IPv6 unicast address.
• Destination Address: The Destination Address identifies the proxy interface. It MUST be a unicast address.

ICMP fields:

• Type: Extended Echo Request. The value for ICMPv4 is 42. The value for ICMPv6 is 160.
• Code: MUST be set to 0 and MUST be ignored upon receipt.
• Checksum: For ICMPv4, see . For ICMPv6, see .
• Identifier: An Identifier to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.
• Sequence Number: A Sequence Number to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.
• Reserved: This field MUST be set to 0 and ignored upon receipt.
• L (local): The L-bit is set if the probed interface resides on the proxy node. The L-bit is clear if the probed interface is directly connected to the proxy node.
• ICMP Extension Structure: The ICMP Extension Structure contains an Interface Identification Object that identifies the probed interface. The checksum in the ICMP Extension structure covers the Interface Identification Object but not any (optional) data that follows.

Section 7 of defines the ICMP Extension Structure. As per RFC 4884, the Extension Structure contains exactly one Extension Header followed by one or more objects. When applied to the ICMP Extended Echo Request message, the Extension Object(s) define the operation to perform. In the PROBE application, the ICMP Extension Structure MUST contain exactly one instance of the Interface Identification Object, and the ICMP Extension Structure does not cover the rest of the packet; it ends at the end of the single Interface Identification Object, and what follows is simply optional data. The behavior when it contains a different Extension Object is not defined by this memo. is an example of a document which defines a different Extension Object and the corresponding behavior. If the L-bit is set, the Interface Identification Object can identify the probed interface by name, index, or address. If the L-bit is clear, the Interface Identification Object MUST identify the probed interface by address. If the Interface Identification Object identifies the probed interface by address, that address can be a member of any address family. For example, an ICMPv4 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4 or IPv6 address. Likewise, an ICMPv6 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4 or IPv6 address. The Interface Identification Object MAY be followed by an optional data section, which is not interpreted but is simply present to be copied to the ICMP Extended Echo Reply. The size of the resulting packet MUST NOT exceed the outgoing interface MTU.

Interface Identification Object The Interface Identification Object identifies the probed interface by name, index, or address. Like any other ICMP Extension Object, it contains an Object Header and Object Payload. The Object Header contains the following fields:

• Class-Num: Interface Identification Object. The value is 3.
• C-Type: Values are (1) Identifies Interface by Name, (2) Identifies Interface by Index, and (3) Identifies Interface by Address.
• Length: Length of the object, measured in octets, including the Object Header and Object Payload.

If the Interface Identification Object identifies the probed interface by name, the Object Payload MUST be the interface name as defined in . If the Object Payload would not otherwise terminate on a 32-bit boundary, it MUST be padded with ASCII NUL characters, adjusting the Length accordingly. If the Interface Identification Object identifies the probed interface by index, the length is equal to 8 and the payload contains the if-index . If the Interface Identification Object identifies the probed interface by address, the payload is as depicted in .

Interface Identification Object - C-Type 3 Payload

Payload fields are defined as follows:

• Address Family Identifier (AFI): This 16-bit field identifies the type of address represented by the Address field. All values found in the IANA registry of Address Family Numbers (available from ) are valid in this field.
• Address Length: Number of significant bytes contained by the Address field. (The Address field contains significant bytes and padding bytes.)
• Reserved: This field MUST be set to 0 and ignored upon receipt.
• Address: This variable-length field represents a unicast address associated with the probed interface. If the address field would not otherwise terminate on a 32-bit boundary, it MUST be padded with zeroes.

ICMP Extended Echo Reply The ICMP Extended Echo Reply message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Reply message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header. depicts the ICMP Extended Echo Reply message.

ICMP Extended Echo Reply Message

IP Header fields:

• Source Address: Copied from the Destination Address field of the invoking Extended Echo Request message.
• Destination Address: Copied from the Source Address field of the invoking Extended Echo Request message.

ICMP fields:

• Type: Extended Echo Reply. The value for ICMPv4 is 43. The value for ICMPv6 is 161.
• Code: Values are (0) No Error, (1) Malformed Query, (2) No Such Interface, (3) No Such Table Entry, and (4) Multiple Interfaces Satisfy Query.
• Checksum: For ICMPv4, see . For ICMPv6, see .
• Identifier: Copied from the Identifier field of the invoking Extended Echo Request packet.
• Sequence Number: Copied from the Sequence Number field of the invoking Extended Echo Request packet.
• State: If Code is not equal to 0, this field MUST be set to 0 and ignored upon receipt. Likewise, if the probed interface resides upon the proxy node, this field MUST be set to 0 and ignored upon receipt. Otherwise, this field reflects the state of the ARP table or Neighbor Cache entry associated with the probed interface. Values are (0) Reserved, (1) Incomplete, (2) Reachable, (3) Stale, (4) Delay, (5) Probe, and (6) Failed.
• Res: This field MUST be set to 0 and ignored upon receipt.
• A (Active): The A-bit is set if the Code is equal to 0, the probed interface resides on the proxy node, and the probed interface is active. Otherwise, the A-bit is clear.
• 4 (IPv4): The 4-bit is set if the A-bit is also set and IPv4 is running on the probed interface. Otherwise, the 4-bit is clear.
• 6 (IPv6): The 6-bit is set if the A-bit is also set and IPv6 is running on the probed interface. Otherwise, the 6-bit is clear.

ICMP Message Processing When a node receives an ICMP Extended Echo Request message and any of the following conditions apply, the node MUST silently discard the incoming message:

• The node does not recognize ICMP Extended Echo Request messages.
• The node has not explicitly enabled ICMP Extended Echo functionality.
• The incoming ICMP Extend Echo Request carries a Source Address that is not explicitly authorized for the L-bit setting of the incoming ICMP Extended Echo Request.
• The incoming ICMP Extend Echo Request carries a Source Address that is not explicitly authorized for the incoming ICMP Extended Echo Request type (i.e., by name, by if-index, or by address).
• The Source Address of the incoming message is not a unicast address.
• The Destination Address of the incoming message is a multicast address.

Otherwise, when a node receives an ICMPv4 Extended Echo Request, it MUST format the IPv4 header of an ICMPv4 Extended Echo Reply as follows:

• TTL is 255
• Protocol is ICMP
• Indicate that the packet is not source fragmented and must not be on-path fragmented with the following values:
  • Don't Fragment (DF) flag is 1
  • More Fragments flag is 0
  • Fragment Offset is 0

When a node receives an ICMPv6 Extended Echo Request, it MUST format the IPv6 header of an ICMPv6 Extended Echo Reply as follows:

• Hop Limit is 255
• Next Header is ICMPv6
• Indicate that the packet is not source fragmented
  • Do not include an IPv6 Fragmentation Header
• This document does not specify any value for the Flow Label field

In either case, the responding node MUST do the following:

• Copy the Source Address from the Extended Echo Request message to the Destination Address of the Extended Echo Reply.
• Copy the Destination Address from the Extended Echo Request message to the Source Address of the Extended Echo Reply.
• Set the DiffServ codepoint to CS0.
• Set the ICMP Type to Extended Echo Reply.
• Copy the Identifier from the Extended Echo Request message to the Extended Echo Reply.
• Copy the Sequence Number from the Extended Echo Request message to the Extended Echo Reply.
• Set the Code field as described in .
• Set the State field to 0.
• Clear the A-bit, the 4-bit, and the 6-bit.
• If (1) the Code Field is equal to (0) No Error, (2) the L-bit is set, and (3) the probed interface is active, set the A-bit. Also, set the 4-bit and the 6-bit as appropriate.
• If the Code field is equal to (0) No Error and the L-bit is clear, then set the State field to reflect the state of the ARP table or Neighbor Cache entry that represents the probed interface.
• Copy the ICMP Extension Structure, ICMP Extension Object, and Data (if any) from the Extended Echo Request message.
• Set the Checksum appropriately.
• Forward the ICMP Extended Echo Reply to its destination. The size of the resulting packet MUST NOT exceed the outgoing interface MTU.

Code Field Processing The Code field MUST be set to (1) Malformed Query if any of the following conditions apply:

• The ICMP Extended Echo Request does not include an ICMP Extension Structure.
• The ICMP Extension Structure does not include exactly one Interface Identification Object.
• The ICMP Extension Structure checksum is 0 or incorrect.
• The L-bit is clear and the Interface Identification Object identifies the probed interface by name or if-index.
• The query is otherwise malformed.

The Code field MUST be set to (2) No Such Interface if the L-bit is set and the ICMP Extension Structure does not identify an interface that resides on the proxy node. The Code field MUST be set to (3) No Such Table Entry if the L-bit is clear and the address found in the Interface Identification Object does not appear in the IPv4 Address Resolution Protocol (ARP) table or the IPv6 Neighbor Cache. More precisely, if the AFI is 1 (IPv4), the IPv4 ARP table is used. If the AFI is 2 (IPv6), the IPv6 Neighbor Cache is used. For any other AFI value, No Such Table Entry is used as there is no table to inspect. The Code field MUST be set to (4) Multiple Interfaces Satisfy Query if any of the following conditions apply:

• The L-bit is set and the ICMP Extension Structure identifies more than one interface that resides in the proxy node.
• The L-bit is clear and the address found in the Interface Identification Object maps to multiple IPv4 ARP or IPv6 Neighbor Cache entries.

Otherwise, the Code field MUST be set to (0) No Error.

Use Cases In the scenarios listed below, network operators can use PROBE to determine the status of a probed interface but cannot use PING for the same purpose. In all scenarios, assume bidirectional connectivity between the probing and proxy interfaces. However, bidirectional connectivity between the probing and probed interfaces is lacking.

• The probed interface is unnumbered.
• The probing and probed interfaces are not directly connected to one another. The probed interface has an IPv6 link-local address but does not have a more globally scoped address.
• The probing interface runs IPv4 only while the probed interface runs IPv6 only.
• The probing interface runs IPv6 only while the probed interface runs IPv4 only.
• For lack of a route, the probing node cannot reach the probed interface.

Caveats A limitation of PROBE is that if probing a link-local destination with the L-bit clear, and the same link-local address is used by multiple neighbors, you may get one of three code values in response:

• No Such Table Entry, if none of the neighbors are currently in the table.
• No Error, if one neighbor is currently in the table, but there is no indication as to which neighbor.
• Multiple Interfaces Satisfy Query, if more than one such neighbor is in the table.

Similarly, when identifying a local interface by link-local address (the L-bit is set), and the same link-local address is assigned to multiple interfaces, you will get a response with the code Multiple Interfaces Satisfy Query, with no indication which interface is active or able to pass traffic.

Updates to RFC 4884 Section 4.6 of provides a list of extensible ICMP messages (i.e., messages that can carry the ICMP Extension Structure). This document adds the ICMP Extended Echo Request message and the ICMP Extended Echo Reply message to that list.

Changes from RFC 8335 This document updates to clarify the handling of extra data beyond the ICMP Extension Structure, that data is echoed in the response packet, and checksum handling in the ICMP Extension Structure. Specifically,

• Updated to reflect the presence of the ICMP Extension Object and additional data.
• Updated to mention the ICMP Extension Structure checksum, and extra verbosity about how the Extension Structure does not cover the rest of the packet.
• Updated to reflect the presence of the ICMP Extension Structure and additional data.
• Added a step in about copying data from the request to the response.
• Added a step in about validating the ICMP Extension Structure checksum.
• Added section to suggest human-readable display of PROBE responses
• Clarified in that the length of an ifName Object is adjusted when padding is added.

Internet Draft Change History

Changes from draft-fenner-intarea-probe-clarification-00

• Changed "NULL" to "NUL" when referring to the ASCII control character, per RFC20.
• Consistently refer to interface name and index using their yang names, not SNMP names.
• Added [] around the Data following the ICMP Extension Structure in and to indicate that it is optional.

Changes from draft-fenner-intarea-probe-clarification-01

• Updated the section on ICMP Extension header format to say that different ICMP Extension Option headers may be present, and if they are, the mechanism is not as specified in this memo.

Changes from draft-fenner-intarea-probe-clarification-02

• Made a stronger statement about not copying this behavior in
• Renamed to rfc8335bis and made WG document

Changes from draft-int-intarea-rfc8335bis-00

• Changed "For the operations in this memo" to "In the PROBE application" to better align with draft-ietf-6man-icmpv6-reflection

Changes from draft-int-intarea-rfc8335bis-01

• None

Changes from draft-int-intarea-rfc8335bis-02

• Added reference to draft-ietf-6man-icmpv6-reflection
• Updated some "RFC NNN" references to bibliography references
• Add MUST NOT exceed MTU.
• Added details of IPv4/IPv6 headers and avoidance of fragmentation to
• Added IP address and interface index considerations to
• Add new (Manageability Considerations) immediately before , per RFC 5706 Section 4.3 guidance.
• Add to details of Amplification risk, Covert channel potential, On-path attacker modification, ICMP header checksum scope.
• Broaden VPN isolation language to cover network instances and logical network elements.
• Clarify the wording of , including further wording about the checksum coverage.

Changes from draft-int-intarea-rfc8335bis-03

• Manageability Considerations:
  • Don't duplicate the configuration items from the security considerations section
  • Clarify that response is the same size as the request, so there is no amplification vector.

Changes from draft-int-intarea-rfc8335bis-04

• Marked this section as removeInRFC="true", while splitting off
• Clarified that the address object must identify a unicast address
• Added
• Clarified that we do not specify the flow label
• Removed "densely" from the concern of enumerating all interfaces, since it only takes 4,294,967,295 packets to enumerate the entire number space.
• Use "specifies" instead of "describes" in abstract
• Clarified that AFI=1 means look in the ARP table, AFI=2 means look in the IPv6 Neighbor Cache, and any other AFI means No Such Table Entry since there is no table.
• Split the acknowledgements, and created a placeholder authors section.

Changes from draft-int-intarea-rfc8335bis-05

• Moved historical authors to RFC8335 authors section.

IANA Considerations IANA is requested to update the references for the below actions from to refer to this document. IANA has performed the following actions:

• Added the following to the "ICMP Type Numbers" registry: Added the following to the "Type 42 - Extended Echo Request" subregistry:
• Added the following to the "ICMPv6 'type' Numbers" registry: Added the following to the "Type 160 - Extended Echo Request" subregistry:
• Added the following to the "ICMP Type Numbers" registry: Added the following to the "Type 43 - Extended Echo Reply" subregistry:
• Added the following to the "ICMPv6 'type' Numbers" registry: Added the following to the "Type 161 - Extended Echo Reply" subregistry:
• Added the following to the "ICMP Extension Object Classes and Class Sub-types" registry: Added the following C-types to the "Sub-types - Class 3 - Interface Identification Object" subregistry: C-Type values are assigned on a First Come First Serve (FCFS) basis with a range of 0-255.

All codes mentioned above are assigned on an FCFS basis with a range of 0-255.

Manageability Considerations This section discusses manageability aspects of PROBE. PROBE is an on-demand diagnostic tool analogous to PING. It does not run autonomously, does not maintain persistent protocol state, and does not require a formal information model or data-model definition. The subsections below address the aspects of that are applicable to PROBE.

Control of Function and Policy Security configuration for implementations of the ICMP Extended Echo functionality support are specified in . These parameters are local to each node and take effect immediately; no protocol restart or network-wide coordination is required. An operator must explicitly enable the feature and configure authorized source prefixes before a node will respond to any Extended Echo Request. No MIB module or YANG data model is defined for these parameters. A YANG model may be defined in a separate document in the future.

Monitoring and Verifying Operation Correct operation of PROBE can be verified by sending an ICMP Extended Echo Request to a proxy node and examining the Code field of the ICMP Extended Echo Reply (). A Code of 0 (No Error) with the expected interface status confirms correct operation. Non-zero Code values indicate specific error conditions enumerated in . The PROBE application described in sends iterative queries and reports per-query results including round-trip time. This round-trip time reflects the path latency between the probing node and the proxy node, not a property of the probed interface itself. Implementations MAY log received Extended Echo Requests at a debug level and MAY maintain counters of received, accepted, and discarded Extended Echo Requests as part of their general ICMP statistics, to assist operators in troubleshooting access-control configuration and detecting unexpected traffic.

Deployment and Backward Compatibility PROBE is deployed on individual nodes and invoked on demand by operators or network management applications. It does not require network-wide signaling, discovery, or coordination. Operators deploying PROBE SHOULD:

• Enable Extended Echo functionality only on nodes that require diagnostic access.
• Restrict permitted source prefixes to authorized management networks.
• Apply rate-limiting to Extended Echo Requests consistent with existing ICMP rate-limiting policies.

This document obsoletes . All known implementations of are compatible with this document. The differences between this document and are clarifications of the packet format and processing rules and not changes to on-the-wire behavior. Nodes implementing this document interoperate with nodes implementing without any transition mechanism or behavioral migration.

Impact on Network Operation Each PROBE invocation generates one ICMP Extended Echo Request and one ICMP Extended Echo Reply. Each query is independent; there is no persistent session or periodic message exchange. The processing cost on the proxy node is comparable to that of a standard ICMP Echo Request. Frequent automated use of PROBE (e.g., by a management application polling many interfaces) could increase ICMP traffic on the network. Operators SHOULD apply rate-limiting at the responder () consistent with their existing ICMP rate-limiting policies to bound this load.

Security Considerations The following are legitimate uses of PROBE:

• to determine the operational status of an interface.
• to determine which protocols (e.g., IPv4 or IPv6) are active on an interface.

However, malicious parties can use PROBE to obtain additional information. For example, a malicious party can use PROBE to discover interface names. Having discovered an interface name, the malicious party may be able to infer additional information. Additional information may include:

• interface bandwidth
• the type of device that supports the interface (e.g., vendor identity)
• the operating system version that the above-mentioned device executes

Addresses and interface index values can also give away information that might not want to be shared. For example, a malicious party can use PROBE to determine that a given IP address is assigned to any interface on the probed node, or it can determine how many interfaces exist on the probed node. Understanding these risks, network operators establish policies that restrict access to ICMP Extended Echo functionality. In order to enforce these policies, nodes that support ICMP Extended Echo functionality MUST support the following configuration options:

• Enable/disable ICMP Extended Echo functionality. By default, ICMP Extend Echo functionality is disabled.
• Define enabled L-bit settings. By default, the option to set the L-bit is enabled and the option to clear the L-bit is disabled.
• Define enabled query types (i.e., by name, by index, or by address); by default, all query types are disabled.
• For each enabled query type, define the prefixes from which ICMP Extended Echo Request messages are permitted.
• For each interface, determine whether ICMP Echo Request messages are accepted.

When a node receives an ICMP Extended Echo Request message that it is not configured to support, it MUST silently discard the message. See for details. PROBE must not leak information across network instance boundaries. Therefore, when a node receives an ICMP Extended Echo Request and the proxy interface and the probed interface are in different Virtual Private Networks (VPNs), network instances , or logical network elements , the node MUST return an ICMP Extended Echo Reply with error code equal to (2) No Such Interface. In order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages. PROBE does not present an amplification risk. The ICMP Extended Echo Reply is the same size as the corresponding ICMP Extended Echo Request; therefore, PROBE is not a useful amplification vector. As with any ICMP message that carries an opaque data payload, the optional data field could theoretically be used as a covert channel. The rate-limiting recommended above bounds the throughput of any such channel. An on-path attacker can modify ICMP Extended Echo Request or Reply messages to return incorrect interface status information. This risk is shared with all ICMP messages and is not unique to PROBE. When integrity protection of PROBE messages is required, IPsec SHOULD be used. The ICMP header checksum provides integrity protection for the entire ICMP message, including any data following the ICMP Extension Structure. However, this is a non-cryptographic checksum intended for error detection, not protection against intentional modification.

References Normative References This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK] The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Huawei China Telecom Huawei HPE ZTE Corp. This document specifies the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 PROBE utility. It is similar to Ping and PROBE in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request. The ICMPv6 Reflection utility differs from Ping and PROBE because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it can allow the user to see how the network modified the request as it traveled from the probing node to the probed node. This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community. This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342. New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community. IANA

The PROBE Application The PROBE application accepts input parameters, sets a counter, and enters a loop to be exited when the counter is equal to 0. On each iteration of the loop, PROBE emits an ICMP Extended Echo Request, decrements the counter, sets a timer, and waits. The ICMP Extended Echo Request includes an Identifier and a Sequence Number. If an ICMP Extended Echo Reply carrying the same Identifier and Sequence Number arrives, PROBE relays information returned by that message to its user. However, on each iteration of the loop, PROBE waits for the timer to expire regardless of whether an Extended Echo Reply message arrives. PROBE accepts the following parameters:

• Count
• Wait
• Probing Interface Address
• Hop Count
• Proxy Interface Address
• Local
• Probed Interface Identifier

Count is a positive integer whose default value is 3. Count determines the number of times that PROBE iterates through the above-mentioned loop. Wait is a positive integer whose minimum and default values are 1. Wait determines the duration of the above-mentioned timer, measured in seconds. Probing Interface Address specifies the Source Address of the ICMP Extended Echo Request. The Probing Interface Address MUST be a unicast address and MUST identify an interface that resides on the probing node. The Proxy Interface Address identifies the interface to which the ICMP Extended Echo Request message is sent. It must be an IPv4 or IPv6 unicast address. If it is an IPv4 address, PROBE emits an ICMPv4 message. If it is an IPv6 address, PROBE emits an ICMPv6 message. Local is a boolean value. It is TRUE if the proxy and probed interfaces both reside on the same node. Otherwise, it is FALSE. The Probed Interface Identifier identifies the probed interface. It is one of the following:

• an interface name;
• an address from any address family (e.g., IPv4, IPv6, IEEE 802, 48-bit MAC, or 64-bit MAC); or
• an if-index.

If the Probed Interface Identifier is an address, it does not need to be of the same address family as the proxy interface address. For example, PROBE accepts an IPv4 Proxy Interface Address and an IPv6 Probed Interface Identifier.

Information Display For the PING application, the primary available piece of information is the fact that we received an ICMP Echo Reply. Therefore, the appropriate information to display is all of the available information about the received reply, e.g., size, ttl, etc. However, with PROBE, the primary piece of information is the reported status of the probed interface: the code, status, A, 4, and 6 fields. It's appropriate to convert the combination of the returned values into a "human-readable" response. For example, an application may perform these steps:

• If the code field is non-zero, print the code value as described in .
• If the code field is zero, then if the L field sent is zero, print the state value as described in .
• Otherwise, the L field sent is 1; print the state represented by the A, 4, and 6 bits. Sample textual translations for these bits are shown in .

Sample translations for bit settings

A	4	6	Text
0	0	0	Interface inactive
1	0	0	Interface active, with no ipv4 or ipv6 running
1	0	1	Interface active, with ipv6 running
1	1	0	Interface active, with ipv4 running
1	1	1	Interface active, with ipv4 and ipv6 running

Deployment Experience As described in , this feature defaults to "off", and is expected to be tightly controlled by an operator in order to prevent leakage of sensitive information. Therefore, most deployments are expected to effectively be within a domain in which the same organization controls, e.g., middleboxes and firewalls, if those devices do not pass these ICMP messages properly. While individual experiments have shown that this protocol can be used across pieces of the public Internet, there are no broad experimental results.

Naming is Very Important to Implementers The biggest lesson to take away from RFC8335 is that it was described as similar to ping, which appears to have led implementors to understand that the packet format was similar to ping, which led to the unusual and awkward packet format described in this document, as these implementations ended up violating RFC4884. While it is tempting to relate a new development with something that users are already familiar with, evidence is that this can result in undesired misunderstanding and shortcuts.

Naming is Very Important to Operators Initial implementations of the probe client displayed information in a very similar way to ping, e.g.,

Sample output from initial probe client

A careful read will show that the ipv4 and ipv6 responses are "0", perhaps meaning that the desired interface state is not present. However, given that more than half of the line matches a successful response from "ping", and that people are very good at pattern matching, users are inclined to recognize this as success, not as failure. This experience led to the suggestions in .

Acknowledgments Thanks to Joe Touch, Sue Hares, Xaio Min, Tony Przygienda, Nick Buraglio and Tal Mizrahi for their thoughtful review of this document.

RFC8335 Acknowledgements Thanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan Looney, Dave Thaler, Mikio Hara, Joel Halpern, Yaron Sheffer, Stefan Winter, Jean-Michel Combes, Amanda Barber, and Joe Touch for their thoughtful review of this document.

RFC8335 Authors

• Ron Bonica
• Juniper Networks
• 2251 Corporate Park Drive
• Herndon, Virginia 20171
• United States of America
• Email: rbonica@juniper.net

• Jen Linkova
• Google
• 1600 Amphitheatre Parkway
• Mountain View, California 94043
• United States of America
• Email: furry@google.com

• Mohamed Boucadair
• Orange
• Rennes 35000
• France
• Email: mohamed.boucadair@orange.com