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
        
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

PROBE:用于探测接口的实用程序

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.

本文档介绍一种称为PROBE的网络诊断工具。PROBE与PING类似,因为它可以用于查询被探测接口的状态,但与PING不同的是,它不需要探测接口和被探测接口之间的双向连接。相反,PROBE需要探测接口和代理接口之间的双向连接。代理接口可以驻留在与探测接口相同的节点上,也可以驻留在探测接口直接连接的节点上。本文档更新了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.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

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.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问https://www.rfc-editor.org/info/rfc8335.

Copyright Notice

版权公告

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2018 IETF信托基金和确定为文件作者的人员。版权所有。

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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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
        
   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
        
1. Introduction
1. 介绍

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.

网络运营商使用PING[RFC2151]测试两个接口之间的双向连接。在本文档中,这些接口称为探测接口和探测接口。PING从探测接口向探测接口发送ICMP[RFC792][RFC4443]回显请求消息。探测接口位于探测节点上,而探测接口位于探测节点上。

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:

如果探测接口收到ICMP回显请求消息,则返回ICMP回显回复。当探测接口收到ICMP回显回复时,它已验证探测接口和探测接口之间的双向连接。具体而言,它已核实:

o The probing node can reach the probed interface.

o 探测节点可以到达探测接口。

o The probed interface is active.

o 被探测的接口处于活动状态。

o The probed node can reach the probing interface.

o 被探测节点可以到达探测接口。

o The probing interface is active.

o 探测接口处于活动状态。

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.

本文档介绍一种称为PROBE的网络诊断工具。PROBE与PING类似,因为它可以用于查询被探测接口的状态,但与PING不同的是,它不需要探测接口和被探测接口之间的双向连接。相反,PROBE需要探测接口和代理接口之间的双向连接。代理接口可以驻留在与探测接口相同的节点上,也可以驻留在探测接口直接连接的节点上。本文档第5节描述了此特性有用的场景。

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.

与PING一样,PROBE在探测节点上执行。它从本地接口(称为探测接口)向代理接口发送ICMP扩展回显请求消息。代理接口驻留在代理节点上。

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.

ICMP扩展回显请求包含ICMP扩展结构,ICMP扩展结构包含接口标识对象。接口标识对象标识被探测的接口。探测接口可以驻留在代理节点上,也可以直接连接到代理节点。

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.

当代理接口收到ICMP扩展回显请求时,代理节点执行访问控制过程。如果授予访问权限,代理节点将确定被探测接口的状态,并返回ICMP扩展回显回复消息。ICMP扩展回显回复指示被探测接口的状态。

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.

如果探测接口位于代理节点上,探测器将确定探测接口的状态,就像它将确定其操作状态一样[RFC7223]。如果oper status等于'up'(1),PROBE报告被探测接口处于活动状态。否则,探测器报告探测接口处于非活动状态。

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.

如果探测接口位于直接连接到代理节点的节点上,并且探测接口出现在IPv4地址解析协议(ARP)表[RFC826]或IPv6邻居缓存[RFC4861]中,则探测报告接口可达性。否则,PROBE报告表条目不存在。

1.1. Terminology
1.1. 术语

This document uses the following terms:

本文件使用以下术语:

o Probing interface: The interface that sends the ICMP Extended Echo Request.

o 探测接口:发送ICMP扩展回显请求的接口。

o Probing node: The node upon which the probing interface resides.

o 探测节点:探测接口所在的节点。

o Proxy interface: The interface to which the ICMP Extended Echo Request message is sent.

o 代理接口:ICMP扩展回显请求消息发送到的接口。

o Proxy node: The node upon which the proxy interface resides.

o 代理节点:代理接口所在的节点。

o Probed interface: The interface whose status is being queried.

o 探测接口:正在查询其状态的接口。

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.

o 探测节点:探测接口所在的节点。如果代理接口和探测接口位于同一节点上,则代理节点也是探测节点。否则,代理节点将直接连接到探测节点。

1.2. Requirements Language
1.2. 需求语言

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.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

2. ICMP Extended Echo Request
2. ICMP扩展回显请求

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.

