rfc2866.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,572 行 · 第 1/4 页

Rigney                       Informational                      [Page 7]

RFC 2866                   RADIUS Accounting                   June 2000


4.1.  Accounting-Request

   Description

      Accounting-Request packets are sent from a client (typically a
      Network Access Server or its proxy) to a RADIUS accounting server,
      and convey information used to provide accounting for a service
      provided to a user.  The client transmits a RADIUS packet with the
      Code field set to 4 (Accounting-Request).

      Upon receipt of an Accounting-Request, the server MUST transmit an
      Accounting-Response reply if it successfully records the
      accounting packet, and MUST NOT transmit any reply if it fails to
      record the accounting packet.

      Any attribute valid in a RADIUS Access-Request or Access-Accept
      packet is valid in a RADIUS Accounting-Request packet, except that
      the following attributes MUST NOT be present in an Accounting-
      Request:  User-Password, CHAP-Password, Reply-Message, State.
      Either NAS-IP-Address or NAS-Identifier MUST be present in a
      RADIUS Accounting-Request.  It SHOULD contain a NAS-Port or NAS-
      Port-Type attribute or both unless the service does not involve a
      port or the NAS does not distinguish among its ports.

      If the Accounting-Request packet includes a Framed-IP-Address,
      that attribute MUST contain the IP address of the user.  If the
      Access-Accept used the special values for Framed-IP-Address
      telling the NAS to assign or negotiate an IP address for the user,
      the Framed-IP-Address (if any) in the Accounting-Request MUST
      contain the actual IP address assigned or negotiated.

   A summary of the Accounting-Request packet format is shown below.

   The fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Request Authenticator                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-




Rigney                       Informational                      [Page 8]

RFC 2866                   RADIUS Accounting                   June 2000


   Code

      4 for Accounting-Request.

   Identifier

      The Identifier field MUST be changed whenever the content of the
      Attributes field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions where the
      contents are identical, the Identifier MUST remain unchanged.

      Note that if Acct-Delay-Time is included in the attributes of an
      Accounting-Request then the Acct-Delay-Time value will be updated
      when the packet is retransmitted, changing the content of the
      Attributes field and requiring a new Identifier and Request
      Authenticator.

   Request Authenticator

      The Request Authenticator of an Accounting-Request contains a 16-octet
      MD5 hash value calculated according to the method described in
      "Request Authenticator" above.

   Attributes

      The Attributes field is variable in length, and contains a list of
      Attributes.

4.2.  Accounting-Response

   Description

      Accounting-Response packets are sent by the RADIUS accounting
      server to the client to acknowledge that the Accounting-Request
      has been received and recorded successfully.  If the Accounting-
      Request was recorded successfully then the RADIUS accounting
      server MUST transmit a packet with the Code field set to 5
      (Accounting-Response).  On reception of an Accounting-Response by
      the client, the Identifier field is matched with a pending
      Accounting-Request.  The Response Authenticator field MUST contain
      the correct response for the pending Accounting-Request.  Invalid
      packets are silently discarded.

      A RADIUS Accounting-Response is not required to have any
      attributes in it.

   A summary of the Accounting-Response packet format is shown below.
   The fields are transmitted from left to right.



Rigney                       Informational                      [Page 9]

RFC 2866                   RADIUS Accounting                   June 2000


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      5 for Accounting-Response.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Accounting-Request which caused this Accounting-Response.

   Response Authenticator

      The Response Authenticator of an Accounting-Response contains a
      16-octet MD5 hash value calculated according to the method
      described in "Response Authenticator" above.

   Attributes

      The Attributes field is variable in length, and contains a list of
      zero or more Attributes.

5.  Attributes

   RADIUS Attributes carry the specific authentication, authorization
   and accounting details for the request and response.

   Some attributes MAY be included more than once.  The effect of this
   is attribute specific, and is specified in each attribute
   description.

   The end of the list of attributes is indicated by the Length of the
   RADIUS packet.

   A summary of the attribute format is shown below.  The fields are
   transmitted from left to right.




