[要約] RFC 2498は、接続性を測定するためのIPPMメトリクスについての規格です。このRFCの目的は、ネットワークの接続性を定量的に評価するためのメトリクスを提供することです。
Network Working Group J. Mahdavi
Request for Comments: 2498 Pittsburgh Supercomputing Center
Category: Experimental V. Paxson
Lawrence Berkeley National Laboratory
January 1999
IPPM Metrics for Measuring Connectivity
接続性を測定するためのIPPMメトリック
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Connectivity is the basic stuff from which the Internet is made. Therefore, metrics determining whether pairs of hosts (IP addresses) can reach each other must form the base of a measurement suite. We define several such metrics, some of which serve mainly as building blocks for the others.
接続性は、インターネットを構成する基本的な要素です。したがって、ホストのペア（IPアドレス）が相互に到達できるかどうかを決定するメトリックは、測定スイートのベースを形成する必要があります。私たちはいくつかのそのようなメトリックを定義し、そのうちのいくつかは主に他のビルディングブロックとして機能します。
This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. The reader is assumed to be familiar with that document.
このメモは、インターネットホストのペア間の接続に関する一連のメトリックを定義します。これは、IPPMフレームワークドキュメントであるRFC 2330で導入および説明されている概念に基づいています。読者はそのドキュメントに精通していることを前提としています。
The structure of the memo is as follows:
メモの構造は次のとおりです。
+ An analytic metric, called Type-P-Instantaneous-Unidirectional-Connectivity, will be introduced to define one-way connectivity at one moment in time. + Using this metric, another analytic metric, called Type-P-Instantaneous-Bidirectional-Connectivity, will be introduced to define two-way connectivity at one moment in time. + Using these metrics, corresponding one- and two-way analytic metrics are defined for connectivity over an interval of time.
+ Type-P-Instantaneous-Unidirectional-Connectivityと呼ばれる分析メトリックが導入され、一時的な一方向接続を定義します。 +このメトリックを使用して、Type-P-Instantaneous-Bidirectional-Connectivityと呼ばれる別の分析メトリックが導入され、一時的に双方向接続を定義します。 +これらの測定基準を使用して、対応する一方向および双方向の分析測定基準が、一定期間の接続性に対して定義されます。
+ Using these metrics, an analytic metric, called Type-P1-P2- Interval-Temporal-Connectivity, will be introduced to define a useful notion of two-way connectivity between two hosts over an interval of time. + Methodologies are then presented and discussed for estimating Type-P1-P2-Interval-Temporal-Connectivity in a variety of settings.
+ これらのメトリックを使用して、Type-P1-P2- Interval-Temporal-Connectivityと呼ばれる分析メトリックが導入され、ある時間間隔での2つのホスト間の双方向接続の有用な概念を定義します。 +次に、さまざまな設定でType-P1-P2-Interval-Temporal-Connectivityを推定するための方法論を示し、説明します。
Careful definition of Type-P1-P2-Interval-Temporal-Connectivity and the discussion of the metric and the methodologies for estimating it are the two chief contributions of the memo.
Type-P1-P2-Interval-Temporal-Connectivityの慎重な定義と、メトリックおよびそれを推定する方法論の議論は、このメモの2つの主要な貢献です。
2.1. Metric Name:
2.1. メトリック名：
Type-P-Instantaneous-Unidirectional-Connectivity
Type-P-Instantaneous-Unidirectional-Connectivity
2.2. Metric Parameters:
2.2. メトリックパラメータ：
+ Src, the IP address of a host + Dst, the IP address of a host + T, a time
+ Src、ホストのIPアドレス+ Dst、ホストのIPアドレス+ T、時間
2.3. Metric Units:
2.3. メートル単位：
Boolean.
ブール。
2.4. Definition:
2.4. 定義：
Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at time T if a type-P packet transmitted from Src to Dst at time T will arrive at Dst.
時間TでSrcからDstに送信されたタイプPパケットがDstに到着する場合、Srcには時間TでDstへの*タイプ-P-一方向-接続性*があります。
2.5. Discussion:
2.5. 討論：
For most applications (e.g., any TCP connection) bidirectional connectivity is considerably more germane than unidirectional connectivity, although unidirectional connectivity can be of interest for some security applications (e.g., testing whether a firewall correctly filters out a "ping of death"). Most applications also require connectivity over an interval, while this metric is instantaneous, though, again, for some security applications instantaneous connectivity remains of interest. Finally, one might not have instantaneous connectivity due to a transient event such as a full queue at a router, even if at nearby instants in time one does have connectivity. These points are addressed below, with this metric serving as a building block.
ほとんどのアプリケーション（TCP接続など）の場合、双方向接続は単方向接続よりもかなり緊密ですが、単方向接続は一部のセキュリティアプリケーション（たとえば、ファイアウォールが「死のping」を正しく除外しているかどうかのテスト）に関心がある場合があります。ほとんどのアプリケーションは、一定の期間にわたって接続を必要としますが、このメトリックは瞬間的なものですが、一部のセキュリティアプリケーションでは、瞬間的な接続が依然として重要です。最後に、ルーターのキューがいっぱいになるなどの一時的なイベントが原因で、すぐに接続できない場合があります。これらのポイントは以下で扱われ、このメトリックはビルディングブロックとして機能します。
Note also that we have not explicitly defined *when* the packet arrives at Dst. The TTL field in IP packets is meant to limit IP packet lifetimes to 255 seconds (RFC 791). In practice the TTL field can be strictly a hop count (RFC 1812), with most Internet hops being much shorter than one second. This means that most packets will have nowhere near the 255 second lifetime. In principle, however, it is also possible that packets might survive longer than 255 seconds. Consideration of packet lifetimes must be taken into account in attempts to measure the value of this metric.
パケットがDstにいつ到着するかを明示的に定義していないことにも注意してください。 IPパケットのTTLフィールドは、IPパケットのライフタイムを255秒に制限するためのものです（RFC 791）。実際には、TTLフィールドは厳密にホップカウント（RFC 1812）になり、ほとんどのインターネットホップは1秒よりもはるかに短くなります。つまり、ほとんどのパケットには、255秒のライフタイムがありません。ただし、原則として、パケットが255秒より長く存続する可能性もあります。このメトリックの値を測定する場合は、パケットの有効期間を考慮する必要があります。
Finally, one might assume that unidirectional connectivity is difficult to measure in the absence of connectivity in the reverse direction. Consider, however, the possibility that a process on Dst's host notes when it receives packets from Src and reports this fact either using an external channel, or later in time when Dst does have connectivity to Src. Such a methodology could reliably measure the unidirectional connectivity defined in this metric.
最後に、逆方向の接続がない場合、単方向の接続を測定するのは難しいと考えるかもしれません。ただし、Dstのホスト上のプロセスがSrcからパケットを受信すると、外部チャネルを使用して、または後でDstがSrcに接続しているときにこの事実を報告する可能性があることに注意してください。そのような方法論は、このメトリックで定義された単方向接続を確実に測定できます。
3.1. Metric Name:
3.1. メトリック名：
Type-P-Instantaneous-Bidirectional-Connectivity
Type-P-Instantaneous-Bidirectional-Connectivity
3.2. Metric Parameters:
3.2. メトリックパラメータ：
+ A1, the IP address of a host + A2, the IP address of a host + T, a time
+ A1、ホストのIPアドレス+ A2、ホストのIPアドレス+ T、時間
3.3. Metric Units:
3.3. メートル単位：
Boolean.
ブール。
3.4. Definition:
3.4. 定義：
Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional-Connectivity* at time T if address A1 has Type-P-Instantaneous-Unidirectional-Connectivity to address A2 and address A2 has Type-P-Instantaneous-Unidirectional-Connectivity to address A1.
アドレスA1にアドレスA2へのType-P-Instantaneous-Unidirectional-Connectivityがあり、アドレスA2にアドレスへのType-P-Instantaneous-Unidirectional-Connectivityがある場合、アドレスA1およびA2は時間Tで* Type-P-Instantaneous-Bidirectional-Connectivity *を持ちます。 A1。
3.5. Discussion:
3.5. 討論：
An alternative definition would be that A1 and A2 are fully connected if at time T address A1 has instantaneous connectivity to address A2, and at time T+dT address A2 has instantaneous connectivity to A1, where T+dT is when the packet sent from A1 arrives at A2. This definition is more useful for measurement, because the measurement can use a reply from A2 to A1 in order to assess full connectivity. It is a more complex definition, however, because it breaks the symmetry between A1 and A2, and requires a notion of quantifying how long a particular packet from A1 takes to reach A2. We postpone discussion of this distinction until the development of interval-connectivity metrics below.
別の定義は、時間TにアドレスA1がアドレスA2に瞬時に接続し、時間T + dTにアドレスA2がA1に瞬時に接続している場合、A1とA2は完全に接続されていることになります。 A2に到着。完全な接続性を評価するために測定ではA2からA1への応答を使用できるため、この定義は測定により役立ちます。ただし、これはA1とA2の対称性を壊し、A1からの特定のパケットがA2に到達するのにかかる時間を定量化する概念を必要とするため、より複雑な定義です。この違いの説明は、以下の間隔接続性メトリックの開発まで延期します。
4.1. Metric Name:
4.1. メトリック名：
Type-P-Interval-Unidirectional-Connectivity
Type-P-Interval-Unidirectional-Connectivity
4.2. Metric Parameters:
4.2. メトリックパラメータ：
+ Src, the IP address of a host + Dst, the IP address of a host + T, a time + dT, a duration {Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}
+ Src、ホストのIPアドレス+ Dst、ホストのIPアドレス+ T、時間+ dT、期間{コメント：したがって、閉じた間隔[T、T + dT]は時間間隔を表します。}
4.3. Metric Units:
4.3. メートル単位：
Boolean.
ブール。
4.4. Definition:
4.4. 定義：
Address Src has *Type-P-Interval-Unidirectional-Connectivity* to address Dst during the interval [T, T+dT] if for some T' within [T, T+dT] it has Type-P-instantaneous-connectivity to Dst.
アドレスSrcには、[T、T + dT]内の一部のT 'にType-P即時接続性がある場合、間隔[T、T + dT]の間にDstをアドレス指定する* Type-P-Interval-Unidirectional-Connectivity *があります。 Dst。
5.1. Metric Name:
5.1. メトリック名：
Type-P-Interval-Bidirectional-Connectivity
Type-P-Interval-Bidirectional-Connectivity
5.2. Metric Parameters:
5.2. メトリックパラメータ：
+ A1, the IP address of a host + A2, the IP address of a host + T, a time + dT, a duration {Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}
+ A1、ホストのIPアドレス+ A2、ホストのIPアドレス+ T、時間+ dT、期間{コメント：したがって、閉じた間隔[T、T + dT]は時間間隔を表します。}
5.3. Metric Units:
5.3. メートル単位：
Boolean.
ブール。
5.4. Definition:
5.4. 定義：
Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* between them during the interval [T, T+dT] if address A1 has Type-P-Interval-Unidirectional-Connectivity to address A2 during the interval and address A2 has Type-P-Interval-Unidirectional-Connectivity to address A1 during the interval.
アドレスA1がアドレスA2へのType-P-Interval-Unidirectional-ConnectivityをアドレスとアドレスA2に持つ場合、アドレスA1とA2は、インターバル[T、T + dT]の間に* Type-P-Interval-Bidirectional-Connectivity *を持ちます。間隔中にA1をアドレス指定するType-P-Interval-Unidirectional-Connectivityがあります。
5.5. Discussion:
5.5. 討論：
This metric is not quite what's needed for defining "generally useful" connectivity - that requires the notion that a packet sent from A1 to A2 can elicit a response from A2 that will reach A1. With this definition, it could be that A1 and A2 have full-connectivity but only, for example, at time T1 early enough in the interval [T, T+dT] that A1 and A2 cannot reply to packets sent by the other. This deficiency motivates the next metric.
このメトリックは、「一般的に有用な」接続を定義するために必要なものではありません。A1からA2に送信されたパケットが、A1に到達するA2からの応答を引き出すことができるという概念が必要です。この定義では、A1とA2は完全な接続性を持っている可能性がありますが、たとえば、間隔T [T、T + dT]の十分に早い時間T1でのみ、A1とA2は他から送信されたパケットに応答できません。この欠陥が次の指標の動機となっています。
6.1. Metric Name:
6.1. メトリック名：
Type-P1-P2-Interval-Temporal-Connectivity
タイプ-P1-P2-インターバル-時間的接続性
6.2. Metric Parameters:
6.2. メトリックパラメータ：
+ Src, the IP address of a host + Dst, the IP address of a host + T, a time + dT, a duration {Comment: Thus, the closed interval [T, T+dT] denotes a time interval.}
+ Src、ホストのIPアドレス+ Dst、ホストのIPアドレス+ T、時間+ dT、期間{コメント：したがって、閉じた間隔[T、T + dT]は時間間隔を表します。}
6.3. Metric Units:
6.3. メートル単位：
Boolean.
ブール。
6.4. Definition:
6.4. 定義：
Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to address Dst during the interval [T, T+dT] if there exist times T1 and T2, and time intervals dT1 and dT2, such that:
アドレスSrcには、次のような時間T1とT2、および時間間隔dT1とdT2が存在する場合、間隔[T、T + dT]の間にDstをアドレス指定する*タイプ-P1-P2-間隔-時間的接続性*があります。
+ T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. + T1+dT1 <= T2. + At time T1, Src has Type-P1 instantanous connectivity to Dst. + At time T2, Dst has Type-P2 instantanous connectivity to Src. + dT1 is the time taken for a Type-P1 packet sent by Src at time T1 to arrive at Dst. + dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 to arrive at Src.
+ T1、T1 + dT1、T2、T2 + dT2はすべて[T、T + dT]です。 + T1 + dT1 <= T2。 +時間T1で、SrcはDstにType-P1で瞬時に接続します。 +時間T2で、DstはType-P2でSrcに瞬時に接続します。 + dT1は、時刻T1でSrcによって送信されたタイプP1パケットがDstに到着するのにかかる時間です。 + dT2は、時刻T2にDstによって送信されたタイプP2パケットがSrcに到着するのにかかる時間です。
6.5. Discussion:
6.5. 討論：
This metric defines "generally useful" connectivity -- Src can send a packet to Dst that elicits a response. Because many applications utilize different types of packets for forward and reverse traffic, it is possible (and likely) that the desired responses to a Type-P1 packet will be of a different type Type-P2. Therefore, in this metric we allow for different types of packets in the forward and reverse directions.
このメトリックは、「一般的に有用な」接続を定義します。Srcは、応答を引き出すパケットをDstに送信できます。多くのアプリケーションは、フォワードトラフィックとリバーストラフィックに異なるタイプのパケットを利用するため、Type-P1パケットに対する望ましい応答が異なるタイプType-P2になる可能性があります（そうなる可能性があります）。したがって、このメトリックでは、順方向と逆方向のさまざまなタイプのパケットを許可します。
6.6. Methodologies:
6.6. 方法論：
Here we sketch a class of methodologies for estimating Type-P1-P2- Interval-Temporal-Connectivity. It is a class rather than a single methodology because the particulars will depend on the types P1 and P2.
ここでは、Type-P1-P2- Interval-Temporal-Connectivityを推定する方法論のクラスをスケッチします。詳細はタイプP1およびP2に依存するため、これは単一の方法論ではなくクラスです。
6.6.1. Inputs:
6.6.1. 入力：
+ Types P1 and P2, addresses A1 and A2, interval [T, T+dT]. + N, the number of packets to send as probes for determining connectivity. + W, the "waiting time", which bounds for how long it is useful to wait for a reply to a packet. Required: W <= 255, dT > W.
+ タイプP1およびP2、アドレスA1およびA2、間隔[T、T + dT]。 + N、接続を決定するためのプローブとして送信するパケットの数。 + W、「待機時間」。これは、パケットへの応答を待機することがどれだけ役立つかを示します。必須：W <= 255、dT>W。
6.6.2. Recommended values:
6.6.2. 推奨値：
dT = 60 seconds. W = 10 seconds. N = 20 packets.
dT = 60秒。 W = 10秒。 N = 20パケット。
6.6.3. Algorithm:
6.6.3. アルゴリズム：
+ Compute N *sending-times* that are randomly, uniformly distributed over [T, T+dT-W]. + At each sending time, transmit from A1 a well-formed packet of type P1 to A2. + Inspect incoming network traffic to A1 to determine if a successful reply is received. The particulars of doing so are dependent on types P1 & P2, discussed below. If any successful reply is received, the value of the measurement is "true". At this point, the measurement can terminate. + If no successful replies are received by time T+dT, the value of the measurement is "false".
+ [T、T + dT-W]にランダムに均一に分布するN * sending-times *を計算します。 +各送信時に、A1からタイプP1の整形式パケットをA2に送信します。 + A1への着信ネットワークトラフィックを検査して、正常な応答が受信されたかどうかを判断します。その詳細は、以下で説明するタイプP1およびP2によって異なります。成功した応答が受信された場合、測定値は「true」です。この時点で、測定を終了できます。 +時間T + dTまでに正常な応答が受信されない場合、測定値は「偽」です。
6.6.4. Discussion:
6.6.4. 討論：
The algorithm is inexact because it does not (and cannot) probe temporal connectivity at every instant in time between [T, T+dT]. The value of N trades off measurement precision against network measurement load. The state-of-the-art in Internet research does not yet offer solid guidance for picking N. The values given above are just guidelines.
このアルゴリズムは、[T、T + dT]の間のすべての瞬間で時間的接続をプローブしない（およびプローブできない）ため、不正確です。 Nの値は、測定精度とネットワーク測定負荷とのトレードオフです。最新のインターネット調査では、Nを選択するための確かなガイダンスはまだ提供されていません。上記の値は単なるガイドラインです。
6.6.5. Specific methodology for TCP:
6.6.5. TCPの具体的な方法：
A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source port N1 and dest port N2 at address A2. Network traffic incoming to A1 is interpreted as follows:
TCPポートN1ポートN2の方法では、アドレスA2で送信元ポートN1および宛先ポートN2を使用してTCP SYNパケットを送信します。 A1に着信するネットワークトラフィックは、次のように解釈されます。
+ A SYN-ack packet from A2 to A1 with the proper acknowledgement fields and ports indicates temporal connectivity. The measurement terminates immediately with a value of "true". {Comment: if, as a side effect of the methodology, a full TCP connection has been established between A1 and A2 -- that is, if A1's TCP stack acknowledges A2's SYN-ack packet, completing the three-way handshake -- then the connection now established between A1 and A2 is best torn down using the usual FIN handshake, and not using a RST packet, because RST packets are not reliably delivered. If the three-way handshake is not completed, however, which will occur if the measurement tool on A1 synthesizes its own initial SYN packet rather than going through A1's TCP stack, then A1's TCP stack will automatically terminate the connection in a reliable fashion as A2 continues transmitting the SYN-ack in an attempt to establish the connection. Finally, we note that using A1's TCP stack to conduct the measurement complicates the methodology in that the stack may retransmit the initial SYN packet, altering the number of probe packets sent.}
+ 適切な確認応答フィールドとポートを持つA2からA1へのSYN-ackパケットは、一時的な接続を示します。測定は、「true」の値ですぐに終了します。 {コメント：方法論の副作用として、完全なTCP接続がA1とA2の間に確立された場合、つまり、A1のTCPスタックがA2のSYN-ackパケットを確認し、3ウェイハンドシェイクを完了した場合-現在A1とA2の間に確立されている接続は、RSTパケットが確実に配信されないため、RSTパケットを使用せずに、通常のFINハンドシェイクを使用して切断するのが最適です。ただし、3ウェイハンドシェイクが完了していない場合、A1の測定ツールがA1のTCPスタックを経由せずに独自の初期SYNパケットを合成すると、A1のTCPスタックがA2として信頼できる方法で接続を自動的に終了します。接続を確立しようとして、SYN-ackの送信を続行します。最後に、A1のTCPスタックを使用して測定を行うと、スタックが最初のSYNパケットを再送信し、送信されるプローブパケットの数を変更する可能性があるため、方法が複雑になることに注意してください。}
+ A RST packet from A2 to A1 with the proper ports indicates temporal connectivity between the addresses (and a *lack* of service connectivity for TCP-port-N1-port-N2 - something that probably should be addressed with another metric). + An ICMP port-unreachable from A2 to A1 indicates temporal connectivity between the addresses (and again a *lack* of service connectivity for TCP-port-N1-port-N2). {Comment: TCP implementations generally do not need to send ICMP port-unreachable messages because a separate mechanism is available (sending a RST). However, RFC 1122 states that a TCP receiving an ICMP port-unreachable MUST treat it the same as the equivalent transport-level mechanism (for TCP, a RST).} + An ICMP host-unreachable or network-unreachable to A1 (not necessarily from A2) with an enclosed IP header matching that sent from A1 to A2 *suggests* a lack of temporal connectivity. If by time T+dT no evidence of temporal connectivity has been gathered, then the receipt of the ICMP can be used as additional information to the measurement value of "false".
+ 適切なポートを持つA2からA1へのRSTパケットは、アドレス間の一時的な接続（およびTCPポートN1ポートN2のサービス接続の*欠如*-おそらく別のメトリックで対処する必要があるもの）を示します。 + A2からA1に到達できないICMPポートは、アドレス間の一時的な接続を示します（ここでも、TCPポートN1ポートN2のサービス接続の*欠如*）。 {コメント：別のメカニズムが使用できるため（RSTを送信する）、TCP実装は通常、ICMPポート到達不能メッセージを送信する必要はありません。ただし、RFC 1122では、ICMPポート到達不能を受信するTCPは、同等のトランスポートレベルメカニズム（TCPの場合はRST）と同じように扱う必要があると述べています。} + ICMPホスト到達不能またはA1へのネットワーク到達不能（必ずしもそうとは限りません） A2から）A1からA2に送信された同封のIPヘッダーマッチングを使用して、一時的な接続の欠如を*推奨*します。時間T + dTまでに一時的な接続性の証拠が収集されていない場合、ICMPの受信を「false」の測定値の追加情報として使用できます。
{Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}
The comments of Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean Shapira are appreciated.
Guy Almes、Martin Horneffer、Jeff Sedayao、およびSean Shapiraのコメントに感謝します。
As noted in RFC 2330, active measurement techniques, such as those defined in this document, can be abused for denial-of-service attacks disguised as legitimate measurement activity. Furthermore, testing for connectivity can be used to probe firewalls and other security mechnisms for weak spots.
RFC 2330に記載されているように、このドキュメントで定義されているようなアクティブな測定手法は、正当な測定アクティビティを装ったサービス拒否攻撃に悪用される可能性があります。さらに、接続性のテストを使用して、ファイアウォールやその他のセキュリティ機構の弱点を探ることができます。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD, 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編集者、「インターネットホストの要件-通信層」、STD、3、RFC 1122、1989年10月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
Jamshid Mahdavi Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
Jamshid Mahdaviピッツバーグスーパーコンピューティングセンター4400 5th Avenueピッツバーグ、ペンシルバニア州15213米国
EMail: mahdavi@psc.edu
Vern Paxson MS 50A-3111 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
Vern Paxson MS 50A-3111ローレンスバークレー国立研究所カリフォルニア大学バークレー、カリフォルニア94720米国
Phone: +1 510/486-7504
EMail: vern@ee.lbl.gov
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。