4.4 Accounting Packet Types

At this point, we have covered the structure of the packets that RADIUS uses to transmit accounting data. But we need to establish the identity and properties of these specific packets. There are two RADIUS packet types that are relevant to the accounting phase of an AAA transaction:

• Accounting-Request

• Accounting-Response

The next section will step through these packets and detail their intent, format, and structure.

Accounting-Request

---

Packet Type	Request
Code	4
Identifier	Unique for each request; unique for each transmission of modified data
Authenticator	Request
Attribute Data	0 or more attributes

Accounting-Request packets are sent from the client to the server. Remember that a client can be a true RADIUS client or another RADIUS server acting as a proxy. The client sends the packet with the code field set to 4 . When the server receives this request packet, it is required to transmit an acknowledgment to the client unless it cannot handle or process the packet. In this case, it cannot transmit anything to the client.

With the exceptions of the User -Password , CHAP-Password , Reply-Message , and State attributes, any other attribute allowed in an Access-Request or Access-Accept packet can be used inside an Accounting-Request packet.

Chapter 3 discusses all standard RADIUS attributes and their properties, including the packets in which they are allowed to be included. Check there for a complete overview of packet presence requirements.

There are a couple more caveats to presence in the packet. As mentioned in Chapter 2, the NAS-IP-Address and NAS-Identifier attributes are mutually exclusive, meaning that one or the other must be included in a packet, but not both. The RFC recommends distinguishing the NAS port or type of port in the packet by using the NAS-Port or NAS-Port-Type attributes unless that information is superfluous to the service. Additionally, the Framed-IP-Address must include the real IP address of the user.

Accounting-Response

---

Packet Type	Response
Code	5
Identifier	Identical to corresponding Accounting-Request
Authenticator	Response
Attribute Data	0 or more attributes

The Accounting-Response packets are primarily designed as acknowledgment packets to be sent from the accounting server to the client, indicating that the request from the client has been received and logged. If the packet was indeed processed and logged successfully, the RFC mandates that the code field of the acknowledgment section be set to 5 to indicate a response. Since the identifier of the response packet is identical to the corresponding Accounting-Request field, the client can easily match the two packets together to keep track of which requests have been fulfilled and which are outstanding.

Not only do Accounting-Response packets not have to contain any attributes, but in practice it is rare for them to do so. However, in the case of a proxy transaction, the Proxy-State attribute can be included in the packet. As well, any vendor-specific attributes may be included in Accounting-Response packets .