RFC964 日本語訳
0964 Some problems with the specification of the Military StandardTransmission Control Protocol. D.P. Sidhu, T. Blumer. November 1985. (Format: TXT=20972 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Deepinder P. Sidhu
Request for Comments: 964 Thomas P. Blumer
SDC - A Burroughs Company
November 1985
Sidhuがコメントのために要求するワーキンググループDeepinder P.をネットワークでつないでください: 964トーマスP.Blumer SDC--バローズ会社1985年11月
SOME PROBLEMS WITH THE SPECIFICATION OF THE
MILITARY STANDARD TRANSMISSION CONTROL PROTOCOL
軍事の標準の通信制御プロトコルの仕様に関するいくつかの問題
STATUS OF THIS MEMO
このメモの状態
The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. Distribution of this note is unlimited.
このRFCの目的は1つがこのプロトコル標準の信頼できる実装を得ることができるようにMilitary Standard通信制御プロトコル(軍規格-1778)に関する役立つ情報を提供することです。 この注意の分配は無制限です。
Reprinted from: Proc. Protocol Specification, Testing and
Verification IV, (ed.) Y. Yemini, et al, North-Holland (1984).
以下から増刷されました。 Proc。 編は仕様、テスト、および検証IVについて議定書の中で述べてください。 Y。 Yemini、他、北部オランダ(1984)。
ABSTRACT
要約
This note points out three errors with the specification of the Military Standard Transmission Control Protocol (MIL-STD-1778, dated August 1983 [MILS83]). These results are based on an initial investigation of this protocol standard. The first problem is that data accompanying a SYN can not be accepted because of errors in the acceptance policy. The second problem is that no retransmission timer is set for a SYN packet, and therefore the SYN will not be retransmitted if it is lost. The third problem is that when the connection has been established, neither entity takes the proper steps to accept incoming data. This note also proposes solutions to these problems.
この注意はMilitary Standard通信制御プロトコル(時代遅れの1983[MILS83]年8月の軍規格-1778)の仕様で3つの誤りを指摘します。 これらの結果はこのプロトコル標準の初期の調査に基づいています。 第1の問題は誤りのために承認方針でSYNに同伴するデータは受け入れることができないということです。 2番目の問題は再送信タイマーが全くSYNパケットに設定されないで、またしたがって、それが無くなるとSYNが再送されないということです。 3番目の問題は接続が確立されたとき、どちらの実体も受信データを受け入れるために適切な方法を採らないということです。 また、この注意はこれらの問題にソリューションを提案します。
1. Introduction
1. 序論
In recent years, much progress has been made in creating an integrated set of tools for developing reliable communication protocols. These tools provide assistance in the specification, verification, implementation and testing of protocols. Several protocols have been analyzed and developed using such tools.
近年、多くの進歩が信頼できる通信プロトコルを開発するために統合セットのツールを作成する際に見られました。 これらのツールはプロトコルの仕様、検証、実装、およびテストにおける支援を提供します。 そのようなツールを使用することでいくつかのプロトコルを、分析されて、開発してあります。
In a recent paper, the authors discussed the verification of the connection management of NBS class 4 transport protocol (TP4). The verification was carried out with the help of a software tool we developed [BLUT82] [BLUT83] [SIDD83]. In spite of the very precise specification of this protocol, our analysis discovered several errors in the current specification of NBS TP4. These errors are incompleteness errors in the specification, that is, states where there is no transition for the reception of some input event. Our analysis did not find deadlocks, livelocks or any other problem in the connection management of TP4. In that paper, we proposed
最近の紙では、作者はNBSクラス4トランスポート・プロトコル(TP4)の接続管理の検証について議論しました。 検証が私たちが開発したソフトウェアツール[BLUT82][BLUT83][SIDD83]の助けによって行われました。 このプロトコルの非常に正確な仕様にもかかわらず、私たちの分析はNBS TP4の現在の仕様でいくつかの誤りを発見しました。 これらの誤りは仕様(すなわち、何らかの入力イベントのレセプションのための変遷が全くない州)に基づき不備誤りです。 私たちの分析はTP4の接続管理で行き詰まり、livelocksまたはいかなる他の問題も見つけませんでした。 その紙では、私たちは提案しました。
Sidhu & Blumer [Page 1]
Sidhu&Blumer[1ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
solutions for all errors except for errors associated with 2 states whose satisfactory resolution may require redesigning parts of TP4. Modifications to TP4 specification are currently underway to solve the remaining incompleteness problems with 2 states. It is important to emphasize that we did not find any obvious error in the NBS specification of TP4.
満足のいく解決が部品を再設計するのをTP4を要求するかもしれない2つの州に関連している誤り以外のすべての誤りのためのソリューション。 TP4仕様への変更は、現在、2つの州に関する残っている不備問題を解決するために進行中です。 私たちがTP4のNBS仕様で少しの明白な誤りも見つけなかったと強調するのは重要です。
The authors are currently working on the verification of connection management of the Military Standard Transmission Control Protocol (TCP). This analysis will be based on the published specification [MILS83] of TCP dated 12 August 1983.
作者は現在、Military Standard通信制御プロトコル(TCP)の接続管理の検証に取り組んでいます。 この分析は1983年8月12日が日付を入れられたTCPの広められた仕様[MILS83]に基づくでしょう。
While studying the MIL standard TCP specification in preparation for our analysis of the connection management features, we have noticed several errors in the specification. As a consequence of these errors, the Transmission Control Protocol (as specified in [MILS83]) will not permit data to be received by TCP entities in SYN_RECVD and ESTAB states.
私たちの接続管理機能の分析に備えてMILの標準のTCP仕様を研究している間、私たちは仕様でいくつかの誤りに気付いています。 これらの誤りの結果として、通信制御プロトコル([MILS83]で指定されるように)は、データがSYN_RECVDとESTAB州にTCP実体によって受け取られることを許可しないでしょう。
The proof of this statement follows from the specification of the three-way handshake mechanism of TCP [MILS83] and from a decision table associated with ESTAB state.
この声明の証拠はTCP[MILS83]の3方向ハンドシェイクメカニズムの仕様と、そして、ESTAB状態に関連している決定表から従います。
2. Transmission Control Protocol
2. 通信制御プロトコル
The Transmission Control Protocol (TCP) is a transport level connection-oriented protocol in the DoD protocol hierarchy for use in packet-switched and other networks. Its most important services are reliable transfer and ordered delivery of data over full-duplex and flow-controlled virtual connections. TCP is designed to operate successfully over channels that are inherently unreliable, i.e., they can lose, damage, duplicate, and reorder packets.
通信制御プロトコル(TCP)はパケットで切り換えられて他における使用のためのDoDプロトコル階層の平らな接続指向のプロトコルがネットワークでつなぐ輸送です。 最も重要なサービスは、全二重と流れで制御された仮想接続の上のデータの信頼できる転送と命令された配送です。 TCPは、本来頼り無いです、すなわち、彼らが損をする場合があります、損害、写しということであるチャンネル、および追加注文パケットの上で首尾よく作動するように設計されています。
TCP is based, in part, on a protocol discussed by Cerf and Kahn [CERV74]. Over the years, DARPA has supported specifications of several versions of this protocol, the last one appeared in [POSJ81]. Some issues in the connection management of this protocol are discussed in [SUNC78].
TCPはサーフとカーン[CERV74]が議論したプロトコルに一部基づいています。 数年間、DARPAはこのプロトコルのいくつかのバージョンの仕様をサポートしていて、最後のものは[POSJ81]に現れました。 [SUNC78]でこのプロトコルの接続管理におけるいくつかの問題について議論します。
A few years ago, DCA decided to standardize TCP for use in DoD networks and supported formal specification of this protocol following the design of this protocol discussed in [POSJ81]. A detailed specification of this protocol given in [MILS83] has been adopted as the DoD standard for the Transmission Control Protocol, a reliable connection-oriented transport protocol for DoD networks.
数年前に、[POSJ81]で議論したこのプロトコルのデザインに従って、DCAはDoDネットワークにおける使用のためにTCPを標準化すると決めて、このプロトコルに関する形式仕様をサポートしました。 [MILS83]で与えられているこのプロトコルの仕様詳細は通信制御プロトコル(DoDネットワークにおいて、信頼できる接続指向のトランスポート・プロトコル)のDoD規格として採用されました。
A TCP connection progresses through three phases: opening (or
TCP接続は三相を通して進歩をします: または始まり、(。
Sidhu & Blumer [Page 2]
Sidhu&Blumer[2ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
synchronization), maintenance, and closing. In this note we consider data transfer in the opening and maintenance phases of the connection.
同期)、メインテナンス、および閉鎖。 この注意では、私たちは接続の始まりと維持相におけるデータ転送を考えます。
3. Problems with MIL Standard TCP
3. ミルの標準のTCPに関する問題
One basic feature of TCP is the three-way handshake which is used to set up a properly synchronized connection between two remote TCP entities. This mechanism is incorrectly specified in the current specification of TCP. One problem is that data associated with the SYN packet can not be delivered. This results from an incorrect specification of the interaction between the accept_policy action procedure and the record_syn action procedure. Neither of the 2 possible strategies suggested in accept_policy will give the correct result when called from the record_syn procedure, because the recv_next variable is updated in record_syn before the accept_policy procedure is called.
TCPに関する1つの基本的特徴が2つのリモートTCP実体の間の適切に連動している関係をセットアップするのに使用される3方向ハンドシェイクです。 このメカニズムはTCPの現在の仕様で不当に指定されます。 1つの問題はSYNパケットに関連しているデータを提供できないということです。 これが間に相互作用の不正確な仕様から生じる、_政策的措置手順と記録_syn動作手順を受け入れてください。 記録_syn手順から呼ばれる場合、中に示された戦略が_方針を受け入れるのが可能な2つのもののどちらも正しい結果を与えないでしょう、以前記録_synでrecv_次変数をアップデートするので方針手順が呼ばれる_を受け入れてください。
Another problem with the specification of the three-way handshake is apparent in the actions listed for the Active Open event (with or without data) when in the CLOSED state. No retransmission timer is set in these actions, and therefore if the initial SYN is lost, there will be no timer expiration to trigger retransmission. This will prevent connection establishment if the initial SYN packet is lost by the network.
CLOSED状態にあるとき、3方向ハンドシェイクの仕様に関する別の問題はActiveオープンイベント(データのあるなしにかかわらず)のために記載された動作で明らかです。 再送信タイマーは全くこれらの動作で設定されません、そして、したがって、初期のSYNが無くなると、「再-トランスミッション」の引き金となるタイマ満了が全くないでしょう。 初期のSYNパケットがネットワークによって失われていると、これはコネクション確立を防ぐでしょう。
The third problem with the specification is that the actions for receiving data in the ESTAB state are incorrect. The accept action procedure must be called when data is received, so that arriving data may be queued and possibly passed to the user.
仕様に関する3番目の問題はESTAB状態にデータを受け取るための動作が不正確であるということです。 動作手順がデータが受信されているとき、到着データを列に並ばせることができるように呼ばなければならなくて、ことによるとユーザに渡されると受け入れてください。
A general problem with this specification is that the program language and action table portions of the specification were clearly not checked by any automatic syntax checking process. Several variable and procedure names are misspelled, and the syntax of the action statements is often incorrect. This can be confusing, especially when a procedure name cannot be found in the alphabetized list of procedures because of misspelling.
この仕様に関する一般的問題は仕様のプログラム言語と動作テーブル部分がどんな自動構文照合プロセスによっても明確にチェックされなかったということです。 いくつかの変数とプロシージャ名がスペルミスされます、そして、アクション文の構文はしばしば不正確です。 これは混乱させられることができます、特にスペルミスのために手順のアルファベット順にされたリストでプロシージャ名を見つけることができないとき。
These are some of the very serious errors that we have discovered with the MIL standard TCP.
これらは私たちがMILの標準のTCPと共に発見した非常に重大な誤りのいくつかです。
Sidhu & Blumer [Page 3]
Sidhu&Blumer[3ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
4. Detailed Discussion of the Problem
4. 問題の詳細な論議
Problem 1: Problem with Receiving Data Accompanying SYN
問題1: データの付随のSYNを受けることに関する問題
The following scenario traces the actions of 2 communicating
entities during the establishment of a connection. Only the
simplest case is considered, i.e., the case where the connection
is established by the exchange of 3 segments.
以下のシナリオは接続の設立の間に実体を伝える2の動作をたどります。 すなわち、最も簡単なケースは考えられるだけです。接続が3つのセグメントの交換で確立されるケース。
TCP entity A TCP entity B
------------ ------------
TCP実体A TCP実体B------------ ------------
state segment segment state
transition recvd or sent recvd or sent transition
by A by B
BによるAによる州のセグメントセグメント状態遷移recvd、送られたrecvdまたは送られた変遷
CLOSED -> LISTEN
閉じている->は聴かれます。
CLOSED -> SYN_SENT SYN -->
SYN_がSYNを送った閉じている->-->。
SYN --> LISTEN -> SYN_RECVD
<-- SYN ACK
SYN-->は->SYN_RECVD<を聴きます--、SYN ACK
SYN_SENT -> ESTAB <-- SYN ACK
ACK -->
SYN_は->ESTAB<--SYN ACK ACK-->を送りました。
ACK --> SYN_RECVD -> ESTAB
ACK-->SYN_RECVD->ESTAB
As shown in the above diagram, 5 state transitions occur and 3 TCP
segments are exchanged during the simplest case of the three-way
handshake. We now examine in detail the actions of each entity
during this exchange. Special attention is given to the sequence
numbers carried in each packet and recorded in the state variables
of each entity.
上のダイヤグラムで示されるように、5つの状態遷移が起こります、そして、3方向ハンドシェイクの最も簡単なケースの間、3つのTCPセグメントを交換します。 私たちは現在、この交換の間、詳細にそれぞれの実体の動作を調べます。 各パケットで運ばれて、それぞれの実体の州の変数に記録された一連番号に特別な注意を与えます。
In the diagram below, the actions occurring within a procedure are
shown indented from the procedure call. The resulting values of
sequence number variables are shown in square brackets to the
right of each statement. The sequence number variables are shown
with the entity name (A or B) as prefix so that the two sets of
state variables may be easily distinguished.
以下のダイヤグラムで、手順の中に起こる動作は手順呼び出しから入り込まれた状態で示されます。 一連番号変数の結果として起こる値はそれぞれの声明の右への角括弧で示されます。 一連番号変数は、容易に2セットの州の変数を区別できるように接頭語として実体名(AかB)で示されます。
Sidhu & Blumer [Page 4]
Sidhu&Blumer[4ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
Transition 1 (entity B goes from state CLOSED to state LISTEN).
The user associated with entity B issues a Passive Open.
変遷1(実体BはLISTENを述べに州のCLOSEDから行きます)。 実体Bに関連しているユーザはPassiveオープンを発行します。
Actions: (see p. 104)
open; (see p. 144)
new state := LISTEN;
動作: (pを見てください。 104) 開いてください。 (pを見てください。 144) 新しい州の:=LISTEN。
Transition 2 (entity A goes from state CLOSED to SYN_SENT). The
user associated with entity A issues an Active Open with Data.
変遷2(実体Aは州のCLOSEDからSYN_SENTまで行きます)。 実体Aに関連しているユーザはDataとのActiveオープンを発行します。
Actions: (see p. 104)
open; (see p. 144)
gen_syn(WITH_DATA); (see p. 141)
send_isn := gen_isn(); [A.send_isn = 100]
send_next := send_isn + 1; [A.send_next = 101]
send_una := send_isn; [A.send_una = 100]
seg.seq_num := send_isn; [seg.seq_num = 100]
seg.ack_flag := FALSE; [seg.ack_flag = FALSE]
seg.wndw := 0; [seg.wndw = 0]
amount := send_policy() [assume amount > 0]
new state := SYN_SENT;
動作: (pを見てください。 104) 開いてください。 (pを見てください。 144) _syn(_データがある)に情報を得てください。 (pを見てください。 141) _:=が情報を得るisnに_isnを送ってください。(); [A.は_isn=100を送ります] 次の:=が_isn+1を送る_を送ってください。 [A.は_次の=101を送ります] _:=が_isnを送るunaを送ってください。 [A.は_una=100を送ります] seg.seq_num:=は_isnを送ります。 [seg.seq_num=100] seg.ack_旗の:=FALSE。 [seg.ack_旗=FALSE] seg.wndw:=0。 [seg.wndw=0] 量の:=は_方針()[量が>0であると仮定します]の新しい州の:=SYN_SENTを送ります。
Sidhu & Blumer [Page 5]
Sidhu&Blumer[5ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
Transition 3 (Entity B goes from state LISTEN to state SYN_RECVD).
Entity B receives the SYN segment accompanying data sent by entity
A.
変遷3(実体BはSYN_RECVDを述べに州のLISTENから行きます)。 実体Bは実体Aによって送られたSYNのセグメントの付随のデータを受け取ります。
Actions: (see p. 106)
(since this segment has no RESET, no ACK, does have SYN, and
we assume reasonable security and precedence parameters, row
3 of the table applies)
record_syn; (see p. 147)
recv_isn := seg.seq_num; [B.recv_isn = seg_seq_num = 100]
recv_next := recv_isn + 1; [B.recv_next = 101]
if seg.ack_flag then
send_una := seg.ack_num; [no change]
accept_policy; (see p. 131)
Accept in-order data only:
Acceptance Test is
seg.seq_num = recv_next;
Accept any data within the receive window:
Acceptance Test has two parts
recv_next =< seg.seq_num =< recv_next +
recv_wndw
or
recv_next =< seg.seq_num + length =<
recv_next + recv_wndw
********************************************
An error occurs here, with either possible
strategy given in accept_policy, because
recv_next > seg.seq_num. Therefore
accept_policy will incorrectly indicate that
the data cannot be accepted.
********************************************
gen_syn(WITH_ACK); (see p. 141)
send_isn := gen_isn(); [B.send_isn = 300]
send_next := send_isn + 1; [B.send_next = 301]
send_una := send_isn; [B.send_una = 300]
seg.seq_num := send_next; [seg.seq_num = 301]
seg.ack_flag := TRUE; [seg.ack_flag = TRUE]
seg.ack_num := recv_isn + 1; [seg.ack_num = 102]
new state := SYN_RECVD;
動作: (pを見てください。 106) (手頃なセキュリティと先行がパラメタであるといいえがRESET、どんなACKもしないこのセグメントでSYNを持って、私たちが、思うので、テーブルの行3は適用されます) _synを記録してください。 (pを見てください。 147) recv_isn:=seg.seq_num。 [B.recv_isnはseg_seq_num=100と等しいです] recv次の_:=recv_isn+1つ。 [次のB.recv_=101] seg.ack_旗であるなら、_una:=seg.ack_numを送ってください。 [変化がありません] _方針を受け入れてください。 (pを見てください。 131) オーダーにおけるデータだけを受け入れてください: 承認Testは次のrecv seg.seq_num=_です。 どんなデータも受け入れる、窓を受けてください: Acceptance Test has two parts recv_next =< seg.seq_num =< recv_next + recv_wndw or recv_next =< seg.seq_num + length =< recv_next + recv_wndw ******************************************** An error occurs here, with either possible strategy given in accept_policy, because recv_next > seg.seq_num. したがって、受け入れた状態で方針が不当に示すデータがあるはずがない_を受け入れてください。 ******************************************** _syn(_ACKと)に情報を得てください。 (pを見てください。 141) _:=が情報を得るisnに_isnを送ってください。(); [B.は_isn=300を送ります] 次の:=が_isn+1を送る_を送ってください。 [B.は_次の=301を送ります] _:=が_isnを送るunaを送ってください。 [B.は_una=300を送ります] seg.seq_num:=は_次に、発信します。 [seg.seq_num=301] seg.ack_旗の:=TRUE。 [seg.ack_旗=TRUE] seg.ack_num:=recv_isn+1。 [seg.ack_num=102] 新しい州の:=SYN_RECVD。
Sidhu & Blumer [Page 6]
Sidhu&Blumer[6ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
Transition 4 (entity A goes from state SYN_SENT to ESTAB) Entity A
receives the SYN ACK sent by entity B.
変遷4(実体Aは州のSYN_SENTからESTABまで行きます)実体Aは実体Bによって送られたSYN ACKを受けます。
Actions: (see p. 107)
In order to select the applicable row of the table on p.
107, we first evaluate the decision function
ACK_status_test1.
ACK_status_test1();
if(seg.ack_flag = FALSE) then
return(NONE);
if(seg.ack_num <= send_una) or
(seg.ack_num > send_next) then
return(INVALID)
else
return(VALID);
動作: (pを見てください。 107) 適切を選択するには、pをテーブルを船をこいで運んでください。 107、私たち1第人は_決定関数ACK_状態test1を評価します。 _ACK_状態test1(); (seg.ack_旗=FALSE)であるなら、(NONE)を返してください。 (=が_unaを送るseg.ack_num<)か次に、(seg.ack_num>は_次に、発信します)リターン(INVALID)であるなら、ほかに、戻ってください(VALID)。
... and so on.
… など。
The important thing to notice in the above scenario is the error
that occurs in transition 3, where the wrong value for recv_next
leads to the routine record_syn refusing to accept the data.
上のシナリオで気付く重要なものは変遷3で発生する誤りです、recv_のための次の間違った値がデータを受け入れるのを拒否する通常の記録_synに通じるところで。
Problem 2: Problem with Retransmission of SYN Packet
問題2: SYNパケットのRetransmissionに関する問題
The actions listed for Active Open (with or without data; see p.
103) are calls to the routines open and gen_syn. Neither of these
routines (or routines that they call) explicitly sets a
retransmission timer. Therefore if the initial SYN is lost there
is no timer expiration to trigger retransmission of the SYN. If
this happens, the TCP will fail in its attempt to establish the
desired connection with a remote TCP.
Activeオープンに記載された動作(データのあるなしにかかわらず。 pを見てください。 103) ルーチンへの呼び出しは開いています、そして、_synに情報を得てください。 これらのルーチン(または、彼らが呼ぶルーチン)のどちらも明らかに再送信タイマーを設定しません。 したがって、初期のSYNが無くなるなら、SYNの「再-トランスミッション」の引き金となるように、タイマ満了は全くありません。 これが起こると、TCPはリモートTCPとの必要な接続を確立する試みに失敗するでしょう。
Note that this differs with the actions specified for transmission
of data from the ESTAB state. In that transition the routine
dispatch (p. 137) is called first which in turn calls the routine
send_new_data (p. 156). One of actions of the last routine is to
start a retransmission timer for the newly sent data.
動作がESTAB状態からのデータの伝達に指定されている状態でこれが異なることに注意してください。 ルーチンが派遣する変遷(p.137)が順番にルーチンを呼び出す1番目と呼ばれるので、_新しい_データ(p.156)を送ってください。 最後のルーチンの動作の1つは新たに送られたデータのために再送信タイマーを始動することです。
Sidhu & Blumer [Page 7]
Sidhu&Blumer[7ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
Problem 3: Problem with Receiving Data in TCP ESTAB State
問題3: TCP ESTAB状態にデータを受け取ることに関する問題
When both entities are in the state ESTAB, and one sends data to
the other, an error in the actions of the receiver prohibits the
data from being accepted. The following simple scenario
illustrates the problem. Here the user associated with entity A
issues a Send request, and A sends data to entity B. When B
receives the data it replies with an acknowledgment.
両方の実体が州のESTABにあって、1つがデータをもう片方に送るとき、受信機の運動における誤りは受け入れるのからデータを禁じます。 以下の簡単なシナリオは問題を例証します。 ここに、AがSend要求を出して、Aが実体B.When Bへのデータを送る実体に関連しているユーザはそれが承認で返答するデータを受け取ります。
TCP entity A TCP entity B
------------ ------------
TCP実体A TCP実体B------------ ------------
state segment segment state
transition recvd or sent recvd or sent transition
by A by B
BによるAによる州のセグメントセグメント状態遷移recvd、送られたrecvdまたは送られた変遷
ESTAB -> ESTAB DATA -->
ESTAB->ESTABデータ-->。
DATA --> ESTAB -> ESTAB
<-- ACK
データ-->ESTAB->ESTAB<--ACK
Transition 1 (entity A goes from state ESTAB to ESTAB) Entity A
sends data packet to entity B.
変遷1(実体Aは州のESTABからESTABまで行きます)実体Aは実体Bにデータ・パケットを送ります。
Actions: (see p. 110)
dispatch; (see p. 137)
動作: (pを見てください。 110) 急いでください。 (pを見てください。 137)
Transition 2 (entity B goes from state ESTAB to ESTAB) Entity B
receives data packet from entity B.
変遷2(実体Bは州のESTABからESTABまで行きます)実体Bは実体Bからデータ・パケットを受けます。
Actions: (see p. 111)
Assuming the data is in order and valid, we use row 6 of the
table.
update; (see p. 159)
************************************************************
An error occurs here, because the routine update does
nothing to accept the incoming data, or to arrange to
pass it on to the user.
************************************************************
動作: (pを見てください。 111) データが整然として有効であると仮定して、私たちがテーブルの行6を使用する、アップデート。 (pを見てください。 159) ************************************************************ 誤りはここに発生します、通常のアップデートが受信データを受け入れるか、またはそれをユーザに渡すように手配するようなことを何もしないので。 ************************************************************
Sidhu & Blumer [Page 8]
Sidhu&Blumer[8ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
5. Solutions to Problems
5. 問題の解決
The problem with record_syn and accept_policy can be solved by having record_syn call accept_policy before the variable recv_next is updated.
記録的な_に関する問題は、可変recv_次をアップデートする前に記録_syn呼び出しに_方針を受け入れさせながら方針を解決できる_をsynして、受け入れます。
The problem with gen_syn can be corrected by having gen_syn or open explicitly request the retransmission timer.
問題、情報を得させるsynが_synに直る場合がある_に情報を得てください。さもないと、戸外は明らかに再送信タイマーを要求します。
The problem with the reception of data in the ESTAB state is apparently caused by the transposition of the action tables on pages 111 and 112. These tables should be interchanged. This solution will also correct a related problem, namely that an entity can never reach the CLOSE_WAIT state from the ESTAB state.
ESTAB状態のデータのレセプションに関する問題は111と112ページにおける動作テーブルの転置で明らかに引き起こされます。 これらのテーブルは交換されるべきです。 また、このソリューションはすなわち、実体がESTAB状態からCLOSE_WAIT状態に決して達することができないという関連する問題を修正するでしょう。
Syntax errors in the action statements and tables could be easily caught by an automatic syntax checker if the document used a more formal description technique. This would be difficult to do for [MILS83] since this document is not based on a formalized description technique [BREM83].
ドキュメントが、より正式な記述手法を使用するなら、自動シンタクスチェッカは容易にアクション文とテーブルの構文エラーを捕らえることができるでしょうに。 このドキュメントが正式にされた記述手法[BREM83]に基づいていないので、これは[MILS83]のためにするのは難しいでしょう。
The errors pointed out in this note have been submitted to DCA and will be corrected in the next update of the MIL STD TCP specification.
この注意で指摘された誤りを、DCAに提出して、MIL STD TCP仕様の次のアップデートで修正するでしょう。
6. Implementation of MIL Standard TCP
6. ミルの標準のTCPの実装
In the discussion above, we pointed out several serious errors in the specification of the Military Standard Transmission Control Protocol [MILS83]. These errors imply that a TCP implementation that faithfully conforms to the Military TCP standard will not be able to
議論では、上では、私たちがMilitary Standard通信制御プロトコル[MILS83]の仕様に基づくいくつかの重大な誤りを指摘しました。 これらの誤りは、Military TCP規格に忠実に従うTCP実装がないためにできた状態で望んでいるのを含意します。
Receive data sent with a SYN packet.
受信データはSYNパケットと共に発信しました。
Establish a connection if the initial SYN packet is lost.
初期のSYNパケットが無くなるなら、取引関係を築いてください。
Receive data when in the ESTAB state.
ESTAB状態にあるときには、データを受け取ってください。
It also follows from our discussion that an implementation of MIL Standard TCP [MILS83] must include corrections mentioned above to get a running TCP.
また、私たちの議論から、実行しているTCPを手に入れるのが、MIL Standard TCP[MILS83]の実装が前記のように修正を含まなければならないのに続きます。
The problems pointed out in this paper with the current specification of the MIL Standard TCP [MILS83] are based on an initial investigation of this protocol standard by the authors.
この紙でMIL Standard TCP[MILS83]の現在の仕様で指摘された問題は作者によるこのプロトコル標準の初期の調査に基づいています。
Sidhu & Blumer [Page 9]
Sidhu&Blumer[9ページ]
RFC 964 November 1985 Some Problems with MIL-STD TCP
RFC964 1985年11月 軍規格TCPに関するいくつかの問題
REFERENCES
参照
[BLUT83] Blumer, T. P., and Sidhu, D. P., "Mechanical Verification
and Automatic Implementation of Authentication Protocols
for Computer Networks", SDC Burroughs Report (1983),
submitted for publication.
[BLUT83] 「コンピュータネットワークのための認証プロトコルの機械的な検証と自動実装」(SDCバローズReport(1983))が公表のために提出したBlumer、T.P.、およびSidhu、D.P.。
[BLUT82] Blumer, T. P., and Tenney, R. L., "A Formal Specification
Technique and Implementation Method for Protocols",
Computer Networks, Vol. 6, No. 3, July 1982, pp. 201-217.
[BLUT82] Blumer、T.P.、テニイ、R.L.、および「プロトコルのためのA形式仕様のテクニックと実装メソッド」、コンピュータNetworks、Vol.6、No.3、1982年7月、ページ 201-217.
[BREM83] Breslin, M., Pollack, R. and Sidhu D. P., "Formalization of
DoD Protocol Specification Technique", SDC - Burroughs
Report 1983.
[BREM83]ブレズリン、M.、セイス、R.、およびSidhu D.P.、「DoDプロトコル仕様のテクニックの形式化」、SDC--バローズは1983を報告します。
[CERV74] Cerf, V., and Kahn, R., "A Protocol for Packet Network
Interconnection", IEEE Trans. Comm., May 1974.
[CERV74]サーフ、V.とカーン、R.、「パケット網インタコネクトのためのプロトコル」IEEE、移- Comm、5月1974日
[MILS83] "Military Standard Transmission Control Protocol",
MIL-STD-1778, 12 August 1983.
[MILS83]「軍事の標準の通信制御プロトコル」、軍規格-1778、1983年8月12日。
[POSJ81] Postel, J. (ed.), "DoD Standard Transmission Control
Protocol", Defense Advanced Research Projects Agency,
Information Processing Techniques Office, RFC-793,
September 1981.
[POSJ81]ポステル、J.編、「DoDの標準の通信制御プロトコル」、ディフェンス先端研究は政府機関を映し出します、情報処理テクニックオフィス、RFC-793、1981年9月。
[SIDD83] Sidhu, D. P., and Blumer, T. P., "Verification of NBS Class
4 Transport Protocol", SDC Burroughs Report (1983),
submitted for publication.
[SIDD83] Sidhu、D.P.、およびBlumer、T.P.、「NBSのクラス4トランスポート・プロトコルの検証」、SDCバローズReport(1983)は公表のために提出しました。
[SUNC78] Sunshine, C., and Dalal, Y., "Connection Management in
Transport Protocols", Computer Networks, Vol. 2, pp.454-473
(1978).
[SUNC78]日光、C.とDalal、Y.、「トランスポート・プロトコルにおける接続管理」コンピュータNetworks、Vol.2、pp.454-473(1978)。
Sidhu & Blumer [Page 10]
Sidhu&Blumer[10ページ]
一覧
スポンサーリンク
