Movatterモバイル変換

Network Working Group                                        V. SchryverRequest for Comments: 3818                             Rhyolite SoftwareBCP: 88                                                        June 2004Category: Best Current PracticeIANA Considerations for the Point-to-Point Protocol (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).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."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.   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.   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.Schryver                 Best Current Practice                  [Page 1]

RFC 3818              IANA Considerations for PPP              June 2004Terminology   The terms "name space", "assigned value", and "registration" are used   here with the meanings defined inBCP 26 [2].  The policies "First   Come First Served" and "IETF Consensus" used here also have the   meanings defined inBCP 26.IANA Considerations for 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:                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 TypesSecurity 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.   [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA       Considerations Section in RFCs",BCP 26,RFC 2434, October 1998.Schryver                 Best Current Practice                  [Page 2]

RFC 3818              IANA Considerations for PPP              June 2004Author's Address   Vernon Schryver   Rhyolite Software   2482 Lee Hill Drive   Boulder, Colorado 80302   EMail: vjs@rhyolite.comSchryver                 Best Current Practice                  [Page 3]

RFC 3818              IANA Considerations for PPP              June 2004Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained inBCP 78, and   except as set forth therein, the authors retain all their rights.   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 inBCP 78 andBCP 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 athttp://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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Schryver                 Best Current Practice                  [Page 4]