Skip to main content

Network Access Servers Requirements: Extended RADIUS Practices

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2882.
Author David Mitton
Last updated 2013-03-02 (Latest revision 2000-05-17)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state RFC 2882 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Access Servers Requirements                            D. Mitton
INTERNET-DRAFT                                           Nortel Networks
Category: Informational                                         May 2000
Expires November 2000

                  Network Access Servers Requirements:
                       Extended RADIUS Practices

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

This memo provides information for the Internet community.  This memo
does not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This document is a product of the Network-Access-Server Requirements
(NASREQ), Next Generation, Working Group of the Internet Engineering
Task Force (IETF).  Comments should be submitted to the mailing list

D. Mitton                    Informational                      [Page 1]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000


This document describes current practices implemented in NAS products
that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The pur-
pose of this effort is to give examples that show the need for address-
ing and standardizing these types of ad-hoc functions.  Since many of
these features require a matching server support component, the ability
to deploy and manage interoperable NAS and AAA server products is
severely hindered.

These practices are documented here to show functions that are obviously
desired in developing future AAA protocols for NAS deployment.

This document is a draft submission of the Network Access Server
Requirements (NASREQ) Working Group of the Internet Engineering Task
Force (IETF).  Comments should be submitted to the mailing list

D. Mitton                    Informational                      [Page 2]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

                           Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4

2.  Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . .  5
2.1. Attribute Conflicts  . . . . . . . . . . . . . . . . . . . . .  6
2.2. Attribute Value Conflicts  . . . . . . . . . . . . . . . . . .  6
2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . . .  6
2.3   Vendor Specific Attribute Usage . . . . . . . . . . . . . . .  6
2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . . .  7
2.3.2 Clients that support multiple Vendors:  . . . . . . . . . . .  7

3.  Attribute Data Types  . . . . . . . . . . . . . . . . . . . . .  8

4.  New Messages  . . . . . . . . . . . . . . . . . . . . . . . . .  8

5.  Additional Functions  . . . . . . . . . . . . . . . . . . . . .  9
5.1 Password Change   . . . . . . . . . . . . . . . . . . . . . . .  9
5.2 Authentication Modes  . . . . . . . . . . . . . . . . . . . . . 10
5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Pseudo Users  . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.  Resource Management . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Resource Management Messages  . . . . . . . . . . . . . . . . . 12
6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . . . 12
6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . . . 12

7. Policy Services  . . . . . . . . . . . . . . . . . . . . . . . . 13

8. Accounting Extentions  . . . . . . . . . . . . . . . . . . . . . 14
8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . . . 14

9. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10. Security Considerations . . . . . . . . . . . . . . . . . . . . 15

11. Implementation Documents  . . . . . . . . . . . . . . . . . . . 16
11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 16

13. Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 17
14. Full Copyright Statement  . . . . . . . . . . . . . . . . . . . 17

D. Mitton                    Informational                      [Page 3]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

1.  Introduction

The RADIUS Working Group was formed in 1995 to document the protocol of
the same name, and was chartered to stay within a set of bounds for
dial-in terminal servers.  Unfortunately the real world of Network
Access Servers (NASes) hasn't stayed that small and simple, and contin-
ues to evolve at an amazing rate.

This document shows some of the current implementations on the market
have already outstripped the capabilities of the RADIUS protocol.  A
quite a few features have been developed completely outside the proto-
col.  These features use the RADIUS protocol struture and format, but
employ operations and semantics well beyond the RFC documents.

I learn of the details of these functions from reading industry manuals
and often have to respond to them in competive bid specifications.  As
they become deployed in the field, they gather the force of de-facto

Because they have been done outside scope of the RFCs, they are vendor
specific, and introduce significant problems in offering an interoper-
able product.

1.1.  Disclaimers

The data and numbers in this document have been gleaned from public
sources and vendor documents along the way.      Actual implementation
of many these features and variation from the documentation has not been

