Network Working Group G. Armitage
Request for Comments: 2491 Lucent Technologies
Category: Standards Track P. Schulter
Bright Tiger Technologies
M. Jork
Digital Equipment GmbH
G. Harter
Compaq
January 1999
Network Working Group G. Armitage
Request for Comments: 2491 Lucent Technologies
Category: Standards Track P. Schulter
Bright Tiger Technologies
M. Jork
Digital Equipment GmbH
G. Harter
Compaq
January 1999
IPv6 over Non-Broadcast Multiple Access (NBMA) networks
非广播多址（NBMA）网络上的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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.
本文档描述了NBMA网络上IPv6的通用体系结构。它构成了描述各种特定NBMA技术（如ATM或帧中继）细节的附属配套文件的基础。IPv6 over NBMA体系结构允许IPv6邻居发现协议的常规主机端操作，同时还支持在动态信号NBMA链路可用时建立“快捷”NBMA转发路径。还描述了管理配置的点对点NBMA链路上的操作。
Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor Discovery protocol operation within Logical Links, and inter-router NHRP for the discovery of off-Link NBMA destinations. Both flow-triggered and explicitly source-triggered shortcuts are supported.
动态NBMA快捷方式是通过在逻辑链路中使用IPv6邻居发现协议操作，以及用于发现非链路NBMA目的地的路由器间NHRP来实现的。支持流触发和显式源触发的快捷方式。
1. Introduction.
1. 介绍
Non Broadcast Multiple Access (NBMA) networks may be utilized in a variety of ways. At one extreme, they can be used to simply provide administratively configurable point to point service, sufficient to interconnect IPv6 routers (and even IPv6 hosts, in certain
非广播多址（NBMA）网络可以以多种方式使用。在一个极端，它们可以用来简单地提供管理上可配置的点对点服务，足以互连IPv6路由器（在某些情况下甚至是IPv6主机）
situations). At the other extreme, NBMA networks that support dynamic establishment and teardown of Virtual Circuits (or functional equivalents) may be used to emulate the service provided to the IPv6 layer by conventional broadcast media such as Ethernet. Typically this emulation requires complex convergence protocols, particularly to support IPv6 multicast.
情况）。在另一个极端，支持虚拟电路（或功能等价物）的动态建立和拆卸的NBMA网络可用于模拟由诸如以太网的传统广播媒体提供给IPv6层的服务。通常，此仿真需要复杂的收敛协议，尤其是支持IPv6多播。
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for companion documents that provide details specific to various NBMA technologies (for example, ATM [17] or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths (when dynamically signaled NBMA links are available).
本文档描述了NBMA网络上IPv6的通用体系结构。它构成了附带文档的基础，这些文档提供了各种NBMA技术（例如ATM[17]或帧中继）的具体细节。IPv6 over NBMA体系结构允许IPv6邻居发现协议的常规主机端操作，同时还支持建立“快捷”NBMA转发路径（当动态信号NBMA链路可用时）。
The majority of this document focuses on the use of dynamically managed point to point and point to multipoint calls between interfaces on an NBMA network. These will be generically referred to as "SVCs" in the rest of the document. The use of administratively configured point to point calls will also be discussed. Such calls will be generically referred to as "PVCs". Depending on context, either may be shortened to "VC".
本文档的大部分内容侧重于在NBMA网络上的接口之间使用动态管理的点对点和点对多点调用。在本文件的其余部分中，这些将被统称为“SVC”。还将讨论管理配置的点到点调用的使用。此类电话一般称为“PVC”。根据上下文的不同，两者都可以缩写为“VC”。
Certain NBMA networks may provide a form of connectionless service (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to implicitly exist if the sender has an NBMA destination address to which it can transmit packets whenever it desires.
某些NBMA网络可提供一种形式的无连接服务（例如SMD）。在这些情况下，如果发送方有一个NBMA目的地地址，它可以在任何时候发送数据包，则“呼叫”或“VC”应被视为隐式存在。
1.1 Neighbor Discovery.
1.1 邻居发现。
A key difference between this architecture and previous IP over NBMA protocols is its mechanism for supporting IPv6 Neighbor Discovery.
此体系结构与以前的IP over NBMA协议之间的一个关键区别是其支持IPv6邻居发现的机制。
The IPv4 world evolved an approach to address resolution that depended on the operation of an auxiliary protocol operating at the 'link layer' - starting with Ethernet ARP (RFC 826 [14]). In the world of NBMA (Non Broadcast, Multiple Access) networks ARP has been applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577 [3]). More recently the ION working group has developed NHRP (Next Hop Resolution Protocol [8]), a general protocol for performing intra-subnet and inter-subnet address resolution applicable to a range of NBMA network technologies.
IPv4世界发展了一种地址解析方法，该方法依赖于在“链路层”上运行的辅助协议的操作——从以太网ARP开始（RFC 826[14]）。在NBMA（非广播多址）网络世界中，ARP已应用于通过SMD的IPv4（RFC 1209[13]）和通过ATM的IPv4（RFC 1577[3]）。最近，ION工作组开发了NHRP（下一跳解析协议[8]），这是一种用于执行子网内和子网间地址解析的通用协议，适用于一系列NBMA网络技术。
IPv6 developers opted to migrate away from a link layer specific approach, chosing to combine a number of tasks into a protocol known as Neighbor Discovery [7], intended to be non-specific across a number of link layer technologies. A key assumption made by Neighbor Discovery's actual protocol is that the link technology underlying a
IPv6开发人员选择从特定于链路层的方法迁移，选择将大量任务组合到称为邻居发现[7]的协议中，旨在跨大量链路层技术实现非特定性。邻居发现的实际协议的一个关键假设是
given IP interface is capable of native multicasting. This is not particularly true of most NBMA network services, and usually requires convergence protocols to emulate the desired service. (The MARS protocol, RFC 2022 [5], is an example of such a convergence protocol.) This document augments and optimizes the MARS protocol for use in support of IPv6 Neighbor Discovery, generalizing the applicability of RFC 2022 beyond ATM networks.
给定的IP接口能够进行本机多播。对于大多数NBMA网络服务来说，情况并非如此，通常需要收敛协议来模拟所需的服务。（MARS协议RFC 2022[5]就是这种融合协议的一个例子。）本文档扩充并优化了MARS协议，用于支持IPv6邻居发现，将RFC 2022的适用性推广到ATM网络之外。
1.2 NBMA Shortcuts.
1.2 NBMA快捷方式。
A shortcut is an NBMA level call (VC) directly connecting two IP endpoints that are logically separated by one or more routers at the IP level. IPv6 packets traversing this VC are said to 'shortcut' the routers that are in the logical IPv6 path between the VC's endpoints.
快捷方式是直接连接两个IP端点的NBMA级别调用（VC），这两个IP端点在IP级别上由一个或多个路由器逻辑分隔。穿过此VC的IPv6数据包被称为“快捷方式”，即VC端点之间的逻辑IPv6路径中的路由器。
NBMA shortcuts are a mechanism for minimizing the consumption of resources within an IP over NBMA cloud (e.g. router hops and NBMA VCs).
NBMA快捷方式是一种将IP over NBMA云中的资源消耗降至最低的机制（例如路由器跳数和NBMA VCs）。
It is important that NBMA shortcuts are supported whenever IP is deployed across NBMA networks capable of supporting dynamic establishment of calls (SVCs or functional equivalent). For IPv6 over NBMA, shortcut discovery and management is achieved through a mixture of Neighbor Discovery and NHRP.
重要的是，只要IP部署在能够支持动态建立呼叫（SVC或等效功能）的NBMA网络上，就必须支持NBMA快捷方式。对于NBMA上的IPv6，通过邻居发现和NHRP的混合实现快捷方式发现和管理。
1.3 Key components of the IPv6 over NBMA architecture.
1.3 IPv6 over NBMA体系结构的关键组件。
1.3.1 NBMA networks providing PVC support.
1.3.1 NBMA网络提供PVC支持。
When the NBMA network is used in PVC mode, each PVC will connect exactly two nodes and the use of Neighbor Discovery and other IPv6 features is limited. IPv6/NBMA interfaces have only one neighbor on each Link. The MARS and NHRP protocols are NOT necessary, since multicast and broadcast operations collapse down to an NBMA level unicast operation. Dynamically discovered shortcuts are not supported.
当NBMA网络在PVC模式下使用时，每个PVC将恰好连接两个节点，并且邻居发现和其他IPv6功能的使用受到限制。IPv6/NBMA接口在每个链路上只有一个邻居。MARS和NHRP协议是不必要的，因为多播和广播操作崩溃为NBMA级别的单播操作。不支持动态发现的快捷方式。
The actual details of encapsulations and link token generation SHALL be covered by companion documents covering specific NBMA technology. They SHALL conform to the following guidelines:
封装和链接令牌生成的实际细节应包含在涵盖特定NBMA技术的配套文件中。它们应符合以下指南：
Both unicast and multicast IPv6 packets SHALL be transmitted over PVC links using the encapsulation described in section 4.4.1.
单播和多播IPv6数据包应使用第4.4.1节所述的封装通过PVC链路传输。
Interface tokens for PVC links SHALL be constructed as described in section 5. Interface tokens need only be unique between the two nodes on the PVC link.
PVC链路的接口标记应按照第5节所述进行构造。接口令牌只需在PVC链路上的两个节点之间是唯一的。
This use of PVC links does not mandate, nor does it prohibit the use of extensions to the Neighbor Discovery protocol which may be developed for either general use of for use in PVC connections (for example, Inverse Neighbor Discovery).
PVC链路的这种使用不强制也不禁止使用邻居发现协议的扩展，该协议可开发用于PVC连接中的一般用途（例如，反向邻居发现）。
NBMA-specific companion documents MAY additionally specify the concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an OPTIONAL approach to point to point IPv6.
NBMA特定的配套文件还可以指定IPv6 over PPP和PPP over NBMA机制的串联，作为点对点IPv6的可选方法。
Except where noted above, the remainder of this document focuses on the SVC case.
除上述情况外，本文件其余部分将重点介绍SVC案例。
1.3.2 NBMA networks providing SVC support.
1.3.2 提供SVC支持的NBMA网络。
When the NBMA network is used in SVC mode, the key components are:
在SVC模式下使用NBMA网络时，关键部件包括：
- The IPv6 Neighbor model, where neighbors are discovered through the use of messages multicast to members of an IPv6 interface's local IPv6 Link. - The MARS model, allowing emulation of general multicast using multipoint calls provided by the underlying NBMA network. - The NHRP service for seeking out the NBMA identities of IP interfaces who are logically distant in an IP topological sense. - The modeling of IP traffic as 'flows', and optionally using the existence of a flow as the basis for attempting to set up a shortcut link level connection.
- IPv6邻居模型，其中邻居通过使用多播消息发现到IPv6接口的本地IPv6链路的成员。-MARS模型，允许使用底层NBMA网络提供的多点调用模拟一般多播。-NHRP服务，用于查找IP拓扑意义上逻辑距离较远的IP接口的NBMA标识。-将IP流量建模为“流”，并可选地使用流的存在作为尝试建立快捷链接级别连接的基础。
In summary:
总之：
The IPv6 "Link" is generalized to "Logical Link" (LL) in NBMA environments (analogous to the generalization of IPv4 IP Subnet to Logical IP Subnet in RFC 1209 and subsequently RFC 1577).
在NBMA环境中，IPv6“链路”被泛化为“逻辑链路”（LL）（类似于RFC 1209和随后的RFC 1577中IPv4 IP子网泛化为逻辑IP子网）。
IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra-Logical Link multicasting. The MARS itself is used to optimally distribute discovery messages within the Logical Link.
IPv6/NBMA接口利用RFC 2022（MARS）进行一般的逻辑内链路多播。MARS本身用于在逻辑链路中以最佳方式分发发现消息。
For destinations not currently considered to be Neighbors, a host sends the packets to one of its default routers.
对于当前未被视为邻居的目的地，主机将数据包发送到其默认路由器之一。
When appropriately configured, the egress router from a Logical Link is responsible for detecting the existence of an IP packet flow through it that might benefit from a shortcut connection.
当适当配置时，来自逻辑链路的出口路由器负责检测通过它的IP分组流的存在，该IP分组流可能受益于快捷连接。
While continuing to conventionally forward the flow's packets, the router initiates an NHRP query for the flow's destination IP address.
在继续传统地转发流的分组的同时，路由器发起针对流的目的地IP地址的NHRP查询。
The last router/NHS before the target of the NHRP query ascertains the target interface's preferred NBMA address.
NHRP查询目标之前的最后一个路由器/NHS确定目标接口的首选NBMA地址。
The originally querying router then issues a Redirect to the IP source, identifying the flow's destination as a transient Neighbor.
最初查询的路由器然后向IP源发出重定向，将流的目的地标识为临时邻居。
Host-initiated triggering of shortcut discovery, regardless of the existence of a packet flow, is also supported through specific Neighbor Solicitations sent to a source host's default router.
通过发送到源主机的默认路由器的特定邻居请求，也支持主机启动的快捷方式发现触发，而不管是否存在数据包流。
A number of key advantages are claimed for this approach. These are:
这种方法有许多关键优势。这些是：
The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology.
主机上的IPv6堆栈不会为每个链路层技术实现单独的ND协议。
When the destination of a flow is solicited as a transient neighbor, the returned NBMA address will be the one chosen by the destination when the flow was originally established through hop-by-hop processing. This supports the existing ND ability for IPv6 destinations to perform their own dynamic interface load sharing.
当请求流的目的地作为临时邻居时，返回的NBMA地址将是最初通过逐跳处理建立流时目的地选择的地址。这支持IPv6目标执行其自己的动态接口负载共享的现有ND功能。
1.4 Terminology.
1.4 术语
The bit-pattern or numeric value used to identify a particular NBMA interface at the NBMA level will be referred to as an "NBMA address". (An example would be an ATM End System Address, AESA, when applying this architecture to ATM networks, or an E.164 number when applying this architecture to SMDS networks.)
用于在NBMA级别识别特定NBMA接口的位模式或数值将被称为“NBMA地址”。（将此体系结构应用于ATM网络时，例如ATM终端系统地址AESA，或将此体系结构应用于SMDS网络时，例如E.164号。）
The call that, once established, is used to transfer IP packets from one NBMA interface to another will be referred to as an SVC or PVC depending on whether the call is dynamically established through some signaling mechanism, or administratively established. The specific signaling mechanisms used to establish or tear down an SVC will be defined in the NBMA-specific companion specifications. Certain NBMA networks may provide a form of connectionless service (e.g. SMDS). In these cases, a "call" or "SVC" shall be considered to implicitly exist if the sender has an NBMA destination address to which it can transmit packets whenever it desires.
一旦建立，用于将IP分组从一个NBMA接口传输到另一个NBMA接口的呼叫将被称为SVC或PVC，这取决于呼叫是通过某种信令机制动态建立的，还是通过管理建立的。用于建立或拆除SVC的特定信号机制将在NBMA特定配套规范中定义。某些NBMA网络可提供一种形式的无连接服务（例如SMD）。在这些情况下，如果发送方有一个NBMA目的地地址，它可以在任何时候发送数据包，则“呼叫”或“SVC”应被视为隐式存在。
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 [16].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[16]中所述进行解释。
1.5 Document Structure.
1.5 文件结构。
The remainder of this document is structured as follows: Section 2 explains the generalization of IPv6 Link to "Logical Link" when used over NBMA networks, and introduces the notion of the Transient Neighbor. Section 3 describes the modifications to the MARS protocol for efficient distribution of ND messages within a Logical Link, and the rules and mechanisms for discovering Transient Neighbors. Section 4 covers the basic rules governing IPv6/NBMA interface initialization, packet and control message encapsulations, and rules for SVC management. Section 5 describes the general rules for constructing Interface Tokens, the Link Layer Address Option, and Link Local addresses. Section 6 concludes the normative sections of the document. Appendix A provides some non-normative descriptive text regarding the operation of Ipv6 Neighbor Discovery. Appendix B describes some sub-optimal solutions for emulating the multicasting of Neighbor Discovery messages around a Logical Link. Appendix C discusses shortcut suppression and briefly reviews the future relationships between flow detection and mapping of flows onto SVCs of differing qualities of service.
本文档的其余部分结构如下：第2节解释了在NBMA网络上使用IPv6链路时将其概括为“逻辑链路”，并介绍了瞬态邻居的概念。第3节描述了为在逻辑链路中有效分发ND消息而对MARS协议进行的修改，以及发现瞬态邻居的规则和机制。第4节介绍了管理IPv6/NBMA接口初始化、数据包和控制消息封装以及SVC管理规则的基本规则。第5节描述了构造接口令牌、链路层地址选项和链路本地地址的一般规则。第6节总结了本文件的规范性章节。附录A提供了一些关于Ipv6邻居发现操作的非规范性描述性文本。附录B描述了一些次优解决方案，用于模拟逻辑链路周围邻居发现消息的多播。附录C讨论了快捷方式抑制，并简要回顾了流量检测和将流量映射到不同服务质量的SVC之间的未来关系。
2. Logical Links, and Transient Neighbors.
2. 逻辑链路和临时邻居。
IPv6 contains a concept of on-link and off-link. Neighbors are those nodes that are considered on-link and whose link-layer addresses may therefore be located using Neighbor Discovery. Borrowing from the terminology definitions in the ND text:
IPv6包含链路上和链路下的概念。邻居是在链路上被考虑的节点，其链路层地址因此可以使用邻居发现进行定位。借用ND文本中的术语定义：
on-link - an address that is assigned to a neighbor's interface on a shared link. A host considers an address to be on-link if: - it is covered by one of the link's prefixes, or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the target address, or - a Neighbor Discovery message is received from the address.
链路上-分配给共享链路上邻居接口的地址。主机认为某个地址在链路上，如果：-该地址被链路的某个前缀覆盖，或者-相邻路由器将该地址指定为重定向消息的目标，或者-接收到目标地址的邻居播发消息，或者-从该地址接收到邻居发现消息。
off-link - the opposite of "on-link"; an address that is not assigned to any interfaces attached to a shared link.
断开连接-与“接通”相反；未分配给连接到共享链接的任何接口的地址。
Off-link nodes are considered to only be accessible through one of the routers directly attached to the link.
脱离链路的节点被认为只能通过直接连接到链路的路由器之一访问。
The NBMA environment complicates the sense of the word 'link' in much the same way as it complicated the sense of 'subnet' in the IPv4 case. For IPv4 this required the definition of the Logical IP Subnet (LIS) - an administratively constructed set of hosts that would share the same routing prefixes (network and subnetwork masks).
NBMA环境使“链接”一词的含义复杂化的方式与IPv4中使“子网”的含义复杂化的方式大致相同。对于IPv4，这需要定义逻辑IP子网（LIS）——一组管理构造的主机，共享相同的路由前缀（网络和子网络掩码）。
This document considers the IPv6 analog to be a Logical Link (LL).
本文档将IPv6模拟视为逻辑链路（LL）。
An LL consists of nodes administratively configured to be 'on link' with respect to each other.
LL由管理配置为相互“链接”的节点组成。
The members of an LL are an IPv6 interface's initial set of neighbors, and each interface's Link Local address only needs to be unique amongst this set.
LL的成员是IPv6接口的初始邻居集，每个接口的链路本地地址只需要在该邻居集中是唯一的。
It should be noted that whilst members of an LL are IPv6 Neighbors, it is possible for Neighbors to exist that are not, administratively, members of the same LL.
应该注意的是，虽然LL的成员是IPv6邻居，但在管理上，可能存在不是同一LL成员的邻居。
Neighbor Discovery events can result in the expansion of an IPv6 interface's set of Neighbors. However, this does not change the set of interfaces that make up its LL. This leads to three possible relationships between any two IPv6 interfaces:
邻居发现事件可能导致IPv6接口的邻居集的扩展。但是，这不会更改构成其LL的接口集。这导致任何两个IPv6接口之间可能存在三种关系：
- On LL, Neighbor. - Off LL, Neighbor. - Off LL, not Neighbor.
- 靠，邻居走开，邻居离开我，而不是邻居。
Off LL Neighbors represent the 'shortcut' connections, where it has been ascertained that direct connectivity at the NBMA level is possible to a target that is not a member of the source's LL.
Off LL neighbories表示“快捷”连接，其中已确定可以在NBMA级别直接连接到不是源LL成员的目标。
Neighbors discovered through the operation of unsolicited messages, such as Redirects, are termed 'Transient Neighbors'.
通过操作未经请求的消息（如重定向）发现的邻居称为“临时邻居”。
3. Intra-LL and Inter-LL Discovery.
3. LL内和LL间发现。
This document makes a distinction between the discovery of neighbors within a Logical Link (intra-LL) and neighbors beyond the LL (inter-LL). The goal is to allow both inter- and intra-LL neighbor discovery to involve no changes to the host-side IPv6 stack for NBMA interfaces.
本文档对逻辑链路内的邻居发现（LL内）和LL外的邻居发现（LL间）进行了区分。目标是允许LL间和LL内邻居发现不涉及对NBMA接口的主机端IPv6堆栈的更改。
Note that section 1.3.1 applies when the NBMA network is being used to provide only configured point to point (PVC) service.
注意，当NBMA网络仅用于提供配置的点对点（PVC）服务时，第1.3.1节适用。
3.1 Intra-LL - ND over emulated multicast.
3.1 模拟多播上的内部LL-ND。
The basic model of ND assumes that a link layer interface will do something meaningful with an ICMPv6 packet sent to a multicast IP destination address. (IPv6 assumes that multicasting is an integral part of the Internet service.) This document assumes multicast support will be provided using the RFC 2022 (MARS) [5] service (generalized for use over other NBMA technologies in addition to ATM). An IPv6 LL maps directly onto an IPv6 MARS Cluster in the same way an IPv4 LIS maps directly onto an IPv4 MARS Cluster.
ND的基本模型假设链路层接口将对发送到多播IP目标地址的ICMPv6数据包执行有意义的操作。（IPv6假设多播是互联网服务的一个组成部分。）本文档假设将使用RFC 2022（MARS）[5]服务提供多播支持（通用于除ATM之外的其他NBMA技术）。IPv6 LL直接映射到IPv6 MARS群集，就像IPv4 LIS直接映射到IPv4 MARS群集一样。
The goal of intra-LL operation is that the IPv6 layer must be able to simply pass multicast ICMPv6 packets down to the IPv6/NBMA driver without any special, NBMA specific processing. The underlying mechanism for distributing Neighbor Discovery and Router Discovery messages then works as expected.
内部LL操作的目标是IPv6层必须能够简单地将多播ICMPv6数据包传递给IPv6/NBMA驱动程序，而无需任何特殊的NBMA特定处理。然后，分发邻居发现和路由器发现消息的底层机制按预期工作。
Sections 3.1.1 describes the additional functionality that SHALL be required of any MARS used in conformance with this document. Background discussion of these additions is provided in Appendix B.
第3.1.1节描述了根据本文件使用的任何火星所需的附加功能。附录B中提供了这些补充内容的背景讨论。
3.1.1 Mandatory augmented MARS and MARS Client behavior.
3.1.1 强制增强MARS和MARS客户端行为。
IPv6/NBMA interfaces SHALL register as MARS Cluster members as described in section 4.1, and SHALL send certain classes of outgoing IPv6 packets directly to their local MARS as described in section 4.4.2.
IPv6/NBMA接口应注册为第4.1节所述的MARS集群成员，并应按照第4.4.2节所述将某些类别的传出IPv6数据包直接发送至其本地MARS。
The MARS itself SHALL then re-transmit these packets according to the following rules:
然后，MARS本身应根据以下规则重新传输这些数据包：
- When the MARS receives an IPv6 packet, it scans the group membership database to find the NBMA addresses of the IPv6 destination group's members.
- 当MARS接收到IPv6数据包时，它扫描组成员数据库以查找IPv6目标组成员的NBMA地址。
- The MARS then checks to see if every group member currently has its pt-pt control VC open to the MARS. If so, the MARS sends a copy of the data packet directly to each group member over the existing pt-pt VCs.
- 然后，MARS检查是否每个组成员当前都有其pt控制VC对MARS开放。如果是这样，MARS通过现有pt VCs直接向每个组成员发送数据包的副本。
- If one or more of the discovered group members do not have an open pt-pt VC to the MARS, or if there are no group members listed, the packet is sent out ClusterControlVC instead. No copies of the packet are sent over the existing (if any) pt-pt VCs.
- 如果发现的一个或多个组成员没有到MARS的open pt VC，或者如果没有列出任何组成员，则将数据包发送到ClusterControlVC。不通过现有（如有）pt VCs发送数据包副本。
3.2 Inter-LL - Redirects, and their generation.
3.2 内部LL-重定向及其生成。
Shortcut connections are justified on the grounds that demanding flows of IP packets may exist between source/destination pairs that are separated by IP routing boundaries. Shortcuts are created between Transient Neighbors.
基于IP路由边界分隔的源/目的地对之间可能存在要求的IP数据包流，因此证明了快捷连接的合理性。在临时邻居之间创建快捷方式。
The key to creating transient neighbors is the Redirect message (section 8 [7]). IPv6 allows a router to inform the members of an LL that there is a better 'first hop' to a given destination (section 8.2 [7]). The advertisement itself is achieved through a Router Redirect message, which may carry the link layer address of this better hop.
创建临时邻居的关键是重定向消息（第8[7]节）。IPv6允许路由器通知LL成员到给定目的地有更好的“第一跳”（第8.2[7]节）。广告本身是通过路由器重定向消息实现的，该消息可能携带该更好跳的链路层地址。
A transmitting host only listens to Router Redirects from the router that is currently acting as the default router for the IP destination that the Redirect refers to. If a Redirect arrives that indicates a better first hop for a given destination, and supplies a link layer (NBMA) address to use as the better first hop, the associated Neighbor Cache entry in the source host is updated and its reachability set to STALE. Updating the cache in this context involves building a new VC to the new NBMA address. If this is successful, the old VC is torn down only if it no longer required (since the old VC was to the router, it may still be required by other packets from the host that are heading to the router).
传输主机仅侦听来自当前充当重定向所指IP目的地的默认路由器的路由器重定向。如果重定向到达，指示给定目的地的更好的第一跳，并提供一个链路层（NBMA）地址用作更好的第一跳，则源主机中关联的邻居缓存项将更新，其可访问性设置为STALE。在此上下文中更新缓存涉及到为新的NBMA地址构建一个新的VC。如果这是成功的，只有当不再需要旧VC时，旧VC才会被拆掉（因为旧VC已连接到路由器，所以从主机发送到路由器的其他数据包可能仍然需要旧VC）。
Two mechanisms are provided for triggering the discovery of a better first hop:
提供了两种机制来触发发现更好的第一跳：
Router-based flow identification/detection.
基于路由器的流识别/检测。
Host-initiated shortcut request.
主机启动的快捷方式请求。
Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses the host initiated trigger, and section 3.2.3 discusses the use of NHRP to discover mappings for IPv6 targets in remote LLs.
第3.2.1节讨论基于流的触发器，第3.2.2节讨论主机启动的触发器，第3.2.3节讨论使用NHRP发现远程LLs中IPv6目标的映射。
3.2.1 Flow Triggered Redirection.
3.2.1 流触发的重定向。
The modification of forwarding paths based on the dynamic detection of IP packet flows is at the core of models such as the Cell Switch Router [11] and the IP Switch [12]. Responsibility for detecting flows is placed into the routers, where packets cross the edges of IP routing boundaries.
基于IP包流动态检测的转发路径修改是蜂窝交换机路由器[11]和IP交换机[12]等模型的核心。检测流的责任放在路由器中，在路由器中，数据包穿过IP路由边界的边缘。
For the purpose of conformance with this document, a router MAY choose to initiate the discovery of a better first-hop when it determines that an identifiable flow of IP packets are passing through it.
为了符合本文档的要求，当路由器确定可识别的IP分组流正在通过它时，它可以选择启动更好的第一跳的发现。
Such a router:
这种路由器：
SHALL only track flows that originate from a directly attached host (a host that is within the LL-local scope of one of the router's interfaces).
应仅跟踪源自直连主机（在路由器接口之一的LL本地范围内的主机）的流。
SHALL NOT use IP packets arriving from another router to trigger the generation of a Router Redirect.
不得使用来自另一路由器的IP数据包触发路由器重定向的生成。
SHALL only consider IPv6 packets with FlowID of zero for the purposes of flow detection as defined in this section.
应仅考虑FlowID的零包的IPv6数据包，以便在本节中定义流量检测的目的。
SHALL utilize NHRP as described in section 3.2.3 to ascertain a better first-hop when a suitable flow is detected, and advertise the information in a Router Redirect.
应使用第3.2.3节中所述的NHRP，以确定在检测到合适的流量时更好的第一跳，并在路由器重定向中公布信息。
IPv6 routers that support the OPTIONAL flow detection behavior described above SHALL support administrative mechanisms to switch off flow-detection. They MAY provide mechanisms for adding additional constraints to the categories of IPv6 packets that constitute a 'flow'.
支持上述可选流检测行为的IPv6路由器应支持关闭流检测的管理机制。它们可以提供为构成“流”的IPv6数据包类别添加额外约束的机制。
The actual algorithm(s) for determining what sequence of IPv6 packets constitute a 'flow' are outside the scope of this document. Appendix C discusses the rationale behind the use of non-zero FlowID to suppress flow detection.
用于确定构成“流”的IPv6数据包序列的实际算法不在本文档范围内。附录C讨论了使用非零FlowID抑制流量检测的基本原理。
A source host MAY also trigger a redirection to a transient neighbor. To support host-triggered redirects, routers conforming to this document SHALL recognize specific Neighbor Solicitation messages sent by hosts as requests for the resolution of off-link addresses.
源主机还可以触发到临时邻居的重定向。为支持主机触发的重定向，符合本文件要求的路由器应将主机发送的特定邻居请求消息识别为断开链路地址解析请求。
To perform a host-triggered redirect, a source host SHALL:
要执行主机触发的重定向，源主机应：
Create a Neighbor Solicitation message referring to the off-LL destination (target) for which a shortcut is desired
创建邻居请求消息，该消息引用需要快捷方式的离线目标（目标）
Address the NS message to the router that would be the next hop for traffic sent towards the off-LL target (rather than the target's solicited node multicast address).
将NS消息寻址到路由器，该路由器将是发送到离线目标（而不是目标请求的节点多播地址）的流量的下一跳。
Use the standard ND hop limit of 255 to ensure the NS won't be discarded by the router.
使用255的标准ND跃点限制，以确保NS不会被路由器丢弃。
Include the shortcut limit option defined in appendix D. The value of this option should be equal to the hop limit of the data flow for which this trigger is being sent. This ensures that the router is able to restrict the shortcut attempt to not exceed the reach of the data flow.
包括附录D中定义的快捷方式限制选项。此选项的值应等于发送此触发器的数据流的跃点限制。这确保路由器能够限制快捷方式尝试，使其不超过数据流的范围。
Forward the NS packet to the router that would be the next hop for traffic sent towards the off-LL target.
将NS数据包转发到路由器，该路由器将是发送到离线目标的流量的下一跳。
Routers SHALL consider a unicast NS with shortcut limit option as a request for a host-triggered redirect. However, actual shortcut discovery is OPTIONAL for IPv6 routers.
路由器应考虑单播NS以快捷限制选项作为主机触发重定向的请求。但是，对于IPv6路由器，实际的快捷方式发现是可选的。
When shortcut discovery is not supported, the router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host.
当不支持快捷方式发现时，路由器应构造一条重定向消息，将路由器本身标识为最佳“快捷方式”，并将其返回给请求主机。
If shortcut discovery is to be supported, the router's response SHALL be:
如果要支持快捷方式发现，路由器的响应应为：
A suitable NHRP Request is constructed and sent as described in section 3.2.3. The original NS message SHOULD be discarded.
如第3.2.3节所述，构造并发送合适的NHRP请求。应丢弃原始NS消息。
Once the NHRP Reply is received by the originating router, the router SHALL construct a Redirect message containing the IPv6 address of the transient neighbor, and the NBMA link layer address returned by the NHRP resolution process.
一旦发起路由器收到NHRP回复，路由器应构建一条重定向消息，其中包含临时邻居的IPv6地址和NHRP解析过程返回的NBMA链路层地址。
The resulting Redirect message SHALL then be transmitted back to the source host. When the Redirect message is received, the source host SHALL update its Neighbor and Destination caches.
然后，产生的重定向消息应传输回源主机。当收到重定向消息时，源主机应更新其邻居和目标缓存。
The off-LL target is now considered a Transient Neighbor. The next packet sent to the Transient Neighbor will result in the creation of the direct, shortcut VC (to the off-LL target itself, or to the best egress router towards that neighbor as determined by NHRP).
脱离LL目标现在被视为瞬态邻居。发送到临时邻居的下一个数据包将导致创建直接的快捷方式VC（到离线目标本身，或到NHRP确定的朝向该邻居的最佳出口路由器）。
If a NHRP NAK or error indication is received for a host-triggered shortcut attempt, the requesting router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host.
如果收到主机触发的快捷方式尝试的NHRP NAK或错误指示，请求路由器应构造一条重定向消息，将路由器本身识别为最佳“快捷方式”，并将其返回给请求主机。
3.2.3 Use of NHRP between routers.
3.2.3 在路由器之间使用NHRP。
Once flow detection has occurred, or a host trigger has been detected, routers SHALL use NHRP in an NHS to NHS mode to establish the IPv6 to link level address mapping of a better first hop.
一旦发生流量检测，或检测到主机触发器，路由器应在NHS到NHS模式下使用NHRP，以建立更好的第一跳的IPv6到链路级地址映射。
IPv6/NBMA routers supporting shortcut discovery will need to perform some or all of the following functions:
支持快捷方式发现的IPv6/NBMA路由器需要执行以下部分或全部功能：
- Construct NHRP Requests and Replies.
- 构造NHRP请求和回复。
- Parse incoming NHRP Requests and Replies from other NHSes (routers).
- 解析来自其他NHSE（路由器）的传入NHRP请求和回复。
- Forward NHRP Requests towards an NHS that is topologically closer to the IPv6 target.
- 将NHRP请求转发到拓扑上更接近IPv6目标的NHS。
- Forward NHRP Replies towards an NHS that is topologically closer to the requester.
- 将NHRP回复转发给拓扑上更接近请求者的NHS。
- Perform syntax translation between Neighbor Solicitations and outbound NHRP Requests.
- 在邻居请求和出站NHRP请求之间执行语法转换。
- Perform syntax translation between inbound NHRP Replies and Redirects.
- 在入站NHRP回复和重定向之间执行语法转换。
The destination of the flow that caused the trigger (or the target of the host initiated trigger) is used as the target for resolution in a NHRP Request. The router then forwards this NHRP Request to the next closest NHS. The process continues (as it would for normal NHRP) until the Request reaches an NHS that believes the IP target is within link-local scope of one of its interfaces. (This may potentially occur within a single router.)
导致触发器的流的目标（或主机启动的触发器的目标）用作NHRP请求中的解析目标。路由器然后将该NHRP请求转发给下一个最近的NHS。该过程将继续（与普通NHRP一样），直到请求到达认为IP目标在其接口之一的链路本地范围内的NHS。（这可能发生在单个路由器内。）
As NHRP resolution requests always follow the routed path for a given target protocol address, the scope of a shortcut request will be automatically bounded to the scope of the IPv6 target address. (e.g. resolution requests for site-local addresses will not be forwarded across site boundaries.)
由于NHRP解析请求始终遵循给定目标协议地址的路由路径，因此快捷方式请求的范围将自动绑定到IPv6目标地址的范围。（例如，不会跨站点边界转发站点本地地址的解析请求。）
The last hop router SHALL resolve the NHRP Request from mapping information contained in its neighbor cache for the interface on which the specified target is reachable. If there is no appropriate entry in the Neighbor cache, or the destination is currently considered unreachable, the last hop router SHALL perform Neighbor Discovery on the local interface, and build the NHRP Reply from the resulting answer. (Note, in the case where the NHRP Request originated due to flow detection, there must already be a hop-by-hop
最后一跳路由器应根据其邻居缓存中包含的可到达指定目标的接口的映射信息来解析NHRP请求。如果邻居缓存中没有合适的条目，或者目标当前被认为无法到达，则最后一跳路由器应在本地接口上执行邻居发现，并根据结果应答构建NHRP应答。（注意，如果由于流检测而发起NHRP请求，则必须已经存在逐跳
flow of packets going through the last hop router towards the target. In this typical case the Neighbor cache will already have the desired information.)
通过最后一跳路由器到达目标的数据包流。在这种典型情况下，邻居缓存将已经具有所需的信息。）
The NHRP Reply is propagated back to the source of the NHRP Request, using a hop-by-hop path as it would for normal NHRP.
NHRP应答被传播回NHRP请求的源，使用一个逐跳路径，就像普通NHRP一样。
If the discovery process was triggered through flow detection at the originating router, the return of the NHRP Reply results in the following events:
如果发现过程是通过发起路由器上的流检测触发的，则NHRP回复的返回将导致以下事件：
A Redirect is constructed using the IPv6/NBMA mapping carried in the NHRP Reply.
使用NHRP回复中携带的IPv6/NBMA映射构造重定向。
The Redirect is unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it is a bi-directional pt-pt VC).
重定向是单播到IP数据包流的源（使用流到达路由器的VC，如果它是双向pt VC）。
Any Redirect message sent by a router MUST conform to all the rules described in [7] so that the packet is properly validated by the receiving host. Specifically, if the target of the resulting short-cut is the destination host then the ICMP Target Address MUST be the same as the ICMP Destination Address in the original message. If the target of the short-cut is an egress router then the ICMP Target Address MUST be a Link Local address of the egress router that is unique to the NBMA cloud to which the router's NBMA interface is attached.
路由器发送的任何重定向消息必须符合[7]中描述的所有规则，以便接收主机正确验证数据包。具体而言，如果生成的快捷方式的目标是目标主机，则ICMP目标地址必须与原始消息中的ICMP目标地址相同。如果捷径的目标是出口路由器，则ICMP目标地址必须是出口路由器的链路本地地址，该地址对于路由器的NBMA接口所连接的NBMA云是唯一的。
Also note that egress routers may subsequently redirect the source host. To do so, the Link Local ICMP Source Address of the Redirect message MUST be the same as the Link Local ICMP Target Address of the original Redirect message.
还要注意，出口路由器随后可能重定向源主机。为此，重定向消息的链路本地ICMP源地址必须与原始重定向消息的链路本地ICMP目标地址相同。
Note that the router constructing the NHRP Reply does so using the NBMA address returned by the target host when the target host first accepted the flow of IP traffic. This retains a useful feature of Neighbor Discovery - destination interface load sharing.
请注意，当目标主机第一次接受IP流量时，构建NHRP应答的路由器使用目标主机返回的NBMA地址执行此操作。这保留了邻居发现-目标接口负载共享的一个有用功能。
Upon receipt of a NHRP NAK reply or error indication for a flow-triggered shortcut attempt, no indication is sent to the source of the flow.
收到NHRP NAK回复或流触发快捷方式尝试的错误指示后，不会向流源发送指示。
3.2.3.1 NHRP/ND packet translation rules.
3.2.3.1 NHRP/ND数据包转换规则。
The following translation rules are meant to augment the packet format specification in section 5 of the NHRP specification [8], covering those packet fields specifically utilized by the IPv6/NBMA architecture.
以下翻译规则旨在扩充NHRP规范[8]第5节中的数据包格式规范，涵盖IPv6/NBMA体系结构专门使用的数据包字段。
NHRP messages are constructed and sent according to the rules in [8]. The value of the NBMA technology specific fields such as ar$afn, ar$pro.type, ar$pro.snap and link layer address format are defined in NBMA-specific companion documents. Source, destination or client protocol addresses in the common header or CIE of a NHRP message are always IPv6 addresses of length 16.
NHRP消息是根据[8]中的规则构造和发送的。NBMA技术特定字段的值，如ar$afn、ar$pro.type、ar$pro.snap和链路层地址格式，在NBMA特定配套文档中定义。NHRP消息的公共头或CIE中的源、目标或客户端协议地址始终是长度为16的IPv6地址。
When constructing an host-triggered NHRP resolution request in response to a Neighbor Solicitation:
构建主机触发的NHRP解析请求以响应邻居请求时：
The ar$hopcnt field MUST be smaller than the shortcut limit value specified in the shortcut limit option included in the triggering NS message. This ensures that hosts have control over the reach of their shortcut request. Note that the shortcut limit given in the option is relative to the requesting host, thus the requirement of ar$hopcnt being smaller than the given shortcut limit.
ar$hopcnt字段必须小于在触发NS消息中包含的快捷方式限制选项中指定的快捷方式限制值。这确保主机可以控制其快捷方式请求的范围。请注意，选项中给出的快捷方式限制是相对于请求主机的，因此ar$hopcnt的要求小于给定的快捷方式限制。
The Flags field in the common header of the NHRP resolution request SHOULD have the Q and S bits set.
NHRP解析请求的公共标头中的标志字段应设置Q和S位。
The U bit SHOULD be set. NBMA and protocol source addresses are those of the router constructing the request.
应设置U位。NBMA和协议源地址是构成请求的路由器的地址。
The target address from the NS message is used as the NHRP destination protocol address. A CIE SHALL NOT be specified.
NS消息中的目标地址用作NHRP目标协议地址。不应规定CIE。
When constructing a NHRP resolution request as a result of flow detection, the choice of values is configuration dependent.
作为流检测的结果构造NHRP分辨率请求时，值的选择取决于配置。
A NHRP resolution reply is build according to the rules in [8].
根据[8]中的规则构建NHRP解决方案回复。
For each CIE returned, the holding time is 10 minutes.
对于每个返回的CIE，保持时间为10分钟。
The MTU may be 0 or a value specified in the NBMA-specific companion document.
MTU可以是0或NBMA特定配套文件中规定的值。
A successful NHRP resolution reply for a host-triggered shortcut attempt is translated into an IPv6 Redirect message as follows:
针对主机触发的快捷方式尝试的成功NHRP解析答复将转换为IPv6重定向消息，如下所示：
IP Fields: Source Address The link-local address assigned to the router's interface from which this message is sent. Destination Address IPv6 Source Address of the triggering NS Hop Limit 255
IP字段：源地址分配给发送此消息的路由器接口的链路本地地址。目标地址IPv6触发NS跃点限制的源地址255
ICMP Fields: Target Address NHRP Client Protocol Address Destination Address Target of triggering NS (this is equivalent to the NHRP Destination Protocol Address) Target link-layer address NHRP Client NBMA Address
ICMP字段：目标地址NHRP客户端协议地址触发NS的目标地址目标地址（相当于NHRP目标协议地址）目标链路层地址NHRP客户端NBMA地址
All NHRP extensions currently defined in [8] have no effect on NHRP/ND translation and MAY be used in NHRP messages for IPv6.
[8]中当前定义的所有NHRP扩展对NHRP/ND转换没有影响，可以在IPv6的NHRP消息中使用。
3.2.3.2 NHRP Purge rules.
3.2.3.2 NHRP清除规则。
Purges are generated by NHRP when changes are detected that invalidate a previously issued NHRP Reply (this may include topology changes, or a target host going down or changing identity). Any IPv6 shortcut previously established on the basis of newly purged information SHOULD be torn down.
当检测到使先前发布的NHRP回复无效的更改时（这可能包括拓扑更改、目标主机停机或身份更改），NHRP将生成清除。应拆除以前根据新清除的信息建立的任何IPv6快捷方式。
Routers SHALL keep track of NHRP cache entries for which they have issued Neighbor Advertisements or Router Redirects. If a NHRP Purge is received that invalidates information previously issued to local host, the router SHALL issue a Router Redirect specifying the router itself as the new best next-hop for the affected IPv6 target.
路由器应跟踪其已发布邻居公告或路由器重定向的NHRP缓存条目。如果收到的NHRP清除使先前发送给本地主机的信息无效，路由器应发出路由器重定向，指定路由器本身为受影响IPv6目标的新最佳下一跳。
Routers SHALL keep track of Neighbor cache entries that have previously been used to generate an NHRP Reply. The expiry of any such Neighbor cache entry SHALL result in a NHRP Purge being sent towards the router that originally requested the NHRP Reply.
路由器应跟踪以前用于生成NHRP回复的邻居缓存条目。任何此类邻居缓存项的到期将导致向最初请求NHRP回复的路由器发送NHRP清除。
3.3. Neighbor Unreachability Detection.
3.3. 邻居不可达性检测。
Neighbor Solicitations sent for the purposes of Neighbor Unreachability Detection (NUD) are unicast to the Neighbor in question, using the VC that is already open to that Neighbor. This suggests that as far as NUD is concerned, the Transient Neighbor is indistinguishable from an On-LL Neighbor.
为了邻居不可达性检测（NUD）的目的而发送的邻居请求使用已经对该邻居开放的VC单播到有问题的邻居。这表明，就NUD而言，瞬态邻居与On LL邻居是无法区分的。
3.4. Duplicate Address Detection.
3.4. 重复地址检测。
Duplicate Address Detection is only required within the link-local scope, which in this case is the LL-local scope. Transient Neighbors are outside the scope of the LL. No particular interaction is required between the mechanism for establishing shortcuts and the mechanism for detection of duplicate link local addresses.
重复地址检测仅在链路本地范围内需要，在本例中，链路本地范围是LL本地范围。瞬态邻居不在LL的范围内。在建立快捷方式的机制和检测重复链接本地地址的机制之间不需要特定的交互。
4 Node Operation Concepts.
4节点操作概念。
This section describes node operations for performing basic functions (such as sending and receiving data) on a Logical Link. The application of these basic functions to the operation of the various IPv6 protocols such as Neighbor Discovery is described in Appendix A.
本节描述在逻辑链路上执行基本功能（如发送和接收数据）的节点操作。附录A中描述了这些基本功能在各种IPv6协议（如邻居发现）操作中的应用。
The majority of this section applies only to NBMA networks when used to provide point to point and point to multipoint SVCs. Section 7 discusses the case where the NBMA network is being used to supply only point to point PVCs.
本节的大部分内容仅适用于用于提供点对点和点对多点SVC的NBMA网络。第7节讨论了NBMA网络仅用于提供点对点PVC的情况。
4.1.Connecting to a Logical Link.
4.1.连接到逻辑链路。
Before a node can send or receive IPv6 datagrams its underlying IPv6/NBMA interface(s) must first join a Logical Link.
在节点可以发送或接收IPv6数据报之前，其底层IPv6/NBMA接口必须首先加入逻辑链路。
An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated with its Logical Link, and register as a Cluster Member [5]. The node's IPv6/NBMA interface will then be a member of the LL, have a Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and IPv6 ND operations.
IPv6/NBMA驱动程序应建立到与其逻辑链路相关联的MARS的pt VC，并注册为集群成员[5]。然后，节点的IPv6/NBMA接口将成为LL的成员，分配集群成员ID（CMI），并可以开始支持IPv6和IPv6 ND操作。
If the node is a host or router starting up it SHALL issue a single group MARS_JOIN for the following groups:
如果节点是正在启动的主机或路由器，则应为以下组发出单个组MARS_JOIN：
- Its derived Solicited-node address(es) with link-local scope. - The All-nodes address with link-local scope. - Other configured multicast groups with at least link-local scope.
- 其具有链接本地作用域的派生请求节点地址。-具有链接本地作用域的所有节点地址。-至少具有链路本地作用域的其他配置的多播组。
If the node is a router it SHALL additionally issue:
如果节点是路由器，则应另外发布：
- A single group MARS_JOIN for the All-routers address with link-local scope. - A block MARS_JOIN for the range(s) of IPv6 multicast addresses (with greater than link-local scope) for which promiscuous reception is required.
- 具有链接本地作用域的所有路由器地址的单个组MARS_连接。-一个用于IPv6多播地址范围（大于链路本地范围）的块MARS_JOIN，需要对其进行混杂接收。
The encapsulation mechanism for, and key field values of, MARS control messages SHALL be defined in companion documents specific to particular NBMA network technologies.
火星控制信息的封装机制和关键字段值应在特定NBMA网络技术的配套文件中定义。
4.2 Joining a Multicast Group.
4.2 加入多播组。
This section describes the node's behavior when it gets a JoinLocalGroup request from the IPv6 Layer. The details of how this behavior is achieved are going to be implementation specific.
本节描述节点从IPv6层获取JoinLocalGroup请求时的行为。如何实现这种行为的细节将是具体实现的。
If a JoinLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver.)
如果接收到节点本地地址的JoinLocalGroup，IPv6/NBMA驱动程序将向调用者返回成功指示，并且不采取其他操作。（发送到节点本地地址的数据包永远不会到达IPv6/NBMA驱动程序。）
If a JoinLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_JOIN request to register this address with the MARS.
如果为大于节点本地作用域的地址接收到JoinLocalGroup，IPv6/NBMA驱动程序应发送适当的单组MARS_JOIN请求，以向MARS注册此地址。
4.3. Leaving a Multicast Group.
4.3. 离开多播组。
This section describes the node's behavior when it gets a LeaveLocalGroup request from the IPv6 Layer. The details of how this behavior is achieved are going to be implementation specific.
本节描述节点从IPv6层获取LeaveLocalGroup请求时的行为。如何实现这种行为的细节将是具体实现的。
If a LeaveLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver.)
如果接收到节点本地地址的LeaveLocalGroup，IPv6/NBMA驱动程序将向调用者返回成功指示，并且不采取其他操作。（发送到节点本地地址的数据包永远不会到达IPv6/NBMA驱动程序。）
If a LeaveLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_LEAVE request to deregister this address with the MARS.
如果为大于节点本地作用域的地址接收到LeaveLocalGroup，IPv6/NBMA驱动程序应发送适当的单组MARS_LEAVE请求，以在MARS中注销该地址。
4.4. Sending Data.
4.4. 发送数据。
Separate processing and encapsulation rules apply for outbound unicast and multicast packets.
单独的处理和封装规则适用于出站单播和多播数据包。
4.4.1. Sending Unicast Data.
4.4.1. 发送单播数据。
The IP level 'next hop' for each outbound unicast IPv6 packet is used to identify a pt-pt VC on which to forward the packet.
每个出站单播IPv6数据包的IP级别“下一跳”用于标识转发数据包的pt VC。
For NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the following LLC/SNAP header and sent over the VC.
对于通常使用LLC/SNAP封装的NBMA网络（如ATM或SMD），IPv6数据包应使用以下LLC/SNAP报头进行封装，并通过VC发送。
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] (LLC) (OUI) (PID)
[0xAA-AA-03][0x00-00-00][0x86 DD][IPv6数据包]（LLC）（OUI）（PID）
For NBMA networks that do not use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document.
对于不使用LLC/SNAP封装的NBMA网络，应在NBMA特定配套文件中规定替代规则。
If no pt-pt VC exists for the next hop address for the packet, the node SHALL place a call to set up a VC to the next hop destination. Any time the IPv6/NBMA driver receives a unicast packet for transmission the IPv6 layer will already have determined the link-layer (NBMA) address of the next hop. Thus, the information needed to place the NBMA call to the next hop will be available.
如果数据包的下一跳地址不存在pt VC，则节点应发出呼叫，以建立到下一跳目的地的VC。每当IPv6/NBMA驱动程序接收到用于传输的单播数据包时，IPv6层将已经确定下一跳的链路层（NBMA）地址。因此，将NBMA呼叫置于下一跳所需的信息将可用。
The sending node SHOULD queue the packet that triggered the call request, and send it when the call is established.
发送节点应将触发呼叫请求的数据包排队，并在呼叫建立时发送。
If the call to the next hop destination node fails the sending node SHALL discard the packet that triggered the call setup. Persistent failure to create a VC to the next hop destination will be detected and handled at the IPv6 Network Layer through NUD.
如果对下一跳目的地节点的呼叫失败，发送节点应丢弃触发呼叫设置的数据包。将在IPv6网络层通过NUD检测并处理创建到下一跳目的地的VC的持续失败。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
此时，没有指定将出站数据包映射到VCs的规则，只使用数据包的目标地址。
4.4.2. Sending Multicast Data.
4.4.2. 发送多播数据。
The IP level 'next hop' for each outbound multicast IPv6 packet is used to identify a pt-pt or pt-mpt VC on which to forward the packet.
每个出站多播IPv6数据包的IP级别“下一跳”用于标识转发数据包的pt或pt mpt VC。
For NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the following manner:
对于通常使用LLC/SNAP封装的NBMA网络（如ATM或SMD），应以以下方式封装多播数据包：
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] (LLC) (OUI) (PID) (mars encaps)
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6数据包]（LLC）（OUI）（PID）（火星包裹）
The IPv6/NBMA driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field prior to transmission.
在传输之前，应将IPv6/NBMA驱动程序的群集成员ID复制到2个八位字节的pkt$cmi字段中。
For NBMA networks that do not use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document. Some mechanism for carrying the IPv6/NBMA driver's Cluster Member ID SHALL be provided.
对于不使用LLC/SNAP封装的NBMA网络，应在NBMA特定配套文件中规定替代规则。应提供一些用于承载IPv6/NBMA驱动程序集群成员ID的机制。
If the packet's destination is one of the following multicast addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt VC to the MARS:
如果数据包的目的地是以下多播地址之一，则应通过IPv6/NBMA驱动程序的直接pt VC发送到MARS：
- A Solicited-node address with link-local scope. - The All-nodes address with link-local scope. - The All-routers address with link-local scope. - A DHCP-v6 relay or server multicast address.
- 具有链接本地作用域的请求节点地址。-具有链接本地作用域的所有节点地址。-具有链接本地作用域的所有路由器地址。-DHCP-v6中继或服务器多播地址。
The MARS SHALL then redistribute the IPv6 packet as described in section 3.1.1. (If the VC to the MARS has been idle timed out for some reason, it MUST be re-established before forwarding the packet to the MARS.)
然后，MARS应按照第3.1.1节所述重新分发IPv6数据包。（如果到MARS的VC由于某种原因已空闲超时，则必须在将数据包转发到MARS之前重新建立该VC。）
If packet's destination is any other address, then the usual MARS client mechanisms are used by the IPv6/NBMA driver to select and/or establish a pt-mpt VC on which the packet is to be sent.
如果数据包的目的地是任何其他地址，则IPv6/NBMA驱动程序使用通常的MARS客户端机制来选择和/或建立发送数据包的pt mpt VC。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
此时，没有指定将出站数据包映射到VCs的规则，只使用数据包的目标地址。
4.5. Receiving Data.
4.5. 接收数据。
Packets received using the encapsulation shown in section 4.4.1 SHALL be de-encapsulated and passed up to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled.
使用第4.4.1节中所示的封装接收的数据包应被解除封装并传递到IPv6层。然后，IPv6层确定如何处理传入的数据包。
Packets received using the encapsulation specified in section 4.4.2 SHALL have their pkt$cmi field compared to the local IPv6/NBMA driver's own CMI. If the pkt$cmi in the header matches the local CMI the packet SHALL be silently dropped. Otherwise, the packet SHALL be de-encapsulated and passed to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled.
与本地IPv6/NBMA驱动程序自己的cmi相比，使用第4.4.2节规定的封装接收的数据包应具有其pkt$cmi字段。如果报头中的pkt$cmi与本地cmi匹配，则数据包将被静默丢弃。否则，数据包应被解除封装并传递到IPv6层。然后，IPv6层确定如何处理传入的数据包。
For NBMA networks that do not use LLC/SNAP encapsulation, alternative rules SHALL be specified in the NBMA-specific companion document.
对于不使用LLC/SNAP封装的NBMA网络，应在NBMA特定配套文件中规定替代规则。
The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6 packets arriving with encapsulation defined for unicast packets, nor attempt to filter out unicast IPv6 packets arriving with encapsulation defined for multicast packets.
IPv6/NBMA驱动程序不得尝试过滤掉使用为单播数据包定义的封装到达的多播IPv6数据包，也不得尝试过滤掉使用为多播数据包定义的封装到达的单播IPv6数据包。
4.6. VC Setup and release for unicast data.
4.6. VC设置和发布单播数据。
Unicast VCs are maintained separately from multicast VCs. The setup and maintenance of multicast VCs are handled by the MARS client in each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt VCs for unicast IPv6 traffic will be described here. Only best effort unicast VCs are considered. The creation of VCs for other classes of service is outside the scope of this document.
单播VCs与多播VCs分开维护。多播VCs的设置和维护由每个IPv6/NBMA驱动程序中的MARS客户端处理[5]。此处仅描述单播IPv6流量的pt VCs的设置和维护。只考虑尽力而为的单播VCs。为其他服务类别创建VCs不在本文档范围内。
Before sending a packet to a new destination within the same LL a node will first perform a Neighbor Discovery on the intra-LL target. This is done to resolve the IPv6 destination address into a link-layer address which the sender can then use to send unicast packets.
在将数据包发送到同一LL内的新目的地之前，节点将首先在LL内目标上执行邻居发现。这样做是为了将IPv6目标地址解析为链路层地址，然后发送方可以使用该地址发送单播数据包。
Appendix A.1.1 contains non-normative, descriptive text covering the Neighbor Solicitation/Advertisement exchange and eventual establishment of a new SVC.
附录A.1.1包含非规范性、描述性文本，涵盖邻居征集/广告交换以及新SVC的最终建立。
A Redirect message (either a redirect to a node on the same LL, or a shortcut redirect to a node outside the LL) results in the sending (redirected) node creating a new pt-pt VC to a new receiving node. the Redirect message SHALL contain the link layer (NBMA) address of the new receiving IPv6/NBMA interface. The redirected node does not concern itself where the new receiving node is located on the NBMA network. The redirected node will set up a pt-pt VC to the new node if one does not previously exist. The redirected node will then use the new VC to send data rather than whatever VC it had previously been using.
重定向消息（重定向到同一LL上的节点，或重定向到LL外的节点的快捷方式）导致发送（重定向）节点创建新的pt VC到新的接收节点。重定向消息应包含新接收IPv6/NBMA接口的链路层（NBMA）地址。重定向节点不关心新接收节点位于NBMA网络上的位置。如果以前不存在pt VC，则重定向节点将为新节点设置pt VC。重定向节点随后将使用新的VC发送数据，而不是以前使用的任何VC。
Redirects are unidirectional. Even after the source has reacted to a redirect, the destination will continue to send IPv6 packets back to the redirected node on the old path. This happens because the destination node has no way of determining the IPv6 address of the other end of a new VC in the absence of Neighbor Discovery. Thus, redirects will not result in both ends of a connection using the new VC. IPv6 redirects are not intended to provide symmetrical redirection. If the non-redirected node eventually receives a redirect it MAY discover the existing VC to the target node and use that rather than creating a new VC.
重定向是单向的。即使在源对重定向做出反应后，目标仍将继续将IPv6数据包发送回旧路径上的重定向节点。这是因为在没有邻居发现的情况下，目标节点无法确定新VC另一端的IPv6地址。因此，重定向不会导致使用新VC连接的两端。IPv6重定向不是为了提供对称重定向。如果未重定向的节点最终收到重定向，它可能会发现目标节点的现有VC，并使用该VC，而不是创建新的VC。
It is desirable that VCs are released when no longer needed.
当不再需要时，最好释放VCs。
An IPv6/NBMA driver SHALL release any VC that has been idle for 20 minutes.
IPv6/NBMA驱动程序应释放空闲20分钟的任何VC。
This time limit MAY be reduced through configuration or as specified in companion documents for specific NBMA networks.
该时限可通过配置或特定NBMA网络的配套文件中规定的方式缩短。
If a Neighbor or Destination cache entry is purged then any VCs associated with the purged entry SHOULD be released.
如果清除了相邻缓存项或目标缓存项，则应释放与已清除项关联的所有VCs。
If the state of an entry in the Neighbor cache is set to STALE, then any VCs associated with the stale entry SHOULD be released.
如果邻居缓存中某个条目的状态设置为STALE，则应释放与该STALE条目关联的所有VCs。
4.7 NBMA SVC Signaling Support and MTU issues.
4.7 NBMA SVC信令支持和MTU问题。
Mechanisms for signaling the establishment and teardown of pt-pt and pt-mpt SVCs for different NBMA networks SHALL be specified in companion documents.
配套文件中应规定为不同NBMA网络建立和拆除pt和pt-mpt SVC的信号机制。
Since any given IPv6/NBMA driver will not know if the remote end of a VC is in the same LL, drivers SHALL implement NBMA-specific mechanisms to negotiate acceptable MTUs at the VC level. These mechanisms SHALL be specified in companion documents.
由于任何给定的IPv6/NBMA驱动程序都不知道VC的远程端是否在同一个LL中，因此驱动程序应实现NBMA特定的机制，以便在VC级别协商可接受的MTU。这些机制应在配套文件中规定。
However, IPv6/NBMA drivers can assume that they will always be talking to another driver attached to the same type of NBMA network. (For example, an IPv6/NBMA driver does not need to consider the possibility of establishing a shortcut VC directly to an IPv6/FR driver.)
但是，IPv6/NBMA驱动程序可以假定它们将始终与连接到同一类型NBMA网络的另一个驱动程序通信。（例如，IPV6/NBMA驱动程序不需要考虑直接向IPv6/FR驱动程序建立快捷VC的可能性。）
Each IPv6 interface must have an interface token from which to form IPv6 autoconfigured addresses. This interface token must be unique within a Logical Link to prevent the creation of duplicate addresses when stateless address configuration is used.
每个IPv6接口必须有一个接口令牌，从中可以形成IPv6自动配置地址。此接口令牌在逻辑链路中必须是唯一的，以防止在使用无状态地址配置时创建重复地址。
In cases where two nodes on the same LL produce the same interface token then one interface MUST choose another host-token. All implementations MUST support manual configuration of interface tokens to allow operators to manually change a interface token on a per-LL basis. Operators may choose to manually set interface tokens for reasons other than eliminating duplicate addresses.
如果同一个LL上的两个节点产生相同的接口令牌，则一个接口必须选择另一个主机令牌。所有实现都必须支持接口令牌的手动配置，以允许操作员在每个LL的基础上手动更改接口令牌。除了消除重复地址外，操作员还可以选择手动设置接口令牌。
All interface tokens MUST be 64 bits in length and formatted as described in the following sections. The hosts tokens will be based on the format of an EUI-64 identifier [10]. Refer to [19 - Appendix A] for a description of creating IPv6 EUI-64 based interface identifiers.
所有接口令牌的长度必须为64位，并按照以下章节中的说明进行格式化。主机令牌将基于EUI-64标识符的格式[10]。有关创建基于IPv6 EUI-64的接口标识符的说明，请参阅[19-附录A]。
Physical NBMA interfaces will generally have some local identifier that may be used to generate a unique IPv6/NBMA interface token. The exact mechanism for generating interface tokens SHALL be specified in companion documents specific to each NBMA network.
物理NBMA接口通常具有一些本地标识符，可用于生成唯一的IPv6/NBMA接口令牌。生成接口令牌的确切机制应在每个NBMA网络的配套文件中规定。
Physical NBMA interfaces MAY be used to provide multiple logical NBMA interfaces. Since each logical NBMA interface MAY support an independent IPv6 interface, two separate scenarios are possible:
物理NBMA接口可用于提供多个逻辑NBMA接口。由于每个逻辑NBMA接口可能支持一个独立的IPv6接口，因此可能存在两种不同的情况：
- A single host with separate IPv6/NBMA interfaces onto a number of independent Logical Links.
- 具有独立IPv6/NBMA接口的单个主机连接到多个独立的逻辑链路上。
- A set of 2 or more 'virtual hosts' (vhosts) sharing a common NBMA driver. Each vhost is free to establish IPv6/NBMA interfaces associated with different or common LLs. However, vhosts are bound by the same requirement as normal hosts - no two interfaces to the same LL can share the same interface token.
- 共享一个公共NBMA驱动程序的两个或多个“虚拟主机”（vhost）的集合。每个vhost都可以自由地建立与不同或公共LLs关联的IPv6/NBMA接口。但是，vhost与普通主机受相同要求的约束-同一LL的两个接口不能共享相同的接口令牌。
In the first scenario, since each IPv6/NBMA interface is associated with a different LL, each interface's external identity can be differentiated by the LL's routing prefix. Thus, the host can re-use a single unique interface token across all its IPv6/NBMA interfaces. (Internally the host will tag received packets in some locally specific manner to identify what IPv6/NBMA interface they arrived on. However, this is an issue generic to IPv6, and does not required clarification in this document.)
在第一个场景中，由于每个IPv6/NBMA接口都与不同的LL相关联，因此每个接口的外部标识可以通过LL的路由前缀来区分。因此，主机可以在其所有IPv6/NBMA接口上重复使用单个唯一接口令牌。（在内部，主机将以某种特定于本地的方式标记接收到的数据包，以识别它们到达的IPv6/NBMA接口。但是，这是IPv6的一个通用问题，不需要在本文档中进行说明。）
The second scenario is more complex, but likely to be rarer.
第二种情况更为复杂，但可能更为罕见。
When supporting multiple logical NBMA interfaces over a single physical NBMA interface, independent and unique identifiers SHALL be generated for each virtual NBMA interface to enable the construction of unique IPv6/NBMA interface tokens. The exact mechanism for generating interface tokens SHALL be specified in companion documents specific to each NBMA network.
当通过单个物理NBMA接口支持多个逻辑NBMA接口时，应为每个虚拟NBMA接口生成独立且唯一的标识符，以便能够构建唯一的IPv6/NBMA接口令牌。生成接口令牌的确切机制应在每个NBMA网络的配套文件中规定。
Neighbor Discovery defines two option fields for carrying link-layer specific source and target addresses.
邻居发现定义了两个选项字段，用于承载特定于链路层的源地址和目标地址。
Between IPv6/NBMA interfaces, the format for these two options is adapted from the MARS [5] and NHRP [8] specs. It SHALL be:
在IPv6/NBMA接口之间，这两个选项的格式改编自MARS[5]和NHRP[8]规范。应为：
[Type][Length][NTL][STL][..NBMA Number..][..NBMA Subaddress..] | Fixed || Link layer address |
[类型][长度][NTL][STL][…NBMA编号..][…NBMA子地址..]|固定| |链路层地址|
[Type] is a one octet field.
[Type]是一个八位字节字段。
1 for Source link-layer address. 2 for Target link-layer address.
1表示源链路层地址。2表示目标链路层地址。
[Length] is a one octet field.
[Length]是一个八位字节字段。
The total length of the option in multiples of 8 octets. Zeroed bytes are added to the end of the option to ensure its length is a multiple of 8 octets.
选项的总长度，以8个八位字节的倍数表示。将零字节添加到选项的末尾，以确保其长度为8个八位字节的倍数。
[NTL] is a one octet 'Number Type & Length' field.
[NTL]是一个八位字节的“数字类型和长度”字段。
[STL] is a one octet 'SubAddress Type & Length' field.
[STL]是一个八位字节的“子地址类型和长度”字段。
[NBMA Number] is a variable length field. It is always present. This contains the primary NBMA address.
[NBMA编号]是一个可变长度字段。它总是存在的。它包含主NBMA地址。
[NBMA Subaddress] is a variable length field. It may or may not be present. This contains any NBMA subaddress that may be required.
[NBMA子地址]是一个可变长度字段。它可能存在，也可能不存在。这包含可能需要的任何NBMA子地址。
If the [NBMA Subaddress] is not present, the option ends after the [NBMA Number] ( and any additional padding for 8 byte alignment).
如果[NBMA子地址]不存在，则该选项在[NBMA编号]（以及8字节对齐的任何附加填充）之后结束。
The contents and interpretation of the [NTL], [STL], [NBMA Number], and [NBMA Subaddress] fields are specific to each NBMA network, and SHALL be specified in companion documents.
[NTL]、[STL]、[NBMA编号]和[NBMA子地址]字段的内容和解释特定于每个NBMA网络，并应在配套文件中规定。
The IPv6 link-local address is formed by appending the interface token, as defined above, to the prefix FE80::/64.
IPv6链路本地地址是通过将接口令牌（如上所述）附加到前缀FE80:：/64来形成的。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token |
+----------+-----------------------+----------------------------+
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that provide details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths (when dynamically signaled NBMA links are available).
本文档描述了NBMA网络上IPv6的通用体系结构。它构成了提供各种特定NBMA技术（如ATM或帧中继）详细信息的附属配套文件的基础。IPv6 over NBMA体系结构允许IPv6邻居发现协议的常规主机端操作，同时还支持建立“快捷”NBMA转发路径（当动态信号NBMA链路可用时）。
The IPv6 "Link" is generalized to "Logical Link" in an analagous manner to the IPv4 "Logical IP Subnet". The MARS protocol is augmented and used to provide relatively efficient intra Logical Link multicasting of IPv6 packets, and distribution of Discovery messages. Shortcut NBMA level paths are supported either through router based flow detection, or host originated explicit requests. Neighbor Discovery is used without modification for all intra-LL control (including the initiation of NBMA shortcut discovery). Router to router NHRP is used to obtain the IPv6/NBMA address mappings for shortcut targets outside a source's Logical Link.
IPv6“链路”以一种与IPv4“逻辑IP子网”类似的方式被概括为“逻辑链路”。MARS协议被扩充并用于提供IPv6数据包的相对高效的逻辑链路内多播，以及发现消息的分发。通过基于路由器的流检测或主机发起的显式请求，支持NBMA级快捷路径。邻居发现用于所有内部LL控制（包括启动NBMA快捷方式发现），无需修改。路由器到路由器NHRP用于获取源逻辑链路外部快捷目标的IPv6/NBMA地址映射。
This architecture introduces no new protocols, but depends on existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject to all the security threats inherent in these protocols. This architecture should not be used in a domain where any of the base protocols are considered unacceptably insecure. However, this protocol itself does not introduce additional security threats.
该体系结构不引入新协议，但依赖于现有协议（NHRP、IPv6、ND、MARS），因此会受到这些协议固有的所有安全威胁。此体系结构不应用于任何基本协议被认为不安全的领域。但是，该协议本身不会带来额外的安全威胁。
While this proposal does not introduce any new security mechanisms all current IPv6 security mechanisms will work without modification for NBMA. This includes both authentication and encryption for both Neighbor Discovery protocols as well as the exchange of IPv6 data packets. The MARS protocol is modified in a manner that does not affect or augment the security offered by RFC 2022.
虽然该提案没有引入任何新的安全机制，但所有当前的IPv6安全机制都将在不修改NBMA的情况下工作。这包括邻居发现协议的身份验证和加密以及IPv6数据包的交换。MARS协议的修改方式不会影响或增强RFC 2022提供的安全性。
Acknowledgments
致谢
Eric Nordmark confirmed the usefulness of ND Redirect messages in private email during the March 1996 IETF. The discussions with various ION WG members during the June and December 1996 IETF helped solidify the architecture described here. Grenville Armitage's original work on IPv6/NBMA occurred while employed at Bellcore. Elements of section 5 were borrowed from Matt Crawford's memo on IPv6 over Ethernet.
埃里克·诺德马克（Eric Nordmark）在1996年3月的IETF会议上确认了私人电子邮件中ND重定向消息的有用性。在1996年6月和12月IETF期间，与各ION工作组成员的讨论有助于巩固此处描述的体系结构。格伦维尔·阿米蒂奇（Grenville Armitage）最初关于IPv6/NBMA的工作是在受雇于Bellcore时完成的。第5节的内容借鉴了马特·克劳福德关于以太网IPv6的备忘录。
Authors' Addresses
作者地址
Grenville Armitage Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA
格雷维尔·阿米蒂奇·贝尔实验室，朗讯科技公司，美国新泽西州霍尔德尔克劳福德角路101号，邮编：07733
EMail: gja@lucent.com
EMail: gja@lucent.com
Peter Schulter Bright Tiger Technologies 125 Nagog Park Acton, MA 01720
Peter Schulter Bright Tiger Technologies马萨诸塞州纳戈尔公园阿克顿125号01720
EMail: paschulter@acm.org
EMail: paschulter@acm.org
Markus Jork European Applied Research Center Digital Equipment GmbH CEC Karlsruhe Vincenz-Priessnitz-Str. 1 D-76131 Karlsruhe Germany
Markus Jork欧洲应用研究中心数字设备有限公司CEC Karlsruhe Vincenz-Priessnitz-Str.1 D-76131 Karlsruhe Germany
EMail: jork@kar.dec.com
EMail: jork@kar.dec.com
Geraldine Harter Digital UNIX Networking Compaq Computer Corporation 110 Spit Brook Road Nashua, NH 03062
Geraldine Harter数字UNIX网络康柏计算机公司新罕布什尔州纳舒亚Spit Brook路110号，邮编03062
EMail: harter@zk3.dec.com
EMail: harter@zk3.dec.com
References
工具书类
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[2] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995.
[2] ATM论坛，“ATM用户网络接口（UNI）规范3.1版”，ISBN 0-13-393828-X，新泽西州恩格尔伍德悬崖普伦蒂斯大厅，1995年6月。
[3] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.
[3] Crawford，M.“通过以太网传输IPv6数据包的方法”，RFC 1972，1996年8月。
[4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[4] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.
[5] Armitage，G.“支持基于UNI 3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[6] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[8] Luciani，J.，Katz，D.，Piscitello，D.Cole B和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[9] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[10] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[10] “64位全局标识符格式教程”，http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router Architecture Extensions for ATM : Overview", RFC 2098, February 1997.
[11] Katsube，Y.，Nagami，K.和H.Esaki，“东芝的ATM路由器架构扩展：概述”，RFC 2098，1997年2月。
[12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under IP", Proceedings of INFOCOM'96, San Francisco, March 1996, pp.1251-1260
[12] P. Newman，T.Lyon，G.MiNeWS，“流标记IP:IP下的ATM”，信息通信网96号，旧金山，1996年3月，pp.1251-1260的程序
[13] Piscitello, D. and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991.
[13] Piscitello，D.和J.Lawrence，“通过SMDS服务传输IP数据报”，RFC 1209，1991年3月。
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[14] Plummer，D.，“以太网地址解析协议-或-将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[15] McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[17] Armitage，G.，Schulter，P.和M.Jork，“ATM网络上的IPv6”，RFC 2492，1999年1月。
[18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.
[18] C.Perkins，J.Bound，“IPv6的动态主机配置协议（DHCPv6）”，正在进行中。
[19] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[19] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
The IPv6 over NBMA model described in this document maintains the complete semantics of the IPv6 protocols. No changes need to be made to the IPv6 Network Layer. Since the concept of the security association is not being changed for NBMA, this framework maintains complete IPv6 security semantics and features. This allows IPv6 nodes to choose their responses to solicitations based on security information as is done with other datalinks, thereby maintaining the semantics of Neighbor Discovery since it is always the solicited node that chooses what (and even if) to reply to the solicitation. Thus, NBMA will be transparent to the network layer except in cases where extra services (such as QoS VCs) are offered.
本文档中描述的IPv6 over NBMA模型维护了IPv6协议的完整语义。无需对IPv6网络层进行任何更改。由于NBMA没有改变安全关联的概念，因此该框架维护了完整的IPv6安全语义和功能。这允许IPv6节点根据安全信息选择其对请求的响应，就像对其他数据链路所做的那样，从而维护邻居发现的语义，因为总是被请求节点选择响应请求的内容（即使是这样）。因此，除了提供额外服务（如QoS VCs）的情况外，NBMA对网络层是透明的。
The remainder of this Appendix describes how the core IPv6 protocols will operate within the model described here.
本附录的其余部分描述了核心IPv6协议将如何在此处描述的模型内运行。
Before performing any sort of Neighbor discover operation, each node must first join the all-node multicast group, and it's solicited node multicast address (the use of this address in relation to DAD is described in A.1.4). The IPv6 network layer will join these multicast groups as described in 4.2.
在执行任何种类的邻居发现操作之前，每个节点必须首先加入全节点多播组，并加入其请求的节点多播地址（与DAD相关的该地址的使用在A.1.4中描述）。IPv6网络层将加入这些多播组，如4.2所述。
An IPv6 host performs address resolution by sending a Neighbor Solicitation to the solicited-node multicast address of the target host, as described in [7]. The Neighbor Solicitation message will contain a Source Link-Layer Address Option set to the soliciting node's NBMA address on the LL.
IPv6主机通过向目标主机的请求节点多播地址发送邻居请求来执行地址解析，如[7]所述。邻居请求消息将包含一个源链路层地址选项，该选项设置为LL上请求节点的NBMA地址。
When the local node's IPv6/NBMA driver is passed the Neighbor Solicitation message from the IPv6 network layer, it follows the steps described in section 4.4.2 Sending Multicast Data.
当本地节点的IPv6/NBMA驱动程序从IPv6网络层传递邻居请求消息时，它将遵循第4.4.2节发送多播数据中描述的步骤。
One or more nodes will receive the Neighbor Solicitation message. The nodes will process the data as described in section 4.5 and pass the de-encapsulated packets to the IPv6 network layer.
一个或多个节点将接收邻居请求消息。节点将按照第4.5节所述处理数据，并将解除封装的数据包传递给IPv6网络层。
If the receiving node is the target of the Neighbor Solicitation it will update its Neighbor cache with the soliciting node's NBMA address, contained in the Neighbor Solicitation message's Source Link-Layer Address Option as described in [7].
如果接收节点是邻居请求的目标，它将使用请求节点的NBMA地址更新其邻居缓存，该地址包含在邻居请求消息的源链路层地址选项中，如[7]所述。
The solicited IPv6 host will respond to the Neighbor Solicitation with a Neighbor Advertisement message sent to the IPv6 unicast address of the soliciting node. The Neighbor Advertisement message will contain a Target Link-Layer Address Option set to the solicited node's NBMA address on the LL.
请求的IPv6主机将使用发送到请求节点的IPv6单播地址的邻居播发消息来响应邻居请求。邻居播发消息将包含目标链路层地址选项，该选项设置为LL上请求节点的NBMA地址。
The solicited node's IPv6/NBMA driver will be passed the Neighbor Advertisement and the soliciting node's link-layer address from the IPv6 network layer. It will then follow the steps described in section section 4.4.1 to send the NA message to the soliciting node. This will create a pt-pt VC between the solicited node and soliciting node if one did not already exist.
请求节点的IPv6/NBMA驱动程序将从IPv6网络层传递邻居播发和请求节点的链路层地址。然后，它将按照第4.4.1节中描述的步骤向请求节点发送NA消息。这将在请求节点和请求节点之间创建pt VC（如果尚未存在）。
The soliciting node will then receive the Neighbor Advertisement message over the new PtP VC, de-encapsulate the message, and pass it to the IPv6 Network layer for processing as described in section 4.5. The soliciting node will then make the appropriate entries in it's Neighbor cache, including caching the NBMA link-layer address of the solicited node as described in [7].
请求节点随后将通过新的PtP VC接收邻居广告消息，对消息进行反封装，并将其传递到IPv6网络层进行处理，如第4.5节所述。请求节点随后将在其邻居缓存中创建适当的条目，包括缓存请求节点的NBMA链路层地址，如[7]所述。
At this point each system has a complete Neighbor cache entry for the other system. They can exchange data over the pt-pt VC newly created by the solicited node when it returned the Neighbor Advertisement, or create a new VC.
此时，每个系统都有另一个系统的完整邻居缓存项。当请求节点返回邻居播发时，它们可以通过请求节点新创建的pt VC交换数据，或者创建新的VC。
An IPv6 host can also send an Unsolicited Neighbor Advertisemnent to the all-nodes multicast address. When the local node IPv6/NBMA driver is passed the Neighbor Advertisement from the IPv6 network layer, it follows the steps described in section 4.4.2 to send the NA message to the all-nodes multicast address. Each node will process the incoming packet as described in section 4.5 and then pass the packet to the IPv6 network layer where it will be processed as described in [7].
IPv6主机还可以向所有节点多播地址发送未经请求的邻居广告。当本地节点IPv6/NBMA驱动程序从IPv6网络层传递邻居播发时，它将按照第4.4.2节中描述的步骤向所有节点多播地址发送NA消息。每个节点将按照第4.5节所述处理传入数据包，然后将数据包传递到IPv6网络层，在该层将按照[7]所述进行处理。
Router Discovery is described in [7]. To support Router Discovery an IPv6 router will join the IPv6 all-routers multicast group address. When the IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 Network Layer, it follows the process described in section 4.2.
[7]中描述了路由器发现。为了支持路由器发现，IPv6路由器将加入IPv6所有路由器多播组地址。当IPv6/NBMA驱动程序从IPv6网络层获取JoinLocalGroup请求时，它将遵循第4.2节中描述的过程。
IPv6 routers periodically send unsolicited Router Advertisements announcing their availability on the LL. When an IPv6 router sends an unsolicited Router Advertisement, it sends a data packet addressed to the IPv6 all-nodes multicast address. When the local node IPv6/NBMA driver gets the Router Advertisement message from the IPv6 network layer, it transmits the message by following steps described in section 4.4.2. The MARS will transmit the packet on the LL's
IPv6路由器定期发送未经请求的路由器广告，宣布其在LL上的可用性。当IPv6路由器发送未经请求的路由器播发时，它会发送一个数据包，地址为IPv6所有节点多播地址。当本地节点IPv6/NBMA驱动程序从IPv6网络层获取路由器广告消息时，它将按照第4.4.2节中描述的步骤发送该消息。火星将在LL上传送数据包
ClusterControlVC, which sends the packets to all nodes on the LL. Each node on the LL will then process the incoming packet as described in section 4.5 and pass the received packet to the IPv6 Network layer for processing as appropriate.
ClusterControlVC，它将数据包发送到LL上的所有节点。然后，LL上的每个节点将按照第4.5节中的描述处理传入的数据包，并将接收到的数据包传递给IPv6网络层进行适当的处理。
To perform Router Discovery, an IPv6 host sends a Router Solicitation message to the all-routers multicast address. When the local node IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. The RS message will be sent to either those nodes which have joined the all-routers multicast group or to all nodes. The nodes which receive the RA message will process the message as described in section 4.5 and pass the RA message up to the IPv6 layer for processing. Only those nodes which are routers will process the message and respond to it.
为了执行路由器发现，IPv6主机向所有路由器多播地址发送路由器请求消息。当本地节点IPv6/NBMA驱动程序从IPv6网络层获得发送数据包的请求时，它将遵循第4.4.2节中描述的步骤。RS消息将被发送到已加入所有路由器多播组的节点或所有节点。接收RA消息的节点将按照第4.5节所述处理消息，并将RA消息传递到IPv6层进行处理。只有作为路由器的节点才会处理消息并对其作出响应。
An IPv6 router responds to a Router Solicitation by sending a Router Advertisement addressed to the IPv6 all-nodes multicast address if the source address of the Router Solicitation was the unspecified address. If the source address in the Router Solicitation is not the unspecified address, the the router will unicast the Router Advertisement to the soliciting node. If the router sends the Router Advertisement to the all-nodes multicast address then it follows the steps described above for unsolicited Router Advertisements.
如果路由器请求的源地址是未指定的地址，则IPv6路由器通过向IPv6所有节点多播地址发送路由器公告来响应路由器请求。如果路由器请求中的源地址不是未指定的地址，则路由器将单播路由器播发到请求节点。如果路由器将路由器播发发送到所有节点多播地址，那么它将遵循上述针对未经请求的路由器播发的步骤。
If the Router Advertisement is to be unicast to the soliciting node, the IPv6 network layer will give the node's IPv6/NBMA driver the Router Advertisement and link-layer address of the soliciting node (obtained through Address Resolution if necessary) which will send the packet according to the steps described in section 4.4.1 This will result in a new pt-pt VC being created between the router and the soliciting node if one did not already exist.
如果路由器播发要单播到请求节点，IPv6网络层将向节点的IPv6/NBMA驱动程序提供请求节点的路由器播发和链路层地址（必要时通过地址解析获得）它将根据第4.4.1节中描述的步骤发送数据包，这将导致在路由器和请求节点之间创建一个新的pt VC（如果还不存在）。
The soliciting node will receive and process the Router Advertisement as described in section 4.5 and will pass the RA message to the IPv6 network layer. The IPv6 network layer may, depending on the state of the Neighbor cache entry, update the Neighbor cache with the router's NBMA address, contained in the Router Advertisement message's Source Link-Layer Address Option.
请求节点将接收并处理第4.5节所述的路由器公告，并将RA消息传递到IPv6网络层。IPv6网络层可以根据邻居缓存条目的状态，使用路由器广告消息的源链路层地址选项中包含的路由器的NBMA地址更新邻居缓存。
If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best effort unicast data between the soliciting node and the router will be transmitted over the new PtP VC.
如果在路由器发现期间设置了pt-VC，则请求节点和路由器之间的后续IPv6尽力而为单播数据将通过新的PtP-VC传输。
Neighbor Unreachability Detection (NUD) is the process by which an IPv6 host determines that a neighbor is no longer reachable, as described in [7]. Each Neighbor cache entry contains information used by the NUD algorithm to detect reachability failures. Confirmation of a neighbor's reachability comes either from upper-layer protocol indications that data recently sent to the neighbor was received, or from the receipt of a Neighbor Advertisement message in response to a Neighbor Solicitation probe.
邻居不可访问性检测（NUD）是IPv6主机确定邻居不再可访问的过程，如[7]所述。每个邻居缓存项都包含NUD算法用于检测可达性故障的信息。邻居的可达性的确认来自上层协议指示最近发送给邻居的数据已被接收，或者来自接收邻居广告消息以响应邻居请求探测。
Connectivity failures at the node's IPv6/NBMA driver, such as released VCs (see section 4.6) and the inability to create a VC to a neighbor (see section 4.4.1), are detected and handled at the IPv6 network layer, through Neighbor Unreachability Detection. The node's IPv6/NBMA driver does not attempt to detect or recover from these conditions.
通过邻居不可访问性检测，在IPv6网络层检测并处理节点IPv6/NBMA驱动程序的连接故障，例如释放的VCs（请参见第4.6节）和无法创建到邻居的VC（请参见第4.4.1节）。节点的IPv6/NBMA驱动程序不会尝试检测这些情况或从中恢复。
A persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors will be detected and handled through NUD. On each attempt to send data from the IPv6 host to its neighbor, the node's IPv6/NBMA driver will attempt to set up a VC to the neighbor, and failing to do so, will drop the packet. IPv6 reachability confirmation timers will eventually expire, and the neighbor's Neighbor cache entry will enter the PROBE state. The PROBE state will cause the IPv6 host to unicast Neighbor Solicitations to the neighbor, which will be dropped by the local node's IPv6/NBMA driver after again failing to setup the VC. The IPv6 host will therefore never receive the solicited Neighbor Advertisements needed for reachability confirmation, causing the neighbor's entry to be deleted from the Neighbor cache. The next time the IPv6 host tries to send data to that neighbor, address resolution will be performed. Depending on the reason for the previous failure, connectivity to the neighbor could be re-established (for example, if the previous VC setup failure was caused by an obsolete link-layer address in the Neighbor cache).
将通过NUD检测并处理从IPv6主机到其IPv6邻居之一创建VC的持续失败。在每次尝试从IPv6主机向其邻居发送数据时，节点的IPv6/NBMA驱动程序将尝试向邻居设置VC，否则，将丢弃数据包。IPv6可达性确认计时器最终将过期，并且邻居的邻居缓存条目将进入探测状态。探测状态将导致IPv6主机单播邻居请求到邻居，在再次设置VC失败后，本地节点的IPv6/NBMA驱动程序将丢弃该请求。因此，IPv6主机将永远不会接收到请求的邻居播发，从而导致邻居的条目从邻居缓存中删除。下次IPv6主机尝试向该邻居发送数据时，将执行地址解析。根据以前失败的原因，可以重新建立与邻居的连接（例如，如果以前的VC设置失败是由邻居缓存中过时的链路层地址引起的）。
In the event that a VC from an IPv6 neighbor is released, the next time a packet is sent from the IPv6 host to the neighbor, the node's IPv6/NBMA driver will recognize that it no longer has a VC to that neighbor and attempt to setup a new VC to the neighbor. If, on the first and on subsequent transmissions, the node is unable to create a VC to the neighbor, NUD will detect and handle the failure as described earlier (handling the persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors). Depending on the reason for the previous failure, connectivity to the neighbor may or may not be re-established.
如果来自IPv6邻居的VC被释放，则下一次从IPv6主机向邻居发送数据包时，节点的IPv6/NBMA驱动程序将识别出该邻居不再具有VC，并尝试向该邻居设置新的VC。如果在第一次和后续传输中，节点无法向邻居创建VC，NUD将按照前面所述检测并处理故障（处理从IPv6主机向其IPv6邻居之一创建VC的持续故障）。取决于先前故障的原因，与邻居的连接可能会重新建立，也可能不会重新建立。
An IPv6 host performs Duplicate Address Detection (DAD) to determine that the address it wishes to use on the LL (i.e. a tentative address) is not already in use, as described in [9] and [7]. Duplicate Address Detection is performed on all addresses the host wishes to use, regardless of the configuration mechanism used to obtain the address.
IPv6主机执行重复地址检测（DAD），以确定其希望在LL上使用的地址（即暂定地址）尚未使用，如[9]和[7]中所述。对主机希望使用的所有地址执行重复地址检测，而不考虑用于获取地址的配置机制。
Prior to performing Duplicate Address Detection, a host will join the all-nodes multicast address and the solicited-node multicast address corresponding to the host's tentative address (see 4.2. Joining a Multicast Group). The IPv6 host initiates Duplicate Address Detection by sending a Neighbor Solicitation to solicited-node multicast address corresponding to the host's tentative address, with the tentative address as the target. When the local node's IPv6/NBMA driver gets the Neighbor Solicitation message from the IPv6 network layer, it follows the steps outlined in section 4.4.2. The NS message will be sent to those nodes which joined the target solicited-node multicast group or to all nodes. The DAD NS message will be received by one or more nodes on the LL and processed by each as described in section 4.5. Note that the MARS client of the sending node will filter out the message so that the sending node's IPv6 network layer will not see the message. The IPv6 network layer of any node which is not a member of the target solicited-node multicast group will discard the Neighbor Solicitation message.
在执行重复地址检测之前，主机将加入所有节点多播地址和与主机暂定地址对应的请求节点多播地址（参见4.2.加入多播组）。IPv6主机通过向请求的节点多播地址发送邻居请求来启动重复地址检测，请求的节点多播地址对应于主机的暂定地址，暂定地址作为目标。当本地节点的IPv6/NBMA驱动程序从IPv6网络层获取邻居请求消息时，它将遵循第4.4.2节中概述的步骤。NS消息将被发送到加入目标请求节点多播组的节点或所有节点。DAD NS消息将由LL上的一个或多个节点接收，并由每个节点按照第4.5节所述进行处理。请注意，发送节点的MARS客户端将过滤掉该消息，以便发送节点的IPv6网络层不会看到该消息。任何不是目标请求节点多播组成员的节点的IPv6网络层将丢弃邻居请求消息。
If no other hosts have joined the solicited-node multicast address corresponding to the tentative address, then the host will not receive a Neighbor Advertisement containing its tentative address as the target. The host will perform the retransmission logic described in [9], terminate Duplicate Address Detection, and assign the tentative address to the NBMA interface.
如果没有其他主机加入与暂定地址对应的请求节点多播地址，则主机将不会接收包含其暂定地址作为目标的邻居播发。主机将执行[9]中描述的重传逻辑，终止重复地址检测，并将暂定地址分配给NBMA接口。
Otherwise, other hosts on the LL that have joined the solicited-node multicast address corresponding to the tentative address will process the Neighbor Solicitation. The processing will depend on whether or not receiving IPv6 host considers the target address to be tentative.
否则，LL上已加入与暂定地址对应的请求节点多播地址的其他主机将处理邻居请求。处理将取决于接收IPv6主机是否认为目标地址是暂定的。
If the receiving IPv6 host's address is not tentative, the host will respond with a Neighbor Advertisement containing the target address. Because the source of the Neighbor Solicitation is the unspecified address, the host sends the Neighbor Advertisement to the all-nodes multicast address following the steps outlined in section 4.4.2. The DAD NA message will be received and processed by the MARS clients on all nodes in the LL as described in section 4.5. Note that the sending node will filter the incoming message since the CMI in the message header will match that of the receiving node. All other
如果接收IPv6主机的地址不是暂定的，则主机将使用包含目标地址的邻居播发进行响应。因为邻居请求的来源是未指定的地址，所以主机按照第4.4.2节中概述的步骤将邻居播发发送到所有节点多播地址。DAD NA消息将由LL中所有节点上的MARS客户端接收和处理，如第4.5节所述。请注意，发送节点将过滤传入消息，因为消息头中的CMI将与接收节点的CMI匹配。所有其他
nodes will de-encapsulate the message and pass it to the IPv6 network layer. The host performing DAD will detect that its tentative address is the target of the Neighbor Advertisement, and determine that the tentative address is not unique and cannot be assigned to its NBMA interface.
节点将反封装消息并将其传递到IPv6网络层。执行DAD的主机将检测到其暂定地址是邻居播发的目标，并确定暂定地址不是唯一的，无法分配给其NBMA接口。
If the receiving IPv6 host's address is tentative, then both hosts are performing DAD using the same tentative address. The receiving host will determine that the tentative address is not unique and cannot be assigned to its NBMA interface.
如果接收IPv6主机的地址为暂定地址，则两台主机使用相同的暂定地址执行DAD。接收主机将确定暂定地址不是唯一的，并且无法分配给其NBMA接口。
An IPv6 router uses a Redirect Message to inform an IPv6 host of a better first-hop for reaching a particular destination, as described in [7]. This can be used to direct hosts to a better first hop router, another host on the same LL, or to a transient neighbor on another LL. The IPv6 router will unicast the Redirect to the IPv6 source address that triggered the Redirect. The router's IPv6/NBMA driver will transmit the Redirect message using the procedure described in section 4.4.1. This will create a VC between the router and the redirected host if one did not previously exist.
IPv6路由器使用重定向消息通知IPv6主机到达特定目的地的更好的第一跳，如[7]所述。这可用于将主机定向到更好的第一跳路由器、同一个LL上的另一个主机或另一个LL上的临时邻居。IPv6路由器将单播重定向到触发重定向的IPv6源地址。路由器的IPv6/NBMA驱动程序将使用第4.4.1节中描述的程序传输重定向消息。这将在路由器和重定向主机之间创建一个VC（如果以前不存在）。
The IPv6/NBMA driver of the IPv6 host that triggered the Redirect will receive the encapsulated Redirect over one of it's pt-pt VCs. It will the de-encapsulate the packet, and pass the Redirect message to the IPv6 Network Layer, as described section 4.5.
触发重定向的IPv6主机的IPv6/NBMA驱动程序将通过其一个pt VCs接收封装的重定向。它将解除数据包的封装，并将重定向消息传递到IPv6网络层，如第4.5节所述。
Subsequent data sent from the IPv6 host to the destination will be sent to the next-hop address specified in the Redirect Message. For NBMA networks, the Redirect Message should contain the link-layer address option as described in [7] and section 5.2, thus the redirected node will not have to perform a Neighbor Solicitation to learn the link-layer address of the node to which it has been redirected. Thus, the redirect can be to any node on the NBMA network, regardless of the LL membership of the new target node. This allows NBMA hosts to be redirected off their LL to achieve shortcut by using standard IPv6 protocols.
从IPv6主机发送到目标的后续数据将发送到重定向消息中指定的下一个跃点地址。对于NBMA网络，重定向消息应包含[7]和第5.2节中所述的链路层地址选项，因此重定向节点不必执行邻居请求以了解其已重定向到的节点的链路层地址。因此，重定向可以是NBMA网络上的任何节点，而与新目标节点的LL成员身份无关。这允许通过使用标准IPv6协议将NBMA主机重定向出其LL以实现快捷方式。
Once redirected, the IPv6 network layer will give the node's IPv6/NBMA driver the IPv6 packet and the link-layer address of the next-hop node when it sends data to the redirected destination. The node's IPv6/NBMA driver will determine if a VC to the next-hop destination exists. If a pt-pt VC does not exist, then the IPv6/NBMA driver will queue the data packet and initiate a setup of a VC to the destination. When the VC is created, or if one already exists, then the node will encapsulate the outgoing data packet and send it on the VC.
一旦重定向，IPv6网络层将在向重定向目的地发送数据时，为节点的IPv6/NBMA驱动程序提供IPv6数据包和下一跳节点的链路层地址。节点的IPv6/NBMA驱动程序将确定到下一跳目的地的VC是否存在。如果pt VC不存在，则IPv6/NBMA驱动程序将对数据包排队，并启动VC到目标的设置。创建VC时，或者如果已经存在VC，则节点将封装传出数据包并将其发送到VC上。
Note that Redirects are unidirectional. The redirected host will create a VC to the next-hop destination as specified in the Redirect message, but the next-hop will not be redirected to the source host. Because no Neighbor Discovery takes place, the next-hop destination has no way of determining the identity of the caller when it receives the new VC. Also, since ND does not take place on redirects, the next-hop receives no event that would cause it to update it's neighbor or destination caches. However, it will continue to transmit data back to the redirected host on the former path to the redirected host. The next-hop node should be able to use the new VC from the redirected destination if it too receives a redirect redirecting it to the redirected node. This behavior is consistent with [7].
请注意，重定向是单向的。重定向的主机将创建一个到重定向消息中指定的下一跳目标的VC，但下一跳不会重定向到源主机。因为没有邻居发现发生，下一跳目的地在接收到新VC时无法确定调用方的身份。此外，由于ND不会发生在重定向上，因此下一个跃点不会收到任何会导致其更新其邻居或目标缓存的事件。但是，它将继续通过前一条路径将数据传输回重定向主机。如果下一跳节点也接收到将其重定向到重定向节点的重定向，则下一跳节点应该能够使用来自重定向目的地的新VC。这种行为与[7]是一致的。
IPv6 addresses are auto-configured using the stateless or stateful address auto-configuration mechanisms, as described in [9] and [18]. The IPv6 auto-configuration process involves creating and verifying the uniqueness of a link-local address on an LL, determining whether to use stateless and/or stateful configurationmechanisms to obtain addresses, and determining if other (non- address) information is to be autoconfigured. IPv6 addresses can also be manually configured, if for example, auto-configuration fails because the autoconfigured link-local address is not unique. An LL administrator specifies the type of autoconfiguration to use; the hosts on an LL receive this autoconfiguration information through Router Advertisement messages.
IPv6地址是使用无状态或有状态地址自动配置机制自动配置的，如[9]和[18]中所述。IPv6自动配置过程涉及在LL上创建和验证链路本地地址的唯一性，确定是否使用无状态和/或有状态配置机制来获取地址，以及确定是否要自动配置其他（非地址）信息。IPv6地址也可以手动配置，例如，如果自动配置失败，因为自动配置的链路本地地址不唯一。LL管理员指定要使用的自动配置类型；LL上的主机通过路由器广告消息接收此自动配置信息。
The following sections describe how stateless, stateful and manual address configuration will work in an IPv6/NBMA environment.
以下各节描述了无状态、有状态和手动地址配置在IPv6/NBMA环境中的工作方式。
IPv6 stateless address configuration is the process by which an IPv6 host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
IPv6无状态地址配置是IPv6主机自动配置其接口的过程，如[IPv6-ADDRCONF]中所述。
When an IPv6 host first starts up, it generates a link-local address for the interface attached to the Logical Link. It then verifies the uniqueness of the link-local address using Duplicate Address Detection (DAD). If the IPv6 host detects that the link-local address is not unique, the autoconfiguration process terminates. The IPv6 host must then be manually configured.
IPv6主机首次启动时，会为连接到逻辑链路的接口生成链路本地地址。然后使用重复地址检测（DAD）验证链路本地地址的唯一性。如果IPv6主机检测到链路本地地址不唯一，则自动配置过程终止。然后必须手动配置IPv6主机。
After the IPv6 host determines that the link-local address is unique and has assigned it to the interface on the Logical Link, the IPv6 host will perform Router Discovery to obtain auto-configuration information. The IPv6 host will send out a Router Solicitation and will receive a Router Advertisement, or it will wait for an
IPv6主机确定链路本地地址唯一并将其分配给逻辑链路上的接口后，IPv6主机将执行路由器发现以获取自动配置信息。IPv6主机将发送路由器请求并接收路由器公告，或者等待
unsolicited Router Advertisement. The IPv6 host will process the M and O bits of the Router Advertisement, as described in [9] and as a result may invoke stateful address auto- configuration.
未经请求的路由器广告。IPv6主机将处理路由器播发的M和O位，如[9]中所述，因此可能会调用有状态地址自动配置。
If there are no routers on the Logical Link, the IPv6 host will be able to communicate with other IPv6 hosts on the Logical Link using link-local addresses. The IPv6 host will obtain a neighbor's link-layer address using Address Resolution. The IPv6 host will also attempt to invoke stateful auto-configuration, unless it has been explicitly configured not to do so.
如果逻辑链路上没有路由器，IPv6主机将能够使用链路本地地址与逻辑链路上的其他IPv6主机通信。IPv6主机将使用地址解析获取邻居的链路层地址。IPv6主机还将尝试调用有状态自动配置，除非已明确配置为不这样做。
IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to perform stateful address auto-configuration, as described in [18].
IPv6主机使用动态主机配置协议（DHCPv6）执行有状态地址自动配置，如[18]所述。
A DHCPv6 server or relay agent is present on a Logical Link that has been configured with manual or stateful auto-configuration. The DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-Agent multicast group on the Logical Link. When the node's IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 network layer, it follows the process described in section 4.2.
已使用手动或有状态自动配置配置的逻辑链路上存在DHCPv6服务器或中继代理。DHCPv6服务器或中继代理将加入逻辑链路上的IPv6 DHCPv6服务器/中继代理多播组。当节点的IPv6/NBMA驱动程序从IPv6网络层获取JoinLocalGroup请求时，它将遵循第4.2节中描述的过程。
An IPv6 host will invoke stateful auto-configuration if M and O bits of Router Advertisements indicate it should do so, and may invoke stateful auto-configuration if it detects that no routers are present on the Logical Link. An IPv6 host that is obtaining configuration information through the stateful mechanism will hereafter be referred to as a DHCPv6 client.
如果路由器播发的M位和O位指示IPv6主机应调用有状态自动配置，则IPv6主机将调用有状态自动配置；如果IPv6主机检测到逻辑链路上不存在路由器，则可能会调用有状态自动配置。通过有状态机制获取配置信息的IPv6主机在下文中称为DHCPv6客户端。
A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6 Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When the soliciting node's IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. This will result in one or more nodes on the LL receiving the message. Each node that receives the solicitation packet will process it as described in section section 4.5. Only the IPv6 network layer of the DHCPv6 server/relay-agent will accept the packet and process it.
DHCPv6客户端将向DHCPv6服务器/中继代理多播地址发送DHCPv6请求消息，以定位DHCPv6代理。当请求节点的IPv6/NBMA驱动程序从IPv6网络层获得发送数据包的请求时，它将遵循第4.4.2节中描述的步骤。这将导致LL上的一个或多个节点接收消息。接收请求包的每个节点将按照第4.5节中的描述对其进行处理。只有DHCPv6服务器/中继代理的IPv6网络层将接受数据包并对其进行处理。
A DHCPv6 Server or Relay Agent on the Logical Link will unicast a DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network layer will give the node's IPv6/NBMA driver the packet and link-layer address of the DHCPv6 client (obtained through Neighbor Discovery if necessary). The node IPv6/NBMA driver will then transmit the packet as described in section 4.4.1. This will result in a new pt-pt VC being created between the server and the client if one did not previously exist.
逻辑链路上的DHCPv6服务器或中继代理将向DHCPv6客户端单播DHCPv6播发。IPv6网络层将为节点的IPv6/NBMA驱动程序提供DHCPv6客户端的数据包和链路层地址（必要时通过邻居发现获得）。然后，节点IPv6/NBMA驱动程序将按照第4.4.1节所述传输数据包。这将导致在服务器和客户端之间创建一个新的pt VC（如果以前不存在）。
The DHCP client's IPv6/NBMA driver will receive the encapsulated packet from the DHCP Server or Relay Agent, as described in section 4.5. The node will de-encapsulate the multicast packet and then pass it up to the IPv6 Network Layer for processing. The IPv6 network layer will deliver the DHCPv6 Advertise message to the DHCPv6 client.
DHCP客户端的IPv6/NBMA驱动程序将从DHCP服务器或中继代理接收封装的数据包，如第4.5节所述。节点将对多播数据包进行反封装，然后将其传递到IPv6网络层进行处理。IPv6网络层将DHCPv6播发消息传递给DHCPv6客户端。
Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are unicast between the DHCPv6 client and the DHCPv6 Server. Depending on the reachability of the DHCPv6 client's address, messages exchanged between a DHCPv6 client and a DHCPv6 Server on another LL are sent either via a router or DHCPv6 Relay-Agent. Prior to sending the DHCPv6 message, the IPv6 network layer will perform Neighbor Discovery (if necessary) to obtain the link-layer address corresponding to the packet's next-hop. A pt-pt VC will be set up between the sender and the next hop, and the encapsulated packet transmitted over it, as described in 4.4. Sending Data.
其他DHCPv6消息（请求、回复、释放和重新配置）在DHCPv6客户端和DHCPv6服务器之间单播。根据DHCPv6客户端地址的可达性，DHCPv6客户端和另一个LL上的DHCPv6服务器之间交换的消息通过路由器或DHCPv6中继代理发送。在发送DHCPv6消息之前，IPv6网络层将执行邻居发现（如有必要），以获得与数据包的下一跳相对应的链路层地址。如4.4所述，将在发送方和下一跳之间建立pt VC，并在其上传输封装的数据包。发送数据。
An IPv6 host will be manually configured if it discovers through DAD that its link-local address is not unique. Once the IPv6 host is configured with a unique interface token, the auto-configuration mechanisms can then be invoked.
如果IPv6主机通过DAD发现其链路本地地址不唯一，则将手动配置该主机。使用唯一接口令牌配置IPv6主机后，即可调用自动配置机制。
IPv6 multicast routers will use the IGMPv6 protocol to periodically determine group memberships of local hosts. In the framework described here, the IGMPv6 protocols can be used without any special modifications for NBMA. While these protocols might not be the most efficient in this environment, they will still work as described below. However, IPv6 multicast routers connected to an NBMA LL could optionally optimize the IGMP functions by sending MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and determining group memberships by the MARS_GROUPLIST_REPLY messages. Querying the MARS for multicast group membership is an optional enchancement and is not required for routers to determine IPv6 multicast group membership on a LL.
IPv6多播路由器将使用IGMPv6协议定期确定本地主机的组成员身份。在这里描述的框架中，可以使用IGMPv6协议，而无需对NBMA进行任何特殊修改。虽然这些协议在这种环境中可能不是最有效的，但它们仍将按如下所述工作。然而，连接到NBMA LL的IPv6多播路由器可以通过向为LL服务的MARS发送MARS_GROUPLIST_请求消息并通过MARS_GROUPLIST_回复消息确定组成员身份来选择性地优化IGMP功能。查询MARS中的多播组成员资格是一种可选的增强，路由器不需要在LL上确定IPv6多播组成员资格。
There are three ICMPv6 message types that carry multicast group membership information: the Group Membership Query, Group Membership Report and Group Membership Reduction messages. IGMPv6 will continue to work unmodified over the IPv6/NBMA architecture described in this document.
有三种携带多播组成员信息的ICMPv6消息类型：组成员查询、组成员报告和组成员减少消息。IGMPv6将继续在本文档中描述的IPv6/NBMA体系结构上工作，无需修改。
An IPv6 multicast router receives all IPv6 multicast packets on the LL by joining all multicast groups in promiscuous mode [5]. The MARS server will then cause the multicast router to be added to all
IPv6多播路由器通过以混杂模式加入所有多播组来接收LL上的所有IPv6多播数据包[5]。然后，MARS服务器将使多播路由器添加到所有
existing and future multicast VCs. The IPv6 multicast router will thereafter be the recipient of all IPv6 multicast packets sent within the Logical Link.
现有和未来的多播VCs。IPv6多播路由器随后将成为逻辑链路中发送的所有IPv6多播数据包的接收者。
An IPv6 multicast router discovers which multicast groups have members in the Logical Link by periodically sending Group Membership Query messages to the IPv6 all-nodes multicast address. When the local node's IPv6/NBMA driver gets the request from the IPv6 network layer to send the Group Membership Query packet, it follows the steps described in 4.4.2. The node determines that the destination address of the packet is the all-nodes multicast address and passes the packet to the node's MARS client where the packet is encapsulated and directly transmitted to the MARS. The MARS then relays the packet to all nodes in the LL. Each node's IPv6/NBMA drivers will receive the packet, de-encapsulate it, and passed it up to the IPv6 Network layer. If the originating node receives the encapsulated packet, the packet will be filtered out by the MARS client since the Cluster Member ID of the receiving node will match the CMI in the packet's MARS encapsulation header.
IPv6多播路由器通过定期向IPv6所有节点多播地址发送组成员资格查询消息来发现逻辑链路中有哪些多播组成员。当本地节点的IPv6/NBMA驱动程序从IPv6网络层获取发送组成员资格查询数据包的请求时，它将遵循4.4.2中描述的步骤。节点确定包的目的地地址是所有节点的多播地址，并将包传递给节点的MARS客户端，在那里包被封装并直接传输到MARS。然后，MARS将数据包中继到LL中的所有节点。每个节点的IPv6/NBMA驱动程序将接收数据包，对其进行反封装，并将其传递到IPv6网络层。如果始发节点接收到封装的分组，则MARS客户端将过滤掉该分组，因为接收节点的集群成员ID将与分组的MARS封装报头中的CMI匹配。
IPv6 hosts in the Logical Link will respond to a Group Membership Query with a Group Membership Report for each IPv6 multicast group joined by the host. IPv6 hosts can also transmit a Group Membership Report when the host joins a new IPv6 multicast group. The Group Membership Report is sent to the multicast group whose address is being reported. When the local node IPv6/NBMA driver gets the request from the IPv6 network layer to send the packet, it follows the steps described in 4.4.2. The node determines that the packet is being sent to a multicast address so forwards it to the node's MARS client for sending on the appropriate VC.
逻辑链路中的IPv6主机将使用主机加入的每个IPv6多播组的组成员资格报告来响应组成员资格查询。IPv6主机还可以在主机加入新的IPv6多播组时发送组成员身份报告。组成员身份报告将发送到正在报告其地址的多播组。当本地节点IPv6/NBMA驱动程序从IPv6网络层获得发送数据包的请求时，它将遵循4.4.2中描述的步骤。节点确定数据包正在发送到多播地址，因此将其转发到节点的MARS客户端，以便在适当的VC上发送。
The Group Membership Report packets will arrive at every node which is a member of the group being reported through one of the VC attached to each node's MARS client. The MARS client will de-encapsulate the incoming packet and the packet will be passed to the IPv6 network layer for processing. The MARS client of the sending node will filter out the packet when it receives it.
组成员报告数据包将到达每个节点，该节点是通过连接到每个节点的MARS客户端的一个VC报告的组的成员。MARS客户端将对传入的数据包进行反封装，数据包将被传递到IPv6网络层进行处理。发送节点的MARS客户端在接收到数据包时会过滤掉数据包。
An IPv6 host sends a Group Membership Reduction message when the host leaves an IPv6 multicast group. The Group Membership Reduction is sent to the multicast group the IPv6 host is leaving. The transmission and receipt of Group Membership Reduction messages are handled in the same manner as Group Membership Reports.
IPv6主机在离开IPv6多播组时发送组成员减少消息。组成员减少将发送到IPv6主机离开的多播组。发送和接收组成员资格减少消息的方式与处理组成员资格报告的方式相同。
B.1 Simplistic approach - Use MARS 'as is'.
B.1简化方法-按原样使用火星。
The IPv6/NBMA driver utilizes the standard MARS protocol to establish a VC forwarding path out of the interface on which it can transmit all multicast IPv6 packets, including ICMPv6 packets. The IPv6 packets are then transmitted, and received by the intended destination set, using separate pt-mpt VCs per destination group.
IPv6/NBMA驱动程序利用标准MARS协议在接口外建立VC转发路径，在该路径上可以传输所有多播IPv6数据包，包括ICMPv6数据包。然后，使用每个目的地组的单独pt mpt VCs，由预期目的地组发送和接收IPv6数据包。
In this approach all the protocol elements in [5] are used 'as is'. However, SVC resource consumption must be taken into consideration. Unfortunately, ND assumes that link level multicast resources are best conserved by generating a sparsely distributed set of Solicited Node multicast addresses (to which discovery queries are initially sent). The original goal was to minimize the number of innocent nodes that simultaneously received discovery messages really intended for someone else.
在这种方法中，[5]中的所有协议元素都“按原样”使用。但是，必须考虑SVC资源消耗。不幸的是，ND假设通过生成稀疏分布的请求节点多播地址集（发现查询最初发送到该地址），链路级多播资源得到了最好的保护。最初的目标是最大限度地减少同时接收到真正为其他人发送的发现消息的无辜节点的数量。
However, in connection oriented NBMA environments it becomes equally (or more) important to minimize the number of independent VCs that a given NBMA interface is required to originate or terminate. If we treat the MARS service as a 'black box' the sparse Solicited Node address space can lead to a large number of short-use, but longer lived, pt-mpt VCs (generated whenever the node is transmitting Neighbor Solicitations). Even more annoying, these VCs are only useful for additional packets being sent to their associated Solicited Node multicast address. A new pt-pt VC is required to actually carry the unicast IPv6 traffic that prompted the Neighbor Solicitation.
然而，在面向连接的NBMA环境中，最小化给定NBMA接口需要发起或终止的独立VCs的数量变得同样（或更）重要。如果我们将MARS服务视为一个“黑箱”，稀疏请求的节点地址空间可能导致大量使用时间短但寿命较长的pt-mpt-VCs（每当节点发送邻居请求时生成）。更令人恼火的是，这些VCs只对发送到相关请求节点多播地址的附加数据包有用。需要一个新的pt-VC来实际承载促使邻居请求的单播IPv6流量。
The axis of inefficiency brought about by the sparse Solicited Nodes address space is orthogonal to the VC mesh vs Multicast Server tradeoff. Typically a multicast server aggregates traffic flow to a common multicast group onto a single VC. To reduce the VC consumption for ND, we need to aggregate across the Solicited Node address space - performing aggregation on the basis of a packet's function rather than its explicit IPv6 destination. The trade-off here is that the aggregation removes the original value of scattering nodes sparsely across the Solicited Nodes space. This is a price of the mismatch between ND and connection oriented networks.
稀疏请求节点地址空间带来的效率低下轴与VC mesh与多播服务器的权衡是正交的。通常，多播服务器将流量聚合到单个VC上的公共多播组。为了减少ND的VC消耗，我们需要跨请求的节点地址空间进行聚合—根据数据包的功能而不是其明确的IPv6目的地执行聚合。这里的折衷是，聚合会在请求的节点空间中稀疏地删除散射节点的原始值。这是ND和面向连接的网络之间不匹配的代价。
B.2 MARS as a Link (Multicast) Server.
B.2 MARS作为链路（多播）服务器。
One possible aggregation mechanism is for every node's IPv6/NBMA driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and logically remap their destinations to the All Nodes
一种可能的聚合机制是每个节点的IPv6/NBMA驱动程序捕获承载多播ND或RD消息的多播ICMPv6数据包，并从逻辑上将其目的地重新映射到所有节点
group (link local scope). By ensuring that the All Nodes group is supported by an MCS, the resultant VC load within the LL will be significantly reduced.
组（链接本地范围）。通过确保MCS支持所有节点组，LL内的结果VC负载将显著减少。
A further optimization is for every node's IPv6/NBMA driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and send them to the MARS itself for retransmission on ClusterControlVC (involving a trivial extension to the MARS itself.) This approach recognizes that in any LL where IPv6 multicasting is supported:
进一步优化是针对每个节点的IPv6/NBMA驱动程序，以捕获承载多播ND或RD消息的多播ICMPv6数据包，并将其发送到MARS本身，以便在ClusterControlVC上重新传输（涉及到MARS本身的一个小扩展）。此方法可识别在支持IPv6多播的任何LL中：
- Nodes already have a pt-pt VC to their MARS.
- 节点已经有一个到火星的pt VC。
- The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster members (LL members registered for multicast support).
- MARS有一个pt mpt VC（ClusterControlVC）输出给所有集群成员（所有注册为多播支持的成员）。
Because the VCs between a MARS and its MARS clients carry LLC/SNAP encapsulated packets, ICMP packets can be multiplexed along with normal MARS control messages. In essence the MARS behaves as a multicast server for non-MARS packets that it receives from around the LL.
由于MARS及其MARS客户端之间的VCs携带LLC/SNAP封装的数据包，ICMP数据包可以与正常的MARS控制消息一起多路传输。本质上，MARS充当多播服务器，用于接收来自LL周围的非MARS数据包。
As there is no requirement that a MARS client accepts only MARS control messages on ClusterControlVC, ICMP packets received in this fashion may be passed to every node's IP layer without further comment. Within the IP layer, filtering will occur based on the packet's actual destination IP address, and only the targeted node will end up responding.
由于不要求MARS客户端只接受ClusterControlVC上的MARS控制消息，因此以这种方式接收的ICMP数据包可以传递到每个节点的IP层，而无需进一步注释。在IP层中，将根据数据包的实际目的地IP地址进行过滤，并且只有目标节点将最终响应。
Regrettably this approach does result in the entire Cluster's membership having to receive a variety of ICMPv6 messages that they will always throw away.
遗憾的是，这种方法确实导致整个集群的成员必须接收各种各样的ICMPv6消息，而这些消息总是会被丢弃。
The relationship between IPv6 packet flows, Quality of Service guarantees, and optimal use of underlying IP and NBMA network resources are still subjects of ongoing research in the IETF (specifically the ISSLL, RSVP, IPNG, and ION working groups). This document currently only describes the use of flow detection as a means to optimize the use of NBMA network resources through the establishment of inter-LL shortcuts.
IPv6数据包流、服务质量保证以及底层IP和NBMA网络资源的最佳使用之间的关系仍然是IETF（特别是ISSLL、RSVP、IPNG和ION工作组）正在进行的研究主题。本文件目前仅描述流量检测的使用，作为通过建立内部LL快捷方式优化NBMA网络资源使用的一种手段。
For the purposes of this IPv6/NBMA architecture, a flow is:
就本IPv6/NBMA体系结构而言，流程为：
A related sequence of IPv6 packets that the first hop router is allowed to perform flow-detection on for the purposes of triggering shortcut discovery.
允许第一跳路由器对其执行流检测以触发快捷方式发现的相关IPv6数据包序列。
How these packets are considered to be related to each other (e.g. through common header fields such as IPv6 destination addresses) is a local configuration issue.
如何将这些数据包视为彼此相关（例如通过公共头字段，如IPv6目标地址）是本地配置问题。
The flow-detection rule specifies that only packets with a zero FlowID can be considered as flows for which shortcut discovery may be triggered. The rationale behind this decision is:
流检测规则指定只有FlowID为零的数据包可以被视为可以触发快捷方式发现的流。这一决定背后的理由是：
NBMA shortcuts are for the benefit of 'the network' optimizing its forwarding of IPv6 packets in the absence of any other guidance from the host.
NBMA快捷方式有利于“网络”在没有主机任何其他指导的情况下优化其IPv6数据包的转发。
It is desirable for an IPv6/NBMA host to have some mechanism for overriding attempts by 'the network' to optimize its internal forwarding path.
IPv6/NBMA主机需要有某种机制来覆盖“网络”的尝试，以优化其内部转发路径。
A zero FlowID has IPv6 semantics of "the source allows the network to utilize its own discretion in providing best-effort forwarding service for packets with zero FlowID"
zero-FlowID的IPv6语义为“源允许网络自行决定为具有零FlowID的数据包提供尽力而为的转发服务”
The IPv6 semantics of zero FlowID are consistent with the flow-detection rule in this document of "if the FlowID is zero, we are free to optimize the forwarding path using shortcuts"
zero FlowID的IPv6语义与本文档中的流检测规则一致，“如果FlowID为零，我们可以使用快捷方式自由优化转发路径”
A non-zero FlowID has IPv6 semantics of "the source has previously established some preferred, end to end hop by hop forwarding behaviour for packets with this FlowID"
非零FlowID的IPv6语义为“源先前已为具有此FlowID的数据包建立了一些首选的端到端逐跳转发行为”
The IPv6 semantics of non-zero FlowID are consistent with the flow-detection rule in this document of "if the FlowID is non-zero, do not attempt to impose a shortcut".
非零FlowID的IPv6语义与本文档中的流检测规则一致，即“如果FlowID非零，请勿尝试强加快捷方式”。
A non-zero FlowID might be assigned by the source host after negotiating a preferred forwarding mechanism with 'the network' (e.g. through dynamic means such as RSVP, or administrative means). Alternatively it can simply be assigned randomly by the source host, and the network will provide default best effort forwarding (an IPv6 router defaults to providing best-effort forwarding for packets whose FlowID/source-address pair is not recognized).
源主机可在与“网络”协商首选转发机制后（例如，通过动态方式，如RSVP或管理方式）分配非零FlowID。或者，它可以简单地由源主机随机分配，网络将提供默认的尽力而为转发（IPv6路由器默认为其FlowID/源地址对不可识别的数据包提供尽力而为转发）。
Thus, the modes of operation supported by this document becomes:
因此，本文件支持的操作模式为：
Zero FlowID Best effort forwarding, with optional shortcut discovery triggered through flow-detection.
零FlowID尽力而为转发，通过流检测触发可选的快捷方式发现。
Non-zero FlowID Best effort forwarding if the routers along the path have not been otherwise configured with alternative processing rules for this FlowID/source-address pair. Flow detection relating to shortcut discovery is suspended.
如果路径上的路由器没有为此FlowID/源地址对配置备用处理规则，则为非零FlowID最大努力转发。与快捷方式发现相关的流检测已挂起。
If the routers along the path have been configured with particular processing rules for this FlowID/source-address pair, the flow is handled according to those rules. Flow detection relating to shortcut discovery is suspended.
如果路径上的路由器已为此FlowID/源地址对配置了特定的处理规则，则将根据这些规则处理流。与快捷方式发现相关的流检测已挂起。
Mechanisms for establishing particular per-hop processing rules for packets with non-zero FlowID are neither constrained by, nor implied by, this document.
为具有非零FlowID的数据包建立特定每跳处理规则的机制既不受本文档的约束，也不受本文档的暗示。
In the future, accurate mapping of IPv6 flows onto NBMA VCs may require more information to be exchanged during the Neighbor Discovery process than is currently available in Neighbor Discovery packets. In these cases, the IPv6 Neighbor Discover protocols can be extended to include new TLV options (see section 4.6 of RFC 1970 [7]). However, if new options are required, the specification of these options must be co-ordinated with the IPNG working group. Since RFC 1970 specifies that nodes must silently ignore options they do not understand, new options can be added at any time without breaking backward compatibility with existing implementations.
未来，将IPv6流精确映射到NBMA VCs可能需要在邻居发现过程中交换比当前邻居发现数据包中可用的更多的信息。在这些情况下，可以扩展IPv6邻居发现协议以包括新的TLV选项（参见RFC 1970[7]第4.6节）。但是，如果需要新的选项，这些选项的规格必须与IPNG工作组协调。由于RFC1970指定节点必须静默地忽略它们不理解的选项，因此可以随时添加新选项，而不会破坏与现有实现的向后兼容性。
NHRP also provides mechanisms for adding optional TLVs to NHRP Requests and NHRP Replies. Future developments of this document's architecture will require consistent QoS extensions to both ND and NHRP in order to ensure they are semantically equivalent (syntactic differences are undesirable, but can be tolerated).
NHRP还提供了向NHRP请求和NHRP回复添加可选TLV的机制。本文档体系结构的未来发展将需要对ND和NHRP进行一致的QoS扩展，以确保它们在语义上是等效的（语法差异是不可取的，但可以容忍）。
Support for QoS on IPv6 unicast flows will not require further extensions to the existing MARS protocol. However, future support for QoS on IPv6 multicast flows may require extensions. MARS control messages share the same TLV extension mechanism as NHRP, allowing QoS extensions to be developed as needed.
IPv6单播流上的QoS支持将不需要对现有MARS协议进行进一步扩展。但是，未来对IPv6多播流的QoS支持可能需要扩展。MARS控制消息与NHRP共享相同的TLV扩展机制，允许根据需要开发QoS扩展。
For NS messages sent as a shortcut trigger, a new type of ND option is needed to pass on the information about the data flow hop limit from the host to the router. The use of this ND option is defined in section 3.2.2 of this specification. Its binary representation follows the rules of section 4.6 of RFC 1970:
对于作为快捷方式触发器发送的NS消息，需要一种新类型的ND选项来将有关数据流跃点限制的信息从主机传递到路由器。本规范第3.2.2节规定了ND选项的使用。其二进制表示遵循RFC 1970第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 | Shortcut Limit| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Shortcut Limit| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type 6
类型6
Length 1
长度1
Shortcut Limit 8-bit unsigned integer. Hop limit for shortcut attempt.
快捷方式限制8位无符号整数。尝试快捷方式的跃点限制。
Reserved1 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留1此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留2此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Description
描述
The shortcut limit option is used by a host in a Neighbor Solicitation message sent as a shortcut trigger to a default router. It restricts the router's shortcut query to targets reachable via the specified number of hops. The shortcut limit is given relative to the host requesting the shortcut. NS messages with shortcut limit values of 0 or 1 MUST be silently ignored.
主机在作为快捷方式触发器发送到默认路由器的邻居请求消息中使用快捷方式限制选项。它将路由器的快捷查询限制为可通过指定的跃点数到达的目标。快捷方式限制是相对于请求快捷方式的主机给出的。必须以静默方式忽略快捷方式限制值为0或1的NS邮件。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。