RADIUS Attributes for Tunnel Protocol Support (RFC2868)
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
G. Zorn: AUTHOR [+5]
This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.
Network Working Group G. Zorn Request for Comments: 2868 Cisco Systems, Inc. Updates: RFC 2865 D. Leifer Category: Informational A. Rubens Ascend Communications J. Shriver Intel Corporation M. Holdrege ipVerse I. Goyret Lucent Technologies June 2000
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.
Zorn, et al. Informational [Page 1]
RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
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 used.
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 an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute.
This Attribute indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a...