From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8335.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc8335.txt (limited to 'doc/rfc/rfc8335.txt') diff --git a/doc/rfc/rfc8335.txt b/doc/rfc/rfc8335.txt new file mode 100644 index 0000000..328678e --- /dev/null +++ b/doc/rfc/rfc8335.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Bonica +Request for Comments: 8335 R. Thomas +Updates: 4884 Juniper Networks +Category: Standards Track J. Linkova +ISSN: 2070-1721 Google + C. Lenart + Verizon + M. Boucadair + Orange + February 2018 + + + PROBE: A Utility for Probing Interfaces + +Abstract + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8335. + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 1] + +RFC 8335 PROBE February 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. ICMP Extended Echo Request . . . . . . . . . . . . . . . . . 5 + 2.1. Interface Identification Object . . . . . . . . . . . . . 6 + 3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 7 + 4. ICMP Message Processing . . . . . . . . . . . . . . . . . . . 9 + 4.1. Code Field Processing . . . . . . . . . . . . . . . . . . 11 + 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. The PROBE Application . . . . . . . . . . . . . . . 17 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 2] + +RFC 8335 PROBE February 2018 + + +1. Introduction + + Network operators use PING [RFC2151] 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 [RFC792] [RFC4443] 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: + + o The probing node can reach the probed interface. + + o The probed interface is active. + + o The probed node can reach the probing interface. + + o 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. Section 5 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 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 directly connect to + the proxy node. + + + + + + +Bonica, et al. Standards Track [Page 3] + +RFC 8335 PROBE February 2018 + + + 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 [RFC7223]. 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 [RFC826] or IPv6 Neighbor + Cache [RFC4861], PROBE reports interface reachability. Otherwise, + PROBE reports that the table entry does not exist. + +1.1. Terminology + + This document uses the following terms: + + o Probing interface: The interface that sends the ICMP Extended Echo + Request. + + o Probing node: The node upon which the probing interface resides. + + o Proxy interface: The interface to which the ICMP Extended Echo + Request message is sent. + + o Proxy node: The node upon which the proxy interface resides. + + o Probed interface: The interface whose status is being queried. + + o 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. + +1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + +Bonica, et al. Standards Track [Page 4] + +RFC 8335 PROBE February 2018 + + +2. 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. + + Figure 1 depicts the ICMP Extended Echo Request message. + + 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| Reserved |L| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ICMP Extension Structure + + Figure 1: ICMP Extended Echo Request Message + + IP Header fields: + + o Source Address: The Source Address identifies the probing + interface. It MUST be a valid IPv4 or IPv6 unicast address. + + o Destination Address: The Destination Address identifies the proxy + interface. It MUST be a unicast address. + + ICMP fields: + + o Type: Extended Echo Request. The value for ICMPv4 is 42. The + value for ICMPv6 is 160. + + o Code: MUST be set to 0 and MUST be ignored upon receipt. + + o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. + + o Identifier: An Identifier to aid in matching Extended Echo Replies + to Extended Echo Requests. May be 0. + + o Sequence Number: A Sequence Number to aid in matching Extended + Echo Replies to Extended Echo Requests. May be 0. + + o Reserved: This field MUST be set to 0 and ignored upon receipt. + + + + + + +Bonica, et al. Standards Track [Page 5] + +RFC 8335 PROBE February 2018 + + + o 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. + + o ICMP Extension Structure: The ICMP Extension Structure identifies + the probed interface. + + Section 7 of [RFC4884] 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 exactly one instance of the Interface Identification Object + (see Section 2.1). + + 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, 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. + +2.1. 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: + + o Class-Num: Interface Identification Object. The value is 3. + + o C-Type: Values are (1) Identifies Interface by Name, (2) + Identifies Interface by Index, and (3) Identifies Interface by + Address. + + o Length: Length of the object, measured in octets, including the + Object Header and Object Payload. + + + + + + + + +Bonica, et al. Standards Track [Page 6] + +RFC 8335 PROBE February 2018 + + + If the Interface Identification Object identifies the probed + interface by name, the Object Payload MUST be the interface name as + defined in [RFC7223]. 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 if-index [RFC7223]. + + If the Interface Identification Object identifies the probed + interface by address, the payload is as depicted in Figure 2. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AFI | Address Length| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address .... + + Figure 2: Interface Identification Object - C-Type 3 Payload + + Payload fields are defined as follows: + + o 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. + + o Address Length: Number of significant bytes contained by the + Address field. (The Address field contains significant bytes and + padding bytes.) + + o Reserved: This field MUST be set to 0 and ignored upon receipt. + + o 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 zeroes. + +3. 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. + + + +Bonica, et al. Standards Track [Page 7] + +RFC 8335 PROBE February 2018 + + + Figure 3 depicts the ICMP Extended Echo Reply message. + + 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|State|Res|A|4|6| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: ICMP Extended Echo Reply Message + + IP Header fields: + + o Source Address: Copied from the Destination Address field of the + invoking Extended Echo Request message. + + o Destination Address: Copied from the Source Address field of the + invoking Extended Echo Request message. + + ICMP fields: + + o Type: Extended Echo Reply. The value for ICMPv4 is 43. The value + for ICMPv6 is 161. + + o Code: Values are (0) No Error, (1) Malformed Query, (2) No Such + Interface, (3) No Such Table Entry, and (4) Multiple Interfaces + Satisfy Query. + + o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. + + o Identifier: Copied from the Identifier field of the invoking + Extended Echo Request packet. + + o Sequence Number: Copied from the Sequence Number field of the + invoking Extended Echo Request packet. + + o 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. + + o Res: This field MUST be set to 0 and ignored upon receipt. + + + + + +Bonica, et al. Standards Track [Page 8] + +RFC 8335 PROBE February 2018 + + + o 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. + + o 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. + + o 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. + +4. 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: + + o The node does not recognize ICMP Extended Echo Request messages. + + o The node has not explicitly enabled ICMP Extended Echo + functionality. + + o 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. + + o 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 ifName, by IfIndex, or by Address). + + o The Source Address of the incoming message is not a unicast + address. + + o The Destination Address of the incoming message is a multicast + address. + + Otherwise, when a node receives an ICMPv4 Extended Echo Request, it + MUST format an ICMP Extended Echo Reply as follows: + + o Don't Fragment (DF) flag is 1 + + o More Fragments flag is 0 + + o Fragment Offset is 0 + + o TTL is 255 + + o Protocol is ICMP + + + + +Bonica, et al. Standards Track [Page 9] + +RFC 8335 PROBE February 2018 + + + When a node receives an ICMPv6 Extended Echo Request, it MUST format + an ICMPv6 Extended Echo Reply as follows: + + o Hop Limit is 255 + + o Next Header is ICMPv6 + + In either case, the responding node MUST do the following: + + o Copy the Source Address from the Extended Echo Request message to + the Destination Address of the Extended Echo Reply. + + o Copy the Destination Address from the Extended Echo Request + message to the Source Address of the Extended Echo Reply. + + o Set the DiffServ codepoint to CS0 [RFC4594]. + + o Set the ICMP Type to Extended Echo Reply. + + o Copy the Identifier from the Extended Echo Request message to the + Extended Echo Reply. + + o Copy the Sequence Number from the Extended Echo Request message to + the Extended Echo Reply. + + o Set the Code field as described in Section 4.1. + + o Set the State field to 0. + + o Clear the A-bit, the 4-bit, and the 6-bit. + + o 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. + + o 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. + + o Set the Checksum appropriately. + + o Forward the ICMP Extended Echo Reply to its destination. + + + + + + + + + +Bonica, et al. Standards Track [Page 10] + +RFC 8335 PROBE February 2018 + + +4.1. Code Field Processing + + The Code field MUST be set to (1) Malformed Query if any of the + following conditions apply: + + o The ICMP Extended Echo Request does not include an ICMP Extension + Structure. + + o The ICMP Extension Structure does not include exactly one + Interface Identification Object. + + o The L-bit is clear and the Interface Identification Object + identifies the probed interface by ifName or ifIndex. + + o 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. + + The Code field MUST be set to (4) Multiple Interfaces Satisfy Query + if any of the following conditions apply: + + o The L-bit is set and the ICMP Extension Structure identifies more + than one interface that resides in the proxy node. + + o 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. + +5. 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. + + o The probed interface is unnumbered. + + + + +Bonica, et al. Standards Track [Page 11] + +RFC 8335 PROBE February 2018 + + + o 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. + + o The probing interface runs IPv4 only while the probed interface + runs IPv6 only. + + o The probing interface runs IPv6 only while the probed interface + runs IPv4 only. + + o For lack of a route, the probing node cannot reach the probed + interface. + +6. Updates to RFC 4884 + + Section 4.6 of [RFC4884] 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. + +7. IANA Considerations + + IANA has performed the following actions: + + o Added the following to the "ICMP Type Numbers" registry: + + 42 Extended Echo Request + + Added the following to the "Type 42 - Extended Echo Request" + subregistry: + + (0) No Error + + o Added the following to the "ICMPv6 'type' Numbers" registry: + + 160 Extended Echo Request + + As ICMPv6 distinguishes between informational and error + messages, and this is an informational message, the value has + been assigned from the range 128-255. + + Added the following to the "Type 160 - Extended Echo Request" + subregistry: + + (0) No Error + + + + + + +Bonica, et al. Standards Track [Page 12] + +RFC 8335 PROBE February 2018 + + + o Added the following to the "ICMP Type Numbers" registry: + + 43 Extended Echo Reply + + Added the following to the "Type 43 - Extended Echo Reply" + subregistry: + + (0) No Error + (1) Malformed Query + (2) No Such Interface + (3) No Such Table Entry + (4) Multiple Interfaces Satisfy Query + + o Added the following to the "ICMPv6 'type' Numbers" registry: + + 161 Extended Echo Reply + + As ICMPv6 distinguishes between informational and error + messages, and this is an informational message, the value has + been assigned from the range 128-255. + + Added the following to the "Type 161 - Extended Echo Reply" + subregistry: + + (0) No Error + (1) Malformed Query + (2) No Such Interface + (3) No Such Table Entry + (4) Multiple Interfaces Satisfy Query + + o Added the following to the "ICMP Extension Object Classes and + Class Sub-types" registry: + + (3) Interface Identification Object + + Added the following C-types to the "Sub-types - Class 3 - + Interface Identification Object" subregistry: + + (0) Reserved + (1) Identifies Interface by Name + (2) Identifies Interface by Index + (3) Identifies Interface by Address + + 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. + + + +Bonica, et al. Standards Track [Page 13] + +RFC 8335 PROBE February 2018 + + +8. Security Considerations + + The following are legitimate uses of PROBE: + + o to determine the operational status of an interface. + + o 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: + + o interface bandwidth + + o the type of device that supports the interface (e.g., vendor + identity) + + o the operating system version that the above-mentioned device + executes + + Understanding this risk, 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: + + o Enable/disable ICMP Extended Echo functionality. By default, ICMP + Extend Echo functionality is disabled. + + o 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. + + o Define enabled query types (i.e., by name, by index, or by + address); by default, all query types are disabled. + + o For each enabled query type, define the prefixes from which ICMP + Extended Echo Request messages are permitted. + + o 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 + Section 4 for details. + + + + + +Bonica, et al. Standards Track [Page 14] + +RFC 8335 PROBE February 2018 + + + 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. + +9. References + +9.1. Normative References + + [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + . + + [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, DOI 10.17487/RFC0826, November 1982, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", STD 89, + RFC 4443, DOI 10.17487/RFC4443, March 2006, + . + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + . + + [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, + "Extended ICMP to Support Multi-Part Messages", RFC 4884, + DOI 10.17487/RFC4884, April 2007, + . + + [RFC7223] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, + . + + + + +Bonica, et al. Standards Track [Page 15] + +RFC 8335 PROBE February 2018 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +9.2. Informative References + + [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ + IP Tools and Utilities", FYI 30, RFC 2151, + DOI 10.17487/RFC2151, June 1997, + . + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + DOI 10.17487/RFC4594, August 2006, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 16] + +RFC 8335 PROBE February 2018 + + +Appendix A. 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: + + o Count + + o Wait + + o Probing Interface Address + + o Hop Count + + o Proxy Interface Address + + o Local + + o 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. + + + +Bonica, et al. Standards Track [Page 17] + +RFC 8335 PROBE February 2018 + + + 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: + + o an interface name; + + o an address from any address family (e.g., IPv4, IPv6, IEEE 802, + 48-bit MAC, or 64-bit MAC); or + + o 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. + +Acknowledgments + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bonica, et al. Standards Track [Page 18] + +RFC 8335 PROBE February 2018 + + +Authors' Addresses + + Ron Bonica + Juniper Networks + 2251 Corporate Park Drive + Herndon, Virginia 20171 + United States of America + + Email: rbonica@juniper.net + + + Reji Thomas + Juniper Networks + Elnath-Exora Business Park Survey + Bangalore, Karnataka 560103 + India + + Email: rejithomas@juniper.net + + + Jen Linkova + Google + 1600 Amphitheatre Parkway + Mountain View, California 94043 + United States of America + + Email: furry@google.com + + + Chris Lenart + Verizon + 22001 Loudoun County Parkway + Ashburn, Virginia 20147 + United States of America + + Email: chris.lenart@verizon.com + + + Mohamed Boucadair + Orange + Rennes 35000 + France + + Email: mohamed.boucadair@orange.com + + + + + + + +Bonica, et al. Standards Track [Page 19] + -- cgit v1.2.3