NAS-Port-Type values: Additional Values for the NAS-Port-Type Attribute
Additions to RADIUS NAS-Port-Type attribute for PPP tunneling methods
Zorn, G., Weber, G., and R. Foltak, "Additional Values for the NAS-Port-Type Attribute", RFC 4603, DOI 10.17487/RFC4603, July 2006, <https://www.rfc-editor.org/info/rfc4603>.
@misc{rfc4603,
series = {Request for Comments},
number = 4603,
howpublished = {RFC 4603},
publisher = {RFC Editor},
doi = {10.17487/RFC4603},
url = {https://www.rfc-editor.org/info/rfc4603},
author = {G. Zorn and G. Weber and R. Foltak},
title = {{Additional Values for the NAS-Port-Type Attribute}},
pagetotal = 5,
year = 2006,
month = jul,
} RFC text
Contents
Network Working Group G. Zorn
Request for Comments: 4603 G. Weber
Category: Informational R. Foltak
Cisco Systems
July 2006
Additional Values for the
NAS-Port-Type Attribute
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.
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
This document defines a set of new values for the NAS-Port-Type
Attribute [RFC2865].
2. NAS-Port-Type Values
This document defines new values for the NAS-Port-Type Attribute.
This specification concerns 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
This document is intended to act as a request for allocation of the
numbers listed by IANA in the appropriate registry [RADTYP],
according to the allocation policy given in [RFC3575].
The values given have already been implemented by at least one vendor
without assignment by IANA.
IANA has registered the numbers listed in Section 2, per this
request.
4. Security Considerations
This specification neither adds to nor detracts from the security of
the RADIUS protocol.
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
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 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 provided by the IETF
Administrative Support Activity (IASA).
AI ELI5
On this page
§1The NAS-Port-Type Attribute
RADIUS is the Remote Authentication Dial-In User Service, a protocol for centralized authentication and accounting on networks. One field RADIUS uses is the NAS-Port-Type attribute, which indicates how a user connected to the network. The existing values described connection methods like dial-up, ISDN, ADSL, and others.
As network technologies evolved, vendors began implementing new connection types—particularly various PPP (Point-to-Point Protocol) tunneling methods—and needed a way to identify them in RADIUS transactions. This RFC formalizes those connection types by assigning them official attribute values.
When you connect to a network server, it wants to know: Did you dial up? Use cable? DSL? This adds new options to that list for newer types of connections.
§2The New Connection Types
The five new NAS-Port-Type values represent different ways to tunnel PPP traffic: PPPoA (PPP over ATM, value 30) uses ATM (Asynchronous Transfer Mode) as the transport. PPPoEoA (value 31) and PPPoEoE (value 32) tunnel PPP over Ethernet, optionally over ATM or over another Ethernet respectively. PPPoEoVLAN (value 33) adds a VLAN (Virtual LAN) layer to the stack, and PPPoEoQinQ (value 34) uses IEEE 802.1QinQ for even more complex network segmentation.
These values were already being used by at least one vendor in deployed systems before this RFC was published, so the document was intended to formalize what was already happening in practice.
The new values describe ways to wrap PPP traffic in different layers: through ATM, Ethernet, VLANs, or other network technologies.
§3Registry Registration
The document serves as a formal request to IANA (Internet Assigned Numbers Authority) to register these new values in the RADIUS types registry. The allocation follows the policy in RFC 3575. Since the values were already implemented and in use, IANA had no choice but to register them retroactively to avoid confusion and ensure consistent implementations across different vendors.
This approach of codifying vendor practice is common in IETF standards work when the horse has already left the barn—registering what is already deployed prevents fragmentation.
The document asks the official authority to write these connection types into the official rulebook, since vendors had already started using them.