RADIUS Attributes for Tunnel Protocol Support (RFC2868)
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
G. Zorn: AUTHOR [+6]
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
Network Working Group G. Zorn
Request for Comments: 2868 Cisco Systems, Inc.
Updates: RFC 2865 D. Leifer
Category: Informational A. Rubens
RADIUS Attributes for Tunnel Protocol Support
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document defines a set of RADIUS attributes designed to support
the provision of compulsory tunneling in dial-up networks.
Many applications of tunneling protocols such as L2TP involve dial-up
network access. Some, such as the provision of access to corporate
intranets via the Internet, are characterized by voluntary tunneling:
the tunnel is created at the request of the user for a specific
purpose. Other applications involve compulsory tunneling: the tunnel
is created without any action from the user and without allowing the
user any choice in the matter. In order to provide this
functionality, new RADIUS attributes are needed to carry the
tunneling information from the RADIUS server to the tunnel end
points; this document defines those attributes. Specific
recommendations for, and examples of, the application of these
attributes for L2TP can be found in RFC 2809.
2. Specification of Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .
Multiple instances of each of the attributes defined below may be
included in a single RADIUS packet. In this case, the attributes to
be applied to any given tunnel SHOULD all contain the same value in
their respective Tag fields; otherwise, the Tag field SHOULD NOT be
If the RADIUS server returns attributes describing multiple tunnels
then the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the
Tunnel-Preference Attribute in the set of Attributes pertaining to
each alternative tunnel. Similarly, if the RADIUS client includes
multiple sets of tunnel Attributes in ...