PROBE: A Utility For Probing InterfacesJuniper Networks2251 Corporate Park DriveHerndon20171VirginiaUSArbonica@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiarejithomas@juniper.netGoogle1600 Amphitheatre ParkwayMountain ViewCalifornia94043USAfurry@google.comVerizon22001 Loudoun County ParkwayAshburnVirginia20147USAchris.lenart@verizon.comOrangeRennes 35000Francemohamed.boucadair@orange.com
Internet
INTAREAPingICMPThis document describes a network diagnostic tool called PROBE. PROBE
is similar to PING, in that it can be used to test the status of a
probed interface. It differs from PING in that it does not require
bidirectional connectivity between the probing and probed interfaces.
Alternatively, 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.Network operators use PING to test
bidirectional connectivity between two interfaces. For the purposes of
this document, we will call these interfaces the probing and probed
interfaces. PING sends an ICMP Echo 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 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 interfaceThe probed interface is activeThe probed node can reach the probing interfaceThe probing interface is activeThis document describes a network diagnostic tool called PROBE. PROBE
is similar to PING, in that it can be used to test the status of a
probed interface. It differs from PING in that it does not require
bidirectional connectivity between the probing and probed interfaces.
Alternatively, 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. of this document describes scenarios in which this
characteristic is useful.Like PING, PROBE executes on a probing node. It sends an ICMP
Extended Echo message from a local interface, called the probing
interface, to a proxy interface. The proxy interface resides on a probed
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 the probed node or it can
be directly connected to the probed node.When the proxy interface receives the ICMP Extended Echo Request, it
executes access control procedures. If access is granted, the probed
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 probed node, PROBE determines
the status of the probed interface as it would determine its MIB-II ifOperStatus. If ifOperStatus 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 probed node, PROBE reports that the interface is up if it appears
in the IPv4 Address Resolution Protocol (ARP) table or the IPv6 Neighbor
Cache. Otherwise, it reports that the interface does not exist.This document uses the following terms:Probing node - The node upon which PROBE executesProbing interface - The interface from which an ICMP Extended
Echo originatesProxy interface - The interface to which the ICMP Extended Echo
message is sentProbed node - The node upon which the proxy interface
residesProbed interface - The interface whose status is being
queriedThe 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.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.IP Header fields:Source Address: The Source Address identifies the probing
interface. It MUST be valid IPv4 or IPv6 unicast address.Destination Address: The Destination Address identifies the proxy
interface. It can be a unicast, multicast or anycast address.ICMP fields:Type: Extended Echo Request. The value for ICMPv4 is TBD by IANA.
The value for ICMPv6 is also TBD by IANA.Code: 0Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.Identifier: An identifier to aid in matching Extended Echo
Replies to Extended Echo Requests. May be zero.Sequence Number: A sequence number to aid in matching Extended
Echo Replies to Extended Echo Requests. May be zero.Reserved: This field MUST be set to zero and ignored upon
receipt.L (local) - The L-bit is set of the probed interface resides on
the probed node. The L-bit is clear if the probed interface is
directly connected to the probed node.ICMP Extension Structure: The ICMP Extension Structure identifies
the probed interface.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 ICMP Extension Structure MUST
contain one or two instances of the Interface
Identification Object.In most cases, a single instance of the Interface Identification
Object identifies the probed interface. However, in some cases, a second
instance is required for disambiguation.If the L-bit is set, the Interface Identification Object identifies
the probed interface by name, index or address. It the L-bit is clear,
the Interface Identification Object identifies 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, IPv6 or IEEE 802 address. Likewise, an ICMPv6 Extended Echo
Request message can carry an Interface Identification Object that
identifies the probed interface by IPv4, IPv6 or IEEE 802 address.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. Value is TBD by
IANAC-type: Values are: (1) Identifies Interface By Name, (2)
Identifies Interface By Index, and (3) Identifies Interface By
AddressLength: 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 MIB-II [RFC2863]
ifName. If the object payload would not otherwise terminate on a
32-bit boundary, it MUST be padded with ASCII NULL characters.If the Interface Identification Object identifies the probed
interface by index, the length is equal to 8 and the payload contains
the MIB-II ifIndex [RFC2863].If the Interface Identification Object identifies the probed
interface by address, the payload is as depicted in .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
<https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml>)
are valid in this field.Reserved: This field MUST be set to zero and ignored upon
receipt.Address Len - Number of significant bytes contained by the
Address field. (The address field contains significant bytes and
padding bytes)Address: This variable-length field represents an address
associated with the probed interface. If the address field would
not otherwise terminate on a 32-bit boundary, it MUST be padded
with zeros.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.IP Header fields:Source address: Copied from the Destination Address field of the
invoking Extended Echo Request messageDestination address: Copied from the Source Address field of the
invoking Extended Echo Request messageICMP fields:Type: Extended Echo Reply. The value for ICMPv4 is TBD by IANA.
The value for ICMPv6 is also TBD by IANACode: (0) No Error, (1) Malformed Query, (2) No Such Interface,
(3) Multiple Interfaces Satisfy QueryChecksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443Identifier: Copied from the Identifier field of the invoking
Extended Echo Request packetSequence Number: Copied from the Sequence Number field of the
invoking Extended Echo Request packetResvd - This field MUST be set to zero and ignored upon
receiptA (Active) - The A-bit is set if Code is equal to zero and the
probed interface is active. Otherwise, the A-bit is clear.F (IPv4) - The F-bit is set if the A-bit is also set and IPv4 is
running on the probed interface. Otherwise, the F-bit is clear.S (IPv6) - The S-bit is set if the A-bit is also set and IPv6 is
running on the probed interface. Otherwise, the S-bit is clear.E (Ethernet) - The E-bit is set if the A-bit is also set and IPv4
is running on the probed interface. Otherwise, the E-bit is
clear.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
messagesThe node has not explicitly enabled ICMP Extended Echo
functionalityThe incoming ICMP Extend Echo Request carries a source address
that is not explicitly authorized for the incoming ICMP Extended
Echo Request L-bit settingThe 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 ifName, by IfIndex, by Address)The Source Address of the incoming messages is not a unicast
addressOtherwise, when a node receives an ICMPv4 Extended Echo Request, it
MUST format an ICMP Extended Echo Reply as follows:Don't Fragment flag (DF) is 1More Fragments flag is 0Fragment Offset is 0TTL is 255Protocol is ICMPWhen a node receives an ICMPv6 Extended Echo Request, it MUST
format an ICMPv6 Extended Echo Reply as follows:Hop Limit is 255Next Header is ICMPv6In either case, the responding node MUST:Copy the source address from the Extended Echo Request message to
the destination address of the Extended Echo ReplyCopy the destination address from the Extended Echo Request
message to the source address of the Extended Echo ReplySet the DiffServ codepoint to CS0Set the ICMP Type to Extended Echo ReplyCopy the Identifier from the Extended Echo Request message to the
Extended Echo ReplyCopy the Sequence Number from the Extended Echo Request message
to the Extended Echo ReplySet the Code field as described If the Code Field is equal to No Error (0) and the L-bit is
clear, set the A-Bit.If the Code Field is equal to No Error (0) and the L-bit is set
and the probed interface is active, set the A-bit.If the A-bit is set, set the F-bit, S-bit and E-bit as
appropriate. Otherwise, clear the F, S and E bits.Set the checksum appropriatelyForward the ICMP Extended Echo Reply to its destinationThe Code field MUST be set to Malformed Query (1) if any of the
following conditions apply:The ICMP Extended Echo Request does not include an ICMP
Extension StructureThe ICMP Extension Structure does not include an Interface
Identification ObjectThe ICMP Extension Structure contains more than two Interface
Identification ObjectsThe L-bit is clear and the Interface Identification Object
identifies the probed interface by ifName or ifIndexThe query is otherwise malformedThe Code field MUST be set to No Such Interface (2) if any of
the following conditions apply:The L-bit is set and the ICMP Extension Structure does not
identify any local interfacesThe L-bit is clear and the address or addresses found in the
Interface Identification object appear in neither the IPv4 Address
Resolution Protocol (ARP) Table nor the IPv6 Neighbor CacheThe Code field MUST be set to Multiple Interfaces Satisfy
Query (3) if any of the following conditions apply:The L-bit is set and the ICMP Extension Structure identifies
more than one local interfacesThe L-bit is clear and the address or addresses found in the
Interface Identification object map to multiple IPv4 ARP or IPv6
Neighbor Cache entriesOtherwise, the Code field MUST be set to No Error (0)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 unnumberedThe 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 addressThe probing interface runs IPv4 only while the probed interface
runs IPv6 onlyThe probing interface runs IPv6 only while the probed interface
runs IPv4 onlyFor lack of a route, the probing node cannot reach the probed
interface.Section 4.6 of RFC 4884 provides a list of extensible ICMP messages
(i.e., messages that can carry the ICMP Extension Structure). This
document adds the ICMP Extended Echo message and the ICMP Extended Echo
Reply message to that list.This document requests the following actions from IANA:Add an entry to the "ICMP Type Number" registry, representing the
Extended Echo Request. This entry has one code (0).Add an entry to the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry, representing the Extended Echo
Request. This entry has one code (0).Add an entry to the "ICMP Type Number" registry, representing the
Extended Echo Reply. This entry has the following codes: (0) No
Error, (1) Malformed Query, (2) No Such Interface, (3) Multiple
Interfaces Satisfy Query. Protocol Flag Bit mappings are as follows:
Bit 0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15
(Reserved).Add an entry to the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry, representing the Extended Echo Reply.
This entry has the following codes: (0) No Error, (1) Malformed
Query, (2) No Such Interface, (3) Multiple Interfaces Satisfy Query.
Protocol Flag Bit mappings are as follows: Bit 0 (IPv4), Bit 1
(IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved).Add an entry to the "ICMP Extension Object Classes and Class
Sub-types" registry, representing the Interface Identification
Object. It has C-types Reserved (0), Identifies Interface By Name
(1), Identifies Interface By Index (2), Identifies Interface By
Address (3)Note to RFC Editor: this section may be removed on publication as an
RFC.The following are legitimate uses of PROBE:to determine the operational status of an interfaceto determine which protocols (e.g., IPv4, IPv6) are active on an
interfaceHowever, 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 bandwidththe type of device that supports the interface (e.g., vendor
identity)the operating system version that the above-mentioned device
executesUnderstanding this risk, network operators establish policies that
restrict access to ICMP Extended Echo functionality. In order to enforce
these polices, 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, L-bit set is enabled
and L-bit clear is disabled.Define enabled query types (i.e., by ifName, by ifIndex, 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 permittedFor each interface, determine whether ICMP Echo Request messages
are acceptedWhen 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 about one Virtual Private Network
(VPN) into another. Therefore, when a node receives an ICMP Extended
Echo Request and the proxy interface is in a different VPN than the
probed interface, 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.The PROBE application accepts input parameters, sets a counter and
enters a loop to be exited when the counter is equal to zero. On each
iteration of the loop, PROBE emits an ICMP Extended Echo Request,
decrements the counter, sets a timer, waits for the timer to expire. If
an expected ICMP Extended Echo Reply arrives while PROBE is waiting for
the timer to expire, 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:CountWaitProbing Interface AddressHop CountProxy Interface AddressLocalProbed Interface IdentifierCount 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 ICMP
Extended Echo Request. The Probing Interface Address MUST be a unicast
address and MUST identify an interface that is local to the probing
node.The Proxy Interface Address identifies the interface to which the
ICMP Extended Echo Request message is sent. It can be an IPv4 or IPv6
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 probed node. It is FALSE if the proxy
interface resides on the probed node and the probed interface is
directly connected to the probed node.The probed interface is the interface whose status is being queried.
It is identified by one of the following:an interface namean address from any address family (e.g., IPv4, IPv6, IEEE 802,
48-bit MAC, 64-bit MAC)an ifIndexIf 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 destination interface address and an IPv6
probed interface identifierThanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan
Looney, Dave Thaler, Mikio Hara and Joe Touch for their thoughtful
review of this document.