GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8335

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 <https://www.iana.org/assignments/address-family-numbers>)
    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,
            <https://www.rfc-editor.org/info/rfc792>.
 [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,
            <https://www.rfc-editor.org/info/rfc826>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [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,
            <https://www.rfc-editor.org/info/rfc4443>.
 [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,
            <https://www.rfc-editor.org/info/rfc4861>.
 [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,
            <https://www.rfc-editor.org/info/rfc4884>.
 [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
            Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
            <https://www.rfc-editor.org/info/rfc7223>.

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, <https://www.rfc-editor.org/info/rfc8174>.

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,
            <https://www.rfc-editor.org/info/rfc2151>.
 [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
            Guidelines for DiffServ Service Classes", RFC 4594,
            DOI 10.17487/RFC4594, August 2006,
            <https://www.rfc-editor.org/info/rfc4594>.

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8335.txt · Last modified: 2018/02/23 01:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki