Network Working Group J. Carlson
Request for Comments: 3772 Sun Microsystems
Category: Standards Track R. Winslow
L-3 Communications
May 2004
Network Working Group J. Carlson
Request for Comments: 3772 Sun Microsystems
Category: Standards Track R. Winslow
L-3 Communications
May 2004
Point-to-Point Protocol (PPP) Vendor Protocol
点对点协议（PPP）供应商协议
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols.
点到点协议（PPP）定义了链路控制协议（LCP）和用于协商点到点链路上多协议通信量的使用的方法。PPP供应商扩展文档添加了特定于供应商的通用配置选项和代码。本文档扩展了这些功能，以涵盖特定于供应商的网络、身份验证和控制协议。
PPP's [1] Vendor Extensions [3] defines a general-purpose mechanism for the negotiation of various vendor-proprietary options and extensions to the kinds of control messages that may be sent via the Code field.
PPP的[1]供应商扩展[3]定义了一种通用机制，用于协商各种供应商专有选项和可通过代码字段发送的各种控制消息的扩展。
Some implementors may want to define proprietary network and control protocols in addition to the already-described features. While it would be possible for such an implementor to use the existing LCP Vendor-Specific Option to enable the use of the proprietary protocol, this staged negotiation (enable via LCP, then negotiate via some locally-assigned protocol number) suffers from at least three problems:
除了已经描述的特性之外，一些实现者可能还想定义专有网络和控制协议。虽然这样的实施者可以使用现有的LCP供应商特定选项来启用专有协议的使用，但这种分阶段协商（通过LCP启用，然后通过一些本地分配的协议号进行协商）至少存在三个问题：
First, because it would be in LCP, the negotiation of the use of the protocol would begin before identification and authentication of the peer had been done. This complicates the security analysis of the feature and constrains the way in which the protocol might be deployed.
首先，因为它将在LCP中，协议使用的协商将在对等方的识别和认证完成之前开始。这使功能的安全性分析复杂化，并限制了协议的部署方式。
Second, where compulsory tunneling is in use, the system performing the initial LCP negotiation may be unrelated to the system that uses the proprietary protocol. In such a scenario, enabling the protocol at LCP time would require either LCP renegotiation or support of the proprietary protocol in the initial negotiator, both of which raise deployment problems.
其次，在使用强制隧道的情况下，执行初始LCP协商的系统可能与使用专有协议的系统无关。在这种情况下，在LCP时间启用协议需要LCP重新协商或初始谈判者对专有协议的支持，这两者都会带来部署问题。
Third, the fact that any protocol negotiated via such a mechanism would necessarily use a protocol number that is not assigned by IANA complicates matters for diagnostic tools used to monitor the datastream. Having a fixed number allows these tools to display such protocols in a reasonable, albeit limited, format.
第三，通过这种机制协商的任何协议都必须使用IANA未分配的协议编号，这一事实使用于监控数据流的诊断工具的问题变得复杂。拥有一个固定的数字可以让这些工具以一种合理但有限的格式显示这些协议。
A cleaner solution is thus to define a set of vendor-specific protocols, one in each of the four protocol number ranges defined by [1]. This specification reserves the following values:
因此，更简洁的解决方案是定义一组特定于供应商的协议，在[1]定义的四个协议编号范围中各一个。本规范保留以下值：
Value (in hex) Protocol Name 005b Vendor-Specific Network Protocol (VSNP) 405b Vendor-Specific Protocol (VSP) 805b Vendor-Specific Network Control Protocol (VSNCP) c05b Vendor-Specific Authentication Protocol (VSAP)
值（十六进制）协议名称005b供应商特定网络协议（VSNP）405b供应商特定协议（VSP）805b供应商特定网络控制协议（VSNCP）c05b供应商特定身份验证协议（VSAP）
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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
The Vendor-Specific Network Control Protocol (VSNCP) is responsible for negotiating the use of the Vendor-Specific Network Protocol (VSNP). VSNCP uses the same packet exchange and option negotiation mechanism as LCP, but with a different set of options.
供应商特定网络控制协议（VSNCP）负责协商供应商特定网络协议（VSNP）的使用。VSNCP使用与LCP相同的数据包交换和选项协商机制，但具有不同的选项集。
VSNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any VSNCP packets received when not in that phase MUST be silently ignored. If a VSNCP packet with an unrecognized OUI is received, an LCP Protocol-Reject SHOULD be sent in response.
在PPP达到网络层协议阶段之前，不得交换VSNCP数据包。当不在该阶段时接收到的任何VSNCP数据包都必须被静默忽略。如果接收到带有无法识别OUI的VSNCP数据包，则应发送LCP协议拒绝响应。
The network layer data, carried in VSNP packets, MUST NOT be sent unless VSNCP is in Opened state. If a VSNP packet is received when VSNCP is not in Opened state and LCP is Opened, the implementation MAY respond using LCP Protocol-Reject.
除非VSNCP处于打开状态，否则不得发送VSNP数据包中携带的网络层数据。如果在VSNCP未处于打开状态且LCP已打开时接收到VSNP数据包，则实现可使用LCP协议Reject进行响应。
Exactly one VSNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805b (VSNCP). A summary of the VSNCP packet format is shown below. The fields are transmitted from left to right.
PPP信息字段中仅携带一个VSNCP数据包，PPP协议字段设置为十六进制805b（VSNCP）。VSNCP数据包格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
Only LCP Code values 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a VSNCP Code-Reject reply.
仅使用LCP代码值1到7（配置请求、配置确认、配置Nak、配置拒绝、终止请求、终止确认和代码拒绝）。所有其他代码都应产生VSNCP代码拒绝回复。
Identifier and Length
标识符和长度
These are as documented for LCP.
这些是为LCP记录的。
OUI
是的
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
此三个八位字节字段包含供应商的组织唯一标识符。八位字节中的位按规范顺序排列，最重要的八位字节首先传输。有关OUI值的更多信息，请参见下文第5节。
Data
数据
This field contains data in the same format as for the corresponding LCP Code numbers.
此字段包含与相应LCP代码相同格式的数据。
When VSNCP is in Opened state, VSNP packets may be sent by setting the PPP Protocol field to hex 005b (VSNP) and placing the vendor-specific data in the PPP Information field. No restrictions are placed on this data.
当VSNCP处于打开状态时，可以通过将PPP协议字段设置为十六进制005b（VSNP）并将特定于供应商的数据放置在PPP信息字段中来发送VSNP数据包。此数据不受任何限制。
The Vendor-Specific Protocol (VSP) is intended for use in situations where the implementation of a complete Network Layer Protocol is unnecessary, or where per-link signaling is required (see Section 7 below).
供应商特定协议（VSP）旨在用于不需要实施完整的网络层协议的情况，或需要每条链路信令的情况（见下文第7节）。
VSP packets MUST NOT be sent until PPP has reached either Network-Layer Protocol or Authentication phase. VSP packets received before those phases MUST be silently ignored. Once the proper phase has been reached, a VSP packet containing an unrecognized OUI value SHOULD be returned using LCP Protocol-Reject.
在PPP达到网络层协议或身份验证阶段之前，不得发送VSP数据包。在这些阶段之前收到的VSP数据包必须被静默忽略。一旦到达正确的阶段，应使用LCP协议Reject返回包含未识别OUI值的VSP数据包。
Exactly one VSP packet is carried in the PPP Information field, with the PPP Protocol field set to 405b (VSP). A summary of the VSP packet format is shown below. The fields are transmitted from left to right.
PPP信息字段中正好携带一个VSP数据包，PPP协议字段设置为405b（VSP）。VSP数据包格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+
Magic-Number
幻数
The four-octet Magic-Number field is used to detect looped-back links. If the Magic-Number Option was not negotiated by LCP, then this field MUST be set to 0. Implementation of the LCP Magic-Number Option is RECOMMENDED.
四个八位组幻数字段用于检测环回链路。如果LCP未协商幻数选项，则此字段必须设置为0。建议实施LCP幻数选项。
OUI
是的
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
此三个八位字节字段包含供应商的组织唯一标识符。八位字节中的位按规范顺序排列，最重要的八位字节首先传输。有关OUI值的更多信息，请参见下文第5节。
Reserved
含蓄的
Reserved for future definition. Must be zero on transmit and ignored on reception.
保留供将来定义。发射时必须为零，接收时忽略。
Data
数据
Vendor-specific data.
供应商特定数据。
The Vendor-Specific Authentication Protocol (VSAP) is used in two ways. First, it is used with the LCP Authentication Option in order to negotiate the use of a vendor-specific authentication protocol to be used during the PPP Authentication phase. Second, it is used in the PPP Protocol field to carry those proprietary authentication messages during the PPP Authentication phase.
供应商特定身份验证协议（VSAP）有两种使用方式。首先，它与LCP身份验证选项一起使用，以便协商在PPP身份验证阶段使用的供应商特定身份验证协议的使用。其次，它在PPP协议字段中用于在PPP身份验证阶段传输这些专有身份验证消息。
This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject messages.
此选项用于LCP配置请求、-Ack、-Nak和-Reject消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
3
3.
Length
长
>=7
>=7
Authentication-Protocol
认证协议
The hex value c05b, in Network Byte Order.
十六进制值c05b，按网络字节顺序。
OUI
是的
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
此三个八位字节字段包含供应商的组织唯一标识符。八位字节中的位按规范顺序排列，最重要的八位字节首先传输。有关OUI值的更多信息，请参见下文第5节。
Data
数据
This optional field contains options or other information specific to the operation of the vendor-specific authentication protocol.
此可选字段包含特定于供应商身份验证协议操作的选项或其他信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
The Identifier and Length fields are as for LCP. The Code and Data fields and the processing of the messages are defined by the vendor-specific protocol.
标识符和长度字段与LCP相同。代码和数据字段以及消息处理由供应商特定协议定义。
However, it is RECOMMENDED that vendor-specific protocols use Code 3 for "Success" and Code 4 for "Failure," as with [4] and [5], in order to simplify the design of network monitoring equipment.
但是，建议供应商特定协议使用代码3表示“成功”，使用代码4表示“失败”，如[4]和[5]，以简化网络监控设备的设计。
The three-octet Organizationally Unique Identifier (OUI) used in the messages described in this document identifies an organization ("vendor") that defines the meaning of the message. This OUI is based on IEEE 802 vendor assignments.
本文件所述信息中使用的三个八位字节组织唯一标识符（OUI）标识了定义信息含义的组织（“供应商”）。此OUI基于IEEE 802供应商分配。
Vendors that desire to use their IEEE 802 OUI for a PPP Vendor Protocol SHOULD also register the assigned OUI with IANA for the benefit of the community.
为了社区的利益，希望将其IEEE 802 OUI用于PPP供应商协议的供应商也应向IANA注册分配的OUI。
A vendor that does not otherwise need an IEEE-assigned OUI can request a PPP-specific OUI from the IANA. This OUI shall be assigned from the CF0000 series. This procedure is defined for vendors that are not able to use IEEE assignments, such as software-only vendors.
不需要IEEE指定OUI的供应商可以从IANA请求PPP特定OUI。该OUI应从CF0000系列中分配。本程序适用于不能使用IEEE分配的供应商，如仅软件供应商。
Vendors are encouraged to define their protocols to allow for future expansion, where necessary. For example, it may be appropriate for a VSNP to include a locally-defined selector field to distinguish among multiple proprietary protocols carried via this mechanism, and appropriate Configuration Options in VSNCP to enable and disable these sub-protocols. Because the requirements of such a selector are known only to the vendor defining such protocols, they are not described further in this document.
鼓励供应商定义其协议，以便在必要时进行未来扩展。例如，VSNP可能适合包括本地定义的选择器字段以区分通过该机制携带的多个专有协议，以及VSNCP中的适当配置选项以启用和禁用这些子协议。由于此类选择器的要求仅为定义此类协议的供应商所知，因此在本文件中不作进一步描述。
An implementation MAY also support more than one vendor-specific protocol, distinguished by OUI. In this case, the implementation MUST also treat LCP Protocol-Reject specially by examining the OUI field in the rejected message and disabling only the protocol to which it refers, rather than all use of the vendor-specific protocol number. Note that such an implementation is compatible with a simple implementation that supports only one OUI: that implementation will respond with LCP Protocol-Reject for unrecognized OUIs and otherwise leave the negotiation state unmodified.
一个实现还可以支持多个特定于供应商的协议，以OUI区分。在这种情况下，实现还必须通过检查被拒绝消息中的OUI字段并仅禁用它所引用的协议，而不是所有使用供应商特定协议号的方式，特别处理LCP协议拒绝。请注意，这样的实现与仅支持一个OUI的简单实现兼容：该实现将对未识别的OUI使用LCP协议Reject进行响应，否则将保持协商状态不变。
An OUI-distinguished mechanism is expected to be used only in the case of cooperating vendors. Vendors are encouraged to use just a single OUI for all protocols defined by that vendor, if possible.
预期仅在合作供应商的情况下使用OUI区分机制。如果可能，鼓励供应商对该供应商定义的所有协议仅使用一个OUI。
The Vendor-Specific Network Protocol (VSNP) is defined to operate at the bundle level if Multilink PPP [6] is in use, and also above any Compression Protocols [7] and Encryption Protocols [8] in use.
供应商特定网络协议（VSNP）被定义为在使用多链路PPP[6]的情况下在捆绑包级别运行，也高于使用的任何压缩协议[7]和加密协议[8]。
The Vendor-Specific Protocol (VSP) is defined to operate at the per-link level if Multilink PPP is in use, and MUST NOT be subjected to data compression. If a per-link encryption protocol is in use, then VSP packets MUST be encrypted.
供应商特定协议（VSP）被定义为在使用多链路PPP的情况下在每链路级别运行，并且不得进行数据压缩。如果使用每链路加密协议，则必须对VSP数据包进行加密。
Note that because VSP is defined at the per-link level, bundle level encryption does not affect VSP.
请注意，由于VSP是在每链路级别定义的，因此捆绑包级别的加密不会影响VSP。
The security of any vendor-specific authentication protocol is subject to the provisions of that proprietary mechanism. Implementations that wish to avoid security problems associated with such protocols SHOULD send LCP Configure-Nak in response to an LCP Configure-Request specifying VSAP, or MAY terminate operation.
任何特定于供应商的认证协议的安全性受该专有机制规定的约束。希望避免与此类协议相关的安全问题的实现应发送LCP Configure Nak以响应指定VSAP的LCP Configure请求，或者可以终止操作。
When operating with PPP encryption, but without Multilink PPP, VSP packets are sent in the clear. Implementations that require PPP encryption as part of a security mechanism should consider whether to employ per-link encryption or forego use of VSP in favor of VSNP.
当使用PPP加密但不使用多链路PPP时，VSP数据包以明文形式发送。实现PPP加密作为安全机制的一部分的实现应该考虑是使用每个链路加密还是放弃使用VSP来支持VSNP。
The security of vendor-specific networking protocols is likewise subject to the security mechanisms defined by those protocols. Independent analysis of the security of any such protocol is RECOMMENDED.
供应商特定网络协议的安全性同样受到这些协议定义的安全机制的约束。建议对任何此类协议的安全性进行独立分析。
IANA has assigned four similarly-numbered PPP Protocol field values, 005b, 405b, 805b, and c05b, as described in Section 1 of this document.
IANA分配了四个类似编号的PPP协议字段值005b、405b、805b和c05b，如本文件第1节所述。
As described in Section 5 above and in [3], the IANA also maintains a CF0000 series block of non-IEEE OUIs that may be allocated for vendors that do not otherwise need an IEEE-assigned OUI.
如上文第5节和[3]中所述，IANA还维护非IEEE OUI的CF0000系列块，可分配给不需要IEEE分配OUI的供应商。
[1] Simpson, W., Ed., "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] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[3] 辛普森W，“PPP供应商扩展”，RFC 2153，1997年5月。
[4] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[4] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[6] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[6] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[7] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[7] Rand，D.，“PPP压缩控制协议（CCP）”，RFC 1962，1996年6月。
[8] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[8] Meyer，G.，“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
The authors thank Karl Fox and Thomas Narten for their comments and help in preparing this document.
作者感谢Karl Fox和Thomas Narten在编写本文件过程中的评论和帮助。
Some of the language and phrasing has been borrowed from RFC 1332, written by Glenn McGregor, and RFC 2153, written by William Allen Simpson.
有些语言和措辞是从格伦·麦克格雷戈（Glenn McGregor）编写的RFC 1332和威廉·艾伦·辛普森（William Allen Simpson）编写的RFC 2153中借用的。
Questions about this document should be addressed to the IETF pppext working group or the authors listed below.
有关本文件的问题应提交给IETF pppext工作组或下列作者。
James Carlson Sun Microsystems 1 Network Drive MS UBUR02-212 Burlington MA 01803-2757
James Carlson Sun Microsystems 1网络驱动器MS UBUR02-212马萨诸塞州伯灵顿01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Richard Winslow L-3 Communications Systems - East 1 Federal Street A&E-2NE Camden, NJ 08102
Richard Winslow L-3通信系统-新泽西州卡姆登联邦大街东1号A&E-2NE 08102
EMail: richard.winslow@l-3com.com
EMail: richard.winslow@l-3com.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。