[要約] RFC 2341は、CiscoのL2Fプロトコルに関する要約であり、L2Fはレイヤー2の転送を提供するためのプロトコルです。目的は、リモートアクセス接続を安全かつ効率的に提供することです。
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 Layer Two Forwarding（プロトコル）「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.
Copyright（C）The Internet Society（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]を介したマルチプロトコルダイヤルアップをサポートするためのプロトコルが指定されていました。このドキュメントでは、上位レベルのプロトコルのリンク層（HDLC、非同期HDLC、またはSLIPフレーム）のトンネリングを可能にするLayer Two Forwardingプロトコル（L2F）について説明します。このようなトンネルを使用すると、最初のダイヤルアップサーバーの場所を、ダイヤルアッププロトコル接続が終了している場所から離して、提供されているネットワークにアクセスすることができます。
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 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
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 L2F内のSLIPのカプセル化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パケットの優先度14 4.3 L2Fトンネルの確立14 4.3.1通常のトンネルネゴシエーションシーケンス15 4.3.2通常のクライアントネゴシエーションシーケンス17 4.4 L2F管理メッセージタイプ18 4.4.1 L2Fメッセージタイプ：無効18 4.4.2 L2F_CONF 19 4.4.3 L2F_OPEN、トンネル確立20 4.4.4 L2F_OPEN、クライアント確立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リモートアクセスプロトコル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.
インターネット上の従来のダイヤルアップネットワークサービスは、登録済み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の目的は、マルチプロトコルダイヤルアップサービスを既存のインターネットサービスプロバイダーのPoint of Presence（以降、それぞれ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 SHOULD or RECOMMEND-例外的な状況を除いて、通常はこの項目に従う必要があります。
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] |________________________________|
[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.
仮想ダイヤルアップサービスが必要ない場合は、インターネットへの標準アクセスを提供できます。
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.
目的のホームゲートウェイへのトンネル接続が現在存在しない場合は、1つが開始されます。 L2Fは、トンネルが確立されるメディアの詳細から大部分が隔離されるように設計されています。 L2Fは、トンネルメディアがパケット指向のポイントツーポイント接続を提供することのみを必要とします。このようなメディアの明白な例は、UDP、フレームリレーPVC、またはX.25 VCです。 UDPを介したL2F操作の詳細については、セクション5.5で説明します。 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 CONFACKのコピーも含まれます。ホームゲートウェイは、この情報を使用して自身の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を物理インターフェイスからリモートユーザーに送信する前に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接続であり、そのエンドポイントは、リモートユーザーのネットワークアプリケーションの一端であり、この接続のホームゲートウェイの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接続通知には、ホームゲートウェイがLCPステートマシンを認証および初期化するための十分な情報が含まれているため、リモートユーザーがCHAP認証のために2回目のクエリを受ける必要も、クライアントが複数回の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.
認証、アドレスの割り当て、承認、アカウンティングに関して、標準のインターネットアクセスサービスと仮想ダイヤルアップサービスの間にはいくつかの重要な違いがあります。これらのサービスの違いの詳細と、これらの違いによって生じる問題について、以下で説明します。仮想ダイヤルアップサービスに使用されるメカニズムは、従来のメカニズムと共存することを目的としています。 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.
ユーザーの認証は3つのフェーズで行われます。 1つ目はISPで、2つ目はオプションで3つ目はホームゲートウェイです。
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).
ホームゲートウェイは、接続を受け入れるかどうかを決定することにより、2番目のフェーズを開始します。接続表示には、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またはSLIP層で認証の第3フェーズを自由に実行できます。これらのアクティビティはこの仕様の範囲外ですが、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:
仮想ダイヤルアップサービスのプロトコル定義には、2つの標準化分野が必要です。
+ 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パケットをインターネット上で正常に送受信できるように、カプセル化プロトコルについて共通の理解が必要です。
+ 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とMIDの接続管理。トンネルは、トンネル内の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は、PPPとほとんど同じ方法でL2F内にカプセル化されます。フレーミングと同様に、L2F内にカプセル化する前に透明文字が削除されます。
The entire encapsulated packet has the form:
カプセル化されたパケット全体の形式は次のとおりです。
---------------------------------
| |
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver ("Version") field represents the major version of the L2F software creating the packet. It MUST contain the value 001.
Ver（ "Version"）フィールドは、パケットを作成する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パケット内で伝送されるプロトコルを指定します。正当な値（ここでは16進数で表記）は次のとおりです。
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_ILLEGAL不正0x01 L2F_PROTO L2F管理パケット0x02 L2F_PPP PPPがL2F内でトンネリング0x03 L2F_SLIP SLIPが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_ILLEGALのプロトコルまたはその他の認識されない値で受信された場合、4.4.1で定義されているように、不正なパケットとして扱われなければなりません（MUST）。
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に設定できます。 L2F以外の管理パケットがSビットセットで受信された場合、その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を法として表されるフリーランニングカウンターです。各個別のMID値には、個別のシーケンス番号の状態（つまり、カウンター）があります。
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パケットのシーケンス番号を記録します。受信したパケットが最後に受信した値以下の値を持っているように見える場合、パケットは静かに破棄されなければなりません（MUST）。それ以外の場合、パケットは受け入れられ、パケット内のシーケンス番号が最後に受信された最新の値として記録されます。
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が割り当てられます。以前のセッションと現在のセッションの間のエイリアシングを減らすために、MIDは16ビット名前空間全体を循環することをお勧めします。以前にトンネル内で使用されていたMID値が閉じられ、現在は再び使用されるため、完全に新しいMIDと見なし、そのように初期化する必要があります。
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 other type is sent on MID 0, the packet is illegal and MUST be processed as defined in 4.4.1.
値0のMIDは特別です。トンネル内の接続とは異なり、トンネル自体の状態を伝えるために使用されます。 L2F_PROTOパケットのみ、0のMIDを使用して送信できます。他のタイプがMID 0で送信される場合、パケットは不正であり、4.4.1で定義されているように処理されなければなりません（MUST）。
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は、Assigned_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を持つパケットは、通知なく破棄されなければなりません（MUST）。
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.
長さは、ヘッダー、存在するすべてのフィールド、およびペイロードを含む、パケット全体のオクテット単位のサイズです。長さは、チェックサムが存在する場合、チェックサムの追加を反映していません。受信したパケットが指定された長さよりも短い場合、パケットは静かに破棄されます。示された長さを超えてパケットに存在する追加のバイトは黙って無視されなければなりません（MUST）。
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です。 L2Fフラグの最初のバイトからペイロードデータの最後のバイトまで、パケット全体に適用されます。チェックサムは、ペイロードデータの最後のバイトの直後に2バイトとして追加されます。
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フィールドが存在します。キーは、トンネルの作成中にピアに最後に与えられた認証応答に基づいています（トンネル作成の詳細については、次のセクションで説明します）。セッションの存続期間中、なりすましに基づく攻撃に抵抗するためのキーとして機能します。キーが期待値と一致しないパケットが受信された場合、パケットは黙って破棄されなければなりません（MUST）。このような処理は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ビット認証応答を取得し、ネットワークバイトオーダーで4つの隣接する32ビットワードとして解釈し、これらのワードをXORし、結果の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キープアライブトラフィックがある場合は、このビットを設定して送信することをお勧めします。
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.
各パケットは、1つの行に送信元->宛先として記述され、次の行に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.
この例ではKeyオプションを使用していますが、OffsetおよびChecksumオプションは使用していないことに注意してください。長さフィールドは、オクテットストリームとしてエンコードされたパケットの実際の長さを反映して存在します。
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_CONF Name：NAS_name Challenge：Rnd Assigned_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パケットは、L2F管理メッセージが含まれていることを示すProtoフィールドとともに送信されます。
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.
トンネルが開始されているため、Keyは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_CONF Name：GW_name Challenge：Rnd2 Assigned_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のAssigned_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フィールドに配置するための独自のAssigned_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_OPEN応答：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_OPEN応答の「応答」フィールドに含まれています。
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_OPEN応答：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_OPEN Type：CHAP Name：CHAP-name Challenge：Rnd3 Response：<値を受信しました。おそらく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は呼び出しを受信し、Rnd3のチャレンジ値でCHAPを試行し、クライアントが応答したことを発見しました。主張された名前は、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_OPEN
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プロトコルではないため、通常は非L2Fメッセージで0に設定されるSeqフィールドを使用しません（これの例外の詳細については、セクション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管理を指定している場合、パケットの本文は0個以上のオプションとしてエンコードされます。オプションは、1オクテットの「メッセージタイプ」であり、その後に0個以上のサブオプションが続きます。各サブオプションは、1バイトのサブオプション値であり、サブオプションに応じてさらにバイトが追加されます。
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
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.
この値、または最後に認識されたオプション値より大きい値でメッセージを受信した場合、またはこの仕様の他の部分で定義されている不正なパケットを受信した場合、そのパケットは無効と見なされます。パケットは破棄されなければならず（MUST）、トンネル全体のL2F_CLOSEが要求されなければなりません（MUST）。 L2F_CLOSEを受信すると、トンネル自体を閉じることができます。他のすべての受信メッセージは破棄されなければなりません。実装は、トンネルの特性に適した時間間隔の後にトンネルを閉じることができます。
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）で始まり、その後に以下の3つのサブオプションすべてが続きます。
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としてエンコードされ、その後に4バイトのAssigned_CLID値が続きます。 Assigned_CLID値は、送信システムに存在するすべてのトンネル全体で一意のゼロ以外の16ビット整数値として生成されます。 Assigned_CLIDの最下位2オクテットはこの値に設定され、最上位2オクテットは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フィールドは、NASからホームゲートウェイへの初期L2F_CONFパケットで0として送信されます。それ以外の場合は、最後に受信した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.
L2F_CONFは、ホームゲートウェイからNASに送信されると、ホームゲートウェイがトンネル作成要求を認識したことを示します。ホームゲートウェイは、メッセージ本文にその名前と独自のチャレンジを提供する必要があります。
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ビット、シークレット、およびチャレンジ値を連結して行われます。 32ビットのキー値の生成については、セクション4.2.11で説明します。
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ダイジェストのサイズと、Assigned_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が不正なL2F_OPEN_RESPとともに受信された場合、パケットは通知なく破棄されなければなりません（MUST）。そのようなイベントがログイベントも生成することをお勧めします。
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_OPEN_TYPEサブオプションが存在している必要があります。これは、オクテット0x06としてエンコードされ、その後に、クライアントの要求されたIDを検出する際にNASがクライアントと交換した認証のタイプを説明する1バイトが続きます。認証タイプで暗黙的に行われるのは、セッションの存続期間にわたって実行されるカプセル化です。認証タイプは次のとおりです。
0x01 Textual username/password exchange for SLIP 0x02 PPP CHAP 0x03 PPP PAP 0x04 PPP no authentication 0x05 SLIP no authentication
0x01 SLIPのテキストによるユーザー名/パスワードの交換0x02 PPP CHAP 0x03 PPP PAP 0x04 PPP認証なし0x05 SLIP認証なし
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の長さを指定するネットワークバイトオーダーの2つのオクテットが続きます。これらのオクテットに続くのはCONFACKパケットの正確なコピーです。 L2F_ACK_LCP1はクライアントから受信した終了CONFACKのコピーを指定し、L2F_ACK_LCP2はNASがクライアントに送信した終了CONFACKのコピーを指定します。
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の長さを指定するネットワークバイトオーダーの2つのオクテットが続きます。これはホームゲートウェイで使用され、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としてエンコードされ、その後に1つのオクテットが続きます。このサブオプションは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_OPENのサブオプションを無視して、とにかく接続を受け入れることを選択できます。その後、ホームゲートウェイは独自の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_CLOSEはいつでもトンネルのどちら側からでも送信できます。 MIDが0で送信された場合、それはトンネル全体とトンネル内のすべてのクライアントを終了したいことを示しています。 L2F_OPENへの応答としてホームゲートウェイから送信された場合、ホームゲートウェイが接続を拒否したことを示しています。ゼロ以外の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としてエンコードされ、切断の理由のビットマスクを指定するネットワークバイトオーダーで4バイトが続きます。ビットは次のようにエンコードされます。
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.
実装は、これらのビットの1つによって記述された条件を検出した場合でも、ステータスビットを提供しないように選択できます。たとえば、実装は、ユーザー名空間の調査に使用できるため、セキュリティ上の理由から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としてエンコードされ、その後にネットワークバイトオーダーで2バイトの長さが続き、指定されたバイト数が続きます。これは、切断に関連する説明的なASCIIテキストとして解釈されます。この文字列は無視できますが、ログに記録して、L2F_CLOSEに関連する詳細情報または補助情報を提供できます。
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_ECHOメッセージの送信はオプションです。実装がL2F_ECHOメッセージを送信する場合、そのような要求を毎秒2つ以上送信してはならない（MUST）。ペイロードのサイズは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_ECHOメッセージは、シングルバイト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オクテットに続くペイロードデータは、もしあれば、応答で保存されなければなりません（MUST）。
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パケット）は、シーケンス番号とともに送信されます。シーケンス番号は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メッセージ交換が完了するまで、1つのクライアントにサービスを提供することはできません。したがって、フロー制御アクションが必要になることはめったにありません。 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_メッセージタイプを指定します（指定されたメッセージのL2F_部分は、テーブルをよりコンパクトにするために省略されています）。開始（ "*"）は、指定された状態に一致しないイベントに一致します。
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)
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)
Open2 OPEN (MID > 0) (below) Open2
Open2 CLOSE Send CLOSE Close1
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
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から、opened状態のトンネル内のクライアント接続の状態を列挙しています。このシーケンスはクライアントをアドレス指定するため、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)
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)
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フレームを単に転送しています。 2つのPPPエンドポイントは、信頼できるリンク、圧縮、マルチリンク、暗号化などの上位レベルの機能をネゴシエートできます。これらの機能は、2つの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_CLOSEアクションに変換するのは、ホームゲートウェイでの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がユーザーの見かけのIDを検出し、任意の交換が発生するホームゲートウェイへのトンネル接続を確立できるように、プロトコルを構造化する必要があります。
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はAppleの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値を使用して逆多重化が行われます。ネットワークトポロジの変更に応答する複数のIPインターフェイスを持つピアに対応している場合があるため、特定のCLIDの送信元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] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662, July 1994.
[3] シンプソン、W。、「PPP in HDLC-like Framing」、STD 51、RFC 1662、1994年7月。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[4] Reynolds、J.、およびJ. Postel、「Assigned Numbers」、STD 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.、Farinacci、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 1701、1994年10月。
Security issues are discussed in Section 3.1.
セキュリティの問題については、セクション3.1で説明します。
Tim Kolar Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
Tim Kolar Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
EMail: tkolar@cisco.com
Morgan Littlewood Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
Morgan Littlewood Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
EMail: littlewo@cisco.com
Andy Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
Andy Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
EMail: valencia@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。