[要約] RFC 2678は、接続性を測定するためのIPPMメトリックについての規格です。このRFCの目的は、ネットワークの接続性を定量的に評価するためのメトリックを提供することです。
Network Working Group J. Mahdavi
Request for Comments: 2678 Pittsburgh Supercomputing Center
Obsoletes: 2498 V. Paxson
Category: Standards Track Lawrence Berkeley National Laboratory
September 1999
IPPM Metrics for Measuring Connectivity
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
タイプP-瞬時一方向性接続と呼ばれる分析メトリックを、+、時間に一瞬に一方向接続を定義するために導入されます。このメトリックを使用して+、タイプP-瞬時双方向接続と呼ばれる別の分析メトリックは、時間的に一瞬で双方向の接続を定義するために導入されます。双方向を、これらのメトリックを使用してワン対応+分析メトリックは、時間の間隔で接続のために定義されています。
+ 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.
これらのメトリックを使用して+、タイプ-P1-P2-間隔、時間的コネクタと呼ばれる分析メトリックは、時間の間隔で2つのホスト間の双方向接続性の有用な概念を定義するために導入されます。 +方法論は、その後に提示し、設定の様々なタイプ-P1-P2間隔、時間的接続を推定するために議論されています。
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.
注意深いタイプ-P1-P2間隔、時間的接続の定義とメトリックとを推定するための方法論の議論は、メモ二主な貢献です。
Type-P-Instantaneous-Unidirectional-Connectivity
タイプ-P-瞬時-単方向-接続
+ Src, the IP address of a host + Dst, the IP address of a host + T, a time
+ SRC、ホスト+ DstののIPアドレス、ホストのIPアドレス+ T、時間
Boolean.
ブール。
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.
Srcは有し*時間TでDSTのSRCから送信されたタイプPパケットがDstのに到着する場合、時刻TにおけるタイプP-瞬時一方向性接続DSTの*。
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コネクション）双方向接続は、一方向の接続よりもかなり密接な関係である（例えば、ファイアウォールが正しく「死のピングを」フィルタリングするかどうかをテストします）。いくつかのセキュリティアプリケーション瞬間接続が関心のままのため、このメトリックは、再び、しかし、瞬間的である一方、ほとんどのアプリケーションはまた、間隔を介して接続が必要です。最後に、1時間1で近くの瞬間に接続されていない場合でも、そのようなルータでフルキューとして過渡イベントへの瞬時の接続性を持っていない可能性があります。これらの点は、このメトリックは、ビルディングブロックとして機能して、以下のアドレス指定されます。
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フィールドは255秒（RFC 791）にIPパケットの寿命を制限することを意味しています。実際にはTTLフィールドには、ほとんどのインターネットのホップが1秒よりもはるかに短いもので、厳密にホップ数（RFC 1812）することができます。これは、ほとんどのパケットが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に接続していない場合、外部チャネル、以降の時間にを使用してパケットを受信する可能性を考えてみましょう。このような方法論は、確実にこのメトリックで定義された一方向の接続性を測定することができます。
Type-P-Instantaneous-Bidirectional-Connectivity
タイプ-P-瞬時-双方向-接続
+ A1, the IP address of a host + A2, the IP address of a host + T, a time
+ A1、ホスト+ A2のIPアドレス、ホストのIPアドレス+ T、時間
Boolean.
ブール。
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は、TYPE-P-瞬時-単方向-接続していればA2とアドレスA2は、TYPE-P-瞬時-単方向-接続したアドレスに対処するために、A1、A2は、時間Tのタイプ-P-瞬時-双方向接続*を*していますA1。
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から送信されたときにT + dTはあるA1への瞬時の接続性を持っている場合、代替の定義は、A1とA2が完全に接続されていることであろうA2に到着。測定は、完全な接続性を評価するために、A2からA1への応答を使用することができますので、この定義は、測定のためのより有用です。それはA1とA2の間の対称性を破るために、しかし、より複雑な定義であり、そしてA1から特定のパケットをA2に到達するのに要する時間を定量化の概念が必要です。当社は、下記の期間、接続指標の開発まで、この区別の議論を延期します。
Type-P-Interval-Unidirectional-Connectivity
タイプ-P-間隔-単方向-接続
+ 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、ホスト+ DstののIPアドレス、ホスト+ T、時間+ dTの、持続時間のIPアドレス{コメント：このように、閉じた間隔[T、T + dTは】時間間隔を表します}
Boolean.
ブール。
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.
*タイプ-P間隔、一方向性接続*は、内のいくつかのT」の[T、T + dTは]それがタイプP-瞬時の接続性を有する場合、区間[T、T + dTの]中のDstに対処するためのSrcが有するアドレスDST。
Type-P-Interval-Bidirectional-Connectivity
タイプ-P-間隔-双方向-接続
+ 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、ホスト+ A2のIPアドレス、ホスト+ T、時間+ dTののIPアドレス、持続時間は{コメント：このように、閉じた間隔[T、T + dTが】時間間隔を表します。}
Boolean.
ブール。
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のアドレスは、アドレスA1が持っている場合は区間[T、T + dTの]中にそれらの間のタイプ-P-間隔-双方向接続*を*している期間とアドレスA2の間、A2に対処するために、P-間隔-単方向-接続を入力TYPE-P-間隔-単方向-接続をしている期間中にA1に対処します。
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.
このメトリックは、「一般的に有用な」接続を定義するために必要なのはかなりものではありません - A2にA1から送信されたパケットがA1に達するA2からの応答を引き出すことが可能という概念を必要とします。この定義では、それはA1とA2は、フル接続性を持っていることだけで、例えば、区間[T、T + dTの]で早期に十分な時間T1でA1とA2は、他の送信したパケットに返信することができないことが考えられます。この欠陥は、次のメトリックに動機を与えます。
Type-P1-P2-Interval-Temporal-Connectivity
タイプ-P1-P2間隔、時間的接続
+ 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、ホスト+ DstののIPアドレス、ホスト+ T、時間+ dTの、持続時間のIPアドレス{コメント：このように、閉じた間隔[T、T + dTは】時間間隔を表します}
Boolean.
ブール。
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は、区間[T、T + dTの]中のDstに対処するため*タイプ-P1-P2間隔、時間的接続*を有する時間T1、T2、および時間間隔DT1とDT2、その結果が存在する場合：
+ 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の型P1をinstantanous接続を有しています。 +時刻T2において、DSTはSRCに入力し-P2をinstantanous接続を持っています。 DT1を+はDstのに到着する時刻T1でSrcによって送信されたタイプP1パケットに要する時間です。 DT2を+はSrcのに到着する時刻T2でのDstによって送信されたタイプP2パケットに要する時間です。
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にパケットを送信することができます。多くのアプリケーションは、前方のパケットの異なるタイプを使用し、トラフィックを逆ので、タイプP1パケットに対する所望の応答が異なるタイプtype-P2とされる可能性（及びおそらく）です。したがって、このメトリックでは、我々は前方でのパケットの異なる種類を可能にし、方向を逆転します。
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.
ここでは、タイプ-P1-P2-間隔 - 時間的-接続を推定するための方法論のクラスをスケッチ。詳細は種類P1およびP2に依存しますので、それはクラスではなく、単一の方法論です。
+ 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、「待ち時間」、。必須：<= 255、dTのW> W.
dT = 60 seconds. W = 10 seconds. N = 20 packets.
dTが60秒を=。 = 10秒WITH。 IN = 20のパケット。
+ 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".
+計算N *送信倍*はランダムであり、均一に分布[T、T + DT-W]。 +各送信時に、A1からA2に型P1のウェルに形成されたパケットを送信します。 +成功応答が受信されたかどうかを判断するためにA1への着信ネットワークトラフィックを検査します。そうすることの詳細は、以下に説明、種類P1＆P2に依存しています。任意の正常な応答を受信した場合、測定の値が「真」です。この時点で、測定が終了することができます。 +何も成功した応答が時間T + dTので受信されない場合は、測定の値が「偽」です。
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.を選ぶための強固なガイダンスを提供していません。
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とdestポート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パケットを+は一時的な接続を示しています。測定は、「真」の値を即座に終了します。 {コメント：方法論の副作用として、完全なTCP接続はA1とA2の間で確立された、場合 - つまり、A1のTCPスタックはA2のSYN-ACKパケットを承認した場合、3ウェイハンドシェイクを完了 - その後、今A1とA2の間で確立された接続は、最高のRSTパケットを確実に配信されないため、通常のFINハンドシェイクを使用して、RSTパケットを使用していない取り壊されます。 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に+ A RSTパケットは、アドレス間の一時的な接続性を示し（およびTCPポート-N1-ポート-N2のためのサービスの接続の*不足の* - おそらく別のメトリックで対処しなければならない何かを）。 +アンICMPポート到達不能A2からA1には、アドレス（と再びTCPポート-N1-ポート-N2のためのサービスの接続の*不足の*）間の時間的な接続を示します。 {コメント：TCP実装は、一般的に別のメカニズムが利用可能であるため、（RSTを送信する）ICMPポート到達不能メッセージを送信する必要はありません。しかし、RFC 1122はICMPポート到達不能を受信TCPは（TCP、RST用）等価トランスポートレベルのメカニズムと同様に扱う必要があること。} + ICMPホスト到達不能またはネットワーク到達不能A1に（必ずしも）A2からA2 *にA1から送信された囲まれたIPヘッダ一致する*時間的接続の欠如を示唆しています。時間T + dTのことで一時的な接続性の証拠が収集されていない場合は、ICMPの領収書は、「偽」の測定値に付加情報として使用することができます。
{Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}
{コメント：同様の方法論はICMPエコー、UDP等のために必要とされています}
The comments of Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean Shapira are appreciated.
ガイAlmes、マーティンHorneffer、ジェフSedayao、そしてショーン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に記載されているように、このような本文書で定義されたもののような能動的測定技術は、正当な測定活動を装ったサービス拒否攻撃のために悪用されることができます。また、接続のための試験は、弱点のためのファイアウォール及び他のセキュリティmechnismsをプローブするために使用することができます。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD, 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、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]パクソン、V.、Almes、G.、Mahdavi、J.とM.マシス、 "IPパフォーマンス・メトリックのための枠組み"、RFC 2330、1998年5月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
Jamshid Mahdavi Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
ジャムシードMahdaviピッツバーグ・スーパーコンピューティング・センター4400 5thアベニューピッツバーグ、PA 15213 USA
EMail: mahdavi@psc.edu
メールアドレス：mahdavi@psc.edu
Vern Paxson MS 50A-3111 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
カリフォルニア州のバーン・パクソンMS-50A 3111ローレンス・バークレー国立研究所大学バークレー、CA 94720 USA
Phone: +1 510/486-7504 EMail: vern@ee.lbl.gov
電話：+1 510/486から7504 Eメール：vern@ee.lbl.gov
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。