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.

著作権(C)インターネット協会(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)の中間システムを含む様々なルーティングプロトコルが、明示的に「等価コストマルチパス」(ECMP)ルーティングを可能にします。いくつかのルータの実装はまた、RIPと他のルーティングプロトコルと等価コストマルチパスの使用を可能にします。フォワーダ上のマルチパスルーティングの効果は、フォワーダは、潜在的に任意の宛先のためのいくつかの次のホップを有し、所与のデータパケットのために使用されるべき次のホップを選択するために、いくつかの方法を使用しなければならないということです。

1. Introduction
1. はじめに

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.

フォワーダ上のマルチパスルーティングの効果は、フォワーダは、潜在的に任意の宛先のためのいくつかの次のホップを有し、所与のデータパケットのために使用されるべき次のホップを選択するために、いくつかの方法を使用しなければならないということです。このメモは、現在のプラクティス、問題、および解決策をまとめました。

2. Concerns
2.懸念

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.

変数Path 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.
        

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]のソース、またはCoreまたはランデブーポイントとして知られている他のルータのいずれかをルート最短パス木を構築します。したがって、彼らは重複が生じないことを確実な方法は、与えられたツリーは、ツリーのルートの方にのみ、単一のネクストホップを使用しなければならないということです。

3. Requirements
3.要件

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)トリプレットによって識別されるかもしれません。したがって、「フロー」は、ポート番号を含む[7]、必ずしもRFC 2474で使用される用語「マイクロ」と同義ではありません。実際、次ホップ選択処理におけるトランスポートレイヤ情報を含めて、実際に問題となり得ます。パケットが断片化されている場合、例えば、トランスポート層の情報は、すべてのパケットに利用可能ではないかもしれません。また、経路の選択を有する同一のエンドポイント間の後続の接続で使用するためにそのような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:

二つの追加機能が望まれています。

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.

最小限の中断マルチパスが使用される場合、複数のルートが有効な次ホップを寄与することを意味する可能性が唯一の「最良の」ルートを使用した場合よりも考察から追加及び削除されるルートの高い(代替ルート内のメトリックの変更がない有する場合トラフィックパスへの影響)。マルチパスが使用中であるときの経路のより高い数は、実際に転送するために使用することができるので、原因経路フラップにパケットの並び替え、パケット損失の可能性は、マルチパスを使用しない場合よりもはるかに大きくすることができます。したがって、別のネクストホップの付加または欠失によって影響を受けるアクティブフローの数を最小限にすることが望ましいです。

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.

高速実装では、パケットを転送するために必要な追加の計算量は小さいはずです。ラウンドロビンを行う場合、例えば、この計算は、(次のホップの数を法)次ホップインデックスをインクリメントから成るかもしれません。

4. Solutions
4.ソリューション

We now provide three possible methods for improving the performance of multipath and then discuss their applicability to unicast and multicast forwarding.

現在、マルチパスのパフォーマンスを改善するための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.

モジュロNハッシュがN次のホップのリストから次のホップを選択するには、ルータは、フローを識別パケットヘッダフィールド上モジュロ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ネクストホップは、ハッシュ関数の出力空間でユニークな領域を割り当てられています。領域境界に対してハッシュ値を比較することにより、ルータは、ハッシュ値が属する領域を判定することができるので、次のホップが使用します。この方法は、次のホップが追加または削除された領域の境界(またはしきい値)付近の流れに影響を与えるという利点を有します。 ECMPハッシュ・スレッショルドの検索のために、単純な割り算(HASH_VALUE / fixed_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)によって影響を受けるフローの数を最小限にするという利点を有するが、モジュロ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.

