RFC1598 日本語訳
1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT=13835 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Simpson Request for Comments: 1598 Daydreamer Category: Standards Track March 1994
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1598年の空想家カテゴリ: 1994年の標準化過程行進
PPP in X.25
X.25のppp
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 このドキュメントはX.25のパケットであるとカプセル化された縁どりPPPの使用について説明します。
This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@merit.edu メーリングリストにコメントを提出するべきです。
Applicability
適用性
This specification is intended for those implementations which desire to use facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between peers, and are not designed for multi-point or multi-access environments.
この仕様はPPPのために定義される施設を使用するそれの願望がLink ControlプロトコルなどのようにControlプロトコル、認証をNetwork層にするそれらの実装と圧縮のために意図します。 これらの能力は、同輩の間の二地点間関係を必要として、マルチポイントかマルチアクセス環境のために設計されていません。
Simpson [Page i] RFC 1598 PPP in X.25 March 1994
X.25 March 1994のシンプソン[ページi]RFC1598PPP
Table of Contents
目次
1. Introduction .......................................... 1
1. 序論… 1
2. Physical Layer Requirements ........................... 2
2. 物理的な層の要件… 2
3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 3
3.2 Modification of the Basic Frame ................. 3
3. データ・リンク層… 2 3.1 形式を縁どってください… 3 3.2 基本枠の変更… 3
4. Call Setup ............................................ 4
4. セットアップに電話をしてください… 4
5. Configuration Details ................................. 5
5. 構成の詳細… 5
SECURITY CONSIDERATIONS ...................................... 6
セキュリティ問題… 6
REFERENCES ................................................... 6
参照… 6
ACKNOWLEDGEMENTS ............................................. 6
承認… 6
CHAIR'S ADDRESS .............................................. 7
議長のアドレス… 7
AUTHOR'S ADDRESS ............................................. 7
作者のアドレス… 7
1. Introduction
1. 序論
CCITT recommendation X.25 [2] describes a network layer protocol providing error-free, sequenced, flow controlled, virtual circuits. X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 and 6256.
CCITT推薦X.25[2]は制御されて、仮想の回路をエラーのなくて、配列された流れに提供するネットワーク層プロトコルについて説明します。 X.25はデータ・リンク層、ISO3309、4335と6256を使用するX.25 LAPBを含んでいます。
PPP also uses ISO 3309 HDLC as a basis for its framing [3].
また、PPPは縁ど[3]りの基礎としてISO3309HDLCを使用します。
When X.25 is configured as a point-to-point circuit, PPP can use X.25 as a framing mechanism, ignoring its other features. This is equivalent to the technique used to carry SNAP headers over X.25 [4].
X.25が二地点間回路として構成されるとき、他の特徴を無視して、PPPは縁どりメカニズムとしてX.25を使用できます。 これはX.25[4]の上でSNAPヘッダーを運ぶのに使用されるテクニックに同等です。
At one time, it had been hoped that PPP HDLC frames and X.25 frames would co-exist on the same links. Equipment could gradually be converted to PPP. Subsequently, it has been learned that some switches actually remove the X.25 header, transport packets to another switch using a different protocol such as Frame Relay, and reconstruct the X.25 header at the final hop. Co-existance and gradual migration are precluded.
ひところ、PPP HDLCフレームとX.25フレームが同じリンクの上に共存することが望まれていました。 徐々に設備をPPPに変換できました。 次に、いくつかのスイッチが実際にX.25ヘッダーを取り除いて、Frame Relayなどの異なったプロトコルを使用することで別のスイッチにパケットを輸送して、最終的なホップでX.25ヘッダーを再建すると学習されました。 共同existanceとゆるやかな移行は排除されます。
Simpson [Page 1]
X.25 March 1994のシンプソン[1ページ]RFC1598ppp
2. Physical Layer Requirements
2. 物理的な層の要件
PPP treats X.25 framing as a bit synchronous link. The link MUST be full-duplex, but MAY be either dedicated (permanent) or switched.
PPPは少し同期のリンクとしてX.25縁どりを扱います。 リンクは、全二重でなければなりませんが、捧げられるか(永久的な)、または切り換えられるかもしれません。
Interface Format
インタフェース形式
PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted.
PPPは物理的な層に八重奏インタフェースを提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。
Transmission Rate
通信速度
PPP does not impose any restrictions regarding transmission rate,
other than that of the particular X.25 interface.
PPPは特定のX.25インタフェースのもの以外の通信速度に関する少しの制限も課しません。
Control Signals
制御信号
Implementation of X.25 requires the provision of control signals,
which indicate when the link has become connected or disconnected.
These in turn provide the Up and Down events to the LCP state
machine.
X.25の実装は制御信号の設備を必要とします。(信号はリンクがいつ接続されるようになるか、または切断したかを示します)。 これらは順番にUpとDownイベントをLCP州のマシンに供給します。
Because PPP does not normally require the use of control signals,
the failure of such signals MUST NOT affect correct operation of
PPP. Implications are discussed in [2].
PPPが通常制御信号の使用を必要としないので、そのような信号の失敗はPPPの正しい操作に影響してはいけません。 [2]で含意について議論します。
Encoding
コード化
The definition of various encodings is the responsibility of the
DTE/DCE equipment in use, and is outside the scope of this
specification.
様々なencodingsの定義は、使用中のDTE/DCE設備の責任であり、この仕様の範囲の外にあります。
While PPP will operate without regard to the underlying
representation of the bit stream, X.25 requires NRZ encoding.
PPPは関係なしでビットストリームの基底表示に作動するでしょうが、X.25はNRZコード化を必要とします。
3. The Data Link Layer
3. データ・リンク層
This specification uses the principles, terminology, and frame structure described in "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [4].
この仕様は「Multiprotocolはパケット形態によるX.25とISDNで内部連絡する」[4]で説明された原則、用語、および枠組構造を使用します。
The purpose of this specification is not to document what is already standardized in [4]. Instead, this document attempts to give a concise summary and point out specific options and features used by PPP.
この仕様の目的は[4]で既に標準化されることを記録しないことです。 代わりに、このドキュメントは、簡潔な概要をして、特定のオプションとPPPによって使用された特徴を指摘するのを試みます。
Simpson [Page 2]
X.25 March 1994のシンプソン[2ページ]RFC1598ppp
3.1. Frame Format
3.1. フレーム形式
Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a basis for framing, the X.25 header is easily substituted for the smaller HDLC header. The fields are transmitted from left to right.
「HDLC縁どりにおけるppp」[3]とX.25の両方が縁どりの基礎としてISO3309を使用するので、X.25ヘッダーは容易により小さいHDLCヘッダーに置換されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p(r) |M|p(s) |0| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+ | 旗(0x7e)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス| コントロール|D|Q| SVC#(こんにちは)| SVC#(見よ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |p(r)|M|p(s)|0| pppプロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1].
以下のPPPプロトコル分野、情報、およびPadding分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。
3.2. Modification of the Basic Frame
3.2. 基本枠の変更
The Link Control Protocol can negotiate modifications to the basic frame structure. However, modified frames will always be clearly distinguishable from standard frames.
Link Controlプロトコルは基本枠構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。
Address-and-Control-Field-Compression
アドレスとコントロール分野圧縮
Because the Address and Control field values are not constant, and
are modified as the frame is transported by the network switching
fabric, Address-and-Control-Field-Compression MUST NOT be
negotiated.
AddressとControl分野値が一定でなく、フレームがネットワーク切り換え骨組みによって輸送されるので変更されて、Addressとコントロール分野圧縮を交渉してはいけないということであるので。
Protocol-Field-Compression
プロトコル分野圧縮
Note that unlike the HDLC framing, the X.25 framing does not align
the Information field on a 32-bit boundary. Alignment to a 16-bit
boundary occurs when the Protocol field is compressed to a single
octet. When this improves throughput, Protocol-Field-Compression
SHOULD be negotiated.
HDLC縁どりと異なって、X.25縁どりが32ビットの境界の情報分野を並べないことに注意してください。 プロトコル分野がただ一つの八重奏に圧縮されるとき、16ビットの境界への整列は起こります。 プロトコル分野圧縮SHOULD、これはスループットを改良します。いつ、交渉されるか。
Simpson [Page 3]
X.25 March 1994のシンプソン[3ページ]RFC1598ppp
4. Call Setup
4. セットアップに電話をしてください。
When the link is configured as a Permanent Virtual Circuit (PVC), support for Switched Virtual Circuit (SVC) call setup and clearing is not required. Calls are Established and Terminated using PPP LCP packets.
リンクがPermanent Virtual Circuit(PVC)として構成されるとき、Switched Virtual Circuit(SVC)呼び出しセットアップのサポートと開拓地は必要ではありません。 呼び出しは、PPP LCPパケットを使用するEstablishedとTerminatedです。
When the link is configured as a Switched Virtual Circuit (SVC), the first octet in the Call User Data (CUD) Field (the first data octet in the Call Request packet) is used for protocol demultiplexing, in accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC TR 9577 [5]. This field contains a one octet Network Layer Protocol Identifier (NLPID), which identifies the encapsulation in use over the X.25 virtual circuit. The CUD field MAY contain more than one octet of information.
リンクがSwitched Virtual Circuit(SVC)として構成されるとき、Call User Data(CUD)分野(Call Requestパケットにおける最初のデータ八重奏)における最初の八重奏はプロトコル逆多重化に使用されます、ISO/IEC TR9577[5]のSubsequentプロトコルIdentifier(SPI)によると。 この分野は1つの八重奏のNetwork LayerプロトコルIdentifier(NLPID)を含んでいます。(IdentifierはX.25の仮想の回路の上に使用中のカプセル化を特定します)。 CUD分野は情報の1つ以上の八重奏を含むかもしれません。
The PPP encapsulation MUST be indicated by the PPP NLPID value (CF hex). Any subsequent octet in this CUD is extraneous and MUST be ignored.
PPP NLPID値(CF十六進法)でPPPカプセル化を示さなければなりません。 このCUDのどんなその後の八重奏も異質であり、無視しなければなりません。
Multipoint networks (or multicast groups) MUST refuse calls which indicate the PPP NLPID in the CUD.
多点ネットワーク(または、マルチキャストグループ)はCUDでPPP NLPIDを示す呼び出しを拒否しなければなりません。
The accidental connection of a link to feed a multipoint network (or multicast group) SHOULD result in a misconfiguration indication. This can be detected by multiple responses to the LCP Configure- Request with the same Identifier, coming from different framing addresses. Some implementations might be physically unable to either log or report such information.
misconfiguration指示における多点ネットワーク(または、マルチキャストグループ)SHOULD結果を食べさせるリンクの偶然の接続。 同じIdentifierとのLCP Configure要求への複数の応答でこれを検出できます、異なった縁どりアドレスから来て。 いくつかの実装は、そのような情報を登録するか、または物理的に報告できないかもしれません。
Conformance with this specification requires that the PPP NLPID (CF) be supported. In addition, conformance with [4] requires that the IP NLPID (CC) be supported, and does not require that other NLPID values be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS (82).
この仕様がある順応は、PPP NLPID(CF)がサポートされるのを必要とします。 さらに、[4]がある順応は、IP NLPID(CC)がサポートされるのが必要であり、他のNLPID値がサポートされるのを必要としません、Zero(00)などのように、SNAP(80)、CLNP(81)、ES存在、(82)。
When IP address negotiation and/or VJ header compression are desired, the PPP call setup SHOULD be attempted first. If the PPP call setup fails, the normal IP call setup MUST be used.
IPアドレス交渉、そして/または、VJヘッダー圧縮が望まれているとき、最初に試みられて、PPPは、セットアップをSHOULDと呼びます。 PPP呼び出しセットアップが失敗するなら、通常のIP呼び出しセットアップを使用しなければなりません。
The PPP NLPID value SHOULD NOT be used to demultiplex circuits which use the Zero NLPID in call setup, as described in [4]. When such a circuit exists concurrently with PPP encapsulated circuits, only network layer traffic which has not been negotiated by the associated NCP is sent over the Zero NLPID circuit.
PPP NLPIDはSHOULD NOTを評価します。呼び出しセットアップでZero NLPIDを使用する「反-マルチプレックス」回路に使用されてください、[4]で説明されるように。 PPPが回路であるとカプセル化されている状態でそのような回路が同時に存在するとき、関連NCPによって交渉されていないネットワーク層トラフィックだけをZero NLPID回路の上に送ります。
Rationale:
原理:
Using call setup to determine if PPP is supported should be
PPPがサポートされるかどうか決定するのに呼び出しセットアップを使用するのは、そうであるべきです。
Simpson [Page 4]
X.25 March 1994のシンプソン[4ページ]RFC1598ppp
inexpensive, when users aren't charged for failed calls.
安価であることで、ユーザがいつ課金されないかが呼び出しに失敗しました。
Using the Zero NLPID call together with PPP could be expensive,
when users are charged per packet or for connect time, due to the
probing of PPP configuration packets at each call.
PPPと共にZero NLPID呼び出しを使用するのは高価であるかもしれません、ユーザがパケットか接続時間の間請求されるとき、各呼び出しにおけるPPP構成パケットの調べのため。
PPP configuration provides a direct indication of the availability
of service, and on that basis is preferred over the Zero NLPID
technique, which can result in "black-holes".
PPP構成は、サービスの有用性のダイレクトしるしを供給して、Zero NLPIDのテクニックよりそのような方式で好まれます。(それは、「ブラックホール」をもたらすことができます)。
5. Configuration Details
5. 構成の詳細
The following Configuration Options are recommended:
以下のConfiguration Optionsはお勧めです:
Magic Number
Protocol Field Compression
マジックナンバープロトコル分野圧縮
The standard LCP configuration defaults apply to X.25 links, except MRU.
MRUを除いて、標準のLCP構成デフォルトはX.25リンクに適用されます。
To ensure interoperability with existing X.25 implementations, the initial Maximum-Receive-Unit (MRU) is 1600 octets [4]. This only affects the minimum required buffer space available for receiving packets, not the size of packets sent.
既存のX.25実装で相互運用性を確実にするために、初期のMaximumがユニットを受けている(MRU)は1600の八重奏[4]です。 これはパケットのサイズではなく、パケットを受けるのに利用可能なスペースが送った最小の必要なバッファに影響するだけです。
The typical network feeding the link is likely to have a MRU of either 1500, or 2048 or greater. To avoid fragmentation, the Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed 1500, unless a peer MRU of 2048 or greater is specifically negotiated.
リンクを食べさせる典型的なネットワークは1500か2048年のどちらか以上のMRUを持っていそうです。 断片化を避けるために、ネットワーク層SHOULD NOTのMaximumトランスミッションユニット(MTU)は1500を超えています、2048年以上の同輩MRUが明確に交渉されない場合。
The X.25 packet size is not directly related to the MRU. Instead,
Protocol Data Units (PDUs) are sent as X.25 "complete packet
sequences". That is, PDUs begin on X.25 data packet boundaries and
the M bit ("more data") is used to fragment PDUs that are larger than
one X.25 data packet in length.
X.25パケットサイズは直接MRUに関連しません。 代わりに、X.25が「パケット系列を完了する」とき、プロトコルData Units(PDUs)を送ります。 すなわち、PDUsはX.25データ・パケット境界で始まります、そして、噛み付いている(「より多くのデータ」)が使用されているMは長さで1つのX.25データ・パケットより大きいPDUsを断片化します。
Simpson [Page 5]
X.25 March 1994のシンプソン[5ページ]RFC1598ppp
Security Considerations
セキュリティ問題
Implementations MUST NOT consider PPP authentication on call setup for one circuit between two systems to apply to concurrent call setup for other circuits between those same two systems. This results in possible security lapses due to over-reliance on the integrity and security of switching systems and administrations. An insertion attack might be undetected. An attacker which is able to spoof the same calling identity might be able to avoid link authentication.
実装は、2台のシステムの間の1個の回路がそれらの同じ2台のシステムの間の他の回路のための同時発生の呼び出しセットアップに適用する呼び出しセットアップのときにPPPが認証であると考えてはいけません。これは甘えのため交換システムと政権の保全とセキュリティで可能なセキュリティ過失をもたらします。 挿入攻撃は非検出されるかもしれません。 アイデンティティと呼びながら同じようにだますことができる攻撃者はリンク認証を避けることができるかもしれません。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1548, December 1993.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、RFC1548、1993年12月。
[2] CCITT Recommendation X.25, "Interface Between Data Terminal
Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
for Terminals Operating in the Packet Mode on Public Data
Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
[2]CCITT推薦X.25、「データ端末装置(DTE)とデータ回線終端装置(DCE)との端末へのパケット形態で公共のデータ網を作動させるインタフェース」、Vol.VIII、分冊VIII.2、Rec。 X.25。
[3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, December
1993.
[3] シンプソン、W.、エディタ、「HDLC縁どりにおけるppp」、RFC1549、1993年12月。
[4] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
August 1992.
[4] Malis、A.、ロビンソン、D.、およびR.ウルマン、「Multiprotocolはパケット形態によるX.25とISDNで内部連絡します」、RFC1356、1992年8月。
[5] ISO/IEC TR 9577, "Information technology - Telecommunications
and Information exchange between systems - Protocol
Identification in the network layer", 1990 (E) 1990-10-15.
[5] ISO/IEC TR9577、「情報技術(システムの間のテレコミュニケーションと情報交換)はネットワーク層でIdentificationについて議定書の中で述べます」、1990(E)1990年10月15日。
Acknowledgments
承認
This design was inspired by the paper "Parameter Negotiation for the Multiprotocol Interconnect", Keith Sklower and Clifford Frost, University of California, Berkeley, 1992, unpublished.
このデザインは紙の「Multiprotocol内部連絡のためのパラメタ交渉」、キースSklower、およびクリフォード・フロストによって奮い立たせられました、カリフォルニア大学バークレイ校1992、未発表です。
Simpson [Page 6]
X.25 March 1994のシンプソン[6ページ]RFC1598ppp
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollay Driveサンタバーバラ、カリフォルニア 93117
EMail: fbaker@acc.com
メール: fbaker@acc.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
メール: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com
Simpson [Page 7]
シンプソン[7ページ]
一覧
スポンサーリンク
