RFC963 日本語訳
0963 Some problems with the specification of the Military StandardInternet Protocol. D.P. Sidhu. November 1985. (Format: TXT=44019 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Deepinder P. Sidhu
Request for Comments: 963 Iowa State University
November 1985
Sidhuがコメントのために要求するワーキンググループDeepinder P.をネットワークでつないでください: 963 アイオワ州立大学1985年11月
SOME PROBLEMS WITH THE SPECIFICATION OF THE
MILITARY STANDARD INTERNET PROTOCOL
軍事の標準のインターネットプロトコルの仕様に関するいくつかの問題
STATUS OF THIS MEMO
このメモの状態
The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol standard. Distribution of this note is unlimited.
このRFCの目的は1つがこのプロトコル標準の信頼できる実現を得ることができるようにMilitary Standardインターネットプロトコル(軍規格-1777)に関する役立つ情報を提供することです。 この注意の分配は無制限です。
ABSTRACT
要約
This paper points out several significant problems in the specification of the Military Standard Internet Protocol (MIL-STD-1777, dated August 1983 [MILS83a]). These results are based on an initial investigation of this protocol standard. The problems are: (1) a failure to reassemble fragmented messages completely; (2) a missing state transition; (3) errors in testing for reassembly completion; (4) errors in computing fragment sizes; (5) minor errors in message reassembly; (6) incorrectly computed length for certain datagrams. This note also proposes solutions to these problems.
この論文はMilitary Standardインターネットプロトコル(時代遅れの1983[MILS83a]年8月の軍規格-1777)の仕様によるいくつかの重大な問題を指摘します。 これらの結果はこのプロトコル標準の初期の調査に基づいています。 問題は以下の通りです。 (1) 完全に断片化しているメッセージを組み立て直すというわけではないこと。 (2) なくなった状態遷移。 (3) 再アセンブリ完成がないかどうかテストすることにおける誤り。 (4) コンピューティングにおける誤りはサイズを断片化します。 (5) メッセージにおける軽い過失は再アセンブリされます。 (6) また、あるデータグラムこの注意のための不当に計算された長さはこれらの問題の解決を提案します。
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. Examples of automated verification and implementation of several real world protocols are discussed in [BLUT82] [BLUT83] [SIDD83] [SIDD84].
近年、多くの進歩が展開している信頼できる通信プロトコルのための統合セットのツールを作成する際に見られました。 これらのツールはプロトコルの仕様、検証、実現、およびテストにおける支援を提供します。 そのようなツールを使用することでいくつかのプロトコルを、分析されて、開発してあります。 [BLUT82][BLUT83][SIDD83][SIDD84]で自動化された検証に関する例といくつかの本当の世界プロトコルの実現について議論します。
We are currently working on the automatic implementation of the Military Standard Internet Protocol (IP). This analysis will be based on the published specification [MILS83a] of IP dated 12 August 1983.
私たちは現在、Military Standardインターネットプロトコル(IP)の自動実現に取り組んでいます。 この分析は1983年8月12日が日付を入れられたIPの広められた仕様[MILS83a]に基づくでしょう。
While studying the MIL Standard IP specification, we have noticed numerous errors in the specification of this protocol. One consequence of these errors is that the protocol will never deliver fragmented incoming datagrams; if this error is corrected, such datagrams will be missing some data and their lengths will be incorrectly reported. In addition, outgoing datagrams that are divided into fragments will be missing some data. The proof of these statements follows from the specification of IP [MILS83a] as discussed below.
MIL Standard IP仕様を研究している間、私たちはこのプロトコルの仕様で頻繁な誤りに気付いています。 これらの誤りの1つの結果はプロトコルが断片化している受信データグラムを決して届けないということです。 この誤りが直ると、そのようなデータグラムはいくつかのデータを逃すでしょう、そして、それらの長さは不当に報告されるでしょう。 さらに、断片に分割される発信データグラムはいくつかのデータを逃すでしょう。 これらの声明の証拠は以下で議論するようにIP[MILS83a]の仕様から従います。
Sidhu [Page 1]
Sidhu[1ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
2. Internet Protocol
2. インターネットプロトコル
The Internet Protocol (IP) is a network layer protocol in the DoD protocol hierarchy which provides communication across interconnected packet-switched networks in an internetwork environment. IP provides a pure datagram service with no mechanism for reliability, flow control, sequencing, etc. Instead, these features are provided by a connection-oriented protocol, DoD Transmission Control Protocol (TCP) [MILS83b], which is implemented in the layer above IP. TCP is designed to operate successfully over channels that are inherently unreliable, i.e., which can lose, damage, duplicate, and reorder packets.
インターネットプロトコル(IP)はインタコネクトされたパケット交換網の向こう側にインターネットワーク環境にコミュニケーションを提供するDoDプロトコル階層のネットワーク層プロトコルです。 IPは信頼性、フロー制御、配列などのためにメカニズムを全く純粋なデータグラムサービスに提供しません。 代わりに、これらの特徴は接続指向のプロトコル、IPの上の層の中で実行されるDoD通信制御プロトコル(TCP)[MILS83b]によって提供されます。 TCPは、本来頼り無いチャンネル、すなわち、どれが損をする場合があるか、そして、損害、写し、および追加注文パケットの上で首尾よく作動するように設計されています。
Over the years, DARPA has supported specifications of several versions of IP; the last one appeared in [POSJ81]. A few years ago, the Defense Communications Agency decided to standardize IP for use in DoD networks. For this purpose, the DCA supported formal specification of this protocol, following the design discussed in [POSJ81] and the technique and organization defined in [SDC82]. A detailed specification of this protocol, given in [MILS83a], has been adopted as the DoD standard for the Internet Protocol.
数年間、DARPAはIPのいくつかのバージョンの仕様を支持しています。 最後のものは[POSJ81]に現れました。 数年前に、Defense Communications Agencyは、DoDネットワークにおける使用のためにIPを標準化すると決めました。 このために、DCAはこのプロトコルに関する形式仕様を支持しました、[SDC82]で定義された[POSJ81]で議論したデザイン、テクニック、および組織に従って。 [MILS83a]で与えられているこのプロトコルの仕様詳細はインターネットプロトコルのDoD規格として採用されました。
The specification of IP state transitions is organized into decision tables; the decision functions and action procedures are specified in a subset of Ada[1], and may employ a set of machine-specific data structures. Decision tables are supplied for the pairs <state name, interface event> as follows: <inactive, send from upper layer>, <inactive, receive from lower layer>, and <reassembling, receive from lower layer>. To provide an error indication in the case that some fragments of a datagram are received but some are missing, a decision table is also supplied for the pair <reassembling, reassembly time limit elapsed>. (The event names are English descriptions and not the names employed by [MILS83a].)
IP状態遷移の仕様は決定表に組織化されます。 決定関数と動作手順は、Ada[1]の部分集合で指定されて、1セットのマシン特有のデータ構造を使うかもしれません。 組<州の名、以下のインタフェースイベント>に決定表を供給します: <不活発であることで、上側の層の>、<から不活発な状態で発信してください、そして、下側の層の>から受信してください、そして、<が組み立て直されて、下側の層の>から受信してください。 また、データグラムのいくつかの断片が受け取られていますが、或るものがなくなって、誤り表示を提供するために、組<の組み立て直すこと(再アセンブリタイムリミットの経過した>)に決定表を供給します。 (イベント名は名前ではなく、[MILS83a]によって使われたイギリスの記述です。)
3. Problems with MIL Standard IP
3. ミルの標準のIPに関する問題
One of the major functions of IP is the fragmentation of datagrams that cannot be transmitted over a subnetwork in one piece, and their subsequent reassembly. The specification has several problems in this area. One of the most significant is the failure to insert the last fragment of an incoming datagram; this would cause datagrams to be delivered to the upper-level protocol (ULP) with some data missing. Another error in this area is that an incorrect value of the data length for reassembled datagrams is passed to the ULP, with unpredictable consequences.
IPの主要な機能の1つは無事にサブネットワークの上に送ることができないデータグラム、およびそれらのその後の再アセンブリの断片化です。 仕様はこの領域にいくつかの問題を持っています。 最も重要なものの1つは受信データグラムの最後の断片を挿入しないことです。 これで、いくつかのデータがなくなっている上側のレベルプロトコル(ULP)にデータグラムを届けるでしょう。 この領域の別の誤りは組み立て直されたデータグラムのためのデータの長さの不正確な値がULPに通過されるということです、予測できない結果で。
As the specification [MILS83a] is now written, these errors are of
仕様[MILS83a]が現在書かれるとき、これらの誤りは書かれます。
Sidhu [Page 2]
Sidhu[2ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
little consequence, since the test for reassembly completion will always fail, with the result that reassembled datagrams would never be delivered at all.
小さい結果、再アセンブリ完成のためのテストがいつも失敗するので、その結果、組み立て直されたデータグラムを全く決して届けません。
In addition, a missing row in one of the decision tables creates the problem that network control (ICMP) messages that arrive in fragments will never be processed. Among the other errors are the possibility that a few bytes will be discarded from each fragment transmitted and certain statements that will create run-time exceptions instead of performing their intended functions.
さらに、決定表の1つのなくなった列は到着するネットワーク制御(ICMP)メッセージが断片となって決して処理されないという問題を生じさせます。 他の誤りの中に、数バイトが伝えられた各断片から捨てられる可能性とそれらの意図している機能を実行することの代わりにランタイム例外を作成するある声明があります。
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. Variable and procedure names are occasionally misspelled, and the syntax of the action statements is often incorrect. We have enumerated some of these problems below as a set of cautionary notes to implementors, but we do not claim to have listed them all. In particular, syntax errors are only discussed when they occur in conjunction with other problems.
この仕様に関する一般的問題は仕様のプログラム言語と動作テーブル部分が過程をチェックするどんな自動構文でも明確にチェックされなかったということです。 変数とプロシージャ名は時折スペルミスされます、そして、アクション文の構文はしばしば不正確です。 1セットの警告的な注意として以下のこれらの問題のいくつかを作成者に列挙しましたが、私たちは、彼らを皆、記載したと主張しません。 他の問題に関連して起こるときだけ、特に、構文エラーについて議論します。
The following section discusses some of the serious errors that we have discovered with the MIL standard IP [MIL83a] during our initial study of this protocol. We also propose corrections to each of these problems.
以下のセクションは私たちが私たちのこのプロトコルの初期の研究の間にMILの標準のIP[MIL83a]と共に発見している重大な誤りのいくつかについて論じます。 また、私たちはそれぞれのこれらの問題に修正を提案します。
4. Detailed Discussion of the Problems
4. 問題の詳細な論議
Problem 1: Failure to Insert Last Fragment
問題1: 最後の断片を挿入しないこと
This problem occurs in the decision table corresponding to the
state reassembling and the input "receive from lower layer"
[MILS83a, sec 9.4.6.1.3]. The problem occurs in the following row
of this table:[2]
この問題が州の組み立て直すのに対応する決定表と「下層から、受信する」という入力に起こる、[MILS83a、秒、9.4 .6 .1 .3]。 問題はこのテーブルの以下の列に起こります:[2]
________________________________________________________
check- SNP TTL where a reass ICMP
sum params valid to frag done check-
valid? valid? ? ? ? ? sum?
__________________________________________________________________
YES YES YES ULP YES YES d reass_
delivery;
state :=
INACTIVE
__________________________________________________________________
________________________________________________________ していた状態で破片手榴弾で殺傷するために有効なreass ICMP合計paramsが有効な状態でチェックするチェックSNP TTL--有効ですか? ? ? ? ? 合計? __________________________________________________________________ YES YES YES ULP YES YES d reass_配送。 州の:=INACTIVE__________________________________________________________________
The reass_done function, as will be seen below, returns YES if the
以下の機能が見られるように行われたreass_ははいを返します。
Sidhu [Page 3]
Sidhu[3ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
fragment just received is the last fragment needed to assemble a
complete datagram and NO otherwise. The action procedure
reass_delivery simply delivers a completely reassembled datagram
to the upper-level protocol. It is the action procedure
reassemble that inserts an incoming fragment into the datagram
being assembled. Since this row does not call reassemble, the
result will be that every incoming fragmented datagram will be
delivered to the upper layer with one fragment missing. The
solution is to rewrite this row of the table as follows:
ただ受け取られた断片はそうでなければ、完全なデータグラムとノー、を組み立てるのが必要である最後の断片です。 動作手順reass_配送は単に完全に組み立て直されたデータグラムを上側のレベルプロトコルに届けます。 組み立てられて、入って来る断片をデータグラムに挿入する動作手順が組み立て直されるということです。 この列が呼ばないので、組み立て直してください、そして、結果は1個の断片がなくなっていた状態であらゆる入って来る断片化しているデータグラムを上側の層に渡すということでしょう。 解決策は以下のテーブルのこの列を書き直すことです:
________________________________________________________
check- SNP TTL where a reass ICMP
sum params valid to frag done check-
valid? valid? ? ? ? ? sum?
__________________________________________________________________
YES YES YES ULP YES YES d reassemble;
reass_
delivery;
state :=
INACTIVE
__________________________________________________________________
________________________________________________________ していた状態で破片手榴弾で殺傷するために有効なreass ICMP合計paramsが有効な状態でチェックするチェックSNP TTL--有効ですか? ? ? ? ? 合計? __________________________________________________________________ YES YES YES ULP YES YES dは組み立て直します。 reass_配送。 州の:=INACTIVE__________________________________________________________________
Incidentally, the mnemonic value of the name of the reass_done
function is questionable, since at the moment this function is
called datagram reassembly cannot possibly have been completed. A
better name for this function might be last_fragment.
ところで、機能が行われたreass_の名前の簡略記憶値は疑わしいです、再アセンブリがこの機能がデータグラムと呼ばれる瞬間に完成したはずがないので。 この機能のための、より良い名前は最後の_断片であるかもしれません。
Problem 2: Missing State Transition
問題2: なくなった状態遷移
This problem is the omission of a row of the same decision table
[MILS83a, sec 9.4.6.1.3]. Incoming packets may be directed to an
upper-level protocol (ULP), or they may be network control
messages, which are marked ICMP (Internet Control Message
Protocol). When control messages have been completely assembled,
they are processed by an IP procedure called analyze. The
decision table contains the row
この問題が同じ決定表の列の省略である、[MILS83a、秒、9.4 .6 .1 .3]。 入って来るパケットは上側のレベルプロトコル(ULP)に向けられるかもしれませんか、それらがネットワーク制御メッセージであるかもしれません。(そのメッセージはICMP(インターネット・コントロール・メッセージ・プロトコル)であるとマークされます)。 コントロールメッセージが完全に組み立てられたとき、それらは呼ばれるIP手順で処理されます。分析します。 決定表は列を含んでいます。
________________________________________________________
check- SNP TTL where a reass ICMP
sum params valid to frag done check-
valid? valid? ? ? ? ? sum?
__________________________________________________________________
YES YES YES ICMP YES NO d reassemble;
__________________________________________________________________
________________________________________________________ していた状態で破片手榴弾で殺傷するために有効なreass ICMP合計paramsが有効な状態でチェックするチェックSNP TTL--有効ですか? ? ? ? ? 合計? __________________________________________________________________ YES YES YES ICMP YES NO dは組み立て直します。 __________________________________________________________________
Sidhu [Page 4]
Sidhu[4ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
but makes no provision for the case in which where_to returns
ICMP, a_frag returns YES, and reass_done returns YES. An
additional row should be inserted, which reads as follows:
しかし、造のノー、は中の_ICMP、_がリターンに破片手榴弾で殺傷されるところではい戻るケース、およびreassのためにリターンがはい行われた_に食糧を供給します。 追加列(以下の通り読む)は挿入されるべきです:
________________________________________________________
check- SNP TTL where a reass ICMP
sum params valid to frag done check-
valid? valid? ? ? ? ? sum?
__________________________________________________________________
YES YES YES ICMP YES YES d reassemble;
analyze;
state :=
INACTIVE
__________________________________________________________________
________________________________________________________ していた状態で破片手榴弾で殺傷するために有効なreass ICMP合計paramsが有効な状態でチェックするチェックSNP TTL--有効ですか? ? ? ? ? 合計? __________________________________________________________________ YES YES YES ICMP YES YES dは組み立て直します。 分析します。 州の:=INACTIVE__________________________________________________________________
Omitting this row means that incoming fragmented ICMP messages
will never be analyzed, since the state machine does not have any
action specified when the last fragment is received.
この列を省略するのは、入って来る断片化しているICMPメッセージが決して分析されないことを意味します、州のマシンには最後の断片が受け取られているときの指定された少しの動作もないので。
Problem 3: Errors in reass_done
問題3: 行われたreass_の誤り
The function reass_done, as can be seen from the above, determines
whether the incoming subnetwork packet contains the last fragment
needed to complete the reassembly of an IP datagram. In order to
understand the errors in this function, we must first understand
how it employs its data structures.
上記で見ることができるように行われた機能reass_は、入って来るサブネットワークパケットが最後の断片を含むかどうかがIPデータグラムの再アセンブリを完成する必要だったことを決定します。 この機能における誤りを理解するために、私たちは、最初に、それがどのようにデータ構造を使うかを理解しなければなりません。
The reassembly of incoming fragments is accomplished by means of a
bit map maintained separately for each state machine. Since all
fragments are not necessarily the same length, each bit in the map
represents not a fragment, but a block, that is, a unit of eight
octets. Each fragment, with the possible exception of the "tail"
fragment (we shall define this term below), is an integral number
of consecutive blocks. Each fragment's offset from the beginning
of the datagram is given, in units of blocks, by a field in the
packet header of each incoming packet. The total length of each
fragment, including the fragment's header, is specified in the
header field total_length; this length is given in octets. The
length of the header is specified in the field header_length; this
length is given in words, that is, units of four octets.
入って来る断片の再アセンブリはそれぞれの州のマシンのために別々に維持されたしばらく地図によって達成されます。 すべての断片が必ず同じ長さでないので、地図の各ビットは断片ではなく、ブロック(すなわち、8つの八重奏のユニット)を表します。 各断片は「テール」断片(私たちは以下の今期を定義するつもりである)の可能な例外がある整数の連続したブロックです。 データグラムの始まりからの各断片のオフセットを与えます、ユニットのブロックで、それぞれの入って来るパケットのパケットのヘッダーの分野のそばで。 断片のヘッダーを含むそれぞれの断片の全長はヘッダーフィールドの合計_長さで指定されます。 八重奏でこの長さを与えます。 ヘッダーの長さは分野のヘッダー_長さで指定されます。 すなわち、単語、4つの八重奏のユニットでこの長さを与えます。
In analyzing this subroutine, we must distinguish between the
"tail" fragment and the "last" fragment. We define the last
fragment as the one which is received last in time, that is, the
fragment that permits reassembly to be completed. The tail
fragment is the fragment that is spatially last, that is, the
fragment that is spatially located after any other fragment. The
このサブルーチンを分析する際に、私たちは「テール」断片と「最後」の断片を見分けなければなりません。 私たちは最後に時間(すなわち、再アセンブリが完成するのを可能にする断片)受け取られるものと最後の断片を定義します。 テール断片は空間的に持続することである断片です、すなわち、次々と空間的に見つけられているいかなる他の断片。 The
Sidhu [Page 5]
Sidhu[5ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
length and offset of the tail fragment make it possible to compute
the length of the entire datagram. This computation is actually
done in the action procedure reassembly, and the result is saved
in the state vector field total_data_length; if the tail fragment
has not been received, this value is assumed to be zero.
テール断片の長さとオフセットで、全体のデータグラムの長さを計算するのは可能になります。 実際に動作手順で再アセンブリにこの計算をします、そして、州のベクトル場合計_のデータ_長さで結果を節約します。 テール断片が受け取られていないなら、この値はゼロであると思われます。
It is the task of the reass_done function [MILS83a, sec 9.4.6.2.6]
to determine whether the incoming fragment is the last fragment.
This determination is made as follows:
それが機能が行われたreass_に関するタスクである、[MILS83a、秒、9.4 .6 .2 .6] 入って来る断片が最後の断片であるかどうか決定するために。 この決断を以下の通りにします:
1) If the tail fragment has not been received previously and
the incoming fragment is not the tail fragment, then return NO.
1) テール断片が以前に、受け取られていなくて、また入って来る断片がテール断片でないなら、そして、リターンNO.です。
2) Otherwise, if the tail fragment has not been received, but
the incoming fragment is the tail fragment, determine whether
all fragments spatially preceding the tail fragment have also
been received.
2) さもなければ、テール断片が受け取られていませんが、入って来る断片がテール断片であるならまた、テール断片に空間的に先行するすべての断片が受け取られたかどうか決定してください。
3) Otherwise, if the tail fragment has been received earlier,
determine whether the incoming fragment is the last one needed
to complete reassembly.
3) より早くテール断片を受け取ったなら、さもなければ、入って来る断片が最後のものであるかどうかが、再アセンブリを完成する必要だったことを決定してください。
The evaluation of case (2) is accomplished by the following
statment:
ケース(2)の評価は以下のstatmentによって実行されます:
if (state_vector.reassembly_map from 0 to
(((from_SNP.dtgm.total_length -
(from_SNP.dtgm.header_length * 4) + 7) / 8)
+ 7) / 8 is set)
then return YES;
(__が0から写像するvector.reassemblyを述べる、(_SNP.dtgm.total_長さ(当時の(_SNP.dtgm.header_長さ*4) +7)/8) + 7)/8から、設定されます)リターンはい)
The double occurrence of the subexpression " + 7 ) / 8" is
apparently a misprint. The function f(x) = (x + 7) / 8 will
convert x from octets to blocks, rounding any remainder upward.
There is no need for this function to be performed twice. The
second problem is that the fragment_offset field of the incoming
packet is ignored. The tail fragment specifies only its own
length, not the length of the entire datagram; to determine the
latter, the tail fragment's offset must be added to the tail
fragment's own length. The third problem hinges on the meaning of
the English "... from ... to ..." phrase. If this phrase has the
same meaning as the ".." range indication in Ada [ADA83, sec 3.6],
that is, includes both the upper and lower bounds, then it is
necessary to subtract 1 from the final expression.
「副-表現」「+7)」の二重発生 /8インチは明らかに誤植です。 機能f(x) = (x+7) 上向きにどんな残りも四捨五入して、/8は八重奏からブロックまでのxを変換するでしょう。 この機能が二度実行される必要は全くありません。 2番目の問題は入って来るパケットの断片_オフセット分野が無視されるということです。 テール断片は全体のデータグラムの長さではなく、それ自身だけの長さを指定します。 後者を決定するために、テール断片の自己の長さにテール断片のオフセットを加えなければなりません。 「3番目の問題はイギリス人の意味で」 …から…までの…に蝶番を付ける」句。 「この句で同じ意味がある、」 . . 」 Ada[ADA83、秒3.6]には、それがいるという範囲指示は両方の上下の領域を含んで、次に、最終的な表現から1を引き算するのが必要です。
The expression following the word to, above, should thus be
changed to read
単語に従う表現、上では、その結果、読むために変えるべきです。
Sidhu [Page 6]
Sidhu[6ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
(from_SNP.dtgm.header_length * 4) + 7) / 8) - 1
_SNP.dtgm.fragment_から、+が相殺されていた、(_SNP.dtgm.total_長さ--(_SNP.dtgm.header_長さ*4) + 7からの)/8)--1
Another serious problem with this routine occurs when evaluating
case (3). In this case, the relevant statement is
ケース(3)を評価するとき、このルーチンの別の深刻な問題は起こります。 この場合、関連声明はそうです。
if (all reassembly map from 0 to
(state_vector.total_data_length + 7)/8 is set
then return YES
(すべての0〜(状態_vector.total_データ_長さ+7)/8までの再アセンブリ地図がはい設定当時のリターンです。
If the tail fragment was received earlier, the code asks, in
effect, whether all the bits in the reassembly map have been set.
This, however, will not be the case even if the incoming fragment
is the last fragment, since the routine reassembly, which actually
sets these bits, has not yet been called for this fragment. This
statement must therefore skip the bits corresponding to the
incoming fragment. In specifying the range to be tested,
allowance must be made for whether these bits fall at the
beginning of the bit map or in the middle (the case where they
fall at the end has already been tested). The statement must
therefore be changed to read
より早くテール断片を受け取ったなら、コードは尋ねます、有効です、再アセンブリ地図のすべてのビットが設定されたか否かに関係なく。 しかしながら、これは入って来る断片が最後の断片であってもそうにならないでしょう、通常の再アセンブリ(実際にこれらのビットを設定する)がこの断片のためにまだ呼ばれていないので。 したがって、この声明は入って来る断片に対応するビットをスキップしなければなりません。 テストされるために範囲を指定する際に、これらのビットがビットマップの始めか中央に下がるかどうか(それらが終わりに低下するケースは既にテストされた)のために考慮をしなければなりません。 したがって、読むために声明を変えなければなりません。
if from_SNP.dtgm.fragment_offset = 0 then
if (all reassembly map from
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
from_SNP.dtgm.header_length * 4) + 7) / 8
to ((state_vector.total_data_length + 7) / 8 - 1) is set)
then return YES;
else return NO;
end if;
_がその時_SNP.dtgm.fragmentから=0を相殺した、(すべてが_SNP.dtgm.fragment_オフセット+(+ (__SNP.dtgm.total_の長さ、SNP.dtgm.header_長さ*4からの)7)/8から1が)セット) その時がはいを返すということであるという(状態_vector.total_データ_長さ+7)/8まで地図を再アセンブリします。 ほかのリターンノー。 終わり、。
else
if (all reassembly map from 0 to
(from_SNP.dtgm.fragment_offset - 1) is set)
and (all reassembly map from
from_SNP.dtgm.fragment_offset +
((from_SNP.dtgm.total_length -
from_SNP.dtgm.header_length * 4) + 7) / 8
to ((state_vector.total_data_length + 7) / 8 - 1) is set)
then return YES;
else return NO;
end if;
end if;
そして、ほか、(すべてが0からの地図を再アセンブリする、(__が相殺したSNP.dtgm.fragmentから--1は)設定されます)、(すべてが_SNP.dtgm.fragment_オフセット+(+ (__SNP.dtgm.total_の長さ、SNP.dtgm.header_長さ*4からの)7)/8から1が)セット) その時がはいを返すということであるという(状態_vector.total_データ_長さ+7)/8まで地図を再アセンブリします。 ほかのリターンノー。 終わり、。 終わり、。
Sidhu [Page 7]
Sidhu[7ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
Note that here again it is necessary to subtract 1 from the upper
bound.
一方、ここで、上限から1を引き算するのが必要であることに注意してください。
Problem 4: Errors in fragment_and_send
問題4: 断片_と_の誤りは発信します。
The action procedure fragment_and_send [MILS83a, sec 9.4.6.3.7] is
used to break up datagrams that are too large to be sent through
the subnetwork as a single packet. The specification requires
[MILS83a sec 9.2.2, sec 9.4.6.3.7] each fragment, except possibly
the "tail" fragment, to contain a whole number of 8-octet groups
(called "blocks"); moreover, each fragment must begin at a block
boundary.
動作手順の断片_と_が発信する、[MILS83a、秒、9.4 .6 .3 .7は、]単一のパケットとしてサブネットワークを通して送ることができないくらい大きいデータグラムを壊れさせるのに使用されます。 仕様が必要である、[MILS83a秒9.2の.2、秒9.4の.6.7が]それぞれ断片化する.3、ことによると「テール」断片、8八重奏の整数を含むのは分類されます(「ブロック」と呼ばれます)。 そのうえ、各断片はブロック境界で始まらなければなりません。
In the algorithm set forth in fragment_and_send, all fragments
except the tail fragment are set to the same size; the procedure
begins by calculating this size. This is done by the following
statement:
中の先へアルゴリズムセットでは、断片_と_は発信して、テール断片以外のすべての断片が同じサイズに設定されます。 手順は、このサイズについて計算することによって、始まります。 以下の声明はこれをします:
data_per_fragment := maximum subnet transmission unit
- (20 + number of bytes of option data);
1_あたりのデータ_は:=の最大のサブネットトランスミッション単位を断片化します--(オプションデータの20+バイト数)
Besides the failure to allow for header padding, which is
discussed in the next section, this statement makes the serious
error of not assuring that the result is an integral multiple of
the block size, i.e., a multiple of eight octets. The consequence
of this would be that as many as seven octets per fragment would
never be sent at all. To correct this problem, and to allow for
header padding, this statement must be changed to
ヘッダー詰め物を考慮しないこと以外に、この声明は結果がブロック・サイズ(すなわち、8つの八重奏の倍数)の不可欠の倍数であることを保証しない重大な誤りをします。次のセクションでことについて議論します。 この結果は1断片あたり最大7つの八重奏を全く決して送らないということでしょう。 この問題を修正して、ヘッダー詰め物を考慮するために、この声明に変えなければなりません。
data_per_fragment := (maximum subnet transmission unit
- (((20 + number of bytes of option data)+3)/4*4)/8*8;
1_あたりのデータ_は:=(最大のサブネットトランスミッション単位--(オプションデータの20+バイト数)+3)/4*4)/8*8を断片化します。
Another problem in this procedure is the failure to provide for
the case in which the length of the data is an exact multiple of
eight. The procedure contains the statements
この手順による別の問題はデータの長さが8の正確な倍数である場合に備えないことです。 手順は声明を含んでいます。
number_of fragments := (from_ULP.length +
(data_per_fragment - 1)) / data_per_fragment;
断片:=(_ULP.length+(_断片あたりのデータ_--1)からの)/データ_の1_あたりの数の_に、断片化してください。
data_in_last_frag := from_ULP.length modulo data_per_fragment;
_最後の_のデータ_は_断片あたりの_ULP.length法データ_から:=を破片手榴弾で殺傷します。
(Note that in our terminology we would rename data_in_last_frag as
data_in_tail_frag; notice, also, that the proper spelling of the
Ada operator is mod [ADA83, sec 4.5.5].)
(_テール_のデータ_が破片手榴弾で殺傷されるとき、私たちが改名する用語では、_最後の_のデータ_が破片手榴弾で殺傷されることに注意してください; また、Adaオペレータの適切なスペルがモッズ[ADA83、秒4.5の.5]であることに注意してください。)
If data_in_last_frag is zero, some serious difficulties arise.
One result might be that the datagram will be broken into one more
_最後の_の_が破片手榴弾で殺傷するデータがゼロであるなら、いくつかの重大な困難が起こります。 1つの結果はデータグラムがもうひとつ壊されるということであるかもしれません。
Sidhu [Page 8]
Sidhu[8ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
fragment than necessary, with the tail fragment containing no data
bytes. The assignment of data into the tail fragment will succeed
even though it will now take the form
必要であるテール断片がデータ・バイトを全く含んでいなく、断片化してください。 現在、形を取るでしょうが、テール断片へのデータの課題は成功するでしょう。
output_data [i..i-1] := input_data [j..j-1];
_データ[i..i-1]:=入力_データ[j..j-1]を出力してください。
because Ada makes provision for so-called "null slices" [ADA83,
sec 4.1.2] and will treat this assignment as a no-op [ADA83, sec
5.2.1].
Adaがいわゆる「ヌル部分」[ADA83、秒4.1の.2]に備えて、どんなオプアート[ADA83、秒5.2の.1]としてもこの課題を扱わないので。
This does, however, cause the transmission of an unnecessary
packet, and also creates difficulties for the reassembly
procedure, which must now be prepared to handle empty packets, for
which not even one bit of the reassembly map should be set.
Moreover, as the procedure is now written, even this will not
occur. This is because the calculation of the number of fragments
is incorrect.
これは、しかしながら、不要なパケットのトランスミッションを引き起こして、また、再アセンブリ手順のために困難を作成します。(今、空のパケットを扱うようにそれを準備しなければなりません)。(再アセンブリ地図のどんな1ビットさえもパケットにおいて設定されるべきではありません)。 そのうえ、手順が現在書かれるとき、これさえ起こらないでしょう。 これは断片の数の計算が不正確であるからです。
A numerical example will clarify this point. Suppose that the
total datagram length is 16 bytes and that the number of bytes per
fragment is to be 8. Then the above statements will compute
number_of_fragments = (16 + 7)/8 = 2 and data_in_last_frag = 16
mod 8 = 0. The result of the inconsistency between
number_of_fragments and data_in_last_frag will be that instead of
sending three fragments, of lengths 8, 8, and 0, the procedure
will send only two fragments, of lengths 8 and 0; the last eight
octets will never be sent.
数字の例はこのポイントをはっきりさせるでしょう。 1断片あたりのバイト数が総データグラムの長さが16バイトであり、8であることであると仮定してください。 そして、上のステートメントは16__最後の_の=(16+7)/8 = 2とデータ_が破片手榴弾で殺傷する断片の数の_=モッズ8 = 0を計算するでしょう。 _最後の_の断片とデータ_が破片手榴弾で殺傷する_の数の_の間の矛盾の結果は3個の断片を送ることの代わりに長さ8、8、および0では、手順が長さ8と0の2個の断片だけを送るということでしょう。 ベストエイト八重奏を決して送らないでしょう。
To avoid these difficulties, the specification should add the
following statement, immediately after computing
data_in_last_frag:
これらの困難を避けるために、_最後の_のコンピューティングデータ_が破片手榴弾で殺傷される直後仕様は以下の声明を加えるべきです:
if data_in_last_frag = 0 then
data_in_last_frag := data_per_fragment;
end if;
_最後の_のデータ_が=0を破片手榴弾で殺傷するなら、_最後の_のデータ_は_断片あたりの:=データ_を破片手榴弾で殺傷します。 終わり、。
This procedure also contains several minor errors. In addition to
failures to account for packet header padding, which are
enumerated in the next section, there is a failure to convert the
header length from words (four octets) to octets in one statement.
This statement, which calculates the total length of the non-tail
fragments, is
また、この手順はいくつかの軽い過失を含んでいます。 パケットのヘッダー詰め物を説明しないことに加えて、1つの声明には単語(4つの八重奏)から八重奏までヘッダ長を変換しないことがあります。それは、次のセクションで列挙されます。 この声明(非テール断片の全長について計算する)はそうです。
to_SNP.dtgm.total_length := to_SNP.dtgm.header_length
+ data_per_fragment;
_への_SNP.dtgm.total_長さの:=に、1_あたりのSNP.dtgm.header_長さ+データ_は断片化します。
Sidhu [Page 9]
Sidhu[9ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
Since header length is expressed in units of words, this
statement should read
この声明が、ヘッダ長がユニットの単語で言い表されると読むべきであるので
to_SNP.dtgm.total_length := to_SNP.dtgm.header_length * 4
+ data_per_fragment;
_SNP.dtgm.header_長さ*への_SNP.dtgm.total_長さの:=に、1_あたりの4+データ_は断片化します。
This is apparently no more than a misprint, since the
corresponding calculation for the tail fragment is done correctly.
テール断片のための対応する計算が正しく完了しているので、これは明らかに誤植にすぎません。
Problem 5: Errors in reassembly
問題5: 再アセンブリの誤り
The action procedure reassembly [MILS83a, sec 9.4.6.3.9], which is
referred to as reassemble elsewhere in the specification [MILS83a,
sec 9.4.6.1.2, sec 9.4.6.1.3], inserts an incoming fragment into a
datagram being reassembled. This procedure contains several
relatively minor errors.
動作手順再アセンブリ、[MILS83a、秒9.4の.6、.3、仕様のほかの場所で組み立て直すとき参照される.9、][MILS83a、秒9.4の.6、.1、.2、秒、9.4 .6 .1 .3、]入来が断片化するデータグラムに組み立て直される差し込み。 この手順はいくつかの比較的小さい方の誤りを含んでいます。
In two places in this procedure, a range is written to contain one
more member than it ought to have. In the first, data from the
fragment is to be inserted into the datagram being reassembled:
この手順による2つの場所では、範囲が、もうひとつのメンバーを含むように書かれているべきであったより書かれています。 1番目では、断片からのデータは組み立て直されるデータグラムに挿入されることです:
state_vector.data [from_SNP.dtgm.fragment_offset*8 ..
from_SNP.dtgm.fragment_offset*8 + data_in_frag] :=
from_SNP.dtgm.data [0..data_in_frag-1];
_SNP.dtgm.data[_で1を破片手榴弾で殺傷している0..data_]より_vector.data[__SNP.dtgm.fragment_から*8に相殺されたSNP.dtgm.fragment_から、_のオフセット*8+データ_は破片手榴弾で殺傷される]:=を述べてください。
In this statement, the slice on the left contains one more byte
than the slice on the right. This will cause a run-time exception
to be raised [ADA83, sec 5.2.1]. The statement should read
この声明では、左の部分は右の部分よりもうひとつのバイトを含んでいます。 これで、ランタイム例外を上げるでしょう[ADA83、秒5.2の.1]。 声明は読むべきです。
state_vector.data [from_SNP.dtgm.fragment_offset*8 ..
from_SNP.dtgm.fragment_offset*8 + data_in_frag - 1] :=
from_SNP.dtgm.data [0..data_in_frag-1];
_SNP.dtgm.data[_で1を破片手榴弾で殺傷している0..data_]より_[__SNP.dtgm.fragment_から*8に相殺されたSNP.dtgm.fragment_から、_のオフセット*8+データ_は破片手榴弾で殺傷されます--1]というvector.data:=を述べてください。
A similar problem occurs in the computation of the range of bits
in the reassembly map that corresponds to the incoming fragment.
This statement begins
同様の問題は入って来る断片に一致している再アセンブリ地図における、ビットの範囲の計算で起こります。 この声明は始まります。
for j in (from_SNP.dtgm.fragment_offset) ..
((from_SNP.dtgm.fragment_offset +
data_in_frag + 7)/8) loop
中(_SNP.dtgm.fragmentから、_は相殺された)のjのために。 (_から、_のSNP.dtgm.fragment_オフセット+データ_は+ 7)/8を破片手榴弾で殺傷します) 輪
Not only are the parentheses in this statement located incorrectly
(because the function f(x) = (x + 7) / 8 should be executed only
on the argument data_in_frag), but also this range contains one
extra member. The statement should read
この声明の括弧が不当に見つけられているだけではなく(機能f(x)=(x+7)/8が_の引数データ_だけで実行されるべきであるので、破片手榴弾で殺傷してください)、この範囲は1人の余分なメンバーを含みもします。 声明は読むべきです。
Sidhu [Page 10]
Sidhu[10ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
for j in (from_SNP.dtgm.fragment_offset) ..
(from_SNP.dtgm.fragment_offset +
(data_in_frag + 7)/8) - 1 loop
中(_SNP.dtgm.fragmentから、_は相殺された)のjのために。 (_SNP.dtgm.fragment_から、+ (_のデータ_は+ 7を破片手榴弾で殺傷します)/8は相殺されています) - 1つの輪
Note that if the statement is corrected in this manner it will
also handle the case of a zero-length fragment, mentioned above,
since the loop will not be executed even once [ADA83, sS 5.5].
また、声明がこの様に修正されるとゼロ・レングス断片のケースを扱うことに注意してください、前記のように、輪が一度[ADA83、sS5.5]さえ実行されないので。
Another minor problem occurs when this procedure attempts to save
the header of the leading fragment. The relevant statement is
この手順が、主な断片のヘッダーを救うのを試みるとき、別の小さな問題は起こります。 関連声明はそうです。
state_vector.header := from_SNP.dtgm;
_SNP.dtgmより_vector.header:=を述べてください。
This statement attempts to transfer the entire incoming fragment
into a record that is big enough to contain only the header. The
result, in Ada, is not truncation, but a run-time exception
[ADA83, sec 5.2]. The correction should be something like
この声明は、ヘッダーしか含むことができないくらい大きい記録に全体の入って来る断片を移すのを試みます。 Adaで、結果はトランケーションではなく、ランタイム例外[ADA83、秒5.2]です。 修正は何か同様のものであるべきです。
state_vector.header := from_SNP.dtgm.header;
_SNP.dtgm.headerより_vector.header:=を述べてください。
This correction cannot be made without also defining the header
portion of the datagram as a subrecord in [MILS83a, sec 9.4.4.6];
such a definition would also necessitate changing many other
statements. For example, from_SNP.dtgm.fragment_offset would now
have to be written as from_SNP.dtgm.header.fragment_offset.
Another possible solution is to write the above statement as a
series of assignments for each field in the header, in the
following fashion:
また、中でデータグラムのヘッダー部分をサブレコードと定義しないでこの修正をすることができない、[MILS83a、秒9.4の.4、.6]。 また、そのような定義は、他の多くの声明を変えるのを必要とするでしょう。 例えば、SNP.dtgm.fragment_オフセットが現在_SNP.dtgm.header.fragment_現在書かれるために持っている_から、相殺してください。 別の可能な解決策はヘッダーの各分野のための一連の課題として上の声明を書くことです、以下のファッションで:
state_vector.header.version :=
from_SNP.dtgm.version;
state_vector.header.header_length :=
from_SNP.dtgm.header_length;
state_vector.header.type_of_service :=
from_SNP.dtgm.type_of_service;
_SNP.dtgm.versionより_vector.header.version:=を述べてください。 _SNP.dtgm.header_長さより_vector.header.header_長さの:=を述べてください。 __サービスのSNP.dtgm.type_より__サービス:=のvector.header.type_を述べてください。
-- etc.
-- など
Note also that this procedure will fail if an incoming fragment,
other than the tail fragment, does not contain a multiple of eight
characters. Implementors must be careful to check for this in the
decision function SNP_params_valid [MILS83a, sec 9.4.6.2.7].
また、テール断片以外に、入って来る断片が8つのキャラクタの倍数を含んでいないとこの手順が失敗することに注意してください。 作成者がこれがないかどうか決定関数SNP_params_で有効な状態でチェックするのに慎重であるに違いない、[MILS83a、秒、9.4 .6 .2 .7]。
Sidhu [Page 11]
Sidhu[11ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
Problem 6: Incorrect Data Length for Fragmented Datagrams
問題6: 断片化しているデータグラムのための間違ったデータの長さ
The procedure reassembled_delivery [MILS83a, sec 9.4.6.3.10] does
not deliver the proper data length to the upper-level protocol.
This is because the assignment is
手順が_配送を組み立て直した、[MILS83a、秒、9.4 .6 .3 .10は]適切なデータの長さを上側のレベルプロトコルに送りません。 これは課題がそうであるからです
to_ULP.length := state_vector.header.total_length
- state_vector.header.header_length * 4;
_vector.header.total_長さを_ULP.length:=に述べてください--状態_vector.header.header_長さ*4
The fields in state_vector.header have been filled in by the
reassembly procedure, discussed above, by copying the header of
the leading fragment. The field total_length in this fragment,
however, refers only to this particular fragment, and not to the
entire datagram (this is not entirely clear from it definition in
[MILS83a, sec 9.3.4], but the fragment_and_send procedure
[MILS83a, sec 9.4.6.3.7] insures that this is the case).
上で議論した再アセンブリ手順で状態_vector.headerの分野は主な断片のヘッダーをコピーすることによって、記入されました。 しかしながら、この断片の分野の合計_長さは全体のデータグラムではなく、この特定の断片だけを参照します。(これがそれから[MILS83a、秒9.3の.4]との定義を完全にクリアしないことである、断片_と_が手順を送る、[MILS83a、秒9.4の.6、.3、.7が、]これがそうであることを保障する、)
The length of the entire datagram can only be computed from the
length and offset of the tail fragment. This computation is
actually done in the reassembly procedure [MILS83a, sec
9.4.6.3.9], and the result saved in state_vector.total_data_length
(see above). It is impossible, however, for reassembly to fill in
state_vector.header.total_length at this time, because
state_vector.header.header_length is filled in from the lead
fragment, which may not yet have been received.
テール断片の長さとオフセットから全体のデータグラムの長さを計算できるだけです。 実際に再アセンブリ手順でこの計算をする、[MILS83a、秒、9.4 .6 .3 .9] そして、状態_vector.total_のデータ_長さ(上を見る)で節約された結果。 しかしながら、再アセンブリがこのとき状態_vector.header.total_の長さに記入するのは、不可能です、状態_vector.header.header_の長さがリード断片(まだ受け取られていないかもしれない)から記入されるので。
Therefore, reassembled_delivery must replace the above statement
with
したがって、配送が上の声明に取って代わらなければならない組み立て直された_
to_ULP.length := state_vector.total_data_length;
_vector.total_データ_の長さを_ULP.length:=に述べてください。
The consequence of leaving this error uncorrected is that the
upper-level protocol will be informed only of the delivery of as
many octets as there are in the lead fragment.
この誤りを非修正でおく結果は上側のレベルプロトコルがリード断片にあるのと同じくらい多くの八重奏の配送だけで知識があるようになるということです。
5. Implementation Difficulties of MIL Standard IP
5. ミルの標準のIPの実現困難
In addition to the problems discussed above, there are several features of the MIL standard IP specification [MILS83a] which lead to difficulties for the implementor. These difficulties, while not actually errors in the specification, take the form of assumptions which are not explicitly stated, but of which implementors must be aware.
上で議論した問題に加えて、作成者のための困難につながるMILの標準のIP仕様[MILS83a]のいくつかの特徴があります。 これらの困難は実際に仕様に基づく誤りでない間、述べられていませんが、作成者が明らかに意識しているに違いない仮定の形を取ります。
Sidhu [Page 12]
Sidhu[12ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
5.1 Header Padding
5.1 ヘッダー詰め物
In several places, the specification makes a computation of the
length of a packet header without explicitly allowing for padding.
The padding is needed because the specification requires [MILS83a,
sec 9.3.14] that each header end on a 32-bit boundary.
方々に、そっと歩くと明らかに考慮しない、仕様はパケットのヘッダーの長さの計算をします。 仕様がそれぞれのヘッダー端のときに32ビットの境界でそれを必要とするので[MILS83a、秒9.3の.14]、詰め物が必要です。
One place this problem arises is in the need_to_frag decision
function [MILS83a, sec 9.4.6.2.5]. This function is used to
determine whether fragmentation is required for an outgoing
datagram. It consists of the single statement
この問題が起こる1つの場所が_への必要性_で決定関数を破片手榴弾で殺傷することである、[MILS83a、秒、9.4 .6 .2 .5]。 この機能は、断片化が発信データグラムに必要であるかどうか決定するのに使用されます。 それはただ一つの声明から成ります。
if ((from_ULP.length + (number of bytes of option data)
+ 20) > maximum transmission unit of the local subnetwork
then return YES
else return NO;
end if;
いいえ; 次に、地方のサブネットワークの(_ULP.length+(オプションデータのバイト数)+20からの)>マキシマム・トランスミッション・ユニットがはいほかのリターンを返すなら終わってください、。
(A minor syntax error results from not terminating the first
return statement with a semicolon [ADA83, sec 5.1, sec 5.3, sec
5.9].) In order to allow for padding, the expression for the
length of the outgoing datagram should be
(1番目を終えないのからの結果がセミコロン[ADA83、秒5.1、秒5.3、秒5.9]がある声明を返す小さい方の構文エラー。) そっと歩くと考慮するために、発信データグラムの長さのための表現は考慮するべきです。
(((from_ULP.length + (number of bytes of option data) + 20)
+ 3)/4 * 4)
(+ (_ULP.length+(オプションデータのバイト数)+20からの)3)/4*4)
Another place that this problem arises is in the action procedure
build_and_send [MILS83a, sec 9.4.6.3.2], which prepares
unfragmented datagrams for transmission. To compute the header
field header_length, which is expressed in words, i.e., units of
four octets [MILS83a, sec 9.3.2], this procedure contains the
statement
別の場所に、この問題が起こるのが体格_と_が送る動作手順にある、[MILS83a、秒、9.4 .6 .3 .2] トランスミッションのために非断片化しているデータグラムを準備する。 ヘッダーフィールドのヘッダー_長さを計算するために、この手順は声明を含んでいます。(長さはすなわち、単語、4つの八重奏[MILS83a、秒9.3の.2]のユニットで表されます)。
to_SNP.dtgm.header_length := 5 +
(number of bytes of option data)/4;
_SNP.dtgm.header_長さ:=5+(オプションデータのバイト数)/4に。
In order to allow for padding, this statement should read
そっと歩くと考慮するために、この声明は読むべきです。
to_SNP.dtgm.header_length :=
5 + ((number of bytes of option data)+3)/4;
_SNP.dtgm.header_長さ:=5+((オプションデータのバイト数)+3)/4に。
The identical statement appears in the action procedure
fragment_and_send [MILS83a, sec 9.4.6.3.7], which prepares
datagram fragments for transmission, and requires the same
correction.
同じ声明が_と_が送る動作手順断片に現れる、[MILS83a、秒、9.4 .6 .3 .7] トランスミッションのためにデータグラム・フラグメントを準備して、同じ修正を必要とする。
Sidhu [Page 13]
Sidhu[13ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
The procedure fragment_and_send also has this problem in two other
places. In the first, the number of octets in each fragment is
computed by
また、_と_が送る手順断片は他の2つの場所でこの問題を持っています。 1番目では、各断片の八重奏の数によって計算されます。
data_per_fragment := maximum subnet transmission unit
- (20 + number of bytes of option data);
1_あたりのデータ_は:=の最大のサブネットトランスミッション単位を断片化します--(オプションデータの20+バイト数)
In order to allow for padding, this statement should read
そっと歩くと考慮するために、この声明は読むべきです。
data_per_fragment := maximum subnet transmission unit
- (((20 + number of bytes of option data)+3)/4*4);
1_あたりのデータ_は:=の最大のサブネットトランスミッション単位を断片化します--(((オプションデータの20+バイト数)+3)/4*4)
(Actually, this statement must be changed to
(実際に、この声明を変えなければなりません。
data_per_fragment := (maximum subnet transmission unit
- (((20 + number of bytes of option data)+3)/4*4)/8*8;
1_あたりのデータ_は:=(最大のサブネットトランスミッション単位--(オプションデータの20+バイト数)+3)/4*4)/8*8を断片化します。
in order to accomplish its intended purpose, for reasons which
have been discussed above.)
本来の目的を達成するために、理由で、上でどれについて議論しましたか?)
A similar problem occurs in the statement which computes the
header length for individual fragments:
同様の問題は個々の断片のためにヘッダ長を計算するステートメントに起こります:
to_SNP.dtgm.header_length := 5 +
(number of copy options octets/4);
_SNP.dtgm.header_長さ:=5の+(コピーオプション八重奏/4の数)に。
To allow for padding, this should be changed to
そっと歩くと考慮するために、これに変えるべきです。
to_SNP.dtgm.header_length := 5 +
(number of copy options octets+3/4);
_SNP.dtgm.header_長さ:=5の+(コピーオプション八重奏+3/4の数)に。
Notice that all of these errors can also be corrected if the
English phrase "number of bytes of option data", and similar
phrases, are always understood to include any necessary padding.
また、イギリス人が「オプションデータのバイト数」を言葉で表すならこれらの誤りのすべてを修正できて、どんな必要な詰め物も含んでいるのが理解されていて、同様の句がいつも修正される通知。
5.2 Subnetworks with Small Transmission Sizes
5.2 小さいトランスミッションサイズがあるサブネットワーク
When an outgoing datagram is too large to be transmitted as a
single packet, it must be fragmented. On certain subnetworks, the
possibility exists that the maximum number of bytes that may be
transmitted at a time is less than the size of an IP packet header
for a given datagram. In this case, the datagram cannot be sent,
even in fragmented form. Note that this does not necessarily mean
that the subnetwork cannot send any datagrams at all, since the
size of the header may be highly variable. When this problem
arises, it should be detected by IP. The proper place to detect
this situation is in the function can_frag.
発信データグラムが単一のパケットとして伝えることができないくらい大きいときに、それを断片化しなければなりません。 あるサブネットワークの上では、与えられたデータグラムには、一度に伝えられるかもしれないバイトの最大数がIPパケットのヘッダーのサイズより少ない可能性は存在しています。 この場合、断片化しているフォームでさえデータグラムを送ることができません。 これが、必ずサブネットワークが全くどんなデータグラムも送ることができないことを意味するというわけではないことに注意してください、ヘッダーのサイズが非常に可変であるかもしれないので。 この問題が起こるとき、それはIPによって検出されるべきです。 この状況を検出する適所は機能缶の_で破片手榴弾で殺傷することです。
Sidhu [Page 14]
Sidhu[14ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
The can_frag decision function [MILS83a, sec 9.4.6.2.2] is used to
determine whether a particular outgoing datagram, which is too
long to be transmitted as a single fragment, is allowed to be
fragmented. In the current specification, this function consists
of the single statement
缶の_が決定関数を破片手榴弾で殺傷する、[MILS83a、秒、9.4 .6 .2 .2は、]特定の発信データグラム(ただ一つの断片として伝えることができないくらい長い)が断片化できるかどうか決定するのに使用されます。 現在の仕様では、この機能はただ一つの声明から成ります。
if (from_ULP.dont_fragment = TRUE)
then return NO
else return YES
end if;
(_ULP.dont_断片=TRUEからの)その時ならどんなほかのリターンはい終わりも返さないでください、。
(A minor syntax error is that the return statements should be
terminated by semicolons; see [ADA83, sec 5.1, sec 5.3, sec 5.9].)
(小さい方の構文エラーはリターン声明がセミコロンによって終えられるべきであるということです; 見てください[ADA83、秒5.1、秒5.3、秒5.9]。)
If the above problem occurs, the procedure fragment_and_send will
obtain negative numbers for fragment sizes, with unpredictable
results. This should be prevented by assuring that the subnetwork
can send the datagram header and at least one block (eight octets)
of data. The can_frag function should be recoded as
上の問題が起こると、_と_が送る手順断片は予測できない結果に従った断片サイズの負数を得るでしょう。 サブネットワークがデータグラムヘッダーと少なくとも1ブロック(8つの八重奏)のデータを送ることができることを保証することによって、これは防がれるべきです。 缶の_が破片手榴弾で殺傷される、機能は再コード化されるべきです。
if ((8 + ((number of bytes of option data)+3)/4*4 + 20)
> maximum transmission unit of the local subnetwork)
then return NO;
elsif (from_ULP.dont_fragment = TRUE)
then return NO
else return YES
end if;
(地方のサブネットワークの((オプションデータ) +3のバイト数)/4*4+20)>8+最大のトランスミッション単位)であるなら、いいえを返してください。 elsifのほかのリターンはい(_ULP.dont_断片=TRUEからの)当時のリターンノーエンド、。
This is similar to the logic of the function need_to_frag,
discussed above.
これは上で破片手榴弾で殺傷して、議論した_における機能の必要性_の論理と同様です。
5.3 Subnetwork Interface
5.3 サブネットワークインタフェース
Provision is made for the subnetwork to report errors to IP
[MILS83a, sec 6.3.6.2], but no provision is made for the IP entity
to take any action when such errors occur.
サブネットワークが誤りをIPに報告するのを設備をします。[MILS83a、.2を]しますが、どんな設備もそのような誤りであるときに、IP実体がどんな行動も取るようにされない秒6.3の.6が起こります。
In addition, the specification [MILS83a, sec 8.2.1.1] calls for
the subnetwork to accept type-of-service indicators (precedence,
reliability, delay, and throughput), which may be difficult to
implement on many local networks.
添加、仕様、[MILS83a、サブネットワークがサービスのタイプインディケータ(先行、信頼性、遅れ、およびスループット)を受け入れるという秒8.2の.1の.1]要求。(インディケータは多くの企業内情報通信網で実行するのは難しいかもしれません)。
Sidhu [Page 15]
Sidhu[15ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
5.4 ULP Errors
5.4 ULP誤り
The IP specification [MILS83a, sec 9.4.6.3.6] states
IP仕様、[MILS83a、秒9.4の.6の.3.6]州
The format of error reports to a ULP is implementation
dependent. However, included in the report should be a value
indicating the type of error, and some information to identify
the associated data or datagram.
ULPへのエラー・レポートの形式は実現に依存しています。 しかしながら、レポートに含まれているのは、関連データかデータグラムを特定するために誤りのタイプ、および何らかの情報を示す値であるべきです。
The most natural way to provide the latter information would be to
return the datagram identifier to the upper-level protocol, since
this identifier is normally supplied by the sending ULP [MILS83a,
sec 9.3.5]. However, the to_ULP data structure makes no provision
for this information [MILS83a, sec 9.4.4.3], probably because this
information is irrelevant for datagrams received from the
subnetwork. Implementors may feel a need to add this field to the
to_ULP data structure.
後者の情報を提供する最も自然な方法は上側のレベルプロトコルにデータグラム識別子を返すだろうことです、この識別子が送付ULP[MILS83a、秒9.3の.5]によって通常提供されるので。 しかしながら、ULPデータ構造がこの情報への設備を全くしない_、[MILS83a、秒、9.4 .4 .3] サブネットワークから受け取られたデータグラムには、たぶんこの情報が無関係であるので。 作成者がこの分野を加える必要性を感じるかもしれない、_ULPデータ構造に。
5.5 Initialization of Data Structures
5.5 データ構造の初期設定
The decision function reass_done [MILS83a, sec 9.4.6.2.6] makes
the implicit assumption that data structures within each finite
state machine are initialized to zero when the machine is created.
In particular, this routine will not function properly unless
state_vector.reassembly_map and state_vector.total_data_length are
so initialized. Since this assumption is not stated explicitly,
implementors should be aware of it. There may be other
initialization assumptions that we have not discovered.
MILS83a、.6が]暗黙の仮定をそのデータ構造にそれぞれ有限な状態でする.2がマシンが初期化されると述べる秒9.4の.6はいつのゼロに合っているか。行われた決定関数reass_、[マシンは作成されます。 州の_vector.reassembly_地図と状態_vector.total_データ_の長さがそのように初期化されないと、特に、このルーチンは適切に機能しないでしょう。 この仮定が明らかに述べられていないので、作成者はそれを意識しているべきです。 私たちが発見していない他の初期化仮定があるかもしれません。
5.6 Locally Defined Types
5.6 局所的に定義されたタイプ
The procedures error_to_source [MILS83a, sec 9.4.6.3.5] and
error_to_ULP [MILS83a, sec 9.4.6.3.6] define enumeration types in
comments. The former contains the comment
_ソースへの手順誤り_、[秒9.4の.6の.3のMILS83a、.5、]および誤り、_ULPへの_、[MILS83a、秒、9.4 .6 .3 .6は]コメントで列挙タイプを定義します。 前者はコメントを含んでいます。
error_param : (PARAM_PROBLEM, EXPIRED_TTL, PROTOCOL_UNREACH);
_誤りparam: (PARAM_問題、満期の_TTL、プロトコル_UNREACH)。
and the latter
そして、後者
error_param : (PARAM_PROBLEM, CAN'T_FRAGMENT, NET_UNREACH,
PROTOCOL_UNREACH, PORT_UNREACH);
_誤りparam: (PARAM_問題、_断片、ネット_UNREACH、プロトコル_UNREACHが_UNREACHを移植できない、)、。
These enumerated values are used before they are encountered
[MILS83a, sec 9.4.6.1.1, sec 9.4.6.1.2, sec 9.4.6.1.3, et al.];
implementors will probably wish to define some error type
globally.
遭遇する前にこれらの列挙された値が使用されている、[MILS83a、秒9.4の.6、.1、.1、秒9.4の.6、.1、.2、秒9.4の.6、.1、.3、他]、。 作成者はたぶん誤りタイプをグローバルに定義したくなるでしょう。
Sidhu [Page 16]
Sidhu[16ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
5.7 Miscellaneous Difficulties
5.7 種々雑多な困難
The specification contains many Ada syntax errors, some of which
have been shown above. We have only mentioned syntax errors
above, however, when they occurred in conjunction with other
problems. One of the main syntactic difficulties that we have not
mentioned is that the specification frequently creates unnamed
types, by declaring records within records; such declarations are
legal in Pascal, but not in Ada [ADA83, sec 3.7].
仕様は多くのAda構文エラーを含んでいます。その或るものは上に示されました。 しかしながら、それらが他の問題に関連して起こったときだけ、私たちは上の構文エラーについて言及しました。私たちが言及していない主な構文の困難の1つは仕様が頻繁に無名タイプを創造するということです、記録の中で記録を宣言することによって。 そのような宣言は、パスカルで法的ですが、Ada[ADA83、秒3.7]で法的であるというわけではありません。
Another problem is that slice assignments frequently do not
contain the same number of elements on the left and right sides,
which will raise a run-time exception [ADA83, sec 5.2.1]. While
we have mentioned some of these, there are others which are not
enumerated above.
別の問題は部分課題が左右の側に頻繁に同じ数の要素を保管していないということです。(側はランタイム例外[ADA83、秒5.2の.1]を上げるでしょう)。 私たちはこれらのいくつかについて言及しましたが、上に数え上げられない他のものがいます。
In particular, the procedure error_to_source [MILS83a, sec
9.4.6.3.5] contains the statement
_ソースへの特に手順誤り_、[MILS83a、秒9.4の.6、.3、.5は]声明を含んでいます。
to_SNP.dtgm.data [8..N+3] := from_SNP.dtgm.data [0..N-1];
__SNP.dtgm.data[0..N-1]からのSNP.dtgm.data[8..N+3]:=に。
We believe that N+3 is a misprint for N+8, but even so the left
side contains one more byte than the right. Implementors should
carefully check every slice assignment.
私たちは、権利よりN+8のための誤植ですが、左側が1つをより多くのバイト含みさえして、N+3が誤植であると信じています。 作成者は丹念にあらゆる部分課題をチェックするべきです。
6. An Implementation of MIL Standard IP
6. ミルの標準のIPの実現
In our discussion above, we have pointed out several serious problems with the Military Standard IP [MILS83a] specification which must be corrected to produce a running implementation conforming to this standard. We have produced a running C implementation for the MIL Standard IP, after problems discussed above were fixed in the IP specification. An important feature of this implementation is that it was generated semi-automatically from the IP specification with the help of a protocol development system [BLUT82] [BLUT83] [SIDD83]. Since this implementation was derived directly from the IP specification with the help of tools, it conforms to the IP standard better that any handed-coded IP implementation can do.
議論では、上では、私たちがこの規格に従う走行実現を起こすために修正しなければならないMilitary Standard IP[MILS83a]仕様のいくつかの深刻な問題を指摘しました。 私たちはMIL Standard IPのために走行C実現を起こしました、上で議論した問題がIP仕様で修正された後に。 この実現の重要な特徴はプロトコル開発システム[BLUT82][BLUT83][SIDD83]の助けでIP仕様から半自動的に発生したということです。 この実現が直接ツールの助けがあるIP仕様から引き出されたので、どんな手渡されてコード化されたIP実現もできるのはIP規格によりよく従います。
The problems pointed out in this paper with the current specification of the MIL Standard IP [MILS83a] are based on an initial investigation of the protocol.
この紙でMIL Standard IP[MILS83a]の現在の仕様で指摘された問題はプロトコルの初期の研究に基づいています。
Sidhu [Page 17]
Sidhu[17ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
NOTES
注意
[1] Ada is a registered trademark of the U.S. Government - Ada Joint Program Office.
[1] Adaは米国政府の登録商標です--Ada Joint Programオフィス。
[2] d indicates a "don't care" condition.
[2] dは「気にかけないでください」という状態を示します。
ACKNOWLEDGEMENTS
承認
The author extends his gratitude to Tom Blumer Michael Breslin, Bob Pollack and Mark J. Vincenzes, for many helpful discussions. Thanks are also due to B. Simon and M. Bernstein for bringing to author's attention a specification of the DoD Internet Protocol during 1981-82 when a detailed study of this protocol began. The author is also grateful to Jon Postel and Carl Sunshine for several informative discussions about DoD IP/TCP during the last few years.
作者は多くの役立つ議論のためにトム・Blumerマイケル・ブレズリン、ボブPollack、およびマークJ.Vincenzesに感謝します。 感謝はこのプロトコルの詳細な研究が始まったとき1981-82の間、DoDインターネットプロトコルの仕様を作者に注目していただくためのB.サイモンとM.バーンスタインのもためです。 また、作者もここ数年間DoD IP/TCPについてのいくつかの有益な議論にジョン・ポステルとカール・サンシャインに感謝しています。
REFERENCES
参照
[ADA83] Military Standard Ada(R) Programming Language, United
States Department of Defense, ANSI/MIL-STD-1815A-1983, 22
January 1983
[ADA83]軍事の標準のAda(R)プログラミング言語、合衆国国防総省、軍規格ANSI/1815A-1983、1983年1月22日
[BLUT83] Blumer, T. P., and Sidhu, D. P., "Mechanical Verification
and Automatic Implementation of Communication Protocols,"
to appear in IEEE Trans. Softw. Eng.
[BLUT83] IEEE Transで見えるBlumer、T.P.とSidhu、D.P.、「通信プロトコルの機械的な検証であって自動である実現。」 Softw。 エング。
[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.
[MILS83a] "Military Standard Internet Protocol," United States
Department of Defense, MIL-STD-1777, 12 August 1983.
[MILS83a]「軍事の標準のインターネットプロトコル」、合衆国国防総省、軍規格-1777、1983年8月12日。
[MILS83b] "Military Standard Transmission Control Protocol," United
States Department of Defense, MIL-STD-1778, 12 August 1983.
[MILS83b]「軍事の標準の通信制御プロトコル」、合衆国国防総省、軍規格-1778、1983年8月12日。
[POSJ81] Postel, J. (ed.), "DoD Standard Internet Protocol," Defense
Advanced Research Projects Agency, Information Processing
Techniques Office, RFC-791, September 1981.
[POSJ81]ポステル、J.編、「DoDの標準のインターネットプロトコル」、国防高等研究計画庁、情報処理テクニックオフィス、RFC-791、1981年9月。
[SDC82] DCEC Protocol Standardization Program: Protocol
Specification Report, System Development Corporation,
TM-7172/301/00, 29 March 1982
[SDC82]DCECは標準化プログラムについて議定書の中で述べます: プロトコル仕様レポート、システム開発社、TM-7172/301/00、1982年3月29日
[SIDD83] Sidhu, D. P., and Blumer, T. P., "Verification of NBS Class
4 Transport Protocol," to appear in IEEE Trans. Comm.
[SIDD83] IEEE Transで見えるSidhu、D.P.とBlumer、T.P.、「NBSのクラス4トランスポート・プロトコルの検証。」 Comm。
Sidhu [Page 18]
Sidhu[18ページ]
RFC 963 November 1985 Some Problems with MIL-STD IP
RFC963 1985年11月 軍規格IPに関するいくつかの問題
[SIDD84] Sidhu, D. P., and Blumer, T. P., "Some Problems with the
Specification of the Military Standard Transmission Control
Protocol," in Protocol Specification, Testing and
Verification IV, (ed.) Y. Yemini et al (1984).
[SIDD84]Sidhu、D.P.とBlumer、T.P.、プロトコル仕様、テスト、および検証IVにおける「軍事の標準の通信制御プロトコルの仕様に関するいくつかの問題」編 Y。 Yemini他(1984)。
Sidhu [Page 19]
Sidhu[19ページ]
一覧
スポンサーリンク