ICMP扩展回显请求消息是为ICMPv4和ICMPv6定义的。与任何ICMP消息一样,ICMP扩展回显请求消息封装在IP头中。扩展回显请求消息的ICMPv4版本封装在IPv4标头中,而ICMPv6版本封装在IPv6标头中。

Figure 1 depicts the ICMP Extended Echo Request message.

图1描述了ICMP扩展回显请求消息。

       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
        
       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

图1:ICMP扩展回显请求消息

IP Header fields:

IP头字段:

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

o 源地址:源地址标识探测接口。它必须是有效的IPv4或IPv6单播地址。

o Destination Address: The Destination Address identifies the proxy interface. It MUST be a unicast address.

o 目标地址:目标地址标识代理接口。它必须是单播地址。

ICMP fields:

ICMP字段:

o Type: Extended Echo Request. The value for ICMPv4 is 42. The value for ICMPv6 is 160.

o 类型:扩展回显请求。ICMPv4的值为42。ICMPv6的值为160。

o Code: MUST be set to 0 and MUST be ignored upon receipt.

o 代码:必须设置为0,并且在收到时必须忽略。

o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.

o 校验和:对于ICMPv4,请参阅RFC 792。有关ICMPv6,请参阅RFC 4443。

o Identifier: An Identifier to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.

o 标识符:用于帮助将扩展回显响应与扩展回显请求匹配的标识符。可能是0。

o Sequence Number: A Sequence Number to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.

o 序列号:用于帮助将扩展回显响应与扩展回显请求匹配的序列号。可能是0。

o Reserved: This field MUST be set to 0 and ignored upon receipt.

o 保留:此字段必须设置为0,并在收到时忽略。

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 L(本地):如果探测接口位于代理节点上,则设置L位。如果探测接口直接连接到代理节点,则L位是明确的。

o ICMP Extension Structure: The ICMP Extension Structure identifies the probed interface.

o ICMP扩展结构:ICMP扩展结构标识被探测的接口。

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).

[RFC4884]第7节定义了ICMP扩展结构。根据RFC4884,扩展结构只包含一个扩展头,后跟一个或多个对象。当应用于ICMP扩展回显请求消息时,ICMP扩展结构必须仅包含接口标识对象的一个实例(见第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.

如果设置了L位,接口标识对象可以通过名称、索引或地址来标识被探测的接口。如果L位是清除的,接口标识对象必须通过地址标识探测的接口。

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.

如果接口标识对象通过地址标识探测的接口,则该地址可以是任何地址族的成员。例如,ICMPv4扩展回显请求消息可以携带接口标识对象,该对象通过IPv4、IPv6或IEEE 802地址标识探测的接口。同样,ICMPv6扩展回显请求消息可以携带接口标识对象,该对象通过IPv4、IPv6或IEEE 802地址标识探测的接口。

2.1. Interface Identification Object
2.1. 接口标识对象

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:

接口标识对象通过名称、索引或地址标识被探测的接口。与任何其他ICMP扩展对象一样,它包含一个对象头和对象负载。对象标题包含以下字段:

o Class-Num: Interface Identification Object. The value is 3.

o Class Num:接口标识对象。值为3。

o C-Type: Values are (1) Identifies Interface by Name, (2) Identifies Interface by Index, and (3) Identifies Interface by Address.

o C-Type:值为(1)通过名称标识接口,(2)通过索引标识接口,(3)通过地址标识接口。

o Length: Length of the object, measured in octets, including the Object Header and Object Payload.

o 长度:对象的长度,以八位字节为单位,包括对象头和对象有效负载。

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.

如果接口标识对象通过名称标识探测接口,则对象有效负载必须是[RFC7223]中定义的接口名称。如果对象有效负载不会以32位边界终止,则必须用ASCII空字符填充。

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].

如果接口标识对象通过索引标识探测的接口,则长度等于8,有效负载包含If索引[RFC7223]。

If the Interface Identification Object identifies the probed interface by address, the payload is as depicted in Figure 2.

如果Interface Identification对象通过地址标识探测的接口,则有效负载如图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   ....
        
    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

