Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
Implementation of L2TP Compulsory Tunneling via RADIUS
通过半径实现L2TP强制隧道
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 Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents.
本文档讨论使用L2TP协议在拨号网络中提供强制隧道时出现的实现问题。这种供应可以通过集成RADIUS和隧道协议来实现。其他隧道协议遇到的实现问题由单独的文档处理。
Voluntary Tunneling In voluntary tunneling, a tunnel is created by the user, typically via use of a tunneling client.
自愿隧道在自愿隧道中，隧道由用户创建，通常通过使用隧道客户端创建。
Compulsory Tunneling In compulsory tunneling, a tunnel is created without any action from the user and without allowing the user any choice.
强制隧道在强制隧道中，创建隧道时不需要用户执行任何操作，也不允许用户进行任何选择。
Tunnel Network Server This is a server which terminates a tunnel. In L2TP terminology, this is known as the L2TP Network Server (LNS).
隧道网络服务器这是终止隧道的服务器。在L2TP术语中，这称为L2TP网络服务器（LNS）。
Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. In L2TP terminology, a NAS performing compulsory tunneling is referred to as the L2TP Access Concentrator (LAC).
网络访问服务器网络访问服务器（NAS）是客户端为了访问网络而联系的设备。在L2TP术语中，执行强制隧道的NAS称为L2TP访问集中器（LAC）。
RADIUS authentication server This is a server which provides for authentication/authorization via the protocol described in [1].
RADIUS身份验证服务器这是一个通过[1]中描述的协议提供身份验证/授权的服务器。
RADIUS proxy In order to provide for the routing of RADIUS authentication requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. Can be used to locate the tunnel endpoint when realm-based tunneling is used.
RADIUS代理为了提供RADIUS身份验证请求的路由，可以使用RADIUS代理。对于NAS，RADIUS代理似乎充当RADIUS服务器；对于RADIUS服务器，代理似乎充当RADIUS客户端。可用于在使用基于领域的隧道时定位隧道端点。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[4]所述。
Many applications of tunneling protocols involve dial-up network access. Some, such as the provisioning of secure 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.
隧道协议的许多应用涉及拨号网络访问。有些，例如通过互联网提供对公司内部网的安全访问，其特点是自愿隧道：隧道是应用户的请求为特定目的而创建的。其他应用程序涉及强制隧道：创建隧道时用户无需执行任何操作，也不允许用户进行任何选择。
Examples of applications that might be implemented using compulsory tunnels are Internet software upgrade servers, software registration servers and banking services. These are all services which, without compulsory tunneling, would probably be provided using dedicated networks or at least dedicated network access servers (NAS), since they are characterized by the need to limit user access to specific hosts.
可以使用强制隧道实现的应用程序示例包括互联网软件升级服务器、软件注册服务器和银行服务。这些都是在没有强制隧道的情况下，可能使用专用网络或至少专用网络访问服务器（NAS）提供的服务，因为它们的特点是需要限制用户对特定主机的访问。
Given the existence of widespread support for compulsory tunneling, however, these types of services could be accessed via any Internet service provider (ISP). The most popular means of authorizing dial-up network users today is through the RADIUS protocol. The use of RADIUS allows the dial-up users' authorization and authentication
然而，鉴于强制隧道的广泛支持，这些类型的服务可以通过任何互联网服务提供商（ISP）访问。当今最流行的授权拨号网络用户的方法是通过RADIUS协议。RADIUS的使用允许拨号用户进行授权和身份验证
data to be maintained in a central location, rather than on each NAS. It makes sense to use RADIUS to centrally administer compulsory tunneling, since RADIUS is widely deployed and was designed to carry this type of information. New RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the NAS. Those attributes are defined in [3].
要在中心位置而不是在每个NAS上维护的数据。使用RADIUS集中管理强制隧道是有意义的，因为RADIUS被广泛部署并设计用于承载此类信息。需要新的RADIUS属性将隧道信息从RADIUS服务器传输到NAS。这些属性在[3]中定义。
Current proposals for routing of tunnel requests include static tunneling, where all users are automatically tunneled to a given endpoint, and realm-based tunneling, where the tunnel endpoint is determined from the realm portion of the userID. User-based tunneling as provided by integration of RADIUS and tunnel protocols offers significant advantages over both of these approaches.
当前对隧道请求路由的建议包括静态隧道（其中所有用户自动通过隧道传输到给定端点）和基于领域的隧道（其中隧道端点由用户ID的领域部分确定）。RADIUS和隧道协议集成所提供的基于用户的隧道比这两种方法都具有显著优势。
Static tunneling requires dedication of a NAS device to the purpose. In the case of an ISP, this is undesirable because it requires them to dedicate a NAS to tunneling service for a given customer, rather than allowing them to use existing NASes deployed in the field. As a result static tunneling is likely to be costly for deployment of a global service.
静态隧道需要NAS设备专用于此目的。对于ISP来说，这是不可取的，因为这要求他们将NAS专用于为给定客户提供隧道服务，而不是允许他们使用部署在现场的现有NASE。因此，对于部署全局服务而言，静态隧道可能代价高昂。
Realm-based tunneling assumes that all users within a given realm wish to be treated the same way. This limits flexibility in account management. For example, BIGCO may desire to provide Janet with an account that allows access to both the Internet and the intranet, with Janet's intranet access provided by a tunnel server located in the engineering department. However BIGCO may desire to provide Fred with an account that provides only access to the intranet, with Fred's intranet access provided by a tunnel network server located in the sales department. Such a situation cannot be accommodated with realm-based tunneling, but can be accommodated via user-based tunneling as enabled by the attributes defined in [3].
基于领域的隧道假设给定领域内的所有用户都希望得到相同的对待。这限制了客户管理的灵活性。例如，BIGCO可能希望向Janet提供一个允许访问Internet和intranet的帐户，Janet的intranet访问由位于工程部门的隧道服务器提供。但是，BIGCO可能希望向Fred提供一个仅提供内部网访问权限的帐户，Fred的内部网访问权限由位于销售部门的隧道网络服务器提供。这种情况不能通过基于领域的隧道来适应，但可以通过[3]中定义的属性启用的基于用户的隧道来适应。
RADIUS-based compulsory tunneling can support both single authentication, where the user is authenticated at the NAS or tunnel server, or dual authentication, where the user is authenticated at both the NAS and the tunnel server. When single authentication is supported, a variety of modes are possible, including telephone-number based authentication. When dual-authentication is used, a number of modes are available, including dual CHAP authentications;
基于RADIUS的强制隧道可以同时支持单一身份验证（用户在NAS或隧道服务器上进行身份验证）和双重身份验证（用户在NAS和隧道服务器上进行身份验证）。当支持单一身份验证时，可以使用多种模式，包括基于电话号码的身份验证。当使用双重身份验证时，可以使用多种模式，包括双重CHAP身份验证；
CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP authentication, using the same EAP type for both authentications. EAP is described in [5].
CHAP/EAP认证；CHAP/PAP（令牌）认证；和EAP/EAP身份验证，对两种身份验证使用相同的EAP类型。EAP如[5]所述。
The alternatives are described in more detail below.
下文将更详细地描述备选方案。
Single authentication alternatives include:
单一身份验证备选方案包括：
NAS authentication NAS authentication with RADIUS reply forwarding Tunnel server authentication
NAS身份验证使用RADIUS应答转发隧道服务器身份验证的NAS身份验证
With this approach, authentication and authorization (including tunneling information) occurs once, at the NAS. The advantages of this approach are that it disallows network access for unauthorized NAS users, and permits accounting to done at the NAS. Disadvantages are that it requires that the tunnel server trust the NAS, since no user authentication occurs at the tunnel server. Due to the lack of user authentication, accounting cannot take place at the tunnel server with strong assurance that the correct party is being billed.
使用这种方法，身份验证和授权（包括隧道信息）在NAS上只发生一次。此方法的优点是，它不允许未经授权的NAS用户访问网络，并允许在NAS上进行记帐。缺点是它要求隧道服务器信任NAS，因为在隧道服务器上不会发生用户身份验证。由于缺少用户身份验证，无法在隧道服务器上进行记帐，同时可以很好地保证向正确的一方计费。
NAS-only authentication is most typically employed along with LCP forwarding and tunnel authentication, both of which are supported in L2TP, described in [2]. Thus, the tunnel server can be set up to accept all calls occurring within authenticated tunnels, without requiring PPP authentication. However, this approach is not compatible with roaming, since the tunnel server will typically only be set up to accept tunnels from a restricted set of NASes. A typical initiation sequence looks like this:
仅NAS身份验证通常与LCP转发和隧道身份验证一起使用，L2TP支持这两种身份验证，如[2]所述。因此，可以将隧道服务器设置为接受在经过身份验证的隧道内发生的所有呼叫，而无需PPP身份验证。但是，这种方法与漫游不兼容，因为隧道服务器通常只设置为接受来自一组受限NASE的隧道。典型的启动顺序如下所示：
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: NCP negotiation
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS, and the PPP LCP negotiation between the client and the NAS. In order to authenticate the client, the NAS will send a RADIUS Access-Request to the RADIUS server and will receive a RADIUS Access-Accept including tunnel attributes, or an Access-Reject.
该过程从对NAS的传入呼叫以及客户端和NAS之间的PPP LCP协商开始。为了对客户端进行身份验证，NAS将向RADIUS服务器发送RADIUS访问请求，并接收包含隧道属性的RADIUS访问接受或访问拒绝。
In the case where an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data will begin to flow through the tunnel. The NAS will typically employ LCP forwarding, although it is also possible for the tunnel server to renegotiate LCP. If LCP renegotiation is to be permitted, the NAS SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server.
在指示L2TP隧道的情况下，如果以前不存在控制连接，NAS现在将启动控制连接，NAS和隧道服务器将启动呼叫。此时，数据将开始流经隧道。NAS通常采用LCP转发，尽管隧道服务器也可以重新协商LCP。如果允许LCP重新协商，NAS不应发送完成LCP协商的LCP确认。NAS将发送LCP配置请求数据包，而不是发送LCP确认，如[6]所述。然后，客户端可以重新协商LCP，并且从该点向前，来自客户端的所有PPP数据包将被封装并发送到隧道服务器。
Since address assignment will occur at the tunnel server, the client and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will occur between the client and the tunnel server.
由于地址分配将在隧道服务器上进行，因此客户端和NAS不得开始NCP协商。相反，NCP协商将在客户端和隧道服务器之间进行。
With this approach, authentication and authorization occurs once at the NAS and the RADIUS reply is forwarded to the tunnel server. This approach disallows network access for unauthorized NAS users; does not require trust between the NAS and tunnel server; and allows for accounting to be done at both ends of the tunnel. However, it also requires that both ends share the same secret with the RADIUS server, since that is the only way that the tunnel server can check the RADIUS Access-Reply.
使用这种方法，身份验证和授权在NAS上发生一次，RADIUS应答被转发到隧道服务器。这种方法不允许未经授权的NAS用户访问网络；不需要NAS和隧道服务器之间的信任；并允许在隧道两端进行核算。但是，它还要求两端与RADIUS服务器共享相同的机密，因为这是隧道服务器可以检查RADIUS访问回复的唯一方法。
In this approach, the tunnel server will share secrets with all the NASes and associated RADIUS servers, and there is no provision for LCP renegotiation by the tunnel server. Also, the tunnel server will need to know how to handle and verify RADIUS Access-Accept messages.
在这种方法中，隧道服务器将与所有NASE和关联的RADIUS服务器共享机密，并且不允许隧道服务器重新协商LCP。此外，隧道服务器还需要知道如何处理和验证RADIUS Access Accept消息。
While this scheme can be workable if the reply comes directly from a RADIUS server, it would become unmanageable if a RADIUS proxy is involved, since the reply would be authenticated using the secret shared by the client and proxy, rather than the RADIUS server. As a result, this scheme is impractical.
虽然如果回复直接来自RADIUS服务器，此方案是可行的，但如果涉及RADIUS代理，则该方案将变得不可管理，因为回复将使用客户端和代理共享的秘密而不是RADIUS服务器进行身份验证。因此，这项计划是不切实际的。
In this scheme, authentication and authorization occurs once at the tunnel server. This requires that the NAS determine that the user needs to be tunneled (through RADIUS or NAS configuration). Where RADIUS is used, the determination can be made using one of the following methods:
在此方案中，身份验证和授权在隧道服务器上发生一次。这需要NAS确定用户需要隧道（通过RADIUS或NAS配置）。如果使用半径，可使用以下方法之一进行测定：
Telephone-number based authentication UserID
基于电话号码的身份验证用户ID
Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, authorization and subsequent tunnel attributes can be based on the phone number originating the call, or the number being called. This allows the RADIUS server to authorize users based on the calling phone number or to provide tunnel attributes based on the Calling-Station-Id or Called-Station-Id. Similarly, in L2TP the tunnel server MAY choose to reject or accept the call based on the Dialed Number and Dialing Number included in the L2TP Incoming-Call-Request packet sent by the NAS. Accounting can also take place based on the Calling-Station-Id and Called-Station-Id.
使用主叫站Id和被叫站Id RADIUS属性，授权和后续隧道属性可以基于发起呼叫的电话号码或正在呼叫的号码。这允许RADIUS服务器根据主叫电话号码授权用户，或根据主叫站Id或被叫站Id提供隧道属性。类似地，在L2TP中，隧道服务器可以根据NAS发送的L2TP传入呼叫请求包中包含的拨号号码和拨号号码选择拒绝或接受呼叫。也可以根据主叫站Id和被叫站Id进行计费。
RADIUS as defined in [1] requires that an Access-Request packet contain a User-Name attribute as well as either a CHAP-Password or User-Password attribute, which must be non-empty. To satisfy this requirement the Called-Station-Id or Calling-Station-Id MAY be furnished in the User-Name attribute and a dummy value MAY be used in the User-Password or CHAP-Password attribute.
[1]中定义的RADIUS要求访问请求数据包包含用户名属性以及CHAP密码或用户密码属性，该属性必须为非空。为满足此要求，可在用户名属性中提供被叫站Id或主叫站Id，并可在用户密码或CHAP密码属性中使用伪值。
In the case of telephone-number based authentication, a typical initiation sequence looks like this:
对于基于电话号码的身份验证，典型的启动顺序如下所示：
Client and NS: Call Connected
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
Client and NS: Call Connected
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS. If configured for telephone-number based authentication, the NAS sends a RADIUS Access-Request containing the Calling-Station-Id and the Called-Station-Id attributes. The RADIUS server will then respond with a RADIUS Access-Accept or Access-Reject.
该过程从对NAS的传入呼叫开始。如果配置为基于电话号码的身份验证，NAS将发送包含呼叫站Id和被叫站Id属性的RADIUS访问请求。然后，RADIUS服务器将响应RADIUS访问接受或访问拒绝。
The NAS MUST NOT begin PPP authentication before bringing up the tunnel. If timing permits, the NAS MAY bring up the tunnel prior to beginning LCP negotiation with the peer. If this is done, then LCP will not need to be renegotiated between the peer and tunnel server, nor will LCP forwarding need to be employed.
在启动隧道之前，NAS不得开始PPP身份验证。如果时间允许，NAS可以在与对等方开始LCP协商之前启动隧道。如果完成此操作，则无需在对等服务器和隧道服务器之间重新协商LCP，也无需使用LCP转发。
If the initial telephone-number based authentication is unsuccessful, the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS MUST send an LCP-Terminate and disconnect the user.
如果初始基于电话号码的身份验证失败，RADIUS服务器将发送RADIUS访问拒绝。在这种情况下，NAS必须发送LCP终止并断开用户连接。
In the case where tunnel attributes are included in the RADIUS Access-Accept, and an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before. This is accomplished by sending an L2TP Start-Control-Connection-Request message to the tunnel server. The tunnel server will then reply with an L2TP Start-Control-Connection-Reply. If this message indicates an error, or if the control connection is terminated at any future time, then the NAS MUST send an LCP-Terminate and disconnect the user.
如果RADIUS Access Accept中包含隧道属性，并且指示L2TP隧道，则NAS现在将启动控制连接（如果以前不存在）。这是通过向隧道服务器发送L2TP启动控制连接请求消息来实现的。然后，隧道服务器将使用L2TP启动控制连接回复进行回复。如果此消息指示错误，或者如果控制连接在将来任何时候终止，则NAS必须发送LCP Terminate并断开用户连接。
The NAS will then send an L2TP Incoming-Call-Request message to the tunnel server. Among other things, this message will contain the Call Serial Number, which along with the NAS-IP-Address and Tunnel-Server-Endpoint is used to uniquely identify the call. The tunnel server will reply with an L2TP Incoming-Call-Reply message. If this message indicates an error, then the NAS MUST send an LCP-Terminate and disconnect the user. If no error is indicated, the NAS then replies with an L2TP Incoming-Call-Connected message.
NAS随后将向隧道服务器发送L2TP传入呼叫请求消息。除其他外，此消息将包含呼叫序列号，该序列号与NAS IP地址和隧道服务器端点一起用于唯一标识呼叫。隧道服务器将用L2TP呼入应答消息进行应答。如果此消息指示错误，则NAS必须发送LCP终止并断开用户连接。如果未指示错误，NAS随后会回复L2TP来电连接消息。
At this point, data can begin to flow through the tunnel. If LCP negotiation had been begun between the NAS and the client, then LCP forwarding may be employed, or the client and tunnel server will now renegotiate LCP and begin PPP authentication. Otherwise, the client and tunnel server will negotiate LCP for the first time, and then move on to PPP authentication.
在这一点上，数据可以开始流经隧道。如果NAS和客户端之间已开始LCP协商，则可以使用LCP转发，或者客户端和隧道服务器现在将重新协商LCP并开始PPP身份验证。否则，客户端和隧道服务器将第一次协商LCP，然后转到PPP身份验证。
If a renegotiation is required, at the time that the renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request Packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to
如果需要重新协商，则在重新协商开始时，NAS不应发送完成LCP协商的LCP确认，并且客户机和NAS不得已开始NCP协商。NAS将发送LCP配置请求数据包，而不是发送LCP确认，如[6]所述。然后，客户机可以重新协商LCP，并且从该点向前，来自客户机的所有PPP数据包将被封装并发送到服务器
the tunnel server. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
隧道服务器。LCP重新协商结束后，NCP阶段将开始，隧道服务器将为客户端分配一个地址。
If L2TP is being used as the tunnel protocol, and LCP renegotiation is required, the NAS MAY in its initial setup notification include a copy of the LCP CONFACKs sent in each direction which completed LCP negotiation. The tunnel server MAY then use this information to avoid an additional LCP negotiation. With L2TP, the initial setup notification can also include the authentication information required to allow the tunnel server to authenticate the user and decide to accept or decline the connection. However, in telephone-number based authentication, PPP authentication MUST NOT occur prior to the NAS bringing up the tunnel. As a result, L2TP authentication forwarding MUST NOT be employed.
如果L2TP被用作隧道协议，并且需要重新协商LCP，NAS可在其初始设置通知中包括一份在每个方向发送的LCP确认副本，该副本已完成LCP协商。然后，隧道服务器可以使用此信息来避免额外的LCP协商。对于L2TP，初始设置通知还可以包括允许隧道服务器对用户进行身份验证并决定接受或拒绝连接所需的身份验证信息。但是，在基于电话号码的身份验证中，在NAS启动隧道之前，不得进行PPP身份验证。因此，不得采用L2TP身份验证转发。
In performing the PPP authentication, the tunnel server can access its own user database, or alternatively can send a RADIUS Access-Request. The latter approach is useful in cases where authentication forwarding is enabled, such as with roaming or shared use networks. In this case, the RADIUS and tunnel servers are under the same administration and are typically located close together, possibly on the same LAN. Therefore having the tunnel server act as a RADIUS client provides for unified user administration. Note that the tunnel server's RADIUS Access-Request is typically sent directly to the local RADIUS server rather than being forwarded via a proxy.
在执行PPP身份验证时，隧道服务器可以访问自己的用户数据库，或者发送RADIUS访问请求。后一种方法在启用身份验证转发的情况下非常有用，例如漫游或共享使用网络。在这种情况下，RADIUS和隧道服务器处于同一管理之下，通常位于一起，可能位于同一LAN上。因此，让隧道服务器充当RADIUS客户端可以提供统一的用户管理。请注意，隧道服务器的RADIUS访问请求通常直接发送到本地RADIUS服务器，而不是通过代理转发。
The interactions involved in initiation of a compulsory tunnel with telephone-number based authentication are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it is understood that the client participates via PPP negotiation, authentication and subsequent data interchange with the Tunnel Server.
使用基于电话号码的身份验证启动强制隧道所涉及的交互概述如下。为了简化下面的图表，我们省略了客户机。然而，可以理解，客户机通过PPP协商、认证以及与隧道服务器的后续数据交换参与。
INITIATION SEQUENCE
起始顺序
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
将传入呼叫请求消息发送到隧道服务器将传入呼叫回复发送到NAS将传入呼叫连接消息发送到隧道服务器
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting
通过隧道发送数据重新协商LCP，验证用户身份，启动IPCP，启动记帐
Since authentication will occur only at the tunnel-server, tunnel initiation must occur prior to user authentication at the NAS. As a result, this scheme typically uses either the domain portion of the userID or attribute-specific processing on the RADIUS server. Since the user identity is never verified by the NAS, either the tunnel server owner must be willing to be billed for all incoming calls, or other information such as the Calling-Station-Id must be used to verify the user's identity for accounting purposes.
由于身份验证将仅在隧道服务器上进行，因此隧道启动必须在NAS上进行用户身份验证之前进行。因此，此方案通常使用用户ID的域部分或RADIUS服务器上特定于属性的处理。由于NAS从未验证用户身份，因此隧道服务器所有者必须愿意为所有传入呼叫付费，或者必须使用其他信息（如呼叫站Id）来验证用户身份以进行计费。
In attribute-specific processing RADIUS may be employed and an attribute is used to signal tunnel initiation. For example, tunnel attributes can be sent back if the User-Password attribute contains a dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID beginning with a special character ('*') could be used to indicate the need to initiate a tunnel. When attribute-specific processing is used, the tunnel server may need to renegotiate LCP.
在属性中，可以使用特定的处理半径，并使用属性来表示隧道启动。例如，如果用户密码属性包含伪值（例如“tunnel”或“L2TP”），则可以发回隧道属性。或者，可以使用以特殊字符（“*”）开头的用户标识来表示需要启动隧道。使用特定于属性的处理时，隧道服务器可能需要重新协商LCP。
Another solution involves using the domain portion of the userID; all users in domain X would be tunneled to address Y. This proposal supports compulsory tunneling, but does not provide for user-based tunneling.
另一个解决方案涉及使用用户ID的域部分；域X中的所有用户都将被隧道传输到地址Y。该提案支持强制隧道传输，但不提供基于用户的隧道传输。
In order for the NAS to start accounting on the connection, it would need to use the identity claimed by the user in authenticating to the tunnel server, since it did not verify the identity via RADIUS. However, in order for that to be of any use in accounting, the tunnel endpoint needs to have an account relationship with the NAS owner. Thus even if a user has an account with the NAS owner, they cannot use this account for tunneling unless the tunnel endpoint also has a business relationship with the NAS owner. Thus this approach is incompatible with roaming.
为了让NAS在连接上开始记帐，它需要使用用户在向隧道服务器进行身份验证时声明的身份，因为它没有通过RADIUS验证身份。但是，为了使其在记帐中发挥任何作用，隧道端点需要与NAS所有者建立帐户关系。因此，即使用户拥有NAS所有者的帐户，他们也不能将此帐户用于隧道，除非隧道端点也与NAS所有者有业务关系。因此，这种方法与漫游不兼容。
A typical initiation sequence involving use of the domain portion of the userID looks like this:
涉及使用用户ID的域部分的典型启动序列如下所示：
Client and NAS: Call Connected Client and NAS: PPP LCP negotiation Client and NAS: Authentication NAS to Tunnel Server: L2TP Incoming-Call-Request Tunnel Server to NAS: L2TP Incoming-Call-Reply NAS to Tunnel Server: L2TP Incoming-Call-Connected Client and Tunnel Server: PPP LCP re-negotiation Client and Tunnel Server: PPP authentication Tunnel Server to RADIUS Server: RADIUS Access-request (optional) RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject Client and Tunnel Server: NCP negotiation
客户端和NAS：呼叫连接客户端和NAS：PPP LCP协商客户端和NAS：验证NAS到隧道服务器：L2TP传入呼叫请求隧道服务器到NAS：L2TP传入呼叫应答NAS到隧道服务器：L2TP传入呼叫连接客户端和隧道服务器：PPP LCP重新协商客户端和隧道服务器：PPP验证隧道服务器到RADIUS服务器：RADIUS访问请求（可选）RADIUS服务器到隧道服务器：RADIUS访问接受/访问拒绝客户端和隧道服务器：NCP协商
The process begins with an incoming call to the NAS, and the PPP LCP negotiation between the Client and NAS. The authentication process will then begin and based on the domain portion of the userID, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data MAY begin to flow through the tunnel. The client and tunnel server MAY now renegotiate LCP and will complete PPP authentication.
该过程从对NAS的传入呼叫以及客户端和NAS之间的PPP LCP协商开始。然后，身份验证过程将开始，并且基于用户ID的域部分，NAS现在将启动控制连接（如果以前不存在），NAS和隧道服务器将启动呼叫。此时，数据可能开始流经隧道。客户端和隧道服务器现在可以重新协商LCP，并将完成PPP身份验证。
At the time that the renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. In single authentication compulsory tunneling, L2TP authentication forwarding MUST NOT be employed. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
在重新协商开始时，NAS不应发送完成LCP协商的LCP确认，客户机和NAS也不应开始NCP协商。NAS将发送LCP配置请求数据包，而不是发送LCP确认，如[6]所述。然后，客户端可以重新协商LCP，并且从该点向前，来自客户端的所有PPP数据包将被封装并发送到隧道服务器。在单身份验证强制隧道中，不得使用L2TP身份验证转发。LCP重新协商结束后，NCP阶段将开始，隧道服务器将为客户端分配一个地址。
In performing the PPP authentication, the tunnel server can access its own user database, or it MAY send a RADIUS Access-Request. After the tunnel has been brought up, the NAS and tunnel server can start accounting.
在执行PPP身份验证时，隧道服务器可以访问自己的用户数据库，也可以发送RADIUS访问请求。启动隧道后，NAS和隧道服务器可以开始记帐。
The interactions are summarized below.
相互作用总结如下。
INITIATION SEQUENCE
起始顺序
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
Send
Start-Control-Connection-Reply
to NAS
ENDIF
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
将传入呼叫请求消息发送到隧道服务器将传入呼叫回复发送到NAS将传入呼叫连接消息发送到隧道服务器
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting
通过隧道发送数据重新协商LCP，验证用户身份，启动IPCP，启动记帐
In this scheme, authentication occurs both at the NAS and the tunnel server. This requires the dial-up client to handle dual authentication, with attendant LCP re-negotiations. In order to allow the NAS and tunnel network server to authenticate against the same database, this requires RADIUS client capability on the tunnel network server, and possibly a RADIUS proxy on the NAS end.
在此方案中，身份验证同时发生在NAS和隧道服务器上。这要求拨号客户端处理双重身份验证，并伴随LCP重新协商。为了允许NAS和隧道网络服务器根据同一数据库进行身份验证，这需要隧道网络服务器上具有RADIUS客户端功能，并且可能需要NAS端具有RADIUS代理。
Advantages of dual authentication include support for authentication and accounting at both ends of the tunnel; use of a single userID/password pair via implementation of RADIUS on the tunnel network server; no requirement for telephone-number based authentication, or attribute-specific processing on the RADIUS server.
双重身份验证的优点包括支持隧道两端的身份验证和记帐；通过在隧道网络服务器上实施RADIUS，使用单个用户ID/密码对；无需在RADIUS服务器上进行基于电话号码的身份验证或特定于属性的处理。
Dual authentication allows for accounting records to be generated on both the NAS and tunnel server ends, making auditing possible. Also the tunnel endpoint does not need to have an account relationship with the NAS owner, making this approach compatible with roaming.
双重身份验证允许在NAS和隧道服务器端生成记帐记录，从而使审核成为可能。此外，隧道端点不需要与NAS所有者建立帐户关系，从而使此方法与漫游兼容。
A disadvantage of dual authentication is that unless LCP forwarding is used, LCP will need to be renegotiated; some clients do not support it at all, and others only support only a subset of the dual authentication combinations. Feasible combinations include PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5].
双重认证的缺点是，除非使用LCP转发，否则LCP将需要重新协商；一些客户端根本不支持它，而另一些客户端只支持双重身份验证组合的一个子集。可行的组合包括PAP/PAP（令牌）、PAP/CHAP、PAP/EAP、CHAP/PAP（令牌）、CHAP/CHAP、CHAP/EAP、EAP/CHAP和EAP/EAP。EAP如[5]所述。
In the case of a dual authentication, a typical initiation sequence looks like this:
在双重身份验证的情况下，典型的启动顺序如下所示：
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation (optional)
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation (optional)
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS. The client and NAS then begin LCP negotiation. Subsequently the PPP authentication phase starts, and the NAS sends a RADIUS Access-Request message to the RADIUS server. If the authentication is successful, the RADIUS server responds with a RADIUS Access-Accept containing tunnel attributes.
该过程从对NAS的传入呼叫开始。然后，客户端和NAS开始LCP协商。随后，PPP认证阶段开始，NAS向RADIUS服务器发送RADIUS访问请求消息。如果身份验证成功，RADIUS服务器将使用包含隧道属性的RADIUS访问接受进行响应。
In the case where an L2TP tunnel is indicated, the NAS will now bring up a control connection if none existed before, and the NAS and tunnel server will bring up the call. At this point, data MAY begin to flow through the tunnel. The client and tunnel server MAY now renegotiate LCP and go through another round of PPP authentication. At the time that this renegotiation begins, the NAS SHOULD NOT have
在指示L2TP隧道的情况下，如果以前不存在控制连接，NAS现在将启动控制连接，NAS和隧道服务器将启动呼叫。此时，数据可能开始流经隧道。客户端和隧道服务器现在可以重新协商LCP并进行另一轮PPP身份验证。在重新协商开始时，NAS不应
sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client.
发送LCP确认以完成LCP协商，并且客户端和NAS不得已开始NCP协商。NAS将发送LCP配置请求数据包，而不是发送LCP确认，如[6]所述。然后，客户端可以重新协商LCP，并且从该点向前，来自客户端的所有PPP数据包将被封装并发送到隧道服务器。LCP重新协商结束后，NCP阶段将开始，隧道服务器将为客户端分配一个地址。
If L2TP is being used as the tunnel protocol, the NAS MAY in its initial setup notification include a copy of the LCP CONFACKs sent in each direction which completed LCP negotiation. The tunnel server MAY then use this information to avoid an additional LCP negotiation. With L2TP, the initial setup notification can also include the authentication information required to allow the tunnel server to authenticate the user and decide to accept or decline the connection. However, this facility creates a vulnerability to replay attacks, and can create problems in the case where the NAS and tunnel server authenticate against different RADIUS servers. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed.
如果L2TP被用作隧道协议，NAS可在其初始设置通知中包括在完成LCP协商的每个方向上发送的LCP确认副本。然后，隧道服务器可以使用此信息来避免额外的LCP协商。对于L2TP，初始设置通知还可以包括允许隧道服务器对用户进行身份验证并决定接受或拒绝连接所需的身份验证信息。但是，此功能会创建一个易受重播攻击的漏洞，并且在NAS和隧道服务器针对不同RADIUS服务器进行身份验证的情况下会产生问题。因此，在通过RADIUS实现基于用户的隧道时，不应采用L2TP身份验证转发。
In performing the PPP authentication, the tunnel server can access its own user database, or it MAY send a RADIUS Access-Request. After the tunnel has been brought up, the NAS and tunnel server can start accounting.
在执行PPP身份验证时，隧道服务器可以访问自己的用户数据库，也可以发送RADIUS访问请求。启动隧道后，NAS和隧道服务器可以开始记帐。
The interactions involved in initiation of a compulsory tunnel with dual authentication are summarized below.
下面总结了启动具有双重身份验证的强制隧道所涉及的交互。
INITIATION SEQUENCE
起始顺序
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with userID and
authentication data
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with userID and
authentication data
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send Incoming-Call-Request message to Tunnel Server Send Incoming-Call-Reply to NAS Send Incoming-Call-Connected message to Tunnel Server
将传入呼叫请求消息发送到隧道服务器将传入呼叫回复发送到NAS将传入呼叫连接消息发送到隧道服务器
Send data through the tunnel Re-negotiate LCP, authenticate user, bring up IPCP, start accounting ENDIF
通过隧道发送数据重新协商LCP，验证用户身份，启动IPCP，启动记帐ENDIF
The tear down of a compulsory tunnel involves an interaction between the client, NAS and Tunnel Server. This interaction is virtually identical regardless of whether telephone-number based authentication, single authentication, or dual authentication is being used. In any of the cases, the following events occur:
强制隧道的拆除涉及客户端、NAS和隧道服务器之间的交互。无论使用的是基于电话号码的身份验证、单一身份验证还是双重身份验证，这种交互实际上是相同的。在任何情况下，都会发生以下事件：
Tunnel Server to NAS: L2TP Call-Clear-Request (optional) NAS to Tunnel Server: L2TP Call-Disconnect-Notify
隧道服务器到NAS:L2TP呼叫清除请求（可选）NAS到隧道服务器：L2TP呼叫断开通知
Tunnel termination can occur due to a client request (PPP termination), a tunnel server request (Call-Clear-Request), or a line problem (call disconnect).
隧道终止可能由于客户端请求（PPP终止）、隧道服务器请求（呼叫清除请求）或线路问题（呼叫断开）而发生。
In the case of a client-requested termination, the tunnel server MUST terminate the PPP session. The tunnel server MUST subsequently send a Call-Clear-Request to the NAS. The NAS MUST then send a Call-Disconnect-Notify message to the tunnel server, and will disconnect the call.
在客户端请求终止的情况下，隧道服务器必须终止PPP会话。隧道服务器随后必须向NAS发送呼叫清除请求。然后，NAS必须向隧道服务器发送呼叫断开通知消息，并将断开呼叫。
The NAS MUST also respond with a Call-Disconnect-Notify message and disconnection if it receives a Call-Clear-Request from the tunnel server without a client-requested termination.
如果NAS接收到来自隧道服务器的呼叫清除请求而没有客户端请求的终止，则还必须使用Call Disconnect Notify（呼叫断开通知）消息和disconnection（断开）响应。
In the case of a line problem or user hangup, the NAS MUST send a Call-Disconnect-Notify to the tunnel server. Both sides will then tear down the call.
如果线路出现问题或用户挂断，NAS必须向隧道服务器发送呼叫断开通知。然后双方都将取消这一呼吁。
The interactions involved in termination of a compulsory tunnel are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it is understood that the client MAY participate via PPP termination and disconnection.
强制隧道终止涉及的相互作用总结如下。为了简化下面的图表，我们省略了客户机。但是，可以理解，客户可以通过PPP终止和断开连接参与。
TERMINATION SEQUENCE
终止序列
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
ENDIF
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
ENDIF
In the case that the NAS and the tunnel server are using distinct RADIUS servers, some interesting cases can arise in the provisioning of compulsory tunnels.
在NAS和隧道服务器使用不同的RADIUS服务器的情况下，强制隧道的供应可能会出现一些有趣的情况。
If distinct RADIUS servers are being used, it is likely that distinct userID/password pairs will be required to complete the RADIUS and tunnel authentications. One pair will be used in the initial PPP authentication with the NAS, and the second pair will be used for authentication at the tunnel server.
如果使用不同的RADIUS服务器，则可能需要不同的用户ID/密码对来完成RADIUS和隧道身份验证。一对将用于NAS的初始PPP身份验证，第二对将用于隧道服务器的身份验证。
This has implications if the NAS attempts to forward authentication information to the tunnel server in the initial setup notification. Since the userID/password pair used for tunnel authentication is different from that used to authenticate against the NAS, forwarding authentication information in this manner will cause the tunnel authentication to fail. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed.
如果NAS试图在初始设置通知中将身份验证信息转发到隧道服务器，则会产生影响。由于用于隧道身份验证的用户ID/密码对与用于针对NAS进行身份验证的用户ID/密码对不同，因此以这种方式转发身份验证信息将导致隧道身份验证失败。因此，在通过RADIUS实现基于用户的隧道时，不应采用L2TP身份验证转发。
In order to provide maximum ease of use in the case where the userID/password pairs are identical, tunnel clients typically attempt authentication with the same userID/password pair as was used in the initial PPP negotiation. Only after this fails do they prompt the user for the second pair. Rather than putting up an error message indicating an authentication failure, it is preferable to present a dialog requesting the tunnel userID/password combination.
为了在用户ID/密码对相同的情况下提供最大的易用性，隧道客户端通常尝试使用初始PPP协商中使用的相同用户ID/密码对进行身份验证。只有在失败后，它们才会提示用户输入第二对。与其显示指示身份验证失败的错误消息，不如显示一个对话框，请求隧道用户ID/密码组合。
A similar issue arises when extended authentication methods are being used, as is enabled by EAP, described in [5]. In particular, when one-time passwords or cryptographic calculators are being used, different passwords will be used for the first and second authentications. Thus the user will need to be prompted to enter the second password.
当使用扩展认证方法时，会出现类似的问题，如[5]中所述，EAP启用了扩展认证方法。特别是，当使用一次性密码或密码计算器时，第一次和第二次身份验证将使用不同的密码。因此，需要提示用户输入第二个密码。
It is possible for the two RADIUS servers to return different Port-Limit attributes. For example, it is conceivable that the NAS RADIUS server will only grant use of a single channel, while the tunnel RADIUS server will grant more than one channel. In this case, the correct behavior is for the tunnel client to open a connection to another NAS in order to bring up a multilink bundle on the tunnel server. The client MUST NOT indicate to the NAS that this additional link is being brought up as part of a multilink bundle; this will only be indicated in the subsequent negotiation with the tunnel server.
两台RADIUS服务器可以返回不同的端口限制属性。例如，可以想象NAS RADIUS服务器将只允许使用单个通道，而隧道RADIUS服务器将允许使用多个通道。在这种情况下，正确的行为是隧道客户端打开到另一个NAS的连接，以便在隧道服务器上启动多链路捆绑包。客户端不得向NAS指示此附加链路是作为多链路捆绑的一部分启动的；这将仅在与隧道服务器的后续协商中指出。
It is also conceivable that the NAS RADIUS server will allow the client to bring up multiple channels, but that the tunnel RADIUS server will allow fewer channels than the NAS RADIUS server. In this case, the client should terminate use of the excess channels.
还可以想象，NAS RADIUS服务器将允许客户端启动多个通道，但隧道RADIUS服务器将允许比NAS RADIUS服务器更少的通道。在这种情况下，客户端应该终止对多余通道的使用。
In the provisioning of roaming and shared use networks, one of the requirements is to be able to route the authentication request to the user's home RADIUS server. This authentication routing is accomplished based on the userID submitted by the user to the NAS in the initial PPP authentication. The userID is subsequently relayed by the NAS to the RADIUS server in the User-Name attribute, as part of the RADIUS Access-Request.
在提供漫游和共享使用网络时，要求之一是能够将身份验证请求路由到用户的家庭RADIUS服务器。此身份验证路由是基于用户在初始PPP身份验证中提交给NAS的用户ID完成的。作为RADIUS访问请求的一部分，NAS随后在用户名属性中将用户ID中继到RADIUS服务器。
Similarly, [2] refers to use of the userID in determining the tunnel endpoint, although it does not provide guidelines for how RADIUS or tunnel routing is to be accomplished. Thus the possibility of conflicting interpretations exists.
类似地，[2]提到在确定隧道端点时使用userID，尽管它没有提供如何完成RADIUS或隧道路由的指南。因此，存在相互冲突的解释的可能性。
The use of RADIUS in provisioning of compulsory tunneling relieves the userID from having to do double duty. Rather than being used both for routing of the RADIUS authentication/authorization request as well for determination of the tunnel endpoint, the userID is now used solely for routing of RADIUS authentication/authorization requests. Tunnel attributes returned in the RADIUS Access-Response are then used to determine the tunnel endpoint.
在提供强制隧道时使用RADIUS可以免除用户ID的双重任务。用户ID现在仅用于路由RADIUS身份验证/授权请求，而不是用于路由RADIUS身份验证/授权请求以及确定隧道端点。然后使用RADIUS访问响应中返回的隧道属性来确定隧道端点。
Since the framework described in this document allows both ISPs and tunnel users to authenticate users as well as to account for resources consumed by them, and provides for maintenance of two distinct userID/password pairs, this scheme provides a high degree of flexibility. Where RADIUS proxies and tunneling are employed, it is possible to allow the user to authenticate with a single userID/password pair at both the NAS and the tunnel endpoint. This is accomplished by routing the NAS RADIUS Access-Request to the same RADIUS server used by the tunnel server.
由于本文档中描述的框架允许ISP和隧道用户对用户进行身份验证，并说明他们所消耗的资源，并提供两个不同的用户ID/密码对的维护，因此该方案提供了高度的灵活性。在使用RADIUS代理和隧道的情况下，可以允许用户在NAS和隧道端点使用单个用户ID/密码对进行身份验证。这是通过将NAS RADIUS访问请求路由到隧道服务器使用的同一RADIUS服务器来实现的。
[1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[1] Rigney C.，Rubens A.，Simpson W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[2] 汤斯利，W.，巴伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和帕尔特，B.，“第二层隧道协议”L2TP“，RFC 26611999年8月。
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", Work in Progress.
[3] Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.和Goyret，I.，“隧道协议支持的半径属性”，正在进行的工作。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Blunk，L.anf J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
In PPP-based tunneling, PPP security is negotiated between the client and the tunnel server, and covers the entire length of the path. This is because the client does not have a way to know that they are being tunneled. Thus, any security the NAS may negotiate with the tunnel server will occur in addition to that negotiated between the client and NAS.
在基于PPP的隧道中，PPP安全性在客户端和隧道服务器之间协商，并覆盖整个路径长度。这是因为客户机无法知道他们正在进行隧道挖掘。因此，NAS可能与隧道服务器协商的任何安全性都将发生在客户端和NAS之间协商的安全性之外。
In L2TP compulsory tunneling, this means that PPP encryption and compression will be negotiated between the client and the tunnel server. In addition, the NAS may bring up an IPSEC security association between itself and the tunnel server. This adds protection against a number of possible attacks.
在L2TP强制隧道中，这意味着PPP加密和压缩将在客户端和隧道服务器之间协商。此外，NAS可能会在其自身和隧道服务器之间建立IPSEC安全关联。这增加了对一些可能的攻击的保护。
Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS server may be processed by one or more proxies prior to being received by the NAS. In order to ensure that tunnel attributes arrive without modification, intermediate RADIUS proxies forwarding the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS proxy does not support tunnel attributes, then it MUST send an Access-Reject to the NAS. This is necessary to ensure that the user is only granted access if the services requested by the RADIUS server can be provided.
在部署RADIUS代理的情况下，在NAS接收到RADIUS服务器发送的访问应答之前，可以由一个或多个代理进行处理。为了确保隧道属性在未经修改的情况下到达，转发访问回复的中间半径代理不得修改隧道属性。如果RADIUS代理不支持隧道属性，则必须向NAS发送访问拒绝。这对于确保只有在可以提供RADIUS服务器请求的服务时才授予用户访问权限是必要的。
Since RADIUS tunnel attributes are used for compulsory tunneling, address assignment is handled by the tunnel server rather than the NAS. As a result, if tunnel attributes are present, the NAS MUST ignore any address assignment attributes sent by the RADIUS server. In addition, the NAS and client MUST NOT begin NCP negotiation, since this could create a time window in which the client will be capable of sending packets to the transport network, which is not permitted in compulsory tunneling.
由于RADIUS隧道属性用于强制隧道，因此地址分配由隧道服务器而不是NAS处理。因此，如果存在隧道属性，NAS必须忽略RADIUS服务器发送的任何地址分配属性。此外，NAS和客户端不得开始NCP协商，因为这可能会创建一个时间窗口，在该时间窗口中客户端将能够向传输网络发送数据包，这在强制隧道中是不允许的。
Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of this problem space, and to Allan Rubens of Tut Systems and Bertrand Buclin of AT&T Labs Europe for their comments on this document.
感谢微软的古尔迪普·辛格·帕尔（Gurdeep Singh Pall）对此问题空间进行了许多有益的讨论，感谢图坦卡蒙系统公司的艾伦·鲁本斯（Allan Rubens）和AT&T实验室欧洲分部的伯特兰·布克林（Bertrand Buclin）对本文件的评论。
Most of the work on this document was performed while Glen Zorn was employed by the Microsoft Corporation.
本文档的大部分工作是在Glen Zorn受雇于微软公司时完成的。
The RADIUS Working Group can be contacted via the current chair:
可通过现任主席联系RADIUS工作组：
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
加利福尼亚州普莱森顿市柳树路4464号卡尔·里格尼·利文斯顿企业，邮编94588
Phone: +1 510-426-0770
EMail: cdr@livingston.com
Phone: +1 510-426-0770
EMail: cdr@livingston.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425-936-6605
EMail: bernarda@microsoft.com
Phone: +1 425-936-6605
EMail: bernarda@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
格伦佐恩思科系统有限公司，地址：美国华盛顿州贝尔维尤第108大道500号，邮编：98004
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, 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, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards 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 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。