Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
Transmission of IPv6 Packets over Frame Relay Networks Specification
IPv6数据包在帧中继网络上的传输规范
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
本备忘录描述了通过帧中继网络传输IPv6数据包的机制。
Table of Contents
目录
1. Introduction.................................................2
2. Maximum Transmission Unit....................................3
3. Frame Format.................................................4
4. Stateless Autoconfiguration..................................5
4.1 Generating the MID field.................................7
5. Link-Local Address...........................................9
6. Address Mapping -- Unicast, Multicast........................9
7. Sending Neighbor Discovery Messages.........................14
8. Receiving Neighbor Discovery Messages.......................15
9. Security Considerations.....................................15
10. Acknowledgments............................................16
11. References.................................................16
12. Authors' Addresses.........................................18
13. Full Copyright Statement...................................19
1. Introduction.................................................2
2. Maximum Transmission Unit....................................3
3. Frame Format.................................................4
4. Stateless Autoconfiguration..................................5
4.1 Generating the MID field.................................7
5. Link-Local Address...........................................9
6. Address Mapping -- Unicast, Multicast........................9
7. Sending Neighbor Discovery Messages.........................14
8. Receiving Neighbor Discovery Messages.......................15
9. Security Considerations.....................................15
10. Acknowledgments............................................16
11. References.................................................16
12. Authors' Addresses.........................................18
13. Full Copyright Statement...................................19
This document specifies the frame format for transmission of IPv6 packets over Frame Relay networks, the method of forming IPv6 link-local addresses on Frame Relay links, and the mapping of the IPv6 addresses to Frame Relay addresses. It also specifies the content of the Source/Target link-layer address option used in Neighbor Discovery [ND] and Inverse Neighbor Discovery [IND] messages when those messages are transmitted over a Frame Relay link. It is part of a set of specifications that define such IPv6 mechanisms for Non Broadcast Multi Access (NBMA) media [IPv6-NBMA], [IPv6-ATM], and a larger set that defines such mechanisms for specific link layers [IPv6-ETH], [IPv6-FDDI], [IPv6-PPP], [IPv6-ATM], etc...
本文件规定了通过帧中继网络传输IPv6数据包的帧格式、在帧中继链路上形成IPv6链路本地地址的方法以及IPv6地址到帧中继地址的映射。它还指定了在通过帧中继链路传输邻居发现[ND]和反向邻居发现[IND]消息时使用的源/目标链路层地址选项的内容。它是为非广播多址（NBMA）媒体定义此类IPv6机制的一组规范[IPv6 NBMA]、[IPv6 ATM]的一部分，以及为特定链路层定义此类机制的一组更大规范[IPv6 ETH]、[IPv6 FDDI]、[IPv6 PPP]、[IPv6 ATM]等。。。
The information in this document applies to Frame Relay devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT.) Frame Relay end stations can be IPv6 hosts or routers. In this document they are referred to as nodes.
本文档中的信息适用于在公共或专用帧中继网络（例如，由公共运营商或PTT提供）上用作终端站（DTE）的帧中继设备。帧中继终端站可以是IPv6主机或路由器。在本文档中，它们被称为节点。
In a Frame Relay network, a number of virtual circuits form the connections between the attached stations (nodes). The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface (card) by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface.
在帧中继网络中，许多虚拟电路在连接的站点（节点）之间形成连接。由此产生的互连设备集形成专用帧中继组，该组可以与虚拟电路的完整“网格”完全互连，也可以仅部分互连。在这两种情况下，每个虚拟电路在每个帧中继接口（卡）处由数据链路连接标识符（DLCI）唯一标识。在大多数情况下，DLCI在每个帧中继接口处具有严格的局部意义。
A Frame Relay virtual circuit acts like a virtual-link (also referred to as logical-link), with its own link parameters, distinct from the parameters of other virtual circuits established on the same wire or fiber. Such parameters are the input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, incoming/outgoing frame rate.
帧中继虚拟电路的作用类似于虚拟链路（也称为逻辑链路），具有自己的链路参数，不同于在同一导线或光纤上建立的其他虚拟电路的参数。这些参数是输入/输出最大帧大小、传入/传出请求/同意吞吐量、传入/传出可接受吞吐量、传入/传出突发大小、传入/传出帧速率。
By default a DLCI is 10 bits in length. Frame Relay specifications define also 16, 17, or 23 bit DLCIs. The former is not used, while the latter two are suggested for use with SVCs.
默认情况下，DLCI的长度为10位。帧中继规范还定义了16、17或23位DLCI。前者不使用，而后两者建议与SVC一起使用。
Frame Relay virtual circuits can be created administratively as Permanent Virtual Circuits -- PVCs -- or dynamically as Switched Virtual Circuits -- SVCs. The mechanisms defined in this document are intended to apply to both permanent and switched Frame Relay virtual circuits, whether they are point to point or point to multi-point.
帧中继虚拟电路可以管理性地创建为永久虚拟电路（PVC），也可以动态地创建为交换虚拟电路（SVC）。本文件中定义的机制旨在适用于永久和交换帧中继虚拟电路，无论它们是点对点还是点对多点。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [RFC 2119].
关键词必须、不得、可、可选、必需、推荐、应、不应、不应按照[RFC 2119]中的定义进行解释。
The IPv6 minimum MTU is defined in [IPv6].
IPv6最小MTU在[IPv6]中定义。
In general, Frame Relay devices are configured to have a maximum frame size of at least 1600 octets. Therefore, the default IPv6 MTU size for a Frame Relay interface is considered to be 1592.
通常，帧中继设备被配置为具有至少1600个八位字节的最大帧大小。因此，帧中继接口的默认IPv6 MTU大小被认为是1592。
A smaller than default frame size can be configured but of course not smaller than the minimum IPv6 MTU.
可以配置小于默认的帧大小，但当然不能小于最小IPv6 MTU。
An adequate larger than default IPv6 MTU and Frame Relay frame size can be configured to avoid fragmentation. The maximum frame size is controlled by the CRC generation mechanisms employed at the HDLC level. CRC16 will protect frames up to 4096 bytes in length, which reduces the effective maximum frame size to approximately 4088 bytes. A larger desired frame size (such as that used by FDDI or Token Ring), would require the CRC32 mechanism, which is not yet widely used and is not mandatory for frame relay systems conforming to Frame Relay Forum and ITU-T standards.
可以配置足够的大于默认值的IPv6 MTU和帧中继帧大小，以避免碎片。最大帧大小由HDLC级别采用的CRC生成机制控制。CRC16将保护长度高达4096字节的帧，从而将有效最大帧大小减少到约4088字节。更大的所需帧大小（如FDDI或令牌环使用的帧大小）将需要CRC32机制，该机制尚未广泛使用，并且对于符合帧中继论坛和ITU-T标准的帧中继系统来说不是强制性的。
In general, if upper layers provide adequate error protection/detection mechanisms, implementations may allow configuring a Frame Relay link with a larger than 4080 octets frame size but with a lesser error protection/detection mechanism at link layer. However, because IPv6 relies on the upper and lower layer error detection, configuring the IPv6 MTU to a value larger than 4080 is strongly discouraged.
通常，如果上层提供足够的错误保护/检测机制，则实现可允许配置帧中继链路，其帧大小大于4080八位字节，但在链路层具有较小的错误保护/检测机制。但是，由于IPv6依赖于上层和下层错误检测，因此强烈建议将IPv6 MTU配置为大于4080的值。
Although a Frame Relay circuit allows the definition of distinct maximum frame sizes for input and output, for simplification purposes, this specification assumes symmetry, i.e. the same MTU for both input and output.
尽管帧中继电路允许为输入和输出定义不同的最大帧大小，但为了简化起见，本规范假定对称，即输入和输出的MTU相同。
Furthermore, implementations may limit the setting of the Frame Relay maximum frame size to the interface (link, or card) level, which then is enforced on all of the PVCs or SVCs on that interface (on that link, or card). For an SVC, the maximum frame size parameter negotiated during circuit setup will not exceed the configured maximum frame size.
此外，实现可以将帧中继最大帧大小的设置限制到接口（链路或卡）级别，然后在该接口（该链路或卡）上的所有pvc或svc上强制执行该设置。对于SVC，在电路设置期间协商的最大帧大小参数将不会超过配置的最大帧大小。
The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs) follows [ENCAPS], which allows a VC to carry IPv6 packets along with other protocol packets. The NLPID frame format is used, in which the IPv6 NLPID has a value of 0x8E:
帧中继（PVC和SVC）的IPv6帧封装遵循[ENCAPS]，允许VC携带IPv6数据包和其他协议数据包。使用NLPID帧格式，其中IPv6 NLPID的值为0x8E：
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | Control (UI) 0x03 | NLPID 0x8E | NLPID
+-----------------------+-----------------------+ indicating
n+2 | . | IPv6
/ . /
/ IPv6 packet /
| . |
+-----------------------+-----------------------+
| |
+ FCS +
| |
+-----------------------+-----------------------+
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | Control (UI) 0x03 | NLPID 0x8E | NLPID
+-----------------------+-----------------------+ indicating
n+2 | . | IPv6
/ . /
/ IPv6 packet /
| . |
+-----------------------+-----------------------+
| |
+ FCS +
| |
+-----------------------+-----------------------+
"n" is the length of the Q.922 address which can be 2 or 4 octets.
“n”是Q.922地址的长度，可以是2或4个八位字节。
The Q.922 representation of a DLCI (in canonical order - the first bit is stored in the least significant, i.e., the right-most bit of a byte in memory) [CANON] is the following:
DLCI的Q.922表示法（按规范顺序-第一位存储在最低有效位，即内存中字节的最右位）[CANON]如下所示：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10位DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
17位DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23位DLCI
The encapsulation of data or control messages exchanged by various protocols that use SNAP encapsulation (with their own PIDs) is not affected. The encoding of the IPv6 protocol identifier in such messages MUST be done according to the specifications of those protocols, and [ASSNUM].
使用SNAP封装（具有自己的PID）的各种协议交换的数据或控制消息的封装不受影响。这些消息中IPv6协议标识符的编码必须根据这些协议的规范和[ASSNUM]进行。
An interface identifier [AARCH] for an IPv6 Frame Relay interface must be unique on a Frame Relay link [AARCH], and must be unique on each of the virtual links represented by the VCs terminated on the interface.
IPv6帧中继接口的接口标识符[AARCH]在帧中继链路[AARCH]上必须是唯一的，并且在接口上终止的VCs表示的每个虚拟链路上必须是唯一的。
The interface identifier for the Frame Relay interface is locally generated by the IPv6 module.
帧中继接口的接口标识符由IPv6模块本地生成。
Each virtual circuit in a Frame Relay network is uniquely identified on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen as an identification of the end point of a virtual circuit on a Frame Relay interface. Since each Frame Relay VC is configured or established separately, and acts like an independent virtual-link from other VCs in the network, or on the interface, link, wire or
帧中继网络中的每个虚拟电路在帧中继接口上由DLCI唯一标识。此外，DLCI可被视为帧中继接口上虚拟电路端点的标识。由于每个帧中继VC都是单独配置或建立的，其作用类似于网络中或接口、链路、导线或网络上其他VCs的独立虚拟链路
fiber, it seems beneficial to view each VC's termination point on the Frame Relay interface as a "pseudo-interface" or "logical-interface" overlaid on the Frame Relay interface. Furthermore, it seems beneficial to be able to generate and associate an IPv6 autoconfigured address (including an IPv6 link local address) to each "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a Frame Relay interface.
在光纤中，将帧中继接口上的每个VC的端点视为覆盖在帧中继接口上的“伪接口”或“逻辑接口”似乎是有益的。此外，能够生成IPv6自动配置地址（包括IPv6链路本地地址）并将其关联到每个“伪接口”，即VC的端点，即帧中继接口上的每个DLCI，似乎是有益的。
In order to achieve the benefits described above, the mechanisms specified in this document suggest constructing the Frame Relay interface identifier from 3 distinct fields (Fig.1):
为了实现上述优点，本文件中规定的机制建议从3个不同字段构造帧中继接口标识符（图1）：
(a) The "EUI bits" field. Bits 6 and 7 of the first octet, representing the EUI-64 "universal/local" and respectively "individual/group" bits converted to IPv6 use. The former is set to zero to reflect that the 64 bit interface identifier value has local significance [AARCH]. The latter is set to 0 to reflect the unicast address [AARCH].
(a) “EUI位”字段。第一个八位字节的第6位和第7位，分别表示转换为IPv6使用的EUI-64“通用/本地”和“单个/组”位。前者设置为零，以反映64位接口标识符值具有局部重要性[AARCH]。后者设置为0以反映单播地址[AARCH]。
(b) The "Mid" field. A 38 bit field which is generated with the purpose of adding uniqueness to the interface identifier.
(b) “中间”区域。为增加接口标识符的唯一性而生成的38位字段。
(c) The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23 bit DLCI value which MUST be extended with 0's to 24 bits. A DLCI based interface identifier -- which contains a valid DLCI -- SHOULD be generated as a result of successfully establishing a VC -- PVC or SVC.
(c) “DLCI”字段。一个24位字段，可保存10、17或23位的DLCI值，该值必须扩展为0到24位。成功建立VC--PVC或SVC后，应生成基于DLCI的接口标识符（其中包含有效的DLCI）。
If a DLCI is not known, the field MUST be set to the "unspecified DLCI" value which consists of setting each of the 24 bits to 1.
如果DLCI未知，则必须将该字段设置为“未指定的DLCI”值，该值包括将24位中的每一位设置为1。
Since DLCIs are local to a Frame Relay node, it is possible to have Frame Relay distinct virtual circuits within a Frame Relay network identified with the same DLCI values.
由于DLCI是帧中继节点的本地，因此可以在帧中继网络中使用相同的DLCI值标识帧中继不同的虚拟电路。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.1 Frame Relay Pseudo-Interface Identifier
图1帧中继伪接口标识符
The Duplicate Address Detection specified in [AUTOCONF] is used repeatedly during the interface identifier and local-link address generation process, until the generated identifier and consequently the link-local address on the link -- VC -- are unique.
[AUTOCONF]中指定的重复地址检测在接口标识符和本地链路地址生成过程中重复使用，直到生成的标识符以及链路上的链路本地地址（VC）是唯一的。
4.1 Generating the "Mid" field.
4.1 生成“中间”字段。
The "Mid" can be generated in multiple ways. This specification suggests two mechanisms:
“Mid”可以通过多种方式生成。本规范提出了两种机制：
(b.1) "Use of Local Administrative Numbers"
（b.1）“使用当地行政号码”
The "Mid" is filled with the result of merging:
“Mid”中填入合并结果：
(b.1.1) A random number of 6 bits in length (Fig.2).
（b.1.1）长度为6位的随机数（图2）。
(b.1.2) The Frame Relay Node Identifier -- 16 bits -- is a user administered value used to locally identify a Frame Relay node (Fig.2).
（b.1.2）帧中继节点标识符（16位）是用户管理的值，用于本地标识帧中继节点（图2）。
(b.1.3) The Frame Relay Link Identifier -- 16 bits -- is a numerical representation of the Frame Relay interface or link (Fig.2).
（b.1.3）帧中继链路标识符——16位——是帧中继接口或链路的数字表示（图2）。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | Random Number | MBZ |
+-----------------------------------+-----+-----+
1 | |
+ Frame Relay Node Identifier +
2 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | |
+ Frame Relay Link Identifier +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | Random Number | MBZ |
+-----------------------------------+-----+-----+
1 | |
+ Frame Relay Node Identifier +
2 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | |
+ Frame Relay Link Identifier +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.2 Frame Relay Pseudo-Interface Identifier
图2帧中继伪接口标识符
or,
或
(b.2) "Use of The Frame Relay address - E.164 [E164], X.121 [X25] numbers, or NSAP [NSAP] address"
（b.2）“帧中继地址的使用-E.164[E164]、X.121[X25]号或NSAP[NSAP]地址”
If a Frame Relay interface has an E.164 or a X.121 number, or an NSAP address, the "Mid" field MUST be filled in with a number resulted from it as follows: the number represented by the BCD encoding of the E.164 or X.121 number, or the binary encoding of the NSAP address is truncated to 38 bits (Fig.3). Since the Frame Relay interface identifier has a "local" significance, the use of such a value has no real practical purposes other than adding to the uniqueness of the interface identifier on the link. Therefore the truncation can be performed on the high order or low order bits. If the high order bits truncation does not provide uniqueness on the link -- perhaps the DLCI value is not unique -- this most likely means that the VC spans more for instance than a national and/or international destination area for an E.164 number, and therefore the truncation of the low order bits should be performed next, which most likely will provide the desired uniqueness.
如果帧中继接口具有E.164或X.121编号，或NSAP地址，“Mid”字段必须填入由其产生的数字，如下所示：由E.164或X.121编号的BCD编码表示的数字，或NSAP地址的二进制编码被截断为38位（图3）。由于帧中继接口标识符具有“本地”意义，因此使用这样的值除了增加链路上接口标识符的唯一性之外没有任何实际目的。因此，可以对高阶或低阶位执行截断。如果高阶位截断没有在链路上提供唯一性——可能DLCI值不是唯一的——这很可能意味着VC跨越的范围超过例如E.164号的国家和/或国际目的地区域，因此，低阶位的截断应在下一步执行，最有可能提供所需的唯一性。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | | MBZ |
+ +-----+-----+
1 | |
+ E.164, X.121 (BCD encoding) +
2 | or NSAP Address |
+ +
3 | (truncated to 38 bits) |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | | MBZ |
+ +-----+-----+
1 | |
+ E.164, X.121 (BCD encoding) +
2 | or NSAP Address |
+ +
3 | (truncated to 38 bits) |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.3 Frame Relay (Pseudo) Interface Identifier
图3帧中继（伪）接口标识符
The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface is formed by appending the interface identifier, formed as defined above, to the prefix FE80::/64 [AARCH].
IPv6帧中继接口的IPv6链路本地地址[AARCH]是通过在前缀FE80:：/64[AARCH]后面附加如上定义的接口标识符形成的。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+
The procedure for mapping IPv6 addresses to link-layer addresses is described in [IPv6-ND]. Additionally, extensions to Neighbor Discovery (ND) that allow the mapping of link-layer addresses to IPv6 addresses are defined as Inverse Neighbor Discovery (IND) in [IND]. This document defines the formats of the link-layer address fields used by ND and IND. This specification does not define an algorithmic mapping of IPv6 multicast addresses to Frame Relay link-layer addresses.
[IPv6 ND]中描述了将IPv6地址映射到链路层地址的过程。此外，允许将链路层地址映射到IPv6地址的邻居发现（ND）扩展在[IND]中定义为反向邻居发现（IND）。本文档定义了ND和IND使用的链路层地址字段的格式。本规范未定义IPv6多播地址到帧中继链路层地址的算法映射。
The Source/Target Link-layer Address option used in Neighbor Discovery and Inverse Neighbor Discovery messages for a Frame Relay link follows the general rules defined by [IPv6-ND]. IPv6 addresses can map two type of identifiers equivalent to link-layer addresses:
帧中继链路的邻居发现和反向邻居发现消息中使用的源/目标链路层地址选项遵循[IPv6 ND]定义的一般规则。IPv6地址可以映射两种等同于链路层地址的标识符：
DLCIs, and Frame Relay Addresses. Therefore, for Frame Relay, this document defines two distinct formats for the ND and IND messages Link-Layer Address field:
DLCI和帧中继地址。因此，对于帧中继，本文档为ND和IND消息链路层地址字段定义了两种不同的格式：
(a) DLCI Format -- used in ND and/or IND messages on VCs that were established prior to the ND or IND message exchange -- mostly PVCs. The use on SVCs makes sense with Inverse Neighbor Discovery [IND] messages if IND is employed after the successful establishing of an SVC to gather information about other IPv6 addresses assigned to the remote node and that SVC.
(a) DLCI格式——用于在ND或IND消息交换之前建立的VCs上的ND和/或IND消息中——主要是PVC。如果在成功建立SVC后使用IND收集有关分配给远程节点和该SVC的其他IPv6地址的信息，则在SVC上使用反向邻居发现[IND]消息是有意义的。
(b) Frame Relay Address Format -- used mostly prior to establishing a new SVC, to get the Frame Relay remote node identifier (link-layer address) mapping to a certain IPv6 address.
(b) 帧中继地址格式——主要在建立新的SVC之前使用，以获取映射到特定IPv6地址的帧中继远程节点标识符（链路层地址）。
Note: An implementation may hold both types of link layer identifiers in the Neighbor Discovery cache. Additionally, in case of multiple VCs between two nodes, one node's Neighbor Discovery cache may hold a mapping of one of the remote node's IPv6 addresses to each and every DLCI identifying the VCs.
注意：一个实现可以在邻居发现缓存中保存这两种类型的链路层标识符。此外，在两个节点之间存在多个vc的情况下，一个节点的邻居发现高速缓存可以保存远程节点的一个IPv6地址到标识vc的每个DLCI的映射。
The mechanisms which in such an implementation would make the distinction between the Neighbor Discovery Cache mapping of an IPv6 address to a "Frame Relay Address Format" and a "DLCI Format" link-layer address, or among several mappings to a "DLCI Format" addresses are beyond the scope of this specification.
在这样的实现中，将区分IPv6地址到“帧中继地址格式”和“DLCI格式”链路层地址的邻居发现缓存映射之间的机制，或者区分到“DLCI格式”地址的多个映射之间的机制超出了本规范的范围。
The use of the override "O" bit in the advertisement messages that contain the above Link-Layer Address formats SHOULD be consistent with the [ND] specifications. Additionally, there should be consistency related to the type of Link-Layer Address format: an implementation should override one address format in its Neighbor Discovery cache with the same type of address format.
在包含上述链路层地址格式的广告消息中使用覆盖“O”位应符合[ND]规范。此外，链路层地址格式的类型应具有一致性：实现应使用相同类型的地址格式覆盖其邻居发现缓存中的一种地址格式。
The "DLCI Format" is defined as follows:
“DLCI格式”定义如下：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
with a DLCI (Q.922 address) encoded as option value:
将DLCI（Q.922地址）编码为选项值：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | |
+ Padding +
7 | (zeros) |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | |
+ Padding +
7 | (zeros) |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10位DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
17位DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23位DLCI
Option fields:
选项字段：
Type 1 for Source Link-layer address. 2 for Target Link-layer address.
为源链路层地址键入1。2表示目标链路层地址。
Length The Length of the Option (including the Type and Length fields) in units of 8 octets. It has the value 1.
长度以8个八位字节为单位的选项长度（包括类型和长度字段）。它的值为1。
Link-Layer Address The DLCI encoded as a Q.922 address.
链路层地址编码为Q.922地址的DLCI。
Description
描述
The "DLCI Format" option value field has two components:
“DLCI格式”选项值字段有两个组件：
(a) Address Type -- encoded in the first two bits of the first two octets. Both bits are set to 1 to indicate the DLCI format. The rest of the bits in the two first octets are not used -- they MUST be set to zero on transmit and MUST be ignored by the receiver.
(a) 地址类型——编码在前两个八位字节的前两位。两个位都设置为1，以指示DLCI格式。前两个八位字节中的其余位不使用——它们在传输时必须设置为零，并且必须被接收器忽略。
(b) DLCI -- encoded as a Q.922 address padded with zeros to the last octet of the 6 octets available for the entire Link-Layer Address field of this format.
(b) DLCI——编码为Q.922地址，用零填充到可用于此格式的整个链路层地址字段的6个八位字节中的最后一个八位字节。
The "Frame Relay Address Format" is defined as follows:
“帧中继地址格式”定义如下：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
with an E.164, X.121, number or NSAP address encoded as option value:
将E.164、X.121、编号或NSAP地址编码为选项值：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | size | 1 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | E.164 or X.121, or NSAP |
+--- Address Family Number ---+
4 | (Assigned Number) |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
/ E.164, or X.121 number (BCD encoded) /
/ or NSAP address /
4+size | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5+size | |
/ Padding /
/ (zeros) /
8*Length-1| |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | size | 1 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | E.164 or X.121, or NSAP |
+--- Address Family Number ---+
4 | (Assigned Number) |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
/ E.164, or X.121 number (BCD encoded) /
/ or NSAP address /
4+size | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5+size | |
/ Padding /
/ (zeros) /
8*Length-1| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Option fields:
选项字段：
Type 1 for Source Link-layer address. 2 for Target Link-layer address.
为源链路层地址键入1。2表示目标链路层地址。
Length The length of the Option (including the Type and Length fields) in units of 8 octet. It may have the value:
长度以8个八位字节为单位的选项长度（包括类型和长度字段）。它可能具有以下值：
2 -- for E.164, or X.121 numbers or NSAP addresses not longer than 11 octets [E164], [X25], [NSAP].
2——对于E.164或X.121数字或不超过11个八位字节[E164]、[X25]、[NSAP]的NSAP地址。
3 -- for NSAP addresses longer than 11 but not longer than 19 octets.
3——对于长度超过11但不超过19个八位字节的NSAP地址。
4 -- for NSAP addresses longer than 19 octets (not longer than the maximum NSAP address length) [NSAP].
4——对于长度超过19个八位字节（不超过最大NSAP地址长度）的NSAP地址[NSAP]。
Link-Layer Address The E.164, X.121, number encoded in Binary Coded Decimal (BCD), or the NSAP address.
链路层地址E.164、X.121、二进制编码十进制（BCD）编码的数字或NSAP地址。
Description
描述
The "Frame Relay Address" option value has three components:
“帧中继地址”选项值有三个组件：
(a) Address Type -- encoded in the first two bits of the first octet. The first bit is set to 0, the second bit is set to 1.
(a) 地址类型——编码在第一个八位组的前两位。第一位设置为0，第二位设置为1。
(b) Size -- encoded in the last (high order) 6 bits of the first octet. The maximum value of the field is the maximum size of the E.164, X.121, or NSAP addresses.
(b) 大小——以第一个八位字节的最后（高阶）6位编码。该字段的最大值是E.164、X.121或NSAP地址的最大大小。
(c) Address Family Number -- the number assigned for the E.164, X.121, or NSAP address family [ASSNUM].
(c) 地址族编号——为E.164、X.121或NSAP地址族[ASSNUM]分配的编号。
(d) E.164, X.121, number -- encoded in BCD (two digits per octet). If the E.164, or X.121 has an even number of digits the encoding will fill all encoding octets -- half the number of digits. If the E.164, or X.121 number has an odd number of digits, the lowest order digit fills only half of an octet -- it is placed in the first 4 bits of the last octet of the E.164, or X.121 BCD encoding. The rest of the field up to the last octet of the 11 octets available is padded with zeros.
(d) E.164，X.121，数字——用BCD编码（每八位字节两位数）。如果E.164或X.121的位数为偶数，则编码将填充所有编码八位字节，即位数的一半。如果E.164或X.121数字的位数为奇数，则最低阶数字仅填充八位字节的一半——它位于E.164或X.121 BCD编码的最后一个八位字节的前4位。该字段的其余部分直到可用的11个八位字节中的最后一个八位字节都用零填充。
NSAP address -- the NSAP address. It is padded with zeros if the NSAP address does not fit in a number of octets that makes the length of the option an even number of 8 octets.
NSAP地址——NSAP地址。如果NSAP地址不适合多个八位字节，则会用零填充，这使得选项的长度为偶数8个八位字节。
Frame Relay networks do not provide link-layer native multicasting mechanisms. For the correct functioning of the Neighbor Discovery mechanisms, link-layer multicasting must be emulated.
帧中继网络不提供链路层本机多播机制。为了正确运行邻居发现机制，必须模拟链路层多播。
To emulate multicasting for Neighbor Discovery (ND) the node MUST send frames carrying ND multicast packets to all VCs on a Frame Relay interface. This applies to ND messages addressed to both all-node and solicited-node multicast addresses. This method works well with PVCs. A mesh of PVCs MAY be configured and dedicated to multicast traffic only. An alternative to a mesh of PVCs is a set of point-to-multipoint PVCs.
为了模拟邻居发现（ND）的多播，节点必须向帧中继接口上的所有VCs发送携带ND多播数据包的帧。这适用于发往所有节点和请求节点多播地址的ND消息。这种方法适用于PVCs。pvc的网格可以被配置并仅专用于多播业务。PVC网格的替代方案是一组点对多点PVC。
If a Neighbor Discovery Solicitation message received by a node contains the Source link-layer address option with a DLCI, the message MUST undergo Frame Relay specific preprocessing required for the correct interpretation of the field during the ND protocol engine processing. This processing is done before the Neighbor Discovery message is processed by the Neighbor Discovery (ND) protocol engine.
如果节点接收到的邻居发现请求消息包含带有DLCI的源链路层地址选项，则该消息必须经过帧中继特定预处理，以便在ND协议引擎处理期间正确解释字段。此处理在邻居发现（ND）协议引擎处理邻居发现消息之前完成。
The motivation for this processing is the local significance of the DLCI fields in the Neighbor Discovery message: the DLCI significance at the sender node is different than the DLCI significance at the receiver node. In other words, the DLCI that identifies the Frame Relay virtual circuit at the sender may be different than the DLCI that identifies the virtual circuit at the receiver node. Furthermore, the sender node may not be aware of the DLCI value at the receiver. Therefore, the Frame Relay specific preprocessing consists in modifying the Neighbor Discovery Solicitation message received, by storing into the Source link-layer address option the DLCI value of the virtual circuit on which the frame was received, as known to the receiver node. The DLCI value being stored must be encoded in the appropriate format (see previous sections). The passing of the DLCI value from the Frame Relay module to the Neighbor Discovery preprocessing module is an implementation choice.
此处理的动机是邻居发现消息中DLCI字段的本地重要性：发送方节点的DLCI重要性不同于接收方节点的DLCI重要性。换句话说，在发送方识别帧中继虚拟电路的DLCI可以不同于在接收方节点识别虚拟电路的DLCI。此外，发送方节点可能不知道接收方的DLCI值。因此，帧中继特定预处理包括通过将接收到帧的虚拟电路的DLCI值存储到源链路层地址选项中（如接收器节点所知）来修改接收到的邻居发现请求消息。存储的DLCI值必须以适当的格式进行编码（请参阅前面的章节）。将DLCI值从帧中继模块传递到邻居发现预处理模块是一种实现选择。
The mechanisms defined in this document for generating an IPv6 Frame Relay interface identifier are intended to provide uniqueness at link level -- virtual circuit. The protection against duplication is achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address Detection mechanisms. Security protection against forgery or accident at the level of the mechanisms described here is provided by the IPv6 security mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to Neighbor Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] messages.
本文档中定义的用于生成IPv6帧中继接口标识符的机制旨在提供链路级（虚拟电路）的唯一性。防止重复的保护是通过IPv6无状态自动配置重复地址检测机制实现的。应用于邻居发现[IPv6 ND]或反向邻居发现[IND]消息的IPv6安全机制[IPSEC]、[IPSEC Auth]、[IPSEC-ESP]在此处描述的机制级别提供了针对伪造或事故的安全保护。
To avoid an IPsec Authentication verification failure, the Frame Relay specific preprocessing of a Neighbor Discovery Solicitation message that contains a DLCI format Source link-layer address option, MUST be done by the receiver node after it completed IP Security processing.
为避免IPsec身份验证失败，接收方节点必须在完成IP安全处理后，对包含DLCI格式源链路层地址选项的邻居发现请求消息进行特定于帧中继的预处理。
Thanks to D. Harrington, and M. Merhar for reviewing this document and providing useful suggestions. Also thanks to G. Armitage for his reviewing and suggestions. Many thanks also to Thomas Narten for suggestions on improving the document.
感谢D.Harrington和M.Merhar审阅本文件并提供有用的建议。还要感谢G.阿米蒂奇的评论和建议。非常感谢Thomas Narten就改进文档提出的建议。
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing Architecture", RFC 2373, July 1998.
[AARCH]Hinden，R.和S.Deering，“IPv6寻址体系结构”，RFC 23731998年7月。
[ASSNUM] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[ASSNUM] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Autoconfiguration", RFC 2462, December 1998.
[AUTOCONF]Thomson，S.和T.Narten，“IPv6无状态自动配置”，RFC 24621998年12月。
[CANON] Narten, T. and C. Burton, "A Caution on the Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
[CANON]Narten，T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 24692998年12月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, November 1998.
[ENCAPS]Brown，C.和A.Malis，“帧中继上的多协议互连”，STD 55，RFC 2427，1998年11月。
[IND] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery", Work in Progress, December 1998.
[IND]Conta，A.，“用于反向发现的IPv6邻居发现的扩展”，正在进行的工作，1998年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议版本6规范”，RFC 2460，1998年12月。
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[IPv6 ATM]Armitage，G.，Schulter，P.和M.Jork，“ATM网络上的IPv6”，RFC 2492，1999年1月。
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6 ETH]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI Networks", RFC 2467, December 1998.
[IPv6 FDDI]Crawford，M.，“通过FDDI网络传输IPv6数据包”，RFC 2467，1998年12月。
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[IPv6 NBMA]Armitage，G.，Schulter，P.，Jork，M.和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6 ND]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[IPv6-PPP] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[IPv6 PPP]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[IPv6-TR] Narten, T., Crawford, M. and M. Thomas, "Transmission of IPv6 packets over Token Ring Networks", RFC 2470, December 1998.
[IPv6 TR]Narten，T.，Crawford，M.和M.Thomas，“通过令牌环网络传输IPv6数据包”，RFC 24701998年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[IPSEC认证]Atkinson，R.和S.Kent，“IP认证头”，RFC 2402，1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[IPSEC-ESP]Atkinson，R.和S.Kent，“IP封装安全协议（ESP）”，RFC 2406，1998年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[E164] International Telecommunication Union - "Telephone Network and ISDN Operation, Numbering, Routing, amd Mobile Service", ITU-T Recommendation E.164, 1991.
[E164]国际电信联盟-“电话网络和ISDN操作、编号、路由、amd移动服务”，ITU-T建议E.164，1991年。
[NSAP] ISO/IEC, "Information Processing Systems -- Data Communications -- Network Service Definition Addendum 2: Network Layer Addressing". International Standard 8348/Addendum 2, ISO/IEC JTC 1, Switzerland 1988.
[NSAP]ISO/IEC，“信息处理系统——数据通信——网络服务定义附录2：网络层寻址”。国际标准8348/附录2，ISO/IEC JTC 1，瑞士1988年。
[X25] "Information Technology -- Data Communications -- X.25 Packet Layer Protocol for Data Terminal Equipment", International Standard 8208, March 1988.
[X25]“信息技术——数据通信——数据终端设备的X.25包层协议”，国际标准82081988年3月。
Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
Alex Conta-Lucent Technologies Inc.马萨诸塞州康科德贝克大道300号100室01742
Phone: +1-978-287-2842
EMail: aconta@lucent.com
Phone: +1-978-287-2842
EMail: aconta@lucent.com
Andrew Malis Ascend Communications 1 Robbins Rd Westford, MA 01886
马萨诸塞州韦斯特福德罗宾斯路1号安德鲁·马利斯·阿森德通讯公司01886
Phone: +1-978-952-7414
EMail: malis@ascend.com
Phone: +1-978-952-7414
EMail: malis@ascend.com
Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
Martin Mueller-Lucent Technologies Inc.马萨诸塞州康科德贝克大道300号100室01742
PHone: +1-978-287-2833
EMail: memueller@lucent.com
PHone: +1-978-287-2833
EMail: memueller@lucent.com
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。