图2:接口标识对象-C-Type 3有效载荷

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 地址族标识符(AFI):此16位字段标识由地址字段表示的地址类型。IANA地址系列号注册表中的所有值(可从<https://www.iana.org/assignments/address-family-numbers>)在该字段中有效。

o Address Length: Number of significant bytes contained by the Address field. (The Address field contains significant bytes and padding bytes.)

o 地址长度:地址字段包含的有效字节数。(地址字段包含有效字节和填充字节。)

o Reserved: This field MUST be set to 0 and ignored upon receipt.

o 保留:此字段必须设置为0,并在收到时忽略。

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.

o 地址:此可变长度字段表示与探测接口关联的地址。如果地址字段不会以32位边界终止,则必须用零填充。

3. ICMP Extended Echo Reply
3. ICMP扩展回显应答

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.

ICMP扩展回显回复消息是为ICMPv4和ICMPv6定义的。与任何ICMP消息一样,ICMP扩展回显回复消息封装在IP报头中。扩展回显回复消息的ICMPv4版本封装在IPv4标头中,而ICMPv6版本封装在IPv6标头中。

Figure 3 depicts the ICMP Extended Echo Reply message.

图3描述了ICMP扩展回显回复消息。

       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|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       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

图3:ICMP扩展回显回复消息

IP Header fields:

IP头字段:

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

o 源地址:从调用扩展回显请求消息的目标地址字段复制。

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

o 目标地址:从调用扩展回显请求消息的源地址字段复制。

ICMP fields:

ICMP字段:

o Type: Extended Echo Reply. The value for ICMPv4 is 43. The value for ICMPv6 is 161.

o 类型:扩展回显回复。ICMPv4的值为43。ICMPv6的值为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 代码:值为(0)无错误,(1)查询格式错误,(2)无此类接口,(3)无此类表条目,(4)多个接口满足查询。

o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.

o 校验和:对于ICMPv4,请参阅RFC 792。有关ICMPv6,请参阅RFC 4443。

o Identifier: Copied from the Identifier field of the invoking Extended Echo Request packet.

o 标识符:从调用扩展回显请求数据包的标识符字段复制。

o Sequence Number: Copied from the Sequence Number field of the invoking Extended Echo Request packet.

o 序列号:从调用扩展回显请求数据包的序列号字段复制。

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 状态:如果代码不等于0,则此字段必须设置为0,并在收到时忽略。同样,如果探测接口位于代理节点上,则此字段必须设置为0,并在收到时忽略。否则,此字段反映与探测接口关联的ARP表或邻居缓存项的状态。值为(0)保留,(1)不完整,(2)可访问,(3)过时,(4)延迟,(5)探测和(6)失败。

o Res: This field MUST be set to 0 and ignored upon receipt.

o Res:此字段必须设置为0,并在收到时忽略。

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 A(活动):如果代码等于0,探测接口位于代理节点上,且探测接口处于活动状态,则设置A位。否则,A位是清楚的。

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 4(IPv4):如果还设置了A位并且IPv4正在探测接口上运行,则设置4位。否则,4位是清除的。

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.

o 6(IPv6):如果还设置了A位并且IPv6正在探测接口上运行,则设置6位。否则,6位是清除的。

4. ICMP Message Processing
4. ICMP消息处理

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:

当节点收到ICMP扩展回显请求消息且以下任何条件适用时,该节点必须以静默方式放弃传入消息:

o The node does not recognize ICMP Extended Echo Request messages.

o 节点无法识别ICMP扩展回显请求消息。

o The node has not explicitly enabled ICMP Extended Echo functionality.

o 该节点未显式启用ICMP扩展回显功能。

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 传入ICMP扩展回显请求携带的源地址未明确授权用于传入ICMP扩展回显请求的L位设置。

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 传入ICMP扩展回显请求携带的源地址未明确授权用于传入ICMP扩展回显请求类型(即通过ifName、IfIndex或通过地址)。

o The Source Address of the incoming message is not a unicast address.

o 传入消息的源地址不是单播地址。

o The Destination Address of the incoming message is a multicast address.

o 传入消息的目标地址是多播地址。

Otherwise, when a node receives an ICMPv4 Extended Echo Request, it MUST format an ICMP Extended Echo Reply as follows:

否则,当节点接收到ICMPv4扩展回显请求时,它必须按如下方式格式化ICMP扩展回显回复:

o Don't Fragment (DF) flag is 1

o 不分段(DF)标志为1

o More Fragments flag is 0

o “更多碎片”标志为0

o Fragment Offset is 0

o 片段偏移量为0

o TTL is 255

o TTL是255

o Protocol is ICMP

o 协议是ICMP

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

当节点收到ICMPv6扩展回显请求时,它必须按如下方式格式化ICMPv6扩展回显回复:

o Hop Limit is 255

o 跳数限制为255

o Next Header is ICMPv6

o 下一个标题是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 将源地址从扩展回显请求消息复制到扩展回显回复的目标地址。

o Copy the Destination Address from the Extended Echo Request message to the Source Address of the Extended Echo Reply.

o 将目标地址从扩展回显请求消息复制到扩展回显回复的源地址。

o Set the DiffServ codepoint to CS0 [RFC4594].

o 将DiffServ代码点设置为CS0[RFC4594]。

o Set the ICMP Type to Extended Echo Reply.

o 将ICMP类型设置为扩展回显回复。

o Copy the Identifier from the Extended Echo Request message to the Extended Echo Reply.

o 将标识符从扩展回显请求消息复制到扩展回显回复。

o Copy the Sequence Number from the Extended Echo Request message to the Extended Echo Reply.

o 将序列号从扩展回显请求消息复制到扩展回显回复。

o Set the Code field as described in Section 4.1.

o 按照第4.1节所述设置代码字段。

o Set the State field to 0.

o 将状态字段设置为0。

o Clear the A-bit, the 4-bit, and the 6-bit.

o 清除A位、4位和6位。

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 如果(1)代码字段等于(0)无错误,(2)设置L位,(3)探测接口处于活动状态,则设置A位。另外,根据需要设置4位和6位。

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 如果代码字段等于(0)无错误且L位为清除,则设置状态字段以反映表示探测接口的ARP表或邻居缓存项的状态。

o Set the Checksum appropriately.

o 适当地设置校验和。

o Forward the ICMP Extended Echo Reply to its destination.

o 将ICMP扩展回显回复转发到其目标。

4.1. Code Field Processing
4.1. 码域处理

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

如果以下任何条件适用,则代码字段必须设置为(1)格式错误的查询:

o The ICMP Extended Echo Request does not include an ICMP Extension Structure.

o ICMP扩展回显请求不包括ICMP扩展结构。

o The ICMP Extension Structure does not include exactly one Interface Identification Object.

o ICMP扩展结构不包括一个接口标识对象。

o The L-bit is clear and the Interface Identification Object identifies the probed interface by ifName or ifIndex.

o L位是清晰的,接口标识对象通过ifName或ifIndex标识探测的接口。

o The query is otherwise malformed.

o 否则,查询的格式不正确。

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.

如果设置了L位且ICMP扩展结构未标识驻留在代理节点上的接口,则代码字段必须设置为(2)无此类接口。

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.

如果L位清除,并且在接口标识对象中找到的地址未出现在IPv4地址解析协议(ARP)表或IPv6邻居缓存中,则必须将代码字段设置为(3)无此类表项。

The Code field MUST be set to (4) Multiple Interfaces Satisfy Query if any of the following conditions apply:

如果以下任何条件适用,则代码字段必须设置为(4)多个接口满足查询:

o The L-bit is set and the ICMP Extension Structure identifies more than one interface that resides in the proxy node.

o 设置L位,ICMP扩展结构标识驻留在代理节点中的多个接口。

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.

o L位是清晰的,在接口标识对象中找到的地址映射到多个IPv4 ARP或IPv6邻居缓存项。

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

否则,代码字段必须设置为(0)无错误。

5. Use Cases
5. 用例

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.

在下面列出的场景中,网络运营商可以使用PROBE来确定被探测接口的状态,但不能将PING用于相同的目的。在所有场景中,假设探测接口和代理接口之间存在双向连接。然而,探测接口和探测接口之间缺乏双向连接。

o The probed interface is unnumbered.

o 探测的接口未编号。

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 探测接口和探测接口之间没有直接连接。探测接口具有IPv6链路本地地址,但没有更全局范围的地址。

o The probing interface runs IPv4 only while the probed interface runs IPv6 only.

o 探测接口仅运行IPv4,而探测接口仅运行IPv6。

o The probing interface runs IPv6 only while the probed interface runs IPv4 only.

o 探测接口仅运行IPv6,而探测接口仅运行IPv4。

o For lack of a route, the probing node cannot reach the probed interface.

o 由于缺少路由,探测节点无法到达探测接口。

6. Updates to RFC 4884
6. 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.

[RFC4884]第4.6节提供了可扩展ICMP消息的列表(即,可以承载ICMP扩展结构的消息)。本文档将ICMP扩展回显请求消息和ICMP扩展回显回复消息添加到该列表中。

7. IANA Considerations
7. IANA考虑

IANA has performed the following actions:

IANA已执行以下操作:

o Added the following to the "ICMP Type Numbers" registry:

o 将以下内容添加到“ICMP类型编号”注册表:

42 Extended Echo Request

42扩展回显请求

Added the following to the "Type 42 - Extended Echo Request" subregistry:

将以下内容添加到“类型42-扩展回显请求”子区域:

(0) No Error

(0) 无误

o Added the following to the "ICMPv6 'type' Numbers" registry:

o 将以下内容添加到“ICMPv6”类型“数字”注册表:

160 Extended Echo Request

160扩展回显请求

As ICMPv6 distinguishes between informational and error messages, and this is an informational message, the value has been assigned from the range 128-255.

由于ICMPv6区分了信息性消息和错误消息,并且这是一条信息性消息,因此已从128-255范围内分配了该值。

Added the following to the "Type 160 - Extended Echo Request" subregistry:

将以下内容添加到“160型-扩展回声请求”子区域:

(0) No Error

(0) 无误

o Added the following to the "ICMP Type Numbers" registry:

o 将以下内容添加到“ICMP类型编号”注册表:

43 Extended Echo Reply

43扩展回音应答

Added the following to the "Type 43 - Extended Echo Reply" subregistry:

将以下内容添加到“43类-扩展回声回复”子区域:

(0) No Error (1) Malformed Query (2) No Such Interface (3) No Such Table Entry (4) Multiple Interfaces Satisfy Query

(0) 没有错误(1)格式错误的查询(2)没有这样的接口(3)没有这样的表条目(4)多个接口满足查询

o Added the following to the "ICMPv6 'type' Numbers" registry:

o 将以下内容添加到“ICMPv6”类型“数字”注册表:

161 Extended Echo Reply

161扩展回音应答

As ICMPv6 distinguishes between informational and error messages, and this is an informational message, the value has been assigned from the range 128-255.

由于ICMPv6区分了信息性消息和错误消息,并且这是一条信息性消息,因此已从128-255范围内分配了该值。

Added the following to the "Type 161 - Extended Echo Reply" subregistry:

将以下内容添加到“161型-扩展回声回复”子区域:

(0) No Error (1) Malformed Query (2) No Such Interface (3) No Such Table Entry (4) Multiple Interfaces Satisfy Query

(0) 没有错误(1)格式错误的查询(2)没有这样的接口(3)没有这样的表条目(4)多个接口满足查询

o Added the following to the "ICMP Extension Object Classes and Class Sub-types" registry:

o 将以下内容添加到“ICMP扩展对象类和类子类型”注册表:

(3) Interface Identification Object

(3) 接口标识对象

Added the following C-types to the "Sub-types - Class 3 - Interface Identification Object" subregistry:

在“子类型-第3类-接口标识对象”子区域中添加了以下C类型:

(0) Reserved (1) Identifies Interface by Name (2) Identifies Interface by Index (3) Identifies Interface by Address

(0) 保留(1)通过名称标识接口(2)通过索引标识接口(3)通过地址标识接口

C-Type values are assigned on a First Come First Serve (FCFS) basis with a range of 0-255.

C型值以先到先得(FCFS)为基础分配,范围为0-255。

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

上述所有代码均以FCFS为基础分配,范围为0-255。

8. Security Considerations
8. 安全考虑

The following are legitimate uses of PROBE:

以下是PROBE的合法使用:

o to determine the operational status of an interface.

o 确定接口的操作状态。

o to determine which protocols (e.g., IPv4 or IPv6) are active on an interface.

o 确定接口上哪些协议(如IPv4或IPv6)处于活动状态。

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:

但是,恶意方可以使用PROBE获取附加信息。例如,恶意方可以使用PROBE来发现接口名称。发现接口名称后,恶意方可能会推断出其他信息。其他信息可能包括:

o interface bandwidth

o 接口带宽

o the type of device that supports the interface (e.g., vendor identity)

o 支持接口的设备类型(例如,供应商标识)

o the operating system version that the above-mentioned device executes

o 上述设备执行的操作系统版本

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:

认识到这一风险,网络运营商制定了限制访问ICMP扩展回显功能的政策。为了实施这些策略,支持ICMP扩展回显功能的节点必须支持以下配置选项:

o Enable/disable ICMP Extended Echo functionality. By default, ICMP Extend Echo functionality is disabled.

o 启用/禁用ICMP扩展回显功能。默认情况下,禁用ICMP扩展回显功能。

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 定义启用的L位设置。默认情况下,设置L位的选项处于启用状态,清除L位的选项处于禁用状态。

o Define enabled query types (i.e., by name, by index, or by address); by default, all query types are disabled.

o 定义启用的查询类型(即按名称、索引或地址);默认情况下,所有查询类型都被禁用。

o For each enabled query type, define the prefixes from which ICMP Extended Echo Request messages are permitted.

o 对于每个启用的查询类型,定义允许ICMP扩展回显请求消息的前缀。

o For each interface, determine whether ICMP Echo Request messages are accepted.

o 对于每个接口,确定是否接受ICMP回显请求消息。

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.

当节点收到未配置为支持的ICMP扩展回显请求消息时,它必须以静默方式放弃该消息。详见第4节。

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.

探测器不得将有关一个虚拟专用网络(VPN)的信息泄漏到另一个虚拟专用网络。因此,当节点接收到ICMP扩展回显请求且代理接口与探测接口位于不同的VPN中时,节点必须返回ICMP扩展回显回复,错误代码等于(2)无此类接口。

In order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages.

为了保护本地资源,实现应该对传入的ICMP扩展回显请求消息进行速率限制。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC792]Postel,J.,“互联网控制消息协议”,STD 5,RFC 792,DOI 10.17487/RFC0792,1981年9月<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>.

