Network Working Group                                        V. Schryver
Request for Comments: 3818                             Rhyolite Software
BCP: 88                                                        June 2004
Category: Best Current Practice
        
Network Working Group                                        V. Schryver
Request for Comments: 3818                             Rhyolite Software
BCP: 88                                                        June 2004
Category: Best Current Practice

IANA Considerations for the Point-to-Point Protocol (PPP)

IANA对点对点协议（PPP）的考虑

Status of this Memo

本备忘录的状况

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2004).

版权所有（C）互联网协会（2004年）。

Abstract

摘要

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served."

点对点协议（PPP）扩展工作组（pppext）的章程包括“积极推进PPP最有用的扩展到完整标准，同时防止可疑价值的进一步增强”的责任。为了支持该章程，PPP协议和其他分配号码的分配将不再是“先到先得”

Introduction

介绍

The Point-to-Point protocol (PPP, RFC 1661 [1]) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The main protocol as well as its extensions involve many name spaces in which values must be assigned. http://www.iana.org/assignments/ppp-numbers contains a list of the address spaces and their current assignments.

点对点协议（PPP，RFC1661[1]）是一个成熟的协议，有大量的子协议、封装和其他扩展。主协议及其扩展涉及许多名称空间，必须在其中分配值。http://www.iana.org/assignments/ppp-numbers 包含地址空间及其当前分配的列表。

Historically, initial values in new name spaces have often been chosen in the RFCs creating the name spaces. The IANA made subsequent assignments with a "First Come First Served" policy. This memo changes that policy for some PPP address spaces.

历史上，在创建名称空间的RFC中，通常会选择新名称空间中的初始值。IANA随后按照“先到先得”的政策进行分配。此备忘录更改了某些PPP地址空间的策略。

Most of the PPP names spaces are quiescent, but some continue to attract proposed extensions. Extensions of PPP have been defined in RFCs that are "Informational" and so are not subject to review. These extensions usually require values assigned in one or more of the PPP name spaces. Making these allocations require "IETF Consensus" will ensure that proposals are reviewed.

大多数PPP名称空间都是静态的，但一些仍然吸引着提议的扩展。PPP的扩展已在RFC中定义，RFC是“信息性”的，因此无需审查。这些扩展通常需要在一个或多个PPP名称空间中指定值。这些分配需要“IETF共识”，这将确保提案得到审查。

Terminology

术语

The terms "name space", "assigned value", and "registration" are used here with the meanings defined in BCP 26 [2]. The policies "First Come First Served" and "IETF Consensus" used here also have the meanings defined in BCP 26.

此处使用术语“名称空间”、“指定值”和“注册”，其含义见BCP 26[2]。此处使用的政策“先到先得”和“IETF共识”也具有BCP 26中定义的含义。

IANA Considerations for PPP

IANA对PPP的考虑

IETF Consensus, usually through the Point-to-Point Protocol Extensions working group (pppext), is required for assigning new values in the following address spaces:

通常通过点对点协议扩展工作组（pppext）达成IETF共识，以便在以下地址空间中分配新值：

PPP DLL PROTOCOL NUMBERS PPP LCP AND IPCP CODES PPP LCP CONFIGURATION OPTION TYPES PPP CCP CONFIGURATION OPTION TYPES PPP CHAP AUTHENTICATION ALGORITHMS PPP LCP FCS-ALTERNATIVES PPP MULTILINK ENDPOINT DISCRIMINATOR CLASS PPP LCP CALLBACK OPERATION FIELDS PPP BRIDGING CONFIGURATION OPTION TYPES PPP BRIDGING MAC TYPES PPP BRIDGING SPANNING TREE PPP IPCP CONFIGURATION OPTION TYPES PPP IPV6CP CONFIGURATION OPTIONS PPP IP-Compression-Protocol Types

PPP DLL协议编号PPP LCP和IPCP代码PPP LCP配置选项类型PPP CCP配置选项类型PPP CHAP身份验证算法PPP LCP FCS-Alternations PPP多链路端点鉴别器类PPP LCP回调操作字段PPP桥接配置选项类型PPP桥接MAC类型PPP桥接生成树PPPIPCP配置选项类型PPP IPV6CP配置选项PPP IP压缩协议类型

Security Considerations

安全考虑

This memo deals with matters of process, not protocol.

这份备忘录涉及的是程序问题，而不是礼节问题。

Normative References

规范性引用文件

[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] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[2] Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。

Author's Address

作者地址

Vernon Schryver Rhyolite Software 2482 Lee Hill Drive Boulder, Colorado 80302

Vernon Schryver流纹岩软件2482 Lee Hill Drive Boulder，科罗拉多州80302 

   EMail: vjs@rhyolite.com
        
   EMail: vjs@rhyolite.com

Full Copyright Statement

完整版权声明

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编辑功能的资金目前由互联网协会提供。