Network Working Group L. Mamakos
Request for Comments: 2516 K. Lidl
Category: Informational J. Evarts
UUNET Technologies, Inc.
D. Carrel
D. Simone
RedBack Networks, Inc.
R. Wheeler
RouterWare, Inc.
February 1999
Network Working Group L. Mamakos
Request for Comments: 2516 K. Lidl
Category: Informational J. Evarts
UUNET Technologies, Inc.
D. Carrel
D. Simone
RedBack Networks, Inc.
R. Wheeler
RouterWare, Inc.
February 1999
A Method for Transmitting PPP Over Ethernet (PPPoE)
一种通过以太网（PPPoE）传输PPP的方法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。
This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.
本文档描述了如何通过以太网构建PPP会话和封装PPP数据包。
Applicability
适用性
This specification is intended to provide the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and more. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi-point relationships which are available in Ethernet and other multi-access environments.
本规范旨在提供为PPP定义的设施，如链路控制协议、网络层控制协议、身份验证等。这些功能需要对等点之间的点对点关系，而不是针对以太网和其他多访问环境中可用的多点关系而设计的。
This specification can be used by multiple hosts on a shared, Ethernet to open PPP sessions to multiple destinations via one or more bridging modems. It is intended to be used with broadband remote access technologies that provide a bridged Ethernet topology, when access providers wish to maintain the session abstraction associated with PPP.
此规范可由共享以太网上的多个主机使用，以通过一个或多个桥接调制解调器打开到多个目的地的PPP会话。当接入提供商希望维护与PPP相关的会话抽象时，它打算与提供桥接以太网拓扑的宽带远程接入技术一起使用。
This document describes the PPP Over Ethernet encapsulation that is being deployed by RedBack Networks, RouterWare, UUNET and others.
本文档描述了RedBack Networks、RouterWare、UUNET和其他公司正在部署的PPP Over Ethernet封装。
Modern access technologies are faced with several conflicting goals. It is desirable to connect multiple hosts at a remote site through the same customer premise access device. It is also a goal to provide access control and billing functionality in a manner similar to dial-up services using PPP. In many access technologies, the most cost effective method to attach multiple hosts to the customer premise access device, is via Ethernet. In addition, it is desirable to keep the cost of this device as low as possible while requiring little or no configuration.
现代接入技术面临着几个相互冲突的目标。希望通过同一个客户端访问设备连接远程站点上的多台主机。它的另一个目标是以类似于使用PPP的拨号服务的方式提供访问控制和计费功能。在许多接入技术中，将多台主机连接到客户端接入设备的最经济有效的方法是通过以太网。此外，希望尽可能降低该设备的成本，同时要求很少或不需要配置。
PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts over a simple bridging access device to a remote Access Concentrator. With this model, each host utilizes it's own PPP stack and the user is presented with a familiar user interface. Access control, billing and type of service can be done on a per-user, rather than a per-site, basis.
以太网PPP（PPPoE）提供了通过简单桥接接入设备将主机网络连接到远程接入集中器的能力。在这个模型中，每个主机都使用自己的PPP堆栈，并向用户提供熟悉的用户界面。访问控制、计费和服务类型可以按用户进行，而不是按站点进行。
To provide a point-to-point connection over Ethernet, each PPP session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that provides this.
为了通过以太网提供点对点连接，每个PPP会话必须了解远程对等方的以太网地址，并建立唯一的会话标识符。PPPoE包括一个提供此功能的发现协议。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [2].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[2]中的说明进行解释。
PPPoE has two distinct stages. There is a Discovery stage and a PPP Session stage. When a Host wishes to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. While PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a Host (the client) discovers an Access Concentrator (the server). Based on the network topology, there may be more than one Access Concentrator that the Host can communicate with. The Discovery stage allows the Host to discover all Access Concentrators and then select one. When Discovery completes successfully, both the Host and the selected Access Concentrator have the information they will use to build their point-to-point connection over Ethernet.
PPPoE有两个不同的阶段。有发现阶段和PPP会话阶段。当主机希望启动PPPoE会话时，它必须首先执行发现以识别对等方的以太网MAC地址并建立PPPoE会话ID。虽然PPP定义了对等关系，但发现本质上是一种客户机-服务器关系。在发现过程中，主机（客户端）发现访问集中器（服务器）。根据网络拓扑，主机可以与多个访问集中器通信。发现阶段允许主机发现所有访问集中器，然后选择一个。当发现成功完成时，主机和选定的访问集中器都具有用于通过以太网建立点对点连接的信息。
The Discovery stage remains stateless until a PPP session is established. Once a PPP session is established, both the Host and the Access Concentrator MUST allocate the resources for a PPP virtual interface.
在PPP会话建立之前，发现阶段保持无状态。一旦建立了PPP会话，主机和访问集中器都必须为PPP虚拟接口分配资源。
The following packet formats are defined here. The payload contents will be defined in the Discovery and PPP sections.
这里定义了以下数据包格式。有效负载内容将在发现和PPP部分中定义。
An Ethernet frame is as follows:
以太网帧如下所示：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DESTINATION_ADDR field contains either a unicast Ethernet destination address, or the Ethernet broadcast address (0xffffffff). For Discovery packets, the value is either a unicast or broadcast address as defined in the Discovery section. For PPP session traffic, this field MUST contain the peer's unicast address as determined from the Discovery stage.
DESTINATION_ADDR字段包含单播以太网目标地址或以太网广播地址（0xFFFFFF）。对于发现数据包，该值是发现部分中定义的单播或广播地址。对于PPP会话流量，此字段必须包含从发现阶段确定的对等方单播地址。
The SOURCE_ADDR field MUST contains the Ethernet MAC address of the source device.
SOURCE_ADDR字段必须包含源设备的以太网MAC地址。
The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 (PPP Session Stage).
乙醚类型设置为0x8863（发现阶段）或0x8864（PPP会话阶段）。
The Ethernet payload for PPPoE is as follows:
PPPoE的以太网有效负载如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VER field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
VER字段为四位，对于此版本的PPPoE规范，必须将其设置为0x1。
The TYPE field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
类型字段为四位，对于此版本的PPPoE规范，必须将其设置为0x1。
The CODE field is eight bits and is defined below for the Discovery and PPP Session stages.
代码字段为8位，定义如下，用于发现和PPP会话阶段。
The SESSION_ID field is sixteen bits. It is an unsigned value in network byte order. It's value is defined below for Discovery packets. The value is fixed for a given PPP session and, in fact, defines a PPP session along with the Ethernet SOURCE_ADDR and DESTINATION_ADDR. A value of 0xffff is reserved for future use and MUST NOT be used
会话ID字段为16位。它是网络字节顺序的无符号值。下面为发现数据包定义了它的值。该值对于给定的PPP会话是固定的，事实上，它定义了一个PPP会话以及以太网源地址和目标地址。0xffff值保留供将来使用，不得使用
The LENGTH field is sixteen bits. The value, in network byte order, indicates the length of the PPPoE payload. It does not include the length of the Ethernet or PPPoE headers.
长度字段为16位。该值以网络字节顺序表示PPPoE有效负载的长度。它不包括以太网或PPPoE头的长度。
There are four steps to the Discovery stage. When it completes, both peers know the PPPoE SESSION_ID and the peer's Ethernet address, which together define the PPPoE session uniquely. The steps consist of the Host broadcasting an Initiation packet, one or more Access Concentrators sending Offer packets, the Host sending a unicast Session Request packet and the selected Access Concentrator sending a Confirmation packet. When the Host receives the Confirmation packet, it may proceed to the PPP Session Stage. When the Access Concentrator sends the Confirmation packet, it may proceed to the PPP Session Stage.
发现阶段分为四个步骤。完成后，两个对等方都知道PPPoE会话ID和对等方的以太网地址，这两个地址共同定义了PPPoE会话。这些步骤包括主机广播发起分组、一个或多个接入集中器发送提供分组、主机发送单播会话请求分组和所选接入集中器发送确认分组。当主机接收到确认分组时，它可以进入PPP会话阶段。当接入集中器发送确认分组时，它可以进入PPP会话阶段。
All Discovery Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
所有Discovery Ethernet帧都将Ethernet_TYPE字段设置为值0x8863。
The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type-length-value) construct and is defined as follows:
PPPoE有效负载包含零个或多个标签。标记是TLV（类型长度值）构造，定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TAG_TYPE is a sixteen bit field in network byte order. Appendix A contains a list of all TAG_TYPEs and their TAG_VALUEs.
TAG_TYPE是网络字节顺序的16位字段。附录A包含所有标记类型及其标记值的列表。
TAG_LENGTH is a sixteen bit field. It is an unsigned number in network byte order, indicating the length in octets of the TAG_VALUE.
TAG_长度是一个16位字段。它是一个以网络字节顺序表示的无符号数字，表示标记值的长度（以八位字节为单位）。
If a discovery packet is received with a TAG of unknown TAG_TYPE, the TAG MUST be ignored unless otherwise specified in this document. This provides for backwards compatibility if/when new TAGs are added. If new mandatory TAGs are added, the version number will be incremented.
如果接收到带有未知标签类型标签的发现数据包，除非本文档中另有规定，否则必须忽略该标签。如果/当添加新标记时，这提供了向后兼容性。如果添加了新的强制标记，则版本号将增加。
Some example Discovery packets are shown in Appendix B.
附录B中显示了一些示例发现数据包。
The Host sends the PADI packet with the DESTINATION_ADDR set to the broadcast address. The CODE field is set to 0x09 and the SESSION_ID MUST be set to 0x0000.
主机将目标地址设置为广播地址的PADI数据包发送到广播地址。代码字段设置为0x09，会话ID必须设置为0x0000。
The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types. An entire PADI packet (including the PPPoE header) MUST NOT exceed 1484 octets so as to leave sufficient room for a relay agent to add a Relay-Session-Id TAG.
PADI数据包必须仅包含一个TAG_类型服务名称的标记，表示主机正在请求的服务，以及任何数量的其他标记类型。整个PADI数据包（包括PPPoE报头）不得超过1484个八位字节，以便为中继代理添加中继会话Id标签留出足够的空间。
When the Access Concentrator receives a PADI that it can serve, it replies by sending a PADO packet. The DESTINATION_ADDR is the unicast address of the Host that sent the PADI. The CODE field is set to 0x07 and the SESSION_ID MUST be set to 0x0000.
当接入集中器接收到它可以服务的PADI时，它通过发送PADO数据包进行应答。DESTINATION_ADDR是发送PADI的主机的单播地址。代码字段设置为0x07，会话ID必须设置为0x0000。
The PADO packet MUST contain one AC-Name TAG containing the Access Concentrator's name, a Service-Name TAG identical to the one in the PADI, and any number of other Service-Name TAGs indicating other services that the Access Concentrator offers. If the Access Concentrator can not serve the PADI it MUST NOT respond with a PADO.
PADO数据包必须包含一个包含接入集中器名称的AC名称标签、一个与PADI中的名称标签相同的服务名称标签，以及指示接入集中器提供的其他服务的任意数量的其他服务名称标签。如果访问集中器不能为PADI提供服务，则它不能使用PADO进行响应。
Since the PADI was broadcast, the Host may receive more than one PADO. The Host looks through the PADO packets it receives and chooses one. The choice can be based on the AC-Name or the Services offered. The Host then sends one PADR packet to the Access Concentrator that it has chosen. The DESTINATION_ADDR field is set to the unicast Ethernet address of the Access Concentrator that sent the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be set to 0x0000.
由于PADI已广播，主机可能会收到多个PADO。主机查看它接收的PADO数据包并选择一个。选择可以基于AC名称或提供的服务。然后，主机将一个PADR数据包发送到它选择的访问集中器。DESTINATION_ADDR字段设置为发送PADO的接入集中器的单播以太网地址。代码字段设置为0x19，会话ID必须设置为0x0000。
The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types.
PADR数据包必须仅包含一个TAG_类型服务名称的标记，表示主机正在请求的服务，以及任何数量的其他标记类型。
When the Access Concentrator receives a PADR packet, it prepares to begin a PPP session. It generates a unique SESSION_ID for the PPPoE session and replies to the Host with a PADS packet. The DESTINATION_ADDR field is the unicast Ethernet address of the Host that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID MUST be set to the unique value generated for this PPPoE session.
当接入集中器接收到PADR数据包时，它准备开始PPP会话。它为PPPoE会话生成唯一的会话ID，并使用PADS数据包回复主机。DESTINATION_ADDR字段是发送PADR的主机的单播以太网地址。代码字段设置为0x65，会话ID必须设置为此PPPoE会话生成的唯一值。
The PADS packet contains exactly one TAG of TAG_TYPE Service-Name, indicating the service under which Access Concentrator has accepted the PPPoE session, and any number of other TAG types.
PADS数据包仅包含一个TAG_类型服务名称的标签，表示接入集中器已接受PPPoE会话的服务，以及任何数量的其他标签类型。
If the Access Concentrator does not like the Service-Name in the PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE Service-Name-Error (and any number of other TAG types). In this case the SESSION_ID MUST be set to 0x0000.
如果访问集中器不喜欢PADR中的服务名称，那么它必须使用包含TAG_类型服务名称错误（以及任何数量的其他标记类型）标记的PADS进行回复。在这种情况下，会话ID必须设置为0x0000。
This packet may be sent anytime after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the Host or the Access Concentrator. The DESTINATION_ADDR field is a unicast Ethernet address, the CODE field is set to 0xa7 and the SESSION_ID MUST be set to indicate which session is to be terminated. No TAGs are required.
该分组可在会话建立后随时发送，以指示PPPoE会话已终止。它可以由主机或访问集中器发送。DESTINATION_ADDR字段是一个单播以太网地址，CODE字段设置为0xa7，SESSION_ID必须设置为指示要终止的会话。不需要标签。
When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination packets MUST NOT be sent after sending or receiving a PADT. A PPP peer SHOULD use the PPP protocol itself to bring down a PPPoE session, but the PADT MAY be used when PPP can not be used.
当收到PADT时，不允许使用该会话发送进一步的PPP通信。在发送或接收PADT后，即使是正常的PPP终止数据包也不得发送。PPP对等方应该使用PPP协议本身来关闭PPPoE会话，但是当PPP不能使用时，可以使用PADT。
Once the PPPoE session begins, PPP data is sent as in any other PPP encapsulation. All Ethernet packets are unicast. The ETHER_TYPE field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The SESSION_ID MUST NOT change for that PPPoE session and MUST be the value assigned in the Discovery stage. The PPPoE payload contains a PPP frame. The frame begins with the PPP Protocol-ID.
一旦PPPoE会话开始，PPP数据将像在任何其他PPP封装中一样发送。所有以太网数据包都是单播的。乙醚类型字段设置为0x8864。PPPoE代码必须设置为0x00。该PPPoE会话的会话ID不得更改，并且必须是在发现阶段分配的值。PPPoE有效负载包含PPP帧。该帧以PPP协议ID开始。
An example packet is shown in Appendix B.
附录B中显示了一个示例数据包。
The Magic Number LCP configuration option is RECOMMENDED, and the Protocol Field Compression (PFC) option is NOT RECOMMENDED. An implementation MUST NOT request any of the following options, and MUST reject a request for such an option:
建议使用幻数LCP配置选项，不建议使用协议字段压缩（PFC）选项。实施不得请求以下任何选项，且必须拒绝此类选项的请求：
Field Check Sequence (FCS) Alternatives,
现场检查顺序（FCS）备选方案，
Address-and-Control-Field-Compression (ACFC),
地址和控制字段压缩（ACFC），
Asynchronous-Control-Character-Map (ACCM)
异步控制字符映射（ACCM）
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492.
最大接收单元（MRU）选项不得协商为大于1492的尺寸。由于以太网的最大有效负载大小为1500个八位字节，PPPoE报头为6个八位字节，PPP协议ID为2个八位字节，因此PPP MTU不得大于1492。
It is RECOMMENDED that the Access Concentrator ocassionally send Echo-Request packets to the Host to determine the state of the session. Otherwise, if the Host terminates a session without sending a Terminate-Request packet, the Access Concentrator will not be able to determine that the session has gone away.
建议访问集中器局部地向主机发送回显请求数据包，以确定会话的状态。否则，如果主机在不发送终止请求数据包的情况下终止会话，则访问集中器将无法确定会话已离开。
When LCP terminates, the Host and Access concentrator MUST stop using that PPPoE session. If the Host wishes to start another PPP session, it MUST return to the PPPoE Discovery stage.
当LCP终止时，主机和访问集中器必须停止使用该PPPoE会话。如果主机希望启动另一个PPP会话，则必须返回PPPoE发现阶段。
When a host does not receive a PADO packet within a specified amount of time, it SHOULD resend it's PADI packet and double the waiting period. This is repeated as many times as desired. If the Host is waiting to receive a PADS packet, a similar timeout mechanism SHOULD be used, with the Host re-sending the PADR. After a specified number of retries, the Host SHOULD then resend a PADI packet.
当主机在指定的时间内没有收到PADO数据包时，它应该重新发送它的PADI数据包并将等待时间延长一倍。这将根据需要重复多次。如果主机正在等待接收PADS数据包，则应使用类似的超时机制，主机重新发送PADR。经过指定次数的重试后，主机应重新发送PADI数据包。
The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use of these values and the PPPoE VER (version) field uniquely identify this protocol.
本文件中使用的以太网类型（0x8863和0x8864）已由IEEE分配，供以太网PPP（PPPoE）使用。使用这些值和PPPoE版本字段可唯一标识此协议。
UTF-8 [5] is used throughout this document instead of ASCII. UTF-8 supports the entire ASCII character set while allowing for international character sets as well. See [5] for more details.
本文件中使用UTF-8[5]代替ASCII。UTF-8支持整个ASCII字符集，同时也支持国际字符集。有关更多详细信息，请参见[5]。
To help protect against Denial of Service (DOS) attacks, the Access Concentrator can employ the AC-Cookie TAG. The Access Concentrator SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR SOURCE_ADDR. Using this, the Access Concentrator can ensure that the PADI SOURCE_ADDR is indeed reachable and can then limit concurrent sessions for that address. What algorithm to use is not defined and left as an implementation detail. An example is HMAC [3] over the Host MAC address using a key known only to the Access > Concentrator. While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
为了帮助防止拒绝服务（DOS）攻击，访问集中器可以使用AC Cookie标记。访问集中器应该能够基于PADR SOURCE\u ADDR唯一地重新生成标记值。使用此方法，访问集中器可以确保PADI源地址确实是可访问的，然后可以限制该地址的并发会话。使用哪种算法没有定义，并留作实现细节。例如，HMAC[3]通过主机MAC地址，使用只有Access>集中器知道的密钥。虽然AC-Cookie对某些DOS攻击很有用，但它不能抵御所有DOS攻击，访问集中器可能会使用其他方法来保护资源。
While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
虽然AC-Cookie对某些DOS攻击很有用，但它不能抵御所有DOS攻击，访问集中器可能会使用其他方法来保护资源。
Many Access Concentrators will not wish to offer information regarding what services they offer to an unauthenticated entity. In that case the Access Concentrator should employ one of two policies. It SHOULD never refuse a request based on the Service-Name TAG, and always return the TAG_VALUE that was sent to it. Or it SHOULD only accept requests with a Service-Name TAG with a zero TAG_LENGTH (indicating any service). The former solution is RECOMMENDED.
许多接入集中器不希望向未经认证的实体提供有关其提供的服务的信息。在这种情况下，访问集中器应该采用两种策略之一。它永远不应该拒绝基于服务名称标记的请求，并且总是返回发送给它的标记值。或者，它应该只接受带有零标记长度的服务名称标记的请求（表示任何服务）。建议采用前一种解决方案。
This document is based on concepts discussed in several forums, including the ADSL forum.
本文档基于多个论坛（包括ADSL论坛）中讨论的概念。
Copious amounts of text have been stolen from RFC 1661, RFC 1662 and RFC 2364.
大量的文本从RFC1661、RFC1662和RFC2364中被盗。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1998.
[3] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1998年2月。
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[5] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
TAG_TYPES and TAG_VALUES
标记类型和标记值
0x0000 End-Of-List
0x0000列表末尾
This TAG indicates that there are no further TAGs in the list. The TAG_LENGTH of this TAG MUST always be zero. Use of this TAG is not required, but remains for backwards compatibility.
此标记表示列表中没有其他标记。此标记的标记长度必须始终为零。不需要使用此标记，但仍保留向后兼容性。
0x0101 Service-Name
0x0101服务名称
This TAG indicates that a service name follows. The TAG_VALUE is an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH is zero this TAG is used to indicate that any service is acceptable. Examples of the use of the Service-Name TAG are to indicate an ISP name or a class or quality of service.
此标记表示后面有一个服务名称。TAG_值是一个UTF-8字符串，不以NULL结尾。当标签长度为零时，该标签用于指示任何服务都是可接受的。使用服务名称标签的示例包括指示ISP名称、服务类别或服务质量。
0x0102 AC-Name
0x0102 AC名称
This TAG indicates that a string follows which uniquely identifies this particular Access Concentrator unit from all others. It may be a combination of trademark, model, and serial id information, or simply an UTF-8 rendition of the MAC address of the box. It is not NULL terminated.
此标记表示后面有一个字符串，它唯一地将此特定访问集中器单元与所有其他单元区别开来。它可能是商标、型号和串行id信息的组合，也可能只是盒子MAC地址的UTF-8格式副本。它不是以NULL结尾的。
0x0103 Host-Uniq
0x0103主机Uniq
This TAG is used by a Host to uniquely associate an Access Concentrator response (PADO or PADS) to a particular Host request (PADI or PADR). The TAG_VALUE is binary data of any value and length that the Host chooses. It is not interpreted by the Access Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or PADR. If the Access Concentrator receives this TAG, it MUST include the TAG unmodified in the associated PADO or PADS response.
主机使用此标记将访问集中器响应（PADO或PADS）与特定主机请求（PADI或PADR）唯一关联。TAG_值是主机选择的任意值和长度的二进制数据。它不由访问集中器解释。主机可以在PADI或PADR中包括主机Uniq标签。如果访问集中器接收到该标签，它必须在相关PADO或PADS响应中包含未修改的标签。
0x0104 AC-Cookie
0x0104 AC Cookie
This TAG is used by the Access Concentrator to aid in protecting against denial of service attacks (see the Security Considerations section for an explanation of how this works). The Access Concentrator MAY include this TAG in a PADO packet. If a Host receives this TAG, it MUST return the TAG unmodified in the following PADR. The TAG_VALUE is binary data of any value and length and is not interpreted by the Host.
访问集中器使用此标记来帮助防止拒绝服务攻击（有关如何工作的说明，请参阅安全注意事项部分）。接入集中器可以在PADO分组中包括该标签。如果主机收到此标记，它必须返回未在以下PADR中修改的标记。TAG_值是任何值和长度的二进制数据，不由主机解释。
0x0105 Vendor-Specific
0x0105特定于供应商
This TAG is used to pass vendor proprietary information. The first four octets of the TAG_VALUE contain the vendor id and the remainder is unspecified. The high-order octet of the vendor id is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [4].
此标签用于传递供应商专有信息。TAG_值的前四个八位字节包含供应商id，其余未指定。供应商id的高阶八位字节为0，低阶三位八位字节为供应商的SMI网络管理专用企业代码，按网络字节顺序排列，如分配编号RFC[4]中所定义。
Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, an implementation MAY silently ignore a Vendor-Specific TAG.
不建议使用此标签。为了确保互操作性，实现可以默默地忽略特定于供应商的标记。
0x0110 Relay-Session-Id
0x0110中继会话Id
This TAG MAY be added to any discovery packet by an intermediate agent that is relaying traffic. The TAG_VALUE is opaque to both the Host and the Access Concentrator. If either the Host or Access Concentrator receives this TAG they MUST include it unmodified in any discovery packet they send as a response. All PADI packets MUST guarantee sufficient room for the addition of a Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.
该标签可由中继通信量的中间代理添加到任何发现包中。TAG_值对主机和访问集中器都是不透明的。如果主机或访问集中器接收到此标记，则它们必须将其未经修改地包含在作为响应发送的任何发现数据包中。所有PADI数据包必须保证有足够的空间添加中继会话Id标签，标签长度为12个八位字节。
A Relay-Session-Id TAG MUST NOT be added if the discovery packet already contains one. In that case the intermediate agent SHOULD use the existing Relay-Session-Id TAG. If it can not use the existing TAG or there is insufficient room to add a Relay-Session-Id TAG, then it SHOULD return a Generic-Error TAG to the sender.
如果发现数据包已包含中继会话Id标签，则不得添加中继会话Id标签。在这种情况下，中间代理应该使用现有的中继会话Id标记。如果它不能使用现有标记，或者没有足够的空间添加中继会话Id标记，那么它应该向发送方返回一个通用错误标记。
0x0201 Service-Name-Error
0x0201服务名称错误
This TAG (typically with a zero-length data section) indicates that for one reason or another, the requested Service-Name request could not be honored.
此标记（通常带有零长度数据段）表示由于某种原因，无法满足请求的服务名称请求。
If there is data, and the first octet of the data is nonzero, then it MUST be a printable UTF-8 string which explains why the request was denied. This string MAY NOT be NULL terminated.
如果有数据，并且数据的第一个八位字节非零，那么它必须是一个可打印的UTF-8字符串，这解释了请求被拒绝的原因。此字符串不能以NULL结尾。
0x0202 AC-System-Error
0x0202交流系统错误
This TAG indicates that the Access Concentrator experienced some error in performing the Host request. (For example insufficient resources to create a virtual circuit.) It MAY be included in PADS packets.
此标记表示访问集中器在执行主机请求时遇到一些错误。（例如，资源不足，无法创建虚拟电路。）它可能包含在PADS数据包中。
If there is data, and the first octet of the data is nonzero, then it MUST be a printable UTF-8 string which explains the nature of the error. This string MAY NOT be NULL terminated.
如果有数据，并且数据的第一个八位字节为非零，那么它必须是一个可打印的UTF-8字符串，用于解释错误的性质。此字符串不能以NULL结尾。
0x0203 Generic-Error
0x0203一般错误
This TAG indicates an error. It can be added to PADO, PADR or PADS packets when an unrecoverable error occurs and no other error TAG is appropriate. If there is data then it MUST be an UTF-8 string which explains the nature of the error. This string MUST NOT be NULL terminated.
此标记表示错误。当发生不可恢复的错误且没有其他合适的错误标记时，可以将其添加到PADO、PADR或PADS数据包中。如果有数据，则必须是解释错误性质的UTF-8字符串。此字符串不能以NULL结尾。
The following are some example packets:
以下是一些示例数据包：
A PADI packet:
PADI数据包：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffffffff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffff | Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffffffff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffff | Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADO packet:
PADO数据包：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) | Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x47 | 0x6f | 0x20 | 0x52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x65 | 0x64 | 0x42 | 0x61 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x63 | 0x6b | 0x20 | 0x2d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | 0x65 | 0x73 | 0x68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x73 | 0x68 | 0x65 | 0x73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x68 | 0x6f | 0x6f | 0x74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) | Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x47 | 0x6f | 0x20 | 0x52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x65 | 0x64 | 0x42 | 0x61 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x63 | 0x6b | 0x20 | 0x2d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | 0x65 | 0x73 | 0x68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x73 | 0x68 | 0x65 | 0x73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x68 | 0x6f | 0x6f | 0x74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PPP LCP packet: The PPP protocol value is shown (0xc021) but the PPP payload is left to the reader. This is a packet from the Host to the Access Concentrator.
PPP LCP数据包：显示PPP协议值（0xc021），但PPP有效负载留给读取器。这是从主机到访问集中器的数据包。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x???? |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x???? |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
作者地址
Louis Mamakos UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
美国弗吉尼亚州费尔法克斯威廉姆斯大道3060号路易斯马马科斯UUNET技术有限公司，邮编：22031-4648
EMail: louie@uu.net
EMail: louie@uu.net
Kurt Lidl UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
美国弗吉尼亚州费尔法克斯威廉姆斯大道3060号Kurt Lidl UUNET Technologies，Inc.22031-4648
EMail: lidl@uu.net
EMail: lidl@uu.net
Jeff Evarts UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
美国弗吉尼亚州费尔法克斯威廉姆斯大道3060号Jeff Evarts UUNET Technologies，Inc.22031-4648
EMail: jde@uu.net
EMail: jde@uu.net
David Carrel RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
David Carrel RedBack Networks，Inc.美国加利福尼亚州桑尼维尔莫菲特公园大道1389号，邮编94089-1134
EMail: carrel@RedBack.net
EMail: carrel@RedBack.net
Dan Simone RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
Dan Simone RedBack Networks，Inc.美国加利福尼亚州桑尼维尔莫菲特公园大道1389号，邮编94089-1134
EMail:dan@RedBack.net
电邮：dan@RedBack.net
Ross Wheeler RouterWare, Inc. 3961 MacArthur Blvd., Suite 212 Newport Beach, CA 92660 United States of America
美国加利福尼亚州纽波特海滩麦克阿瑟大道3961号，212室，罗斯·惠勒·罗特瓦有限公司，邮编92660
EMail: ross@routerware.com
EMail: ross@routerware.com
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。