From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3818.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc3818.txt (limited to 'doc/rfc/rfc3818.txt') diff --git a/doc/rfc/rfc3818.txt b/doc/rfc/rfc3818.txt new file mode 100644 index 0000000..cfc98dd --- /dev/null +++ b/doc/rfc/rfc3818.txt @@ -0,0 +1,227 @@ + + + + + + +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) + +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 2004 + + +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. + +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 Types + +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. + + [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 2004 + + +Author's Address + + Vernon Schryver + Rhyolite Software + 2482 Lee Hill Drive + Boulder, Colorado 80302 + + EMail: vjs@rhyolite.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schryver Best Current Practice [Page 3] + +RFC 3818 IANA Considerations for PPP June 2004 + + +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. + + 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. + + 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. + + 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] + -- cgit v1.2.3