The RADIUS CoA (Change of Authorization) feature enables a RADIUS server to modify an active subscriber session without the necessity of the user reconnecting. The server forwards a CoA-Request to the network access server (NAS) via UDP port 3799 and the NAS responds with either a CoA-ACK or a CoA-NAK. This is as defined by RFC 5176.
Standard RADIUS (which is the Remote Authentication Dial-In User Service as defined in RFC 2865) allows the NAS to begin the conversation; CoA enables the AAA (Authentication, Authorization, and Accounting) server to take the initiative. It is used by operators to increase a subscriber’s speed, reduce the rate of a session which has used its quota, or send the device to a top-up page during the session.
RADIUS CoA ports: 3799 and 1700
The UDP port used for RADIUS CoA is 3799, with IANA designating 3799 as “radius-dynauth” and RFC 5176 specifying it as the destination port for CoA-Request and Disconnect-Request packets. The port number 1700 for RADIUS CoA is still found on certain equipment as an older vendor default.
| Port | Status | What to know |
| UDP 3799 | IANA-assigned, specified in RFC 5176 | The default for standards-based NAS and AAA software |
| UDP 1700 | Legacy vendor default | Still the default on some equipment. IANA lists 1700 for an unrelated service |
Vendors were shipping CoA before the IETF documented it in RFC 3576 in 2003, and some equipment still defaults to 1700. Neither port is wrong on the wire. A mismatch is what breaks things, so set the CoA port per NAS.
How a CoA exchange works
A RADIUS CoA exchange consists of a single request and a single reply, travelling in the opposite direction to the usual RADIUS flow. According to RFC 5176, this is referred to as dynamic authorization: in this case, the server initiates the exchange rather than the NAS. The entity that sends the message is the Dynamic Authorization Client (DAC), which is generally the AAA server. The one that receives the message is the Dynamic Authorization Server (DAS), and this is either the NAS itself or a proxy situated in front of it. That is the reason why the NAS waits for connections on port 3799.
- Something on the policy side triggers the change, such as a plan upgrade or an exhausted quota.
- The AAA server sends a CoA-Request that identifies the NAS and session, carries the new attributes, and is signed with the shared secret.
- The NAS checks the source and the shared secret, finds the session, and applies the change.
- The NAS replies with a CoA-ACK, or a CoA-NAK that may carry an Error-Cause. With no reply, the AAA server retransmits.
Figure: CoA exchange between policy system, AAA server, and NAS.
Changes are all or nothing. If the request fails on any matching session, the NAS changes none of them.
| Code | Message | Sent by | Meaning |
| 43 | CoA-Request | AAA server | Change this session |
| 44 | CoA-ACK | NAS | Change applied |
| 45 | CoA-NAK | NAS | Change refused, nothing applied |
| 40 | Disconnect-Request | AAA server | End this session |
| 41 | Disconnect-ACK | NAS | Session ended |
| 42 | Disconnect-NAK | NAS | Session not ended |
CoA vs. Disconnect-Request
CoA changes a session. A RADIUS Disconnect-Request ends it. Both use UDP 3799 and the same packet format, but a Disconnect-Request carries only identification attributes, since there’s nothing to change.
Use CoA when the subscriber should stay online under new rules. Disconnect suits fraud, non-payment, or a change the NAS can’t apply live. A new IP address is one, because a CoA-Request can’t assign it. The reconnect then picks up the new policy.
How the server identifies the session
The NAS matches each CoA-Request to a live session using session identification attributes. If nothing matches, it returns a CoA-NAK rather than guessing.
NAS-IP-Address and NAS-Identifier confirm the request is meant for that device. Acct-Session-Id, User-Name, Framed-IP-Address, and Calling-Station-Id point to the session. RFC 5176 recommends always sending Acct-Session-Id, plus User-Name or Chargeable-User-Identity.
Mismatches usually come from stale data:
- The subscriber reconnected, but the AAA server still holds the old Acct-Session-Id.
- A proxy stripped or added a realm, so the User-Name no longer matches the NAS.
- The NAS-IP-Address or NAS-Identifier doesn’t match the NAS (Error-Cause 403).
- Several sessions share a User-Name, so the NAS changes all of them or rejects the request (Error-Cause 508).
Pull identifiers from the latest accounting record, not the original Access-Request. A mismatch always returns a NAK, but something has to log it and read it. Otherwise the policy side never learns the change didn’t happen.
RADIUS CoA packet format and attributes
On the wire, a CoA packet looks like any RADIUS packet: Code (43, 44, or 45), Identifier, Length, a 16-byte Authenticator, and attributes. The Authenticator is calculated as for an Accounting-Request (RFC 2866), so a wrong shared secret invalidates the packet.
| Attribute (type) | Job in a CoA exchange |
| NAS-IP-Address (4), NAS-Identifier (32) | Identify the NAS |
| Acct-Session-Id (44), User-Name (1) | Identify the session |
| Filter-Id (11), Session-Timeout (27), Vendor-Specific (26) | Carry the change |
| Event-Timestamp (55), Message-Authenticator (80) | Guard against replay and tampering |
| Error-Cause (101) | Explain a CoA-NAK |
Identification attributes only identify, so a new Framed-IP-Address won’t renumber a session. Change attributes behave differently: any you include replace the existing values, and anything you leave out stays as it was.
What CoA is used for
CoA is how policy decisions reach running sessions. Common jobs are bandwidth tier changes, quota and fair-usage enforcement, captive portal redirects for top-ups, hotlining unpaid accounts, and session timer changes.
RADIUS CoA example: a mid-session speed upgrade
A subscriber buys a faster plan in the self-care app while streaming.
- The BSS (Business Support Systems) records the order and notifies the policy system.
- The policy system selects the new profile and asks the AAA server to apply it.
- The AAA server finds the live session in accounting data and sends a CoA-Request on port 3799. Base RADIUS has no bandwidth attribute. The new rate usually travels as a Filter-Id naming a profile already set up on the NAS, or as a vendor-specific attribute.
- The NAS applies the profile and returns a CoA-ACK. The stream never drops.
- On a NAK, the policy system retries or falls back to a Disconnect-Request, so the reconnect picks up the new profile.
See how Alepo’s converged policy control turns plan, quota, and device rules into live session changes.
When CoA fails
When a RADIUS CoA request fails, the NAS never processed it, couldn’t find the session, or sent a NAK that nobody read. Partial vendor support can cause any of the three.
The NAS never processed the request
You’ll see retransmissions and no reply, because RFC 5176 tells the NAS to silently discard untrusted requests. Start by checking that CoA is enabled and the port matches. Then confirm no firewall blocks UDP to the NAS, the AAA server’s IP is an allowed client, and the shared secret matches. Clock drift causes silent drops too if the NAS enforces Event-Timestamp. RFC 5176 suggests a 300-second window.
The session couldn’t be found
Here the NAS does reply, with a CoA-NAK. Look for Error-Cause 503 (Session Context Not Found) or 403 (NAS Identification Mismatch), then recheck the identifiers.
The NAK nobody read
When a NAK carries an Error-Cause, it tells you what to fix:
- 401 or 407: an attribute or value isn’t supported, so nothing in the request applied.
- 405: the Service-Type value isn’t supported.
- 501: the NAS is configured to refuse CoA for that session.
- 508: the identifiers matched more than one session.
Error-Cause is optional, so log every NAK with its full attribute set.
Partial vendor support
Not every NAS implements CoA fully. Some accept Disconnect but not CoA, some handle one session per request, and some take rate changes only through their own attributes. RFC 5176 also warns that an attribute a NAS accepts in an Access-Accept may not work in a CoA-Request. Test each NAS model and firmware against your exact requests before go-live. It’s also why per-NAS port, secret, and attribute settings matter in a carrier-grade AAA server. Alepo’s AAA Server supports RFC 5176 dynamic authorization, with out-of-the-box vendor-specific attribute support for major NAS vendors.
Testing CoA across your NAS fleet? Book a demo of Alepo’s AAA Server.
Frequently asked questions
Q1. What port does RADIUS CoA use?
UDP 3799, assigned by IANA and specified in RFC 5176. Some equipment still defaults to legacy port 1700.
Q2. Is CoA on port 3799 or 1700?
3799, the registered port and the right default. 1700 is a legacy vendor default, so match the AAA server to each NAS.
Q3. What is the difference between CoA and Disconnect?
CoA changes an active session while the subscriber stays online. Disconnect ends the session.
Q4. Which RFC defines RADIUS CoA?
RFC 5176, Dynamic Authorization Extensions to RADIUS (2008), which replaced RFC 3576. RFC 8559 later added rules for proxying.
Q5. Why was my CoA request rejected?
Usually the identifiers matched no live session, or an attribute wasn’t supported. The NAK’s Error-Cause says which. No reply at all means the NAS isn’t accepting CoA from your server.
Q6. Does every NAS support CoA?
No. Support varies by vendor, model, and firmware, so test before relying on it.
Q7. Can CoA change bandwidth mid-session?
Yes. The CoA-Request carries the new rate profile, usually as a Filter-Id or a vendor-specific attribute, and the session stays up.
