7 Network Working Group C. Rigney
8 Request for Comments: 2139 Livingston
9 Obsoletes: 2059 April 1997
10 Category: Informational
17 This memo provides information for the Internet community. This memo
18 does not specify an Internet standard of any kind. Distribution of
19 this memo is unlimited.
23 This document describes a protocol for carrying accounting
24 information between a Network Access Server and a shared Accounting
29 This memo documents the RADIUS Accounting protocol. There has been
30 some confusion in the assignment of port numbers for this protocol.
31 The early deployment of RADIUS Accounting was done using the
32 erroneously chosen port number 1646, which conflicts with the "sa-
33 msg-port" service. The officially assigned port number for RADIUS
38 1. Introduction .......................................... 2
39 1.1 Specification of Requirements ................... 3
40 1.2 Terminology ..................................... 3
41 2. Operation ............................................. 4
42 3. Packet Format ......................................... 5
43 4. Packet Types .......................................... 7
44 4.1 Accounting-Request .............................. 7
45 4.2 Accounting-Response ............................. 8
46 5. Attributes ............................................ 10
47 5.1 Acct-Status-Type ................................ 11
48 5.2 Acct-Delay-Time ................................. 12
49 5.3 Acct-Input-Octets ............................... 13
50 5.4 Acct-Output-Octets .............................. 14
51 5.5 Acct-Session-Id ................................. 14
52 5.6 Acct-Authentic .................................. 15
53 5.7 Acct-Session-Time ............................... 16
54 5.8 Acct-Input-Packets .............................. 16
58 Rigney Informational [Page 1]
60 RFC 2139 RADIUS Accounting April 1997
63 5.9 Acct-Output-Packets ............................. 17
64 5.10 Acct-Terminate-Cause ............................ 18
65 5.11 Acct-Multi-Session-Id ........................... 20
66 5.12 Acct-Link-Count ................................. 21
67 5.13 Table of Attributes ............................. 22
68 Security Considerations ...................................... 24
69 References ................................................... 24
70 Acknowledgements ............................................. 24
71 Chair's Address .............................................. 24
72 Author's Address ............................................. 25
76 Managing dispersed serial line and modem pools for large numbers of
77 users can create the need for significant administrative support.
78 Since modem pools are by definition a link to the outside world, they
79 require careful attention to security, authorization and accounting.
80 This can be best achieved by managing a single "database" of users,
81 which allows for authentication (verifying user name and password) as
82 well as configuration information detailing the type of service to
83 deliver to the user (for example, SLIP, PPP, telnet, rlogin).
85 The RADIUS (Remote Authentication Dial In User Service) document [4]
86 specifies the RADIUS protocol used for Authentication and
87 Authorization. This memo extends the use of the RADIUS protocol to
88 cover delivery of accounting information from the Network Access
89 Server (NAS) to a RADIUS accounting server.
91 Key features of RADIUS Accounting are:
95 A Network Access Server (NAS) operates as a client of the
96 RADIUS accounting server. The client is responsible for
97 passing user accounting information to a designated RADIUS
100 The RADIUS accounting server is responsible for receiving the
101 accounting request and returning a response to the client
102 indicating that it has successfully received the request.
104 The RADIUS accounting server can act as a proxy client to other
105 kinds of accounting servers.
114 Rigney Informational [Page 2]
116 RFC 2139 RADIUS Accounting April 1997
121 Transactions between the client and RADIUS accounting server
122 are authenticated through the use of a shared secret, which is
123 never sent over the network.
127 All transactions are comprised of variable length Attribute-
128 Length-Value 3-tuples. New attribute values can be added
129 without disturbing existing implementations of the protocol.
131 1.1. Specification of Requirements
133 In this document, several words are used to signify the requirements
134 of the specification. These words are often capitalized.
136 MUST This word, or the adjective "required", means that the
137 definition is an absolute requirement of the specification.
139 MUST NOT This phrase means that the definition is an absolute
140 prohibition of the specification.
142 SHOULD This word, or the adjective "recommended", means that there
143 may exist valid reasons in particular circumstances to
144 ignore this item, but the full implications must be
145 understood and carefully weighed before choosing a
148 MAY This word, or the adjective "optional", means that this
149 item is one of an allowed set of alternatives. An
150 implementation which does not include this option MUST be
151 prepared to interoperate with another implementation which
152 does include the option.
156 This document uses the following terms:
158 service The NAS provides a service to the dial-in user, such as PPP
170 Rigney Informational [Page 3]
172 RFC 2139 RADIUS Accounting April 1997
175 session Each service provided by the NAS to a dial-in user
176 constitutes a session, with the beginning of the session
177 defined as the point where service is first provided and
178 the end of the session defined as the point where service
179 is ended. A user may have multiple sessions in parallel or
180 series if the NAS supports that, with each session
181 generating a separate start and stop accounting record with
182 its own Acct-Session-Id.
185 This means the implementation discards the packet without
186 further processing. The implementation SHOULD provide the
187 capability of logging the error, including the contents of
188 the silently discarded packet, and SHOULD record the event
189 in a statistics counter.
193 When a client is configured to use RADIUS Accounting, at the start of
194 service delivery it will generate an Accounting Start packet
195 describing the type of service being delivered and the user it is
196 being delivered to, and will send that to the RADIUS Accounting
197 server, which will send back an acknowledgement that the packet has
198 been received. At the end of service delivery the client will
199 generate an Accounting Stop packet describing the type of service
200 that was delivered and optionally statistics such as elapsed time,
201 input and output octets, or input and output packets. It will send
202 that to the RADIUS Accounting server, which will send back an
203 acknowledgement that the packet has been received.
205 The Accounting-Request (whether for Start or Stop) is submitted to
206 the RADIUS accounting server via the network. It is recommended that
207 the client continue attempting to send the Accounting-Request packet
208 until it receives an acknowledgement, using some form of backoff. If
209 no response is returned within a length of time, the request is re-
210 sent a number of times. The client can also forward requests to an
211 alternate server or servers in the event that the primary server is
212 down or unreachable. An alternate server can be used either after a
213 number of tries to the primary server fail, or in a round-robin
214 fashion. Retry and fallback algorithms are the topic of current
215 research and are not specified in detail in this document.
217 The RADIUS accounting server MAY make requests of other servers in
218 order to satisfy the request, in which case it acts as a client.
220 If the RADIUS accounting server is unable to successfully record the
221 accounting packet it MUST NOT send an Accounting-Response
222 acknowledgment to the client.
226 Rigney Informational [Page 4]
228 RFC 2139 RADIUS Accounting April 1997
233 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
234 field [1], where the UDP Destination Port field indicates 1813
237 When a reply is generated, the source and destination ports are
240 This memo documents the RADIUS Accounting protocol. There has been
241 some confusion in the assignment of port numbers for this protocol.
242 The early deployment of RADIUS Accounting was done using the
243 erroneously chosen port number 1646, which conflicts with the "sa-
244 msg-port" service. The officially assigned port number for RADIUS
247 A summary of the RADIUS data format is shown below. The fields are
248 transmitted from left to right.
251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253 | Code | Identifier | Length |
254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
261 +-+-+-+-+-+-+-+-+-+-+-+-+-
266 The Code field is one octet, and identifies the type of RADIUS
267 packet. When a packet is received with an invalid Code field, it is
270 RADIUS Accounting Codes (decimal) are assigned as follows:
273 5 Accounting-Response
277 The Identifier field is one octet, and aids in matching requests and
282 Rigney Informational [Page 5]
284 RFC 2139 RADIUS Accounting April 1997
289 The Length field is two octets. It indicates the length of the
290 packet including the Code, Identifier, Length, Authenticator and
291 Attribute fields. Octets outside the range of the Length field
292 should be treated as padding and should be ignored on reception. If
293 the packet is shorter than the Length field indicates, it should be
294 silently discarded. The minimum length is 20 and maximum length is
299 The Authenticator field is sixteen (16) octets. The most significant
300 octet is transmitted first. This value is used to authenticate the
301 messages between the client and RADIUS accounting server.
303 Request Authenticator
305 In Accounting-Request Packets, the Authenticator value is a 16 octet
306 MD5 [3] checksum, called the Request Authenticator.
308 The NAS and RADIUS accounting server share a secret. The Request
309 Authenticator field in Accounting-Request packets contains a one- way
310 MD5 hash calculated over a stream of octets consisting of the Code +
311 Identifier + Length + 16 zero octets + request attributes + shared
312 secret (where + indicates concatenation). The 16 octet MD5 hash
313 value is stored in the Authenticator field of the Accounting-Request
316 Note that the Request Authenticator of an Accounting-Request can
317 not be done the same way as the Request Authenticator of a RADIUS
318 Access-Request, because there is no User-Password attribute in an
321 Response Authenticator
323 The Authenticator field in an Accounting-Response packet is called
324 the Response Authenticator, and contains a one-way MD5 hash
325 calculated over a stream of octets consisting of the Accounting-
326 Response Code, Identifier, Length, the Request Authenticator field
327 from the Accounting-Request packet being replied to, and the response
328 attributes if any, followed by the shared secret. The resulting 16
329 octet MD5 hash value is stored in the Authenticator field of the
330 Accounting-Response packet.
338 Rigney Informational [Page 6]
340 RFC 2139 RADIUS Accounting April 1997
345 Attributes may have multiple instances, in such a case the order of
346 attributes of the same type SHOULD be preserved. The order of
347 attributes of different types is not required to be preserved.
351 The RADIUS packet type is determined by the Code field in the first
354 4.1. Accounting-Request
358 Accounting-Request packets are sent from a client (typically a
359 Network Access Server or its proxy) to a RADIUS accounting server,
360 and convey information used to provide accounting for a service
361 provided to a user. The client transmits a RADIUS packet with the
362 Code field set to 4 (Accounting-Request).
364 Upon receipt of an Accounting-Request, the server MUST transmit an
365 Accounting-Response reply if it successfully records the
366 accounting packet, and MUST NOT transmit any reply if it fails to
367 record the accounting packet.
369 Any attribute valid in a RADIUS Access-Request or Access-Accept
370 packet is valid in a RADIUS Accounting-Request packet, except that
371 the following attributes MUST NOT be present in an Accounting-
372 Request: User-Password, CHAP-Password, Reply-Message, State.
373 Either NAS-IP-Address or NAS-Identifier MUST be present in a
374 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
375 Port-Type attribute or both unless the service does not involve a
376 port or the NAS does not distinguish among its ports.
378 A summary of the Accounting-Request packet format is shown below.
379 The fields are transmitted from left to right.
394 Rigney Informational [Page 7]
396 RFC 2139 RADIUS Accounting April 1997
400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
402 | Code | Identifier | Length |
403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
405 | Request Authenticator |
408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410 +-+-+-+-+-+-+-+-+-+-+-+-+-
414 4 for Accounting-Request.
418 The Identifier field MUST be changed whenever the content of the
419 Attributes field changes, and whenever a valid reply has been
420 received for a previous request. For retransmissions where the
421 contents are identical, the Identifier MUST remain unchanged.
423 Note that if Acct-Delay-Time is included in the attributes of an
424 Accounting-Request then the Acct-Delay-Time value will be updated
425 when the packet is retransmitted, changing the content of the
426 Attributes field and requiring a new Identifier and Request
429 Request Authenticator
431 The Request Authenticator of an Accounting-Request contains a 16-
432 octet MD5 hash value calculated according to the method described
433 in "Request Authenticator" above.
437 The Attributes field is variable in length, and contains a list of
440 4.2. Accounting-Response
444 Accounting-Response packets are sent by the RADIUS accounting
445 server to the client to acknowledge that the Accounting-Request
446 has been received and recorded successfully. If the Accounting-
450 Rigney Informational [Page 8]
452 RFC 2139 RADIUS Accounting April 1997
455 Request was recorded successfully then the RADIUS accounting
456 server MUST transmit a packet with the Code field set to 5
457 (Accounting-Response). On reception of an Accounting-Response by
458 the client, the Identifier field is matched with a pending
459 Accounting-Request. Invalid packets are silently discarded.
461 A RADIUS Accounting-Response is not required to have any
464 A summary of the Accounting-Response packet format is shown below.
465 The fields are transmitted from left to right.
468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
470 | Code | Identifier | Length |
471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 | Response Authenticator |
476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478 +-+-+-+-+-+-+-+-+-+-+-+-+-
482 5 for Accounting-Response.
486 The Identifier field is a copy of the Identifier field of the
487 Accounting-Request which caused this Accounting-Response.
489 Response Authenticator
491 The Response Authenticator of an Accounting-Response contains a
492 16-octet MD5 hash value calculated according to the method
493 described in "Response Authenticator" above.
497 The Attributes field is variable in length, and contains a list of
498 zero or more Attributes.
506 Rigney Informational [Page 9]
508 RFC 2139 RADIUS Accounting April 1997
513 RADIUS Attributes carry the specific authentication, authorization
514 and accounting details for the request and response.
516 Some attributes MAY be included more than once. The effect of this
517 is attribute specific, and is specified in each attribute
520 The end of the list of attributes is indicated by the Length of the
523 A summary of the attribute format is shown below. The fields are
524 transmitted from left to right.
527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 | Type | Length | Value ...
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
534 The Type field is one octet. Up-to-date values of the RADIUS Type
535 field are specified in the most recent "Assigned Numbers" RFC [2].
536 Values 192-223 are reserved for experimental use, values 224-240
537 are reserved for implementation-specific use, and values 241-255
538 are reserved and should not be used. This specification concerns
539 the following values:
541 1-39 (refer to RADIUS document [4])
545 43 Acct-Output-Octets
549 47 Acct-Input-Packets
550 48 Acct-Output-Packets
551 49 Acct-Terminate-Cause
552 50 Acct-Multi-Session-Id
554 60+ (refer to RADIUS document [4])
562 Rigney Informational [Page 10]
564 RFC 2139 RADIUS Accounting April 1997
569 The Length field is one octet, and indicates the length of this
570 attribute including the Type, Length and Value fields. If an
571 attribute is received in an Accounting-Request with an invalid
572 Length, the entire request should be silently discarded.
576 The Value field is zero or more octets and contains information
577 specific to the attribute. The format and length of the Value
578 field is determined by the Type and Length fields.
580 The format of the value field is one of four data types.
584 address 32 bit value, most significant octet first.
586 integer 32 bit value, most significant octet first.
588 time 32 bit value, most significant octet first -- seconds
589 since 00:00:00 GMT, January 1, 1970. The standard
590 Attributes do not use this data type but it is presented
591 here for possible use within Vendor-Specific attributes.
593 5.1. Acct-Status-Type
597 This attribute indicates whether this Accounting-Request marks the
598 beginning of the user service (Start) or the end (Stop).
600 It MAY be used by the client to mark the start of accounting (for
601 example, upon booting) by specifying Accounting-On and to mark the
602 end of accounting (for example, just before a scheduled reboot) by
603 specifying Accounting-Off.
605 A summary of the Acct-Status-Type attribute format is shown below.
606 The fields are transmitted from left to right.
609 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
611 | Type | Length | Value
612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
618 Rigney Informational [Page 11]
620 RFC 2139 RADIUS Accounting April 1997
625 40 for Acct-Status-Type.
633 The Value field is four octets.
644 This attribute indicates how many seconds the client has been
645 trying to send this record for, and can be subtracted from the
646 time of arrival on the server to find the approximate time of the
647 event generating this Accounting-Request. (Network transit time
650 Note that changing the Acct-Delay-Time causes the Identifier to
651 change; see the discussion under Identifier above.
653 A summary of the Acct-Delay-Time attribute format is shown below.
654 The fields are transmitted from left to right.
657 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
659 | Type | Length | Value
660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
666 41 for Acct-Delay-Time.
674 Rigney Informational [Page 12]
676 RFC 2139 RADIUS Accounting April 1997
681 The Value field is four octets.
683 5.3. Acct-Input-Octets
687 This attribute indicates how many octets have been received from
688 the port over the course of this service being provided, and can
689 only be present in Accounting-Request records where the Acct-
690 Status-Type is set to Stop.
692 A summary of the Acct-Input-Octets attribute format is shown below.
693 The fields are transmitted from left to right.
696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
698 | Type | Length | Value
699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
705 42 for Acct-Input-Octets.
713 The Value field is four octets.
715 5.4. Acct-Output-Octets
719 This attribute indicates how many octets have been sent to the
720 port in the course of delivering this service, and can only be
721 present in Accounting-Request records where the Acct-Status-Type
724 A summary of the Acct-Output-Octets attribute format is shown below.
725 The fields are transmitted from left to right.
730 Rigney Informational [Page 13]
732 RFC 2139 RADIUS Accounting April 1997
736 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738 | Type | Length | Value
739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745 43 for Acct-Output-Octets.
753 The Value field is four octets.
759 This attribute is a unique Accounting ID to make it easy to match
760 start and stop records in a log file. The start and stop records
761 for a given session MUST have the same Acct-Session-Id. It is
762 strongly recommended that the Acct-Session-Id be a printable ASCII
765 For example, one implementation uses a string with an 8-digit
766 upper case hexadecimal number, the first two digits increment on
767 each reboot (wrapping every 256 reboots) and the next 6 digits
768 counting from 0 for the first person logging in after a reboot up
769 to 2^24-1, about 16 million. Other encodings are possible.
771 A summary of the Acct-Session-Id attribute format is shown below.
772 The fields are transmitted from left to right.
786 Rigney Informational [Page 14]
788 RFC 2139 RADIUS Accounting April 1997
792 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
794 | Type | Length | String ...
795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
799 44 for Acct-Session-Id.
807 The String field SHOULD be a string of printable ASCII characters.
813 This attribute MAY be included in an Accounting-Request to
814 indicate how the user was authenticated, whether by RADIUS, the
815 NAS itself, or another remote authentication protocol. Users who
816 are delivered service without being authenticated SHOULD NOT
817 generate Accounting records.
819 A summary of the Acct-Authentic attribute format is shown below. The
820 fields are transmitted from left to right.
823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
825 | Type | Length | Value
826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
832 45 for Acct-Authentic.
842 Rigney Informational [Page 15]
844 RFC 2139 RADIUS Accounting April 1997
849 The Value field is four octets.
855 5.7. Acct-Session-Time
859 This attribute indicates how many seconds the user has received
860 service for, and can only be present in Accounting-Request records
861 where the Acct-Status-Type is set to Stop.
863 A summary of the Acct-Session-Time attribute format is shown below.
864 The fields are transmitted from left to right.
867 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
869 | Type | Length | Value
870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
876 46 for Acct-Session-Time.
884 The Value field is four octets.
886 5.8. Acct-Input-Packets
890 This attribute indicates how many packets have been received from
891 the port over the course of this service being provided to a
892 Framed User, and can only be present in Accounting-Request records
893 where the Acct-Status-Type is set to Stop.
898 Rigney Informational [Page 16]
900 RFC 2139 RADIUS Accounting April 1997
903 A summary of the Acct-Input-packets attribute format is shown below.
904 The fields are transmitted from left to right.
907 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909 | Type | Length | Value
910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
916 47 for Acct-Input-Packets.
924 The Value field is four octets.
926 5.9. Acct-Output-Packets
930 This attribute indicates how many packets have been sent to the
931 port in the course of delivering this service to a Framed User,
932 and can only be present in Accounting-Request records where the
933 Acct-Status-Type is set to Stop.
935 A summary of the Acct-Output-Packets attribute format is shown below.
936 The fields are transmitted from left to right.
939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
941 | Type | Length | Value
942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
948 48 for Acct-Output-Packets.
954 Rigney Informational [Page 17]
956 RFC 2139 RADIUS Accounting April 1997
965 The Value field is four octets.
967 5.10. Acct-Terminate-Cause
971 This attribute indicates how the session was terminated, and can
972 only be present in Accounting-Request records where the Acct-
973 Status-Type is set to Stop.
975 A summary of the Acct-Terminate-Cause attribute format is shown
976 below. The fields are transmitted from left to right.
979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
981 | Type | Length | Value
982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
988 49 for Acct-Terminate-Cause
1010 Rigney Informational [Page 18]
1012 RFC 2139 RADIUS Accounting April 1997
1017 The Value field is four octets, containing an integer specifying
1018 the cause of session termination, as follows:
1034 15 Service Unavailable
1041 The termination causes are as follows:
1043 User Request User requested termination of service, for
1044 example with LCP Terminate or by logging out.
1046 Lost Carrier DCD was dropped on the port.
1048 Lost Service Service can no longer be provided; for
1049 example, user's connection to a host was
1052 Idle Timeout Idle timer expired.
1054 Session Timeout Maximum session length timer expired.
1056 Admin Reset Administrator reset the port or session.
1058 Admin Reboot Administrator is ending service on the NAS,
1059 for example prior to rebooting the NAS.
1061 Port Error NAS detected an error on the port which
1062 required ending the session.
1066 Rigney Informational [Page 19]
1068 RFC 2139 RADIUS Accounting April 1997
1071 NAS Error NAS detected some error (other than on the
1072 port) which required ending the session.
1074 NAS Request NAS ended session for a non-error reason not
1075 otherwise listed here.
1077 NAS Reboot The NAS ended the session in order to reboot
1078 non-administratively ("crash").
1080 Port Unneeded NAS ended session because resource usage fell
1081 below low-water mark (for example, if a
1082 bandwidth-on-demand algorithm decided that
1083 the port was no longer needed).
1085 Port Preempted NAS ended session in order to allocate the
1086 port to a higher priority use.
1088 Port Suspended NAS ended session to suspend a virtual
1091 Service Unavailable NAS was unable to provide requested service.
1093 Callback NAS is terminating current session in order
1094 to perform callback for a new session.
1096 User Error Input from user is in error, causing
1097 termination of session.
1099 Host Request Login Host terminated session normally.
1101 5.11. Acct-Multi-Session-Id
1105 This attribute is a unique Accounting ID to make it easy to link
1106 together multiple related sessions in a log file. Each session
1107 linked together would have a unique Acct-Session-Id but the same
1108 Acct-Multi-Session-Id. It is strongly recommended that the Acct-
1109 Multi-Session-Id be a printable ASCII string.
1111 A summary of the Acct-Session-Id attribute format is shown below.
1112 The fields are transmitted from left to right.
1115 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1117 | Type | Length | String ...
1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1122 Rigney Informational [Page 20]
1124 RFC 2139 RADIUS Accounting April 1997
1129 50 for Acct-Multi-Session-Id.
1137 The String field SHOULD be a string of printable ASCII characters.
1139 5.12. Acct-Link-Count
1143 This attribute gives the count of links which are known to have
1144 been in a given multilink session at the time the accounting
1145 record is generated. The NAS MAY include the Acct-Link-Count
1146 attribute in any Accounting-Request which might have multiple
1149 A summary of the Acct-Link-Count attribute format is show below. The
1150 fields are transmitted from left to right.
1153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1155 | Type | Length | Value
1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1162 51 for Acct-Link-Count.
1170 The Value field is four octets, and contains the number of links
1171 seen so far in this Multilink Session.
1178 Rigney Informational [Page 21]
1180 RFC 2139 RADIUS Accounting April 1997
1183 It may be used to make it easier for an accounting server to know
1184 when it has all the records for a given Multilink session. When
1185 the number of Accounting-Requests received with Acct-Status-Type =
1186 Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
1187 Id's equals the largest value of Acct-Link-Count seen in those
1188 Accounting-Requests, all Stop Accounting-Requests for that
1189 Multilink Session have been received.
1191 An example showing 8 Accounting-Requests should make things
1192 clearer. For clarity only the relevant attributes are shown, but
1193 additional attributes containing accounting information will also
1194 be present in the Accounting-Request.
1196 Multi-Session-Id Session-Id Status-Type Link-Count
1206 5.13. Table of Attributes
1208 The following table provides a guide to which attributes may be found
1209 in Accounting-Request packets. No attributes should be found in
1210 Accounting-Response packets except Proxy-State and possibly Vendor-
1217 0-1 NAS-IP-Address [5]
1221 0-1 Framed-IP-Address
1222 0-1 Framed-IP-Netmask
1226 0+ Framed-Compression
1234 Rigney Informational [Page 22]
1236 RFC 2139 RADIUS Accounting April 1997
1242 0-1 Framed-IPX-Network
1248 0-1 Termination-Action
1249 0-1 Called-Station-Id
1250 0-1 Calling-Station-Id
1251 0-1 NAS-Identifier [4]
1253 0-1 Login-LAT-Service
1256 0-1 Framed-AppleTalk-Link
1257 0-1 Framed-AppleTalk-Network
1258 0-1 Framed-AppleTalk-Zone
1261 0-1 Acct-Input-Octets
1262 0-1 Acct-Output-Octets
1265 0-1 Acct-Session-Time
1266 0-1 Acct-Input-Packets
1267 0-1 Acct-Output-Packets
1268 0-1 Acct-Terminate-Cause
1269 0+ Acct-Multi-Session-Id
1277 [5] An Accounting-Request MUST contain either a NAS-IP-Address or a
1278 NAS-Identifier, and it is permitted (but not recommended) for it to
1281 The following table defines the above table entries.
1283 0 This attribute MUST NOT be present
1284 0+ Zero or more instances of this attribute MAY be present.
1285 0-1 Zero or one instance of this attribute MAY be present.
1286 1 Exactly one instance of this attribute MUST be present.
1290 Rigney Informational [Page 23]
1292 RFC 2139 RADIUS Accounting April 1997
1295 Security Considerations
1297 Security issues are briefly discussed in sections concerning the
1298 authenticator included in accounting requests and responses, using a
1299 shared secret which is never sent over the network.
1303 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1304 USC/Information Sciences Institute, August 1980.
1306 [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1307 1700, USC/Information Sciences Institute, October 1994.
1309 [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
1310 RFC 1321, MIT Laboratory for Computer Science, RSA Data
1311 Security Inc., April 1992.
1313 [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
1314 Authentication Dial In User Service (RADIUS)", RFC 2138,
1319 RADIUS and RADIUS Accounting were originally developed by Livingston
1320 Enterprises for their PortMaster series of Network Access Servers.
1324 The RADIUS working group can be contacted via the current chair:
1327 Livingston Enterprises
1329 Pleasanton, California 94588
1331 Phone: +1 510 426 0770
1332 EMail: cdr@livingston.com
1346 Rigney Informational [Page 24]
1348 RFC 2139 RADIUS Accounting April 1997
1353 Questions about this memo can also be directed to:
1356 Livingston Enterprises
1358 Pleasanton, California 94588
1360 EMail: cdr@livingston.com
1402 Rigney Informational [Page 25]