Network Working Group G. Armitage
Request for Comments: 2492 Lucent Technologies
Category: Standards Track P. Schulter
BrightTiger Technologies
M. Jork
Digital Equipment GmbH
January 1999
Network Working Group G. Armitage
Request for Comments: 2492 Lucent Technologies
Category: Standards Track P. Schulter
BrightTiger Technologies
M. Jork
Digital Equipment GmbH
January 1999
IPv6 over ATM Networks
ATM网络上的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 is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.
本文件是ION工作组架构文件“非广播多址（NBMA）网络上的IPv6”的配套文件。它提供了如何将IPv6 over NBMA体系结构应用于ATM网络的具体细节。此体系结构允许IPv6邻居发现协议的常规主机端操作，同时还支持建立“快捷”ATM转发路径（使用SVC时）。还支持通过管理配置的点对点PVC进行操作。
1. Introduction.
1. 介绍
This document is an ATM-specific companion document to the ION working group's, "IPv6 over Non Broadcast Multiple Access (NBMA) networks" specification [1]. Terminology and architectural descriptions will not be repeated here.
本文件是ION工作组“非广播多址（NBMA）网络上的IPv6”规范[1]的ATM专用配套文件。这里不再重复术语和体系结构描述。
The use of ATM to provide point to point PVC service, or flexible point to point and point to multipoint SVC service, is covered by this document.
本文件涵盖使用ATM提供点对点PVC服务，或灵活的点对点和点对多点SVC服务。
A minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. An IPv6/ATM driver that supports the full SVC mode SHALL also support PVC mode of operation.
符合最低要求的IPv6/ATM驱动程序应支持PVC操作模式。支持全SVC模式的IPv6/ATM驱动程序也应支持PVC操作模式。
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]中所述进行解释。
When the ATM 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/ATM 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 ATM level unicast operation. Dynamically discovered shortcuts are not supported.
当ATM网络以PVC模式使用时，每个PVC将恰好连接两个节点，并且邻居发现和其他IPv6功能的使用受到限制。IPv6/ATM接口在每个链路上只有一个邻居。MARS和NHRP协议是不必要的，因为多播和广播操作崩溃为ATM级别的单播操作。不支持动态发现的快捷方式。
The actual details of encapsulations, MTU, and link token generation are provided in the following sections.
封装、MTU和链接令牌生成的实际细节将在以下部分中提供。
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连接中的一般用途（例如，反向邻居发现）。
Since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. If a link-layer address option is present in an ND message, then the option SHOULD be ignored.
由于ATM PVC链路不使用链路层地址，因此链路层地址选项不应包含在任何ND消息中[11]。如果ND消息中存在链路层地址选项，则应忽略该选项。
A minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. PVC only implementations are not required to support any SVC mode of operation.
符合最低要求的IPv6/ATM驱动程序应支持PVC操作模式。仅PVC实施不需要支持任何SVC运行模式。
Following the model in RFC 1483 [2], AAL5 SHALL be the default Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be default encapsulation used by unicast and multicast packets across pt-pt PVC links. As defined in [1], the default IPv6 packet encapsulation SHALL be:
按照RFC 1483[2]中的模型，AAL5应为默认的适配层服务，（LLC/SNAP）封装应为pt PVC链路上单播和多播数据包使用的默认封装。如[1]中所定义，默认IPv6数据包封装应为：
[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）
IPv6/ATM drivers MAY also support null encapsulation as a configurable option. When null encapsulation is enabled, the IPv6 packet is passed directly to the AAL5 layer. Both ends of the PVC MUST be configured to use null encapsulation. The PVC will not be available for use by protocols other than IPv6.
IPv6/ATM驱动程序还可以支持空封装作为一个可配置选项。当启用空封装时，IPv6数据包将直接传递到AAL5层。PVC的两端必须配置为使用空封装。PVC将不可用于IPv6以外的协议。
The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not covered by this specification.
本规范不包括IPv6 over PPP与PPP over AAL5 PVC的具体情况。
The default IP MTU size for PVC links is 9180 bytes as specified in [7]. Other IP MTU values MAY be used.
PVC链路的默认IP MTU大小为9180字节，如[7]中所述。可使用其他IP MTU值。
When the ATM network is used in PVC mode interface tokens SHALL be generated using one of the methods described in section 5. Interface tokens need only be unique between the two nodes on the PVC link.
当ATM网络用于PVC模式时，应使用第5节所述的方法之一生成接口令牌。接口令牌只需在PVC链路上的两个节点之间是唯一的。
4 SVC environments
4 SVC环境
Following the model in RFC 1483 [2], AAL5 SHALL be the default Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the default encapsulation used by unicast and multicast packets across SVC links.
按照RFC 1483[2]中的模型，AAL5应为默认的适配层服务，（LLC/SNAP）封装应为SVC链路上单播和多播数据包使用的默认封装。
As defined in [1], the default IPv6 unicast packet encapsulation SHALL be:
如[1]中所定义，默认IPv6单播数据包封装应为：
[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）
As defined in [1], the default IPv6 multicast packet encapsulation SHALL be:
如[1]中所定义，默认IPv6多播数据包封装应为：
[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/ATM driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field prior to transmission.
在传输之前，应将IPv6/ATM驱动程序的集群成员ID复制到2个八位字节的pkt$cmi字段中。
IPv6/ATM drivers MAY also support null encapsulation as a configurable option. Null encapsulation SHALL only be used for passing IPv6 packets from one IPv6/ATM driver to another. Null encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM driver and its local MARS.
IPv6/ATM驱动程序还可以支持空封装作为一个可配置选项。空封装只能用于将IPv6数据包从一个IPv6/ATM驱动程序传递到另一个驱动程序。IPv6/ATM驱动程序与其本地MARS之间的pt SVC上不得使用空封装。
If null encapsulation is enabled, the IPv6 packet is passed directly to the AAL5 layer. Both ends of the SVC MUST agree to use null encapsulation during the call SETUP phase. The SVC will not be available for use by protocols other than IPv6.
如果启用空封装，IPv6数据包将直接传递到AAL5层。SVC的两端必须同意在呼叫设置阶段使用空封装。SVC将不可用于IPv6以外的协议。
If null encapsulation is enabled on data SVCs between routers, inter-router NHRP traffic SHALL utilize a separate, parallel SVC.
如果在路由器之间的数据SVC上启用空封装，路由器间NHRP流量应使用单独的并行SVC。
Use of null encapsulation is not encouraged when IPv6/ATM is used with MARS/NHRP/ND as described in [1].
如[1]所述，当IPv6/ATM与MARS/NHRP/ND一起使用时，不鼓励使用空封装。
The encapsulation of MARS control messages (between MARS and MARS Clients) remains the same as shown in RFC 2022 [3]:
MARS控制消息的封装（在MARS和MARS客户端之间）与RFC 2022[3]中所示的相同：
[0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message] (LLC) (OUI) (PID)
[0xAA-AA-03][0x00-00-5E][0x00-03][MARS控制信息]（LLC）（OUI）（PID）
The key control field values are:
关键控制字段值为：
The mar$afn field remains 0x0F (ATM addresses)
mar$afn字段保持0x0F（ATM地址）
The mar$pro field SHALL be 0x86DD (IPv6)
mar$pro字段应为0x86DD（IPv6）
The mar$op.version field remains 0x00 (MARS)
mar$op.version字段保持0x00（MARS）
The mar$spln and mar$tpln fields (where relevant) are either 0 (for null or non-existent information) or 16 (for the full IPv6 protocol address)
mar$spln和mar$tpln字段（如果相关）要么为0（表示空信息或不存在信息），要么为16（表示完整的IPv6协议地址）
The way in which ATM addresses are stored remains the same as shown in RFC 2022 [3]
ATM地址的存储方式与RFC 2022[3]中所示的相同
The encapsulation of NHRP control messages remains the same as shown in RFC 2332 [4]:
NHRP控制消息的封装与RFC 2332[4]中所示的相同：
[0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message] (LLC) (OUI) (PID)
[0xAA-AA-03][0x00-00-5E][0x00-03][NHRP控制消息]（LLC）（OUI）（PID）
The key control field values are:
关键控制字段值为：
The ar$afn field remains 0x0F (ATM addresses)
ar$afn字段保持0x0F（ATM地址）
The ar$pro field SHALL be 0x86DD (IPv6)
ar$pro字段应为0x86DD（IPv6）
The ar$op.version field remains 0x01 (NHRP)
ar$op.version字段保持0x01（NHRP）
The ar$spln and ar$tpln fields (where relevant) are either 0 (for null or non-existent information) or 16 (for the full IPv6 protocol address)
ar$spln和ar$tpln字段（如果相关）要么为0（表示空信息或不存在信息），要么为16（表示完整的IPv6协议地址）
The way in which ATM addresses are stored remains the same as shown in RFC 2022 [3]
ATM地址的存储方式与RFC 2022[3]中所示的相同
Section 5.2 of [1] describes the ND Link-layer address option. For IPv6/ATM drivers, the subfields SHALL be encoded in the following manner:
[1]的第5.2节描述了ND链路层地址选项。对于IPv6/ATM驱动程序，子字段应按以下方式编码：
[NTL] defines the type and length of the ATM number immediately following the [STL] field. The format is as follows:
[NTL]定义紧跟在[STL]字段后面的ATM号码的类型和长度。格式如下:
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The second most significant bit (x) is a flag indicating whether the ATM number is in:
最高有效位保留，必须设置为零。第二个最高有效位（x）是一个标志，指示ATM号码是否在：
ATM Forum AESA format (x = 0). Native E.164 format (x = 1).
ATM论坛AESA格式（x=0）。本机E.164格式（x=1）。
The bottom 6 bits represent an unsigned integer value indicating the length of the associated ATM address field in octets.
底部6位表示一个无符号整数值，以八位字节表示相关ATM地址字段的长度。
The [STL] format is the same as the [NTL] field. Defines the length of the subaddress field, if it exists. If it does not exist this entire octet field MUST be zero. If the subaddress exists it will be in AESA format, so flag x SHALL be zero.
[STL]格式与[NTL]字段相同。定义子地址字段的长度（如果存在）。如果不存在，则整个八位字节字段必须为零。如果子地址存在，它将采用AESA格式，因此标志x应为零。
[NBMA Number] is a variable length field containing the ATM address of the Link layer target. It is always present.
[NBMA编号]是一个可变长度字段，包含链路层目标的ATM地址。它总是存在的。
[NBMA Subaddress] is a variable length field containing the ATM subaddress of the Link layer target. It may or may not be present. When it is not, the option ends after the [NBMA Number] (or any additional padding for 8 byte alignment).
[NBMA子地址]是一个可变长度字段，包含链路层目标的ATM子地址。它可能存在，也可能不存在。否则，该选项在[NBMA编号]（或8字节对齐的任何附加填充）后结束。
The octet ordering of the [NBMA Number] and [NBMA Subaddress] fields SHALL be the same as that used in MARS and NHRP control messages.
[NBMA编号]和[NBMA子地址]字段的八位字节顺序应与MARS和NHRP控制消息中使用的八位字节顺序相同。
4.2 UNI 3.0/3.1 signaling issues (SVC mode).
4.2 UNI 3.0/3.1信令问题（SVC模式）。
When an IPv6 node places a call to another IPv6 node, it SHOULD follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs [9] and negotiating MTU. The default IP MTU size on a LL is 9180 bytes as specified in [7].
当一个IPv6节点向另一个IPv6节点发出呼叫时，它应遵循[6]和[7]中的程序，以向UNI 3.0/3.1 SVC[9]发送信号并协商MTU。LL上的默认IP MTU大小为9180字节，如[7]中所述。
Note that while the procedures in [7] still apply to IPv6 over ATM, IPv6 Path MTU Discovery [8] is used by nodes and routers rather than IPv4 MTU discovery. Additionally, while IPv6 nodes are not required to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it. Also, since IPv6 nodes will negotiate an appropriate MTU for each VC, Path MTU should never be triggered since neither node should ever receive a Packet Too Big message to trigger Path MTU Discovery. When nodes are communicating via one or more routers Path MTU Discovery will be used just as it is for legacy networks.
请注意，虽然[7]中的过程仍然适用于ATM上的IPv6，但节点和路由器使用IPv6路径MTU发现[8]，而不是IPv4 MTU发现。此外，虽然IPv6节点不需要实现路径MTU发现，但IPv6/ATM节点应该实现它。此外，由于IPv6节点将为每个VC协商一个适当的MTU，因此决不应触发路径MTU，因为两个节点都不应收到过大的数据包消息以触发路径MTU发现。当节点通过一个或多个路由器进行通信时，MTU发现路径将与传统网络一样使用。
5 Interface Tokens
5接口令牌
For both PVC and SVC modes of operation, one of the following methods SHALL be used to generate Interface Tokens as required by section 5.1 of [1].
对于PVC和SVC操作模式，应使用以下方法之一生成[1]第5.1节要求的接口令牌。
When the underlying ATM interface is identified by an ATM End System Address (AESA, formerly known as an NSAPA), the interface token MAY be formed from the ESI and SEL values in the AESA as follows:
当底层ATM接口由ATM终端系统地址（AESA，以前称为NSAPA）标识时，接口令牌可由AESA中的ESI和SEL值形成，如下所示：
[0x00][ESI][SEL]
[0x00][ESI][SEL]
[0x00] is a one octet field which is always set to 0. Note that the bit corresponding to the EUI-64 Global/Local bit [5] is always reset indicating that this address is not a globally unique IPv6 interface token.
[0x00]是一个始终设置为0的八位字节字段。请注意，与EUI-64全局/本地位[5]相对应的位始终被重置，这表明该地址不是全局唯一的IPv6接口令牌。
[ESI] is a six octet field. This field always contains the six octet ESI value for the AESA used to address the specific instance of the IPv6/ATM interface.
[ESI]是一个六个八位组的字段。此字段始终包含AESA的六个八位ESI值，用于寻址IPv6/ATM接口的特定实例。
[SEL] is a one octet field. This field always contains the SEL value from the AESA used to address the specific instance of the IPv6/ATM interface.
[SEL]是一个八位组字段。此字段始终包含AESA中用于寻址IPv6/ATM接口特定实例的SEL值。
Where the underlying ATM NIC driver has access to a set of one or more 48 bit MAC values unique to the ATM NIC (e.g. MAC addresses configured into the NIC's ROM), the IPv6/ATM interface MAY use one of these values to create a unique interface token as described in [10].
如果基础ATM NIC驱动程序可以访问一组ATM NIC独有的一个或多个48位MAC值（例如，配置到NIC ROM中的MAC地址），IPv6/ATM接口可以使用这些值中的一个来创建唯一的接口令牌，如[10]所述。
Where the underlying ATM NIC driver has access to a set of one or more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64 addresses configured into the NIC's ROM), the IPv6/ATM interface SHOULD use one of these values to create a unique interface token. after inverting the Global/Local identifier bit [10]. (Any relationship between these values and the ESI(s) registered with the local ATM switch by the ATM driver are outside the scope of this document.)
如果基础ATM NIC驱动程序可以访问ATM NIC独有的一组或多个64位EUI-64值（例如配置到NIC ROM中的EUI-64地址），IPv6/ATM接口应使用这些值之一创建唯一的接口令牌。在反转全局/本地标识符位[10]之后。（这些值与ATM驱动程序在本地ATM交换机上注册的ESI之间的任何关系不在本文件范围内。）
When EUI-64 values are used for IPv6 interface tokens the only modification allowed to the octet string read from the NIC is inversion of the Global/Local identifier bit.
当EUI-64值用于IPv6接口令牌时，唯一允许对从NIC读取的八位字节字符串进行的修改是反转全局/本地标识符位。
When an interface uses Native E.164 addresses then the E.164 values MAY be used to generate an interface token as follows:
当接口使用本机E.164地址时，E.164值可用于生成接口令牌，如下所示：
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
[D14] A single octet containing the semi-octet representing the most significant E.164 digit shifted left four bits to the most significant four bits of the octet. The lower four bits MUST be set to 0. Note that the EUI-64 Global/Local indicator is set to 0 indicating that this is not a globally unique IPv6 interface token.
[D14]包含代表最高有效E.164位的半八位字节的单个八位字节，左移四位至八位字节的最高有效四位。低位四位必须设置为0。请注意，EUI-64全局/本地指示符设置为0，表示这不是全局唯一的IPv6接口令牌。
[D13D12] A single octet containing the semi-octet representing the second most significant E.164 digit [D13] shifted left four places to the most significant bits of the octet, and the third most significant semi-octet in the four least significant bits of the octet.
[D13D12]包含表示第二个最高有效位E.164数字[D13]的半八位字节的单个八位字节左移四位至该八位字节的最高有效位，以及该八位字节的四个最低有效位中的第三个最高有效半八位字节。
[D11D10] - [D1D0] Octets each containing two E.164 digits, one in the most significant four bits, and one in the least significant four bits as indicated.
[D11D10]-[D1D0]八位字节，每个八位字节包含两个E.164数字，一个位于最高有效位的四位，另一个位于最低有效位的四位，如图所示。
If no MAC, EUI-64, AESA, or E.164 value is available for generating an interface token, then the interface token SHALL be generated as described in Appendix A of [10].
如果没有MAC、EUI-64、AESA或E.164值可用于生成接口令牌，则应按照[10]附录A中的说明生成接口令牌。
A logical ATM interface might be associated with a different SEL field of a common AESA prefix, or a set of entirely separate ESIs might have been registered with the local ATM switch to create a range of unique AESAs.
逻辑ATM接口可能与公共AESA前缀的不同SEL字段相关联，或者可能已向本地ATM交换机注册了一组完全独立的ESI，以创建一系列独特的AESA。
The minimum information required to uniquely identify each logical ATM interface is (within the context of the local switch port) their ESI+SEL combination.
唯一标识每个逻辑ATM接口所需的最低信息是（在本地交换机端口的上下文中）它们的ESI+SEL组合。
For the vhost case described in section 5.1.2 of [1], vhost SHALL select a different interface token from the range of 64 bit values available to the ATM NIC (as described in 4.1). Each vhost SHALL implement IPv6/ATM interfaces in such a way that no two or more vhosts end up advertising the same interface token onto the same LL. (Conformance with this requirement may be achieved by choosing different SEL values, ESI values, or both.)
对于[1]第5.1.2节所述的vhost情况，vhost应从ATM NIC可用的64位值范围中选择不同的接口令牌（如4.1所述）。每个虚拟主机应以这样的方式实现IPv6/ATM接口，即不会有两个或多个虚拟主机在同一个LL上公布相同的接口令牌。（可通过选择不同的SEL值、ESI值或两者来实现与本要求的一致性。）
6. Conclusion and Open Issues.
6. 结论和未决问题。
This document is an ATM-specific companion document to the ION working group's, "IPv6 over Non Broadcast Multiple Access (NBMA) networks" specification [1]. It specifies codepoints for the administratively configured PVC, and dynamically established SVC, modes of operation.
本文件是ION工作组“非广播多址（NBMA）网络上的IPv6”规范[1]的ATM专用配套文件。它为管理配置的PVC和动态建立的SVC操作模式指定代码点。
There are no major open issues. Comments to the ION mailing list are solicited (ion@nexen.com).
没有重大未决问题。请对ION邮件列表提出意见(ion@nexen.com).
While this proposal does not introduce any new security mechanisms all current IPv6 security mechanisms will work without modification for ATM. This includes both authentication and encryption for both Neighbor Discovery protocols as well as the exchange of IPv6 data packets.
虽然该提案没有引入任何新的安全机制，但所有当前的IPv6安全机制都可以在不修改ATM的情况下工作。这包括邻居发现协议的身份验证和加密以及IPv6数据包的交换。
Acknowledgments
致谢
The original IPv6/ATM work by G. Armitage occurred while employed at Bellcore. Elements of section 4 were borrowed from Matt Crawford's memo on IPv6 over Ethernet.
G.Armitage最初的IPv6/ATM工作是在受雇于Bellcore时完成的。第4节的内容借鉴了马特·克劳福德关于以太网IPv6的备忘录。
The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho, Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi Hagiwara for their contributions based on actual PVC implementations.
作者要感谢山本和彦、赵健二郎、井上吉诺布、伊崎弘、田崎义文和夏原聪在实际PVC实施基础上所做的贡献。
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 BrightTiger Technologies 125 Nagog Park Acton, MA 01720
Peter Schulter BrightTiger 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
References
工具书类
[1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[1] Armitage，G.，Schulter，P.，Jork，M.和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, July 1993.
[2] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.
[3] Armitage，G.“支持基于UNI 3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[4] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[5] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[5] “64位全局标识符格式教程”，http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[6] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[6] Perez，M.，Liaw，F.，Mankin，A.，Hoffman，E.，Grossman，D.和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, May 1994.
[7] 阿特金森，R.，“通过ATM AAL5使用的默认IP MTU”，RFC 1626，1994年5月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8] McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[9] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995.
[9] ATM论坛，“ATM用户网络接口（UNI）规范3.1版”，ISBN 0-13-393828-X，新泽西州恩格尔伍德悬崖普伦蒂斯大厅，1995年6月。
[10] Hinden, B. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[10] Hinden，B.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[11] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
G. Armitage, et. al. Standards Track [Page 12]
G.Armitage等人标准轨道[第12页]