RADIUS attributes are the data fields inside a RADIUS packet. They identify the subscriber and the session, describe the network access server (NAS), and tell it what to deliver: an IP address, a filter, a bandwidth limit, a timeout. IANA assigns each attribute a number, and attribute 26 lets vendors add their own.
Most pages on RADIUS attributes give you a numbered dictionary and stop. This one is organized by the job each attribute does, because that’s how you meet them in a capture: identify, authorize, shape, or account. The RADIUS packet format is covered separately.
After the fixed header, everything in the packet is attributes, each a type, a length, and a value. Attribute 26 nests a vendor sub-attribute inside its value field.
RADIUS attribute reference table
These twelve RADIUS attributes cover most of what you will see in an Access-Request, Access-Accept, or Accounting-Request. Numbers and data types follow the IANA RADIUS Attribute Types registry; base definitions are in RFC 2865 and the accounting set in RFC 2866.
| Number | Attribute | Data type | Purpose |
| 1 | User-Name | text | Identity being authenticated |
| 4 | NAS-IP-Address | ipv4addr | IPv4 address of the requesting NAS |
| 5 | NAS-Port | integer | Port on the NAS carrying the session |
| 8 | Framed-IP-Address | ipv4addr | IPv4 address assigned to the session |
| 11 | Filter-Id | text | Name of a filter list on the NAS |
| 25 | Class | string | Opaque value echoed back in accounting |
| 26 | Vendor-Specific | vsa | Container for vendor-defined sub-attributes |
| 27 | Session-Timeout | integer | Maximum session length, in seconds |
| 28 | Idle-Timeout | integer | Idle seconds allowed before disconnect |
| 31 | Calling-Station-Id | text | Subscriber endpoint, often a MAC or number |
| 44 | Acct-Session-Id | text | Unique identifier for one session |
| 61 | NAS-Port-Type | enum | Access technology behind the port |
Searches for “RADIUS attribute types” mix up two things. The type is the one-byte number in the first column. The data type in the third column is how the value is encoded. Diameter calls its fields AVPs, but the two protocols aren’t wire-compatible, so a Diameter dictionary won’t help you here.
Attributes that identify a session
Four RADIUS attributes do most of the work of telling one subscriber session apart from millions of others: Acct-Session-Id, NAS-IP-Address, User-Name, and Class. Session IDs are unique only per NAS, so RFC 2865 requires NAS-IP-Address (4) or NAS-Identifier (32) in every Access-Request.
1. Acct-Session-Id (44)
Acct-Session-Id follows a session from start to finish. The NAS generates it, and RFC 2866 requires the same value in every Accounting-Request for that session, so Start, Interim-Update, and Stop records line up.
2. User-Name (1)
User-Name carries whatever identity the subscriber presented: a PPPoE login, an outer EAP identity, a MAC address on open Wi-Fi, or an IMSI-derived NAI. It is the most readable key and the least reliable one, since one account can hold several sessions.
3. Class (25)
Class is an opaque string the server places in the Access-Accept and the NAS echoes, unchanged, in every accounting packet. The NAS never interprets it, which makes it the server’s own correlation handle: a policy name, a plan ID, or a session-store pointer. Months later, Class in the RADIUS accounting records, RADIUS Accounting Explained, is where that answer survives.
NAS-Port and NAS-Port-Type
NAS-Port says which port a subscriber came in on; NAS-Port-Type says what kind of port it is. They are the two most-searched individual attributes and the two most often misread, because a 1997 dial-up server and a BNG use them differently.
1. NAS-Port (5)
NAS-Port is a 32-bit integer identifying the physical or logical port carrying the session. On a modem bank it was the modem number. On a modern access router it is whatever the vendor packs into those bits, usually slot, port, and VLAN or session index. The encoding is per NAS model, so never compare values across vendors. For a readable form, the NAS sends NAS-Port-Id (87) as text, usually the circuit identifier.
2. NAS-Port-Type (61)
NAS-Port-Type is an enumerated value describing the access technology, and the AAA server uses it to pick the authentication method and policy: 19 means a Wi-Fi client that will probably speak EAP, 15 an Ethernet port likely doing MAC authentication. These are the values you will meet in a service provider network.
| Value | Name | What it means in practice |
| 5 | Virtual | Tunneled or virtual session, no physical port |
| 15 | Ethernet | Wired Ethernet, including IPoE and 802.1X |
| 16 | xDSL | DSL where the exact flavor is not reported |
| 17 | Cable | DOCSIS cable modem termination |
| 18 | Wireless – Other | Wireless access that is not 802.11 |
| 19 | Wireless – IEEE 802.11 | Wi-Fi, carrier hotspots, enterprise WLAN |
| 26 | FTTP | Fiber to the premises |
| 32 | PPPoEoE | PPPoE over plain Ethernet |
| 33 | PPPoEoVLAN | PPPoE over a VLAN-tagged interface |
| 35 | xPON | GPON or XGS-PON, common on fiber BNGs |
The full list, past 40 values, is in the IANA registry under “Values for RADIUS Attribute 61.”
Framed-IP-Address and addressing attributes
Framed-IP-Address (8) is the IPv4 address the subscriber session will use. Its meaning depends on direction.
Framed-IP-Address (8)
In an Access-Accept it is an instruction: the AAA server tells the NAS which address to hand the subscriber, which is how static IP add-ons work. In an Accounting-Request it is a report of the address the session actually got. RFC 2865 reserves two values: 255.255.255.255 means let the subscriber negotiate an address, and 255.255.255.254 means assign one from the NAS pool. Either means the server is deliberately declining to choose.
Dual-stack subscribers need more. Framed-IPv6-Prefix (97) carries the link prefix, Framed-IPv6-Address (168) a single address, and Delegated-IPv6-Prefix (123) the prefix a customer router hands out via DHCPv6. They come from RFC 3162, 4818, and 6911, so an older dictionary may not know them.
Authorization and policy attributes
The RADIUS attributes in an Access-Accept are the policy. Authentication answers whether the subscriber is who they claim; the reply attributes decide what they get, with the NAS as the policy enforcement point. The standard set covers framing (Framed-Protocol, 7), filters, and time limits. It has nothing for bandwidth.
1. Filter-Id (11)
Filter-Id applies an access control list to a session and is the attribute behind most “RADIUS ACL” searches. The server sends a name, such as residential-basic, and the NAS looks it up in its own filter lists. The server never sends the rules, so the name must already exist on every NAS that might terminate the session. That makes it a check item for every NAS rollout, and a common reason a subscriber gets full access on one gateway and none on another.
2. Session-Timeout (27) and Idle-Timeout (28)
Session-Timeout is the maximum seconds a session may live before the NAS ends it or, with Termination-Action (29) set to RADIUS-Request, re-authenticates it. Idle-Timeout is the seconds without traffic the NAS tolerates before disconnecting. Hotspots use the first for timed passes. Broadband operators use both to reap sessions whose CPE vanished without sending a Stop.
3. Bandwidth and rate limiting
There is no standard RADIUS attribute for bandwidth. Every vendor defines its own, as a rate-limit string, a pair of integers, or a QoS profile name, and all of them ride inside attribute 26. That is where RADIUS interoperability ends. Changing a rate on a live session is CoA’s job, using the same attributes.
Vendor-specific attributes
A RADIUS VSA (vendor-specific attribute) is any attribute carried inside attribute 26, Vendor-Specific. RFC 2865 reserved that number so equipment makers could define their own RADIUS attributes without asking IANA for space in the 8-bit type field. Nearly every bandwidth profile, service tag, and NAS-specific setting is a VSA.
How a VSA is built
From the outside, attribute 26 looks like any other attribute. The difference is inside the value field.
| Field | Size | Contents |
| Type | 1 byte | Always 26 |
| Length | 1 byte | Total length of the whole attribute, including this header |
| Vendor-Id | 4 bytes | The vendor’s IANA Private Enterprise Number; high byte is 0 |
| Vendor type | 1 byte | The vendor’s own attribute number, 1–255 |
| Vendor length | 1 byte | Length of this sub-attribute |
| Attribute data | up to 247 bytes | The value, in whatever data type the vendor chose |
RFC 2865 recommends this layout but doesn’t require it, and a few vendors use 2-byte or 4-byte vendor type fields. A RADIUS dictionary file turns all of this into names. Dictionaries aren’t part of the protocol, so every AAA platform ships its own, and that’s where migrations go wrong.
What happens when an attribute is not recognized
RFC 2865 lets a server or NAS ignore RADIUS attributes with an unknown type; a proxy usually passes them through. An unknown attribute never causes an Access-Reject on its own. A VSA missing from a dictionary raises no error, is never sent, and the subscriber comes up with no rate limit, service tag, or VLAN. Nothing in the log looks wrong.
Attributes and platform migration
Standard RADIUS attributes move between AAA platforms cleanly. VSAs don’t, which is how a migration can pass every lab test and still degrade service on cutover day. The usual cause is a dictionary that is almost right. A renamed attribute the policy no longer references, a sub-attribute number that changed between NAS firmware releases, a rate limit defined as a string in one dictionary and an integer in the other. None of these raise an error. The second problem is live sessions. Accounting from sessions the old platform authenticated carries Class values the new one has never seen, and that usage is lost.
Mapping VSAs without breaking sessions
Measure the mapping before you configure it.
- Capture a week of production RADIUS traffic and list every attribute and VSA that appears, by Vendor-Id and sub-attribute number.
- Build a mapping table: old name, new name, Vendor-Id, sub-attribute number, data type, units, and an owner per row.
- Load the vendor’s own dictionary files instead of retyping them, and diff them against the table.
- Run the new platform in shadow mode: replay captured Access-Requests through both and compare Access-Accepts attribute by attribute.
- Confirm the new platform accepts accounting for sessions it did not authenticate.
- Cut over one NAS at a time and watch its reply-attribute mix before moving on.
Alepo follows this process when its carrier-grade AAA server replaces an incumbent platform on a live network, including for Tier 1 operators. For a technical consultation on your AAA platform migration, book a demo.
Frequently asked questions
Q1. What is NAS-Port-Type?
NAS-Port-Type (attribute 61) tells the AAA server what kind of access the subscriber is using. In a service provider network you’ll mostly see 19 for Wi-Fi, 15 for Ethernet, 35 for PON fiber, 32 or 33 for PPPoE, and 5 for virtual sessions.
Q2. What is Framed-IP-Address used for?
Framed-IP-Address (attribute 8) carries the subscriber session’s IPv4 address. An Access-Accept assigns it; accounting reports it. IPv6 sessions use Framed-IPv6-Prefix, Framed-IPv6-Address, and Delegated-IPv6-Prefix instead.
Q3. What is a vendor-specific attribute?
A vendor-specific attribute is any RADIUS attribute carried inside attribute 26. Its value holds the vendor’s IANA enterprise number followed by one or more sub-attributes, each with its own number, length, and data.
Q4. What is a RADIUS key?
A “RADIUS key” almost always means the shared secret, not an attribute. It’s the password both NAS and server hold to authenticate each other and obscure User-Password, and it never appears in a packet. How the shared secret secures a RADIUS exchange is covered in the protocol guide.
Q5. Which attributes identify a session?
Acct-Session-Id paired with NAS-IP-Address or NAS-Identifier, because session IDs are unique only per NAS. User-Name, Framed-IP-Address, and Calling-Station-Id narrow it further, and CoA requests target a session with the same RADIUS attributes.
Q6. What is the Class attribute for?
Class (attribute 25) is an opaque value the server sets in the Access-Accept and the NAS echoes unchanged in every accounting packet, so the server can recover a policy or plan identifier later.
Q7. What happens if an attribute is not recognized?
The login still succeeds. An unrecognized attribute is simply ignored, so the problem shows up as a missing reply attribute rather than an error. To catch it, compare the attributes in the Access-Accept against the policy that should have produced it.
Q8. Do VSAs survive a platform migration?
Only with deliberate mapping. Each platform’s dictionary may name, number, or type the same vendor attribute differently, so inventory VSAs in live traffic and compare Access-Accepts in shadow mode before you cut anything over.