[RFC826]Plummer,D.,“以太网地址解析协议:或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”,STD 37,RFC 826,DOI 10.17487/RFC0826,1982年11月<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>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<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>.

[RFC4443]Conta,A.,Deering,S.和M.Gupta,Ed.“互联网协议版本6(IPv6)规范的互联网控制消息协议(ICMPv6)”,STD 89,RFC 4443,DOI 10.17487/RFC4443,2006年3月<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>.

[RFC4861]Narten,T.,Nordmark,E.,Simpson,W.,和H.Soliman,“IP版本6(IPv6)的邻居发现”,RFC 4861,DOI 10.17487/RFC48612007年9月<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>.

[RFC4884]Bonica,R.,Gan,D.,Tappan,D.,和C.Pignataro,“扩展ICMP以支持多部分消息”,RFC 4884,DOI 10.17487/RFC4884,2007年4月<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>.

[RFC7223]Bjorklund,M.,“用于接口管理的YANG数据模型”,RFC 7223,DOI 10.17487/RFC7223,2014年5月<https://www.rfc-editor.org/info/rfc7223>.

[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>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References
9.2. 资料性引用

[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>.

[RFC2151]Kessler,G.和S.Shepard,“互联网和TCP/IP工具及实用程序入门”,FYI 30,RFC 2151,DOI 10.17487/RFC2151,1997年6月<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>.

[RFC4594]Babiarz,J.,Chan,K.,和F.Baker,“区分服务服务类的配置指南”,RFC 4594,DOI 10.17487/RFC4594,2006年8月<https://www.rfc-editor.org/info/rfc4594>.

Appendix A. The PROBE Application
附录A.探头应用

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.

探测应用程序接受输入参数,设置计数器,并在计数器等于0时输入要退出的循环。在循环的每次迭代中,探测器发出ICMP扩展回显请求,递减计数器,设置计时器,然后等待。ICMP扩展回显请求包括标识符和序列号。

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.

如果带有相同标识符和序列号的ICMP扩展回显回复到达,则探测器会将该消息返回的信息转发给其用户。但是,在循环的每次迭代中,探测器都会等待计时器过期,而不管扩展回显回复消息是否到达。

PROBE accepts the following parameters:

PROBE接受以下参数:

o Count

o 计数

o Wait

o 等待

o Probing Interface Address

o 探测接口地址

o Hop Count

o 跳数

o Proxy Interface Address

o 代理接口地址

o Local

o 地方的

o Probed Interface Identifier

o 探测接口标识符

Count is a positive integer whose default value is 3. Count determines the number of times that PROBE iterates through the above-mentioned loop.

Count是一个正整数,其默认值为3。Count确定探测器在上述循环中迭代的次数。

Wait is a positive integer whose minimum and default values are 1. Wait determines the duration of the above-mentioned timer, measured in seconds.

Wait是一个正整数,其最小值和默认值为1。等待确定上述计时器的持续时间,以秒为单位。

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.

探测接口地址指定ICMP扩展回显请求的源地址。探测接口地址必须是单播地址,并且必须标识驻留在探测节点上的接口。

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.

代理接口地址标识ICMP扩展回显请求消息发送到的接口。它必须是IPv4或IPv6单播地址。如果是IPv4地址,探测器将发出ICMPv4消息。如果是IPv6地址,探测器将发出ICMPv6消息。

Local is a boolean value. It is TRUE if the proxy and probed interfaces both reside on the same node. Otherwise, it is FALSE.

Local是一个布尔值。如果代理和探测接口都位于同一节点上,则为真。否则,这是错误的。

The Probed Interface Identifier identifies the probed interface. It is one of the following:

探测接口标识符标识探测接口。它是以下内容之一:

o an interface name;

o 接口名称;

o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 48-bit MAC, or 64-bit MAC); or

o 来自任何地址系列的地址(例如,IPv4、IPv6、IEEE 802、48位MAC或64位MAC);或

o an if-index.

o if索引。

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.

如果探测的接口标识符是地址,则它不需要与代理接口地址属于同一地址族。例如,探测器接受IPv4代理接口地址和IPv6探测接口标识符。

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.

感谢Sowmini Varadhan、Jeff Haas、Carlos Pignataro、Jonathan Looney、Dave Thaler、Mikio Hara、Joel Halpern、Yaron Sheffer、Stefan Winter、Jean-Michel Combes、Amanda Barber和Joe Touch对本文件进行了深思熟虑的审阅。

Authors' Addresses

作者地址

Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 United States of America

Ron Bonica Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171

   Email: rbonica@juniper.net
        
   Email: rbonica@juniper.net
        

Reji Thomas Juniper Networks Elnath-Exora Business Park Survey Bangalore, Karnataka 560103 India

Reji Thomas Juniper Networks Elnath Exora商业园调查印度卡纳塔克邦班加罗尔560103

   Email: rejithomas@juniper.net
        
   Email: rejithomas@juniper.net
        

Jen Linkova Google 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America

Jen Linkova谷歌1600圆形剧场公园路山景,加利福尼亚州94043美利坚合众国

   Email: furry@google.com
        
   Email: furry@google.com
        

Chris Lenart Verizon 22001 Loudoun County Parkway Ashburn, Virginia 20147 United States of America

Chris Lenart Verizon 22001美国弗吉尼亚州阿什本市劳顿县公园路,邮编:20147

   Email: chris.lenart@verizon.com
        
   Email: chris.lenart@verizon.com
        

Mohamed Boucadair Orange Rennes 35000 France

穆罕默德·布卡代尔·奥兰治·雷恩35000法国

   Email: mohamed.boucadair@orange.com
        
   Email: mohamed.boucadair@orange.com