RFC2341 日本語訳
2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M.Littlewood, T. Kolar. May 1998. (Format: TXT=66592 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Valencia
Request for Comments: 2341 M. Littlewood
Category: Historic T. Kolar
Cisco Systems
May 1998
コメントを求めるワーキンググループA.バレンシアの要求をネットワークでつないでください: 2341年のM.リトルウッドカテゴリ: 歴史的なT.コラールシスコシステムズ1998年5月
Cisco Layer Two Forwarding (Protocol) "L2F"
コクチマス層Twoの推進(プロトコル)"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)インターネット協会(1998)。 All rights reserved。
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.
仮想のダイヤルアップで、多くの別々の、そして、自治のプロトコルドメインがモデム、Access Servers、およびISDNルータを含む一般的なアクセスインフラストラクチャを共有できます。 前のRFCsはPPP[2]を通してSLIP[1]と「マルチ-プロトコル」ダイヤルアップでIPダイヤルアップをサポートするのにプロトコルを指定しました。 このドキュメントは、より高い平らなプロトコルのリンクレイヤ(すなわち、HDLC、async 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
1.0 序論3 1.1Conventions3 2.0Problem Space Overview3 2.1Initial Assumptions3 2.2Topology4 2.3VirtualダイヤルアップService--aもっとも、散歩5 3.0Service Model Issues7 3.1Security7 3.2Address配分8 3.3Authentication8 3.4Accounting8 4.0プロトコルDefinition、9、4.1Encapsulation、L2F10 4.1、L2F10の中のPPPの.1Encapsulation
Valencia, et. al. Historic [Page 1] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [1ページ]歴史的なRFC2341コクチマスL2F1998年5月
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 L2F10 4.2L2F Packet Format10 4.2.1Overall Packet Format10 4.2.2Packet Header11 4.2.3バージョンの中のSLIPのカプセル化が11 4.2.4プロトコル分野11 4.2.5Sequence Number12 4.2.6Packet Multiplex ID12 4.2.7Client ID13 4.2に.8Lengthをさばく、13、4.2; 9 パケットChecksum13 4.2.10有効搭載量Offset14 4.2.11パケットKey14 4.2.12パケット優先権14 4.3L2F Tunnel特権階級14 4.3.1Normal Tunnel Negotiation Sequence15 4.3.2Normal Client Negotiation Sequence17 4.4L2F管理メッセージは4.4.1L2Fメッセージがタイプする18をタイプします: 無効の18 4.4.2L2F_CONF19 4.4.3L2F_オープン、トンネル設立20 4.4.4L2F_オープン、クライアント設立20 4.4.5L2F_CLOSE22 4.4.6L2F_ECHO22 4.4.7L2F_ECHO_RESP23 4.5L2F Message Delivery23 4.5.1Sequenced Delivery23 4.5.2Flow Control23 4.5.3Tunnel州Table24 4.5.4Client州Table、25、5; 0 作者のIP/UDP27 6.0の承認27 7.0の参照箇所27 8.0のセキュリティ問題28 9.0のところでの5.5操作が28 10.0の完全な著作権宣言文29を扱うプロトコル問題26 5.1のppp機能26 5.2終了26 5.3の拡張認証26 5.4MNP4とアップルのリモートアクセス・プロトコル27
Valencia, et. al. Historic [Page 2] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [2ページ]歴史的なRFC2341コクチマスL2F1998年5月
1.0 Introduction
1.0 序論
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.
既存のインターネットサービスプロバイダのPresence(今後それぞれISPとPOPと呼ばれる)のPointと「マルチ-プロトコル」ダイヤルアップサービスを統合する際に遭遇する問題を特定して、既存のアクセス・プロトコルの力を入れを可能にするL2Fプロトコルについて説明するのは、このRFCの目的です。
1.1. Conventions
1.1. コンベンション
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 SHALL、MANDATORY--この項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o SHOULDかRECOMMEND--一般に、この商品はほとんど例外的な事情のために従われるべきです。
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、この商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2.0 Problem Space Overview
2.0 問題スペース概要
In this section we describe in high level terms the scope of the problem that will be explored in more detail in later sections.
このセクションでは、私たちは高い平らな用語でさらに詳細に後のセクションで探られる問題の範囲について説明します。
2.1 Initial Assumptions
2.1 初期の仮定
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でインターネット・アクセスを提供して、伝統的な登録されたIPアドレス以外のサービスを提供するというISP願望がネットワークのダイアルアップユーザーに対するサービスを基礎づけたと仮定することによって、私たちは始めます。
Valencia, et. al. Historic [Page 3] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [3ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
+ 終わりのSystem透明: リモートエンドシステムも彼のホームサイトホストも、安全な方法でこのサービスを利用するために少しの特別なソフトウェアも必要とするべきではありません。
+ 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(支払い目的のための)とユーザ(不渡りと監査のための)によって実行されるべきです。
2.2 Topology
2.2 トポロジー
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.
以下に示されているのは、Public切り換えられたTelephone Network(PSTN)アクセス(すなわち、モデムを通したasync PPP)とIntegrated Services Digital Network(ISDN)アクセス(すなわち、同期PPPアクセス)があるジェネリックインターネットです。 まるで彼らがホームゲートウェイにダイヤルされるかのようにリモート・ユーザー(async PPPかSLIPかISDNのどちらか)はホームLANにアクセスするでしょう、ISP Network Access Serverを通して彼らの物理的なダイヤルアップがありますが。
Valencia, et. al. Historic [Page 4] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [4ページ]歴史的なRFC2341コクチマスL2F1998年5月
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
...----[L]----+---[L]-----... | | [H]| ________|________________________ | | ________|__ ______|________ | | | | | PSTN[R][R]ISDN| | 雲| | 雲[N]__[U]| | インターネット| | | | [R]| [N]______[R]|_____________| | | | | | | [U]|________________________________|
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
[H] = ホームゲートウェイ[L]=ホームLAN[R]はルータ[U]=リモート・ユーザー[N]=ISPネットワークアクセス・サーバーと等しいです。(「NAS」)
2.3 Providing Virtual dial-up Services - a walk-through
2.3 VirtualダイヤルアップServicesを提供します--立ち稽古
To motivate the following discussion, this section walks through an example of what might happen when a Virtual dial-up client initiates access.
以下の議論を動機づけるために、このセクションはVirtualダイヤルアップクライアントがアクセサリーを開始するとき、何が起こるかもしれないかに関する例を通って歩きます。
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.
Remote UserはPSTNかISDNでPPP接続をISPに開始します。 Network Access Server(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を通して終わりのシステム/ユーザの部分的な認証を引き受けます。 ユーザ名分野だけが、ユーザがVirtualダイヤルアップサービスを必要とするかどうか決定するために解釈されます。 予想されますが、ユーザ名が構造化されるのが(例えば、 littlewo@cisco.com )必要ではありません。 あるいはまた、ISPはユーザをサービスに写像するデータベースを維持するかもしれません。 Virtualダイヤルアップの場合では、マッピングは特定の終点、ホームをゲートウェイと命名するでしょう。
If a virtual dial-up service is not required, standard access to the Internet may be provided.
仮想のダイヤルアップサービスを必要としないなら、インターネットへの標準アクセスを提供するかもしれません。
Valencia, et. al. Historic [Page 5] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [5ページ]歴史的なRFC2341コクチマスL2F1998年5月
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、Frame Relay PVC、またはX.25 VCのものです。 UDPの上のL2F操作のための詳細はセクション5.5に明らかにされます。 セクション4.4で始動するセクション4.2、メッセージタイプ、および意味論をL2Fパケット・フォーマットのための仕様に提供します。
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(将来の、そして、「中間」の)が割り当てられる未使用のMultiplex、およびaは指示を接続します。この新しいダイヤルアップセッションのホームゲートウェイに通知するために、送ります。 ホームゲートウェイは接続、または廃棄物を受け入れます。 拒絶は理由指示を含むかもしれません。(それは、ダイアルアップユーザーに表示されるかもしれません)。(その時、呼び出し切断されたべきでした後)。
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 CONFACKsのコピーを含むかもしれません。 ホームゲートウェイがそれ自身の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を取り除いているとのリモート・ユーザーへの物理インターフェース。
Valencia, et. al. Historic [Page 6] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [6ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
ここに、接続性は、終点が片端におけるリモート・ユーザーのネットワークアプリケーションとゲートウェイのSLIPかPPPがもう片方でサポートするホームへのこの接続性の終了である二地点間PPPかSLIP接続です。 リモート・ユーザーが単にホームゲートウェイアクセス・サーバーの別のダイヤルアップクライアントになったので、さらなる承認、プロトコルアクセス、およびフィルタリングに関する伝統的なメカニズムを使用することで現在、クライアントの接続性に対処できます。
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を使用することでいくつかの可能なAccountingのテクニックを例証しますが、この仕様の範囲の外にそのようなAccountingを囲む方針があります。
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.
L2Fが接続するので、PPPクライアントへの通知はホームゲートウェイがLCP州のマシンを認証して、初期化できるくらいの情報を含んでいて、リモート・ユーザーがもう一度、CHAP認証のために質問されて、クライアントがLCP交渉と集合の複数のラウンドを受けるのが必要ではありません。 これらのテクニックは、接続設定を最適化することを意図して、PPP仕様によって必要とされた機能を非難することを意図しません。
3.0 Service Model Issues
3.0 サービスモデル問題
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.
標準のインターネット・アクセスサービスとVirtualダイヤルアップサービスの間には、認証、アドレス配分、承認、および会計に関していくつかの著しい違いがあります。 これらのサービスの違いの詳細とこれらの違いによって提示された問題は以下で説明されます。 Virtual Dial上がっているサービスに使用されるメカニズムが、より伝統的なメカニズムと共存することを意図します。 ISPのPOPが同時にVirtualダイヤルアップクライアントと同様にISPクライアントにサービスを提供できることを意図します。
3.1 Security
3.1 セキュリティ
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.
Virtualダイヤルアップサービスのために、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からホームへのゲートウェイ認証フェーズにかかわります。
Valencia, et. al. Historic [Page 7] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [7ページ]歴史的なRFC2341コクチマスL2F1998年5月
3.2 Address Allocation
3.2 アドレス配分
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アドレスがServiceプロバイダーアドレスのプールからダイナミックに割り当てられるかもしれないと受け入れます。 このモデルは、しばしばリモート・ユーザーがそれらのホームネットワークのリソースにまず近づく手段を持っていることを意味します、ホームネットワークによって外部の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.
Virtualダイヤルアップサービスのために、ホームゲートウェイはホームファイアウォールの後ろに存在できます、内部であることの(そして、事実上、RFC1597アドレス、または非IPアドレスであることができます)アドレスを割り当てて。 L2Fが排他的にフレーム層でトンネルを堀るので、そのようなアドレス管理の実際の政策はVirtualダイヤルアップサービスを修正するために無関係です。 PPPのすべての目的かSLIPプロトコル取り扱いに関しては、ダイヤルインのユーザは、ホームゲートウェイで接続したように見えます。
3.3 Authentication
3.3 認証
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における1番目と、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は、Virtualダイヤルアップサービスが必要であると決心して、適切なホームゲートウェイにトンネル接続を開始するのにユーザ名を使用します。 一度、トンネルが確立されるのを新しい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番目のフェーズを追求できます。 この仕様の範囲の外にTCP/IP telnetセッションで運ばれたLCP認証、独占PPP拡張子、または原文の挑戦の追加サイクルを含むかもしれないのを除いて、これらの活動があります。
3.4 Accounting
3.4 会計
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.
それはしたがって、Accessゲートウェイとホームゲートウェイの両方がともに会計データを提供できて、パケット、八重奏、および接続始めを数えて、回を止めるかもしれないという要件です。
Valencia, et. al. Historic [Page 8] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [8ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
Virtualダイヤルアップがアクセス・サービスであるので、接続試み(特定の、そして、失敗した接続試みにおける)の会計は重要におもしろいです。 ホームゲートウェイは対応する伐採で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パケットをリモートシステムと交換する必要があるでしょう。
4.0 Protocol Definition
4.0 プロトコル定義
The protocol definition for Virtual dial-up services requires two areas of standardization:
Virtualダイヤルアップサービスのためのプロトコル定義は標準化の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とMIDsの接続管理。 MIDsでなければならないことのようにトンネルの中でトンネルを開始されて、終えなければなりません。 終了は、問題の診断を助けて、会計をサポートするために診断コードを含んでいます。
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パケットが運ばれる基板に関するほんのわずかな仮定をしなければなりません。
Valencia, et. al. Historic [Page 9] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [9ページ]歴史的なRFC2341コクチマスL2F1998年5月
+ Simple deployment. The protocol must not rely on additional
telecommunication support (for instance, unique called numbers,
or caller ID) to operate.
+ 簡単な展開。 プロトコルは、作動するために、追加電気通信サポート(例えば、ユニークな呼ばれた数、または発信者番号)に依存してはいけません。
4.1 Encapsulation within L2F
4.1 L2Fの中のカプセル化
4.1.1 Encapsulation of PPP within L2F
4.1.1 L2Fの中のpppのカプセル化
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
+ + 旗+透明データ(asyncのためのACCM、同時性のためのビット・スタッフィング)CRC
The following ARE still present:
以下はまだ存在しています:
+ Address and control flags (unless negotiated away by LCP) + Protocol value
+ アドレスとコントロールは+ (LCPによって譲歩されない場合)プロトコル価値に旗を揚げさせます。
4.1.2 Encapsulation of SLIP within L2F
4.1.2 L2Fの中のメモ用紙のカプセル化
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の中で要約する前に、外されます。
4.2 L2F Packet Format
4.2 L2Fパケット・フォーマット
4.2.1 Overall Packet Format
4.2.1 総合的なパケット・フォーマット
The entire encapsulated packet has the form:
全体のカプセル化されたパケットには、フォームがあります:
---------------------------------
| |
| L2F Header |
| |
---------------------------------
| |
| Payload packet (SLIP/PPP) |
| |
---------------------------------
| |
| L2F Checksum (optional) |
| |
---------------------------------
--------------------------------- | | | L2Fヘッダー| | | --------------------------------- | | | 有効搭載量パケット(SLIP/PPP)| | | --------------------------------- | | | L2Fチェックサム(任意の)| | | ---------------------------------
Valencia, et. al. Historic [Page 10] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [10ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.2.2 Packet Format
4.2.2 パケット・フォーマット
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| プロトコル|系列(選びます)|\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | IDを多重送信してください。| クライアントID| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F| 長さ| 相殺してください(選んでください)。| |ヘッダー+++++++++++++++++++++++++++++++++| | キー(選びます)| /+++++++++++++++++++++++++++++++++/+(ペイロード)| + ..... | + ..... | + ..... | + (ペイロード)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2Fチェックサム(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.3 Version field
4.2.3 バージョン分野
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に定義される無効のパケットとして扱われます。
4.2.4 Protocol field
4.2.4 プロトコル分野
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
L2Fの中でトンネルを堀られたL2F0x03L2F_SLIP SLIPの中でトンネルを堀られた値のType記述0x00L2F_ILLEGAL Illegal0x01L2F_PROTO L2F管理パケット0x02L2F_PPP PPP
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
Valencia, et. al. Historic [Page 11] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [11ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.2.5 Sequence Number
4.2.5 一連番号
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に設定されるなら、Sequence番号は存在しています。 このビットはすべてのL2F管理パケットのための1でなければなりません。 それは非L2F管理パケットのために1に設定されるかもしれません。 Sビットがセットした状態で非L2F管理パケットを受け取るなら、そのMID MUSTのために送られたすべての将来の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.
Sequence番号は0時に最初の配列されたL2Fパケットのために始まります。 一連番号の次の増分と共にそれぞれのその後のパケットを送ります。 一連番号はその結果、自由な実行しているカウンタが法256を表したということです。 異なったSequence数の状態がそれぞれの異なった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パケットの一連番号を記録します。 容認されたパケットが値を持っているように見えるなら、より最終は値を受けて、静かにパケットを捨てなければなりません。 さもなければ、パケットは、受け入れて最新の値の最終が受信されたので記録されたパケットの一連番号です。
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の後継者値の範囲にあるなら、容認された系列値は最後の容認されたより値であると考えられます。 例えば0〜15、および144〜255の一連番号がある当時のパケットは、最後の容認された一連番号が15であったならそれほど考えられないで、静かに捨てられるでしょう。 さもなければ、それを受け入れるでしょう。
4.2.6 Packet Multiplex ID
4.2.6 パケット多重ID
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.
Multiplex ID(「中間」の)はトンネルの中で特定の接続を特定します。 現在トンネルの中の未使用の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
値0があるMIDは特別です。 それは、トンネルの中のどんな接続とも異なるとしてトンネル自体の状態を伝えるのに使用されます。 L2F_プロトパケットだけに0のMIDを使用させるかもしれません。 もしあれば
Valencia, et. al. Historic [Page 12] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [12ページ]歴史的なRFC2341コクチマスL2F1998年5月
other type is sent on MID 0, the packet is illegal and MUST be processed as defined in 4.4.1.
他のタイプをMID0に送って、パケットを不法であり、中で定義されるとして処理しなければならない、4.4、.1
4.2.7 Client ID
4.2.7 クライアントID
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.
基本的な二地点間基板がそれほど直接するための効率的であるか信頼できるテクニックを欠いているとき、Client 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メッセージ(以下で、説明される)を送るとき、Assigned_CLID分野を通って同輩のCLIDを伝えなければなりません。 これはホームゲートウェイのL2F_CONF応答で予想されることである送付者の側のユニークな非ゼロ値であるに違いありません、CONFパケットが受けたすべての将来の非L2Fの_と同様に。
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.
すべてのその後のパケットのためのCLID分野価値が同輩に発信したので、最後の有効なL2F_CONFメッセージからの値が受けたCLIDは記録されていて使用されているに違いありません。
Packets with an unknown Client ID MUST be silently discarded.
静かに未知のClient 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.
トンネル設立の間に送られた初期のパケットにおいてCLID分野を0に設定しなければなりません。そこでは、L2F_CONFが全くまだ受け取られていません。
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値でタグ付けををされたすべてが唯一この同輩を特定するタグとして機能します。
4.2.8 Length
4.2.8 長さ
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.
長さはヘッダー、分野が提示するすべて、およびペイロードを含む全体のパケットの八重奏でサイズです。 1つが存在しているなら、長さはチェックサムの添加を反映しません。 容認されたパケットが示された長さより脆いなら、パケットは静かに捨てられるべきです。 静かにパケットの示された長さを超えた現在の追加バイトを無視しなければなりません。
4.2.9 Packet Checksum
4.2.9 パケットチェックサム
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ビットがヘッダー旗で存在しているなら、Checksumは存在しています。 PPP/HDLCによって使用されるようにそれは16ビットのCRCです。(明確にFCS-16[3])。 ペイロードデータの最後のバイトを通してL2F旗の最初のバイトから始まる全体のパケットの上に適用されます。 そして、すぐにペイロードデータの最後のバイトに続いて、チェックサムは2バイトとして加えられます。
Valencia, et. al. Historic [Page 13] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [13ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.2.10 Payload Offset
4.2.10 有効搭載量は相殺されました。
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ビットがヘッダー旗で設定されるなら、Offsetは存在しています。 この分野はペイロードデータが出発すると予想される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.
ペイロードを並べられた32ビットの境界でL2Fヘッダーに関して始動させるのが、より効率的である構造において、Fビットがセットと、オフセットであることはお勧めです。0では、使用されてください。
4.2.11 Packet Key
4.2.11 パケットキー
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.
KビットがL2Fヘッダーに設定されるなら、Key分野は存在しています。 Keyは最後にトンネル創造の間に同輩に与えられた認証応答に基づいています(トンネル創造の詳細は次のセクションに明らかにされます)。 抵抗するセッションの人生の間のキーがスプーフィングに基づいて攻撃されるとき、それは役立ちます。 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.
Key値は、同輩からの128ビットの認証応答、ネットワークバイトオーダーにおける4つの隣接している32ビットの単語としてそれを解釈するXOR'ingにこれらの単語を一緒に取って、Keyとして結果として起こる32ビットの値を使用することによって、発生します。
4.2.12 Packet priority
4.2.12 パケット優先権
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交通を送るのはお勧めです。
4.3 L2F Tunnel Establishment
4.3 L2Fトンネル設立
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サービスを提供する前に、終点はMID0について話し合います。 このコミュニケーションは、リモートエンドでL2Fの存在について確かめて、どんな必要な認証も可能にするのに使用されます。
Valencia, et. al. Historic [Page 14] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [14ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
L2F管理を示して、いつもそのような交渉のためのプロトコルは1です。 メッセージ自体がゼロがあとに続いたオプションを示すただ一つの八重奏の系列として構造化されるか、または以上はオプションのために必要に応じてフォーマットされた八重奏を促進します。
4.3.1 Normal Tunnel Negotiation Sequence
4.3.1 正常なトンネル交渉系列
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.
この例がKeyオプションを使用しますが、OffsetとChecksumオプションは使用しないことに注意してください。 八重奏の流れとしてコード化されるようにパケットの実際の長さを反映して、Length分野は存在しているでしょう。
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: 主要な=0L2F_CONFは、CLID=0、プロトがL2F、Seq=0、中間の=0と等しいと命名します: NAS_名前挑戦: Rndは_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パケットを送ります。
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という要求された名前を指定します、そして、aはGWが有効なトンネル終点としてそれ自体を認証する際に使用する乱数に挑戦します。 割り当てられた_CLIDは、いかなる他のホームゲートウェイへの現在いかなる他のトンネルへの外にも割り当てられていない値にもなるように発生します。
Valencia, et. al. Historic [Page 15] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [15ページ]歴史的なRFC2341コクチマスL2F1998年5月
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: 主要な=0L2F_CONFは、CLID=22、プロトがL2F、Seq=0、中間の=0と等しいと命名します: GW_名前挑戦: Rnd2は_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.
ホームゲートウェイは、前のパケットを処理して、応答を送ります。 プロトコルはずっと一連番号0をもってL2Fです(それぞれの側はトランスミッションのためにそれ自身の一連番号を維持します)。 トンネル設立を反映するために、MIDはずっと0歳です。 CLIDはCONFが受けたL2F_のAssigned_CLID分野を反映します。 Keyはトンネル設立のこの段階の間、ずっと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のものへの類似の方法で発生します。 この後、CLID分野が73を含んでいて、NASから受け取られたすべてのパケットにタグ付けをしなければなりません、そして、CLID分野が22を含んでいて、NASに送られたすべてのパケットにタグ付けをしなければなりません。
3. NAS->GW
Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
L2F_OPEN
Response: C(Rnd2)
3. C(Rnd2)L2Fの_の開いているGWプロト=L2F(Seq=1、中間の=0、CLID=73)が合わせるNAS->=応答: 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は現在共有秘密キーを反映するように用意ができているKeyと共に応じます。 Keyは乱数の細切れ肉料理が受けたCHAP-スタイルです。 各パケットは今後この計算された値を反映するでしょう。(それは、トンネルの人生のためのキーとして機能します)。 ホームゲートウェイとNASの両方がトンネルの人生にそのようなキーズを使用します。 Keyは共有秘密キーをコード化するのからのMD5ダイジェストの結果になることの32ビットの表現です。 完全なMD5ダイジェストはL2F_オープン応答、「応答」分野に含まれています。
4. GW->NAS
Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
L2F_OPEN
Response: C(Rnd)
4. C(Rnd)L2Fの_の開いているNASプロト=L2F(Seq=1、中間の=0、CLID=22)が合わせるGW->=応答: 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からキーの閉鎖を提供します、Key分野と「応答」分野の両方では、反射しています。 トンネルは、現在、クライアントが証明されるために利用可能です。
Valencia, et. al. Historic [Page 16] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [16ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.3.2 Normal Client Negotiation Sequence
4.3.2 正常なクライアント交渉系列
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におけるVirtualダイヤルアップクライアントの設立についてホームゲートウェイに説明します。 それは、トンネルが4.3で.1に述べられた方法で作成されたと仮定します。 この例のためのクライアントはCHAPのために構成されたPPPクライアントです。
Treatment of Checksum, Length, and Offset are as in 4.3.1.
コネ4.3としてChecksumの処理、Length、およびOffsetが.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. C(Rnd2)L2F_GWプロト=L2F(Seq=2、中間の=1、CLID=73)が合わせるNAS->=開放型: 名前のひびが切れてください: やつ名の挑戦: Rnd3応答: <対価領収、おそらく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が、それがホームゲートウェイによって接待されたVirtualダイヤルアップクライアントであったと信じているように導きます。 次の自由なMIDを割り当てて、CHAP挑戦/応答に関連している情報を含んでいる、通知を接続してください。
2. GW->NAS
Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
L2F_OPEN
2. C(Rnd)L2F_NASプロト=L2F(Seq=2、中間の=1、CLID=22)が合わせるGW->=戸外
The Home Gateway, by sending back the L2F_OPEN, accepts the client.
L2F_オープンを返送することによって、ホームゲートウェイはクライアントを受け入れます。
3. NAS->GW
Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
<Frame follows>
3. NAS、->GWプロトはPPP、Seq=0、MID=1、CLID=73と等しく、Key=C(Rnd2)<Frameは>に続きます。
4. GW->NAS
Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
<Frame follows>
4. GW、->NASプロトはPPP、Seq=0、MID=1、CLID=22と等しく、Key=C(Rnd)<Frameは>に続きます。
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ビットを見ます))。
Valencia, et. al. Historic [Page 17] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [17ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.4 L2F management message types
4.4 L2F管理メッセージタイプ
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パケットのプロト分野が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
十六進法値の略語記述-------- ------------ ----------- 0×00 同輩送付L2F_CONF0x03L2F_CONF_CHAL Random数の同輩のNAME Nameが、0×04L2F_CONF_CLID Assigned_CLIDと共に同輩が_0×02L2F_オープンAccept構成0x01L2F_オープンNAME Nameを使用するのに挑むクライアント0x02L2F_オープン_CHAL Challengeクライアントから受け取られた無効のInvalidメッセージ0×01L2F_CONF Request構成0x02L2F_CONF_はクライアント0×04L2F_ACK_LCP1 LCPから0×03L2F_オープン_RESP Challenge応答を受けました; ACK_LCP2 LCP CONFACKが_認証のクライアント0x06L2F_オープンTYPE Typeに送ったクライアント0×05L2F_から受け入れられたCONFACKはオープン_ID IDが同輩0×05L2F_ECHO_RESP Respondの厳密な0×02のL2F_CLOSE_STR ASCIIストリング記述0x04L2F_ECHO Verify存在のためのクライアント0×03L2F_CLOSE Request分離0x01L2F_CLOSE_WHY ReasonコードからL2F_ECHOまで認証0x08L2F_REQ_LCP0 First LCP CONFREQに関連づけた0×07L2F_を使用しました。
4.4.1 L2F message type: Invalid
4.4.1 L2Fメッセージタイプ: 病人
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_CLOSEを要求しなければなりません。 L2F_CLOSEを受け取り次第、トンネル自体は閉じられるかもしれません。 他のすべての受信されたメッセージを捨てなければなりません。 実現はトンネルの特性に適切な時間ぶりにトンネルを閉じるかもしれません。
Valencia, et. al. Historic [Page 18] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [18ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
無効のKeyがあるパケットが捨てられますが、分離が開始されないことに注意してください。 これはサービス不能攻撃を防ぎます。 まるで全体のメッセージタイプが無効であるかのようにメッセージの中の無効のオプションタイプを扱わなければなりません。
4.4.2 L2F_CONF
4.4.2 L2F_CONF
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サブオプションは存在していなければなりません。 送付者のASCII名として解釈されるバイトの示された数に従って非ゼロ・レングスを指定する八重奏があとに続いた八重奏値0x02が続いて、それはコード化されます。
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サブオプションは存在していなければなりません。 4バイトのAssigned_CLID価値があとに続いていて、それは八重奏0x04としてコード化されます。 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.
0として、初期のL2F_CONFパケットでは、NASからホームゲートウェイに送ります。そうでなければ、CLID野原にCONFメッセージが受けた最後のL2F_の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はホームゲートウェイのトンネル創造要求の認識を示します。 ホームゲートウェイは名前とそれ自身の挑戦をメッセージ本体に提供しなければなりません。
Valencia, et. al. Historic [Page 19] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [19ページ]歴史的なRFC2341コクチマスL2F1998年5月
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に続くすべてのパケットでは、Keyは容認された挑戦バイトのCHAP-スタイル細切れ肉料理に用意ができなければなりません。 割り当てられたCLID、秘密、および挑戦価値の低8ビットの連結の上にCHAP-スタイル細切れ肉料理をします。 セクション4.2.11で32ビットのキー値の世代について議論します。
4.4.3 L2F_OPEN, tunnel establishment
4.4.3 L2F_オープン、トンネル設立
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_オープンメッセージは、トンネルセットアップ閉鎖(0のMIDのための)を提供するか、または以前にL2F_CONFによって確立されたトンネルとL2F_オープンメッセージ(0と等しくないMID)の中でクライアント接続を証明するのに使用されます。 このセクションはトンネル設立について説明します。 セクション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_オープン_RESP、トンネル設立のためのL2F_オープンはサブオプション0×03だけを含まなければなりません。 八重奏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_オープンを不正確な_L2Fオープン_RESPと共に受けるなら、静かにパケットを捨てなければなりません。 そのような出来事がまた、ログイベントを発生させるのは、お勧めです。
4.4.4 L2F_OPEN, client establishment
4.4.4 L2F_オープン、クライアント設立
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_オープン(非ゼロ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_オープン_TYPEサブオプションは存在していなければなりません。 それは八重奏0x06としてコード化されます、NASがクライアントと共にクライアントを検出する際に交換した認証のタイプについて説明する識別であると主張された1バイトがあとに続いていて。 認証タイプで暗黙であることは、セッションの人生の間に運ばれるべきカプセル化です。 認証タイプは以下の通りです。
0x01 Textual username/password exchange for SLIP
0x02 PPP CHAP
0x03 PPP PAP
0x04 PPP no authentication
0x05 SLIP no authentication
0×01の原文のユーザ名/パスワードがSLIP0x02PPP CHAP0x03PPP PAP0x04PPPと認証0×05SLIPノー、を全く交換しない、認証
Valencia, et. al. Historic [Page 20] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [20ページ]歴史的なRFC2341コクチマスL2F1998年5月
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.
名前のバイトの示された数に従って名前の長さを指定する八重奏があとに続いた八重奏0x01が続いて、L2F_オープン_NAMEサブオプションはコード化されます。 この分野は0×04(なにも)以外のどんな認証タイプのためにも存在していなければなりません。 それはクライアントの認証応答で指定された名前を含まなければなりません。
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.
挑戦自体で送られた挑戦の長さを指定する八重奏があとに続いた八重奏0x02が続いて、L2F_オープン_CHALサブオプションはコード化されます。 この分野は、単に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".
挑戦へのクライアントの応答で受けられた応答の長さを指定する八重奏があとに続いた八重奏0x03が続いて、L2F_オープン_RESPサブオプションはコード化されます。 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サブオプションは八重奏0×04と0x05としてそれぞれコード化されます、クライアントに最後に受け取られたLCP CONFACKの長さを指定するか、または発信するネットワークバイトオーダーにおける2つの八重奏がどちらの場合でもあとに続いていて。 これらの八重奏に続くのは、CONFACKパケットの正確なコピーです。 L2F_ACK_LCP1はCONFACKがクライアントから受けた閉鎖のコピーを指定します、そして、L2F_ACK_LCP2はCONFACKが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の長さが初めはクライアントから受けたネットワークバイトオーダー指定における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_オープン_IDサブオプションは八重奏0x06としてコード化されます。 このサブオプションは単にCHAPのために存在しています。 ただ一つの八重奏はCHAP挑戦の間にクライアントに送られたCHAP Identifier値を含んでいます。
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トンネルの透明を最大にするために、できれば、余分な交渉と認証が避けられるのは、お勧めです。
Valencia, et. al. Historic [Page 21] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [21ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.4.5 L2F_CLOSE
4.4.5 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を送るかもしれません。 0のMIDと共に送ると、それは全体のトンネルとトンネルの中のすべてのクライアントを終える願望を示します。 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:
バイト0x01が断線の理由のマスクを少し指定するネットワークバイトオーダーで4バイト続いて、L2F_CLOSE_WHYサブオプションはコード化されます。 ビットは以下としてコード化されます。
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
0×00000001 リソース0x00000004Administrative介入0x00000008User割当ての認証の失敗した0×00000002Outは0×00000010プロトコル誤り0×00000020Unknownユーザ0×00000040Incorrectパスワード0×00000080PPP構成両立しない0x00000100WrongマルチリンクPPPの目的地を超えていました。
Bits in the mask 0xFF000000 are reserved for per-vendor interpretation.
マスク0xFF000000のビットは1業者あたりの解釈のために予約されます。
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つによって説明された状態を検出しても、実現は、ステータスビットを提供しないのを選ぶことができます。 例えば、実現は、セキュリティ問題に0×00000020支払われるべきものを使用しないのを選ぶかもしれません、ユーザ名前スペースを調べるのにそれを使用できるとき。
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.
描写的であるASCIIテキストが断線と交際したので解釈されるバイトの示された数に従ってネットワークバイトオーダーにおける2バイトの長さがあとに続いたバイト0x02が続いて、L2F_CLOSE_STRサブオプションはコード化されます。 このストリングを無視されたかもしれませんが、L2F_CLOSEに関連している詳細であるか補助の情報を提供するためにログに記録できました。
4.4.6 L2F_ECHO
4.4.6 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_ECHOメッセージの伝達は任意です。 実現がL2F_ECHOメッセージを送るなら、それはそれぞれの秒にそのような要求の1つ以上を伝えてはいけません。 長さはペイロードサイズが64バイト以下でなければなりません。 実現が、同輩が終わったと仮定する前に応答なしで少なくとも5つのL2F_ECHOメッセージを送るのはお勧めです。
Valencia, et. al. Historic [Page 22] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [22ページ]歴史的なRFC2341コクチマスL2F1998年5月
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 MUST、0になってください。 応答でL2F_ECHO_RESP(以下では、記録される)を返送しなければなりません。
4.4.7 L2F_ECHO_RESP
4.4.7 L2F_エコー_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に変化したのを除いて。 応答でもしあれば0×04八重奏に続く有効搭載量データを保存しなければなりません。
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にこの応答を関連づけるのに使用されるかもしれませんか、またはパケットは静かに捨てられるかもしれません。
4.5 L2F Message Delivery
4.5 L2Fメッセージ配送
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コントロールメッセージにすぎません。 この過程はこのセクションで説明されます。
4.5.1 Sequenced delivery
4.5.1 配列された配送
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コントロールメッセージ(すなわち、0×01人のプロトコルタイプがあるそれらのL2Fパケット)が一連番号で送られます。 1L2Fあたり一連番号は各パケットが伝えられた後に増加しているカウンタ(法256)を走らせる無料の1つのトンネルです。 コピーされたか故障しているパケットを検出して、そのようなパケットを捨てることを犠牲者を許可するのにおいてそれは使用されています。 セクション4.2 .5 詳細に過程について説明します。
4.5.2 Flow control
4.5.2 フロー制御
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コントロールメッセージは交換された型にはまったやり方であると予想されます。 したがって、トンネルセットアップが完全になるまで、1クライアントあたりの活動は起こることができません。 どちらも、前のクライアントにとって、L2F交換処理が完全になるまで、1人のクライアントにサービスを提供できません。 したがって、かつてなら、そんなにめったにフロー制御動作は必要であるべきでないと予想されます。 L2Fコントロールメッセージの入力キューが実現のための好ましくないレベルに達するなら、実現は静かに状況を安定させる待ち行列におけるすべてのメッセージを捨てるかもしれません。
Valencia, et. al. Historic [Page 23] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [23ページ]歴史的なRFC2341コクチマスL2F1998年5月
4.5.3 Tunnel State table
4.5.3 トンネル州テーブル
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)
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- 4Cleanが上げるStart0 Send CONF Start1 Start1 CONF SendオープンStart2 Start1タイムアウト1-3Send CONF Start1 Start1タイムアウトはStart2オープン(最初のクライアントを開始します)Open1 Start2タイムアウト1-3SendオープンStart2 Start2タイムアウト4Cleanにトンネル(する)Open1オープンにトンネルを堀ります(します); トンネル(する)Close2 CLOSE Cleanに上がっている4Cleanが(します)Close2タイムアウト1-3Send CLOSE Close2 Close2タイムアウト4Cleanにトンネルを堀るどんなMIDsの開いているSend CLOSE Close2 Close1 CLOSE Send CLOSE Close1 Close1タイムアウトもオープンOpen1 Open1 CLOSE Send CLOSE Close1 Open1に送らないでください、トンネル(します)
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)
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- トンネル(する)Open1オープンSendオープンOpen1 Open1オープン(MID>0)(以下の最初のクライアント)Open2 Open1 CLOSE Send CLOSE Close1 Open1タイムアウト4Cleanに上がっている4Cleanがトンネルを堀るStart0 CONF Send CONF Start1 Start1 CONF Send CONF Start1 Start1オープンSendオープンOpen1 Start1タイムアウト(します)
Valencia, et. al. Historic [Page 24] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [24ページ]歴史的なRFC2341コクチマスL2F1998年5月
Open2 OPEN (MID > 0) (below) Open2
Open2 CLOSE Send CLOSE Close1
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
トンネルへのOpen2オープン(MID>0)(below) Open2Open2 CLOSE Send CLOSE Close1 Close1 CLOSE Send CLOSE Close1 Close1タイムアウト4Clean(します)
4.5.4 Client State table
4.5.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)
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- Start0 SendオープンStart1 Start1オープン(推進を可能にする)Open1 Start1 CLOSE CleanがMID(行われたMID)Close2タイムアウト1-3Send CLOSE Close2 Close2タイムアウト4CleanへのMID(行われたMID)Close2 CLOSE Cleanへの4Cleanが上げるSend CLOSE Close2 Close1 CLOSE Send CLOSE Close1 Close1タイムアウトが行われたMID(行われたMID)Start1クライアントのされたSend CLOSE Close2 Open1オープン(変化がない)Open1 Open1 CLOSE Send CLOSE Close1 Open1クライアントにMID(行われたMID)Start1タイムアウト1-3SendオープンStart1 Start1タイムアウト4Cleanを上げる、MID(行われたMID)
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)
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- Start0オープンSendオープンOpen1 Start0オープン(失敗する)がMID(行われたMID)Close3オープンSend CLOSE Close3 Close3タイムアウト4CleanへのMID(行われたMID)Close2タイムアウト1-3Send CLOSE Close2 Close2タイムアウト4CleanへのMID(行われたMID)Close2 CLOSE Cleanへの4Cleanが上げるクライアントのされたSend CLOSE Close2 Close1 CLOSE Send CLOSE Close1 Close1タイムアウトをCLOSE Close3 Open1オープンSendオープンOpen1 Open1 CLOSE Send CLOSE Close1 Open1に送る、MID(行われたMID)
Valencia, et. al. Historic [Page 25] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [25ページ]歴史的なRFC2341コクチマスL2F1998年5月
5. Protocol Considerations
5. プロトコル問題
Several aspects of operation over L2F, while outside the realm of the protocol description itself, serve to clarify the operation of L2F.
プロトコル記述自体の分野の外にある間、L2Fの上の操作のいくつかの局面が、L2Fの操作をはっきりさせるのに役立ちます。
5.1 PPP Features
5.1 ppp機能
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フレームです。
5.2 Termination
5.2 終了
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は、閉鎖の理由について説明するために含まれるかもしれません。
5.3 Extended Authentication
5.3 拡張認証
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はプロトコル自体の中で認証を提供しないで、その結果、始動される前にユーザ名とパスワードの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がホームゲートウェイ(任意の交換は起こることができる)にユーザの見かけのアイデンティティを検出して、トンネル接続を確立できるように、プロトコルを構造化しなければなりません。
Valencia, et. al. Historic [Page 26] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [26ページ]歴史的なRFC2341コクチマスL2F1998年5月
5.4 MNP4 and Apple Remote Access Protocol
5.4 MNP4とアップルのリモートアクセス・プロトコル
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プロトコルと互換性があるように見えます。 単にこの実験的なRFCにはそのような操作の対応する実現がないので、L2Fの下の操作は説明されていません。
5.5 Operation of IP and UDP
5.5 IPとUDPの操作
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]を使用します。 UDPデータグラムの中にペイロードとL2Fヘッダーを含む全体のL2Fパケットを送ります。 逆多重化がCLID値を使用することで達成されている状態で、ソースと仕向港は同じです(1701)。 与えられた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はこれを最適化するためのどんな特別な努力もしません。 LCPはNAS実現で、特定のMRUを交渉するかもしれません。(MRUはL2Fパケットが旅行しそうである経路のMTUsが一貫した値を持っているNAS環境のために最適化できました)。
6.0 Acknowledgments
6.0 承認
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]によって奮い立たせられたパケット・フォーマットを使用します。 相談のためのフレッド・ベイカー、セキュリティ局面に関して相談するためのデーヴCarrelと、そして、哲学的な指導のためのポールTrainaをありがとうございます。
7.0 References
7.0の参照箇所
[1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988.
[1] J.、Romkeyに、「IPデータグラムの送信に、シリーズの上で標準的でないAは立ち並んでいます」。 「メモ用紙」、RFC1055、1988年6月。
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[2] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
July 1994.
[3] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、7月1994日
Valencia, et. al. Historic [Page 27] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [27ページ]歴史的なRFC2341コクチマスL2F1998年5月
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[4] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
[5] ハンクスとS.と李とT.とファリナッチ、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC1701、1994年10月。
8.0 Security Considerations
8.0 セキュリティ問題
Security issues are discussed in Section 3.1.
セクション3.1で安全保障問題について議論します。
9.0 Authors' Addresses
9.0 作者のアドレス
Tim Kolar Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
ティムコラールシスコシステムズ170の西タスマン・ドライブサンノゼカリフォルニア95134-1706
EMail: tkolar@cisco.com
メール: tkolar@cisco.com
Morgan Littlewood Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
モーガンリトルウッドシスコシステムズ170の西タスマン・ドライブサンノゼカリフォルニア95134-1706
EMail: littlewo@cisco.com
メール: littlewo@cisco.com
Andy Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
アンディバレンシアシスコシステムズ170の西タスマン・ドライブサンノゼカリフォルニア95134-1706
EMail: valencia@cisco.com
メール: valencia@cisco.com
Valencia, et. al. Historic [Page 28] RFC 2341 Cisco L2F May 1998
etバレンシア、アル。 [28ページ]歴史的なRFC2341コクチマスL2F1998年5月
9.0 Full Copyright Statement
9.0 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Valencia, et. al. Historic [Page 29]
etバレンシア、アル。 歴史的[29ページ]
一覧
スポンサーリンク
