RFC2868.docVIP

RFC2868 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属性 (RFC2868-RADIUS Attributes for Tunnel Protocol Support) 摘要 该文档定义了一组Radius属性，用于支持拨号网络中的强制隧道。 1、目的（Motivation） 许多隧道协议的应用，例如L2TP, 都包括拨号网络接入。一部分被定义为非强制隧道，例如通过 Internet提供安全接入到企业网：只有用户申请后才被创建。另外一部分是强制隧道： 隧道直接被创建，不用用户的任何动作，也不用用户做任何选择。为了提供这种功能， 需要定义一些用于从RADIUS服务器传送隧道信息到隧道另一端的新的RADIUS属性。 该文档定义了这些属性。有关这些用于L2TP属性的更详细的描述请参考RFC 2809。 2、要求规范 In this document, the key words MAY, MUST, MUST NOT, optional, recommended, SHOULD, and SHOULD NOT, are to be interpreted as described in [14]. 3、属性 下面定义的每个属性有可能在同一个RADIUS报文中被包含多次。在这种情况下，它们各自属性 中Tag域的值必需相同。否则，就不要使用Tag域。 如果RADIUS服务器返回的属性中描述了多条隧道，则隧道的创建者会把它解释成可选择的。 服务器应该在每组隧道属性集合中包含一个Tunnel-Preference属性。 同样，如果客户端 在Access-Request报文中包含了多组隧道属性集合，则所有属于同一隧道的属性的Tag域 的值应该相同，并且每组属性集合应该包含一个带有合适值的Tunnel-Preference属性。 3.1. Tunnel-Type 描述 该属性描述了将被使用的隧道协议（隧道创建者[tunnel initiator]）或者是已经被使用的 隧道协议（隧道终结者[tunnel terminator]）。该属性可以被包含在Access-Request, Access-Accept 和 Accounting-Request报文中。如果该属性是被包含在隧道创建者发送 的Access-Request报文中，则是暗示RADIUS服务器隧道终点（the tunnel end-point) 所能支持的隧道协议；但是，RADIUS服务器可以忽视这个。隧