Network Working Group A. Conta
Request for Comments: 3122 Transwitch Corporation
Category: Standards Track June 2001
Network Working Group A. Conta
Request for Comments: 3122 Transwitch Corporation
Category: Standards Track June 2001
Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
用于反向发现规范的IPv6邻居发现扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
此备忘录描述了IPv6邻居发现的扩展，该扩展允许节点确定和公布与给定链路层地址相对应的IPv6地址。这些扩展称为反向邻居发现。反向邻居发现（IND）最初是为帧中继网络开发的，但也可以应用于具有类似行为的其他网络。
Table of Contents
目录
1. Introduction.................................................... 3
2. Inverse Neighbor Discovery Messages............................. 3
2.1 Inverse Neighbor Discovery Solicitation Message............. 3
2.2 Inverse Neighbor Discovery Advertisement Message............ 5
3. Inverse Neighbor Discovery Options Format....................... 6
3.1 Target Address List......................................... 6
4. Inverse Neighbor Discovery Protocol............................. 9
4.1 Sender Node Processing...................................... 9
4.2 Receiver Node Processing.................................... 9
4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
4.3 Message Validation......................................... 10
4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
5. Security Considerations........................................ 12
6. IANA Considerations............................................ 13
7. Acknowledgments................................................ 13
8. References..................................................... 13
9. Authors' Addresses............................................. 14
Appendix A........................................................ 15
Full Copyright Statement.......................................... 20
1. Introduction.................................................... 3
2. Inverse Neighbor Discovery Messages............................. 3
2.1 Inverse Neighbor Discovery Solicitation Message............. 3
2.2 Inverse Neighbor Discovery Advertisement Message............ 5
3. Inverse Neighbor Discovery Options Format....................... 6
3.1 Target Address List......................................... 6
4. Inverse Neighbor Discovery Protocol............................. 9
4.1 Sender Node Processing...................................... 9
4.2 Receiver Node Processing.................................... 9
4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
4.3 Message Validation......................................... 10
4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
5. Security Considerations........................................ 12
6. IANA Considerations............................................ 13
7. Acknowledgments................................................ 13
8. References..................................................... 13
9. Authors' Addresses............................................. 14
Appendix A........................................................ 15
Full Copyright Statement.......................................... 20
This document defines extensions to the IPv6 Neighbor Discovery (ND)[IPv6-IND]. The extensions are called IPv6 Inverse Neighbor Discovery (IND). The IPv6 Inverse Neighbor Discovery (IND) allows a node that knows the link-layer address of a directly connected remote node to learn the IPv6 addresses of that node. A node using IND sends solicitations and receives advertisements for one or more IPv6 addresses corresponding to a known link-layer address.
本文档定义了IPv6邻居发现（ND）[IPv6 IND]的扩展。这些扩展称为IPv6反向邻居发现（IND）。IPv6反向邻居发现（IND）允许知道直接连接的远程节点的链路层地址的节点了解该节点的IPv6地址。使用IND的节点发送请求并接收与已知链路层地址对应的一个或多个IPv6地址的播发。
The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
反向邻居发现（IND）最初是为帧中继网络开发的，但也可以应用于具有类似行为的其他网络。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [KEYWORDS].
关键词必须、不得、可、可选、必需、推荐、应、不应、不应、不应按照[关键词]中的定义进行解释。
There are a number of similarities and differences between the mechanisms described here and those defined for Inverse ARP for IPv4 in [INV-ARP] or its replacement documents.
此处描述的机制与[INV-ARP]或其替代文档中为IPv4的反向ARP定义的机制有许多相似之处和不同之处。
The following messages are defined:
定义了以下消息：
A node sends an Inverse Neighbor Discovery Solicitation message to request an IPv6 address corresponding to a link-layer address of the target node while also providing its own link-layer address to the target. Since the remote node IPv6 addresses are not known, Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address.
节点发送反向邻居发现请求消息以请求与目标节点的链路层地址相对应的IPv6地址，同时还向目标节点提供其自己的链路层地址。由于远程节点IPv6地址未知，反向邻居发现（IND）请求将作为IPv6所有节点多播[IPv6]、[IPv6 FR]、[ENCAPS]发送。然而，在链路层级别，IND请求直接发送到由已知链路层地址标识的目标节点。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Source Address An IPv6 address assigned to the interface from which this message is sent.
源地址分配给发送此消息的接口的IPv6地址。
Destination Address The IPv6 all-node multicast address. This address is specified in its link-scope format, which is FF02::1.
目标地址IPv6所有节点多播地址。此地址以其链接作用域格式指定，即FF02:：1。
Hop Limit 255
跃点限制255
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination, then the sender SHOULD include this header.
身份验证标头如果发送方和目标之间存在IP身份验证标头的安全关联，则发送方应包含此标头。
ICMP Fields:
ICMP字段：
Type 141
141型
Code 0
代码0
Checksum The ICMP checksum. See [ICMPv6].
校验和ICMP校验和。见[ICMPv6]。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Required options:
所需选项：
The sender node MUST send the following options in the Solicitation message:
发件人节点必须在请求消息中发送以下选项：
Source Link-Layer Address The link-layer address of the sender.
源链接层地址发送方的链接层地址。
Target Link-Layer Address The link-layer address of the target node.
目标链路层地址目标节点的链路层地址。
Other valid options:
其他有效选项：
The sender node MAY choose to add the following options in the Solicitation message:
发送方节点可以选择在请求消息中添加以下选项：
Source Address List The list of one or more IPv6 addresses of the interface identified by the Source Link-Layer Address. This option is defined in section 3.
源地址列表由源链路层地址标识的接口的一个或多个IPv6地址的列表。该选项在第3节中定义。
MTU The MTU configured for this link [IPv6-ND].
MTU为该链路配置的MTU[IPv6 ND]。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
此协议的未来版本可能会添加其他选项类型。接收者必须默默地忽略他们不识别的任何选项，并继续处理消息。
A node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
节点发送反向邻居发现播发以响应反向邻居发现请求。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP字段：
Source Address An address assigned to the interface from which the advertisement is sent.
源地址分配给发送播发的接口的地址。
Destination Address The Source Address of an invoking Inverse Discovery Neighbor Solicitation.
目标地址调用反向发现邻居请求的源地址。
Hop Limit 255
跃点限制255
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
身份验证标头如果发送方和目标地址之间存在IP身份验证标头的安全关联，则发送方应包含此标头。
ICMP Fields:
ICMP字段：
Type 142
142型
Code 0
代码0
Checksum The ICMP checksum. See [ICMPv6].
校验和ICMP校验和。见[ICMPv6]。
Reserved 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留32位未使用字段。发送方必须将其初始化为零，接收方必须忽略它。
Required options:
所需选项：
The sender node MUST send the following options in the Advertisement message:
发件人节点必须在播发消息中发送以下选项：
Source Link-Layer Address The link-layer address of the sender.
源链接层地址发送方的链接层地址。
Target Link-Layer Address The link-layer address of the target, that is, the sender of the advertisement.
目标链接层地址目标的链接层地址，即广告的发送者。
Target Address List The list of one or more IPv6 addresses of the interface identified by the Target Link-Layer Address in the Inverse Neighbor Discovery Solicitation message that prompted this advertisement. This option is defined in Section 3.
目标地址列表提示此播发的反向邻居发现请求消息中由目标链路层地址标识的接口的一个或多个IPv6地址的列表。该选项在第3节中定义。
Other valid options:
其他有效选项：
The sender node MAY choose to add the following option in the Advertisement message:
发送方节点可以选择在广告消息中添加以下选项：
MTU The MTU configured for this link [IPv6-ND].
MTU为该链路配置的MTU[IPv6 ND]。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
此协议的未来版本可能会添加其他选项类型。接收者必须默默地忽略他们不识别的任何选项，并继续处理消息。
Inverse Neighbor Discovery messages include Neighbor Discovery options [IPv6-ND] as well as an Inverse Neighbor Discovery specific options: the Source Address List and the Target Address List.
反向邻居发现消息包括邻居发现选项[IPv6 ND]以及反向邻居发现特定选项：源地址列表和目标地址列表。
The Source Address List and the Target Address List option are TLV options (type, length, variable size field) (see Section 4.6 of [IPv6-ND] with the following fields:
源地址列表和目标地址列表选项是TLV选项（类型、长度、可变大小字段）（见[IPv6 ND]第4.6节，其中包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...
Fields:
领域：
Type 9 for Source Address List 10 for Target Address List
源地址列表类型9目标地址列表类型10
Note: These Option Type values should be assigned from the IPv6 Neighbor Discovery family of values.
注意：这些选项类型值应从IPv6邻居发现值系列中分配。
Length The length of the option (including the Type, Length, and the Reserved fields) in units of 8 octets. The minimum value for Length is 3, for one IPv6 address.
长度以8个八位字节为单位的选项长度（包括类型、长度和保留字段）。对于一个IPv6地址，长度的最小值为3。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
IPv6 Addresses One or more IPv6 addresses of the interface.
IPv6地址接口的一个或多个IPv6地址。
Description:
说明：
The Source Address List contains a list of IPv6 addresses of the interface identified by the Source Link-Layer Address.
源地址列表包含由源链路层地址标识的接口的IPv6地址列表。
The Target Address List contains a list of IPv6 addresses of the interface identified by the Target Link-Layer Address.
目标地址列表包含由目标链路层地址标识的接口的IPv6地址列表。
The number of addresses "n" in the list is calculated based on the length of the option:
列表中地址“n”的数量根据选项的长度计算：
n = (Length - 1)/2 (Length is the number of groups of 8 octets)
n = (Length - 1)/2 (Length is the number of groups of 8 octets)
The Source Address List MUST fit in one IND Solicitation message. Therefore in case all IPv6 addresses of an interface do not fit in one messages, the option does not contain a complete list. For a complete list of IPv6 addresses, a node should rely on the IND Advertisement message.
源地址列表必须适合一条IND请求消息。因此，如果一个接口的所有IPv6地址不适合一条消息，则该选项不包含完整列表。对于IPv6地址的完整列表，节点应依赖IND播发消息。
The Target Address List SHOULD be the complete list of addresses of the interface identified by the Target Link-Layer Address. If the list of IPv6 addresses of an interface does not fit in one IND Advertisement message, one or more IND Advertisement messages, with the same fields as the first message, SHOULD follow. The Target Address List option(s) of the second, and subsequent message(s) SHOULD contain the rest of the IPv6 addresses of the interface identified by the Target Link-Layer Address, which did not fit in the first message.
目标地址列表应该是由目标链路层地址标识的接口地址的完整列表。如果接口的IPv6地址列表不适合一条IND播发消息，则应遵循一条或多条与第一条消息具有相同字段的IND播发消息。第二条和后续消息的目标地址列表选项应包含由目标链路层地址标识的接口的其余IPv6地址，该地址不适合第一条消息。
Note 1: The scope of the Inverse Neighbor Discovery mechanism is limited to IPv6 address discovery, that is, providing address mapping information. Therefore, it does not make any provisions or rules regarding how a node uses the addresses that were returned in an Inverse Discovery message. Furthermore, it does not exclude any particular type of IPv6 address from the Source or Target Address
注1：反向邻居发现机制的范围仅限于IPv6地址发现，即提供地址映射信息。因此，它没有对节点如何使用反向发现消息中返回的地址做出任何规定或规则。此外，它不会从源地址或目标地址中排除任何特定类型的IPv6地址
List. For example, if an interface has manually configured, and autoconfigured addresses, including temporary ones, unicast, multicast, etc..., the list should not exclude any.
列表例如，如果接口已手动配置，并且自动配置了地址，包括临时地址、单播地址、多播地址等，则列表不应排除任何地址。
Note 2: An implementation MUST NOT send duplicates in the IPv6 address list.
注2：实现不得发送IPv6地址列表中的重复项。
IND operates essentially the same as ND [IPv6-ND]: the solicitor of a target IP address sends on an interface a solicitation message, the target node responds with an advertisement message containing the information requested. The information learned MAY be stored in the Neighbor Discovery cache [IPv6-ND], as well as IPv6 address structures which may be associated with the interface.
IND的操作基本上与ND[IPv6 ND]相同：目标IP地址的代理在接口上发送请求消息，目标节点用包含所请求信息的广告消息进行响应。学习到的信息可以存储在邻居发现缓存[IPv6 ND]中，也可以存储在与接口相关联的IPv6地址结构中。
A soliciting node formats an IND Solicitation message as defined in a previous section, encapsulates the packet for the specific link-layer and sends it directly to the target node. Although the destination IP address is the all-node multicast address, the message is sent only to the target node. The significant fields for the IND protocol are the Source IP address, the Source link-layer address, the Target link-layer address, and the MTU. The latter can be used in setting the optimum value of the MTU for the link.
请求节点按照上一节中的定义格式化IND请求消息，封装特定链路层的分组，并将其直接发送到目标节点。尽管目标IP地址是全节点多播地址，但消息仅发送到目标节点。IND协议的重要字段是源IP地址、源链路层地址、目标链路层地址和MTU。后者可用于设置链路MTU的最佳值。
While awaiting a response, the sender SHOULD retransmit IND Solicitation messages approximately every RetransTimer (expiration)[IPv6-ND], even in the absence of additional traffic to the neighbor. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer.
在等待响应时，发送方应该在大约每一个重定时（过期）[IPv6 ND]重新传输IND请求消息，即使没有到邻居的额外通信量。重传速率必须限制为每个重传者每个邻居最多一次请求。
If no IND Advertisement is received after MAX_MULTICAST_SOLICIT [IPv6-ND] solicitations, inverse address resolution has failed. If the sending of the Solicitation was required by an upper-layer, the sender module MUST notify the error to the upper-layer through an appropriate mechanism (e.g., return value from a procedure call).
如果在最大多播请求[IPv6 ND]请求后未收到IND播发，则反向地址解析失败。如果上层要求发送请求，则发送方模块必须通过适当的机制（例如，过程调用的返回值）将错误通知上层。
For every IND Solicitation, the receiving node SHOULD format in response a proper IND Advertisement using the link-layer source and target address pair as well as the IPv6 source address from the IND Solicitation message.
对于每个IND请求，接收节点应使用链路层源地址和目标地址对以及来自IND请求消息的IPv6源地址格式化适当的IND广告以响应。
If a node updates the Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND Solicitation SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the source IP address and the Source link-layer address from the solicitation message - into its ND cache [IPv6-ND] as it would for a ND solicitation.
如果节点使用从IND消息中获取的信息更新邻居发现缓存，则IND请求的接收方节点应将发送方的IPv6地址/链路层地址映射（即来自请求消息的源IP地址和源链路层地址）放入其ND缓存[IPv6 ND]就好像是一个讨价还价的人。
Because IPv6 nodes may have multiple IPv6 addresses per interface, a node responding to an IND Solicitation SHOULD return in the Target Address List option a list containing one or more IPv6 addresses corresponding to the interface identified by the Target Link-Layer Address field in the solicitation message. The list MUST not contain duplicates.
由于IPv6节点每个接口可能有多个IPv6地址，响应IND请求的节点应在目标地址列表选项中返回一个列表，该列表包含一个或多个IPv6地址，对应于请求消息中目标链路层地址字段标识的接口。列表中不得包含重复项。
If a node updates The Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND advertisement SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the IP addresses from Target addresses list and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND advertisement.
如果节点使用从IND消息中学习到的信息更新邻居发现缓存，则IND播发的接收方节点应将发送方的IPv6地址/链路层地址映射（即，来自目标地址列表的IP地址和来自IND播发消息的源链路层地址）放入其ND缓存[IPv6 ND]就像做广告一样。
Inverse Neighbor Discovery messages are validated as follows:
反向邻居发现消息的验证如下所示：
A node MUST silently discard any received Inverse Neighbor Solicitation messages that do not satisfy all of the following validity checks:
节点必须以静默方式丢弃任何接收到的不满足以下所有有效性检查的反向邻居请求消息：
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IP跃点限制字段的值为255，即数据包不可能由路由器转发。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- 如果消息包含IP身份验证标头，则消息将正确进行身份验证。
- ICMP Checksum is valid.
- ICMP校验和有效。
- ICMP Code is 0.
- ICMP代码为0。
- ICMP length (derived from the IP length) is 24 or more octets.
- ICMP长度（源自IP长度）为24个或更多八位字节。
- The Target Link-Layer Address is a required option and MUST be present.
- 目标链路层地址是必需的选项，必须存在。
- The Source Link-Layer Address is a required option and MUST be present.
- 源链路层地址是必需的选项，必须存在。
- All included options have a length that is greater than zero.
- 所有包含的选项的长度都大于零。
The content of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项；向后不兼容的更改可能使用不同的代码值。
The contents of any Neighbor Discovery [IPv6-ND] options that are not specified to be used with Inverse Neighbor Discovery Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
必须忽略未指定用于反向邻居发现请求消息的任何邻居发现[IPv6 ND]选项的内容，并按正常方式处理数据包。除所需选项外，唯一定义的选项是MTU选项。
An Inverse Neighbor Solicitation that passes the validity checks is called a "valid solicitation".
通过有效性检查的反向邻居请求称为“有效请求”。
A node MUST silently discard any received Inverse Neighbor Discovery Advertisement messages that do not satisfy all of the following validity checks:
节点必须以静默方式丢弃任何接收到的不满足以下所有有效性检查的反向邻居发现播发消息：
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IP跃点限制字段的值为255，即数据包不可能由路由器转发。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- 如果消息包含IP身份验证标头，则消息将正确进行身份验证。
- ICMP Checksum is valid.
- ICMP校验和有效。
- ICMP Code is 0.
- ICMP代码为0。
- ICMP length (derived from the IP length) is 48 or more octets.
- ICMP长度（源自IP长度）为48或更多个八位字节。
- Source Link-Layer Address option is present.
- 存在源链接层地址选项。
- Target Link-Layer Address option is present.
- 存在目标链路层地址选项。
- The Target Address List option is present.
- 目标地址列表选项已存在。
- The length of the Target Address List option is at least 3.
- 目标地址列表选项的长度至少为3。
- All other included options have a length that is greater than zero.
- 所有其他包含的选项的长度都大于零。
The contents of the Reserved fields, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved fields or add new options; backward-incompatible changes may use different Code values.
必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项；向后不兼容的更改可能使用不同的代码值。
The contents of any defined options [IPv6-ND] that are not specified to be used with Inverse Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
必须忽略未指定用于反向邻居播发消息的任何已定义选项[IPv6 ND]的内容，并按正常方式处理数据包。除所需选项外，唯一定义的选项是MTU选项。
An Inverse Neighbor Advertisement that passes the validity checks is called a "valid advertisement".
通过有效性检查的反向邻居播发称为“有效播发”。
When being employed on point to point virtual circuits, as it is the case with Frame Relay networks, Inverse Neighbor Discovery messages are less sensitive to impersonation attacks from on-link nodes, as it would be the case with broadcast links.
当在点对点虚拟电路上使用时（如帧中继网络），反向邻居发现消息对来自链路节点的模拟攻击不太敏感，广播链路也是如此。
Like Neighbor Discovery, the protocol reduces the exposure to threats from off-link nodes in the absence of authentication by ignoring IND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor.
与邻居发现一样，该协议通过忽略从断开链路发送方接收的IND数据包，减少了在没有身份验证的情况下来自断开链路节点的威胁。验证所有接收数据包的跃点限制字段是否包含最大合法值255。因为路由器减少了它们转发的所有数据包的跳数限制，所以接收到的包含255跳数限制的数据包必须来自邻居。
Inverse Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPSEC-Auth]. A node SHOULD include an Authentication Header when sending Inverse Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
反向邻居发现协议数据包交换可以使用IP身份验证头[IPSEC Auth]进行身份验证。如果目标地址存在用于IP身份验证头的安全关联，则节点在发送反向邻居发现数据包时应包括身份验证头。安全关联可能是通过手动配置或某些密钥管理协议的操作创建的。
Received Authentication Headers in Inverse Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored.
必须验证反向邻居发现数据包中接收到的身份验证头的正确性，并且必须忽略身份验证不正确的数据包。
In case of use with Frame Relay, to avoid an IP Security Authentication verification failure, the Frame Relay specific preprocessing of a Neighbor Discovery Solicitation message that contains a DLCI format Source link-layer address option, MUST be done by the receiver node after it completed IP Security processing.
在与帧中继一起使用的情况下，为避免IP安全身份验证失败，接收方节点必须在完成IP安全处理后，对包含DLCI格式源链路层地址选项的邻居发现请求消息进行特定于帧中继的预处理。
It SHOULD be possible for the system administrator to configure a node to ignore any Inverse Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
系统管理员应该可以将节点配置为忽略任何未使用身份验证标头或封装安全负载进行身份验证的反向邻居发现消息。这种开关应该默认为允许未经验证的消息。
Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-ESP].
机密性问题由IP安全体系结构和IP封装安全有效负载文档[IPSEC]、[IPSEC-ESP]解决。
IANA was requested to assign two new ICMPv6 type values, as described in Section 2.1 and 2.2. They were assigned from the Informational range of messages, as defined in Section 2.1 of RFC 2463. There were no ICMPv6 code values defined for these types (other than 0); future assignments are to be made under Standards Action as defined in RFC 2434.
IANA被要求分配两个新的ICMPv6类型值，如第2.1节和第2.2节所述。它们是根据RFC 2463第2.1节中定义的信息范围分配的。没有为这些类型定义ICMPv6代码值（0除外）；未来的任务将根据RFC 2434中定义的标准行动进行。
IANA was also requested to assign two new ICMPv6 Neighbor Discovery Option types as defined in Section 3.1. No outside reviewing was necessary.
IANA还被要求分配第3.1节中定义的两种新的ICMPv6邻居发现选项类型。没有必要进行外部审查。
Thanks to Steve Deering, Thomas Narten and Erik Nordmark for discussing the idea of Inverse Neighbor Discovery. Thanks to Thomas Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing.
感谢Steve Deering、Thomas Narten和Erik Nordmark讨论了逆邻居发现的概念。感谢Thomas Narten和Erik Nordmark，以及Dan Harrington、Milan Merhar、Barbara Fox、Martin Mueller和Peter Tam的全面回顾。
Also it should be acknowledged that parts of the text in this specification derived from the IPv6 Neighbor Discovery text [IPv6- ND].
还应该承认，本规范中的部分文本源自IPv6邻居发现文本[IPv6-ND]。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议版本6规范”，RFC 2460，1998年12月。
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6 ND]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[ICMPv6] Conta, A., and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6", RFC 2463, December 1998.
[ICMPv6]Conta，A.和S.Deering“互联网协议版本6的互联网控制消息协议”，RFC 2463，1998年12月。
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks", RFC 2590, May 1999. December 1997.
[IPv6 FR]Conta，A.，Malis，A.和M.Mueller，“通过帧中继网络传输IPv6数据包”，RFC 25901999年5月。1997年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[IPSEC认证]Atkinson，R.和S.Kent，“IP认证头”，RFC 2402，1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[IPSEC-ESP]Atkinson，R.和S.Kent，“IP封装安全协议（ESP）”，RFC 2406，1998年11月。
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, March 1994.
[分配]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年3月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, November 1998.
[ENCAPS]Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 2427，1998年11月。
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse Address Resolution Protocol", RFC 2390, August 1998.
[INV-ARP]Bradley，T.，Brown，C.和A.Malis“反向地址解析协议”，RFC 23901998年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
Alex Conta Transwitch Corporation 3企业大道谢尔顿，CT 06484
Phone: +1-203-929-8810
EMail: aconta@txc.com
Phone: +1-203-929-8810
EMail: aconta@txc.com
A. Inverse Neighbor Discovery with Frame Relay Networks
A.使用帧中继网络的反向邻居发现
This appendix documents the details of using the Inverse Neighbor Discovery on Frame Relay Networks, which were too specific to be part of the more general content of the previous sections.
本附录记录了在帧中继网络上使用反向邻居发现的详细信息，这些内容过于具体，无法作为前几节更一般内容的一部分。
The Inverse Neighbor Discovery (IND) specifically applies to Frame Relay nodes. Frame Relay permanent virtual circuits (PVCs) and switched virtual circuits (SVCs) are identified in a Frame Relay network by a Data Link Connection Identifier (DLCI). Each DLCI defines for a Frame Relay node a single virtual connection through the wide area network (WAN). A DLCI has in general a local significance.
反向邻居发现（IND）特别适用于帧中继节点。帧中继永久虚拟电路（PVC）和交换虚拟电路（SVC）在帧中继网络中由数据链路连接标识符（DLCI）标识。每个DLCI通过广域网（WAN）为帧中继节点定义单个虚拟连接。DLCI通常具有局部意义。
By way of specific signaling messages, a Frame Relay network may announce to a node a new virtual circuit with its corresponding DLCI. The DLCI identifies to a node a virtual circuit, and can be used as the equivalent of a remote node link-layer address, allowing a node to identify at link layer level the node at the other end of the virtual circuit. For instance in Figure 1., node A (local node) identifies the virtual circuit to node B (remote node) by way of DLCI = 30. However, the signaling message does not contain information about the DLCI used by a remote node to identify the virtual circuit to the local node, which could be used as the equivalent of the local link-layer address. For instance in Figure 1., node B (remote node) may identify the virtual circuit to node A by way of DLCI = 62.
通过特定信令消息的方式，帧中继网络可以向节点宣布具有其相应DLCI的新虚拟电路。DLCI向节点标识虚拟电路，并可用作远程节点链路层地址的等效物，允许节点在链路层级别标识虚拟电路另一端的节点。例如，在图1中，节点A（本地节点）通过DLCI=30来标识节点B（远程节点）的虚拟电路。然而，信令消息不包含关于远程节点用于识别本地节点的虚拟电路的DLCI的信息，该虚拟电路可用作本地链路层地址的等效物。例如，在图1中，节点B（远程节点）可以通过DLCI＝62来识别到节点A的虚拟电路。
Furthermore, the message being transmitted at link-layer level and completely independent of the IPv6 protocol does not include any IPv6 addressing information. The Inverse Neighbor Discovery is a protocol that allows a Frame Relay node to discover the equivalent of a local link layer address, that is, the identifier by way of which remote nodes identify the node, and more importantly discover the IPv6 addresses of the interface at the other end of the virtual circuit, identified by the remote link-layer address.
此外，在链路层级别传输且完全独立于IPv6协议的消息不包括任何IPv6寻址信息。反向邻居发现是一种协议，它允许帧中继节点发现本地链路层地址的等价物，即远程节点识别节点的标识符，更重要的是发现虚拟电路另一端接口的IPv6地址，由远程链路层地址标识。
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.
The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame Relay node to discover dynamically the DLCI by which a remote node identifies the virtual circuit. It also allows a node to learn the IPv6 addresses of a node at the remote end of a virtual circuit.
IPv6反向邻居发现（IND）协议允许帧中继节点动态发现远程节点用来识别虚拟电路的DLCI。它还允许节点了解虚拟电路远端节点的IPv6地址。
Frame Relay nodes generate Inverse Neighbor Discovery messages as follows:
帧中继节点生成反向邻居发现消息，如下所示：
The sender of an Inverse Neighbor Discovery Solicitation does not know the remote node's IPv6 addresses, but knows the equivalent of a remote node link-layer address. Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address (DLCI).
反向邻居发现请求的发送方不知道远程节点的IPv6地址，但知道远程节点链路层地址的等效地址。反向邻居发现（IND）请求作为IPv6所有节点多播[IPv6]、[IPv6 FR]、[ENCAPS]发送。然而，在链路层级别，IND请求直接发送到由已知链路层地址（DLCI）标识的目标节点。
The fields of the message, which are filled following considerations specific to Frame Relay are:
消息的字段填写了以下特定于帧中继的注意事项：
Source Link-Layer Address For the sender Frame Relay node, the Source Link-Layer Address is the equivalent of the link-layer address by which the remote node identifies the source of this message. The sender may have no knowledge of this information. If the sender knows the information, it SHOULD include it in the field, otherwise it SHOULD live it zero (empty). This information, if present, can be used for network debugging purposes. Regardless of the sender's action on this field, prior to any Inverse Neighbor Discovery processing, the receiver of this message replaces this field, whether filled in or not by the sender, with information carried by the Frame Relay header in the DLCI field. The field is encoded in DLCI format as defined by [IPv6-FR].
源链路层地址对于发送方帧中继节点，源链路层地址相当于远程节点用来标识此消息源的链路层地址。发件人可能不知道此信息。如果发送方知道该信息，则应将其包含在字段中，否则应为零（空）。此信息（如果存在）可用于网络调试目的。无论发送方对此字段采取何种操作，在进行任何反向邻居发现处理之前，此消息的接收方都会使用DLCI字段中帧中继头携带的信息替换此字段（无论发送方是否填写）。该字段以[IPv6 FR]定义的DLCI格式编码。
Target Link-Layer Address For sender Frame Relay node, the Target Link-Layer Address field is filled with the value known as the equivalent of the target node link-layer address. This value is the DLCI of the VC to the target node. It is encoded in DLCI format [IPv6-FR].
目标链路层地址对于发送方帧中继节点，目标链路层地址字段填充的值称为目标节点链路层地址的等效值。此值是VC到目标节点的DLCI。它以DLCI格式[IPv6 FR]编码。
To illustrate the generating of a IND Solicitation message by a Frame Relay node, let's consider as an example Node A (Figure 1.) which sends an IND solicitation to Node B. The Solicitation message fields will have the following values:
为了说明由帧中继节点生成一个IE请求消息，让我们考虑一个示例节点A（图1），它向节点B发送一个IE请求。
At Node A (sender of the IND solicitation message).
在节点A（IND请求消息的发送方）。
Source Link-Layer Address DLCI=unknown (overwritten by the receiver).
源链路层地址DLCI=未知（由接收器覆盖）。
Target Link-Layer Address DLCI=30.
目标链路层地址DLCI=30。
At Node B (receiver of the IND solicitation message).
在节点B（IND请求消息的接收者）。
Source Link-Layer Address DLCI=62 (filled in by the receiver).
源链路层地址DLCI=62（由接收方填写）。
Target Link-Layer Address DLCI=30.
目标链路层地址DLCI=30。
Note: For Frame Relay, both the above addresses are in Q.922 format (DLCI), which can have 10 (default), or 23 significant addressing bits [IPv6-FR]. The option length (link-layer address) is expressed in 8 octet units, therefore, the DLCI will have to be extracted from the 8 bytes based on the EA field (bit 0) of the second, third, or forth octet (EA = 1). The C/R, FECN, BECN, DE fields in the Q.922 address have no significance for IND and are set to 0 [IPv6-FR].
注意：对于帧中继，上述两个地址都是Q.922格式（DLCI），可以有10个（默认）或23个有效寻址位[IPv6 FR]。选项长度（链路层地址）以8个八位字节单位表示，因此，必须根据第二、第三或第四个八位字节（EA=1）的EA字段（位0）从8个字节中提取DLCI。Q.922地址中的C/R、FECN、BECN、DE字段对IND没有意义，设置为0[IPv6 FR]。
MTU The value filled in the MTU option is the MTU for the virtual circuit identified by the known DLCI [IPv6-FR].
MTU MTU选项中填写的值是由已知DLCI[IPv6 FR]标识的虚拟电路的MTU。
A Frame Relay node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
帧中继节点响应于反向邻居发现请求发送反向邻居发现广告。
The fields of the message, which are filled following considerations specific to Frame Relay are:
消息的字段填写了以下特定于帧中继的注意事项：
Source Link-Layer Address For Frame Relay, this field is copied from the Target link-layer address field of the Inverse Neighbor Discovery Solicitation. It is encoded in DLCI format [IPv6-FR].
帧中继的源链路层地址，此字段从反向邻居发现请求的目标链路层地址字段复制。它以DLCI格式[IPv6 FR]编码。
Target Link-Layer Address For Frame Relay, this field is copied from the Source link-layer address field of the Inverse Neighbor Discovery Solicitation. It is encoded in DLCI format [IPv6-FR].
帧中继的目标链路层地址，此字段从反向邻居发现请求的源链路层地址字段复制。它以DLCI格式[IPv6 FR]编码。
For example if Node B (Figure 1.) responds to an IND solicitation sent by Node A. with an IND advertisement, these fields will have the following values:
例如，如果节点B（图1.）响应节点A发送的IND请求，则这些字段将具有以下值：
At Node B (sender of the advertisement message):
在节点B（广告消息的发送者）：
Source Link-Layer Address DLCI=30 (was Target in Solicitation Message).
源链路层地址DLCI=30（是请求消息中的目标）。
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
目标链路层地址DLCI=62（是请求消息中的源）。
At Node A (receiver of the advertisement message from B).
在节点A（来自B的广告消息的接收器）。
Source Link-Layer Address DLCI=30 (was Target in Solicitation Message).
源链路层地址DLCI=30（是请求消息中的目标）。
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
目标链路层地址DLCI=62（是请求消息中的源）。
Target Address List The list of one or more IPv6 addresses of the interface identified by the Target Link-Layer Address in the Inverse Neighbor Discovery Solicitation message that prompted this advertisement.
目标地址列表提示此播发的反向邻居发现请求消息中由目标链路层地址标识的接口的一个或多个IPv6地址的列表。
MTU The MTU configured for this link (virtual circuit) [IPv6-ND].
MTU为该链路配置的MTU（虚拟电路）[IPv6 ND]。
Note: In case of Frame Relay networks, the IND messages are sent on a virtual circuit, which acts like a virtual-link. If the virtual circuit breaks, all participants to the circuit receive appropriate link layer signaling messages, which can be propagated to the upper layers, including IPv6.
注意：在帧中继网络的情况下，IND消息在虚拟电路上发送，其作用类似于虚拟链路。如果虚拟电路中断，电路的所有参与者都会收到适当的链路层信令消息，这些消息可以传播到上层，包括IPv6。
This section of the appendix documents only the specific aspects of Inverse Neighbor Discovery with Frame Relay Networks.
附录的这一部分仅记录了帧中继网络反向邻居发现的具体方面。
A soliciting Frame Relay node formats an IND solicitation message as defined in a previous section, encapsulates the packet for the Frame Relay link-layer [IPv6-FR] and sends it to the target Frame Relay node. Although the destination IP address is the IPv6 all-node multicast address, the message is sent only to the target Frame Relay node. The target node is the known remote node on the link represented by the virtual circuit.
请求帧中继节点按照上一节中的定义格式化IND请求消息，封装帧中继链路层[IPv6-FR]的分组，并将其发送到目标帧中继节点。尽管目标IP地址是IPv6全节点多播地址，但消息仅发送到目标帧中继节点。目标节点是虚拟电路表示的链路上的已知远程节点。
A Frame Relay node, before further processing, is replacing in the Source link-layer address the existent DLCI value with the DLCI value from the Frame Relay header of the frame containing the message. The DLCI value has to be formatted appropriately in the Source link-layer address field [IPv6-FR]. This operation is required to allow a correct interpretation of the fields in the further processing of the IND solicitation message.
在进一步处理之前，帧中继节点将源链路层地址中的现有DLCI值替换为包含消息的帧的帧中继报头中的DLCI值。DLCI值必须在源链路层地址字段[IPv6 FR]中正确格式化。需要进行此操作，以便在进一步处理IND请求消息时正确解释字段。
For a Frame Relay node, the MTU value from the solicitation message MAY be used to set the receiver's MTU to a value that is more optimal, in case that was not already done at the interface configuration time.
对于帧中继节点，来自请求消息的MTU值可用于将接收机的MTU设置为更优化的值，前提是在接口配置时尚未这样做。
The receiver Frame Relay node of the IND Advertisement MAY put the sender's IPv6 address/link-layer address mapping - i.e., the Target IP addresses and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND Advertisement.
IND广告的接收器帧中继节点可以将发送方的IPv6地址/链路层地址映射（即，来自IND广告消息的目标IP地址和源链路层地址）放入其ND高速缓存[IPv6 ND]，就像它用于ND广告一样。
Further, the receiver Frame Relay node of the IND Advertisement MAY store the Target link-layer address from the message as the DLCI value at the remote end of the VC. This DLCI value is the equivalent of the link-layer address by which the remote node identifies the receiver.
此外，IND广告的接收器帧中继节点可以在VC的远端将来自消息的目标链路层地址存储为DLCI值。此DLCI值相当于远程节点用来标识接收器的链路层地址。
If the receiver node of the IND Advertisement has a pool of IPv6 addresses, and if the implementation allows, it may take decisions to pairing specific local IPv6 addresses to specific IPv6 addresses from the target list in further communications on the VC. More specifically, such a pairing may be based on IPv6 addresses being on the same subnet, that is having the same prefix.
如果IND广告的接收器节点具有IPv6地址池，并且如果实现允许，则其可以在VC上的进一步通信中决定将特定本地IPv6地址与目标列表中的特定IPv6地址配对。更具体地说，这种配对可以基于位于相同子网上的具有相同前缀的IPv6地址。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。