This document is a snapshot of known practices at the time of writing.
It is not intended to standardize these practices here, or keep this
document current, beyond initial publication. While some detailed infor-
mation is given, it is not the purpose of this document to directly or
sufficently describe the functions mentioned to the level of a complete
functional specification.

The author has not transcribed copyrighted material, and is not aware of
whether any of these practices have of intellectual property restric-

Any numeric assignments or functional operations are subject to change
by vendors without notice.  I would appreciate any direct input, prefer-
ably first hand, from implementors.

D. Mitton                    Informational                      [Page 4]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

1.2.  Presentation

Without any easy organization for the material, information is arranged
in a simple taxonomy from bottom-up complexity:

-    Attribute Usage

-    Attribute Data Types

-    Message Codes

-    New Operations

2.  Attribute Usage

The RADIUS RFCs define attribute type ranges and specific attribute

-    There are about 70 defined RADIUS attributes:

-    Values 192-223 are reserved for experimental use

-    Values 224-240 are reserved for implementation-specific use

-    Values 241-255 are reserved and should not be used.

Attribute 26 was defined to be the Vendor Specific Attribute (VSA) with
further internal structure to allow vendor expansion.

2.1.  Attribute conflicts

In practice attributes 92-255 are in use by a vendor. And another vendor
also use attributes in the 90-104 range and conflicts with this usage.

To deal with these issues, server vendors have added vendor specific
parameters to their client database files.      The administrator has to
indicate the vendor type of NAS along with the client IP address and
secret, so that the server can disambiguate the attribute usage.

One server has a single large vendors file to describe the mapping all
attributes to an internal format that retains the vendor id.  Another
server implementation uses multiple dictionaries, each indexed to a NAS
and Vendor Model definition list.

D. Mitton                    Informational                      [Page 5]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

2.2.  Attribute Value Conflicts

Adding additional attributes may be more trouble than necessary for sim-
ple features.  Often existing RADIUS attributes could be extended with
additional values (particularly attributes that are enumerated choices).
But in doing such there is no way to guarantee not conflicting with
other vendor's extentions.

2.2.1.  Vendor Specific Enumerations proposal

One proposed solution to this problem was Vendor Specific Enumerations
(VSEs).  That is to imbed the vendor's management ID in the numeric
value (ala VSAs) which would to divide up the attribute value space.
This technique has not seen any acceptance by the working group or other
vendors, however, the vendor did accomplish the goal of not conflicting
with working group additions or other vendor values.

Example dictionary of VSE values:

VALUE   Service-Type        VSE-Authorize-Only       0x06300001

VALUE   Acct-Status-Type    VSE-User-Reject          0x06300001
VALUE   Acct-Status-Type    VSE-Call-Reject          0x06300002
VALUE   Acct-Status-Type    VSE-IPCP-Start           0x06300003
VALUE   Acct-Status-Type    VSE-IPXCP-Start          0x06300004
VALUE   Acct-Status-Type    VSE-ATCP-Start           0x06300005
VALUE   Acct-Status-Type    VSE-Accounting-Restart   0x06300006
VALUE   Acct-Status-Type    VSE-Accounting-Shutoff   0x06300007
VALUE   Acct-Status-Type    VSE-Tunnel-Start         0x06300008
VALUE   Acct-Status-Type    VSE-Tunnel-Stop          0x06300009
VALUE   Acct-Status-Type    VSE-Tunnel-Reject        0x0630000a
VALUE   Acct-Status-Type    VSE-Tunnel-Link-Start    0x0630000b
VALUE   Acct-Status-Type    VSE-Tunnel-Link-Stop     0x0630000c
VALUE   Acct-Status-Type    VSE-MP-Start             0x0630000d
VALUE   Acct-Status-Type    VSE-MP-Stop              0x0630000e
VALUE   Acct-Status-Type    VSE-Line-Seizure         0x0630000f
VALUE   Acct-Status-Type    VSE-Rlogin-Start         0x06300010
VALUE   Acct-Status-Type    VSE-Rlogin-Stop          0x06300011

