Network Working Group A. Valencia
Request for Comments: 2341 M. Littlewood
Category: Historic T. Kolar
Cisco Systems
May 1998
Network Working Group A. Valencia
Request for Comments: 2341 M. Littlewood
Category: Historic T. Kolar
Cisco Systems
May 1998
Cisco Layer Two Forwarding (Protocol) "L2F"
Cisco第二层转发（协议）“L2F”
Status of Memo
备忘录的状况
This memo describes a historic protocol 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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided.
虚拟拨号允许许多独立的自治协议域共享公共访问基础设施，包括调制解调器、访问服务器和ISDN路由器。以前的RFC指定了通过SLIP[1]支持IP拨号和通过PPP支持多协议拨号的协议[2]。本文档描述了第二层转发协议（L2F），该协议允许对更高级别协议的链路层（即HDLC、异步HDLC或滑动帧）进行隧道传输。使用这种隧道，可以将初始拨号服务器的位置与拨号协议连接终止的位置分离，并提供对网络的访问。
Table of Contents
目录
1.0 Introduction 3 1.1 Conventions 3 2.0 Problem Space Overview 3 2.1 Initial Assumptions 3 2.2 Topology 4 2.3 Virtual dial-up Service - a walk-though 5 3.0 Service Model Issues 7 3.1 Security 7 3.2 Address allocation 8 3.3 Authentication 8 3.4 Accounting 8 4.0 Protocol Definition 9 4.1 Encapsulation within L2F 10 4.1.1 Encapsulation of PPP within L2F 10
1.0 导言3 1.1约定3 2.0问题空间概述3 2.1初始假设3 2.2拓扑4 2.3虚拟拨号服务-漫游5 3.0服务模型问题7 3.1安全7 3.2地址分配8 3.3身份验证8 3.4记帐8 4.0协议定义9 4.1 L2F中的封装10 4.1.1 L2F中的PPP封装10
4.1.2 Encapsulation of SLIP within L2F 10 4.2 L2F Packet Format 10 4.2.1 Overall Packet Format 10 4.2.2 Packet Header 11 4.2.3 Version field 11 4.2.4 Protocol field 11 4.2.5 Sequence Number 12 4.2.6 Packet Multiplex ID 12 4.2.7 Client ID 13 4.2.8 Length 13 4.2.9 Packet Checksum 13 4.2.10 Payload Offset 14 4.2.11 Packet Key 14 4.2.12 Packet priority 14 4.3 L2F Tunnel Establishment 14 4.3.1 Normal Tunnel Negotiation Sequence 15 4.3.2 Normal Client Negotiation Sequence 17 4.4 L2F management message types 18 4.4.1 L2F message type: Invalid 18 4.4.2 L2F_CONF 19 4.4.3 L2F_OPEN, tunnel establishment 20 4.4.4 L2F_OPEN, client establishment 20 4.4.5 L2F_CLOSE 22 4.4.6 L2F_ECHO 22 4.4.7 L2F_ECHO_RESP 23 4.5 L2F Message Delivery 23 4.5.1 Sequenced Delivery 23 4.5.2 Flow Control 23 4.5.3 Tunnel State Table 24 4.5.4 Client State Table 25 5.0 Protocol Considerations 26 5.1 PPP Features 26 5.2 Termination 26 5.3 Extended Authentication 26 5.4 MNP4 and Apple Remote Access Protocol 27 5.5 Operation over IP/UDP 27 6.0 Acknowledgments 27 7.0 References 27 8.0 Security Considerations 28 9.0 Authors' Addresses 28 10.0 Full Copyright Statement 29
4.1.2 L2F 10 4.2 L2F包格式10 4.2.1总包格式10 4.2.2包头11 4.2.3版本字段11 4.2.4协议字段11 4.2.5序列号12 4.2.6包多路复用ID 12 4.2.7客户端ID 13 4.2.8长度13 4.2.9包校验和13 4.2.10有效负载偏移14 4.2.11包密钥14 4.2.12包优先级144.3 L2F隧道建立14 4.3.1正常隧道协商顺序15 4.3.2正常客户端协商顺序17 4.4 L2F管理消息类型18 4.4.1 L2F消息类型：无效18 4.4.2 L2F_配置19 4.4.3 L2F_打开，隧道建立20 4.4.4 L2F_打开，客户端建立20 4.4.5 L2F_CLOSE 22 4.4.6 L2F_ECHO 22 4.4.7 L2F_ECHO_RESP 23 4.5 L2F消息传递23 4.5.1顺序传递23 4.5.2流控制23 4.5.3隧道状态表24 4.5.4客户端状态表25 5.0协议考虑26 5.1 PPP功能26 5.2终止26 5.3扩展身份验证26 5.4 MNP4和Apple Remote访问协议27 5.5 IP/UDP上的操作27 6.0确认27 7.0参考27 8.0安全注意事项28 9.0作者地址28 10.0完整版权声明29
The traditional dial-up network service on the Internet is for registered IP addresses only. A new class of virtual dial-up application which allows multiple protocols and unregistered IP addresses is also desired on the Internet. Examples of this class of network application are support for privately addressed IP, IPX, and AppleTalk dial-up via SLIP/PPP across existing Internet infrastructure.
Internet上的传统拨号网络服务仅用于注册IP地址。互联网上还需要一种新的虚拟拨号应用程序，它允许多种协议和未注册的IP地址。此类网络应用程序的示例包括通过现有互联网基础设施中的SLIP/PPP支持私有寻址IP、IPX和AppleTalk拨号。
The support of these multiprotocol virtual dial-up applications is of significant benefit to end users and Internet Service providers as it allows the sharing of very large investments in access and core infrastructure and allows local calls to be used. It also allows existing investments in non-IP protocol applications to be supported in a secure manner while still leveraging the access infrastructure of the Internet.
这些多协议虚拟拨号应用程序的支持对最终用户和互联网服务提供商具有重大的好处，因为它允许共享接入和核心基础设施方面的巨大投资，并允许使用本地呼叫。它还允许以安全的方式支持对非IP协议应用程序的现有投资，同时仍然利用互联网的访问基础设施。
It is the purpose of this RFC to identify the issues encountered in integrating multiprotocol dial-up services into an existing Internet Service Provider's Point of Presence (hereafter referred to as ISP and POP, respectively), and to describe the L2F protocol which permits the leveraging of existing access protocols.
本RFC旨在确定将多协议拨号服务集成到现有互联网服务提供商的存在点（以下分别称为ISP和POP）时遇到的问题，并描述允许利用现有访问协议的L2F协议。
The following language conventions are used in the items of specification in this document:
本文件中的规范项目使用了以下语言约定：
o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification.
o 必须、必须或强制性——该项是本规范的绝对要求。
o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances.
o 应该或建议——除特殊情况外，一般应遵循本项。
o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor.
o MAY或OPTIONAL——此项是真正的可选项，可以根据实现者的需要遵循或忽略。
In this section we describe in high level terms the scope of the problem that will be explored in more detail in later sections.
在本节中，我们将从较高的层次描述问题的范围，并将在后面的章节中进行更详细的探讨。
We begin by assuming that Internet access is provided by an ISP and that the ISP wishes to offer services other than traditional registered IP address based services to dial-up users of the network.
我们首先假设互联网接入由ISP提供，并且ISP希望向网络拨号用户提供传统注册IP地址服务以外的服务。
We also assume that the user of such a service wants all of the security facilities that are available to him in a dedicated dial-up configuration. In particular, the end user requires:
我们还假设这样一个服务的用户希望在一个专用的拨号配置中拥有所有可用的安全设施。具体而言，最终用户需要：
+ End System transparency: Neither the remote end system nor his home site hosts should require any special software to use this service in a secure manner.
+ 终端系统透明度：无论是远程终端系统还是其主站点主机，都不需要任何特殊软件来安全地使用此服务。
+ Authentication as provided via dial-up PPP CHAP or PAP, or through other dialogs as needed for protocols without authentication (e.g., SLIP). This will include TACACS+ and RADIUS solutions as well as support for smart cards and one-time passwords. The authentication should be manageable by the user independently of the ISP.
+ 通过拨号PPP CHAP或PAP提供的身份验证，或通过无身份验证协议（如SLIP）所需的其他对话框提供的身份验证。这将包括TACACS+和RADIUS解决方案，以及对智能卡和一次性密码的支持。认证应由用户独立于ISP进行管理。
+ Addressing should be as manageable as dedicated dial-up solutions. The address should be assigned by the home site and not the ISP.
+ 寻址应与专用拨号解决方案一样易于管理。地址应由主站点而不是ISP分配。
+ Authorization should be managed by the home site as it would in a direct dial-up solution.
+ 授权应由主站点管理，就像在直接拨号解决方案中一样。
+ Accounting should be performed both by the ISP (for billing purposes) and by the user (for charge-back and auditing).
+ 应由ISP（用于计费）和用户（用于计费和审核）进行计费。
Shown below is a generic Internet with Public switched Telephone Network (PSTN) access (i.e., async PPP via modems) and Integrated Services Digital Network (ISDN) access (i.e., synchronous PPP access). Remote users (either async PPP or SLIP, or ISDN) will access the Home LAN as if they were dialed into the Home Gateway, although their physical dial-up is via the ISP Network Access Server.
下图所示为具有公共交换电话网（PSTN）接入（即通过调制解调器的异步PPP）和综合业务数字网（ISDN）接入（即同步PPP接入）的通用互联网。远程用户（异步PPP或SLIP或ISDN）将访问家庭LAN，就像他们被拨入家庭网关一样，尽管他们的物理拨号是通过ISP网络访问服务器进行的。
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
To motivate the following discussion, this section walks through an example of what might happen when a Virtual dial-up client initiates access.
为了激发下面的讨论，本节将通过一个示例介绍虚拟拨号客户端启动访问时可能发生的情况。
The Remote User initiates a PPP connection to an ISP via either the PSTN or ISDN. The Network Access Server (NAS) accepts the connection and the PPP link is established.
远程用户通过PSTN或ISDN发起到ISP的PPP连接。网络访问服务器（NAS）接受连接并建立PPP链路。
The ISP undertakes a partial authentication of the end system/user via CHAP or PAP. Only the username field is interpreted to determine whether the user requires a Virtual dial-up service. It is expected-- but not required--that usernames will be structured (e.g. littlewo@cisco.com). Alternatively, the ISP may maintain a database mapping users to services. In the case of Virtual dial-up, the mapping will name a specific endpoint, the Home Gateway.
ISP通过CHAP或PAP对终端系统/用户进行部分认证。仅解释用户名字段以确定用户是否需要虚拟拨号服务。预期（但不是必需的）用户名将是结构化的（例如。littlewo@cisco.com). 或者，ISP可以维护将用户映射到服务的数据库。在虚拟拨号的情况下，映射将命名一个特定的端点，即家庭网关。
If a virtual dial-up service is not required, standard access to the Internet may be provided.
如果不需要虚拟拨号服务，则可以提供对Internet的标准访问。
If no tunnel connection currently exists to the desired Home Gateway, one is initiated. L2F is designed to be largely insulated from the details of the media over which the tunnel is established; L2F requires only that the tunnel media provide packet oriented point-to-point connectivity. Obvious examples of such media are UDP, Frame Relay PVC's, or X.25 VC's. Details for L2F operation over UDP are provided in section 5.5. The specification for L2F packet formats is provided in section 4.2, and the message types and semantics starting in section 4.4.
如果当前不存在到所需家庭网关的隧道连接，则启动一个隧道连接。L2F的设计在很大程度上与修建隧道的介质细节隔离；L2F只要求隧道媒体提供面向数据包的点对点连接。这种媒体的明显例子是UDP、帧中继PVC或X.25 VC。第5.5节提供了UDP上L2F操作的详细信息。L2F数据包格式规范见第4.2节，消息类型和语义从第4.4节开始。
Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is allocated, and a connect indication is sent to notify the Home Gateway of this new dial-up session. The Home Gateway either accepts the connection, or rejects. Rejection may include a reason indication, which may be displayed to the dial-up user, after which the call should be disconnected.
一旦隧道存在，将分配一个未使用的多路复用ID（以下简称“MID”），并发送连接指示以通知家庭网关此新拨号会话。家庭网关要么接受连接，要么拒绝连接。拒绝可能包括一个原因指示，可向拨号用户显示，之后应断开呼叫。
The initial setup notification may include the authentication information required to allow the Home Gateway to authenticate the user and decide to accept or decline the connection. In the case of CHAP, the set-up packet includes the challenge, username and raw response. For PAP or text dialog (i.e., for SLIP users), it includes username and clear text password. The Home Gateway may choose to use this information to complete its authentication, avoiding an additional cycle of authentication.
初始设置通知可包括允许家庭网关认证用户并决定接受或拒绝连接所需的认证信息。对于CHAP，设置数据包包括质询、用户名和原始响应。对于PAP或文本对话框（即，对于SLIP用户），它包括用户名和明文密码。家庭网关可以选择使用该信息来完成其认证，从而避免额外的认证周期。
For PPP, the initial setup notification may also include a copy of the the LCP CONFACKs sent in each direction which completed LCP negotiation. The Home Gateway may use this information to initialize its own PPP state (thus avoiding an additional LCP negotiation), or it may choose to initiate a new LCP CONFREQ exchange.
对于PPP，初始设置通知还可以包括在完成LCP协商的每个方向上发送的LCP确认的副本。家庭网关可以使用该信息初始化其自己的PPP状态（从而避免额外的LCP协商），或者可以选择发起新的LCP CONFREQ交换。
If the Home Gateway accepts the connection, it creates a "virtual interface" for SLIP or PPP in a manner analogous to what it would use for a direct-dialed connection. With this "virtual interface" in place, link layer frames may now pass over this tunnel in both directions. Frames from the remote user are received at the POP, stripped of any link framing or transparency bytes, encapsulated in L2F, and forwarded over the appropriate tunnel.
如果家庭网关接受连接，它将以类似于直接拨号连接的方式为SLIP或PPP创建一个“虚拟接口”。有了这个“虚拟接口”，链路层帧现在可以在两个方向上通过这个隧道。来自远程用户的帧在POP处接收，去除任何链路帧或透明字节，封装在L2F中，并通过适当的隧道转发。
The Home Gateway accepts these frames, strips L2F, and processes them as normal incoming frames for the appropriate interface and protocol. The "virtual interface" behaves very much like a hardware interface, with the exception that the hardware in this case is physically located at the ISP POP. The other direction behaves analogously, with the Home Gateway encapsulating the packet in L2F, and the POP stripping L2F before transmitting it out the physical interface to the remote user.
家庭网关接受这些帧，剥离L2F，并将其作为适当接口和协议的正常传入帧进行处理。“虚拟接口”的行为非常类似于硬件接口，但本例中的硬件实际位于ISP POP。另一个方向的行为类似，家庭网关将数据包封装在L2F中，POP在将数据包从物理接口发送到远程用户之前剥离L2F。
At this point, the connectivity is a point-to-point PPP or SLIP connection whose endpoints are the remote user's networking application on one end and the termination of this connectivity into the Home Gateway's SLIP or PPP support on the other. Because the remote user has become simply another dial-up client of the Home Gateway access server, client connectivity can now be managed using traditional mechanisms with respect to further authorization, protocol access, and filtering.
此时，连接是一种点对点PPP或滑动连接，其端点在一端是远程用户的网络应用程序，在另一端是家庭网关的SLIP或PPP支持的连接终止。由于远程用户已成为家庭网关访问服务器的另一个拨号客户端，因此现在可以使用有关进一步授权、协议访问和过滤的传统机制来管理客户端连接。
Accounting can be performed at both the NAS as well as the Home Gateway. This document illustrates some Accounting techniques which are possible using L2F, but the policies surrounding such Accounting are outside the scope of this specification.
可以在NAS和家庭网关上执行记帐。本文档说明了一些可以使用L2F的会计技术，但围绕此类会计的政策不在本规范的范围内。
Because L2F connect notifications for PPP clients contain sufficient information for a Home Gateway to authenticate and initialize its LCP state machine, it is not required that the remote user be queried a second time for CHAP authentication, nor that the client undergo multiple rounds of LCP negotiation and convergence. These techniques are intended to optimize connection setup, and are not intended to deprecate any functions required by the PPP specification.
由于PPP客户端的L2F connect通知包含足够的信息，家庭网关可以对其LCP状态机进行身份验证和初始化，因此无需再次向远程用户查询CHAP身份验证，也无需对客户端进行多轮LCP协商和聚合。这些技术旨在优化连接设置，而不是反对PPP规范要求的任何功能。
There are several significant differences between the standard Internet access service and the Virtual dial-up service with respect to authentication, address allocation, authorization and accounting. The details of the differences between these services and the problems presented by these differences are described below. The mechanisms used for Virtual Dial-up service are intended to coexist with more traditional mechanisms; it is intended that an ISP's POP can simultaneously service ISP clients as well as Virtual dial-up clients.
在身份验证、地址分配、授权和记帐方面，标准Internet访问服务和虚拟拨号服务之间存在一些显著差异。下文详细介绍了这些服务之间的差异以及这些差异带来的问题。用于虚拟拨号服务的机制旨在与更传统的机制共存；ISP的POP可以同时为ISP客户端和虚拟拨号客户端提供服务。
For the Virtual dial-up service, the ISP pursues authentication only to the extent required to discover the user's apparent identity (and by implication, their desired Home Gateway). As soon as this is determined, a connection to the Home Gateway is initiated with the authentication information gathered by the ISP. The Home Gateway completes the authentication by either accepting the connection, or rejecting it.
对于虚拟拨号服务，ISP仅在发现用户的明显身份所需的范围内进行身份验证（暗示用户所需的家庭网关）。一旦确定这一点，就使用ISP收集的身份验证信息启动与家庭网关的连接。家庭网关通过接受或拒绝连接来完成身份验证。
The Home Gateway must also protect against attempts by third parties to establish tunnels to the Home Gateway. Tunnel establishment involves an ISP-to-Home Gateway authentication phase to protect against such attacks.
家庭网关还必须防止第三方试图建立到家庭网关的隧道。隧道建立涉及ISP到家庭网关的身份验证阶段，以防止此类攻击。
For an Internet service, the user accepts that the IP address may be allocated dynamically from a pool of Service provider addresses. This model often means that the remote user has little or no access to their home network's resources, due to firewalls and other security policies applied by the home network to accesses from external IP addresses.
对于因特网服务，用户接受可以从服务提供商地址池动态分配IP地址。这种模式通常意味着，由于家庭网络应用防火墙和其他安全策略从外部IP地址进行访问，远程用户很少或根本无法访问其家庭网络的资源。
For the Virtual dial-up service, the Home Gateway can exist behind the home firewall, allocating addresses which are internal (and, in fact, can be RFC1597 addresses, or non-IP addresses). Because L2F tunnels exclusively at the frame layer, the actual policies of such address management are irrelevant to correct Virtual dial-up service; for all purposes of PPP or SLIP protocol handling, the dial-in user appears to have connected at the Home Gateway.
对于虚拟拨号服务，家庭网关可以位于家庭防火墙后面，分配内部地址（实际上可以是RFC1597地址或非IP地址）。由于L2F隧道只在帧层，因此这种地址管理的实际策略与正确的虚拟拨号服务无关；出于PPP或SLIP协议处理的所有目的，拨入用户似乎已连接到家庭网关。
The authentication of the user occurs in three phases; the first at the ISP, and the second and optional third at the Home gateway.
用户认证分三个阶段进行；第一个在ISP，第二个和可选的第三个在家庭网关。
The ISP uses the username to determine that a Virtual dial-up service is required and initiate the tunnel connection to the appropriate Home Gateway. Once a tunnel is established, a new MID is allocated and a session initiated by forwarding the gathered authentication information.
ISP使用用户名确定需要虚拟拨号服务，并启动到相应家庭网关的隧道连接。一旦建立了隧道，就会分配一个新的MID，并通过转发收集到的身份验证信息来启动会话。
The Home Gateway undertakes the second phase by deciding whether or not to accept the connection. The connection indication may include CHAP, PAP, or textual authentication information. Based on this information, the Home Gateway may accept the connection, or may reject it (for instance, it was a PAP request and the username/password are found to be incorrect).
家庭网关通过决定是否接受连接来进行第二阶段。连接指示可以包括CHAP、PAP或文本认证信息。基于此信息，家庭网关可以接受连接，也可以拒绝连接（例如，这是PAP请求，并且发现用户名/密码不正确）。
Once the connection is accepted, the Home Gateway is free to pursue a third phase of authentication at the PPP or SLIP layer. These activities are outside the scope of this specification, but might include an additional cycle of LCP authentication, proprietary PPP extensions, or textual challenges carried via a TCP/IP telnet session.
一旦连接被接受，家庭网关就可以在PPP或滑动层进行第三阶段的身份验证。这些活动不在本规范的范围内，但可能包括LCP身份验证的附加周期、专有PPP扩展或通过TCP/IP telnet会话进行的文本挑战。
It is a requirement that both the Access gateway and the Home Gateway can provide accounting data and hence both may count packets, octets and connection start and stop times.
要求接入网关和家庭网关都能提供记帐数据，因此都能计算数据包、八位字节和连接开始和停止时间。
Since Virtual dial-up is an access service, accounting of connection attempts (in particular, failed connection attempts) is of significant interest. The Home Gateway can reject new connections based on the authentication information gathered by the ISP, with corresponding logging. For cases where the Home Gateway accepts the connection and then continues with further authentication, the Home Gateway might subsequently disconnect the client. For such scenarios, the disconnection indication back to the ISP may also include a reason.
由于虚拟拨号是一种访问服务，因此对连接尝试（特别是失败的连接尝试）的统计非常重要。家庭网关可以根据ISP收集的身份验证信息以及相应的日志记录拒绝新连接。对于家庭网关接受连接然后继续进行进一步身份验证的情况，家庭网关可能随后断开客户端的连接。对于这种情况，返回ISP的断开指示也可能包括原因。
Because the Home Gateway can decline a connection based on the authentication information collected by the ISP, accounting can easily draw a distinction between a series of failed connection attempts and a series of brief successful connections. Lacking this facility, the Home Gateway must always accept connection requests, and would need to exchange a number of PPP packets with the remote system.
由于家庭网关可以根据ISP收集的身份验证信息拒绝连接，因此记帐可以轻松区分一系列失败的连接尝试和一系列短暂的成功连接。缺少这种功能，家庭网关必须始终接受连接请求，并且需要与远程系统交换大量PPP数据包。
The protocol definition for Virtual dial-up services requires two areas of standardization:
虚拟拨号服务的协议定义需要两个标准化领域：
+ Encapsulation of PPP packets within L2F. The ISP NAS and the Home gateway require a common understanding of the encapsulation protocol so that SLIP/PPP packets can be successfully transmitted and received across the Internet.
+ 在L2F中封装PPP数据包。ISP NAS和家庭网关需要对封装协议有一个共同的理解，以便SLIP/PPP数据包可以通过Internet成功传输和接收。
+ Connection management of L2F and MIDs. The tunnel must be initiated and terminated, as must MIDs within the tunnel. Termination includes diagnostic codes to assist in the diagnosis of problems and to support accounting.
+ L2F和MIDs的连接管理。隧道必须启动和终止，隧道内的MID也必须启动和终止。终止包括帮助诊断问题和支持记帐的诊断代码。
While providing these services, the protocol must address the following required attributes:
在提供这些服务时，协议必须解决以下所需属性：
+ Low overhead. The protocol must impose a minimal additional overhead. This requires a compact encapsulation, and a structure for omitting some portions of the encapsulation where their function is not required.
+ 低开销。协议必须施加最小的额外开销。这需要一个紧凑的封装，以及一个省略封装中一些不需要其功能的部分的结构。
+ Efficiency. The protocol must be efficient to encapsulate and deencapsulate.
+ 效率协议必须有效地进行封装和解封。
+ Protocol independence. The protocol must make very few assumptions about the substrate over which L2F packets are carried.
+ 协议独立性。协议必须对承载L2F数据包的基板进行很少的假设。
+ Simple deployment. The protocol must not rely on additional telecommunication support (for instance, unique called numbers, or caller ID) to operate.
+ 简单的部署。协议不得依赖额外的电信支持（例如，唯一的被叫号码或呼叫者ID）来运行。
The PPP packets may be encapsulated within L2F. The packet encapsulated is the packet as it would be transmitted over a physical link. The following are NOT present in the packet:
PPP分组可以封装在L2F内。封装的数据包是通过物理链路传输的数据包。数据包中不存在以下内容：
+ Flags + Transparency data (ACCM for async, bit stuffing for sync) + CRC
+ 标志+透明数据（ACCM表示异步，位填充表示同步）+CRC
The following ARE still present:
以下人员仍然在场：
+ Address and control flags (unless negotiated away by LCP) + Protocol value
+ 地址和控制标志（除非通过LCP协商）+协议值
SLIP is encapsulated within L2F in much the same way as PPP. The transparency characters are removed before encapsulating within L2F, as is the framing.
SLIP封装在L2F中的方式与PPP大致相同。透明字符在封装到L2F之前会被移除，就像框架一样。
The entire encapsulated packet has the form:
整个封装包的形式如下：
---------------------------------
| |
| L2F Header |
| |
---------------------------------
| |
| Payload packet (SLIP/PPP) |
| |
---------------------------------
| |
| L2F Checksum (optional) |
| |
---------------------------------
---------------------------------
| |
| L2F Header |
| |
---------------------------------
| |
| Payload packet (SLIP/PPP) |
| |
---------------------------------
| |
| L2F Checksum (optional) |
| |
---------------------------------
An L2F packet has the form:
L2F数据包的形式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|P|S|0|0|0|0|0|0|0|0|C| Ver | Protocol |Sequence (opt)|\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Multiplex ID | Client ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
| Length | Offset (opt) | |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Key (opt) | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+ (payload) |
+ ..... |
+ ..... |
+ ..... |
+ (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2F Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|P|S|0|0|0|0|0|0|0|0|C| Ver | Protocol |Sequence (opt)|\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Multiplex ID | Client ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
| Length | Offset (opt) | |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Key (opt) | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+ (payload) |
+ ..... |
+ ..... |
+ ..... |
+ (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2F Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver ("Version") field represents the major version of the L2F software creating the packet. It MUST contain the value 001.
Ver（“版本”）字段表示创建数据包的L2F软件的主要版本。它必须包含值001。
If Ver holds a value other than 1, or any bits are non-zero after bit S but before bit C, this corresponds to a packet containing extensions not understood by the receiving end. The packet is handled as an invalid packet as defined in 4.4.1.
如果Ver持有除1以外的值，或者任何位在位S之后但在位C之前非零，则这对应于包含接收端不理解的扩展的分组。按照4.4.1中的定义，该数据包被视为无效数据包。
The Protocol specifies the protocol carried within the L2F packet. Legal values (represented here in hexadecimal) are:
协议指定L2F数据包中携带的协议。法定值（此处以十六进制表示）为：
Value Type Description 0x00 L2F_ILLEGAL Illegal 0x01 L2F_PROTO L2F management packets 0x02 L2F_PPP PPP tunneled inside L2F 0x03 L2F_SLIP SLIP tunneled inside L2F
值类型说明0x00 L2F_非法非法0x01 L2F_协议L2F管理数据包0x02 L2F_PPP在L2F内部隧道0x03 L2F_在L2F内部隧道滑动
If a packet is received with a Protocol of L2F_ILLEGAL or any other unrecognized value, it MUST be treated as an illegal packet as defined in 4.4.1.
如果使用L2F_非法协议或任何其他无法识别的值接收数据包，则必须将其视为4.4.1中定义的非法数据包。
The Sequence number is present if the S bit in the L2F header is set to 1. This bit MUST be 1 for all L2F management packets. It MAY be set to 1 for non-L2F management packets. If a non-L2F management packet is received with the S bit set, all future L2F packets sent for that MID MUST have the S bit set (and, by implication, be sent using sequence numbers). For instance, the Home Gateway might choose to force sequenced packet delivery if it detects an NCP opening for a protocol which can not operate with out-of-sequence packets.
如果L2F标头中的S位设置为1，则序列号存在。对于所有L2F管理数据包，该位必须为1。对于非L2F管理数据包，可以将其设置为1。如果接收到带有S位集的非L2F管理数据包，则为该MID发送的所有未来L2F数据包必须具有S位集（并且，暗示使用序列号发送）。例如，如果家庭网关检测到一个协议的NCP打开，而该协议不能使用无序数据包进行操作，则家庭网关可能会选择强制顺序数据包交付。
The Sequence number starts at 0 for the first sequenced L2F packet. Each subsequent packet is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 256. There is distinct Sequence number state (i.e., counter) for each distinct MID value.
对于第一个已排序的L2F数据包，序列号从0开始。随后的每个数据包都以序列号的下一个增量发送。因此，序列号是以256模表示的自由运行计数器。每个不同的中值都有不同的序列号状态（即计数器）。
For packets with S bit and sequence number, the sequence number is used to protect against duplication of packets, as follows:
对于具有S位和序列号的数据包，序列号用于防止数据包重复，如下所示：
The receiving side of the tunnel records the sequence number of each valid L2F packet it receives. If a received packet appears to have a value less than or equal to the last received value, the packet MUST be silently discarded. Otherwise, the packet is accepted and the sequence number in the packet recorded as the latest value last received.
隧道的接收端记录它接收的每个有效L2F数据包的序列号。如果接收到的数据包的值小于或等于上次接收到的值，则必须悄悄地丢弃该数据包。否则，数据包被接受，数据包中的序列号被记录为上次接收的最新值。
For purposes of detecting duplication, a received sequence value is considered less than or equal to the last received value if its value lies in the range of the last value and its 127 successor values. For example, if the last received sequence number was 15, then packets with sequence numbers 0 through 15, as well as 144 through 255, would be considered less than or equal to, and would be silently discarded. Otherwise it would be accepted.
为了检测重复，如果接收到的序列值位于最后一个值及其127个后续值的范围内，则将其视为小于或等于最后一个接收到的值。例如，如果最后接收到的序列号是15，则序列号为0到15以及144到255的数据包将被视为小于或等于，并且将被静默地丢弃。否则，它将被接受。
The Multiplex ID ("MID") identifies a particular connection within the tunnel. Each new connection is assigned a MID currently unused within the tunnel. It is recommended that the MID cycle through the entire 16-bit namespace, to reduce aliasing between previous and current sessions. A MID value which has been previously used within a tunnel, has been closed, and will now be used again, must be considered as an entirely new MID, and initialised as such.
多路复用ID（“MID”）标识隧道内的特定连接。为每个新连接分配一个当前在隧道内未使用的MID。建议在整个16位命名空间中循环中间，以减少以前和当前会话之间的别名。以前在隧道内使用、已关闭且现在将再次使用的中间值必须视为全新的中间值，并进行初始化。
The MID with value 0 is special; it is used to communicate the state of the tunnel itself, as distinct from any connection within the tunnel. Only L2F_PROTO packets may be sent using an MID of 0; if any
值为0的MID是特殊的；它用于传达隧道本身的状态，与隧道内的任何连接不同。使用MID 0只能发送L2F_协议包；如果有的话
other type is sent on MID 0, the packet is illegal and MUST be processed as defined in 4.4.1.
其他类型在MID 0上发送，数据包是非法的，必须按照4.4.1中的定义进行处理。
The Client ID ("CLID") is used to assist endpoints in demultiplexing tunnels when the underlying point-to-point substrate lacks an efficient or dependable technique for doing so directly. Using the CLID, it is possible to demultiplex multiple tunnels whose packets arrive over the point-to-point media interleaved, without requiring media-specific semantics.
客户端ID（“CLID”）用于在底层点到点基板缺乏有效或可靠的技术来直接进行解复用时，在解复用隧道中帮助端点。使用CLID，可以解复用多个隧道，这些隧道的数据包通过点对点媒体交错到达，而不需要特定于媒体的语义。
When transmitting the L2F_CONF message (described below), the peer's CLID must be communicated via the Assigned_CLID field. This MUST be a unique non-zero value on the sender's side, which is to be expected in the Home Gateway's L2F_CONF response, as well as all future non-L2F_CONF packets received.
传输L2F_CONF消息（如下所述）时，对等方的CLID必须通过分配的_CLID字段进行通信。这在发送方一侧必须是唯一的非零值，家庭网关的L2F_CONF响应以及将来接收到的所有非L2F_CONF数据包中都需要该值。
The CLID value from the last valid L2F_CONF message received MUST be recorded and used as the CLID field value for all subsequent packets sent to the peer.
必须记录收到的最后一条有效L2F_CONF消息中的CLID值，并将其用作发送给对等方的所有后续数据包的CLID字段值。
Packets with an unknown Client ID MUST be silently discarded.
具有未知客户端ID的数据包必须以静默方式丢弃。
For the initial packet sent during tunnel establishment, where no L2F_CONF has yet been received, the CLID field MUST be set to 0.
对于在隧道建立期间发送的初始数据包，如果尚未收到L2F_CONF，则必须将CLID字段设置为0。
Thus, during L2F_CONF each side is told its CLID value. All later packets sent, tagged with this CLID value, serve as a tag which uniquely identifies this peer.
因此，在L2F_CONF期间，每一方都被告知其CLID值。所有随后发送的数据包，用该CLID值标记，作为唯一标识该对等方的标记。
Length is the size in octets of the entire packet, including header, all fields present, and payload. Length does not reflect the addition of the checksum, if one is present. The packet should be silently discarded if the received packet is shorter than the indicated length. Additional bytes present in the packet beyond the indicated length MUST be silently ignored.
长度是整个数据包的大小（以八位字节为单位），包括报头、所有字段和有效负载。如果存在校验和，则长度不反映校验和的相加。如果接收到的数据包短于指定的长度，则应悄悄丢弃该数据包。数据包中超出指定长度的额外字节必须被静默忽略。
The Checksum is present if the C bit is present in the header flags. It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]). Is is applied over the entire packet starting with the first byte of L2F flags, through the last byte of payload data. The checksum is then added as two bytes immediately following the last byte of payload data.
如果报头标志中存在C位，则存在校验和。它是PPP/HDLC（特别是FCS-16[3]）使用的16位CRC。Is应用于整个数据包，从L2F标志的第一个字节开始，一直到有效负载数据的最后一个字节。然后将校验和作为有效负载数据最后一个字节之后的两个字节添加。
The Offset is present if the F bit is set in the header flags. This field specifies the number of bytes past the L2F header at which the payload data is expected to start. If it is 0, or the F bit is not set, the first byte following the last byte of L2F header is the first byte of payload data.
如果在标头标志中设置了F位，则存在偏移量。此字段指定经过L2F报头的字节数，有效负载数据预计在该字节数处开始。如果为0，或未设置F位，则L2F标头最后一个字节后的第一个字节为有效负载数据的第一个字节。
It is recommended that data skipped due to the payload offset be initialized to 0's.
建议将由于有效负载偏移而跳过的数据初始化为0。
For architectures where it is more efficient to have the payload start at an aligned 32-bit boundary with respect to the L2F header, it is recommended that the F bit be set, and an offset of 0 be used.
对于有效负载从与L2F报头对齐的32位边界开始更有效的架构，建议设置F位，并使用偏移量0。
The Key field is present if the K bit is set in the L2F header. The Key is based on the authentication response last given to the peer during tunnel creation (the details of tunnel creation are provided in the next section). It serves as a key during the life of a session to resist attacks based on spoofing. If a packet is received in which the Key does not match the expected value, the packet MUST be silently discarded. Such handling takes precedence over 4.4.1.
如果在L2F报头中设置了K位，则存在Key字段。密钥基于在隧道创建过程中最后给予对等方的身份验证响应（隧道创建的详细信息将在下一节中提供）。它在会话生命周期中充当密钥，以抵抗基于欺骗的攻击。如果接收到密钥与预期值不匹配的数据包，则必须以静默方式丢弃该数据包。此类处理优先于4.4.1。
The Key value is generated by taking the 128-bit authentication response from the peer, interpreting it as four adjacent 32-bit words in network byte order, XOR'ing these words together, and using the resulting 32-bit value as the Key.
通过从对等方获取128位身份验证响应，将其解释为网络字节顺序的四个相邻32位字，将这些字异或在一起，并使用得到的32位值作为密钥，生成键值。
If the P bit in the L2F header is set, this packet is a "priority" packet. When possible for an implementation, a packet received with the P bit should be processed in preference to previously received unprocessed packets without the P bit.
如果L2F报头中的P位已设置，则该数据包为“优先级”数据包。在可能实现的情况下，应优先处理使用P位接收的数据包，而不是之前未使用P位接收的未处理数据包。
The P bit may be set by an implementation based on criteria beyond the scope of this specification. However, it is recommended that PPP keepalive traffic, if any, be sent with this bit set.
P位可以由基于超出本规范范围的标准的实现来设置。但是，建议使用此位集发送PPP keepalive流量（如果有）。
When the point-to-point link is first initiated between the NAS and the Home Gateway, the endpoints communicate on MID 0 prior to providing general L2F services to clients. This communication is used to verify the presence of L2F on the remote end, and to permit any needed authentication.
当NAS和家庭网关之间的点到点链路首次启动时，端点在向客户端提供一般L2F服务之前在MID 0上进行通信。此通信用于验证远程端是否存在L2F，并允许进行任何必要的身份验证。
The protocol for such negotiation is always 1, indicating L2F management. The message itself is structured as a sequence of single octets indicating an option, followed by zero or more further octets formatted as needed for the option.
此类协商的协议始终为1，表示L2F管理。消息本身的结构是一个表示选项的单八位字节序列，后面是零个或多个根据选项需要格式化的八位字节。
The establishment sequence is best illustrated by a "typical" connection sequence. Detailed description of each functions follows, along with descriptions of the handling of exceptional conditions.
“典型”连接顺序最能说明建立顺序。以下是每个功能的详细说明，以及异常情况的处理说明。
Each packet is described as a source->destination on one line, a description of the L2F packet field contents on the next, and the contents of the packet's body on following lines. The exact encoding of octets will be described later.
每一个数据包在一行中被描述为一个源->目的地，在下一行中被描述为L2F数据包字段内容，在下面的行中被描述为数据包正文的内容。八位字节的精确编码将在后面描述。
Note that this example uses the Key option, but does not use the Offset and Checksum options. The Length field would be present, reflecting the actual length of the packets as encoded as an octet stream.
请注意，此示例使用键选项，但不使用偏移和校验和选项。长度字段将出现，反映作为八位字节流编码的数据包的实际长度。
1. NAS->GW: Proto=L2F, Seq=0, MID=0, CLID=0, Key=0 L2F_CONF Name: NAS_name Challenge: Rnd Assigned_CLID: 22
1. NAS->GW:Proto=L2F，Seq=0，MID=0，CLID=0，Key=0 L2F\u配置名称：NAS\u名称挑战：Rnd分配\u CLID:22
The NAS decides that a tunnel must be initiated from the NAS to the GW. An L2F packet is sent with the Proto field indicating an L2F management message is contained.
NAS决定必须启动从NAS到GW的隧道。发送L2F数据包时，Proto字段指示包含L2F管理消息。
Because the tunnel is being initiated, Key is set to 0. The sequence number starts at 0; the MID is 0 to reflect the establishment of the tunnel itself. Since the NAS has not yet received an L2F_CONF, the CLID is set to 0.
因为隧道正在启动，所以密钥设置为0。序列号从0开始；MID为0，以反映隧道本身的建立。由于NAS尚未收到L2F_CONF，因此CLID设置为0。
The body of the packet specifies the claimed name of the NAS, and a challenge random number which GW will use in authenticating itself as a valid tunnel endpoint. Assigned_CLID is generated to be a value not currently assigned out to any other tunnel to any other Home Gateway.
数据包的主体指定了NAS的声明名称，以及GW将在验证自身为有效隧道端点时使用的质询随机数。Assigned_CLID生成为当前未分配给任何其他隧道和任何其他家庭网关的值。
2. GW->NAS: Proto=L2F, Seq=0, MID=0, CLID=22, Key=0 L2F_CONF Name: GW_name Challenge: Rnd2 Assigned_CLID: 73
2. GW->NAS:Proto=L2F，Seq=0，MID=0，CLID=22，Key=0 L2F\u配置名称：GW\u名称挑战：Rnd2分配\u CLID:73
The Home Gateway has processed the previous packet, and sends a response. The protocol continues to be L2F, with a sequence number 0 (each side maintains its own sequence number for transmissions). MID continues to be 0 to reflect tunnel establishment. CLID reflects the Assigned_CLID field of the L2F_CONF received. The Key continues to be 0 during this phase of tunnel establishment.
家庭网关已处理上一个数据包，并发送响应。该协议仍然是L2F，序列号为0（每一方为传输保留自己的序列号）。MID继续为0，以反映隧道的建立。CLID反映所接收L2F_CONF的已分配_CLID字段。在隧道建立的这个阶段，密钥仍然是0。
The body contains the Home Gateway's name, its own random number challenge, and its own Assigned_CLID for the NAS to place in the CLID field of future packets. The CLID is generated in an analogous manner to that of the NAS. After this, all packets received from the NAS must be tagged with a CLID field containing 73, and all packets sent to the NAS must be tagged with a CLID field containing 22.
正文包含家庭网关的名称、它自己的随机数质询以及它自己分配给NAS的CLID，以放置在未来数据包的CLID字段中。CLID的生成方式与NAS类似。此后，从NAS接收的所有数据包必须使用包含73的CLID字段进行标记，发送到NAS的所有数据包必须使用包含22的CLID字段进行标记。
3. NAS->GW Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2) L2F_OPEN Response: C(Rnd2)
3. NAS->GW Proto=L2F，Seq=1，MID=0，CLID=73，Key=C（Rnd2）L2F\U打开响应：C（Rnd2）
The NAS responds with its Key now set to reflect the shared secret. The Key is a CHAP-style hash of the random number received; each packet hereafter will reflect this calculated value, which serves as a key for the life of the tunnel. Both the Home Gateway and the NAS use such Keys for the life of the tunnel. The Key is a 32-bit representation of the MD5 digest resulting from encrypting the shared secret; the full MD5 digest is included in the L2F_OPEN response, in the "response" field.
NAS响应时，其密钥现在设置为反映共享秘密。密钥是接收到的随机数的CHAP样式散列；此后，每个数据包将反映该计算值，该值作为隧道寿命的关键。家庭网关和NAS在隧道的生命周期中都使用此类密钥。密钥是加密共享密钥后产生的MD5摘要的32位表示；完整的MD5摘要包含在L2F_开放响应的“响应”字段中。
4. GW->NAS Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd) L2F_OPEN Response: C(Rnd)
4. GW->NAS Proto=L2F，Seq=1，MID=0，CLID=22，Key=C（Rnd）L2F\U打开响应：C（Rnd）
The Home Gateway provides closure of the key from the NAS, reflected in both the Key field as well as the "response" field. The tunnel is now available for clients to be established.
家庭网关可关闭来自NAS的密钥，这反映在密钥字段和“响应”字段中。隧道现在可供待建立的客户使用。
This section describes the establishment of a Virtual dial-up client on a NAS into a Home Gateway. It assumes a tunnel has been created in the way described in 4.3.1. The client for this example is a PPP client configured for CHAP.
本节介绍如何在NAS上将虚拟拨号客户端建立到家庭网关。假设已按照4.3.1中所述的方式创建隧道。本例中的客户端是为CHAP配置的PPP客户端。
Treatment of Checksum, Length, and Offset are as in 4.3.1.
校验和、长度和偏移量的处理如4.3.1所示。
1. NAS->GW Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2) L2F_OPEN Type: CHAP Name: CHAP-name Challenge: Rnd3 Response: <Value received, presumably C(Rnd3)> ID: <ID used in challenge>
1. NAS->GW Proto=L2F，Seq=2，MID=1，CLID=73，Key=C（Rnd2）L2F\u开放类型：CHAP名称：CHAP名称质询：Rnd3响应：<Value received，推测为C（Rnd3）>ID:<ID用于质询>
The NAS has received a call, tried CHAP with a challenge value of Rnd3, and found that the client responded. The claimed name lead the NAS to believe it was a Virtual dial-up client hosted by the Home Gateway. The next free MID is allocated, and the information associated with the CHAP challenge/response is included in the connect notification.
NAS已收到呼叫，尝试CHAP（质询值为Rnd3），并发现客户端已响应。声称的名称使NAS相信它是由家庭网关托管的虚拟拨号客户端。将分配下一个空闲MID，与CHAP质询/响应相关的信息将包含在连接通知中。
2. GW->NAS Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd) L2F_OPEN
2. GW->NAS Proto=L2F，Seq=2，MID=1，CLID=22，Key=C（Rnd）L2F\U打开
The Home Gateway, by sending back the L2F_OPEN, accepts the client.
家庭网关通过发送回L2F_OPEN，接受客户端。
3. NAS->GW Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2) <Frame follows>
3. NAS->GW Proto=PPP，Seq=0，MID=1，CLID=73，Key=C（Rnd2）<框架如下>
4. GW->NAS Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd) <Frame follows>
4. GW->NAS Proto=PPP，Seq=0，MID=1，CLID=22，Key=C（Rnd）<框架如下>
Traffic is now free to flow in either direction as sent by the remote client or the home site. The contents is uninterpreted data, HDLC in this case. Data traffic, since it is not the L2F protocol, does not usually use the Seq field, which is set to 0 in non-L2F messages (see the S bit in section 4.2.5 for details on an exception to this).
流量现在可以自由地向远程客户端或主站点发送的任何方向流动。内容是未解释的数据，在本例中为HDLC。由于数据通信不是L2F协议，因此通常不使用Seq字段，在非L2F消息中该字段设置为0（有关此异常的详细信息，请参阅第4.2.5节中的S位）。
When an L2F packet's Proto field specifies L2F management, the body of the packet is encoded as zero or more options. An option is a single octet "message type", followed by zero or more sub-options. Each sub-option is a single byte sub-option value, and further bytes as appropriate for the sub-option.
当L2F数据包的Proto字段指定L2F管理时，数据包的主体被编码为零个或多个选项。一个选项是一个八位字节的“消息类型”，后跟零个或多个子选项。每个子选项都是一个单字节的子选项值，并根据子选项的需要添加更多字节。
Options in L2F are:
L2F中的选项包括：
Hex Value Abbreviation Description
-------- ------------ -----------
0x00 Invalid Invalid message
0x01 L2F_CONF Request configuration
0x02 L2F_CONF_NAME Name of peer sending L2F_CONF
0x03 L2F_CONF_CHAL Random number peer challenges with
0x04 L2F_CONF_CLID Assigned_CLID for peer to use
0x02 L2F_OPEN Accept configuration
0x01 L2F_OPEN_NAME Name received from client
0x02 L2F_OPEN_CHAL Challenge client received
0x03 L2F_OPEN_RESP Challenge response from client
0x04 L2F_ACK_LCP1 LCP CONFACK accepted from client
0x05 L2F_ACK_LCP2 LCP CONFACK sent to client
0x06 L2F_OPEN_TYPE Type of authentication used
0x07 L2F_OPEN_ID ID associated with authentication
0x08 L2F_REQ_LCP0 First LCP CONFREQ from client
0x03 L2F_CLOSE Request disconnect
0x01 L2F_CLOSE_WHY Reason code for close
0x02 L2F_CLOSE_STR ASCII string description
0x04 L2F_ECHO Verify presence of peer
0x05 L2F_ECHO_RESP Respond to L2F_ECHO
Hex Value Abbreviation Description
-------- ------------ -----------
0x00 Invalid Invalid message
0x01 L2F_CONF Request configuration
0x02 L2F_CONF_NAME Name of peer sending L2F_CONF
0x03 L2F_CONF_CHAL Random number peer challenges with
0x04 L2F_CONF_CLID Assigned_CLID for peer to use
0x02 L2F_OPEN Accept configuration
0x01 L2F_OPEN_NAME Name received from client
0x02 L2F_OPEN_CHAL Challenge client received
0x03 L2F_OPEN_RESP Challenge response from client
0x04 L2F_ACK_LCP1 LCP CONFACK accepted from client
0x05 L2F_ACK_LCP2 LCP CONFACK sent to client
0x06 L2F_OPEN_TYPE Type of authentication used
0x07 L2F_OPEN_ID ID associated with authentication
0x08 L2F_REQ_LCP0 First LCP CONFREQ from client
0x03 L2F_CLOSE Request disconnect
0x01 L2F_CLOSE_WHY Reason code for close
0x02 L2F_CLOSE_STR ASCII string description
0x04 L2F_ECHO Verify presence of peer
0x05 L2F_ECHO_RESP Respond to L2F_ECHO
If a message is received with this value, or any value higher than the last recognized option value, or if an illegal packet as defined by other parts of this specification is received, the packet is considered invalid. The packet MUST be discarded, and an L2F_CLOSE of the entire tunnel MUST be requested. Upon receipt of an L2F_CLOSE, the tunnel itself may be closed. All other received message MUST be discarded. An implementation MAY close the tunnel after an interval of time appropriate to the characteristics of the tunnel.
如果接收到具有该值的消息，或任何高于上次识别的选项值的值，或如果接收到本规范其他部分定义的非法数据包，则该数据包被视为无效。必须丢弃该数据包，并且必须请求关闭整个隧道。收到L2F_关闭通知后，隧道本身可能会关闭。必须丢弃所有其他收到的消息。实施可以在适合于隧道特性的时间间隔之后关闭隧道。
Note that packets with an invalid Key are discarded, but disconnect is not initiated. This prevents denial-of-service attacks. Invalid option types within a message MUST be treated as if the entire message type was invalid.
请注意，具有无效密钥的数据包将被丢弃，但断开连接不会启动。这可以防止拒绝服务攻击。必须将消息中的无效选项类型视为整个消息类型无效。
The L2F message type is used to establish the tunnel between the NAS and the Home Gateway. MID is always set to 0. The body of such a message starts with the octet 0x01 (L2F_CONF), followed by all three of the sub-options below.
L2F消息类型用于在NAS和家庭网关之间建立隧道。MID始终设置为0。此类消息的正文以八位字节0x01（L2F_CONF）开头，后跟下面所有三个子选项。
The L2F_CONF_NAME sub-option MUST be present. It is encoded as the octet value 0x02, followed by an octet specifying a non-zero length, followed by the indicated number of bytes, which are interpreted as the sender's ASCII name.
L2F_CONF_NAME子选项必须存在。它被编码为八位字节值0x02，后跟一个指定非零长度的八位字节，后跟指定的字节数，这些字节数被解释为发送方的ASCII名称。
The L2F_CONF_CHAL sub-option MUST be present. It is encoded as the octet value 0x03, followed by a non-zero octet, followed by a number of bytes specified by this non-zero octet.
L2F_CONF_CHAL子选项必须存在。它被编码为八位字节值0x03，后跟一个非零八位字节，后跟该非零八位字节指定的字节数。
The challenge value should be generated using whatever techniques provide the highest quality of random numbers available to a given implementation.
应使用任何技术生成质询值，这些技术为给定实现提供最高质量的随机数。
The L2F_CONF_CLID sub-option MUST be present. It is encoded as the octet 0x04, followed by four bytes of Assigned_CLID value. The Assigned_CLID value is generated as a non-zero 16-bit integer value unique across all tunnels which exist on the sending system. The least significant two octets of Assigned_CLID are set to this value, and the most significant two octets MUST be set to 0.
L2F_CONF_CLID子选项必须存在。它被编码为八位字节0x04，后跟四个字节的赋值。分配的_CLID值作为非零16位整数值生成，该整数值在发送系统上存在的所有隧道中都是唯一的。分配的_CLID的最低有效的两个八位字节设置为该值，最高有效的两个八位字节必须设置为0。
The CLID field is sent as 0 in the initial L2F_CONF packet from NAS to Home Gateway, and otherwise MUST be sent containing the value specified in the Assigned_CLID field of the last L2F_CONF message received.
CLID字段作为初始L2F_CONF数据包中的0从NAS发送到家庭网关，否则必须发送包含在接收到的最后一条L2F_CONF消息的Assigned_CLID字段中指定的值。
Key MUST be set to 0 in all L2F_CONF packets, and no key field is included in the packet.
在所有L2F_CONF数据包中，密钥必须设置为0，并且数据包中不包含密钥字段。
When sent from a NAS to a Home Gateway, the L2F_CONF is the initial packet in the conversation.
当从NAS发送到家庭网关时，L2F_CONF是会话中的初始数据包。
When sent from the Home Gateway to the NAS, an L2F_CONF indicates the Home Gateway's recognition of the tunnel creation request. The Home Gateway MUST provide its name and its own challenge in the message body.
当从家庭网关发送到NAS时，L2F_CONF指示家庭网关识别隧道创建请求。家庭网关必须在消息正文中提供其名称和自己的挑战。
In all packets following the L2F_CONF, the Key MUST be set to the CHAP-style hash of the received challenge bytes. The CHAP-style hash is done over the concatenation of the low 8 bits of the assigned CLID, the secret, and the challenge value. Generation of the 32-bit key value is discussed in section 4.2.11.
在L2F_CONF之后的所有数据包中，密钥必须设置为接收的质询字节的CHAP样式哈希。CHAP样式的哈希是在分配的CLID的低8位、机密和质询值的串联上完成的。第4.2.11节讨论了32位键值的生成。
The L2F_OPEN message is used to provide tunnel setup closure (for a MID of 0) or to establish a client connection within a tunnel previously established by L2F_CONF and L2F_OPEN messages (MID not equal to 0). This section describes tunnel establishment; section 4.4.4 following describes clients established within the tunnel.
L2F_OPEN消息用于提供隧道设置关闭（MID为0）或在先前由L2F_CONF和L2F_OPEN消息（MID不等于0）建立的隧道内建立客户端连接。本节描述了隧道的建立；下文第4.4.4节描述了隧道内建立的客户。
An L2F_OPEN for tunnel establishment MUST contain only the sub-option 0x03, L2F_OPEN_RESP. This option MUST be followed by the octet 0x10, specifying the size of the 128-bit MD5 digest resulting from encrypting the challenge value in the L2F_CONF, along with the low byte of the Assigned_CLID. After this byte MUST be the sixteen bytes of the generated MD5 digest.
用于建立隧道的L2F_OPEN必须仅包含子选项0x03、L2F_OPEN_RESP。此选项后面必须紧跟八位字节0x10，指定加密L2F_CONF中的质询值所产生的128位MD5摘要的大小，以及分配的_CLID的低位字节。该字节之后必须是生成的MD5摘要的16个字节。
If during tunnel establishment an L2F_OPEN is received with an incorrect L2F_OPEN_RESP, the packet MUST be silently discarded. It is recommended that such an event generate a log event as well.
如果在隧道建立期间接收到L2F_OPEN_RESP错误的L2F_OPEN_，则必须以静默方式丢弃数据包。建议此类事件也生成日志事件。
An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway indicates the presence of a new dial-in client. When sent back from the Home Gateway to the NAS, it indicates acceptance of the client. This message starts with the octet 0x02. When sent from the NAS, it may contain further sub-options. When sent from the Home Gateway, it may not contain any sub-options. All further discussion of sub-options in this section apply only to the NAS to Home Gateway direction.
从NAS发送到家庭网关的L2F_OPEN（具有非零MID）表示存在新的拨入客户端。从家庭网关发送回NAS时，表示接受客户端。此消息以八位字节0x02开头。从NAS发送时，它可能包含更多的子选项。从家庭网关发送时，它可能不包含任何子选项。本节中关于子选项的所有进一步讨论仅适用于NAS到家庭网关方向。
The L2F_OPEN_TYPE sub-option MUST be present. It is encoded as the octet 0x06, followed by a single byte describing the type of authentication the NAS exchanged with the client in detecting the client's claimed identification. Implicit in the authentication type is the encapsulation to be carried over the life of the session. The authentication types are:
L2F\u OPEN\u类型子选项必须存在。它被编码为八位字节0x06，后跟一个字节，用于描述NAS在检测客户端声明的标识时与客户端交换的身份验证类型。身份验证类型中隐含的是会话生命周期中要进行的封装。身份验证类型包括：
0x01 Textual username/password exchange for SLIP 0x02 PPP CHAP 0x03 PPP PAP 0x04 PPP no authentication 0x05 SLIP no authentication
0x01纸条的文本用户名/密码交换0x02 PPP CHAP 0x03 PPP PAP 0x04 PPP无身份验证0x05纸条无身份验证
The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed by an octet specifying the length of the name, followed by the indicated number of bytes of the name. This field MUST be present for any authentication type except 0x04 (None). It MUST contain the name specified in the client's authentication response.
L2F_OPEN_NAME子选项被编码为八位字节0x01，后跟一个指定名称长度的八位字节，后跟指定的名称字节数。对于除0x04（无）之外的任何身份验证类型，此字段都必须存在。它必须包含客户端身份验证响应中指定的名称。
The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed by an octet specifying the length of the challenge sent, followed by the challenge itself. This field is only present for CHAP, and MUST contain the challenge value sent to the client by the NAS.
L2F_OPEN_CHAL子选项编码为八位字节0x02，后跟一个八位字节，指定发送的质询的长度，后跟质询本身。此字段仅用于CHAP，并且必须包含NAS发送到客户端的质询值。
The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed by an octet specifying the length of the response received, followed by the client's response to the challenge. For CHAP, this field contains the response value received by the NAS. For PAP or textual authentication, it contains the clear text password received from the client by the NAS. This field is absent for authentication 0x04 "None".
L2F_OPEN_RESP子选项编码为八位字节0x03，后跟一个八位字节，指定接收到的响应的长度，后跟客户端对质询的响应。对于CHAP，此字段包含NAS接收的响应值。对于PAP或文本身份验证，它包含NAS从客户端接收的明文密码。身份验证0x04“无”缺少此字段。
The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the octets 0x04 and 0x05 respectively, followed in either case by two octets in network byte order specifying the length of the LCP CONFACK last received from or sent to the client. Following these octets is an exact copy of the CONFACK packet. L2F_ACK_LCP1 specifies a copy of the closing CONFACK received from the client, and L2F_ACK_LCP2 specifies a copy of the closing CONFACK sent to the client by the NAS.
L2F_ACK_LCP1和L2F_ACK_LCP2子选项分别编码为八位字节0x04和0x05，在这两种情况下，后跟两个八位字节，以网络字节顺序指定上次从客户端接收或发送到客户端的LCP确认的长度。在这些八位字节之后是CONFACK数据包的精确副本。L2F_ACK_LCP1指定从客户端接收的结束确认的副本，L2F_ACK_LCP2指定NAS发送到客户端的结束确认的副本。
The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by two octets in network byte order specifying the length of the LCP CONFREQ initially received from the client. This may be used by the Home Gateway to detect capabilities of the client which were negotiated away while starting LCP with the NAS. Detection of such options may be used by the Home Gateway to decide to renegotiate LCP.
L2F_REQ_LCP0子选项编码为八位字节0x08，后跟两个八位字节，以网络字节顺序指定最初从客户端接收的LCP CONFREQ的长度。这可由家庭网关用于检测在使用NAS启动LCP时协商掉的客户端功能。家庭网关可使用对此类选项的检测来决定重新协商LCP。
The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by a single octet. This sub-option is only present for CHAP; the single octet contains the CHAP Identifier value sent to the client during the CHAP challenge.
L2F_OPEN_ID子选项编码为八位字节0x06，后跟一个八位字节。此子选项仅适用于CHAP；单个八位组包含CHAP质询期间发送给客户端的CHAP标识符值。
The Home Gateway may choose to ignore any sub-option of the L2F_OPEN, and accept the connection anyway. The Home Gateway would then have to undertake its own LCP negotiations and authentication. To maximize the transparency of the L2F tunnel, it is recommended that extra negotiations and authentication be avoided if possible.
家庭网关可以选择忽略L2F_打开的任何子选项，并无论如何接受连接。然后，家庭网关必须进行自己的LCP协商和认证。为了最大限度地提高L2F隧道的透明度，建议尽可能避免额外的协商和认证。
This message is encoded as the byte 0x03. An L2F_CLOSE may be sent by either side of the tunnel at any time. When sent with MID of 0, it indicates the desire to terminate the entire tunnel and all clients within the tunnel. When sent from the Home Gateway in response to an L2F_OPEN, it indicates that the Home Gateway has declined the connection. When sent with a non-zero MID, it indicates the termination of that client within the tunnel.
此消息编码为字节0x03。隧道两侧可随时发送L2F_关闭。当MID为0时，表示希望终止整个隧道和隧道内的所有客户端。当从家庭网关发送以响应L2F_打开时，表示家庭网关已拒绝连接。当使用非零MID发送时，它表示隧道内该客户端的终止。
The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed four bytes in network byte order specifying a bit mask of reasons for the disconnection. The bits are encoded as:
L2F_CLOSE_WHY子选项编码为字节0x01，后跟网络字节顺序中的四个字节，指定断开原因的位掩码。这些位被编码为：
0x00000001 Authentication failed 0x00000002 Out of resources 0x00000004 Administrative intervention 0x00000008 User quota exceeded 0x00000010 Protocol error 0x00000020 Unknown user 0x00000040 Incorrect password 0x00000080 PPP configuration incompatible 0x00000100 Wrong multilink PPP destination
0x00000001身份验证失败0x00000002资源不足0x00000004管理干预0x00000008用户配额超过0x00000010协议错误0x00000020未知用户0x00000040错误密码0x00000080 PPP配置不兼容0x00000100错误多链路PPP目标
Bits in the mask 0xFF000000 are reserved for per-vendor interpretation.
掩码0xFF000000中的位保留用于每个供应商的解释。
An implementation can choose to not provide status bits even if it detects a condition described by one of these bits. For instance, an implementation may choose to not use 0x00000020 due to security considerations, as it can be used to probe user name space.
实现可以选择不提供状态位，即使它检测到由这些位之一描述的条件。例如，出于安全考虑，实现可能会选择不使用0x00000020，因为它可以用于探测用户名空间。
The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by a two-byte length in network byte order, followed by the indicated number of bytes, which are interpreted as descriptive ASCII text associated with the disconnection. This string may be ignored, but could be recorded in a log to provide detailed or auxiliary information associated with the L2F_CLOSE.
L2F_CLOSE_STR子选项编码为字节0x02，后跟网络字节顺序的两字节长度，后跟指定的字节数，这些字节数被解释为与断开连接相关的描述性ASCII文本。此字符串可以忽略，但可以记录在日志中，以提供与L2F_关闭相关的详细或辅助信息。
Transmission of L2F_ECHO messages is optional. If an implementation transmits L2F_ECHO messages, it MUST not transmit more than one such request each second. The payload size MUST be 64 bytes or less in length. It is recommended that at least 5 L2F_ECHO messages be sent without response before an implementation assumes that its peer has terminated.
L2F_回显消息的传输是可选的。如果一个实现发送L2F_ECHO消息，它每秒不得发送超过一个这样的请求。有效负载大小的长度必须小于等于64字节。建议在实现假定其对等端已终止之前，至少发送5条L2F_ECHO消息而不进行响应。
The L2F_ECHO message is encoded as the single byte 0x04. It may be sent by either side once the tunnel is established. MID MUST be 0. An L2F_ECHO_RESP (documented below) MUST be sent back in response.
L2F_回显消息编码为单字节0x04。一旦隧道建成，可由任何一方发送。MID必须为0。L2F_ECHO_RESP（记录如下）必须发回响应。
All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP. The received packet MUST be sent back verbatim, except that the CLID, sequence number, and checksum (if any) MUST be updated, and the L2F_ECHO message type changed to an L2F_ECHO_RESP. Payload data following the 0x04 octet, if any, MUST be preserved in the response.
所有实现都必须使用L2F_ECHO_RESP响应L2F_ECHO。接收到的数据包必须逐字发送回，但必须更新CLID、序列号和校验和（如果有），并且L2F_ECHO消息类型更改为L2F_ECHO_RESP。响应中必须保留0x04八位字节后的有效负载数据（如果有）。
When an L2F_ECHO_RESP is received, the payload data may be used to associate this response with a previously sent L2F_ECHO, or the packet may be silently discarded.
当接收到L2F_ECHO_RESP时，有效载荷数据可用于将该响应与先前发送的L2F_ECHO相关联，或者该分组可被静默地丢弃。
L2F is designed to operate over point-to-point unreliable links. It is not designed to provide flow control of the data traffic, nor does it provide reliable delivery of this traffic; each protocol tunnel carried via L2F is expected to manage flow control and retry itself. Thus, it is only L2F control messages which must be retransmitted; this process is described in this section.
L2F设计用于在点对点不可靠链路上运行。其设计目的不是提供数据流量的流量控制，也不是提供该流量的可靠交付；通过L2F承载的每个协议隧道都需要管理流控制并自行重试。因此，只有L2F控制消息必须重新传输；本节将介绍此过程。
All L2F control messages (i.e., those L2F packets with a protocol type of 0x01) are transmitted with a sequence number. The sequence number is a per-L2F tunnel free running counter which is incremented (modulo 256) after each packet is transmitted. It is used to permit the receiving end to detect duplicated or out-of-order packets, and to discard such packets. Section 4.2.5 describes the process in detail.
所有L2F控制消息（即协议类型为0x01的L2F数据包）都使用序列号进行传输。序列号是一个per-L2F隧道自由运行计数器，在每个数据包传输后递增（模256）。它用于允许接收端检测重复或无序的数据包，并丢弃这些数据包。第4.2.5节详细描述了该过程。
L2F control messages are expected to be exchanged lock-step. Thus, per-client activities can not occur until tunnel setup is complete. Neither can one client be serviced until the L2F message exchange is complete for a previous client. Thus, it is expected that rarely--if ever--should a flow control action be required. If the input queue of L2F control messages reaches an objectionable level for an implementation, the implementation may silently discard all messages in the queue to stabilize the situation.
L2F控制信息应在锁定步骤中交换。因此，在隧道设置完成之前，每个客户端的活动都不能发生。在前一个客户端的L2F消息交换完成之前，不能为一个客户端提供服务。因此，预计很少（如果有的话）需要流控制操作。如果L2F控制消息的输入队列达到某个实现的不良级别，则该实现可能会自动丢弃队列中的所有消息以稳定情况。
The following enumerates the handling of L2F messages for tunnel creation in state table format. Events name an L2F_ message type (the L2F_ portion of the named message is omitted to permit a more compact table). A start ("*") matches any event not otherwise matched for the named state.
下面列举了以状态表格式创建隧道时L2F消息的处理。事件名称为L2F_u消息类型（省略命名消息的L2F_u部分以允许更紧凑的表）。开始（“*”）匹配任何与命名状态不匹配的事件。
A NAS starts at initial state Start0, sending a packet before waiting for its first event. A Home Gateway starts at Start1, waiting for an initial packet to start service.
NAS从初始状态Start0开始，在等待其第一个事件之前发送数据包。家庭网关从Start1开始，等待初始数据包开始服务。
If an event is not matched for a given state, the packet associated with that event is silently discarded.
如果某个事件与给定状态不匹配，则与该事件关联的数据包将被静默丢弃。
Tunnel establishment (MID == 0), NAS side.
隧道建立（MID==0），NAS侧。
State Event Action New State
----- ----- ------ ---------
Start0 Send CONF Start1
Start1 CONF Send OPEN Start2
Start1 timeout 1-3 Send CONF Start1
Start1 timeout 4 Clean up tunnel (done)
Start2 OPEN (initiate 1st client) Open1
Start2 timeout 1-3 Send OPEN Start2
Start2 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 no MIDs open Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
Close2 CLOSE Clean up tunnel (done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up tunnel (done)
State Event Action New State
----- ----- ------ ---------
Start0 Send CONF Start1
Start1 CONF Send OPEN Start2
Start1 timeout 1-3 Send CONF Start1
Start1 timeout 4 Clean up tunnel (done)
Start2 OPEN (initiate 1st client) Open1
Start2 timeout 1-3 Send OPEN Start2
Start2 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 no MIDs open Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
Close2 CLOSE Clean up tunnel (done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up tunnel (done)
Tunnel establishment (MID == 0), Home Gateway side.
家庭网关侧的隧道建立（MID==0）。
State Event Action New State
----- ----- ------ ---------
Start0 CONF Send CONF Start1
Start1 CONF Send CONF Start1
Start1 OPEN Send OPEN Open1
Start1 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 OPEN (MID > 0) (1st client, below) Open2
Open1 CLOSE Send CLOSE Close1
Open1 timeout 4 Clean up tunnel (done)
State Event Action New State
----- ----- ------ ---------
Start0 CONF Send CONF Start1
Start1 CONF Send CONF Start1
Start1 OPEN Send OPEN Open1
Start1 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 OPEN (MID > 0) (1st client, below) Open2
Open1 CLOSE Send CLOSE Close1
Open1 timeout 4 Clean up tunnel (done)
Open2 OPEN (MID > 0) (below) Open2 Open2 CLOSE Send CLOSE Close1 Close1 CLOSE Send CLOSE Close1 Close1 timeout 4 Clean up tunnel (done)
打开2打开（中间>0）（下方）打开2打开2关闭发送关闭1关闭1关闭发送关闭1关闭超时4清理通道（完成）
This table is similar to the previous one, but enumerates the states for a client connection within a tunnel in the opened state from 4.5.3. As this sequence addresses clients, MID will be non-zero.
此表与上一个表类似，但从4.5.3中列举了处于打开状态的隧道内客户端连接的状态。由于该序列寻址客户机，MID将为非零。
Client establishment (MID != 0), NAS side.
客户端建立（MID！=0），NAS端。
State Event Action New State
----- ----- ------ ---------
Start0 Send OPEN Start1
Start1 OPEN (enable forwarding) Open1
Start1 CLOSE Clean up MID (MID done)
Start1 timeout 1-3 Send OPEN Start1
Start1 timeout 4 Clean up MID (MID done)
Start1 client done Send CLOSE Close2
Open1 OPEN (no change) Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
State Event Action New State
----- ----- ------ ---------
Start0 Send OPEN Start1
Start1 OPEN (enable forwarding) Open1
Start1 CLOSE Clean up MID (MID done)
Start1 timeout 1-3 Send OPEN Start1
Start1 timeout 4 Clean up MID (MID done)
Start1 client done Send CLOSE Close2
Open1 OPEN (no change) Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Client establishment (MID != 0), Home Gateway side.
客户端建立（MID！=0），家庭网关端。
State Event Action New State
----- ----- ------ ---------
Start0 OPEN Send OPEN Open1
Start0 OPEN (fail) Send CLOSE Close3
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Close3 OPEN Send CLOSE Close3
Close3 timeout 4 Clean up MID (MID done)
State Event Action New State
----- ----- ------ ---------
Start0 OPEN Send OPEN Open1
Start0 OPEN (fail) Send CLOSE Close3
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Close3 OPEN Send CLOSE Close3
Close3 timeout 4 Clean up MID (MID done)
Several aspects of operation over L2F, while outside the realm of the protocol description itself, serve to clarify the operation of L2F.
L2F上操作的几个方面，虽然不在协议描述本身的范围内，但有助于澄清L2F的操作。
Because L2F in operation carries uninterpreted frames, it permits operation of features without explicit knowledge of these features. For instance, if a PPP session is carried, L2F is simply transporting HDLC frames. The two PPP endpoints can negotiate higher-level features, such as reliable link, compression, multi-link, or encryption. These features then operate between the two PPP endpoints (the dial-in client on one end, and the Home Gateway on the other), with L2F continuing to simply ship HDLC frames back and forth.
由于运行中的L2F携带未解释的帧，因此它允许在不明确了解这些特征的情况下运行特征。例如，如果进行PPP会话，L2F只是传输HDLC帧。两个PPP端点可以协商更高级别的功能，例如可靠链路、压缩、多链路或加密。然后，这些功能在两个PPP端点（一端是拨入客户端，另一端是家庭网关）之间运行，L2F继续简单地来回发送HDLC帧。
For similar reasons, PPP echo requests, NCP configuration negotiation, and even termination requests, are all simply tunneled HDLC frames.
出于类似的原因，PPP回送请求、NCP配置协商，甚至终止请求都只是隧道HDLC帧。
As L2F simply tunnels link-layer frames, it does not detect frames like PPP TERMREQ. L2F termination in these scenarios is driven from a protocol endpoint; for instance, if a Home Gateway receives a TERMREQ, its action will be to "hang up" the PPP session. It is the responsibility of the L2F implementation at the Home Gateway to convert a "hang up" into an L2F_CLOSE action, which will shut down client's session in the tunnel cleanly. L2F_CLOSE_WHY and L2F_CLOSE_STR may be included to describe the reason for the shutdown.
由于L2F只是隧道连接层帧，它不会检测像PPP TERMREQ这样的帧。这些场景中的L2F终止由协议端点驱动；例如，如果家庭网关收到TERMREQ，其操作将是“挂断”PPP会话。家庭网关的L2F实现负责将“挂起”转换为L2F_关闭操作，这将完全关闭隧道中的客户端会话。L2F_CLOSE_WHY和L2F_CLOSE_STR可用于描述停机原因。
L2F is compatible with both PAP and CHAP protocols. SLIP does not provide authentication within the protocol itself, and thus requires an ASCII exchange of username and password before SLIP is started. L2F is compatible with this mode of operation as well.
L2F兼容PAP和CHAP协议。SLIP在协议本身中不提供身份验证，因此需要在启动SLIP之前交换ASCII用户名和密码。L2F也与此操作模式兼容。
One-time password cards have become very common. To the extent the NAS can capture and forward the one-time password, L2F operation is compatible with password cards. For the most general solution, an arbitrary request/response exchange must be supported. In an L2F environment, the protocol must be structured so that the NAS can detect the apparent identity of the user and establish a tunnel connection to the Home Gateway, where the arbitrary exchange can occur.
一次性密码卡已经变得非常普遍。在NAS能够捕获和转发一次性密码的范围内，L2F操作与密码卡兼容。对于最通用的解决方案，必须支持任意请求/响应交换。在L2F环境中，协议的结构必须确保NAS能够检测到用户的明显身份，并建立到家庭网关的隧道连接，在那里可以进行任意交换。
L2F appears compatible with Apple's ARAP protocol. Its operation under L2F has not been described simply because this experimental RFC does not have a corresponding implementation of such operation.
L2F似乎与苹果的ARAP协议兼容。它在L2F下的操作并没有简单描述，因为这个实验性RFC并没有这种操作的相应实现。
L2F tries to be self-describing, operating at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. This section describes the issues which have been found when operating L2F over IP and UDP.
L2F试图自我描述，在承载它的特定媒体之上的级别上运行。然而，为了实现可互操作性，需要一些与媒体连接的细节。本节介绍通过IP和UDP操作L2F时发现的问题。
L2F uses the well-known UDP port 1701 [4]. The entire L2F packet, including payload and L2F header, is sent within a UDP datagram. The source and destination ports are the same (1701), with demultiplexing being achieved using CLID values. It is legal for the source IP address of a given CLID to change over the life of a connection, as this may correspond to a peer with multiple IP interfaces responding to a network topology change. Responses should reflect the last source IP address for that CLID.
L2F使用众所周知的UDP端口1701[4]。整个L2F数据包（包括有效负载和L2F报头）在UDP数据报中发送。源端口和目标端口相同（1701），使用CLID值实现解复用。给定CLID的源IP地址在连接生命周期内发生更改是合法的，因为这可能对应于具有多个IP接口的对等方对网络拓扑更改做出响应。响应应反映该CLID的最后一个源IP地址。
IP fragmentation may occur as the L2F packet travels over the IP substrate. L2F makes no special efforts to optimize this. A NAS implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for NAS environments in which the MTUs of the path over which the L2F packets are likely to travel have a consistent value.
当L2F包在IP基板上移动时，可能会发生IP碎片。L2F没有特别努力来优化这一点。NAS实施可能会导致其LCP协商特定的MRU，这可能会优化L2F数据包可能经过的路径MTU具有一致值的NAS环境。
L2F uses a packet format inspired by GRE [5]. Thanks to Fred Baker for consultation, Dave Carrel for consulting on security aspects, and to Paul Traina for philosophical guidance.
L2F使用了受GRE[5]启发的数据包格式。感谢Fred Baker提供咨询，Dave Carrel提供安全方面的咨询，Paul Traina提供哲学指导。
[1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP", RFC 1055, June 1988.
[1] Romkey，J.，“通过串行线路传输IP数据报的非标准：SLIP”，RFC 1055，1988年6月。
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662, July 1994.
[3] 辛普森，W.“HDLC类框架中的PPP”，标准51，RFC1662，1994年7月。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[4] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[5] Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
Security issues are discussed in Section 3.1.
第3.1节讨论了安全问题。
Tim Kolar Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
蒂姆·科拉尔·思科系统有限公司加利福尼亚州圣何塞西塔斯曼大道170号95134-1706
EMail: tkolar@cisco.com
EMail: tkolar@cisco.com
Morgan Littlewood Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
摩根·利特伍德思科系统有限公司加利福尼亚州圣何塞西塔斯曼大道170号95134-1706
EMail: littlewo@cisco.com
EMail: littlewo@cisco.com
Andy Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
安迪瓦伦西亚思科系统有限公司加利福尼亚州圣何塞西塔斯曼大道170号95134-1706
EMail: valencia@cisco.com
EMail: valencia@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。