RADIUS attribute from rfc2867


Acct-Tunnel-Packets-Lost

This Attribute indicates the number of packets lost on a given
         link.  It SHOULD be included in Accounting-Request packets
         which contain an Acct-Status-Type attribute having the value
         Tunnel-Link-Stop.A summary of the Acct-Tunnel-Packets-Lost 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     |               Lost
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Lost (cont)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         86 for Acct-Tunnel-Packets-Lost

      Length

         6

      Lost

         The Lost field is 4 octets in length and represents the number
         of packets lost on the link.5.  Table of AttributesThe following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No tunnel attributes should be found
   in Accounting-Response packets.

   Request        #       Attribute
     0-1          64      Tunnel-Type
     0-1          65      Tunnel-Medium-Type
     0-1          66      Tunnel-Client-Endpoint
     0-1          67      Tunnel-Server-Endpoint
     0-1          68      Acct-Tunnel-Connection
     0            69      Tunnel-Password
     0-1          81      Tunnel-Private-Group-ID
     0-1          82      Tunnel-Assignment-ID
     0            83      Tunnel-Preference
     0-1          86      Acct-Tunnel-Packets-LostThe following table defines the meaning of the above table entries.

   0     This attribute MUST NOT be present in packet.
   0+    Zero or more instances of this attribute MAY be present in
         packet.
   0-1   Zero or one instance of this attribute MAY be present in
         packet.6.  Security ConsiderationsBy "sniffing" RADIUS Accounting packets, it might be possible for an
   eavesdropper to perform a passive analysis of tunnel connections.7.  References  Rigney, C., "RADIUS Accounting",, June 2000.

     Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels",,, March 1997.

     Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
        I.  Goyret, "RADIUS Attributes for Tunnel Protocol Support",, June 2000.

     Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B.  Palter, "Layer Two Tunneling Protocol "L2TP"",,
        August 1999.

     Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G.  Zorn, "Point-to-Point Tunneling Protocol (PPTP)",,
        July 1999.8.  AcknowledgmentsThanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
   for salient input and review.9.  Authors' AddressesQuestions about this memo can be directed to:

   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004
   USA

   Phone: +1 425 438 8218
   FAX:   +1 425 438 1848
   EMail: [email protected]


   Dave Mitton
   Nortel Networks
   880 Technology Park Drive
   Billerica, MA 01821

   Phone: +1 978 288 4570
   Fax:   +1 978 288 3030
   EMail: [email protected]


   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone: +1 425 936 6605
   Fax:   +1 425 936 7329
   EMail: [email protected]  Full Copyright StatementCopyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Zorn, et al.                 Informational