RFC1570 日本語訳
1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format: TXT=35719 bytes) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson, Editor Request for Comments: 1570 Daydreamer Updates: 1548 January 1994 Category: Standards Track
ワーキンググループのW.シンプソン、コメントを求めるエディタ要求をネットワークでつないでください: 1570の空想家アップデート: 1548 1994年1月のカテゴリ: 標準化過程
PPP LCP Extensions
ppp LCP拡張子
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. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、データリンク接続を設立して、構成して、テストするために、広げることができるLink Controlプロトコル(LCP)を定義します。 このドキュメントは過去数年間にわたって示されているいくつかの追加LCPの特徴を定義します。
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@ucdavis.edu mailing list.
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@ucdavis.edu メーリングリストにコメントを提出するべきです。
Table of Contents
目次
1. Additional LCP Packets ................................ 1
1.1 Identification .................................. 1
1.2 Time-Remaining .................................. 3
2. Additional LCP Configuration Options .................. 6
2.1 FCS-Alternatives ................................ 6
2.1.1 LCP considerations .............................. 7
2.1.2 Null FCS ........................................ 8
2.2 Self-Describing-Padding ......................... 9
2.3 Callback ........................................ 11
2.4 Compound-Frames ................................. 12
2.4.1 LCP considerations .............................. 14
APPENDICES ................................................... 15
A. Fast Frame Check Sequence (FCS) Implementation ........ 15
A.1 32-bit FCS Computation Method ................... 15
SECURITY CONSIDERATIONS ...................................... 17
REFERENCES ................................................... 17
ACKNOWLEDGEMENTS ............................................. 18
CHAIR'S ADDRESS .............................................. 18
EDITOR'S ADDRESS ............................................. 18
1. 追加LCPパケット… 1 1.1識別… 1 1.2 時間が残っています… 3 2. 追加LCP設定オプション… 6 2.1のFCS-選択肢… 6 2.1 .1 LCP問題… 7 2.1 .2 ヌルFCS… 8 そっと歩くと説明する2.2自己… 9 2.3コールバック… 11 2.4 合成フレーム… 12 2.4 .1 LCP問題… 14個の付録… 15A.の速いフレームチェックシーケンス(FCS)実装… 15 A.1の32ビットのFCS計算メソッド… 15 セキュリティ問題… 17の参照箇所… 17の承認… 18 議長のアドレス… 18エディタのアドレス… 18
Simpson [Page i] RFC 1570 PPP LCP extensions January 1994
シンプソン[ページi]RFC1570PPP LCP拡大1994年1月
1. Additional LCP Packets
1. 追加LCPパケット
The Packet format and basic facilities are already defined for LCP [1].
Packet形式と基本施設はLCP[1]のために既に定義されます。
Up-to-date values of the LCP Code field are specified in the most recent "Assigned Numbers" RFC [2]. This specification concerns the following values:
LCP Code分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 この仕様は以下の値に関係があります:
12 Identification
13 Time-Remaining
12 識別13時間残り
1.1. Identification
1.1. 識別
Description
記述
This Code provides a method for an implementation to identify
itself to its peer. This Code might be used for many diverse
purposes, such as link troubleshooting, license enforcement, etc.
このCodeは実装が同輩にそれ自体を特定するメソッドを提供します。 このCodeはリンクトラブルシューティング、ライセンス実施などのさまざまの多くの目的に使用されるかもしれません。
Identification is a Link Maintenance packet. Identification
packets MAY be sent at any time, including before LCP has reached
the Opened state.
識別はLink Maintenanceパケットです。 何時でも、LCPがOpened状態に達する前の包含で識別パケットを送るかもしれません。
The sender transmits a LCP packet with the Code field set to 12
(Identification), the Identifier field set, the local Magic-Number
(if any) inserted, and the Message field filled with any desired
data, but not exceeding the default MRU minus eight.
送付者はデフォルトMRUの12(識別)、Identifier分野セット、挿入された地方のマジック数(もしあれば)、およびどんな必要なデータでも満たされたMessage分野に設定するのにもかかわらずの、8を引いたCode分野による超過でないのでのLCPパケットを伝えます。
Receipt of an Identification packet causes the RXR or RUC event.
There is no response to the Identification packet.
Identificationパケットの領収書はRXRかRUCイベントを引き起こします。 Identificationパケットへの応答が全くありません。
Receipt of a Code-Reject for the Identification packet SHOULD
generate the RXJ+ (permitted) event.
SHOULDがRXJ+(受入れられる)のイベントを生成するIdentificationパケットのためのCode-廃棄物の領収書。
Rationale:
原理:
This feature is defined as part of LCP, rather than as a
separate PPP Protocol, in order that its benefits may be
available during the earliest possible stage of the Link
Establishment phase. It allows an operator to learn the
identification of the peer even when negotiation is not
converging. Non-LCP packets cannot be sent during the Link
Establishment phase.
この特徴はLCPの一部と定義されます、むしろ別々のPPPプロトコルより、利益がLink特権階級フェーズの可能な限り前のステージの間、利用可能であることができなるように。 交渉が一点に集まらないときさえ、それで、オペレータは同輩の識別を学ぶことができます。 Link特権階級段階の間、非LCPパケットを送ることができません。
Simpson [Page 1]
シンプソン[1ページ]RFC1570PPP LCP拡大1994年1月
This feature is defined as a separate LCP Code, rather than a
Configuration-Option, so that the peer need not include it with
other items in configuration packet exchanges, and handle
"corrected" values or "rejection", since its generation is both
rare and in one direction. It is recommended that
Identification packets be sent whenever a Configure-Reject is
sent or received, as a final message when negotiation fails to
converge, and when LCP reaches the Opened state.
この特徴はConfiguration-オプションよりむしろ別々のLCP Codeと定義されます、同輩が構成パケット交換で他の項目でそれを入れて、「直っている」値か「拒絶」を扱う必要はないように、ともにまれであり、一方向に世代。 Configure-廃棄物を送るか、または受け取るときはいつも、Identificationパケットを送るのはお勧めです、交渉が一点に集まらないで、LCPがOpened状態に達するとき最終的なメッセージとして。
A summary of the Identification packet format is shown below. The fields are transmitted from left to right.
Identificationパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ… +-+-+-+-+-+-+-+-+
Code
コード
12 for Identification
12 識別のために
Identifier
識別子
The Identifier field MUST be changed for each Identification sent.
Identificationが送ったそれぞれのためにIdentifier分野を変えなければなりません。
Length
長さ
>= 8
>= 8
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 マジック数のConfiguration Optionが首尾よく交渉されるまで、ゼロとしてマジック数を伝えなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
Message
メッセージ
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
Message分野は、ゼロか、より多くの八重奏です、そして、内容は実装に依存しています。 それは、人間読み込み可能であることを意図して、プロトコルの操作に影響してはいけません。 それはお勧めです。
Simpson [Page 2]
シンプソン[2ページ]RFC1570PPP LCP拡大1994年1月
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
メッセージは「ディスプレイ-可能」ASCII文字32〜126小数を含んでいます。 他の文字集合への拡大のためのメカニズムは今後の研究の話題です。 サイズはLength分野から決定しています。
Implementation Note:
実装注意:
The Message will usually contain such things as the sender's
hardware type, PPP software revision level, and PPP product
serial number, MIB information such as link speed and interface
name, and any other information that the sender thinks might be
useful in debugging connections. The format is likely to be
different for each implementor, so that those doing serial
number tracking can validate their numbers. A robust
implementation SHOULD treat the Message as displayable text,
and SHOULD be able to receive and display a very long Message.
送付者のハードウェアタイプ、PPPソフトウェア改正レベル、PPP製品通し番号、リンク速度やインタフェース名のMIB情報、および送付者が考えるといういかなる他の情報もデバッグ接続で役に立つかもしれないので、通常、Messageはそのようなものを含むでしょう。 形式は各作成者にとって異なる傾向があります、通し番号追跡をする人がそれらの番号を有効にすることができるように。 SHOULDがMessageを扱う強健な実装がテキストを「ディスプレイ-可能」して、SHOULDは受信できて、非常に長いMessageを表示します。
1.2. Time-Remaining
1.2. 時間残り
Description
記述
This Code provides a mechanism for notifying the peer of the time
remaining in this session.
このCodeは、このセッションのときに残りながら、現代について同輩に通知するのにメカニズムを提供します。
The nature of this information is advisory only. It is intended
that only one side of the connection will send this packet
(generally a "network access server"). The session is actually
concluded by the Terminate-Request packet.
この情報の本質は状況報告専用です。 接続の半面だけがこのパケット(一般に「ネットワークアクセス・サーバー」)を送ることを意図します。 セッションは実際にTerminate-リクエスト・パケットによって結論づけられます。
Time-Remaining is a Link Maintenance packet. Time-Remaining
packets may only be sent in the LCP Opened state.
時間残りはLink Maintenanceパケットです。 LCP Opened状態で時間が残るパケットを送るだけであるかもしれません。
The sender transmits a LCP packet with the Code field set to 13
(Time-Remaining), the Identifier field set, the local Magic-Number
(if any) inserted, and the Message field filled with any desired
data, but not exceeding the peer's established MRU minus twelve.
送付者は13(時間が残る)に設定されたCode分野、地方のマジック数(もしあれば)が指し込んだIdentifier分野セットでLCPパケットを伝えます、そして、Message分野はどんな必要なデータでも満ちましたが、同輩を超えていないと、MRUは12を引いて創業しました。
Receipt of an Time-Remaining packet causes the RXR or RUC event.
There is no response to the Time-Remaining packet.
Timeが残っているパケットの領収書はRXRかRUCイベントを引き起こします。 Timeが残っているパケットへの応答が全くありません。
Receipt of a Code-Reject for the Time-Remaining packet SHOULD
generate the RXJ+ (permitted) event.
SHOULDがRXJ+(受入れられる)のイベントを生成するTimeが残っているパケットのためのCode-廃棄物の領収書。
Rationale:
原理:
This notification is defined as a separate LCP Code, rather
この通知はむしろ別々のLCP Codeと定義されます。
Simpson [Page 3]
シンプソン[3ページ]RFC1570PPP LCP拡大1994年1月
than a Configuration-Option, in order that changes and warning
messages may occur dynamically during the session, and that the
information might be determined after Authentication has
occurred. Typically, this packet is sent when the link enters
Network-Layer Protocol phase, and at regular intervals
throughout the session, particularly near the end of the
session.
変化と警告メッセージがConfiguration-オプションそうすることができるには、セッションの間、ダイナミックに起こってください。そうすれば、情報がAuthenticationの後に決定しているかもしれないのは起こりました。 通常、リンクがNetwork-層のプロトコルフェーズに入るときに時と一定の間隔を置いてセッションの間中このパケットを送ります、特にセッションの終わり頃に。
A summary of the Time-Remaining packet format is shown below. The fields are transmitted from left to right.
Timeが残っているパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds-Remaining |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒が残っています。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ… +-+-+-+-+-+-+-+-+
Code
コード
13 for Time-Remaining
13 時間残りのために
Identifier
識別子
The Identifier field MUST be changed for each Time-Remaining sent.
送られた各Time-残り単位でIdentifier分野を変えなければなりません。
Length
長さ
>= 12
>= 12
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 マジック数のConfiguration Optionが首尾よく交渉されるまで、ゼロとしてマジック数を伝えなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
Seconds-Remaining
秒が残っています。
The Seconds-Remaining field is four octets and indicates the
number of integral seconds remaining in this session. This 32 bit
Secondsが残っている分野は、このセッションのときに残りながら、4つの八重奏であり、不可欠の秒の数を示します。 この32ビット
Simpson [Page 4]
シンプソン[4ページ]RFC1570PPP LCP拡大1994年1月
unsigned value is sent most significant octet first. A value of
0xffffffff (all ones) represents no timeout, or "forever".
最初に、最も重要な八重奏を未署名の値に送ります。 0xffffffff(すべてのもの)の値はタイムアウトを全く表さないか、「いつまでも。」
Message
メッセージ
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
Message分野は、ゼロか、より多くの八重奏です、そして、内容は実装に依存しています。 それは、人間読み込み可能であることを意図して、プロトコルの操作に影響してはいけません。 メッセージが「ディスプレイ-可能」ASCII文字32〜126小数を含むのは、お勧めです。 他の文字集合への拡大のためのメカニズムは今後の研究の話題です。 サイズはLength分野から決定しています。
Simpson [Page 5]
シンプソン[5ページ]RFC1570PPP LCP拡大1994年1月
2. Additional LCP Configuration Options
2. 追加LCP設定オプション
The Configuration Option format and basic options are already defined for LCP [1].
Configuration Option書式と基本的なオプションはLCP[1]のために既に定義されます。
Up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. This document concerns the following values:
LCP Option Type分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 このドキュメントは以下の値に関係があります:
9 FCS-Alternatives
10 Self-Describing-Padding
13 Callback
15 Compound-Frames
9 FCS-代替手段10そっと歩くと説明する自己13コールバック15合成フレーム
2.1. FCS-Alternatives
2.1. FCS-代替手段
Description
記述
This Configuration Option provides a method for an implementation
to specify another FCS format to be sent by the peer, or to
negotiate away the FCS altogether.
このConfiguration Optionは、同輩によって送られるか、または全体でFCSを譲歩するために実装が別のFCS形式を指定するメソッドを提供します。
This option is negotiated separately in each direction. However,
it is not required that an implementation be capable of
concurrently generating a different FCS on each side of the link.
このオプションは別々に各方向と交渉されます。 しかしながら、実装が同時にリンクの各側面の上の異なったFCSを生成することができるのが必要ではありません。
The negotiated FCS values take effect only during Authentication
and Network-Layer Protocol phases. Frames sent during any other
phase MUST contain the default FCS.
交渉されたFCS値はAuthenticationとNetwork-層のプロトコル段階だけの間実施します。 いかなる他の段階の間にも送られたフレームはデフォルトFCSを含まなければなりません。
A summary of the FCS-Alternatives Configuration Option format is shown below. The fields are transmitted from left to right.
FCS-代替手段Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9
9
Simpson [Page 6]
シンプソン[6ページ]RFC1570PPP LCP拡大1994年1月
Length
長さ
3
3
Options
オプション
This field is one octet, and is comprised of the "logical or" of
the following values:
または、この分野が1つの八重奏であり、包括される、「論理的である、」 以下の値について:
1 Null FCS
2 CCITT 16-bit FCS
4 CCITT 32-bit FCS
1 ヌルFCS2のCCITTの16ビットのFCS4のCCITTの32ビットのFCS
Implementation Note:
実装注意:
For most PPP HDLC framed links, the default FCS is the CCITT 16-
bit FCS. Some framing techniques and high speed links may use
another format as the default FCS.
大部分に関しては、PPP HDLCはリンクを縁どって、デフォルトFCSはCCITT16ビットFCSです。 いくつかの縁どりのテクニックと高速リンクがデフォルトFCSとして別の形式を使用するかもしれません。
2.1.1. LCP considerations
2.1.1. LCP問題
The link can be subject to loss of state, and the LCP can re- negotiate at any time. When the LCP begins renegotiation or termination, it is recommended that the LCP Configure-Request or Terminate-Request packet be sent with the last negotiated FCS, then change to the default FCS, and a duplicate LCP packet is sent with the default FCS. The Identifier field SHOULD NOT be incremented for each such duplicate packet.
リンクは状態の損失を被りやすい場合があります、そして、LCPはいつでも、再交渉できます。 LCPが再交渉か終了を始めるとき、最後に交渉されたFCSと共にLCP Configure-要求かTerminate-リクエスト・パケットを送るのがお勧めであり、FCSがその時、デフォルトに変化して、デフォルトFCSで写しLCPパケットを送ります。 増加されていて、Identifierはそのようなそれぞれの写しパケットのためにSHOULD NOTをさばきます。
On receipt of a LCP Configure-Request or Terminate-Request packet, the implementation MUST change to the default FCS for both transmission and reception. If a Request packet is received which contains a duplicate Identifier field, a new reply MUST be generated.
LCP Configure-要求かTerminate-リクエスト・パケットを受け取り次第、実装はトランスミッションとレセプションの両方のためにデフォルトFCSに変化しなければなりません。 Requestパケットが受け取られているなら、(写しIdentifier分野を含んでいます)新しい回答を生成しなければなりません。
Implementation Notes:
実装注意:
The need to send two packets is only necessary after the
Alternative-FCS has already been negotiated. It need not occur
during state transitions when there is a natural indication that
the default FCS is in effect, such as the Down and Up events. It
is necessary to send two packets in the Ack-Sent and Opened
states, since the peer could mistakenly believe that the link has
Opened.
Alternative-FCSが既に交渉された後に2つのパケットを送る必要性が必要であるだけです。 デフォルトFCSが有効であることは自然な指示があるときの状態遷移の間、起こる必要はありません、DownやUpイベントのように。 Ackによって送られるのとOpened州で2つのパケットを送るのが必要です、同輩が、リンクにはOpenedがあると誤って信じることができたので。
It is possible to send a single 48-bit FCS which is a combination
of the 16-bit and 32-bit FCS. This may be sent instead of sending
16ビットと32ビットのFCSの組み合わせである独身の48ビットのFCSを送るのは可能です。 発信の代わりにこれを送るかもしれません。
Simpson [Page 7]
シンプソン[7ページ]RFC1570PPP LCP拡大1994年1月
the two packets described above. We have not standardized this
procedure because of intellectual property concerns. If such a
48-bit FCS is used, it MUST only be used for LCP packets.
上で説明された2つのパケット。 私たちは知的所有権関心のためにこの手順を標準化していません。 そのような48ビットのFCSが使用されているなら、LCPパケットにそれを使用するだけでよいです。
2.1.2. Null FCS
2.1.2. ヌルFCS
The Null FCS SHOULD only be used for those network-layer and transport protocols which have an end-to-end checksum available, such as TCP/IP, or UDP/IP with the checksum enabled. That is, the Null FCS option SHOULD be negotiated together with another non-null FCS option in a heterogeneous environment.
Null FCS SHOULD、終わりから終わりへのTCP/IP、またはUDP/IPなどのように利用可能な可能にされているチェックサムでチェックサムを持っているそれらのネットワーク層とトランスポート・プロトコルに単に使用されてください。 すなわち、Null FCSは交渉された別のものに伴う非ヌルのFCSが異機種混在環境でオプションであったならSHOULDにゆだねます。
When a configuration (LCP or NCP) or authentication packet is sent, the FCS MUST be included. When a configuration (LCP or NCP) or authentication packet is received, the FCS MUST be verified.
構成(LCPかNCP)か認証パケットを送るときFCS MUST、含められてください。 構成(LCPかNCP)か受け取られた認証パケット、FCS MUSTである、確かめられてください。
There are several cases to be considered:
考えられる数個のケースがあります:
Null FCS alone
ヌルFCSだけ
The sender generates the FCS for those frames which require the
FCS before sending the frame.
送付者はフレームを送る前にFCSを必要とするそれらのフレームにFCSを生成します。
When a frame is received, it is not necessary to check the FCS
before demultiplexing. Any FCS is treated as padding.
フレームが受け取られているとき、逆多重化の前にFCSをチェックするのは必要ではありません。 どんなFCSも詰め物として扱われます。
Receipt of an Authentication or Control packet would be discovered
after passing the frame to the demultiplexer. Verification of the
FCS can easily be accomplished using one of the software
algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and
Appendix A (32-bit FCS).
フレームをデマルチプレクサに通り過ぎた後に、AuthenticationかControlパケットの領収書は発見されるでしょう。 「HDLC縁どりにおけるppp」[3]で定義されたソフトウェアアルゴリズム(16ビットのFCS)とAppendix A(32ビットのFCS)の1つを使用することで容易にFCSの検証を実行できます。
Null FCS with another FCS, using software
ソフトウェアを使用する別のFCSとヌルFCS
This is similar to the above case.
これは上のケースと同様です。
Those packets which are required to have the FCS (Authentication,
Control, or Network-Protocols lacking a checksum) are checked
using software after demultiplexing. Packets which fail the FCS
test are discarded as usual.
FCS(認証、Control、またはチェックサムを欠いているNetwork-プロトコル)を持たなければならないそれらのパケットが、逆多重化の後にソフトウェアを使用することでチェックされます。 FCSテストに失敗するパケットがいつものように捨てられます。
Null FCS with another FCS, using hardware
ハードウェアを使用する別のFCSとヌルFCS
A flag is passed with the frame, indicating whether or not it has
passed the hardware FCS check. The incorrect FCS MUST be passed
with the rest of the data. The frame MUST NOT be discarded until
after demultiplexing, and only those frames that require the FCS
それがハードウェアFCSチェックを通過したかどうかを示して、旗はフレームに渡されます。 不正確なFCS MUST、データの残りで、通過されてください。 逆多重化、およびFCSを必要とするそれらのフレームだけの後までフレームを捨ててはいけません。
Simpson [Page 8]
シンプソン[8ページ]RFC1570PPP LCP拡大1994年1月
are discarded.
捨てられます。
All three FCS forms (Null, 16 and 32) may be used concurrently on different frames when using software. That is probably not possible with most current hardware.
ソフトウェアを使用するとき、すべての3つのFCSフォーム(ヌル、16、および32)が同時に異なったフレームの上に使用されるかもしれません。 それはたぶん最も現在のハードウェアで可能ではありません。
2.2. Self-Describing-Padding
2.2. そっと歩くと説明する自己
Description
記述
This Configuration Option provides a method for an implementation
to indicate to the peer that it understands self-describing pads
when padding is added at the end of the PPP Information field.
このConfiguration Optionは実装が詰め物がPPP情報分野の端で加えられるとき、自己にパッドについて説明するのを理解しているのを同輩に示すメソッドを提供します。
This option is most likely to be used when some protocols, such as
network-layer or compression protocols, are configured which
require detection and removal of any trailing padding. Such
special protocols are identified in their respective documents.
ネットワーク層か圧縮プロトコルなどのいくつかのプロトコルが構成されるとき、このオプションは最も使用されそうです(どんな引きずっている詰め物の検出と取り外しも必要とします)。 そのような特別なプロトコルはそれらのそれぞれのドキュメントで特定されます。
If the option is Rejected, the peer MUST NOT add any padding to
the identified special protocols, but MAY add padding to other
protocols.
オプションがRejectedであるなら、同輩は、特定された特別なプロトコルに少しの詰め物も追加してはいけませんが、他のプロトコルに詰め物を追加するかもしれません。
If the option is Ack'd, the peer MUST follow the procedures for
adding self-describing pads, but only to the specifically
identified protocols. The peer is not required to add any padding
to other protocols.
オプションがそうなら、Ackは後をつけるでしょう、と自己にパッドについて説明しますが、加えるための手順が明確に特定されたプロトコルだけに後をつける場合、同輩は後をつけなければなりません。 同輩はどんな詰め物も他のプロトコルに追加する必要はありません。
Implementation Notes:
実装注意:
This is defined so that the Reject handles either case where
the peer does not generate self-describing pads. When the peer
never generates padding, it may safely Reject the option. When
the peer does not understand the option, it also will not
successfully configure a special protocol which requires
elimination of pads.
これが定義されるので、Rejectは同輩が自己について説明するパッドを生成しないどちらのケースも扱います。 同輩が詰め物を決して生成しないと、安全に生成する、Reject、オプション。 また、同輩がオプションを理解していない場合、それは首尾よくパッドの除去を必要とする特別なプロトコルを構成しないでしょう。
While some senders might only be capable of adding padding to
every protocol or not adding padding to any protocol, by design
the receiver need not examine those protocols which do not need
the padding stripped.
何人かの送付者がどんなプロトコルにもそっと歩きながら、付加ではなく、あらゆるプロトコルに付加をそっと歩くことができるだけであるかもしれませんが、故意に、受信機は詰め物を剥取る必要はないそれらのプロトコルを調べる必要はありません。
To avoid unnecessary configuration handshakes, an
implementation which generates padding, and has a protocol
configured which requires the padding to be known, SHOULD
include this Option in its Configure-Request, and SHOULD
不要な構成握手、詰め物を生成して、詰め物が知られているのを必要とする構成されたプロトコルを持っている実装を避けるために、SHOULDはConfigure-要求、およびSHOULDにこのOptionを含んでいます。
Simpson [Page 9]
シンプソン[9ページ]RFC1570PPP LCP拡大1994年1月
Configure-Nak with this Option when it is not present in the
peer's Request.
それであるときに、これでNakを構成しているOptionは同輩のRequestに存在していません。
Each octet of self-describing pad contains the index of that
octet. The first pad octet MUST contain the value one (1), which
indicates the Padding Protocol to the Compound-Frames option.
After removing the FCS, the final pad octet indicates the number
of pad octets to remove. For example, three pad octets would
contain the values 1, 2, 3.
自己について説明するパッドの各八重奏はその八重奏のインデックスを含んでいます。 最初のパッド八重奏は値を含まなければなりません。もの(1)。(そのものはCompound-フレームオプションにPaddingプロトコルを示します)。 FCSが取り外されるために、最終的なパッド八重奏は次々とパッド八重奏の数を示します。 例えば、3つのパッド八重奏が値1、2、3を含んでいるでしょう。
The Maximum-Pad-Value (MPV) is also negotiated. Only the values 1
through MPV are used. When no padding would otherwise be
required, but the final octet of the PPP Information field
contains the value 1 through MPV, at least one self-describing pad
octet MUST be added to the frame. If the final octet is greater
than MPV, no additional padding is required.
また、Maximumパッド価値(MPV)は交渉されます。 MPVを通した値1だけが使用されています。 水増しでないのが別の方法で必要でしょうが、PPP情報分野の最終的な八重奏がMPVを通して値1を含むとき、少なくとも1つの自己について説明するパッド八重奏をフレームに加えなければなりません。 最終的な八重奏がMPVより大きいなら、どんな追加詰め物も必要ではありません。
Implementation Notes:
実装注意:
If any of the pad octets contain an incorrect index value, the
entire frame SHOULD be silently discarded. This is intended to
prevent confusion with the FCS-Alternatives option, but might
not be necessary in robust implementations.
パッド八重奏のどれかが不正確なインデックス値を含んでいるなら、捨てられて、全体のフレームSHOULDは静かに含んでいます。 これは、FCS-代替手段オプションへの混乱を防ぐことを意図しますが、強健な実装では必要でないかもしれません。
Since this option is intended to support compression protocols,
the Maximum-Pad-Value is specified to limit the likelihood that
a frame may actually become longer.
このオプションが、圧縮がプロトコルであるとサポートすることを意図するので、Maximumパッド価値はフレームが実際により長くなるかもしれないという見込みを制限するために指定されます。
A summary of the Self-Describing-Padding Configuration Option format is shown below. The fields are transmitted from left to right.
そっと歩くと説明するSelf Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Maximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 最大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
10
10
Length
長さ
3
3
Simpson [Page 10]
シンプソン[10ページ]RFC1570PPP LCP拡大1994年1月
Maximum
最大
This field specifies the largest number of padding octets which
may be added to the frame. The value may range from 1 to 255, but
values of 2, 4, or 8 are most likely.
この分野はフレームに加えられるかもしれない詰め物八重奏の最多数を指定します。 値は1〜255まで及ぶかもしれませんが、2の値であり、4、または8が最もありそうです。
2.3. Callback
2.3. コールバック
Description
記述
This Configuration Option provides a method for an implementation
to request a dial-up peer to call back. This option might be used
for many diverse purposes, such as savings on toll charges.
このConfiguration Optionは実装が電話し直すようダイヤルアップ同輩に要求するメソッドを提供します。 このオプションは料金に関する貯蓄などのさまざまの多くの目的に使用されるかもしれません。
When Callback is successfully negotiated, and authentication is
complete, the Authentication phase proceeds directly to the
Termination phase, and the link is disconnected.
Callbackが首尾よく交渉されて、認証が完全であるときに、Authenticationフェーズは直接Terminationフェーズに続きます、そして、リンク切断されます。
Then, the peer re-establishes the link, without negotiating
Callback.
そして、Callbackを交渉しないで、同輩はリンクを復職させます。
Implementation Notes:
実装注意:
A peer which agrees to this option SHOULD request the
Authentication-Protocol Configuration Option. The user
information learned during authentication can be used to
determine the user location, or to limit a user to certain
locations, or merely to determine whom to bill for the service.
SHOULDがAuthentication-プロトコルConfiguration Optionを要求するのにこのオプションに同意する同輩。 ユーザ位置を決定するか、ユーザをある位置に制限するか、または単にサービスのための請求書にだれを決定するかに認証の間に学習されたユーザー情報は使用できます。
Authentication SHOULD be requested in turn by the
implementation when it is called back, if mutual authentication
is desired.
それがコールバックされるとき、認証SHOULDが実装によって順番に要求されて、互いであるなら、認証は望まれています。
A summary of the Callback Option format is shown below. The fields are transmitted from left to right.
Callback Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Operation | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 操作| メッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
13
13
Simpson [Page 11]
シンプソン[11ページ]RFC1570PPP LCP拡大1994年1月
Length
長さ
>= 3
>= 3
Operation
操作
The Operation field is one octet and indicates the contents of the
Message field.
Operation分野は、1つの八重奏であり、Message分野のコンテンツを示します。
0 location is determined by user authentication
0 位置はユーザー認証で決定します。
1 Dialing string, the format and contents of which assumes
configuration knowledge of the specific device which is
making the callback.
1 それのストリングにダイヤルする、形式、およびコンテンツがコールバックを作っている特定のデバイスに関する構成知識を仮定する。
2 Location identifier, which may or may not be human
readable, to be used together with the authentication
information for a database lookup to determine the
callback location.
2位置の識別子。(その識別子は、データベースルックアップがコールバック位置を決定するのに認証情報と共に使用されるために読み込み可能な状態で人間であるかもしれません)。
3 E.164 number.
3 E.164番号。
4 Distinguished name.
4分類名。
Message
メッセージ
The Message field is zero or more octets, and its general contents
are determined by the Operation field. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The size is determined from the Length field.
Message分野は、ゼロか、より多くの八重奏です、そして、一般的な内容はOperation分野のそばで決定しています。 情報の実際の形式は、サイトかアプリケーション特有であって、SHOULDが平凡な八重奏として分野をサポートする強健な実装です。 サイズはLength分野から決定しています。
It is intended that only an authorized user will have correct site
specific information to make use of the Callback. The
codification of the range of allowed usage of this field is
outside the scope of this specification.
認定ユーザだけにはCallbackを利用する正しいサイト特殊情報があることを意図します。 この仕様の範囲の外にこの分野の許容用法の範囲の成文化があります。
2.4. Compound-Frames
2.4. 合成フレーム
Description
記述
This Configuration Option provides a method for an implementation
to send multiple PPP encapsulated packets within the same frame.
This option might be used for many diverse purposes, such as
savings on toll charges.
このConfiguration Optionは実現が同じフレームの中に要約のパケットを複数のPPPに送る方法を提供します。 このオプションは料金に関する貯蓄などのさまざまの多くの目的に使用されるかもしれません。
Simpson [Page 12]
シンプソン[12ページ]RFC1570PPP LCP拡大1994年1月
Only those PPP Protocols which have determinate lengths or
integral length fields may be aggregated into a compound frame.
確定的な長さか不可欠の長さの分野を持っているそれらのPPPプロトコルだけを合成フレームに集めてもよいです。
When Compound-Frames is successfully negotiated, the sender MAY
add additional packets to the same frame. Each packet is
immediately followed by another Protocol field, with its attendant
datagram.
Compound-フレームが首尾よく交渉されるとき、送付者は同じフレームに追加パケットを加えるかもしれません。 付き添いのデータグラムがある別のプロトコル分野はすぐに、各パケットのあとに続きます。
When padding is added to the end of the Information field, the
procedure described in Self-Describing-Padding is used.
Therefore, this option MUST be negotiated together with the Self-
Describing-Padding option.
詰め物が情報分野の端に加えられるとき、そっと歩くと説明するSelfで説明された手順は使用されています。 したがって、説明をそっと歩くSelfオプションと共にこのオプションを交渉しなければなりません。
If the FCS-Alternatives option has been negotiated, self
describing padding MUST always be added. That is, the final
packet MUST be followed by a series of octets, the first of which
contains the value one (1).
FCS-代替手段オプションが交渉されたなら、いつもそっと歩くと説明する自己を加えなければなりません。 一連の八重奏がすなわち、最終的なパケットのあとに続かなければなりません、値を含むものの1番目。1(1)。
On receipt, the first Protocol field is examined, and the packet
is processed as usual. For those datagrams which have a
determinate length, the remainder of the frame is returned to the
demultiplexor. Each succeeding Protocol field is processed as a
separate packet. This processing is complete when a packet is
processed which does not have a determinate length, when the
remainder of the frame is empty, or when the Protocol field is
determined to have a value of one (1).
領収書の上では、最初のプロトコル分野は調べられます、そして、パケットはいつものように処理されます。 確定的な長さを持っているそれらのデータグラムに関しては、フレームの残りは「反-マルチプレクサー」に返されます。 続くそれぞれのプロトコル分野は別々のパケットとして処理されます。 確定的な長さを持っていないパケットが処理されるとき、この処理は完全です、フレームの残りが空であるか、またはプロトコル分野が1つ(1)の値を持っていることを決定しているとき。
The PPP Protocol value of one (1) is reserved as the Padding
Protocol. Any following octets are removed as padding.
1つ(1)のPPPプロトコル価値はPaddingプロトコルとして予約されます。 詰め物としてどんな次の八重奏も取り除きます。
A summary of the Compound-Frames Option format is shown below. The fields are transmitted from left to right.
Compound-フレームOption形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
15
15
Length
長さ
2
2
Simpson [Page 13]
シンプソン[13ページ]RFC1570PPP LCP拡大1994年1月
2.4.1. LCP considerations
2.4.1. LCP問題
During initial negotiation, the Compound-Frames option can be used to minimize the negotiation latency, by reducing the number of frames exchanged.
初期の交渉の間、交渉潜在を最小にするのにCompound-フレームオプションを使用できます、交換されたフレームの数を減少させることによって。
The first LCP Configure-Request packet is sent as usual in a single frame, including the Self-Describing-Padding and Compound-Frames options.
そっと歩くと説明するSelfとCompound-フレームオプションを含んでいて、シングルフレームでいつものように最初のLCP Configure-リクエスト・パケットを送ります。
The peer SHOULD respond with a Configure-Ack, followed in a compound frame by its LCP Configure-Request, and any NCP Configure-Requests desired.
SHOULDがLCP Configure-要求が合成フレームであとに続いたConfigure-Ackと共に反応して、どんなNCP Configure-要求も望んでいた同輩。
Upon receipt, the local implementation SHOULD process the Configure- Ack as usual. Since the peer has agreed to send compound frames, the implementation MUST examine the remainder of the frame for additional packets. If the peer also specified the Self-Describing-Padding and Compound-Frames options in its Configure-Request, the local implementation SHOULD retain its Configure-Ack, and further NCP configuration packets SHOULD be added to the return frame.
領収書に、地方の実現SHOULDは通常通りのConfigure- Ackを処理します。 同輩が、合成フレームを送るのに同意したので、実現は追加パケットがないかどうかフレームの残りを調べなければなりません。 また、同輩がConfigure-要求におけるそっと歩くと説明するSelfとCompound-フレームオプションを指定したなら、地方の実現SHOULDはConfigure-Ack、およびさらなるNCP構成パケットSHOULDを保有します。リターンフレームに加えられます。
Together with the peer's final return frame, the minimum number of frames to complete configuration is 4.
同輩の確定申告フレームと共に、構成を完成するフレームの最小の数は4です。
Simpson [Page 14]
シンプソン[14ページ]RFC1570PPP LCP拡大1994年1月
A. Fast Frame Check Sequence (FCS) Implementation
A。 速いフレームチェックシーケンス(FCS)実現
A.1. 32-bit FCS Computation Method
A.1。 32ビットのFCS計算方法
The following code provides a table lookup computation for calculating the 32-bit Frame Check Sequence as data arrives at the interface.
以下のコードはデータがインタフェースに到着するので32ビットのFrame Check Sequenceについて計算するための索表計算を提供します。
/*
* u32 represents an unsigned 32-bit number. Adjust the typedef for
* your hardware.
*/
typedef unsigned long u32;
/**u32は無記名の32ビットの数を表します。 *のためにtypedefを調整してください。あなたのハードウェア。 */typedef無記名の長いu32。
static u32 fcstab_32[256] =
{
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
静的なu32 fcstab_32256が等しい、0×00000000、0×77073096、0xee0e612c、0x990951ba、0x076dc419、0x706af48f、0xe963a535、0x9e6495a3、0x0edb8832、0x79dcb8a4、0xe0d5e91e、0x97d2d988、0x09b64c2b、0x7eb17cbd、0xe7b82d07、0x90bf1d91、0x1db71064、0x6ab020f2、0xf3b97148、0x84be41de、0x1adad47d、0x6ddde4eb、0xf4d4b551、0x83d385c7、0x136c9856、0x646ba8c0、0xfd62f97a、0x8a65c9ec、0x14015c4f、0x63066cd9、0xfa0f3d63、0x8d080df5、0x3b6e20c8、0x4c69105e、0xd56041e4、0xa2677172、0x3c03e4d1、0x4b04d447、0xd20d85fd、0xa50ab56b; 0x35b5a8fa、0x42b2986c、0xdbbbc9d6、0xacbcf940、0x32d86ce3、0x45df5c75、0xdcd60dcf、0xabd13d59、0x26d930ac、0x51de003a、0xc8d75180、0xbfd06116、0x21b4f4b5、0x56b3c423、0xcfba9599、0xb8bda50f、0x2802b89e、0x5f058808、0xc60cd9b2、0xb10be924、0x2f6f7c87; 0x58684c11、0xc1611dab、0xb6662d3d、0x76dc4190、0x01db7106、0x98d220bc、0xefd5102a、0x71b18589、0x06b6b51f、0x9fbfe4a5、0xe8b8d433、0x7807c9a2、0x0f00f934、0x9609a88e、0xe10e9818、0x7f6a0dbb、0x086d3d2d、0x91646c97、0xe6635c01、0x6b6b51f4、0x1c6c6162、0×856530d8、0xf262004e、0x6c0695ed、0x1b01a57b、0x8208f4c1、0xf50fc457、0x65b0d9c6、0x12b7e950、0x8bbeb8ea、0xfcb9887c、0x62dd1ddf、0x15da2d49、0x8cd37cf3、0xfbd44c65、0x4db26158、0x3ab551ce、0xa3bc0074、0xd4bb30e2、0x4adfa541、0x3dd895d7、0xa4d1c46d、0xd3d6f4fb、0x4369e96a; 0x346ed9fc、0xad678846、0xda60b8d0、0x44042d73、0x33031de5、0xaa0a4c5f、0xdd0d7cc9、0x5005713c、0x270241aa、0xbe0b1010、0xc90c2086、0x5768b525、0x206f85b3、0xb966d409、0xce61e49f、0x5edef90e、0x29d9c998、0xb0d09822、0xc7d7a8b4、0x59b33d17、0x2eb40d81、0xb7bd5c3b、0xc0ba6cad
Simpson [Page 15]
シンプソン[15ページ]RFC1570PPP LCP拡大1994年1月
0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
};
0xedb88320、0x9abfb3b6、0x03b6e20c、0x74b1d29a、0xead54739、0x9dd277af、0x04db2615、0x73dc1683、0xe3630b12、0x94643b84、0x0d6d6a3e、0x7a6a5aa8、0xe40ecf0b、0x9309ff9d、0x0a00ae27、0x7d079eb1、0xf00f9344、0x8708a3d2、0x1e01f268、0x6906c2fe、0xf762575d、0x806567cb; 0x196c3671、0x6e6b06e7、0xfed41b76、0x89d32be0、0x10da7a5a、0x67dd4acc、0xf9b9df6f、0x8ebeeff9、0x17b7be43、0x60b08ed5、0xd6d6a3e8、0xa1d1937e、0x38d8c2c4、0x4fdff252、0xd1bb67f1、0xa6bc5767、0x3fb506dd、0x48b2364b、0xd80d2bda、0xaf0a1b4c、0x36034af6; 0x41047a60、0xdf60efc3、0xa867df55、0x316e8eef、0x4669be79、0xcb61b38c、0xbc66831a、0x256fd2a0、0x5268e236、0xcc0c7795、0xbb0b4703、0x220216b9、0x5505262f、0xc5ba3bbe、0xb2bd0b28、0x2bb45a92、0x5cb36a04、0xc2d7ffa7、0xb5d0cf31、0x2cd99e8b、0x5bdeae1d、0x9b64c2b0、0xec63f226、0x756aa39c、0x026d930a、0x9c0906a9、0xeb0e363f、0×72076785、0×05005713、0x95bf4a82、0xe2b87a14、0x7bb12bae、0x0cb61b38、0x92d28e9b、0xe5d5be0d、0x7cdcefb7、0x0bdbdf21、0x86d3d2d4、0xf1d4e242、0x68ddb3f8、0x1fda836e、0x81be16cd0xf6b9265b、0x6fb077e1、0x18b74777、0x88085ae6、0xff0f6a70、0x66063bca、0x11010b5c、0x8f659eff、0xf862ae69、0x616bffd3、0x166ccf45、0xa00ae278、0xd70dd2ee、0x4e048354、0x3903b3c2、0xa7672661、0xd06016f7、0x4969474d、0x3e6e77db、0xaed16a4a、0xd9d65adc、0x40df0b66; 0x37d83bf0、0xa9bcae53、0xdebb9ec5、0x47b2cf7f、0x30b5ffe9、0xbdbdf21c、0xcabac28a、0x53b39330、0x24b4a3a6、0xbad03605、0xcdd70693、0x54de5729、0x23d967bf、0xb3667a2e、0xc4614ab8、0x5d681b02、0x2a6f2b94、0xb40bbe37、0xc30c8ea1、0x5a05df1b、0x2d02ef8d、。
#define PPPINITFCS32 0xffffffff /* Initial FCS value */ #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */
#定義、PPPINITFCS32 0xffffffff/*初期のFCS値*/#、はPPPGOODFCS32 0xdebb20e3/*良い最終的なFCS値*/を定義します。
/*
* Calculate a new FCS given the current FCS and the new data.
*/
u32 pppfcs32(fcs, cp, len)
register u32 fcs;
register unsigned char *cp;
register int len;
{
ASSERT(sizeof (u32) == 4);
ASSERT(((u32) -1) > 0);
while (len--)
現在のFCSと新しいデータを考えて、/**は新しいFCSについて計算します。 */u32 pppfcs32(fcs、cp、len)レジスタu32 fcs。 無記名の炭*cpを登録してください。 int lenを登録してください。 (sizeof(u32)=4)について断言してください; (((u32)-1)>0)について断言してください。(len--、)
Simpson [Page 16]
シンプソン[16ページ]RFC1570PPP LCP拡大1994年1月
fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
fcsは^fcstab_32[((fcs)^(*cp++))と0xff)と等しいです((fcs)>>8)。
return (fcs);
}
戻ってください(fcs)。 }
/*
* How to use the fcs
*/
tryfcs32(cp, len)
register unsigned char *cp;
register int len;
{
u32 trialfcs;
fcs*/tryfcs32を使用するために、(cp、len)が無記名で登録される/**は*cpを炭にします。 int lenを登録してください。 u32 trialfcs。
/* add on output */
trialfcs = pppfcs32( PPPINITFCS32, cp, len );
trialfcs ^= 0xffffffff; /* complement */
cp[len] = (trialfcs & 0x00ff); /* Least significant byte first */
cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
cp[len+3] = ((trialfcs >> 8) & 0x00ff);
/*は出力*/trialfcs=pppfcs32(PPPINITFCS32、cp、len)を加えます。 trialfcs^は0xffffffffと等しいです。 /*補数*/cp[len]は(trialfcsと0x00ff)と等しいです。 最初に、/*最も重要でないバイト*/cp[len+1]は((trialfcs>>=8)と0x00ff)と等しいです。 cp[len+2]は((trialfcs>>=8)と0x00ff)と等しいです。 cp[len+3]は((trialfcs>>8)と0x00ff)と等しいです。
/* check on input */
trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
if ( trialfcs == PPPGOODFCS32 )
printf("Good FCS\n");
}
入力*/trialfcsの/*チェックはpppfcs32(PPPINITFCS32、cp、len+4)と等しいです。 (trialfcs=PPPGOODFCS32)printf(「良いFCS\n」)であるなら。 }
Security Considerations
セキュリティ問題
Security issues are briefly discussed in sections concerning the Callback Configuration Option.
Callback Configuration Optionに関してセクションで簡潔に安全保障問題について議論します。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1548, Daydreamer, December 1993.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、RFC1548、空想家、1993年12月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1340, USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
Daydreamer, December 1993.
[3] シンプソン、W.、エディタ、「HDLC縁どりにおけるppp」、RFC1549、空想家、1993年12月。
Simpson [Page 17]
シンプソン[17ページ]RFC1570PPP LCP拡大1994年1月
Acknowledgments
承認
The Identification feature was suggested by Bob Sutterfield (Morning Star Technologies).
Identificationの特徴はボブSutterfield(朝のStar Technologies)によって勧められました。
The Time-Remaining feature was suggested by Brad Parker (FCR).
Timeが残っている特徴はブラッド・パーカー(FCR)によって提案されました。
Some of the original text for FCS-Alternatives was provided by Arthur Harvey (then of DEC). The Null FCS was requested by Peter Honeyman (UMich). The 32-bit FCS example code was provided by Karl Fox (Morning Star Technologies).
FCS-代替手段のための原本のいくつかがアーサー・ハーヴェイ(次に12月について)によって提供されました。 Null FCSはピーター・ハニーマン(UMich)によって要求されました。 32ビットのFCS例のコードはカールフォックス(朝のStar Technologies)によって提供されました。
Self-Describing-Padding was suggested and named by Fred Baker (ACC).
そっと歩くと説明する自己が、提案されて、フレッドで(ACC)とベイカーを命名しました。
Compound-Frames was suggested by Keith Sklower (Berkeley).
合成フレームはキースSklower(バークレー)によって勧められました。
Special thanks to Morning Star Technologies for providing computing resources and network access support for writing this specification.
コンピューティング資源とネットワークアクセスを提供するためのMorning Star Technologiesへの特別な感謝は書くことのためにこの仕様を支持します。
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
Editor'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 18]
シンプソン[18ページ]
一覧
スポンサーリンク
