Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
IPv6 Node Information Queries
IPv6节点信息查询
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.
本文档描述了一种协议，用于请求IPv6节点提供某些网络信息，例如其主机名或完全限定的域名。IPv6实施经验表明，对主机名的直接查询非常有用，而对其他信息的直接查询机制在无服务器环境和调试中也很有用。
Table of Contents
目录
1. Introduction ....................................................2
2. Applicability Statement .........................................2
3. Terminology .....................................................2
4. Node Information Messages .......................................3
5. Message Processing ..............................................5
6. Defined Qtypes ..................................................6
6.1. NOOP .......................................................7
6.2. Node Name ..................................................7
6.3. Node Addresses .............................................8
6.4. IPv4 Addresses .............................................9
6.4.1. Discussion ..........................................9
7. IANA Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Applicability Statement .........................................2
3. Terminology .....................................................2
4. Node Information Messages .......................................3
5. Message Processing ..............................................5
6. Defined Qtypes ..................................................6
6.1. NOOP .......................................................7
6.2. Node Name ..................................................7
6.3. Node Addresses .............................................8
6.4. IPv4 Addresses .............................................9
6.4.1. Discussion ..........................................9
7. IANA Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
This document specifies a mechanism for discovering information about names and addresses. The applicability of these mechanisms is currently limited to diagnostic and debugging tools and network management (e.g., node discovery). In the global internet, the Domain Name System (DNS) [1][2] is the authoritative source of such information and this specification is not intended to supplant or supersede it. In fact, in a well-supported network, the names and addresses dealt with by this mechanism will be the same ones, with the same relationships, as those listed in the DNS.
本文档指定了一种用于发现有关名称和地址的信息的机制。这些机制的适用性目前仅限于诊断和调试工具以及网络管理（例如，节点发现）。在全球互联网中，域名系统（DNS）[1][2]是此类信息的权威来源，本规范无意取代或取代它。事实上，在一个支持良好的网络中，此机制处理的名称和地址将与DNS中列出的名称和地址相同，具有相同的关系。
This new Node Information protocol provides facilities that are not found in the DNS, for example, discovering relationships between addresses without reference to names. The functions that do overlap with the DNS may be useful in serverless environments, for debugging, or in regard to link-local and unique-local addresses [3] that often will not be listed in the DNS.
这个新的节点信息协议提供了DNS中找不到的功能，例如，在不引用名称的情况下发现地址之间的关系。与DNS重叠的功能可能在无服务器环境中有用，用于调试，或用于通常不会在DNS中列出的链接本地和唯一本地地址[3]。
IPv6 Node Information Queries include the capability to provide forward and reverse name lookups independent of the DNS by sending packets directly to IPv6 nodes or groups of nodes.
IPv6节点信息查询包括通过直接向IPv6节点或节点组发送数据包来提供独立于DNS的正向和反向名称查找的功能。
The applicability of these mechanisms is currently limited to diagnostic and debugging tools and network management (e.g., node discovery). These mechanisms can be used to learn the addresses and names for nodes on the other end of a point-to-point link or nodes on a shared-medium link such as an Ethernet. This is very useful when debugging problems or when bringing up IPv6 service where there is no global routing or DNS name services available. IPv6's large auto-configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. An example of an IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in the KAME (http://www.kame.net), USAGI, and other IPv6 implementations.
这些机制的适用性目前仅限于诊断和调试工具以及网络管理（例如，节点发现）。这些机制可用于了解点到点链路另一端的节点或共享介质链路（如以太网）上的节点的地址和名称。这在调试问题或在没有全局路由或DNS名称服务的情况下启动IPv6服务时非常有用。如果没有这些机制，IPv6的大型自动配置地址会使调试网络问题和提供IPv6服务变得困难。使用IPv6节点信息查询的IPv6调试工具的一个示例是KAME中的ping6程序(http://www.kame.net)、USAGI和其他IPv6实现。
The mechanisms defined in this document may have wider applicability in the future, but any use beyond debugging and diagnostic tools is left for further study and is beyond the scope of this document.
本文档中定义的机制在将来可能具有更广泛的适用性，但调试和诊断工具之外的任何用途将留待进一步研究，并且超出本文档的范围。
A "Node Information Query" (or "NI Query") message is sent by a "Querier" node to a "Responder" node in an ICMPv6 packet addressed to the "Queried Address". The Query contains a "Subject Address" (which may differ from the Queried Address and may be an IPv6 or IPv4
“查询者”节点将“节点信息查询”（或“NI查询”）消息发送到地址为“查询地址”的ICMPv6数据包中的“响应者”节点。查询包含“主题地址”（可能与查询的地址不同，可能是IPv6或IPv4地址）
address) or a "Subject Name". The Responder sends a "Node Information Reply" to the Querier, containing information associated with the node at the Queried Address. A node receiving an NI Query will be termed a Responder even if it does not send a reply.
地址）或“受试者姓名”。响应者向查询者发送“节点信息回复”，其中包含与查询地址处的节点相关的信息。接收NI查询的节点将被称为响应者，即使它不发送应答。
The word "name" in this document refers to a hostname with or without the domain. Where necessary, the cases of fully-qualified and single-label names will be distinguished.
本文档中的“名称”一词指的是带有或不带域的主机名。必要时，将区分完全限定名称和单标签名称。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[4]中所述进行解释。
Packet fields marked "unused" must be zero on transmission and, aside from inclusion in checksums or message integrity checks, ignored on reception.
标记为“未使用”的数据包字段在传输时必须为零，除了包含在校验和或消息完整性检查中，在接收时忽略。
Two types of Node Information messages, the NI Query and the NI Reply, are carried in ICMPv6 [5] packets. They have the same format.
ICMPv6[5]数据包中包含两种类型的节点信息消息，即NI查询和NI回复。它们有相同的格式。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node Information Messages
图1：节点信息消息
Fields:
领域：
o Type
o 类型
* 139 - NI Query
* 139-NI查询
* 140 - NI Reply
* 140-倪的答复
o Code
o 密码
* For NI Query
* 查询NI
+ 0 - Indicates that the Data field contains an IPv6 address that is the Subject of this Query.
+ 0-表示数据字段包含作为此查询主题的IPv6地址。
+ 1 - Indicates that the Data field contains a name that is the Subject of this Query, or is empty, as in the case of a NOOP.
+ 1-表示数据字段包含作为此查询主题的名称，或者是空的，如NOOP。
+ 2 - Indicates that the Data field contains an IPv4 address that is the Subject of this Query.
+ 2-表示数据字段包含作为此查询主题的IPv4地址。
* For NI Reply
* 谢谢你的回复
+ 0 - Indicates a successful reply. The Reply Data field may or may not be empty.
+ 0-表示答复成功。回复数据字段可能为空，也可能不为空。
+ 1 - Indicates that the Responder refuses to supply the answer. The Reply Data field will be empty.
+ 1-表示响应者拒绝提供答案。答复数据字段将为空。
+ 2 - Indicates that the Qtype of the Query is unknown to the Responder. The Reply Data field will be empty.
+ 2-表示响应者不知道查询的Qtype。答复数据字段将为空。
o Checksum - The ICMPv6 checksum.
o 校验和-ICMPv6校验和。
o Qtype - A 16-bit field that designates the type of information requested in a Query or supplied in a Reply. Its value in a Reply is always copied from the corresponding Query by the Responder. Five values of Qtype are specified in this document.
o Qtype—一个16位字段，用于指定查询中请求的或答复中提供的信息类型。应答器总是从相应的查询中复制它在应答中的值。本文档中指定了五个Qtype值。
o Flags - Qtype-specific flags that may be defined for certain Query types and their Replies. Flags not defined for a given Qtype must be zero on transmission and ignored on reception, and must not be copied from a Query to a Reply unless so specified in the definition of the Qtype.
o Flags—可以为某些查询类型及其答复定义的特定于Qtype的标志。未为给定Qtype定义的标志在传输时必须为零，在接收时必须忽略，并且不得从查询复制到应答，除非在Qtype定义中指定。
o Nonce - An opaque 64-bit field to help avoid spoofing and/or to aid in matching Replies with Queries. Its value in a Query is chosen by the Querier. Its value in a Reply is always copied from the corresponding Request by the Responder.
o Nonce-一个不透明的64位字段，用于帮助避免欺骗和/或帮助将答复与查询匹配。它在查询中的值由查询者选择。应答器总是从相应的请求复制应答中的值。
o Data - In a Query, the Subject Address or Name. In a Reply, Qtype-specific data is present only when the ICMPv6 Code field is zero. The length of the Data may be inferred from the IPv6 header's Payload Length field [6], the length of the fixed portion
o 数据-在查询中，主题地址或名称。在回复中，仅当ICMPv6代码字段为零时，才会出现特定于Qtype的数据。数据的长度可以从IPv6报头的有效负载长度字段[6]中推断出来，即固定部分的长度
of the NI packet, and the lengths of the ICMPv6 header and intervening extension headers.
以及ICMPv6报头和中间扩展报头的长度。
Note that the type of information present in the Data field of a Query is declared by the ICMP Code, whereas the type of information, if any, in the Data field of a Reply is determined by the Qtype.
请注意，查询数据字段中的信息类型由ICMP代码声明，而回复数据字段中的信息类型（如果有）由Qtype确定。
When the Subject of a Query is a name, the name MUST be in DNS wire format [2]. The name may be either a fully-qualified domain name, including the terminating zero-length label, or a single DNS label followed by two zero-length labels. Since a Query contains at most one name, DNS name compression MUST NOT be used.
当查询的主题是名称时，名称必须为DNS wire格式[2]。该名称可以是完全限定的域名（包括终止的零长度标签），也可以是一个DNS标签，后跟两个零长度标签。由于查询最多包含一个名称，因此不能使用DNS名称压缩。
The Querier constructs an ICMP NI Query and sends it to the address from which information is wanted. When the Subject of the Query is an IPv6 address, that address will normally be used as the IPv6 destination address of the Query, but need not be if the Querier has useful a priori information about the addresses of the target node. An NI Query may also be sent to a multicast address of link-local scope [3].
查询器构造一个ICMP NI查询并将其发送到需要信息的地址。当查询的主题是IPv6地址时，该地址通常将用作查询的IPv6目标地址，但如果查询者具有关于目标节点地址的有用先验信息，则不必使用该地址。NI查询也可以发送到链路本地作用域[3]的多播地址。
When the Subject is a name, either fully-qualified or single-component, and the Querier does not have a unicast address for the target node, the query MUST be sent to a link-scope multicast address formed in the following way. The Subject Name is converted to the canonical form defined by DNS Security [7], which is uncompressed with all alphabetic characters in lowercase. (If additional DNS label types or character sets for hostnames are defined, the rules for canonicalizing those labels will be found in their defining specification.) Compute the MD5 hash [8] of the first label of the Subject Name--the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF00::/104. The resulting multicast address will be termed the "NI Group Address" for the name. A node will support an "NI Group Address" for each unique single-label name.
当主题是一个名称（完全限定或单个组件），并且查询器没有目标节点的单播地址时，必须将查询发送到按以下方式形成的链接作用域多播地址。主题名称被转换为DNS安全性[7]定义的规范格式，并使用所有小写字母字符进行解压缩。（如果定义了主机名的其他DNS标签类型或字符集，则规范化这些标签的规则将在其定义规范中找到。）计算主题名的第一个标签的MD5哈希[8]——该部分从第一个八位字节长度字段开始，直到但不包括任何后续长度字段。将该128位哈希的前24位附加到前缀FF02:0:0:0:0:2:FF00:：/104。产生的多播地址将被称为名称的“NI组地址”。节点将为每个唯一的单个标签名称支持“NI组地址”。
The Nonce MUST be a random or good pseudo-random value to foil spoofed replies. An implementation that allows multiple independent processes to send NI Queries MAY use the Nonce value to deliver Replies to the correct process. Nonetheless, such processes MUST check the received Nonce and ignore extraneous Replies.
Nonce必须是一个随机或良好的伪随机值，以屏蔽伪造的回复。允许多个独立进程发送NI查询的实现可以使用Nonce值向正确的进程发送回复。尽管如此，这些过程必须检查收到的Nonce并忽略无关的回复。
If true communication security is required, IP Security (IPsec) [14] should be used. Providing the infrastructure to authenticate NI
如果需要真正的通信安全性，则应使用IP安全性（IPsec）[14]。提供对NI进行身份验证的基础设施
Queries and Replies may be quite difficult outside of a well-defined community.
在定义良好的社区之外，查询和回复可能非常困难。
Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing unless it is one of the Responder's unicast or anycast addresses, or a link-local scope multicast address that the Responder has joined. Typically, the latter will be an NI Group Address for a name belonging to the Responder. A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es), but if so, the default configuration SHOULD be not to discard them.
收到NI查询后，响应程序必须检查查询的IPv6目标地址，并放弃查询，无需进一步处理，除非该查询是响应程序的单播或选播地址之一，或响应程序已加入的链路本地作用域多播地址。通常，后者将是属于响应者的名称的NI组地址。节点可以配置为放弃对其NI组地址以外的多播地址的NI查询，但如果是这样，则默认配置不应放弃这些查询。
A Responder must also silently discard a Query whose Subject Address or Name (in the Data field) does not belong to that node. A single-component Subject Name matches any fully-qualified name whose first label matches the Subject. All name matching is done in a case-independent manner consistent with DNS Security (DNSSEC) name canonicalization [7].
响应者还必须悄悄地放弃其主题地址或名称（在数据字段中）不属于该节点的查询。单个组件主题名称与第一个标签与主题匹配的任何完全限定名称匹配。所有名称匹配均以与DNS安全（DNSSEC）名称规范化一致的大小写无关的方式完成[7]。
Next, if Qtype is unknown to the Responder, it must return an NI Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should rate-limit such replies as it would ICMPv6 error replies [5].
接下来，如果响应程序未知Qtype，则它必须返回ICMPv6 Code=2且无回复数据的NI回复。响应者应按照ICMPv6错误回复[5]的方式对此类回复进行评级限制。
Next, the Responder should decide whether to refuse an answer, based on local policy. (See the "Security Considerations" section for recommended default behavior.) If an answer is refused, depending on local policy the Responder can elect to silently discard the query or send an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the Responder should rate-limit such replies as it would ICMPv6 error replies [5].
接下来，响应者应根据当地政策决定是否拒绝回答。（有关建议的默认行为，请参阅“安全注意事项”部分。）如果拒绝回答，根据本地策略，响应者可以选择以静默方式放弃查询或发送ICMPv6 Code=1且无回复数据的NI回复。同样，响应者应该像对ICMPv6错误响应一样对此类响应进行评级限制[5]。
Finally, if the Qtype is known and the response is allowed by local policy, the Responder MUST fill in the Flags and Reply Data of the NI Reply in accordance with the definition of the Qtype and transmit the NI Reply. The source address of the NI Reply SHOULD be selected using the rules defined in [9].
最后，如果Qtype已知且本地策略允许响应，则响应者必须根据Qtype的定义填写NI应答的标志和应答数据，并发送NI应答。应使用[9]中定义的规则选择NI回复的源地址。
If the Query was sent to a multicast address, transmission of the Reply MUST be delayed by a random interval between zero and [Query Response Interval], as defined by Multicast Listener Discovery Version 2 [10].
如果查询被发送到多播地址，则应答的传输必须延迟0到[Query Response interval]之间的随机间隔，如多播侦听器发现版本2[10]所定义。
The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be supported by any implementation of this protocol. Qtype 4 SHOULD be supported by any implementation of this protocol on an IPv4/IPv6 dual-stack node and MAY be supported on an IPv6-only node.
定义了以下QTYPE。此协议的任何实现都必须支持QType 0、2和3。此协议在IPv4/IPv6双堆栈节点上的任何实现都应支持Qtype 4，并且仅在IPv6节点上可能支持Qtype 4。
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
This NI type has no defined flags and never has a Data field. A Reply to an NI NOOP Query tells the Querier that a node with the Queried Address is up and reachable and implements the Node Information protocol. On transmission, the ICMPv6 Code in a NOOP Query must be set to 1 and the Code in a NOOP Reply must be 0. On reception of a NOOP Query or Reply, the Code must be ignored.
此NI类型没有定义的标志，也没有数据字段。对NI NOOP查询的回复告诉查询者具有查询地址的节点已启动且可访问，并实现节点信息协议。传输时，NOOP查询中的ICMPv6代码必须设置为1，NOOP应答中的代码必须为0。收到NOOP查询或回复时，必须忽略代码。
The NI Node Name Query requests the fully-qualified or single-component name corresponding to the Subject Address or Name. The Reply Data has the following format.
NI节点名称查询请求与主题地址或名称相对应的完全限定或单个组件名称。回复数据的格式如下。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... |
+ +
/ /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... |
+ +
/ /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Node Information Reply Message
图2：节点信息回复消息
o TTL (Time to Live) - MUST be zero. Any non-zero value received MUST be treated as zero. This field is no longer used but is present to preserve backward compatibility with older implementations.
o TTL（生存时间）-必须为零。收到的任何非零值都必须视为零。此字段不再使用，但用于保持与旧实现的向后兼容性。
o Node Names - The fully-qualified or single-component name or names of the Responder that correspond(s) to the Subject Address or Name, in DNS wire format, Section 3.1 of [2]. Each name MUST be fully-qualified if the responder knows the domain suffix;
o 节点名称-响应者的完全限定或单个组件名称，对应于主题地址或名称，采用DNS wire格式，见[2]第3.1节。如果响应者知道域名后缀，则每个名称必须完全限定；
otherwise, each name MUST be a single DNS label followed by two zero-length labels. When multiple node names are returned and more than one of them is fully-qualified, DNS name compression, Section 4.1.4 of [2], SHOULD be used, and the offsets are counted from the first octet of the Data field. An offset of 4, for example, will point to the beginning of the first name.
否则，每个名称必须是一个DNS标签，后跟两个零长度标签。当返回多个节点名且其中一个以上完全限定时，应使用DNS名称压缩（见[2]第4.1.4节），并从数据字段的第一个八位字节开始计算偏移量。例如，偏移量为4将指向名字的开头。
The Responder must fill in the TTL field of the Reply with zero.
应答者必须在应答的TTL字段中填入零。
Only one TTL is included in the Reply.
答复中仅包含一个TTL。
If the Responder does not know its name at all, it MUST send a Reply with TTL=0 and no Node Names (or a Reply with Code=1 indicating refusal to answer). The Querier will be able to determine from the packet length that the Data field contains no names.
如果响应者根本不知道自己的名称，那么它必须发送一个TTL=0且没有节点名称的回复（或者一个代码=1表示拒绝应答的回复）。查询者将能够根据数据包长度确定数据字段不包含名称。
The NI Node Addresses Query requests some set of the Responder's IPv6 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 addresses, with each address preceded by a separate 32-bit TTL value, with Preferred addresses listed before Deprecated addresses [11]; otherwise, they are in no special order. Five flag bits are defined in the Query and six in the Reply.
NI节点地址查询请求响应程序的某组IPv6单播地址。回复数据是一个128位IPv6地址序列，每个地址前面都有一个单独的32位TTL值，首选地址列在不推荐的地址之前[11]；否则，它们没有特殊顺序。查询中定义了五个标志位，应答中定义了六个标志位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=3 | unused |G|S|L|C|A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=3 | unused |G|S|L|C|A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Node Information Address Query
图3：节点信息地址查询
o G - If set to 1, Global-scope addresses [12] are requested.
o G-如果设置为1，则请求全局作用域地址[12]。
o S - If set to 1, Site-local addresses [12] are requested. However, Site-local addresses are now deprecated [15] and this flag is for backward compatibility.
o S-如果设置为1，则请求站点本地地址[12]。但是，现在不推荐使用站点本地地址[15]，此标志用于向后兼容。
o L - If set to 1, Link-local addresses [12] are requested.
o L-如果设置为1，则请求链路本地地址[12]。
o C - If set to 1, IPv4-compatible (now deprecated) and IPv4-mapped addresses [3] are requested. Responses SHOULD include IPv4 addresses in IPv4-mapped form.
o C-如果设置为1，则请求IPv4兼容（现在已弃用）和IPv4映射地址[3]。响应应包括IPv4映射形式的IPv4地址。
o A - If set to 1, all the Responder's unicast addresses (of the specified scope(s)) are requested. If 0, only those addresses are requested that belong to the interface (or any one interface) that
o A-如果设置为1，则请求所有响应程序的单播地址（在指定范围内）。如果为0，则仅请求属于该接口（或任何一个接口）的地址
has the Subject Address or that are associated with the Subject Name.
具有与主题名称关联的主题地址或。
o T - Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons.
o T-仅在应答中定义，表示由于空间原因，地址集不完整。
Flags G, S, L, C, and A are copied from a Query to the corresponding Reply.
标志G、S、L、C和A从查询复制到相应的应答。
The TTL associated with each address MUST be zero.
与每个地址关联的TTL必须为零。
The NI IPv4 Addresses Query requests some set of the Responder's IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 addresses, each address preceded by a 32-bit TTL value. One flag bit is defined in the Query and two in the Reply.
NI IPv4地址查询请求响应程序的某组IPv4单播地址。应答数据是一个32位IPv4地址序列，每个地址前面都有一个32位TTL值。查询中定义了一个标志位，应答中定义了两个标志位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=4 | unused |A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=4 | unused |A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Node Information IPv4 Address Query
图4：节点信息IPv4地址查询
o A - If set to 1, all the Responder's unicast addresses are requested. If 0, only those addresses are requested that belong to the interface (or any one interface) that has the Subject Address.
o A-如果设置为1，则请求所有响应者的单播地址。如果为0，则仅请求属于具有主题地址的接口（或任何一个接口）的地址。
o T - Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons.
o T-仅在应答中定义，表示由于空间原因，地址集不完整。
Flag A is copied from a Query to the corresponding Reply.
标志A从查询复制到相应的应答。
The TTL associated with each address MUST be zero.
与每个地址关联的TTL必须为零。
It is possible that a node may treat IPv4 interfaces and IPv6 interfaces as distinct, even though they are associated with the same hardware. When such a node is responding to an NI Query having a Subject Address of one type requesting the other type, and the Query has the A flag set to 0, it SHOULD consider IP interfaces, other than tunnels, associated with the same hardware as being the same interface.
节点可能会将IPv4接口和IPv6接口视为不同的接口，即使它们与相同的硬件相关联。当这样的节点响应具有请求另一类型的一种类型的主题地址的NI查询时，并且该查询具有设置为0的A标志时，它应该考虑与相同的硬件相关联的IP接口，而不是与相同的接口相关联的相同的硬件。
ICMPv6 type values 139 and 140 were previously assigned by IANA for this protocol. This document defines three values of the ICMPv6 Code field for each of these ICMPv6 Type values. Additional Code values may be defined using the "Specification Required" criteria from [16]. IANA has established and will maintain a registry for the Code fields associated with the Node Information Query ICMPv6 Types as a part of its ICMPv6 Registry updated in [13].
ICMPv6类型值139和140先前由IANA为此协议分配。本文档为每个ICMPv6类型值定义了ICMPv6代码字段的三个值。可使用[16]中的“所需规范”标准定义其他代码值。IANA已经建立并将维护一个与节点信息查询ICMPv6类型相关的代码字段注册表，作为其ICMPv6注册表的一部分，该注册表在[13]中更新。
This document defines five values of Qtype, numbers 0 through 4. Following the policies outlined in [16], new values, and their associated Flags and Reply Data, are to be defined by IETF Consensus.
本文档定义了Qtype的五个值，编号为0到4。按照[16]中概述的策略，新值及其相关标志和回复数据将由IETF共识定义。
The IANA has assigned the IPv6 multicast prefix FF02:0:0:0:0:2:FF00::/104 for use in Node Information Queries as defined in Section 5. It should be noted that this assignment does conform with the requirements defined in [17].
IANA已分配IPv6多播前缀FF02:0:0:0:0:2:FF00:：/104，用于第5节中定义的节点信息查询。应注意的是，该任务确实符合[17]中定义的要求。
This protocol shares the security issues of ICMPv6 that are documented in the "Security Considerations" section of [5].
本协议共享ICMPv6的安全问题，这些问题记录在[5]的“安全注意事项”一节中。
This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration that refuses to answer queries from global-scope [3] addresses.
此协议有可能泄露对潜在攻击者有用的信息。此协议的实现必须具有拒绝回答来自全局作用域[3]地址的查询的默认配置。
Implementations SHOULD apply rate-limiting to NI responses to avoid being used in a denial-of-service attack.
实现应该对NI响应应用速率限制，以避免被用于拒绝服务攻击。
The anti-spoofing Nonce does not give any protection from spoofers who can eavesdrop the Query or the Reply.
反欺骗暂时性不提供任何保护，防止欺骗者窃听查询或回复。
The information learned via this protocol SHOULD NOT be trusted for making security-relevant decisions unless some other mechanisms beyond the scope of this document are used to authenticate this information.
除非使用本文件范围以外的其他机制对该信息进行身份验证，否则通过本协议获取的信息在做出安全相关决策时不应被信任。
An implementation of this protocol SHOULD provide the ability to control the dissemination of information related to IPv6 Privacy Addresses [18]. The default action of this policy SHOULD NOT provide a response to a Query that contains a node's Privacy Addresses.
该协议的实现应能够控制与IPv6隐私地址相关的信息的传播[18]。此策略的默认操作不应提供对包含节点隐私地址的查询的响应。
A node MUST NOT include Privacy Addresses in any Node Addresses response that includes a public address, or for which the source address of the response, the destination address of the request, or
节点不得在包含公共地址的任何节点地址响应中包含隐私地址，或在响应的源地址、请求的目标地址或
the Subject Address of the request is a public address. Similarly, a node MUST NOT include any address other than the (single) Privacy Address in any Node Addresses response that includes the Privacy Address, or for which the source address of the response, the destination address of the request, or the Subject Address of the request is the Privacy Address.
请求的主题地址是公共地址。类似地，在包含隐私地址的任何节点地址响应中，或者响应的源地址、请求的目标地址或请求的主题地址是隐私地址的任何节点地址响应中，节点不得包含除（单个）隐私地址以外的任何地址。
Alain Durand contributed to this specification, and valuable feedback and implementation experience were provided by Jun-Ichiro Hagino and Tatuya Jinmei. Other useful comments were received from Robert Elz, Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden and Brian Haberman have acted as document editors during the IETF advancement process.
Alain Durand对此规范做出了贡献，Jun Ichiro Hagino和Tatuya Jinmei提供了宝贵的反馈和实施经验。其他有用的评论来自罗伯特·埃尔兹、基思·摩尔、埃尔文·戴维斯、佩卡·萨沃拉和戴夫·泰勒。Bob Hinden和Brian Haberman在IETF推进过程中担任文档编辑。
This document is not the first proposal of a direct query mechanism for address-to-name translation. The idea had been discussed briefly in the IPng working group, and RFC 1788 [19] describes such a mechanism for IPv4.
本文件并非地址到名称转换的直接查询机制的第一个提案。IPng工作组对该想法进行了简要讨论，RFC 1788[19]描述了IPv4的这种机制。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[3] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[5] Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[7] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[9] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[10] Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC3810，2004年6月。
[11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[11] Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[12] Hinden，R.，Deering，S.，和E.Nordmark，“IPv6全球单播地址格式”，RFC 3587，2003年8月。
[13] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[13] Conta，A.，Deering，S.，和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 44432006年3月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[15] Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 38792004年9月。
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[17] Haberman，B.，“IPv6多播地址分配指南”，RFC33072002年8月。
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
[19] 辛普森，W.，“ICMP域名信息”，RFC17881995年4月。
Authors' Addresses
作者地址
Matt Crawford Fermilab PO Box 500 Batavia, IL 60510 US
美国伊利诺伊州巴达维亚市马特·克劳福德·费米拉布邮政信箱500号，邮编：60510
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
布莱恩·哈伯曼（编辑）约翰·霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰·霍普金斯路11100号20723-6099
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。