2.3.  Vendor Specific Attribute Usage

Because attribute 26 Vendor Specific Attributes (VSAs) came late in the
RADIUS working group development,  there were some server implementa-
tions that were late to support them.  Today, there are several leading
implementations of clients that make extensive use of VSAs.  What's

D. Mitton                    Informational                      [Page 6]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

unfortunate is that there is also several different formats of VSAs
implemented.  This is because the RFC suggested format does not support
more than 256 attributes.

2.3.1.  VSAs in use by some clients:

At the time this document was written, the following had be observed:

-    Microsoft: several for MS-CHAP authentication support [9]

-    ACC: 42 [10]

-    Nortel(Bay): about 60 VSAs and 16 VSEs

-    Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header.
     Aptis VSAs have shifted from a regular format to a 4-byte header
     format, due to the large number of attributes implemented.

-    3Com (USR): about 130
     USR VSAs are different than the format suggested in RFC 2138. They
     have a 4 byte type field and have no internal length.

Some vendors that did not initially use VSAs, have shifted in later
releases VSA usage as a configuration option.

2.3.2.  Clients that support Multiple Vendor Attributes

Now that MS-CHAP RADIUS attributes have been published in RFC 2548 [9]
as Microsoft VSA attributes, it will become typical that for NAS clients
that support MS-CHAP authentication to process several different vendor
VSA types.  This has implications for RADIUS servers that filter or
"prune" return attributes based on the vendor make/model of the NAS

One NAS implementation can receive up to three different vendor specific
attribute sets, but will only send attributes according to the "mode"
that has been configured by the operator. This allows it to fit into
environments where the customer has become dependent on a particular set
of RADIUS attributes, and allows the NAS to "drop-in" without server
attribute changes.

D. Mitton                    Informational                      [Page 7]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

There is another NAS that supports 3 vendor attributes sets con-
currently.  That is, it will normally use a combination of different
vendor VSAs in return profiles from the server.  This was done to sup-
port a superset of competing vendor's extentions, as well as it's own,
and include an extentions from a sister product.

3.  Attribute Data Types

The base RFCs define only has 4 basic data types:

-    integer, 32 bit unsigned

-    string, 1-253 bytes, counted.

-    ipaddr, 32 bit IPv4

-    date, 32 bit Unix format.

Since then, various variations have been added:

The tunnel authentication draft [6] adds an optional compound "tag" byte
to tunnel attributes.  These are a single byte prepended to the data
field in order to support sets of attributes to be returned.  The byte
value must be in the range 01-3F hex or it is considered to be data.

Note that there is no native support for IPv6 addresses. In fact IPv6
support is missing in some fixed message components too.

There have been special attribute types created within servers.  For
packet filters, the format called "abinary" was created.  The user
enters an ASCII string filter description in the user profile, but the
server parses it into a binary string before passing it to the NAS.
This lowers the complexity of the NAS parser.  Also a "phonestring"
server data type allows additional data type checking at the entry

4.  New Messages

A number of new message types have been introduced by various parties
over time. The base specification has 6, vendors have added 26.

These fall into a number of categories which are described in the next
section below. Some of these messages are actually used between the
RADIUS server and some other resource server, using a RADIUS-like

D. Mitton                    Informational                      [Page 8]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

protocol to implement new functions.

      6 Accounting Status
               (now Interim Accounting in draft-radius-ext-04.txt)
      7 Password Request
      8 Password Ack
      9 Password Reject
      10 Accounting Message

      21 Resource Free Request
      22 Resource Free Response
      23 Resource Query Request
      24 Resource Query Response
      25 Alternate Resource Reclaim Request
      26 NAS Reb Request
      27 NAS Reb Response

      29 Next Passcode
      30 New Pin
      31 Terminate Session
      32 Password Expired
      33 Event Request
      34 Event Response
      40 Disconnect Request
      41 Disconnect Ack
      42 Disconnect Nak
      43 Change Filters Request
      44 Change Filters Ack
      45 Change Filters Nak
      50 IP Address Allocate
      51 IP Address Release

