ietf-corpus

rfc-3575

IANA Considerations for RADIUS (Remote Authentication Dial In User Service)

B. Aboba
date2003-07 streamIETF wgnon working group statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc3575 doi10.17487/RFC3575 errataview
This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]

updated by

updates

Extracted elements (17)

design-rationale §2

Attribute Types (range 1-255) are described as the scarcest resource in RADIUS and must be allocated with care. Vendor-Specific extensions (Attribute 26) should be used for vendor-specific functions rather than consuming global attribute type space.

radius

design-rationale §Appendix A

Packet Type Codes 40-45 (Disconnect and CoA messages from RFC 3576) are formally allocated here rather than reclaimed, because they were listed in RFC 2882, widely implemented, and in widespread use; their assignments are not reclaimable in practice.

radius

design-rationale §2.1

Type Codes 52-249 should be allocated before using 14-20, 35-39, and 46-49, preserving the latter ranges as a secondary pool. This ordering policy helps avoid fragmentation of the scarce Packet Type Code space.

radius

interoperability-note §2.1

Packet Type Codes 6-10, 12-13, 21-34, and 50-51 have no meaning defined by an IETF RFC but are reserved to avoid interoperability problems with software implementing non-standard RADIUS extensions that are or have been in use on the Internet.

radius

normative-requirement §2.1 REQUIRED

A new RADIUS Packet Type Code requires IESG Approval because a new Packet Type has considerable impact on interoperability. The intention is that any allocation will be accompanied by a published RFC.

radius, registry

normative-requirement §2 REQUIRED

Allocation of new Service-Type attribute (type 6) values requires IETF Consensus, with the intention that any allocation be accompanied by a published RFC. Values 1-16 have already been allocated.

radius, registry

normative-requirement §2 REQUIRED

Attribute Type values 241-255 require Standards Action for allocation, whereas values 192-240 are considered Private Use per RFC 2865.

radius, registry

normative-requirement §2 MAY

For Attribute Types, values 17, 21, 54, 56-59, 89, and 101-191 may be allocated by IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted.

radius, registry

normative-requirement §2.1 REQUIRED

For Designated Expert review, the Expert must post to the AAA WG mailing list for comment, then within 30 days either approve or deny the registration request, notify the list, and inform IANA. A denial must be justified with an explanation and, where possible, suggestions for modification.

radius, registry, process

normative-requirement §2 SHOULD NOT

RADIUS allocations SHOULD NOT be made for purposes unrelated to Authentication, Authorization, or Accounting, since RADIUS is not intended as a general-purpose protocol.

radius

protocol-element §Appendix A

Appendix A lists all RADIUS Packet Type codes: 1=Access-Request, 2=Access-Accept, 3=Access-Reject, 4=Accounting-Request, 5=Accounting-Response, 11=Access-Challenge, 12=Status-Server, 13=Status-Client, 40-42=Disconnect-Request/ACK/NAK, 43-45=CoA-Request/ACK/NAK, among others.

radius

protocol-element §2

RADIUS defines three name spaces requiring IANA registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain attributes). No new IANA registries are created by this document; the existing registry was established by RFC 2865.

radius, registry

protocol-element §2.1

RADIUS Packet Type Codes range from 1 to 253. Codes 254-255 are reserved and unavailable. Codes 250-253 are reserved for Experimental Use. The full list of assigned codes is given in Appendix A.

radius

registry §2

Attribute Values for certain RADIUS attributes (e.g., NAS-Port-Type) are registered via Designated Expert review. Up to 2^32 values per attribute are possible. The Service-Type attribute (6) is an exception: its values require IETF Consensus because they define new modes of RADIUS operation.

radius, registry

registry §2

RFC 3575 updates the RADIUS Packet Type Codes registry created by RFC 2865, formally allocating codes 40-45 (Disconnect-Request/ACK/NAK, CoA-Request/ACK/NAK) from RFC 3576, reserving codes 250-253 for Experimental Use, and reserving 254-255. Codes 1-5 and 11-13 were allocated in RFC 2865.

radius, registry

registry §2

The RADIUS Attribute Types registry covers values 1-255. Attributes 1-53, 55, 60-88, 90-91, 94-100 have been allocated; values 17, 21, 54, 56-59, 89, 101-191 may be allocated by IETF Consensus; 192-240 are Private Use; 241-255 require Standards Action.

radius, registry

security-consideration §4

The security considerations of BCP 26 (RFC 2434) are generally applicable. Security considerations specific to RADIUS are deferred to RFC 2607, RFC 2865, RFC 3162, RFC 3576 (DynAuth), and RFC 2869bis (RADIUS EAP support).

radius, security