rfc2809.txt

很多RFC的中文文档

   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



Aboba & Zorn                 Informational                      [Page 7]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   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.
   如果重新协商是必须的，在进行重新协商开始的时候，NAS不该（SHOULD NOT）
   已经发送一个LCP CONFACK完成了LCP协商，并且用户客户端和NAS之间不应该
   （MUST NOT）已经开始NCP协商。与发送一个LCP CONFACK相反，NAS将发送一个
   LCP配置请求（LCP Configure-Request）包，此情况在〔6〕中描述。随后用户
   客户端可能（MAY）进行LCP重新协商，并且从此以后，所有的源于用户客户端的
   PPP包将被封装并发送到隧道服务器。到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可能（MAY）在初始化
   建立阶段通知中包含一份两个方向的LCP CONFACK拷贝，此发向两个方向的
   LCP CONFACK是用来完成LCP协商的。隧道服务器可以（MAY）使用这些信息来避免
   额外的LCP协商。如果使用L2TP，初始化阶段通知中还可以包括需要的认证信息，来允
   许隧道服务器认证用户，以决定是接受或拒绝此连接。但是，在基于电话号码的认证中，
   PPP认证不应该（MUST NOT）在NAS建立隧道前发生。这导致的结果是，L2TP认证转发
   不应该（MUST NOT）被使用。

   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协商、认证和后继的数据交换参与流程是可以理解的。


















Aboba & Zorn                 Informational                      [Page 8]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call connected
   Send RADIUS
    Access-Request
    with Called-Station-Id,
    and/or Calling-Station-Id
   LCP starts
   呼叫请求
   发送包含主叫和/或被叫号码的
   RADIUS认证请求
   LCP 开始
                                                      IF authentication
                                                      succeeds
                                                       Send ACK
                                                      ELSE Send NAK
                                                      如果认证成功
                                                          发送接受（ACK）
                                                      否则
                                                          发送拒绝（NAK）
   IF NAK DISCONNECT
   ELSE
    IF no control
     connection exists
     Send
     Start-Control-Connection-Request
     to Tunnel Server
   如果 拒绝（NAK） 切断连接
   否则
       如果 没有控制连接存在
           发送Start-Control-Connection-Request
           到隧道服务器
                                Send
                                Start-Control-Connection-Reply
                                to NAS
                                发送Start-Control-Connection-Reply
                                到NAS
    ENDIF
    结束

   Send
   Incoming-Call-Request
   message to Tunnel Server
   发送Incoming-Call-Request
   消息到隧道服务器
                                Send Incoming-Call-Reply
                                to NAS
                                发送Incoming-Call-Reply
                                到 NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server
   发送Incoming-Call-Connected
   消息到隧道服务器

   Send data through the tunnel
   通过隧道发送数据
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting
                                重新协商 LCP
                                认证用户
                                建立 IPCP
                                开始计费











Aboba & Zorn                 Informational                      [Page 9]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


4.1.2.3.  User-Name
          用户名

   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（userID）的域部分或在RADIUS服务器
   上的具体属性处理。因为用户的身份将绝不被NAS验证，或者隧道服务器的所有者必
   须愿意为所有的呼叫付费，或者其他信息如主叫号码为了计费的目的必须被用来验
   证用户的身份。

   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.
   在具体属性处理中RADIUS可能被使用，并且一条属性被用作触发隧道初始化。
   例如：如果用户密码（User-Password）包含了一个虚假值（如“tunnel、L2TP”），
   隧道属性就能被回送。相对应另一种，以字符（'*'）开头的用户ID（userID）能
   被用来表明需要初始化一条隧道。当具体属性处理被使用的时候，隧道服务器可能
   需要进行重新协商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（userID）的域部分；在域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.
   因为不通过RADIUS进行对用户身份验证，为了NAS能对连接开始计费，需要使用
   用户声明在到隧道服务器的认证中的用户身份。但是，为了计费的完全有效，
   隧道终结端需要和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 Incoming-Call-Request
   隧道服务器到NAS：L2TP Incoming-Call-Reply
   NAS 到隧道服务器： L2TP  Incoming-Call-Connected
   用户客户端和隧道服务器：PPP LCP 重新协商
   用户客户端和隧道服务器：PPP 认证
   隧道服务器到RADIUS服务器：RADIUS认证请求（可选）
   RADIUS服务器到隧道服务器：RADIUS 认证接受/拒绝
   用户客户端和隧道服务器：NCP协商



Aboba & Zorn                 Informational                     [Page 10]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   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,