5.  Additional Functions

These are operations performed using RADIUS extentions and additional
messages types.

5.1.  Password Change

Remotely requested password change operations were described and pro-
posed, but rejected by the working group.  None the less, the feature is
still deployed in a number of products.

Message types:

D. Mitton                    Informational                      [Page 9]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

 - Password Request
 - Password Ack or Reject

5.2.  Authentication Modes

Additional message types have been added to negotiate passcode changes
for token card servers.
 - Next Passcode
 - New PIN
 - Password Expired

They allow the NAS or RADIUS server negotiate passcode changes with an
external security server.

5.3.  Menus

At least two vendors have built menuing interaction systems for use with
terminal dial-ins.

One implementation uses the Reply-Message string as the menu text to be
displayed, and the State attribute to keep track of the place in the
menu.  The menu is displayed using the Access-Challenge message.  The
response is encoded in the User-Password field like an ordinary chal-
lenge sequence would.

Some RADIUS clients have problems with this because they cannot handle
long or multiple Reply-Message attributes that may have embedded car-
riage returns and line-feeds.  The new Echo attribute should also con-
trol echo behavior on the menu response.   Use of the State attribute to
keep track of a Challenge sequence is also standard behavior.

Another implementation uses two vendor attributes (VSA-Menu-Item, and
VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this informa-
tion.  This implementation is vendor specific.

5.4.  Pseudo Users

One client implementation takes advantage of your vanilla RADIUS
server's ability to be used as a remote database server.  By using some
well-known, implementation specific, strings for Username and Password
attributes, the NAS can request information from the server, such as:
Static IP routes, Static IPX routes, or the Message of the Day.

D. Mitton                    Informational                     [Page 10]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

These are called pseudo-user requests, because they use a user entry
with this manufactured name, for purposes other than authentication.

Another client also uses a pseudo-user technique for resolving unknown
Filter-ID(11) values.  An Access-Request message is sent to the RADIUS
server with the Filter-ID as the Username value, the password is a known
string, and the Service-Type is VSE-Authorization-Only.  The response
must also be of the same Service-Type, or the response will be ignored.
The responding profile should contain the IP-Filter VSA attributes that
will define the desired filter.

It should be noticed that pseudo-user profiles could be a security prob-
lem if a specific or operationally invalid Service-Type is not attached
to the profile. The client should test for this returned value, to
prevent normal dial-in users from gaining access via this profile.

6.  Resource Management

Authorized sessions may need to be allocated additional dynamic
resources in order to preform their services.  The most typical is IP
addresses.  The allocation may want to be delayed until needed or coori-
dinated on a scale independent of the RADIUS server.  Additional mes-
sages may be used to allocate and free these resources.  The RADIUS
server may proxy these requests to another server.

Examples: Certain servers can allocate addresses local to the NAS or use
an outboard address server.  Other servers have an internal address pool
capability, which will fill in the Framed-IP-Address attribute with an
assigned value based on pool selected.

6.1.  Managed Resources:

Resources managed include: IP Addresses, Concurrent Logins, Dial-in Port
allocation policies, Tunnel limits and load distribution.

There are several different types of implementation techniques:
 - Explicit request/free resource requests
 - Monitor usage with deamons watching the state
 - Explicit messages to a state deamon
 - Monitor Accounting messages for state changes

D. Mitton                    Informational                     [Page 11]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

6.2.  Resource Management Messages

Messages used for resource management
 - IP Address Allocate
 - IP Address Release

 - Resource Request
 - Resource Response
 - Resource Free Request
 - Resource Free Response
 - Resource Reclaim Request
 - NAS Reboot Request/Reponse

These messages are used to allocate and free resources for a NAS from a
centralized server.  These mechanisms allows the service provider better
administrative control than some automated LAN services, which don't
have policy inputs or controls.

6.3.  Concurrent Logins

The RADIUS protocol was designed to allow stateless servers.  That is,
servers that don't know the status of the active sessions.  However, it
is very important for many service providers to keep track of how many
sessions a given user may have open, and accordingly disallow access.

There are several different techniques used to implement login limits on
a RADIUS enviroment.  Some vendors have build NAS monitoring tools
either into their RADIUS servers, either directly or as auxiliary
deamons, that can check the session status of the controlled NASes by
SNMP or proprietary methods.

Other vendors monitor the RADIUS accesses and accounting messages and
derive state information from the requests.  This monitoring is not as
reliable as directly auditing the NAS, but it is also less vendor
specific, and can work with any RADIUS NAS, provided it sends both
streams to the same server.

Some of the approaches used:
 - SNMP commands
 - Telnet monitor deamon
 - Accounting monitor

6.4.  Authorization Changes:

D. Mitton                    Informational                     [Page 12]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

To implement an active changes to a running session, such as filter
changes or timeout and disconnect, at least one vendor has added a
RADIUS "server" to his NAS. This server accepts messages sent from an
application in the network, and upon matching some session information,
will perform such operations.

Messages sent from Server to NAS

 - Change Filter Request
 - Change Filter Ack / Nak
 - Disconnect Request
 - Disconnect Response

Filters are used to limit the access the user has to the network by res-
tricting the systems and protocols he can send packets to.  Upon fulfil-
ling some registration with an authorization server, the service pro-
vider may wish to remove those restrictions, or disconnect the user.

7.  Policy Services

Some vendors have implemented policy servers using RADIUS as the control
protocol.  Two prominent Policy Managers act as RADIUS proxy filters and
use RADIUS messages to deny access to new sessions that exceed active
policy limits.

One implementation behaves like a RADIUS proxy server, but with a policy
process governing it's forward decisions. Typically a pre-authentication
message (like the new RADIUS draft Service-Type = CallCheck) is emitted
by the NAS upon call arrival. This message will contain only the
Dialed-Number information in the Username field.  The server receives
the Access-Request messages and processes them against it's knowledge of
the network state and the provisioned policies.

An Access-Accept will be returned to the system to accept the call, and
many also contain dynamic policy information and Virtual POP specific
default parameters. When the real PPP authentication is engaged, the
proxy will forwards the Access-Request to a RADIUS server, if this ses-
sion was approved at pre-auth.  It can also process Access-Requests that
were not preceded by a pre-auth exchange, and use the Username field for
information about the desired realm, in it's policy evaluation.

The other implementation performs a similar operations. It uses VSAs in
the Access-Request to distinguish pre-authentication message types.

D. Mitton                    Informational                     [Page 13]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

8.  Accounting Extentions

Traditional Accounting only records session starts and stops which is
pretty boring. Additional session information reporting can be added
easily which gives a better picture of operation in use as they happen.
Some event types are listed below.

8.1.  Auditing/Activity

 - Call or Modem Starts, Stops
 - Tunnel Starts, Stops
 - Tunnel Link Starts & Stops
 - Admin changes

These events if monitored by a stateful server can be used to gather
information about the usage of the network on a user/session basis.
Information about when a particular user entered the network is more
relevant to network service management than attempting track backwards
from low level IP address flows.   Useful information about port usage
across a range of NASes allows service provider to quickly find problem
areas or users.

Information about call failures, successes, and quality are also deemed
important many service providers.

Extending RADIUS accounting is easy, it's suprising that more implemen-
tations have not been made in this area.

9.  Conclusions

In real life RADIUS Servers are becoming rather complex software imple-
mentations.  They are often brokering authentication and authorization
to other authorities or repositories.  Variants of RADIUS protocol is
often used as glue protocol for these type of solutions.

Some of the solutions are kludges that could be cleaned up by better
underlying services.

What this means to the implementor is that RADIUS as the RFCs describe
it is becoming less relevant.  Many additional features require matching
client and server processing message processing.  Without standardiza-
tion of these functions we don't have much interoperability in the field
and much effort is spent in reverse engineering and reaction to unknown

D. Mitton                    Informational                     [Page 14]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

This draft is not a complete survey by any means.  It is a representa-
tive summary of practices that I am aware of at the time of writing.   I
still appreciate input from vendors or users on practices and details
known, and particularly any reference material you can pass me.

10.  Security Considerations

This document documents known practices, and does not propose any par-
ticular new protocols. Extentions to RADIUS protocols create new secu-
rity implications because of their functions go beyond those considered
in the RFCs.  Some of these include:

 - The ability to change passwords via a RADIUS exchange was
   deliberately left out of the protocol by the working group, because
   of security concerns.
 - The Pseudo-User profiles and the Call-Check operation may allow
   unintended access if static and well-know account names and passwords
   are allowed to be used by regular interactive accounts.
 - Resource Management operations must be protected from denial of
   service attacks.
 - Client side authorization change exchanges need to be secured from
   attacks that could disconnect or restrict user services.

D. Mitton                    Informational                     [Page 15]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

11.  Implementation Documents

Information about the following implementations can be obtained from the
respective owners.  Most listed are availible from the manufacturer's
web site.

11.1.  Clients:

- 3Com(USR) Total Control Hub
- Ericsson(ACC) Tigris
        draft-ilgun-radius-accvsa-01.txt, Dec 1998
- Lucent(Ascend) MAX TNT
- Lucent(Livingston) Portmaster
- Nortel(Aptis) CVX 1800
- Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
- Intel(Shiva)

11.2.  Servers:

- Ericsson(ACC) Virtual Port Server Manager
- Funk Steel-Belted RADIUS
- Intel(Shiva) Access Manager
- Lucent(Ascend) Access Control
- Lucent(Ascend) NavisAccess
- Lucent(Ascend) Modified Livingston 1.16
- Lucent(Livingston) V2.01
- Lucent(Livingston) ABM
- Lucent Port Authority
- MERIT AAA Servers
- Nortel(Bay Networks) BaySecure Access Control
- Nortel Preside Radius
- Nortel CVX Policy Manager

12.  References

[1] C. Rigney, "Remote Authentication Dial In User Service
    (RADIUS)", RFC 2138, April 1977.

[2] C. Rigney, "RADIUS Accounting", RFC 2139, April 1977.

[3] C. Rigney, "Remote Authentication Dial In User Service
    (RADIUS)", draft-ietf-radius-radius-v2-01.txt, May 1999

[4] C. Rigney, "RADIUS Accounting", draft-ietf-radius-

D. Mitton                    Informational                     [Page 16]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

    accounting-v2-01.txt, May 1999.

[5] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", draft-ietf-
    radius-ext-04.txt,  May 1999

[6] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for
    Tunnel Protocol Support", draft-ietf-radius-tunnel-auth-09.txt,
    August 1999

[7] G. Zorn, D. Mitton, "RADIUS Accounting Modifications for Tunnel Pro-
    tocol Support",draft-ietf-radius-tunnel-acct-04.txt, August 1999

[8] Aboba, Zorn, "Implementation of PPTP/L2TP Compulsory Tunneling via
    RADIUS", draft-ietf-radius-tunnel-imp-05.txt, August 1999.

[9] G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", RFC 2548,
    March 1999

[10] K. Ilgun, "RADIUS Vendor Specific Attributes for ACC/Ericsson
    Datacom Access", draft-ilgun-radius-accvsa-01.txt, December 1998

13.  Author's Address

David Mitton
Nortel Networks
8 Federal St
Billerica, MA 01821


14.  Full Copyright Statement

Copyright (C) The Internet Society (Feb 2000). All Rights Reserved.

This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, 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,

D. Mitton                    Informational                     [Page 17]
INTERNET-DRAFT         Extended RADIUS Practices                May 2000

except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards 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

D. Mitton                    Informational                     [Page 18]