RFC 4603

RFC 4603: Additional Values for the NAS-Port-Type Attribute ✨

Okay bestie, this is RFC 4603, and it's giving tiny but mighty 🎀. It's from the Network Working Group and was written by Glen Zorn, Greg Weber, and Rich Foltak, all from Cisco Systems. It's Informational 🌸 and it's dated July 2006. The title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 💅.

---

Status of This Memo

This memo gives info to the Internet community 💜. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2006) 🦋.

IESG Note

Okay, this part is important, so read it closely 👀. This RFC is not a candidate for any level of Internet Standard. The IETF doesn't vouch for how fit it is for any purpose, and it especially doesn't claim the decision to publish was based on IETF review of things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor chose to publish it at their own discretion. So readers should be careful about how much they lean on it for implementation and deployment. See RFC 3932 for more info ⚠️.

Abstract

This document defines a set of values for the NAS-Port-Type RADIUS Attribute ✨.

Table of Contents

   1. Introduction ....................................................2
   2. NAS-Port-Type Values ............................................2
   3. IANA Considerations .............................................2
      3.1. Attribute Values ...........................................2
   4. Security Considerations .........................................2
   5. References ......................................................3
      5.1. Normative References .......................................3
      5.2. Informative References .....................................3

---

1. Introduction ✨

So the whole point is that this document adds some new values to the NAS-Port-Type Attribute [RFC2865] 🧚.

2. NAS-Port-Type Values 💅

This document defines new values for the NAS-Port-Type Attribute, and it's only concerned with the following values 🍓:

   30   PPPoA (PPP over ATM [RFC3336])

   31   PPPoEoA (PPP over Ethernet [RFC2516] over ATM)

   32   PPPoEoE (PPP over Ethernet [RFC2516] over Ethernet)

   33   PPPoEoVLAN (PPP over Ethernet [RFC2516] over VLAN)

   34   PPPoEoQinQ (PPP over Ethernet [RFC2516] over IEEE 802.1QinQ)

3. IANA Considerations 🌈

3.1. Attribute Values

Here's the deal: this document is meant to act as a request for IANA to allocate the numbers listed above in the appropriate registry [RADTYP], following the allocation policy given in [RFC3575] 📋.

The values listed have already been implemented by at least one vendor without assignment by IANA 😭. Which is so real.

IANA has registered the numbers listed in Section 2, per this request ✔️.

4. Security Considerations 🔥

This one is short and sweet 💀. This specification neither adds to nor detracts from the security of the RADIUS protocol. It doesn't make RADIUS safer and it doesn't make it sketchier. It just adds the values.

5. References 📚

5.1. Normative References

• [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
• [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.

5.2. Informative References

• [RADTYP] Internet Assigned Numbers Authority, "RADIUS TYPES", November 2005, <http://www.iana.org/assignments/radius-types>.
• [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
• [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 3336, December 2002.

---

Authors' Addresses 🫶

The three of them are all at Cisco, so here's where to find them:

   Glen Zorn
   Cisco Systems
   2901 Third Avenue, Suite 600
   SEA1/5/
   Seattle, WA  98121
   US

   Phone: +1 (425) 344 8113
   EMail: gwz@cisco.com


   Greg Weber
   Cisco Systems
   10850 Murdock Road
   KNV/1/
   Knoxville, TN  37932
   US

   EMail: gdweber@cisco.com


   Rich Foltak
   Cisco Systems
   2200 East President George Bush Turnpike
   RCDN6/4/2
   Richardson, TX  75082
   US

   Phone: +1 (469) 255-6557
   EMail: rfoltak@cisco.com

Full Copyright Statement

Copyright (C) The Internet Society (2006) 🌸.

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, 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, that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether any license under those rights is or isn't available, and it hasn't made any independent effort to find such rights. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses that will be available, or the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF 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 comes from the IETF Administrative Support Activity (IASA). Thank you, IASA 👑.