Rigney                       Informational                     [Page 10]

RFC 2866                   RADIUS Accounting                   June 2000


    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      The Type field is one octet.  Up-to-date values of the RADIUS Type
      field are specified in the most recent "Assigned Numbers" RFC [6].
      Values 192-223 are reserved for experimental use, values 224-240
      are reserved for implementation-specific use, and values 241-255
      are reserved and should not be used.  This specification concerns
      the following values:

           1-39   (refer to RADIUS document [2])
          40      Acct-Status-Type
          41      Acct-Delay-Time
          42      Acct-Input-Octets
          43      Acct-Output-Octets
          44      Acct-Session-Id
          45      Acct-Authentic
          46      Acct-Session-Time
          47      Acct-Input-Packets
          48      Acct-Output-Packets
          49      Acct-Terminate-Cause
          50      Acct-Multi-Session-Id
          51      Acct-Link-Count
          60+     (refer to RADIUS document [2])

   Length

      The Length field is one octet, and indicates the length of this
      attribute including the Type, Length and Value fields.  If an
      attribute is received in an Accounting-Request with an invalid
      Length, the entire request MUST be silently discarded.

   Value

      The Value field is zero or more octets and contains information
      specific to the attribute.  The format and length of the Value
      field is determined by the Type and Length fields.

      Note that none of the types in RADIUS terminate with a NUL (hex
      00).  In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646



Rigney                       Informational                     [Page 11]

RFC 2866                   RADIUS Accounting                   June 2000


      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      RADIUS implementers using C are cautioned not to use strcpy() when
      handling strings.

      The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string."

      text     1-253 octets containing UTF-8 encoded 10646 [7]
               characters.  Text of length zero (0) MUST NOT be sent;
               omit the entire attribute instead.

      string   1-253 octets containing binary data (values 0 through 255
               decimal, inclusive).  Strings of length zero (0) MUST NOT
               be sent; omit the entire attribute instead.

      address  32 bit value, most significant octet first.

      integer  32 bit unsigned value, most significant octet first.

      time     32 bit unsigned value, most significant octet first --
               seconds since 00:00:00 UTC, January 1, 1970.  The
               standard Attributes do not use this data type but it is
               presented here for possible use in future attributes.

5.1.  Acct-Status-Type

   Description

      This attribute indicates whether this Accounting-Request marks the
      beginning of the user service (Start) or the end (Stop).

      It MAY be used by the client to mark the start of accounting (for
      example, upon booting) by specifying Accounting-On and to mark the
      end of accounting (for example, just before a scheduled reboot) by
      specifying Accounting-Off.

   A summary of the Acct-Status-Type attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Rigney                       Informational                     [Page 12]

RFC 2866                   RADIUS Accounting                   June 2000


   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

      The Value field is four octets.

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off
       9-14   Reserved for Tunnel Accounting
      15      Reserved for Failed

5.2.  Acct-Delay-Time

   Description

      This attribute indicates how many seconds the client has been
      trying to send this record for, and can be subtracted from the
      time of arrival on the server to find the approximate time of the
      event generating this Accounting-Request.  (Network transit time
      is ignored.)

      Note that changing the Acct-Delay-Time causes the Identifier to
      change; see the discussion under Identifier above.

   A summary of the Acct-Delay-Time attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Rigney                       Informational                     [Page 13]

RFC 2866                   RADIUS Accounting                   June 2000


   Type

      41 for Acct-Delay-Time.

   Length

      6

   Value

      The Value field is four octets.

5.3.  Acct-Input-Octets

   Description

      This attribute indicates how many octets have been received from
      the port over the course of this service being provided, and can
      only be present in Accounting-Request records where the Acct-
      Status-Type is set to Stop.

   A summary of the Acct-Input-Octets attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      42 for Acct-Input-Octets.

   Length

      6

   Value

      The Value field is four octets.








Rigney                       Informational                     [Page 14]