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

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

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