Internet Draft                                             Pat R. Calhoun
Category: Experimental                            US Robotics Access Corp.
expires in six months                                           June 1996

      Enhanced Remote Authentication Dial In User Service (RADIUS)
                   Protocol Extension Specifications
                   <draft-calhoun-radius-ext-00.txt>


Status of this Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   Enhanced RADIUS is an extension to the existing RADIUS
   commands/attributes. This document defines the required documentation
   for extensions to the protocol.








Calhoun                                                          [Page 1]

DRAFT           Protocol Extension Specifications              June 1996


Introduction

   The intent of providing for Commands within the Enhanced RADIUS
   Protocol is to permit the RADIUS Protocol to be enhanced in
   functionality. It should be possible for devices to invent, test, or
   discard commands at will. Nevertheless, it is envisioned that
   commands which prove generally useful will eventually be supported by
   many implementations of RADIUS Servers and Network Access Devices;
   therefore it is desirable that commands be documented and publicized.
   In addition, it is necessary to insure that a single command code
   does not have multiple definitions.


   This document specifies a method of Enhanced RADIUS Command Code
   assignement and standards for documentation of new commands. The
   invidual responsible for assignement of the Command code may waive
   the requirement for complete documentation for some cases of
   experimentation, but in general documentation will be required prior
   to code assignment.  Commands will be publicized by publishing their
   documentation as RFCs; inventors of the commands may, of course,
   publicize them in other ways as well.

   Command codes will be assigned by:

      Pat R. Calhoun
      US Robotics Access Corp.
      8100 N. McCormick Blvd.
      Skokie, Il, 60076

      pcalhoun@usr.com
      (847) 933-5181


   Since it will obviously occur that new commands are not supported by
   existing devices, it is recommended that a device respond with a
   Command-Unrecognized packet if it receives an unsupported RADIUS
   Command Type. However, for backward compatibility, it is necessary
   for an implementation to support the fact that the recipient of the
   packet may silently discard the frame.










Calhoun                                                          [Page 2]

DRAFT           Protocol Extension Specifications              June 1996


Documentation of Commands should contain at least the following sections:

   Section 1 - Command Name and Command Code

   Section 2 - Command Meanings

      The meaning of each possible Enhanced RADIUS command relevant to
      this command should be described.  Note that for complex commands,
      where use of the flag field is required, such flags must be
      described in detail.

   Section 3 - Attribute Name and Attribute Code

   Section 4 - Attribute Meanings

      The meaning of each possible Enhanced RADIUS command relevant to
      this command should be described.  Note that for complex commands,
      where use of the flag field is required, such flags must be
      described in detail.

   Section 5 - Motivation

      A detailed explanation of the motivation for inventing a
      particular command, or for choosing a particular form for the
      command, is extremely helpful to those who are not faced (or don't
      realize that they are faced) by the problem that the command is
      designed to solve.

   Section 6 - Description (or Implementation Rules)

      Merely defining the command meanings and providing a statement of
      motivation are not always sufficient to insure that two
      implementations of an option will be able to communicate.
      Therefore, a more complete description should be furnished in most
      cases.  This description might take the form of text, a sample
      implementation, hints to implementers, etc.













Calhoun                                                          [Page 3]