Network Working Group M. Crawford
Request for Comments: 2470 Fermilab
Category: Standards Track T. Narten
IBM
S. Thomas
TransNexus
December 1998
Network Working Group M. Crawford
Request for Comments: 2470 Fermilab
Category: Standards Track T. Narten
IBM
S. Thomas
TransNexus
December 1998
Transmission of IPv6 Packets over Token Ring Networks
通过令牌环网传输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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network.
此备忘录指定令牌环网上IPv6数据包传输的MTU和帧格式。它还规定了在令牌环网络上形成IPv6链路本地地址的方法，以及在令牌环网络上传输路由器请求、路由器通告、重定向、邻居请求和邻居通告消息时使用的源/目标链路层地址选项的内容。
Implementors should be careful to note that Token Ring adaptors assume addresses are in non-canonical rather than canonical format, requiring that special care be taken to insure that addresses are processed correctly. See [CANON] for more details.
实现者应该注意，令牌环适配器假定地址是非规范格式而不是规范格式，需要特别注意确保正确处理地址。有关更多详细信息，请参见[佳能]。
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 [KWORD].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[KWORD]中所述进行解释。
IEEE 802.5 networks have a maximum frame size based on the maximum time a node may hold the token. This time depends on many factors including the data signaling rate and the number of nodes on the ring. Because the maximum frame size varies, implementations must
IEEE 802.5网络具有基于节点可持有令牌的最长时间的最大帧大小。这一时间取决于许多因素，包括数据信令速率和环上的节点数。因为最大帧大小不同，所以实现必须
rely on manual configuration or router advertisements [DISC] to determine actual MTU sizes. Common default values include approximately 2000, 4000, and 8000 octets.
依靠手动配置或路由器广告[DISC]来确定实际MTU大小。常见的默认值包括大约2000、4000和8000个八位字节。
In the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults, as well as with Ethernet LANs in an environment using transparent bridging.
在没有任何其他信息的情况下，实现应使用1500个八位字节的默认MTU。此大小提供了与所有常见802.5默认值的兼容性，以及与使用透明桥接的环境中的以太网LAN的兼容性。
In an environment using source route bridging, the process of discovering the MAC-level path to a neighbor can yield the MTU for the path to that neighbor. The information is contained in the largest frame (LF) subfield of the routing information field. This field limits the size of the information field of frames to that destination, and that information field includes both the LLC [LLC] header and the IPv6 datagram. Since, for IPv6, the LLC header is always 8 octets in length, the IPv6 MTU can be found by subtracting 8 from the maximum frame size defined by the LF subfield. If an implementation uses this information to determine MTU sizes, it must maintain separate MTU values for each neighbor.
在使用源路由桥接的环境中，发现到邻居的MAC级路径的过程可以产生到该邻居的路径的MTU。该信息包含在路由信息字段的最大帧（LF）子字段中。该字段将帧信息字段的大小限制到该目的地，该信息字段包括LLC[LLC]头和IPv6数据报。由于对于IPv6，LLC报头的长度始终为8个八位字节，因此可以通过从LF子字段定义的最大帧大小中减去8来找到IPv6 MTU。如果实现使用此信息确定MTU大小，则必须为每个邻居维护单独的MTU值。
A detailed list of the LF values and the resulting maximum frame size can be found in [BRIDGE]. To illustrate the calculation of IPv6 MTU, the following table lists several common values. Note that some of the 802.1D LF values would result in an IP MTU less than 1280 bytes. This size is less than the IPv6 minimum, and communication across paths with those MTUs is generally not possible using IPv6.
LF值和产生的最大帧大小的详细列表可在[BRIDGE]中找到。为了说明IPv6 MTU的计算，下表列出了几个常用值。请注意，某些802.1D LF值将导致IP MTU小于1280字节。此大小小于IPv6最小值，使用IPv6通常不可能跨路径与这些MTU通信。
LF (base) LF (extension) MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592
LF（基本）LF（扩展）MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592
When presented with conflicting MTU values from several sources, an implementation should choose from those sources according to the following priorities:
当呈现来自多个来源的冲突MTU值时，实施应根据以下优先级从这些来源中进行选择：
1. Largest Frame values from source route bridging (only for specific, unicast destinations), but only if not greater than value from any router advertisements
1. 源路由桥接的最大帧值（仅适用于特定的单播目的地），但仅当不大于任何路由器广告的值时
2. Router advertisements, but only if not greater than any manual configuration (including DHCP)
2. 路由器播发，但仅当不大于任何手动配置（包括DHCP）时
3. Manual configuration (including DHCP)
3. 手动配置（包括DHCP）
4. Default of 1500
4. 默认值为1500
IPv6 packets are transmitted in LLC/SNAP frames. The data field contains the IPv6 header and payload. The following figure shows a complete 802.5 frame containing an IPv6 datagram.
IPv6数据包在LLC/SNAP帧中传输。数据字段包含IPv6标头和有效负载。下图显示了包含IPv6数据报的完整802.5帧。
+-------+-------+-------+-------+
| SD | AC | FC | |
+-----------------------+ |
| Destination Address |
| +-----------------------+
| | Source |
+-------+ Address +-------+
| | DSAP |
+-------+-------+-------+-------+
| SSAP | CTL | OUI |
+-------+-------+-------+-------+
| OUI | EtherType | |
+-------+---------------+ |
| |
~ IPv6 header and payload... ~
| |
+-------------------------------+
| FCS |
+-------+-------+---------------+
| ED | FS |
+-------+-------+
+-------+-------+-------+-------+
| SD | AC | FC | |
+-----------------------+ |
| Destination Address |
| +-----------------------+
| | Source |
+-------+ Address +-------+
| | DSAP |
+-------+-------+-------+-------+
| SSAP | CTL | OUI |
+-------+-------+-------+-------+
| OUI | EtherType | |
+-------+---------------+ |
| |
~ IPv6 header and payload... ~
| |
+-------------------------------+
| FCS |
+-------+-------+---------------+
| ED | FS |
+-------+-------+
Token Ring Header Fields
令牌环头字段
SD: Starting Delimiter
SD:起始分隔符
AC: Access Control
AC：访问控制
FC: Frame Control
帧控制
Destination Address: 48-bit IEEE address of destination station
目的地址：目的站的48位IEEE地址
Source Address: 48-bit IEEE address of source station
源地址：源站的48位IEEE地址
DSAP: Destination Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA)
DSAP：目标服务接入点（对于LLC/SNAP格式，应始终包含值0xAA）
SSAP: Source Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA)
SSAP：源服务访问点（对于LLC/SNAP格式，应始终包含值0xAA）
CTL: Control Field (for Unnumbered Information, shall always contain the value 0x03)
控制字段（对于未编号的信息，应始终包含值0x03）
OUI: Organizationally Unique Identifier (for EtherType encoding, shall always contain the value 0x000000)
OUI：组织唯一标识符（对于EtherType编码，应始终包含值0x000000）
EtherType: Protocol type of encapsulated payload (for IPv6, shall always contain the value 0x86DD)
EtherType：封装负载的协议类型（对于IPv6，应始终包含值0x86DD）
FCS: Frame Check Sequence
FCS：帧检查序列
ED: Ending Delimiter
结束分隔符
FS: Frame Status
帧状态
In the presence of source route bridges, a routing information field (RIF) may appear immediately after the source address. A RIF is present in frames when the most significant bit of the source address is set to one. (This is the bit whose position corresponds to that of the Individual/Group bit in the Destination Address.)
在存在源路由桥的情况下，路由信息字段（RIF）可能会立即出现在源地址之后。当源地址的最高有效位设置为1时，RIF出现在帧中。（该位的位置与目标地址中单个/组位的位置相对应。）
The RIF is a variable-length field that (when present) contains a two-octet Routing Control (RC) header, followed by zero or more two-octet Route Designator fields:
RIF是一个可变长度字段（如果存在），包含一个双八位组路由控制（RC）头，后跟零个或多个双八位组路由指示符字段：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Control: |Bcast| Length |D| LF |rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator 1: | Segment 1 |Bridge1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator N: | Segment N |BridgeN|
(0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Control: |Bcast| Length |D| LF |rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator 1: | Segment 1 |Bridge1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator N: | Segment N |BridgeN|
(0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator Fields:
路线指示器字段：
Bcast: Broadcast Indicator, Defined values:
Bcast：广播指示器，定义值：
10x: All Routes Explorer 11x: Spanning Tree Explorer 0xx: Specifically Routed Frame
10x:所有路由资源管理器11x:生成树资源管理器0xx:特定路由帧
Length: Total length of RIF field in octets
长度：RIF字段的总长度（以八位字节为单位）
D: Direction of source route. A value of 0 means that the left-to-right sequence of Route Designators provides the path from the sender to recipient. A value of 0 indicates the sequence goes from recipient to sender.
D：源路由的方向。值为0表示从左到右的路由指示符序列提供了从发送方到接收方的路径。值0表示序列从收件人到发件人。
LF: Largest Frame
LF：最大帧
rsvd: Reserved
rsvd：保留
On transmission, the Route Designator fields give the sequence of (bridge, LAN segment) numbers the packet is to traverse. It is the responsibility of the sender to provide this sequence for Specifically Routed Frames, i.e., unicast IP datagrams.
在传输时，路由指示符字段给出数据包要穿越的（网桥、LAN段）编号序列。发送方负责为特定路由帧（即单播IP数据报）提供该序列。
The Interface Identifier [AARCH] for a Token Ring interface is based on the EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE 802 address. The OUI of the Token Ring address (the first three octets) becomes the company_id of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value FFFE hexadecimal. The last three octets of the Token Ring address become the last three octets of the EUI-64.
令牌环接口的接口标识符[AARCH]基于从接口的内置48位IEEE 802地址派生的EUI-64标识符[EUI64]。令牌环地址（前三个八位字节）的OUI成为EUI-64（前三个八位字节）的公司id。EUI的第四和第五个八位字节设置为固定值FFFE十六进制。令牌环地址的最后三个八位字节成为EUI-64的最后三个八位字节。
The Interface Identifier is then formed from the EUI-64 by complementing the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in address is expected to be from a universally administered address space and hence have a globally unique value. A universally administered IEEE 802 address or an EUI-64 is signified by a 0 in the U/L bit position, while a globally unique IPv6 Interface Identifier is signified by a 1 in the corresponding position. For further discussion on this point, see [AARCH].
然后，通过补充“通用/本地”（U/L）位，从EUI-64形成接口标识符，该位是EUI-64的第一个八位组的下一个最低阶位。补充该位通常会将0值更改为1，因为接口的内置地址预期来自通用管理的地址空间，因此具有全局唯一值。通用管理的IEEE 802地址或EUI-64由U/L位位置的0表示，而全局唯一IPv6接口标识符由相应位置的1表示。关于这一点的进一步讨论，请参见[AARCH]。
For example, the Interface Identifier for a Token Ring interface whose built-in address is, in hexadecimal and in canonical bit order,
例如，令牌环接口的接口标识符，其内置地址为十六进制且按规范位顺序，
34-56-78-9A-BC-DE
34-56-78-9A-BC-DE
would be
会是
36-56-78-FF-FE-9A-BC-DE.
36-56-78-FF-FE-9A-BC-DE。
A different MAC address set manually or by software should not be used to derive the Interface Identifier. If such a MAC address must be used, its global uniqueness property should be reflected in the value of the U/L bit.
不应使用手动或软件设置的不同MAC地址来推导接口标识符。如果必须使用这样的MAC地址，则其全局唯一性属性应反映在U/L位的值中。
An IPv6 address prefix used for stateless autoconfiguration of a Token Ring interface must have a length of 64 bits.
用于令牌环接口无状态自动配置的IPv6地址前缀的长度必须为64位。
The IPv6 link-local address [AARCH] for a Token Ring interface is formed by appending the Interface Identifer, as defined above, to the prefix FE80::/64.
令牌环接口的IPv6链路本地地址[AARCH]是通过将接口标识符（如上所述）附加到前缀FE80:：/64来形成的。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
The procedure for mapping unicast IPv6 addresses into Token Ring link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Token Ring.
[DISC]中描述了将单播IPv6地址映射到令牌环链路层地址的过程。当链路层为令牌环时，源/目标链路层地址选项具有以下形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Token Ring -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Token Ring -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option fields:
选项字段：
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
类型：1表示源链接层地址。2表示目标链路层地址。
Length: 1 (in units of 8 octets).
长度：1（以8个八位字节为单位）。
Token Ring Address: The 48 bit Token Ring IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used to derive the Interface Identifier.
令牌环地址：48位令牌环IEEE 802地址，按规范位顺序排列。这是接口当前响应的地址，可能与用于派生接口标识符的内置地址不同。
When source routing bridges are used, the source route for the path to a destination can be extracted from the RIF field of received Neighbor Advertisement messages. Note that the RIF field of received packets can be reversed into a source route suitable for transmitting return traffic by toggling the value of the 'D' bit and insuring that the Bcast field is set to indicate a Specifically Routed Frame.
当使用源路由桥时，可以从接收到的邻居播发消息的RIF字段中提取到目的地的路径的源路由。注意，通过切换“D”位的值并确保Bcast字段设置为指示特定路由的帧，可以将接收到的分组的RIF字段反转为适合发送返回业务的源路由。
All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. The following table shows the specific mapping between the IPv6 addresses and Token Ring functional addresses (in canonical form). Note that protocols other than IPv6 may use these same functional addresses, so all Token Ring frames destined to these functional addresses are not guaranteed to be IPv6 datagrams.
具有多播目标地址的所有IPv6数据包都传输到令牌环功能地址。下表显示了IPv6地址和令牌环功能地址（标准形式）之间的特定映射。请注意，IPv6以外的协议可能使用这些相同的功能地址，因此不保证发送到这些功能地址的所有令牌环帧都是IPv6数据报。
MAC Addr (canonical) IPv6 Multicast Addresses
MAC地址（规范）IPv6多播地址
03-00-80-00-00-00 All-Nodes (FF01::1 and FF02::1) and
solicited node (FF02:0:0:0:0:1:FFXX:XXXX)
addresses
03-00-80-00-00-00 All-Nodes (FF01::1 and FF02::1) and
solicited node (FF02:0:0:0:0:1:FFXX:XXXX)
addresses
03-00-40-00-00-00 All-Routers addresses (FF0X::2)
03-00-40-00-00-00所有路由器地址（FF0X:：2）
03-00-00-80-00-00 any other multicast address with three least significant bits = 000
03-00-00-80-00-00任何其他具有三个最低有效位=000的多播地址
03-00-00-40-00-00 any other multicast address with three least significant bits = 001
03-00-00-40-00-00任何其他具有三个最低有效位的多播地址=001
03-00-00-20-00-00 any other multicast address with three least significant bits = 010
03-00-00-20-00-00任何其他具有三个最低有效位的多播地址=010
03-00-00-10-00-00 any other multicast address with three least significant bits = 011
03-00-00-10-00-00任何其他具有三个最低有效位的多播地址=011
03-00-00-08-00-00 any other multicast address with three least significant bits = 100
03-00-00-08-00-00任何其他具有三个最低有效位=100的多播地址
03-00-00-04-00-00 any other multicast address with three least significant bits = 101
03-00-00-04-00-00任何其他具有三个最低有效位的多播地址=101
03-00-00-02-00-00 any other multicast address with three least significant bits = 110
03-00-00-02-00-00任何其他具有三个最低有效位的多播地址=110
03-00-00-01-00-00 any other multicast address with three least significant bits = 111
03-00-00-01-00-00任何其他具有三个最低有效位的多播地址=111
In a bridged token ring network, all multicast packets SHOULD be sent with a RIF header specifying the use of the Spanning Tree Explorer.
在桥接令牌环网中，所有多播数据包都应使用指定使用生成树资源管理器的RIF报头发送。
Note: it is believed that some (very) old bridge implementations do not properly support the Spanning Tree Explorer mechanism. In such environments, multicast traffic sent through bridges must use a RIF with the All Routes Explorer. Consequently, an implementation MAY wish to allow the sending of IP multicast traffic using an All Routes Explorer. However, such an ability must be configurable by a system administrator and the default setting of the switch MUST be to use the Spanning Tree Explorer.
注意：人们认为一些（非常）旧的桥接器实现不能正确支持生成树资源管理器机制。在这样的环境中，通过网桥发送的多播流量必须使用带有“所有路由”资源管理器的RIF。因此，实现可能希望允许使用全路由资源管理器发送IP多播通信量。但是，这样的功能必须由系统管理员配置，并且交换机的默认设置必须是使用生成树资源管理器。
Token Ring, like most broadcast LAN technologies, has inherent security vulnerabilities. For example, any sender can claim the identity of another and forge traffic. It is the responsibility of higher layers to take appropriate steps in those environments where such vulnerabilities are unacceptable.
令牌环与大多数广播局域网技术一样，具有固有的安全漏洞。例如，任何发送方都可以声明另一方的身份并伪造流量。高层有责任在此类漏洞不可接受的环境中采取适当措施。
Several members of the IEEE 802.5 Working Group contributed their knowledge and experience to the drafting of this specification, including Jim, Andrew Draper, George Lin, John Messenger, Kirk Preiss, and Trevor Warwick. The author would also like to thank many members of the IPng working group for their advice and suggestions, including Ran Atkinson, Scott Bradner, Steve Deering, Francis Dupont, Robert Elz, and Matt Thomas. A special thanks is due Steve Wise, who gave the most relevant advice of all by actually trying to implement this specification while it was in progress.
IEEE 802.5工作组的若干成员为本规范的起草贡献了他们的知识和经验，包括Jim、Andrew Draper、George Lin、John Messenger、Kirk Preiss和Trevor Warwick。作者还要感谢IPng工作组的许多成员的建议和建议，包括Ran Atkinson、Scott Bradner、Steve Deering、Francis Dupont、Robert Elz和Matt Thomas。特别要感谢Steve Wise，他给出了所有建议中最相关的建议，在规范进行过程中实际尝试实现了该规范。
[802.5] 8802-5 : 1995 (ISO/IEC) [ANSI/IEEE 802.5, 1995 Edition] Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements-- Part 5: Token ring access method and physical layer specification.
[802.5]8802-5:1995（ISO/IEC）[ANSI/IEEE 802.51995版]信息技术——系统间的电信和信息交换——局域网和城域网——特殊要求——第5部分：令牌环访问方法和物理层规范。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[BRIDGE] 10038: 1993 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1993 Edition] Information technology--Telecommunications and information exchange between systems--Local area networks--Media access control (MAC) bridges.
[网桥]10038:1993（ISO/IEC）[ANSI/IEEE标准802.1D，1993年版]信息技术——系统间的电信和信息交换——局域网——媒体访问控制（MAC）网桥。
[CANON] Narten, T. and C. Burton, "A Caution on Canonical Bit Order Of Link-Layer Addresses", RFC 2469, December 1998.
[CANON]Narten，T.和C.Burton，“链路层地址规范位顺序的注意事项”，RFC 24692998年12月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
[CONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 1971，1996年8月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[EUI64] "64-Bit Global Identifier Format Tutorial", http: //standards.ieee.org/db/oui/tutorials/EUI64.html.
[EUI64]“64位全局标识符格式教程”，http://standards.ieee.org/db/oui/tutorials/EUI64.html。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[KWORD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LLC] 8802-2 : 1994 (ISO/IEC) [ANSI/IEEE 802.2, 1994 Edition] Information technology--Telecommunications and information exchange between systems--Local and Metropolitan area networks--Specific requirements-- Part 2: Logical link control.
[LLC]8802-2:1994（ISO/IEC）[ANSI/IEEE 802.219994版]信息技术系统间电信和信息交换局域网和城域网特殊要求第2部分：逻辑链路控制。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368美国伊利诺伊州巴达维亚500号邮政信箱60510
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
美国北卡罗来纳州三角研究园12195号邮政信箱托马斯·纳顿IBM公司，邮编：27709-2195
Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.com
Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.com
Stephen Thomas TransNexus 430 Tenth Street NW Suite N204 Atlanta, GA 30318 USA
Stephen Thomas TransNexus美国佐治亚州亚特兰大西北第十街430号N204套房，邮编30318
Phone: +1 404 872 4745
EMail: stephen.thomas@transnexus.com
Phone: +1 404 872 4745
EMail: stephen.thomas@transnexus.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。