[要約] RFC 2991は、ユニキャストとマルチキャストの次ホップ選択におけるマルチパスの問題についての要約です。このRFCの目的は、ネットワークのパフォーマンスと信頼性を向上させるために、マルチパスルーティングの実装に関するガイドラインを提供することです。
Network Working Group D. Thaler
Request for Comments: 2991 Microsoft
Category: Informational C. Hopps
NextHop Technologies
November 2000
Multipath Issues in Unicast and Multicast Next-Hop Selection
ユニキャストおよびマルチキャストのネクストホップ選択のマルチパスの問題
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet.
オープン最短パスファースト（OSPF）および中間システム（ISIS）から中間システム（ISIS）を含むさまざまなルーティングプロトコルは、「等しいコストマルチパス」（ECMP）ルーティングを明示的に許可します。一部のルーターの実装では、RIPおよびその他のルーティングプロトコルを使用した同コストのマルチパス使用も可能にします。フォワーダーに対するマルチパスルーティングの効果は、フォワーダーが任意の宛先にいくつかのネクストホップを持っている可能性があり、特定のデータパケットに使用する次のホップを選択するために何らかの方法を使用する必要があることです。
Various routing protocols, including OSPF and ISIS, explicitly allow "Equal-Cost Multipath" routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. Using equal-cost multipath means that if multiple equal-cost routes to the same destination exist, they can be discovered and used to provide load balancing among redundant paths.
OSPFやISISを含むさまざまなルーティングプロトコルは、「等しいコストマルチパス」ルーティングを明示的に許可しています。一部のルーターの実装では、RIPおよびその他のルーティングプロトコルを使用した同コストのマルチパス使用も可能にします。等しいコストのマルチパスを使用すると、同じ宛先への複数の等しいコストルートが存在する場合、それらを発見して使用して冗長パス間の負荷分散を提供することができます。
The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions.
フォワーダーに対するマルチパスルーティングの効果は、フォワーダーが任意の宛先にいくつかのネクストホップを持っている可能性があり、特定のデータパケットに使用する次のホップを選択するために何らかの方法を使用する必要があることです。このメモは、現在のプラクティス、問題、およびソリューションを要約しています。
Several router implementations allow multipath forwarding. This is sometimes done naively via round-robin, where each packet matching a given destination route is forwarded using the subsequent next-hop, in a round-robin fashion. This does provide a form of load balancing, but there are several problems with approaches such as round-robin or random:
いくつかのルーターの実装により、マルチパス転送が可能になります。これは、特定の宛先ルートに一致する各パケットが、ラウンドロビンのファッションで後続のネクストホップを使用して転送されるラウンドロビンを介して素朴に行われることがあります。これはロードバランシングの形式を提供しますが、ラウンドロビンやランダムなどのアプローチにはいくつかの問題があります。
Variable Path MTU Since each of the redundant paths may have a different MTU, this means that the overall path MTU can change on a packet-by-packet basis, negating the usefulness of path MTU discovery.
可変経路MTU冗長パスのそれぞれが異なるMTUを持っている可能性があるため、これはパスごとのパケットベースでMTU全体が変化し、パスMTU発見の有用性を無効にすることを意味します。
Variable Latencies Since each of the redundant paths may have a different latency involved, having packets take separate paths can cause packets to always arrive out of order, increasing delivery latency and buffering requirements.
さまざまなレイテンシー冗長なパスのそれぞれが異なるレイテンシを伴う可能性があるため、パケットを個別に実行すると、パケットが常に故障して到着し、配送遅延とバッファリング要件が増加する可能性があります。
Packet reordering causes TCP to believe that loss has taken place when packets with higher sequence numbers arrive before an earlier one. When three or more packets are received before a "late" packet, TCP enters a mode called "fast-retransmit" [6] which consumes extra bandwidth (which could potentially cause more loss, decreasing throughput) as it attempts to unnecessarily retransmit the delayed packet(s). Hence, reordering can be detrimental to network performance.
パケットの並べ替えにより、TCPは、より高いシーケンス番号のパケットが以前のパケットの前に到着したときに損失が発生したと信じるようになります。「遅い」パケットの前に3つ以上のパケットが受信されると、TCPは「Fast-Retransmit」[6]と呼ばれるモードに入ります。パケット。したがって、並べ替えは、ネットワークのパフォーマンスに有害な場合があります。
Debugging Common debugging utilities such as ping and traceroute are much less reliable in the presence of multiple paths and may even present completely wrong results.
PingやTracerouteなどの一般的なデバッグユーティリティのデバッグは、複数のパスの存在下でははるかに信頼性が低く、完全に間違った結果をもたらすことさえあります。
In multicast routing, the problem with multiple paths is that multicast routing protocols prevent loops and duplicates by constructing a single tree to all receivers of the same group address. Multicast routing protocols deployed today (DVMRP, PIM-DM, PIM-SM) [2] construct shortest-path trees rooted at either the source, or another router known as a Core or Rendezvous Point. Hence, the way they ensure that duplicates will not arise is that a given tree must use only a single next-hop towards the root of the tree.
マルチキャストルーティングでは、複数のパスの問題は、マルチキャストルーティングプロトコルが同じグループアドレスのすべての受信機に単一のツリーを構築することにより、ループと重複を防ぐことです。今日展開されているマルチキャストルーティングプロトコル（DVMRP、PIM-DM、PIM-SM）[2]は、ソースまたはコアまたはランデブーポイントとして知られる別のルーターに根付いた最短パスツリーを構築します。したがって、それらが複製が発生しないことを保証する方法は、特定のツリーがツリーのルートに向かって単一のネクストホップのみを使用する必要があるということです。
In the remainder of this document, we will use the term "flow" to represent the granularity at which the router keeps state (if at all) for classes of traffic. The exact definition of a flow may depend on the actual implementation. For example, a flow might be identified solely by destination address, or it might be identified by (source address, destination address, protocol id) triplet. Hence "flow" is not necessarily synonymous with the term "microflow" as used in RFC 2474 [7], which also includes port numbers. Indeed, including transport-layer information in the next-hop selection process can actually be problematic. For example, if packets are fragmented, the transport-layer information may not be available in every packet. Furthermore, having the choice of path depend on transport-layer fields may negate the benefit of caching information such as MTU for use in subsequent connections between the same endpoints.
このドキュメントの残りの部分では、「フロー」という用語を使用して、トラフィックのクラスのためにルーターが状態を保持する粒度を表します。フローの正確な定義は、実際の実装に依存する場合があります。たとえば、フローは宛先アドレスのみで識別されるか、（ソースアドレス、宛先アドレス、プロトコルID）トリプレットによって識別される場合があります。したがって、「フロー」は、ポート番号を含むRFC 2474 [7]で使用される「マイクロフロー」という用語と同義語ではありません。実際、次のホップ選択プロセスに輸送層情報を含めることには、実際には問題があります。たとえば、パケットが断片化されている場合、すべてのパケットで輸送層情報が利用できない場合があります。さらに、パスを選択すると、輸送層フィールドに依存することは、同じエンドポイント間の後続の接続で使用するためにMTUなどのキャッシュ情報の利点を無効にする可能性があります。
All of the problems outlined in the previous section arise when packets in the same unicast or multicast "flow" are split among multiple paths. The natural solution is therefore to ensure that packets for the same flow always use the same path.
前のセクションで概説されているすべての問題は、同じユニキャストまたはマルチキャストの「フロー」のパケットが複数のパスに分割されると発生します。したがって、自然な解決策は、同じフローのパケットが常に同じパスを使用するようにすることです。
Two additional features are desirable:
2つの追加機能が望ましいです。
Minimal disruption When multipath is used, meaning that multiple routes contribute valid next-hops, the chances are higher of routes being added and deleted from consideration than when only the "best" route is used (in which case metric changes in alternate routes have no effect on traffic paths). Since a higher number of routes may actually be used for forwarding when multipath is in use, the potential for packet reordering and packet loss due to route flaps can be much greater than when not using multipath. Hence, it is desirable to minimize the number of active flows affected by the addition or deletion of another next-hop.
マルチパスを使用する場合の最小限の混乱、つまり、複数のルートが有効な次のホップを提供することを意味します。「最良の」ルートのみが使用される場合よりも、考慮事項から削除され、削除される可能性が高くなります（代替ルートのメトリックの変化にはありません。トラフィックパスへの影響）。MultiPathが使用されている場合、実際にはより多くのルートが転送に使用される可能性があるため、ルートフラップによるパケットの再注文とパケット損失の可能性は、MultiPathを使用しない場合よりもはるかに大きくなります。したがって、別のネクストホップの追加または削除によって影響を受けるアクティブフローの数を最小限に抑えることが望ましいです。
Fast implementation The amount of additional computation required to forward a packet should be small. For example, when doing round-robin, this computation might consist of incrementing (modulo the number of next-hops) a next-hop index.
迅速な実装パケットを転送するために必要な追加の計算額は小さい必要があります。たとえば、ラウンドロビンを実行する場合、この計算は次のホップインデックスである増加（次のホップの数をmodulo）で構成する場合があります。
We now provide three possible methods for improving the performance of multipath and then discuss their applicability to unicast and multicast forwarding.
現在、MultiPathのパフォーマンスを向上させるための3つの可能な方法を提供し、ユニキャストとマルチキャストの転送への適用性について議論します。
Modulo-N Hash To select a next-hop from the list of N next-hops, the router performs a modulo-N hash over the packet header fields that identify a flow. This has the advantage of being fast, at the expense of (N-1)/N of all flows changing paths whenever a next-hop is added or removed.
modulo-nハッシュN Next-HopのリストからNext-Hopを選択するために、ルーターは、フローを識別するパケットヘッダーフィールド上でModulo-Nハッシュを実行します。これには、次のホップが追加または削除されるたびにパスを変えるすべてのフローの（n-1）/nを犠牲にして、速くなるという利点があります。
Hash-Threshold The router first selects a key by performing a hash over the packet header fields that identify the flow. The N next-hops have been assigned unique regions in the hash function's output space. By comparing the hash value against region boundaries the router can determine which region the hash value belongs to and thus which next-hop to use. This method has the advantage of only affecting flows near the region boundaries (or thresholds) when next-hops are added or removed. For ECMP hash-threshold's lookup can be done with a simple division (hash_value / fixed_region_size). When a next-hop is added or removed, between 1/4 and 1/2 of all flows change paths. An analysis of this method can be found in [3].
ハッシュスレッジルーターは、最初にフローを識別するパケットヘッダーフィールドにハッシュを実行することにより、キーを選択します。N Next-Hopsには、ハッシュ関数の出力スペースに一意の領域が割り当てられています。ハッシュ値を領域の境界と比較することにより、ルーターはハッシュ値がどの領域に属するか、したがって使用する次のホップを決定できます。この方法には、ネクストホップが追加または削除されたときに、領域の境界（またはしきい値）の近くのフローのみに影響を与えるという利点があります。ECMPの場合、Hash-Thresholdのルックアップは、単純な分割（hash_value / sixed_region_size）で実行できます。次のホップが追加または削除されると、すべてのフローの1/4から1/2の間にパスが変わります。この方法の分析は[3]にあります。
Highest Random Weight (HRW) The router computes a key for EACH next-hop by performing a hash over the packet header fields that identify the flow, as well as over the address of the next-hop. The router then chooses the next-hop with the highest resulting key value [4]. This has the advantage of minimizing the number of flows affected by a next-hop addition or deletion (only 1/N of them), but is approximately N times as expensive as a modulo-N hash.
最高のランダム重量（HRW）ルーターは、フローを識別するパケットヘッダーフィールドと次のホップのアドレス上でハッシュを実行することにより、各ネクストホップのキーを計算します。次に、ルーターは、結果として最も高いキー値を持つ次のホップを選択します[4]。これには、ネクストホップの追加または削除の影響を受けるフローの数を最小限に抑えるという利点がありますが（そのうち1/nのみ）、Modulo-nハッシュのほぼn倍も高価です。
The applicability of these three alternatives depends on (at least) two factors: whether the forwarder maintains per-flow state, and how precious CPU is to a multipath forwarder.
これら3つの代替品の適用性は、（少なくとも）2つの要因に依存します。フォワーダーが流量あたりの状態を維持するかどうか、およびマルチパス転送業者にとってCPUの貴重なCPUです。
Some routers may maintain per-flow state for reasons other than for supporting multipath. For example, routers typically keep per-flow state for multicast flows so that they can maintain the list of interfaces to which packets in the flow should be copied.
一部のルーターは、マルチパスをサポートする以外の理由により、流量あたりの状態を維持する場合があります。たとえば、ルーターは通常、マルチキャストフローのためにフローごとの状態を保持しているため、フロー内のパケットをコピーするインターフェイスのリストを維持できます。
If per-flow state is maintained in a multipath forwarder, then computation of the next-hop can be done by the router at state creation time. This entails no additional computations at packet forwarding time compared with normal forwarding to a single next-hop, since the next-hop is precomputed. In this case, any method can be used, including round-robin, random, modulo-N, hash-threshold or HRW. Hash functions such as modulo-N, hash-threshold and HRW are better if the forwarder state may be deleted for any reason during the lifetime of a flow since subsequent next-hop computations by the router will always select the same path. This also improves the usefulness of debugging utilities such as traceroute. Finally, to maximize the stability of paths (and hence the usefulness of traceroute, etc.), the use of HRW is recommended over the other methods mentioned herein.
フローごとの状態がマルチパスの転送者で維持されている場合、次のホップの計算は、州の作成時にルーターによって実行できます。これには、次のホップが事前に計算されているため、単一のネクストホップへの通常の転送と比較して、パケット転送時間での追加の計算は必要ありません。この場合、ラウンドロビン、ランダム、モジュロ-N、ハッシュスレッジホールド、またはHRWなどの方法を使用できます。Modulo-N、Hash-rshold、HRWなどのハッシュ関数は、フローの寿命の間に何らかの理由で転送状態が削除される場合がある場合、ルーターによる次のネクストホップ計算は常に同じパスを選択します。これにより、Tracerouteなどのデバッグユーティリティの有用性も向上します。最後に、パスの安定性を最大化するため（したがって、Tracerouteなどの有用性など）、ここに記載されている他の方法よりもHRWの使用が推奨されます。
If per-flow state is not maintained by the forwarder, then using multiple next-hops requires that the next-hop be calculated at packet arrival time. When CPU is more precious than stability of flow paths, hash-threshold is recommended over the other methods mentioned herein.
フローごとの状態がフォワーダーによって維持されていない場合、複数のネクストホップを使用するには、パケットの到着時刻に次のホップを計算する必要があります。CPUがフローパスの安定性よりも貴重である場合、ここに記載されている他の方法よりもハッシュスレッジホールドが推奨されます。
Depending on the implementation, unicast forwarding may or may not keep per-flow state. We recommend that where forwarder implementations keep flow state, routers should use HRW at state creation time (and next-hop deletion time) to select the next-hop, and that forwarders without per-flow state use hash-threshold.
実装に応じて、ユニキャストの転送は、流量あたりの状態を維持する場合と維持する場合があります。フォワーダーの実装がフロー状態を維持する場合、ルーターは次のホップを選択するために州の作成時間（および次のホップ削除時間）でHRWを使用する必要があり、フローごとの状態のないフォワーダーはハッシュスレッジホルドを使用することをお勧めします。
Today's multicast forwarding engines use a cache of forwarding entries indexed by group (or group prefix) and source (or source prefix). This means that today's multicast forwarder's always keep per-flow state, although for some multicast routing protocols, the "flow" may be fairly coarse (e.g., traffic from all sources to the same destination). Since per-flow state is kept by the forwarder, it is recommended that the router always use HRW to select the next-hop.
今日のマルチキャスト転送エンジンは、グループ（またはグループプレフィックス）とソース（またはソースプレフィックス）によってインデックス付けされた転送エントリのキャッシュを使用しています。これは、今日のマルチキャストのフォワーダーが常に流量あたりの状態を維持することを意味しますが、一部のマルチキャストルーティングプロトコルの場合、「フロー」はかなり粗い場合があります（たとえば、すべてのソースから同じ宛先へのトラフィックなど）。フローごとの状態はフォワーダーによって保持されているため、ルーターは常にHRWを使用して次のホップを選択することをお勧めします。
Routers using explicit-joining protocols such as PIM-SM [5] should thus use the multipath information when determining to which neighbor a join message should be sent. For example, when multiple next-hops exist for a given Rendezvous Point (RP) toward which a (*,G) Join should be sent, it is recommended that HRW be used to select the next-hop to use for each group.
したがって、PIM-SM [5]などの明示的な結合プロトコルを使用するルーターしたがって、接続メッセージを送信する隣接を決定する際には、マルチパス情報を使用する必要があります。たとえば、（*、g）結合が送信される特定のランデブーポイント（RP）に複数のネクストホップが存在する場合、各グループに使用する次のホップを選択するためにHRWを使用することをお勧めします。
The algorithms discussed above (except round-robin) all rely on some form of hash function. Equal flow distribution is achieved when the hash function is uniformly distributed. Since the commonly used hash functions only become uniformly distributed when the number of inputs is relatively large, these algorithms are more applicable to routers used to route many flows, than in, for example, a small business setting.
上記のアルゴリズム（ラウンドロビンを除く）はすべて、何らかの形のハッシュ関数に依存しています。ハッシュ関数が均一に分布すると、等しい流れ分布が達成されます。一般的に使用されるハッシュ関数は、入力の数が比較的大きい場合にのみ均一に分布するため、これらのアルゴリズムは、たとえば小規模ビジネスの設定よりも多くのフローをルーティングするために使用されるルーターにより適用可能です。
A related problem occurs when multiple parallel links are used between the same pair of routers. A common solution is to bundle the two links together into a "super"-link when is then used for routing. For multicast forwarding, this results in the two links being reduced to a single next-hop (over the combined link) which can be used to prevent duplicates. When a unicast or multicast packet is queued to the combined link, some method, such as those discussed earlier, is still required to determine the physical link on which to transmit the packet. If the parallel links are identical, then most of the concerns discussed in this document are avoided with the combined link. The exception is packet reordering, which can still occur with round-robin, adversely affecting TCP.
関連する問題は、同じルーターのペア間で複数の平行リンクが使用される場合に発生します。一般的な解決策は、2つのリンクを一緒に「スーパー」リンクにバンドルすることです。その後、ルーティングに使用されます。マルチキャスト転送の場合、これにより、2つのリンクが1つの次のホップ（結合リンク上）に削減され、重複を防ぐために使用できます。ユニキャストまたはマルチキャストパケットが複合リンクにキューにキューになった場合、パケットを送信するための物理リンクを決定するために、前述の方法などのいくつかの方法が必要です。並列リンクが同一の場合、このドキュメントで説明されている懸念のほとんどは、結合リンクで回避されます。例外はパケットの並べ替えです。これは、ラウンドロビンで発生する可能性があり、TCPに悪影響を及ぼします。
This document discusses issues with various methods of choosing a next-hop from among multiple valid next-hops. As such, it does not directly impact the security of the Internet infrastructure or its applications.
このドキュメントでは、複数の有効なネクストホップの中から次のホップを選択するさまざまな方法に関する問題について説明します。そのため、インターネットインフラストラクチャまたはそのアプリケーションのセキュリティに直接影響しません。
One issue that is worth mentioning, however, is that when next-hop selection is predictable, an attacker can synthesize traffic that will all hash the same, making it possible to launch a denial-of-service attack that overloads a particular path. Since a special case of this is when the same (single) next-hop is always selected, such an attack is easiest when multipath is not being used. Introducing multipath routing can make such an attack more difficult; the more unpredictable the hash is, the harder it becomes to conduct a denial-of-service attack against any single link.
ただし、言及する価値のある問題の1つは、Next-Hopの選択が予測可能である場合、攻撃者がすべて同じものをハッシュするトラフィックを合成し、特定のパスを過負荷にするサービス拒否攻撃を開始できることです。これの特別なケースは、同じ（シングル）ネクストホップが常に選択される場合であるため、そのような攻撃はマルチパスが使用されていない場合に最も簡単です。マルチパスルーティングを導入すると、このような攻撃がより困難になる可能性があります。ハッシュが予測できないほど、単一のリンクに対するサービス拒否攻撃を実施するのが難しくなります。
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[2] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.
[2] Maufer、T。、「エンタープライズにIPマルチキャストの展開」、Prentice-Hall、1998。
[3] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[3] Hopps、C。、「等しいコストのマルチパスアルゴリズムの分析」、RFC 2992、2000年11月。
[4] Thaler, D., and C.V. Ravishankar, "Using Name-Based Mappings to Increase Hit Rates", IEEE/ACM Transactions on Networking, February 1998.
[4] Thaler、D。、およびC.V.Ravishankar、「名前ベースのマッピングを使用してヒット率を上げる」、1998年2月、ネットワーキングでのIEEE/ACMトランザクション。
[5] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[5] Estrin、D.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L. wei、 "Protocol Independent Multicast-Sparseモード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[6] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[6] Allman、M.、Paxson、V。and W. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。
[7] Nichols, K., Blake, S., Baker, F. and D. Black., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[7] Nichols、K.、Blake、S.、Baker、F。and D. Black。、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond、WA 98052
Phone: +1 425 703 8835
EMail: dthaler@dthaler.microsoft.com
Christian E. Hopps NextHop Technologies, Inc. 517 W. William Street Ann Arbor, MI 48103-4943 U.S.A
Christian E. Hopps Nexthop Technologies、Inc。517 W. William Street Ann Arbor、MI 48103-4943 U.S.A
Phone: +1 734 936 0291
EMail: chopps@nexthop.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。