フォワーダは、フローごとの状態を維持しているかどうか、そしてどのように貴重なCPUは、マルチパスフォワーダにある。これらの3つの選択肢の適用は、(少なくとも)二つの要因によって異なります。

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を含め、使用することができます。ルータによるその後のネクストホップ計算が常に同じパスを選択するので、フォワーダ状態はフローの存続期間中に何らかの理由で削除されてもよい場合、このようなモジュロN、ハッシュ閾値とHRWとしてハッシュ関数が優れています。また、これは、このようなトレースルートなどのデバッグユーティリティの有用性を向上させます。最後に、パス(および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は、流路の安定性よりも貴重である場合、ハッシュ閾値は、本明細書に記載の他の方法よりも推奨されます。

4.1. Unicast Forwarding
4.1. ユニキャスト転送

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を使用し、フォワーダーフローごとの状態を使用するハッシュしきい値なしのことをすべきであることをお勧めします。

4.2. Multicast Forwarding
4.2. マルチキャスト転送

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が各グループに使用する次のホップを選択するために使用することが推奨されます。

5. Applicability
5.適用性

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.

(ラウンドロビン除く)上述のアルゴリズムのすべては、ハッシュ関数の何らかの形態に依存しています。ハッシュ関数が均一に分布している場合に等しい流量分布が達成されます。一般的に使用されるハッシュ関数のみ均一入力の数が比較的多い場合、分散になるので、これらのアルゴリズムは、例えば、中小企業の設定、よりも、ルート多くのフローに使用されるルータに対してより適用可能です。

6. Redundant Parallel Links
6.冗長パラレルリンク

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.

複数のパラレルリンクがルータの同一の対の間に使用されるときに関連する問題が発生します。一般的な解決策は、ルーティングに使用される場合、「スーパー」-linkに一緒に2個のリンクをバンドルすることです。マルチキャスト転送のために、これは重複を防ぐために使用することができる(合成リンクを介して)単一のネクストホップに低減されている2つのリンクになります。ユニキャストまたはマルチキャストパケットを組み合わせリンクにキューイングされたときに、例えば前述のものなどのいくつかの方法が、依然としてパケットを送信するための物理リンクを決定するために必要とされます。パラレルリンクが同一である場合には、この文書で説明する懸念のほとんどが組み合わさリンクで回避されています。例外はまだ悪影響TCPに影響を与え、ラウンドロビンで発生する可能性があるパケットの並べ替え、です。

7. Security Considerations
7.セキュリティの考慮事項

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つの問題は、しかし、次ホップ選択が予測可能であるとき、攻撃者はそれが可能な特定のパスをオーバーロードサービス拒否攻撃を開始すること、すべてが同じをハッシュしますトラフィックを合成することができるということです。同じ(単一)のネクストホップが常に選択されている場合、この特殊なケースであるので、マルチパスが使用されていない場合、そのような攻撃が最も簡単です。マルチパスルーティングを導入することは、そのような攻撃をより困難にすることができます。より多くの予測不可能なハッシュは、難しく、それは、任意の単一のリンクに対するサービス拒否攻撃を行うようになっています。

8. References
8.参照文献

[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[1]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。

[2] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.

[2] Maufer、T.、 "Enterpriseの展開IPマルチキャスト"、プレンティス・ホール、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]ターレル、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード(PIM-SM):プロトコル仕様"、RFC 2362、1998年6月。

[6] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.

[6]オールマン、M.、パクソン、V.とW.スティーブンス、 "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]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒。、 "IPv4とIPv6ヘッダーの差別化されたサービス分野(DSフィールド)の定義"、RFC 2474、1998年12月。

9. Authors' Addresses
9.著者のアドレス

Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052

デーブターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052

Phone: +1 425 703 8835 EMail: dthaler@dthaler.microsoft.com

電話:+1 425 703 8835 Eメール:dthaler@dthaler.microsoft.com

Christian E. Hopps NextHop Technologies, Inc. 517 W. William Street Ann Arbor, MI 48103-4943 U.S.A

クリスチャン・E. HoppsがのNextHop Technologies社517 W.ウィリアム・ストリートアナーバー、ミシガン州48103から4943 U.S.A

Phone: +1 734 936 0291 EMail: chopps@nexthop.com

電話:+1 734 936 0291 Eメール:chopps@nexthop.com

10. Full Copyright Statement
10.完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

著作権(C)インターネット協会(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 Editor機能のための基金は現在、インターネット協会によって提供されます。