RFC 3818

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

📅 published June 2004, from ietf

RFC 3818: IANA Considerations for the Point-to-Point Protocol (PPP) 🎀

Network Working Group ✨ This one was written by Vernon Schryver from Rhyolite Software 💖 It's a Best Current Practice (BCP 88) dated June 2004 🌸 The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any earlier RFC 🧚

Status of This Memo 📋

okay so this document is a Best Current Practice for the Internet Community 💅 It's also asking for your discussion and suggestions for improvements 🫶 Distribution is unlimited, so share it with your whole group chat 🦋

Copyright (C) The Internet Society (2004). ✨ Iconic, legally speaking 👑

Abstract 🌈

Okay, the charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes a job to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." 💜 To back that up, the way PPP protocol numbers and other assigned numbers get handed out is changing. They will no longer be "first come first served" 💀

Introduction 🧚‍♀️

So PPP (the Point-to-Point protocol, described in RFC 1661 [1]) is a mature protocol with a ton of subprotocols, encapsulations, and other extensions 🍓 The main protocol and all its extensions involve lots of name spaces where values have to be assigned 🔥 You can find a list of those address spaces and their current assignments at http://www.iana.org/assignments/ppp-numbers 🙈

Historically, the starting values in new name spaces were often picked inside the RFCs that created them 🌷 After that, IANA handed out assignments on a "First Come First Served" basis. This memo changes that policy for some PPP address spaces ✨

Most of the PPP name spaces are quiet these days, but a few keep attracting new extension proposals 🦋 PPP extensions have also been defined in RFCs marked "Informational," which means they aren't subject to review 😭 Those extensions usually need values from one or more of the PPP name spaces. Making those allocations require "IETF Consensus," so every proposal actually gets reviewed 💅

Terminology 📖

The terms "name space", "assigned value", and "registration" mean what BCP 26 [2] defines them to mean 💜 The "First Come First Served" and "IETF Consensus" policies also carry the meanings BCP 26 gives them 🌈

IANA Considerations for PPP 🎀

Here's the deal: IETF Consensus, usually handled through the Point-to-Point Protocol Extensions working group (pppext), is needed to assign new values in the address spaces below 👑

            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 🔐

😱 Plot twist: this memo deals with matters of process, not protocol. So there's no protocol-level security story here, but the process is still very serious business 💀

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. 🌸

Author's Address 💌

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

EMail: vjs@rhyolite.com 🦋

Copyright (C) The Internet Society (2004). ✨ This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 👑

⚠️ This document and the information in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or in scope, or on whether any license under those rights is available 🙈 It also doesn't claim to have independently searched for such rights 💅 Info on how rights work for RFC documents is in BCP 78 and BCP 79 🌷

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of attempts to get a general license or permission to use those proprietary rights for implementers or users of this specification can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🫶

The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🧚

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 💖 Thank you, Internet Society, you're the real MVP 👑

📦 where this page comes from