Internet Engineering Task Force (IETF) S. Venaas
Request for Comments: 6450 Cisco Systems
Category: Standards Track December 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Venaas
Request for Comments: 6450 Cisco Systems
Category: Standards Track December 2011
ISSN: 2070-1721
Multicast Ping Protocol
多播Ping协议
Abstract
摘要
The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping".
本文档中指定的多播Ping协议允许检查端点是否可以接收多播—源特定多播（SSM）和任何源多播（ASM）。它还可用于获取额外的多播相关信息，如多播树设置时间。该协议基于名为“ssmping”和“asmping”的工具的实现。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6450.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6450.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Architecture ....................................................3
3. Protocol Specification ..........................................6
3.1. Option Format ..............................................7
3.2. Defined Options ............................................7
3.3. Packet Format .............................................13
3.4. Message Types and Options .................................13
3.5. Rate Limiting .............................................15
3.5.1. Message Rate Variables .............................16
4. Client Behaviour ...............................................16
5. Server Behaviour ...............................................18
6. Recommendations for Implementers ...............................19
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. Acknowledgments ................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Architecture ....................................................3
3. Protocol Specification ..........................................6
3.1. Option Format ..............................................7
3.2. Defined Options ............................................7
3.3. Packet Format .............................................13
3.4. Message Types and Options .................................13
3.5. Rate Limiting .............................................15
3.5.1. Message Rate Variables .............................16
4. Client Behaviour ...............................................16
5. Server Behaviour ...............................................18
6. Recommendations for Implementers ...............................19
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. Acknowledgments ................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
The Multicast Ping Protocol specified in this document allows for checking multicast connectivity. In addition to checking reception of multicast (SSM or ASM), the protocol can provide related information, such as multicast tree setup time, the number of hops the packets have traveled, and packet delay and loss. This functionality resembles, in part, the ICMP Echo Request/Reply mechanism [RFC0792], but uses UDP [RFC0768] and requires that both a client and a server implement this protocol. Intermediate routers are not required to support this protocol. They forward protocol messages and data traffic as usual.
本文档中指定的多播Ping协议允许检查多播连接。除了检查多播（SSM或ASM）的接收之外，该协议还可以提供相关信息，例如多播树的建立时间、数据包经过的跳数以及数据包延迟和丢失。此功能部分类似于ICMP回送请求/回复机制[RFC0792]，但使用UDP[RFC0768]，并且要求客户端和服务器都实现此协议。中间路由器不需要支持此协议。它们像往常一样转发协议消息和数据流量。
This protocol is based on the current implementation of the ssmping and asmping tools [IMPL], which are widely used by the Internet community to conduct multicast connectivity tests.
该协议基于ssmping和asmping工具[IMPL]的当前实现，互联网社区广泛使用这些工具进行多播连接测试。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Before describing the protocol in detail, we provide a brief overview of how the protocol may be used and what information it may provide.
在详细描述该协议之前，我们将简要概述如何使用该协议以及它可能提供的信息。
The protocol is used between clients and servers to check multicast connectivity. Servers are multicast sources, and clients are multicast receivers. A server may be configured with a set of ranges of multicast addresses that can be used for testing, or it may use some implementation defaults. Depending on the server configuration or the implementation, it may control which clients (which unicast addresses) are allowed to use different group ranges, and also whether clients can select a group address, or if the group address is selected by the server. Whether several clients are allowed to simultaneously use the same multicast address also depends on configuration and/or implementation.
该协议用于客户端和服务器之间检查多播连接。服务器是多播源，客户端是多播接收器。服务器可以配置一组可用于测试的多播地址范围，也可以使用一些实现默认值。根据服务器配置或实现，它可以控制允许哪些客户端（哪些单播地址）使用不同的组范围，以及客户端是否可以选择组地址，或者是否由服务器选择组地址。是否允许多个客户端同时使用相同的多播地址还取决于配置和/或实现。
In addition to the above state, a server normally has runtime soft state. The server must generally perform rate limiting to restrict the number of client requests it handles. This rate limiting is per-client IP address. This state need usually only be maintained for a few seconds, depending on the limit used. If the server provides unique multicast addresses to clients, it must also have soft state for tracking which multicast addresses are used by which client IP address. This state should expire if the server has not received requests within a few minutes. The exact timeout should ideally be configurable to cope with different environments. If a client is expected to perform multicast ping checks continuously for a long period of time, and to cope with requests not reaching the client for several minutes, then this timeout needs to be extended. In order to verify the client IP address, the server should perform a return routability check by giving the client a non-predictable session ID. This would then also be part of the server soft state for that client.
除上述状态外，服务器通常还具有运行时软状态。服务器通常必须执行速率限制，以限制其处理的客户端请求数。此速率限制为每个客户端IP地址。此状态通常只需保持几秒钟，具体取决于使用的限制。如果服务器向客户端提供唯一的多播地址，它还必须具有软状态以跟踪哪个客户端IP地址使用哪个多播地址。如果服务器在几分钟内未收到请求，此状态将过期。理想情况下，精确的超时应该是可配置的，以应对不同的环境。如果期望客户机长时间连续执行多播ping检查，并处理几分钟内未到达客户机的请求，则需要延长此超时。为了验证客户端IP地址，服务器应通过向客户端提供不可预测的会话ID来执行返回路由性检查。这也将是该客户端的服务器软状态的一部分。
Before it can perform a multicast ping test, a client must know the unicast address of a server. In addition, it may be configured with a multicast address or range to use. In that case, the client will tell the server which group or range it wishes to use. If not, the server is left to decide the group. Normally, a client sends Default-Client-Request-Rate requests per second. It may, however, be configured to use another rate. See the definition of Default-Client-Request-Rate in Section 3.5.1. Note that the value can be less than 1.
在执行多播ping测试之前，客户端必须知道服务器的单播地址。此外，它可以配置多播地址或使用范围。在这种情况下，客户端将告诉服务器希望使用哪个组或范围。如果不是，则由服务器决定组。通常，客户机每秒发送默认的客户机请求速率请求。但是，可以将其配置为使用其他速率。参见第3.5.1节中的默认客户端请求速率定义。请注意，该值可以小于1。
At runtime, a client generates a client ID that is unique for the ping test. This ID is included in all messages sent by the client. Further, if not supplied with a specific group address, the client will receive from the server a group address that is used for the ping requests. It may also receive a Session ID from the server. The client ID, group address, and Session ID (if received) will then be fixed for all ping requests in this session. When a client receives replies from a server, it will verify the client ID in the reply, and ignore it if not matching what it used in the requests. For each reply, it may print or record information like round trip time, number of hops, etc. The client may, once a ping session is ended, calculate and print or record statistics based on the entire ping session.
在运行时，客户端生成一个客户端ID，该ID对于ping测试是唯一的。此ID包含在客户端发送的所有消息中。此外，如果没有提供特定的组地址，客户端将从服务器接收用于ping请求的组地址。它还可以从服务器接收会话ID。客户端ID、组地址和会话ID（如果收到）将被固定用于此会话中的所有ping请求。当客户端从服务器接收到答复时，它将验证答复中的客户端ID，如果与请求中使用的ID不匹配，则忽略该ID。对于每个回复，它可以打印或记录诸如往返时间、跳数等信息。一旦ping会话结束，客户端可以基于整个ping会话计算、打印或记录统计信息。
The typical protocol usage is as follows:
典型的协议用法如下所示：
A server runs continuously to serve requests from clients. A client has somehow learned the unicast address of the server and tests the multicast reception from the server.
服务器持续运行以服务来自客户端的请求。客户端以某种方式了解了服务器的单播地址，并测试了来自服务器的多播接收。
The client application will then send a unicast message to the server, asking for a group to use. Optionally, a user may request a specific group or scope, in which case the client will ask for a group matching the user's request. The server will respond with a group to use, or an error if no group is available.
然后，客户端应用程序将向服务器发送单播消息，请求组使用。或者，用户可以请求特定的组或范围，在这种情况下，客户端将请求与用户请求匹配的组。服务器将使用要使用的组进行响应，如果没有可用的组，则会出现错误。
Next, for ASM, the client joins an ASM group G, while for SSM it joins a channel (S,G), where G is the multicast group address specified by the server, and S is the unicast address used to reach the server.
接下来，对于ASM，客户端加入ASM组G，而对于SSM，客户端加入通道（S，G），其中G是服务器指定的多播组地址，S是用于到达服务器的单播地址。
After joining the group/channel, the client unicasts multicast ping requests to the server. The requests are sent using UDP with the destination port set to the standardised multicast ping port (9903). The requests are sent periodically to the server. The rate is by default Default-Client-Request-Rate (Section 3.5.1) requests per second, but the client may be configured to use another rate. These requests contain a sequence number and, typically, a timestamp. The requests are echoed by the server, which may add a few options.
加入组/通道后，客户端单播多播ping请求到服务器。使用UDP发送请求，目标端口设置为标准化多播ping端口（9903）。请求会定期发送到服务器。该速率默认为每秒客户端请求速率（第3.5.1节），但客户端可配置为使用其他速率。这些请求包含一个序列号，通常还有一个时间戳。服务器会回显请求，这可能会添加一些选项。
For each request, the server sends two replies. One reply is unicast to the source IP address and source UDP port of the requesting client. The other reply is multicast to the requested multicast group G and the source UDP port of the requesting client.
对于每个请求，服务器发送两个回复。一个应答是单播到请求客户端的源IP地址和源UDP端口。另一个应答是多播到请求的多播组G和请求客户端的源UDP端口。
Both replies are sent from the same port on which the request was received. The server should specify the TTL (IPv4 time-to-live or IPv6 hop-count) used for both the unicast and multicast messages (TTL of at least 64 is recommended) by including a TTL option. This allows the client to compute the number of hops. The client should leave the group/channel when it has finished its measurements.
这两个回复都是从接收请求的同一端口发送的。服务器应通过包含TTL选项来指定用于单播和多播消息的TTL（IPv4生存时间或IPv6跃点计数）（建议TTL至少为64）。这允许客户端计算跳数。客户端完成测量后应离开组/通道。
By use of this protocol, a client (or a user of the client) can obtain information about several multicast delivery characteristics. First, by receiving unicast replies, the client can verify that the server is receiving the unicast requests, and is operational and responding. Hence, provided that the client receives unicast replies, a failure to receive multicast indicates either a multicast problem or a multicast administrative restriction. If it does receive multicast, it knows not only that it can receive multicast traffic but that it may also estimate the amount of time it took to establish the multicast tree (at least if it is in the range of seconds), whether there are packet drops, and the length and variation of round trip times (RTTs).
通过使用该协议，客户机（或客户机的用户）可以获得有关多播交付特性的信息。首先，通过接收单播回复，客户机可以验证服务器是否正在接收单播请求，以及是否可以运行和响应。因此，如果客户端接收到单播回复，则接收多播失败指示多播问题或多播管理限制。如果它确实接收到多播，它不仅知道它可以接收多播通信量，还知道它还可以估计建立多播树所花费的时间量（至少如果它在秒的范围内），是否存在丢包，以及往返时间（RTT）的长度和变化。
For unicast, the RTT is the time from when the unicast request is sent to the time when the reply is received. The measured multicast RTT also references the client's unicast request. By specifying the TTL of the replies when they are originated, the client can also determine the number of router hops it is from the source. Since similar information is obtained in the unicast replies, the host may compare its multicast and unicast results and is able to check for differences, such as the number of hops, and RTT.
对于单播，RTT是从发送单播请求到接收回复的时间。测量的多播RTT还引用客户端的单播请求。通过指定发起应答时应答的TTL，客户端还可以确定来自源的路由器跳数。由于在单播应答中获得类似的信息，因此主机可以比较其多播和单播结果，并且能够检查差异，例如跳数和RTT。
The number of multicast hops and changes in the number of hops over time may reveal details about the multicast tree and multicast tree changes. Provided that the server sends the unicast and multicast replies nearly simultaneously, the client may also be able to measure the difference in one-way delay for unicast and multicast on the path from server to client.
多播跃点数和跃点数随时间的变化可能揭示多播树和多播树变化的细节。如果服务器几乎同时发送单播和多播回复，则客户端还可以测量从服务器到客户端的路径上单播和多播的单向延迟差异。
Servers may optionally specify a timestamp. This may be useful, since the unicast and multicast replies cannot be sent simultaneously (the delay is dependent on the host's operating system and load).
服务器可以选择指定时间戳。这可能很有用，因为单播和多播回复不能同时发送（延迟取决于主机的操作系统和负载）。
There are four different message types:
有四种不同的消息类型：
o Echo Request and Echo Reply messages, which are used for the actual measurements.
o 回送请求和回送回复消息，用于实际测量。
o An Init message, which SHOULD be used to initialise a ping session and negotiate which group to use.
o 初始化消息，用于初始化ping会话并协商使用哪个组。
o A Server Response message, which is mainly used in response to the Init message.
o 服务器响应消息，主要用于响应Init消息。
The messages MUST always be in network byte order. UDP checksums MUST always be used.
消息必须始终按网络字节顺序排列。必须始终使用UDP校验和。
The messages share a common format: one octet specifying the message type, followed by a number of options in TLV (Type, Length, and Value) format. This makes the protocol easily extendible.
这些消息共享一种通用格式：一个八位字节指定消息类型，后面是许多TLV（类型、长度和值）格式的选项。这使得协议易于扩展。
Message types in the range 0-253 are reserved and available for allocation in an IANA registry. Message types 254 and 255 are freely available for experimental use. See Section 7.
0-253范围内的消息类型是保留的，可在IANA注册表中分配。消息类型254和255可免费供实验使用。见第7节。
The Init message generally contains some prefix options asking the server for a group from one of the specified prefixes. The server responds with a Server Response message that contains the group address to use, or possibly prefix options describing what multicast groups the server may be able to provide.
Init消息通常包含一些前缀选项，要求服务器从指定的前缀中选择一个组。服务器使用服务器响应消息进行响应，该消息包含要使用的组地址，或者可能包含描述服务器可能能够提供的多播组的前缀选项。
For an Echo Request, the client includes a number of options, and a server MAY simply echo the contents (only changing the message type) without inspecting the options if it does not support any options. This might be true for a simple Multicast Ping Protocol server, but it severely limits what information a client can obtain and hence makes the protocol less useful. However, the server SHOULD add a TTL option (allowing the client to determine the number of router hops a reply has traversed), and there are other options that a server implementation MAY support; e.g., the client may ask for certain information or a specific behaviour from the server. The Echo Reply messages (one unicast and one multicast) MUST first contain the exact options from the request (in the same order), and then, immediately following, any options appended by the server. A server MUST NOT process unknown options, but they MUST still be included in the Echo Reply. A client MUST ignore any unknown options.
对于回显请求，客户机包括许多选项，如果服务器不支持任何选项，则服务器可能只回显内容（仅更改消息类型），而不检查选项。对于一个简单的多播Ping协议服务器来说，这可能是正确的，但它严重限制了客户机可以获得的信息，从而降低了协议的实用性。但是，服务器应该添加一个TTL选项（允许客户端确定应答所经过的路由器跳数），并且服务器实现可能支持其他选项；e、 例如，客户端可能要求服务器提供某些信息或特定行为。回送回复消息（一个单播和一个多播）必须首先包含来自请求的确切选项（顺序相同），然后紧接着是服务器附加的任何选项。服务器不能处理未知选项，但它们仍必须包含在回送回复中。客户端必须忽略任何未知选项。
The size of the protocol messages is generally smaller than the Path MTU, and fragmentation is not a concern. There may, however, be cases where the Path MTU is really small, or where a client sends large requests in order to verify that it can receive fragmented multicast datagrams. This document does not specify whether Path MTU Discovery should be performed, etc. A possible extension could be an option where a client requests Path MTU Discovery and receives the current Path MTU from the server.
协议消息的大小通常小于路径MTU，不需要考虑碎片。然而，在某些情况下，MTU路径可能非常小，或者客户机发送大请求以验证其是否可以接收分段多播数据报。本文档未指定是否应执行路径MTU发现等。可能的扩展可以是一个选项，其中客户端请求路径MTU发现并从服务器接收当前路径MTU。
This document defines a number of different options. Some options do not require processing by servers and are simply returned unmodified in the reply. There are, however, other client options that the server may care about, as well as server options that may be requested by a client. Unless otherwise specified, an option MUST NOT be used multiple times in the same message.
本文档定义了许多不同的选项。有些选项不需要服务器处理，只需在回复中返回而不作修改。但是，服务器可能关心其他客户端选项，以及客户端可能请求的服务器选项。除非另有规定，否则同一消息中不得多次使用选项。
All options are TLVs formatted as below.
所有选项的TLV格式如下所示。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets) specifies the option.
类型（2个八位字节）指定该选项。
Length (2 octets) specifies the length of the value field. Depending on the option type, it can be from 0 to 65535.
长度（2个八位字节）指定值字段的长度。根据选项类型，它可以是0到65535。
Value must always be of the specified length. See the respective option definitions for possible values. If the length is 0, the value field is not included.
值必须始终具有指定的长度。有关可能的值，请参见相应的选项定义。如果长度为0，则不包括值字段。
This document defines the following options: Version (0), Client ID (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), Option Request (5), Server Information (6), TTL (9), Multicast Prefix (10), Session ID (11), and Server Timestamp (12). Option values 7 and 8 are deprecated and must not be allocated by any future document. The options are defined below.
本文档定义了以下选项：版本（0）、客户端ID（1）、序列号（2）、客户端时间戳（3）、多播组（4）、选项请求（5）、服务器信息（6）、TTL（9）、多播前缀（10）、会话ID（11）和服务器时间戳（12）。选项值7和8已弃用，以后的任何文档都不能分配。选项定义如下。
Option types in the range 0-65531 are reserved and available for allocation in an IANA registry. Option types in the range 65532-65535 are not registered and are freely available for experimental use. See Section 7.
0-65531范围内的选项类型是保留的，可在IANA注册表中分配。65532-65535范围内的选项类型未注册，可免费供实验使用。见第7节。
Version, type 0
版本，键入0
Length MUST be 1. This option MUST always be included in all messages, and for the current specified protocol this value MUST be set to 2 (in decimal). Note that there are implementations of older revisions of this protocol that only partly follow this specification. They can be regarded as version 1 and do not use this option. If a server receives a message with a version other than 2 (or missing), the server SHOULD (unless it supports the particular version) send a Server Response message back with version set to 2. This tells the client that the server expects version 2 messages. Client ID and Sequence Number options MUST be echoed if present, so that a client can be certain it is a response to one of its messages, and to exactly which message. The server SHOULD NOT include any other options. A client receiving a response with a version other than 2 MUST stop sending requests to the server (unless it supports the particular version).
长度必须为1。此选项必须始终包含在所有消息中，对于当前指定的协议，此值必须设置为2（十进制）。请注意，本协议的一些较旧版本的实现仅部分遵循本规范。它们可以被视为版本1，不使用此选项。如果服务器接收到版本不是2（或缺少）的消息，则服务器应（除非支持特定版本）将版本设置为2的服务器响应消息发回。这会告诉客户端服务器需要版本2消息。如果存在客户机ID和序列号选项，则必须回显，以便客户机可以确定它是对其消息之一的响应，以及确切响应的消息。服务器不应包括任何其他选项。接收版本不是2的响应的客户端必须停止向服务器发送请求（除非它支持特定版本）。
Client ID, type 1
客户端ID，类型1
Length MUST be non-zero. A client SHOULD always include this option in all messages (both Init and Echo Request). The client may use any value it likes to detect whether a reply is a reply to its Init/Echo Request or not. A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Echo Reply). The value might be a pseudo-random byte string that is likely to be unique, possibly combined with the client IP address. Predictability is not a big concern here. This is used by the client to ensure that server messages are in response to its requests. In some cases, a client may receive multicast responses to queries from other clients. It is left to the client implementer how to use this option.
长度必须为非零。客户端应始终在所有消息（Init和Echo请求）中包含此选项。客户端可以使用它喜欢的任何值来检测回复是否是对其Init/Echo请求的回复。服务器应将此视为不透明数据，并且必须在回复中回显此选项（如果存在）（服务器响应和回显回复）。该值可能是一个伪随机字节字符串，该字符串可能是唯一的，可能与客户端IP地址组合在一起。可预测性在这里不是一个大问题。客户端使用它来确保服务器消息响应其请求。在某些情况下，客户机可能会收到对来自其他客户机的查询的多播响应。如何使用此选项留给客户机实现者。
Sequence Number, type 2
序列号，类型2
Length MUST be 4. A client MUST always include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply (or Server Response message on error). The sequence number is a 32-bit integer. Values typically start at 1 and increase by one for each Echo Request in a sequence.
长度必须为4。客户端必须始终在回显请求消息中包含此消息，而不能在初始化消息中包含此消息。回复回显请求消息的服务器必须将其复制到回显回复（或错误时的服务器响应消息）中。序列号是32位整数。值通常从1开始，并为序列中的每个回显请求增加1。
Client Timestamp, type 3
客户端时间戳，类型3
Length MUST be 8. A client SHOULD include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply. The timestamp specifies the time when the Echo Request message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second specified in the first 4 bytes. This option would typically be used by a client to compute round trip times.
长度必须为8。客户端应该在回显请求消息中包含此消息，而不能在初始化消息中包含此消息。回复回显请求消息的服务器必须将其复制到回显回复中。时间戳指定发送回显请求消息的时间。前4个字节指定自历元（0000 UTC 1970年1月1日）起的秒数。接下来的4个字节指定自前4个字节中指定的第二个字节起的微秒数。客户机通常会使用此选项来计算往返时间。
Note that while this protocol uses the above 32-bit format, it would have been better to use another format, such as the one defined in NTPv4 [RFC5905]. This should be considered for future extensions of the protocol.
请注意，虽然此协议使用上述32位格式，但最好使用另一种格式，如NTPv4[RFC5905]中定义的格式。这一点应在今后延长议定书时加以考虑。
Multicast Group, type 4
多播组，类型4
Length MUST be greater than 2. It MAY be used in Server Response messages to tell the client what group to use in subsequent Echo Request messages. It MUST be used in Echo Request messages to tell the server what group address to respond to (this group would typically be previously obtained in a Server Response message). It MUST be used in Echo Reply messages (copied from the Echo Request message). It MUST NOT be used in Init messages. The format of the option value is as below.
长度必须大于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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for Internet address families [ADDRFAMILY]. This is followed by the group address. Length of the option value will be 6 for IPv4, and 18 for IPv6.
地址族是IANA为Internet地址族[ADDRFAMILY]分配的值0-65535。然后是组地址。选项值的长度对于IPv4为6，对于IPv6为18。
Option Request, type 5
选项请求，类型5
Length MUST be greater than 1. This option MAY be used in client messages (Init and Echo Request messages). A server MUST NOT send this option, except that if it is present in an Echo Request message, the server MUST echo it in replies (Echo Reply message) to the Echo Request. This option contains a list of option types for options that the client is requesting
长度必须大于1。此选项可用于客户端消息（Init和Echo请求消息）。服务器不得发送此选项，除非它出现在回显请求消息中，服务器必须在回显请求的回复（回显回复消息）中回显它。此选项包含客户端请求的选项的选项类型列表
from the server. Support for this option is OPTIONAL for both clients and servers. The length of this option will be a non-zero even number, since it contains one or more option types that are two octets each. The format of the option value is as below.
从服务器。对该选项的支持对于客户端和服务器都是可选的。此选项的长度将为非零偶数，因为它包含一个或多个选项类型，每个选项类型为两个八位字节。选项值的格式如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
This option might be used by the client to ask the server to include options like Server Timestamp or Server Information. A client MAY request Server Information in Init messages; it MUST NOT request it in other messages. A client MAY request a Server Timestamp in Echo Request messages; it MUST NOT request it in other messages. Subject to enforcing the above restrictions, a server supporting this option SHOULD include the requested options in responses (Echo Reply messages) to the Echo Request containing the Option Request option. The server may, according to implementation or local configuration, not necessarily include all the requested options, or possibly none. Any options included are appended to the echoed options, similar to other options included by the server.
客户端可能会使用此选项要求服务器包含服务器时间戳或服务器信息等选项。客户端可以在Init消息中请求服务器信息；它不能在其他消息中请求它。客户端可以在Echo请求消息中请求服务器时间戳；它不能在其他消息中请求它。在执行上述限制的前提下，支持此选项的服务器应在包含选项请求选项的Echo请求的响应（Echo Reply messages）中包含请求的选项。根据实现或本地配置，服务器可能不一定包括所有请求的选项，也可能不包括任何选项。与服务器包含的其他选项类似，包含的任何选项都会附加到回显选项中。
Server Information, type 6
服务器信息，类型6
Length MUST be non-zero. It MAY be used in Server Response messages and MUST NOT be used in other messages. Support for this option is OPTIONAL. A server supporting this option SHOULD add it in Server Response messages if and only if requested by the client. The value is a UTF-8 [RFC3629] string that might contain vendor and version information for the server implementation. It may also contain information on which options the server supports. An interactive client MAY support this option, and SHOULD then allow a user to request this string and display it. Although support for this is OPTIONAL, we say that a server SHOULD return it if requested, since this may be helpful to a user running the client. It is, however, purely informational; it is not needed for the protocol to function.
长度必须为非零。它可以在服务器响应消息中使用，不得在其他消息中使用。对该选项的支持是可选的。当且仅当客户端请求时，支持此选项的服务器应将其添加到服务器响应消息中。该值是UTF-8[RFC3629]字符串，可能包含服务器实现的供应商和版本信息。它还可能包含服务器支持哪些选项的信息。交互式客户端可能支持此选项，然后应允许用户请求并显示此字符串。尽管对此的支持是可选的，但我们认为服务器应该在请求时返回它，因为这可能对运行客户机的用户有所帮助。然而，它纯粹是信息性的；协议不需要它来运行。
Deprecated, type 7
已弃用，类型7
This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message).
此选项代码值由本协议版本1的实现使用，在此版本中未使用。服务器必须将其视为未知选项（如果收到，则不进行处理，但如果在回送请求消息中收到，则必须在回送回复消息中回送）。
Deprecated, type 8
已弃用，类型8
This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message).
此选项代码值由本协议版本1的实现使用，在此版本中未使用。服务器必须将其视为未知选项（如果收到，则不进行处理，但如果在回送请求消息中收到，则必须在回送回复消息中回送）。
TTL, type 9
TTL，9型
Length MUST be 1. This option contains a single octet specifying the TTL of an Echo Reply message. Every time a server sends a unicast or multicast Echo Reply message, it SHOULD include this option specifying the TTL. This is used by clients to determine the number of hops the messages have traversed. It MUST NOT be used in other messages. A server SHOULD specify this option if it knows what the TTL of the Echo Reply will be. In general, the server can specify a specific TTL to the host stack. Note that the TTL is not necessarily the same for unicast and multicast. Also note that this option SHOULD be included even when not requested by the client. The protocol will work even if this option is not included, but it limits what information a client can obtain.
长度必须为1。此选项包含一个八位字节，用于指定回显回复消息的TTL。每次服务器发送单播或多播回显回复消息时，它都应该包含指定TTL的此选项。客户端使用它来确定消息经过的跃点数。不得在其他消息中使用它。如果服务器知道回显回复的TTL是什么，则应指定此选项。通常，服务器可以为主机堆栈指定特定的TTL。注意，对于单播和多播，TTL不一定相同。还要注意，即使客户没有要求，也应包括此选项。即使不包括此选项，该协议也可以工作，但它限制了客户端可以获取的信息。
If the server did not include this TTL option, there is no reliable way for the client to know the initial TTL of the Echo Reply, and therefore the client SHOULD NOT attempt to calculate the number of hops the message has traversed.
如果服务器未包含此TTL选项，则客户端无法可靠地知道回显回复的初始TTL，因此客户端不应尝试计算消息经过的跃点数。
Multicast Prefix, type 10
多播前缀，类型10
Length MUST be greater than 2. It MAY be used in Init messages to request a group within the prefix(es), and it MAY be used in Server Response messages to tell the client from what prefix(es) it may try to obtain a group. It MUST NOT be used in Echo Request/Reply messages. Note that this option MAY be included multiple times to specify multiple prefixes.
长度必须大于2。它可以在Init消息中用于请求前缀内的组，也可以在服务器响应消息中用于告知客户端它可以尝试从哪个前缀获取组。不得在回显请求/回复消息中使用。请注意，此选项可能包含多次以指定多个前缀。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for Internet address families [ADDRFAMILY]. This is followed by a prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special "wildcard" use discussed below), and finally a group address. For any family, prefix length 0 means that any multicast address from that family is acceptable. This is what we call "wildcard". The group address need only contain enough octets to cover the prefix length bits (i.e., the group address would have to be 3 octets long if the prefix length is 17-24, and there need be no group address for the wildcard with prefix length 0). Any bits past the prefix length MUST be ignored. For IPv4, the option value length will be 4-7, while for IPv6, it will be 4-19, and for the wildcard, it will be 3.
地址族是IANA为Internet地址族[ADDRFAMILY]分配的值0-65535。然后是前缀长度（IPv4为4-32，IPv6为8-128，下面讨论的特殊“通配符”使用为0），最后是组地址。对于任何族，前缀长度0表示该族的任何多播地址都是可接受的。这就是我们所说的“通配符”。组地址只需要包含足够的八位字节来覆盖前缀长度位（即，如果前缀长度为17-24，则组地址必须为3个八位字节长，并且前缀长度为0的通配符不需要组地址）。必须忽略超过前缀长度的任何位。对于IPv4，选项值长度为4-7，而对于IPv6，选项值长度为4-19，对于通配符，选项值长度为3。
Session ID, type 11
会话ID，类型11
Length MUST be 4 or larger. A server SHOULD include this in Server Response messages. If a client receives this option in a message, the client MUST echo the Session ID option in subsequent Echo Request messages, with the exact same value. The Session ID may help the server in keeping track of clients and possibly manage per-client state. The value of a new Session ID SHOULD be a pseudo-random byte string that is hard to predict; see [RFC4086]. The string MUST be at least 4 bytes long. The Session ID can be used to mitigate spoofing of the source address of Echo Request messages. We say that this option SHOULD be used, because it is important for security reasons. There may, however, be environments where this is not required. See Section 8, "Security Considerations", for details.
长度必须为4或更大。服务器应在服务器响应消息中包含此消息。如果客户机在消息中收到此选项，则客户机必须在后续的echo请求消息中使用完全相同的值回显会话ID选项。会话ID可以帮助服务器跟踪客户端，并可能管理每个客户端的状态。新会话ID的值应该是难以预测的伪随机字节字符串；参见[RFC4086]。字符串长度必须至少为4字节。会话ID可用于缓解对回显请求消息源地址的欺骗。我们说应该使用这个选项，因为出于安全原因，它很重要。但是，在某些环境中可能不需要这样做。详见第8节“安全注意事项”。
Server Timestamp, type 12
服务器时间戳，类型12
Length MUST be 8 bytes. A server supporting this option SHOULD include it in Echo Reply messages, if requested by the client. The timestamp specifies the time when the Echo Reply message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second specified in the first 4 bytes. If this option is not included, the protocol will still work, but it makes it impossible for a client to compute one-way delay.
长度必须为8字节。如果客户端请求，支持此选项的服务器应将其包含在回显回复消息中。时间戳指定发送回显回复消息的时间。前4个字节指定自历元（0000 UTC 1970年1月1日）起的秒数。接下来的4个字节指定自前4个字节中指定的第二个字节起的微秒数。如果不包括此选项，该协议仍将工作，但它使客户端无法计算单向延迟。
Note that while this protocol uses the above 32-bit format, it would have been better to use another format, such as the one defined in NTPv4 [RFC5905]. This should be considered for future extensions of the protocol.
请注意，虽然此协议使用上述32位格式，但最好使用另一种格式，如NTPv4[RFC5905]中定义的格式。这一点应在今后延长议定书时加以考虑。
The format of all messages is a one-octet message type, followed by a variable number of options.
所有消息的格式都是一个八位字节的消息类型，后跟可变数量的选项。
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 | Options ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
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 | Options ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
There are four message types defined. Type 81 (the character Q in ASCII) specifies an Echo Request (Query). Type 65 (the character A in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I in ASCII) is an Init message. Type 83 (the character S in ASCII) is a Server Response message.
定义了四种消息类型。类型81（ASCII中的字符Q）指定回显请求（查询）。类型65（ASCII中的字符A）指定回显回复（应答）。类型73（ASCII中的字符I）是一条初始消息。类型83（ASCII中的字符S）是服务器响应消息。
The options immediately follow the type octet and are not aligned in any way (no spacing or padding); i.e., options might start at any octet boundary. The option format is specified above.
选项紧跟在八位字节之后，并且没有以任何方式对齐（没有间距或填充）；i、 例如，选项可以从任何八位组边界开始。选项格式如上所述。
We will now describe each of the four message types and which options they may contain.
现在我们将描述四种消息类型中的每一种，以及它们可能包含的选项。
Init, type 73
初始化，73型
This message is sent by a client to request information from a server. It is mainly used for requesting a group address, but it may also be used to check which group prefixes the server may provide groups from, or other server information. It MUST include a Version option, and SHOULD include a Client ID. It MAY include Option Request and Multicast Prefix options. This message is a request for a group address if and only if it contains Multicast Prefix options. If multiple Prefix options are included, they should be in prioritised order. That is, the server will consider the prefixes in the order they are specified, and if it finds a group for a prefix, it will only return that one group, not considering the remaining prefixes.
此消息由客户端发送，以从服务器请求信息。它主要用于请求组地址，但也可用于检查服务器提供组的组前缀或其他服务器信息。它必须包括一个版本选项，并且应该包括一个客户端ID。它可能包括选项请求和多播前缀选项。当且仅当此消息包含多播前缀选项时，此消息是对组地址的请求。如果包含多个前缀选项，则它们应按优先级顺序排列。也就是说，服务器将按照指定的顺序考虑前缀，并且如果找到前缀的组，则只返回一个组，而不考虑其余的前缀。
Server Response, type 83
服务器响应，类型83
This message is sent by a server, either as a response to an Init, or in response to an Echo Request. When responding to an Init, it may provide the client with a multicast group (if requested by the client), or it may provide other server information. In response to an Echo Request, the message tells the client to stop sending Echo Request messages. The Version option MUST always be included. Client ID and Sequence Number options are echoed if present in the client message. When providing a group to the client, it includes a Multicast Group option. It SHOULD include Server Information and Prefix options if requested. It SHOULD also include the Session ID option.
此消息由服务器发送，作为对Init的响应或对Echo请求的响应。当响应Init时，它可以向客户机提供多播组（如果客户机请求），也可以提供其他服务器信息。作为对回显请求的响应，该消息告诉客户端停止发送回显请求消息。必须始终包括版本选项。如果客户端消息中存在客户端ID和序列号选项，则会回显。向客户端提供组时，它包括一个多播组选项。如果需要，它应该包括服务器信息和前缀选项。它还应该包括会话ID选项。
Echo Request, type 81
回显请求，81型
This message is sent by a client, asking the server to send unicast and multicast Echo Reply messages. It MUST include Version, Sequence Number, and Multicast Group options. If a Session ID was received in a Server Response message, then the Session ID MUST be included. It SHOULD include Client ID and Client Timestamp options. It MAY include an Option Request option.
此消息由客户端发送，要求服务器发送单播和多播回显回复消息。它必须包括版本、序列号和多播组选项。如果在服务器响应消息中收到会话ID，则必须包括会话ID。它应该包括客户端ID和客户端时间戳选项。它可能包括一个选项请求选项。
Echo Reply, type 65
回音回复，65型
This message is sent by a server in response to an Echo Request message. This message is always sent in pairs, one as unicast and one as multicast. The contents of the messages are mostly the same. The server always echoes all of the options (but never the Session ID) from the Echo Request. Any options in the Echo Request that are unsupported by the server are also to be echoed. The two Echo Reply messages SHOULD both always contain a TTL option (not necessarily equal). When requested, both Echo Reply messages SHOULD also contain Server Timestamps (not necessarily equal).
此消息由服务器发送以响应回显请求消息。此消息始终成对发送，一个作为单播，另一个作为多播。消息的内容基本相同。服务器总是从回显请求中回显所有选项（但从不回显会话ID）。回显请求中服务器不支持的任何选项也将被回显。两条回显回复消息应始终包含TTL选项（不一定相等）。请求时，两条回送回复消息还应包含服务器时间戳（不一定相等）。
The matrix below summarises what options can go in what messages.
下面的矩阵总结了哪些选项可以包含在哪些消息中。
\ Message Type | Init | Server | Echo | Echo |
Option \ | | Response | Request | Reply |
---------------------- -+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) | SHOULD | ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6) | NOT | RQ | NOT | NOT |
Deprecated (7) | NOT | NOT | NOT | ECHO |
Deprecated (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT | SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
---------------------- -+--------+----------+---------+--------+
\ Message Type | Init | Server | Echo | Echo |
Option \ | | Response | Request | Reply |
---------------------- -+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) | SHOULD | ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6) | NOT | RQ | NOT | NOT |
Deprecated (7) | NOT | NOT | NOT | ECHO |
Deprecated (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT | SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
---------------------- -+--------+----------+---------+--------+
"NOT" means that the option MUST NOT be included. "ECHO" for a server means that if the option is specified by the client, then the server MUST echo the option in the response, with the exact same option value. ECHO for a client only applies to the Session ID option. If it is present in the Server Response, then it MUST be present with the exact same option value in the following Echo Request messages. "RQ" means that the server SHOULD include the option in the response, when requested by the client using the Option Request option.
“不”表示不得包含该选项。服务器的“ECHO”意味着，如果该选项由客户端指定，则服务器必须在响应中使用完全相同的选项值回显该选项。客户端的回显仅适用于会话ID选项。如果它出现在服务器响应中，那么它必须在以下Echo请求消息中以完全相同的选项值出现。“RQ”表示当客户端使用选项请求选项请求时，服务器应在响应中包含该选项。
Clients MUST by default send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second. Note that the value can be less than 1. Servers MUST by default perform rate limiting, to guard against this protocol being used for denial-of-service (DoS) attacks. A server MUST by default limit the number of clients that can be served at the same time, and for a given client, a server MUST also by default respond to, on average, at most Default-Server-Rate-Limit (see Section 3.5.1) Echo Request messages per second. Note that the value can be less than 1. Server implementations should provide configuration options allowing certain clients to perform more rapid rates of Echo Request messages. If higher rates are allowed for specific client IP addresses, then Init messages and the Session ID option MUST be used to help mitigate spoofing.
默认情况下，客户端必须以每秒最多默认客户端请求速率（第3.5.1节）发送回显请求消息。请注意，该值可以小于1。默认情况下，服务器必须执行速率限制，以防止此协议被用于拒绝服务（DoS）攻击。默认情况下，服务器必须限制可同时服务的客户端数量，对于给定的客户端，服务器还必须默认响应平均每秒最多默认服务器速率限制（见第3.5.1节）的回显请求消息。请注意，该值可以小于1。服务器实现应提供配置选项，允许某些客户端以更快的速度执行回显请求消息。如果特定客户端IP地址允许更高的速率，则必须使用Init消息和会话ID选项来帮助缓解欺骗。
Implementers of applications/tools using this protocol SHOULD consider the UDP guidelines [RFC5405], in particular if clients are to send, or servers are to accept, Echo Request messages at rates exceeding the defaults given in this document. See Section 8, "Security Considerations", for additional discussion.
使用此协议的应用程序/工具的实现者应考虑UDP准则[RCF5405]，特别是如果客户端要发送或服务器接受以超过文档中给出的默认值的速率返回请求消息。更多讨论见第8节“安全注意事项”。
There are two variables that control message rates. They are defined as follows.
有两个变量控制消息速率。它们的定义如下。
Default-Client-Request-Rate
默认客户端请求速率
This variable defines the default client echo request rate, specifying the number of requests per second. Note that the value may be less than one. For example, a value of 0.1 means one packet per 10 seconds. The value 1 is RECOMMENDED, but the value might be too small or large, depending on the type of network in which the client is deployed. The value 1 is chosen because it should be safe in most deployments, and it is similar to what is typically used for the common tool "ping" for ICMP Echo Request messages.
此变量定义默认的客户端回显请求速率，指定每秒的请求数。请注意，该值可能小于1。例如，值0.1表示每10秒一个数据包。建议使用值1，但该值可能太小或太大，具体取决于部署客户端的网络类型。选择值1是因为它在大多数部署中应该是安全的，并且与通常用于ICMP回显请求消息的通用工具“ping”的值类似。
Default-Server-Rate-Limit
默认服务器速率限制
This variable defines the default per-client rate limit that a server uses for responding to Echo Request messages. The average rate of replies MUST NOT exceed Default-Server-Rate-Limit per second. Note that the value may be less than one. For example, a value of 0.1 means an average of one packet per 10 seconds. The value 1 is RECOMMENDED, but the value might be too small or large, depending on the type of network in which the client is deployed. The value 1 is chosen because it should be safe in most deployments. This value SHOULD be high enough to accept the value chosen for the Default-Client-Request-Rate.
此变量定义服务器用于响应回显请求消息的默认每客户端速率限制。平均答复速率不得超过默认服务器每秒速率限制。请注意，该值可能小于1。例如，值0.1表示平均每10秒一个数据包。建议使用值1，但该值可能太小或太大，具体取决于部署客户端的网络类型。选择值1是因为它在大多数部署中应该是安全的。此值应足够高，以接受为默认客户端请求速率选择的值。
We will consider how a typical interactive client using the above protocol would behave.
我们将考虑使用上述协议的典型交互客户端的行为。
A client only requires a user to specify the unicast address of the server. It can then send an Init message with a prefix option containing the desired address family and zero prefix length (wildcard entry). The server can then decide which group, from the specified family, it should return. A client may also allow the user to specify group address(es) or prefix(es) (for IPv6, the user may
客户端只需要用户指定服务器的单播地址。然后，它可以发送带有前缀选项的Init消息，该选项包含所需的地址系列和零前缀长度（通配符条目）。然后，服务器可以决定应该返回指定族中的哪个组。客户端还可以允许用户指定组地址或前缀（对于IPv6，用户可以
only be required to specify a scope or a Rendezvous Point (RP) address, from which the client can construct the desired prefix, possibly embedded-RP). From this, the client can specify one or more prefix options in an Init message to tell the server which address it would prefer. If the user specifies a group address, that can be encoded as a prefix of maximal length (e.g., 32 for IPv4). The prefix options are in prioritised order; i.e., the client should put the most preferred prefix first.
只需要指定一个范围或集合点（RP）地址，客户机就可以从中构造所需的前缀（可能是嵌入的RP）。由此，客户机可以在Init消息中指定一个或多个前缀选项，以告诉服务器它更喜欢哪个地址。如果用户指定了组地址，则可以将其编码为最大长度的前缀（例如，IPv4为32）。前缀选项按优先级顺序排列；i、 例如，客户机应该将最首选的前缀放在第一位。
If the client receives a Server Response message containing a group address, it can start sending Echo Request messages; see the next paragraph. If there is no group address option, the client would typically exit with an error message. The server may have included some prefix options in the Server Response. The client may use this to provide the user some feedback on what prefixes or scopes are available.
如果客户端接收到包含组地址的服务器响应消息，则可以开始发送回显请求消息；见下一段。如果没有组地址选项，客户端通常会退出并显示错误消息。服务器响应中可能包含一些前缀选项。客户机可以使用它向用户提供有关可用前缀或作用域的一些反馈。
Assuming the client got a group address in a Server Response, it can start the multicast pings, after letting the user know which group is being used. Normally, a client should send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second.
假设客户端在服务器响应中获得了一个组地址，它可以在让用户知道正在使用哪个组后启动多播ping。通常，客户端应以每秒最多默认客户端请求速率（第3.5.1节）发送回显请求消息。
When sending the Echo Request messages, the client must always include the group option. If the Server Response contained a Session ID option, then it must also include a Session ID option, with the exact same value, in the Echo Request messages. If a client receives a Server Response message in response to an Echo Request (that is, a Server Response message containing a sequence number), this means there is an error, and it should stop sending Echo Request messages. This could happen after server restart.
在发送回显请求消息时，客户端必须始终包含组选项。如果服务器响应包含会话ID选项，则它还必须在回显请求消息中包含具有完全相同值的会话ID选项。如果客户端接收到响应回显请求的服务器响应消息（即，包含序列号的服务器响应消息），这意味着存在错误，它应该停止发送回显请求消息。这可能在服务器重新启动后发生。
The client may allow the user to request server information. If the user requests server information, the client can send an Init message with no prefix options, but with an Option Request option, requesting that the server return a Server Information option. The server will return server information, if supported, and it may also return a list of prefixes it supports. It will not, however, return a group address. The client may also try to obtain only a list of prefixes by sending an Init message with no prefixes and not requesting any specific options.
客户端可能允许用户请求服务器信息。如果用户请求服务器信息，客户端可以发送不带前缀选项的Init消息，但带有选项Request选项，请求服务器返回服务器信息选项。如果支持，服务器将返回服务器信息，还可能返回其支持的前缀列表。但是，它不会返回组地址。客户端还可以通过发送不带前缀的Init消息而不请求任何特定选项来尝试仅获取前缀列表。
Although this technique is not recommended, a client may pick a multicast group and send Echo Request messages without first going through the Init - Server Response negotiation. If this is supported
虽然不推荐使用这种技术，但客户端可以选择一个多播组并发送回显请求消息，而无需先通过Init-Server响应协商。如果这是支持的
by the server and the server is okay with the group used, the server can then send Echo Reply messages as usual. If the server is not okay with the group used, it will send a Server Response telling the client to stop.
如果服务器对所使用的组没有问题，则服务器可以像往常一样发送回显回复消息。如果服务器对所使用的组不满意，它将发送服务器响应，通知客户端停止。
We will consider how a typical server using the above protocol would behave, first looking at how to respond to Init messages.
我们将考虑使用上述协议的典型服务器将如何运行，首先查看如何响应init消息。
If the Init message contains prefix options, the server should look at them in order and see if it can assign a multicast address from the given prefix. The server would be configured with a (possibly default) set of groups it can offer. It may have a large pool and pick a group at random, or possibly choose a group based on hashing of the client's IP address or identifier, or simply use a fixed group. A server could possibly decide whether to include site-scoped group ranges based on the client's IP address. It is left to the server to decide whether it should allow the same address to be used simultaneously by multiple clients.
如果Init消息包含前缀选项，服务器应按顺序查看这些选项，并查看是否可以从给定前缀分配多播地址。服务器将配置一组（可能是默认的）它可以提供的组。它可能有一个大的池并随机选择一个组，或者可能根据客户机IP地址或标识符的散列来选择一个组，或者简单地使用一个固定组。服务器可能会根据客户端的IP地址决定是否包括站点范围的组范围。由服务器决定是否允许多个客户端同时使用同一地址。
If the server finds a suitable group address, it returns this address in a group option in a Server Response message. The server should additionally include a Session ID. This may help the server if it is to keep some state -- for instance, to make sure the client uses the group assigned to it. A good Session ID would be a pseudo-random byte string that is hard to predict; see [RFC4086]. If the server cannot find a suitable group address, or if there were no prefixes in the Init message, it may send a Server Response message containing prefix options listing what prefixes may be available to the client. Finally, if the Init message requests the Server Information option, the server should include that option.
如果服务器找到合适的组地址，它将在服务器响应消息的组选项中返回该地址。服务器还应包括会话ID。如果服务器要保持某种状态，例如，确保客户端使用分配给它的组，这可能有助于服务器。一个好的会话ID是一个难以预测的伪随机字节字符串；参见[RFC4086]。如果服务器找不到合适的组地址，或者如果Init消息中没有前缀，它可能会发送一条服务器响应消息，其中包含前缀选项，列出客户端可以使用的前缀。最后，如果Init消息请求服务器信息选项，则服务器应包括该选项。
When the server receives an Echo Request message, it must first check that the group address and Session ID (if provided) are valid. If the server is satisfied, it will send a unicast Echo Reply message back to the client, and also a multicast Echo Reply message to the group address. The Echo Reply messages contain the exact options (but no Session ID), and in the same order as in the Echo Request; after that, the server adds a TTL option and additional options if needed. For example, it may add a timestamp if requested by the client. If the server is not happy with the Echo Request (such as bad group address or Session ID, or request is too large), it may send a Server Response message asking the client to stop. This Server Response must echo the sequence number from the Echo Request.
服务器收到回显请求消息时，必须首先检查组地址和会话ID（如果提供）是否有效。如果服务器满意，它将向客户端发送单播回显回复消息，并向组地址发送多播回显回复消息。回送回复消息包含确切的选项（但没有会话ID），其顺序与回送请求中的顺序相同；之后，服务器会添加一个TTL选项和其他选项（如果需要）。例如，如果客户端请求，它可以添加时间戳。如果服务器对Echo请求不满意（例如组地址或会话ID错误，或者请求太大），它可能会发送服务器响应消息，要求客户端停止。此服务器响应必须回显回显请求中的序列号。
This Server Response may contain group prefixes from which a client can try to request a group address. The unicast and multicast Echo Reply messages have identical UDP payload, apart from possibly TTL and timestamp option values.
此服务器响应可能包含组前缀，客户端可以从中尝试请求组地址。除了TTL和timestamp选项值之外，单播和多播回显回复消息具有相同的UDP负载。
Note that the server may receive Echo Request messages with no prior Init message. This may happen when the server restarts or if a client sends an Echo Request with no prior Init message. The server may go ahead and respond if it is okay with the group and Session ID (if included) used. If it is not okay with this information, the server sends back a Server Response.
请注意，服务器可能会在没有先前的Init消息的情况下接收回显请求消息。这可能发生在服务器重新启动时，或者如果客户机在没有预先初始化消息的情况下发送回显请求。如果对所使用的组和会话ID（如果包括）没有问题，服务器可能会继续进行响应。如果对此信息不满意，服务器将发回服务器响应。
The protocol, as specified, is fairly flexible and leaves a lot of freedom for implementers. In this section, we present some recommendations.
正如所指定的那样，该协议相当灵活，为实现者留下了很多自由。在本节中，我们提出一些建议。
Server administrators should be able to configure one group prefix or multiple group prefixes in a server implementation. When deploying servers on the Internet and in other environments, the server administrator should be able to restrict the server to respond to only a few multicast groups that should not be currently used by multicast applications. A server implementation should also provide flexibility for an administrator to apply various policies to provide one group prefix or multiple group prefixes to specific clients, e.g., site-scoped addresses for clients that are inside the site.
服务器管理员应该能够在服务器实现中配置一个组前缀或多个组前缀。在Internet和其他环境中部署服务器时，服务器管理员应能够限制服务器仅响应少数多播应用程序当前不应使用的多播组。服务器实现还应为管理员提供灵活性，以应用各种策略为特定客户端提供一个组前缀或多个组前缀，例如，站点内客户端的站点范围地址。
As specified in Section 3.5, for a given client, a server must by default respond to at most an average rate of Default-Server-Rate-Limit Echo Request messages per second. A leaky bucket algorithm is suggested, where the rate can be higher for a few seconds, but the average rate should by default be limited to Default-Server-Rate-Limit messages per client per second. Server implementations should provide administrative control of which client IP addresses to serve, and may also allow certain clients to perform more rapid rates of Echo Request messages.
如第3.5节所述，对于给定的客户端，服务器在默认情况下必须每秒最多响应默认服务器速率限制回显请求消息的平均速率。建议使用漏桶算法，在几秒钟内速率可以更高，但默认情况下，平均速率应限制为默认服务器速率限制消息/客户端/秒。服务器实现应该提供对服务于哪个客户机IP地址的管理控制，还可以允许某些客户机执行更快的回显请求消息。
If a server uses different policies for different IP addresses, it should require clients to send Init messages and return an unpredictable Session ID to help mitigate spoofing. This is an absolute requirement if exceeding the default rate limit. See the specification in Section 3.5.
如果服务器对不同的IP地址使用不同的策略，它应该要求客户端发送Init消息并返回不可预测的会话ID，以帮助减轻欺骗。如果超过默认利率限制，这是绝对要求。参见第3.5节中的规范。
IANA has assigned UDP user port 9903 (multicast-ping) for use by this protocol. IANA also provides registries for message and option types.
IANA已分配UDP用户端口9903（多播ping）供此协议使用。IANA还提供消息和选项类型的注册表。
IANA has created a message types registry. Message types are in the range 0-255. Message types 0-253 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 254 and 255 are for experimental use. The registry includes the messages defined in Section 3.4. A message specification MUST describe the behaviour with known option types as well as the default behaviour with unknown option types.
IANA已经创建了一个消息类型注册表。消息类型的范围为0-255。消息类型0-253是按照RFC 5226[RFC5226]要求的规范程序注册的，而类型254和255是供实验使用的。注册表包括第3.4节中定义的消息。消息规范必须描述具有已知选项类型的行为以及具有未知选项类型的默认行为。
IANA has created an option type registry. Option types 0-65531 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 65532-65535 are for experimental use. The registry should include the options defined in Section 3.2. An option specification must describe how the option may be used with the known message types. This includes which message types the option may be used with.
IANA已创建选项类型注册表。选项类型0-65531按照RFC 5226[RFC5226]要求的规范程序注册，而类型65532-65535用于实验用途。注册表应包括第3.2节中定义的选项。选项规范必须描述如何将选项与已知消息类型一起使用。这包括选项可与哪些消息类型一起使用。
The initial registry definitions are as follows:
初始注册表定义如下所示：
Multicast Ping Protocol Parameters:
多播Ping协议参数：
Registry Name: Multicast Ping Protocol Message Types Reference: RFC 6450 Registration Procedures: Specification Required
注册表名称：多播Ping协议消息类型参考：RFC 6450注册过程：需要规范
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply RFC 6450
73 Init RFC 6450
81 Echo Request RFC 6450
83 Server Response RFC 6450
254-255 Experimental
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply RFC 6450
73 Init RFC 6450
81 Echo Request RFC 6450
83 Server Response RFC 6450
254-255 Experimental
Registry Name: Multicast Ping Protocol Option Types Reference: RFC 6450 Registration Procedures: Specification Required
注册表名称：多播Ping协议选项类型参考：RFC 6450注册过程：需要规范
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version RFC 6450
1 Client ID RFC 6450
2 Sequence Number RFC 6450
3 Client Timestamp RFC 6450
4 Multicast Group RFC 6450
5 Option Request RFC 6450
6 Server Information RFC 6450
7 Deprecated RFC 6450
8 Deprecated RFC 6450
9 TTL RFC 6450
10 Multicast Prefix RFC 6450
11 Session ID RFC 6450
12 Server Timestamp RFC 6450
65532-65535 Experimental
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version RFC 6450
1 Client ID RFC 6450
2 Sequence Number RFC 6450
3 Client Timestamp RFC 6450
4 Multicast Group RFC 6450
5 Option Request RFC 6450
6 Server Information RFC 6450
7 Deprecated RFC 6450
8 Deprecated RFC 6450
9 TTL RFC 6450
10 Multicast Prefix RFC 6450
11 Session ID RFC 6450
12 Server Timestamp RFC 6450
65532-65535 Experimental
There are some security issues to consider. One is that a host may send an Echo Request with an IP source address of another host, and make an arbitrary multicast ping server on the Internet send packets to this other host. This behaviour is fairly harmless. The worst case is if the host receiving the unicast Echo Reply messages also happens to be joined to the multicast group used. This is less of a problem for SSM, where also the source address of the server must match the address joined. In this case, there would be an amplification effect, where the host receives twice as many replies as there are requests sent. See below for how spoofing can be mitigated.
有一些安全问题需要考虑。一种是，一台主机可以发送一个带有另一台主机的IP源地址的回显请求，并使Internet上的任意多播ping服务器向该另一台主机发送数据包。这种行为是相当无害的。最坏的情况是，接收单播回显回复消息的主机碰巧也加入了所使用的多播组。这对于SSM来说不是什么问题，因为服务器的源地址必须与加入的地址匹配。在这种情况下，会产生放大效应，主机收到的回复是发送请求的两倍。请参见下文，了解如何缓解欺骗。
For ASM (Any-Source Multicast), a host could also make a multicast ping server send multicast packets to a group that is used for something else, possibly disturbing other uses of that group. However, server implementations should allow administrators to restrict which groups a server responds to. The administrator should then try to configure a set of groups that are not used for other purposes. Another concern is bandwidth. To limit the bandwidth used, a server MUST by default limit the number of clients that can be served at the same time, and a server MUST also by default perform per-client rate limiting.
对于ASM（任何源多播），主机还可以使多播ping服务器向用于其他用途的组发送多播数据包，这可能会干扰该组的其他用途。但是，服务器实现应该允许管理员限制服务器响应的组。然后，管理员应尝试配置一组不用于其他目的的组。另一个问题是带宽。要限制使用的带宽，服务器默认情况下必须限制可同时服务的客户端数量，并且服务器默认情况下还必须执行每个客户端的速率限制。
In order to help mitigate spoofing, a server SHOULD require that the client send an Init message, and return an unpredictable Session ID in the response. The ID should be associated with the IP address and have a limited lifetime. The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with the source IP address of the Echo Request. Note, however, that a server is replying with a Server Response message if the Session ID is invalid. This is used to tell the client that something is wrong and that it should stop sending requests, and start over if necessary. This means, however, that someone may spoof a client request, and have the server send a message back to the client address. One solution here would be for the server to have a very low rate limit for the Server Response messages.
为了帮助减轻欺骗，服务器应该要求客户端发送Init消息，并在响应中返回不可预测的会话ID。ID应该与IP地址关联，并且具有有限的生存期。然后，服务器应该只响应具有与Echo请求的源IP地址关联的有效会话ID的Echo请求消息。但是，请注意，如果会话ID无效，服务器将使用服务器响应消息进行响应。这是用来告诉客户机出了问题，应该停止发送请求，必要时重新开始。然而，这意味着有人可能伪造客户机请求，并让服务器将消息发送回客户机地址。这里的一个解决方案是服务器对服务器响应消息的速率限制非常低。
Note that the use of a Session ID only to some degree helps mitigate spoofing. An attacker that is on the path between a client and a server may eavesdrop the traffic, learn a valid Session ID, and generate Echo Request messages using this ID. The server will respond as long as the Session ID remains valid.
请注意，使用会话ID仅在一定程度上有助于减少欺骗。位于客户端和服务器之间路径上的攻击者可能会窃听通信量，获取有效的会话ID，并使用该ID生成回显请求消息。只要会话ID保持有效，服务器就会响应。
This protocol may be used to establish a covert channel between a multicast ping client and other hosts listening to a multicast group. A client can, for instance, send an Echo Request containing an undefined option with arbitrary data. The server would echo this back in an Echo Reply that may reach other hosts listening to that group. One solution that should be considered for future protocol versions is to reply with a hash of the data, rather than simply a copy of the same data.
该协议可用于在多播ping客户端和侦听多播组的其他主机之间建立隐蔽通道。例如，客户端可以发送包含未定义选项和任意数据的回显请求。服务器将在回送回复中回送此消息，回送回复可能会到达侦听该组的其他主机。对于未来的协议版本，应该考虑的一个解决方案是使用数据的散列来回复，而不仅仅是相同数据的副本。
The ssmping concept was proposed by Pavan Namburi, Kamil Sarac, and Kevin C. Almeroth in the paper "SSM-Ping: A Ping Utility for Source Specific Multicast" (2004) and also "MPing: A Ping Utility for IP Multicast" (Sarac and Almeroth, 2004). Mickael Hoerdt contributed several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb, and Dave Thaler have contributed in different ways to the implementation of the ssmping tools [IMPL]. Many people in communities like the Trans-European Research and Education Networking Association (TERENA), Internet2, and the M6Bone (IPv6 multicast network) have used early implementations of ssmping and provided feedback that influenced the current protocol. Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol, and Cao Wei for reviewing and providing feedback on this document. In particular, Hugo, Gorry, and Bharat provided lots of input on several revisions of the document.
ssmping概念是由Pavan Namburi、Kamil Sarac和Kevin C.Almeroth在论文“SSM Ping：源特定多播的Ping实用程序”（2004）和“MPing：IP多播的Ping实用程序”（Sarac和Almeroth，2004）中提出的。米克尔·霍尔特提出了几个想法。Alexander Gall、Nicholas Humfrey、Nick Lamb和Dave Thaler以不同的方式为ssmping工具[IMPL]的实现做出了贡献。跨欧洲研究和教育网络协会（TERENA）、Internet2和M6Bone（IPv6多播网络）等社区的许多人使用了ssmping的早期实现，并提供了影响当前协议的反馈。感谢Kevin Almeroth、Tony Ballardi、Bill Cervny、Toerless Eckert、Marshall Eubanks、Gorry Fairhurst、Alfred Hoenes、Liu Hui、Bharat Joshi、Olav Kvittem、Hugo Santos、Kamil Sarac、Pekka Savola、Trond Skjesol和曹伟对本文件的审查和提供反馈。特别是，雨果、戈里和巴拉特对该文件的几次修订提供了大量意见。
[ADDRFAMILY] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[ADDRFAMILY]IANA，“地址家族编号”<http://www.iana.org/assignments/address-family-numbers>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IMPL] Venaas, S., "ssmping implementation", <http://software.uninett.no/ssmping/>.
[IMPL]Venaas，S.，“ssmping实现”<http://software.uninett.no/ssmping/>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
Author's Address
作者地址
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com