Network Working Group G. Swallow
Request for Comments: 4928 S. Bryant
BCP: 128 Cisco Systems, Inc.
Category: Best Current Practice L. Andersson
Acreo AB
June 2007
Avoiding Equal Cost Multipath Treatment in MPLS Networks
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.
この文書では、現在展開MPLSネットワークのイコールコストマルチパス（ECMP）の動作を説明します。この文書では、複数の異なる等コストパスの上に同じフローと異なるパケットの送信に起因することができます並べ替えを避けたいMPLSネットワーク上で実行するアプリケーションを定義する人のためのベストプラクティスの推奨事項になります。これらの推奨事項は、パケット内のIPバージョン番号フィールドの検査に依存しています。勧告のヒューリスティックな性質にもかかわらず、彼らはIPのバージョン番号の将来の割り当てが何らかの目的のために作られた場合でも、MPLSネットワークを動作させるための比較的安全な方法を提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Current ECMP Practices ..........................................2
3. Recommendations for Avoiding ECMP Treatment .....................4
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. We discuss cases where multiple packets from the same top-level LSP might be transmitted over different equal cost paths, resulting in possible mis-ordering of packets that are part of the same top-level LSP. This document also makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the resulting potential for mis-ordered packets. While disabling ECMP behavior is an option open to most operators, few (if any) have chosen to do so, and the application designer does not have control over the behavior of the networks that the application may run over. Thus, ECMP behavior is a reality that must be reckoned with.
この文書では、現在展開MPLSネットワークのイコールコストマルチパス（ECMP）の動作を説明します。我々は、同じトップレベルのLSPから複数のパケットが同じトップレベルLSPの一部であるパケットの可能誤順序で、その結果、異なる等コスト・パスを介して送信されるかもしれない場合を議論します。また、このドキュメントでは、誤発注のパケットの結果の可能性を避けたいMPLSネットワーク上で実行するアプリケーションを定義する人のためのベストプラクティスの推奨事項になります。 ECMPの動作を無効にすると、ほとんどの事業者へのオプション開いている間は、（もしあれば）、数はそうすることを選択した、およびアプリケーション設計者は、アプリケーションが上で実行可能なネットワークの振る舞いを制御できません。このように、ECMPの動作は侮れしなければならない現実があります。
ECMP Equal Cost Multipath
ECMPイコールコストマルチパス
FEC Forwarding Equivalence Class
FEC転送等価クラス
IP ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the header(s) of an IP packet
IP ECMP等しいコストルート間の次のホップの選択は、IPパケットのヘッダ（単数または複数）に基づいている転送動作
Label ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the label stack of an MPLS packet
ラベルECMP等しいコストルート間の次のホップの選択は、MPLSパケットのラベルスタックに基づいている転送動作
LSP Label Switched Path
LSPラベルスイッチパス
LSR Label Switching Router
LSRラベルスイッチングルータ
The MPLS label stack and Forwarding Equivalence Classes are defined in [RFC3031]. The MPLS label stack does not carry a Protocol Identifier. Instead the payload of an MPLS packet is identified by the Forwarding Equivalence Class (FEC) of the bottom most label. Thus, it is not possible to know the payload type if one does not know the label binding for the bottom most label. Since an LSR, which is processing a label stack, need only know the binding for the label(s) it must process, it is very often the case that LSRs along an LSP are unable to determine the payload type of the carried contents.
MPLSラベルスタックと転送等価クラスは、[RFC3031]で定義されています。 MPLSラベルスタックは、プロトコル識別子を運ぶことはありません。代わりに、MPLSパケットのペイロードは、一番下のラベルの転送等価クラス（FEC）によって識別されます。したがって、1つが下のほとんどのラベルに対するラベルバインディングを知らない場合には、ペイロードタイプを知ることは不可能です。ラベルスタックを処理しているLSRは、それだけには処理しなければならないラベル（S）のバインディングを知っている必要があるため、それは、LSPに沿ってのLSRを搭載コンテンツのペイロードタイプを判別できないことが非常によくあります。
As a means of potentially reducing delay and congestion, IP networks have taken advantage of multiple paths through a network by splitting traffic flows across those paths. The general name for this practice is Equal Cost Multipath or ECMP. In general, this is done by hashing on various fields on the IP or contained headers. In practice, within a network core, the hashing is based mainly or exclusively on the IP source and destination addresses. The reason for splitting aggregated flows in this manner is to minimize the re-ordering of packets belonging to individual flows contained within the aggregated flow. Within this document, we use the term IP ECMP for this type of forwarding algorithm.
潜在的に遅延輻輳を低減する手段として、IPネットワークトラフィックを分割することによって、ネットワークを介して複数のパスを利用しているそれらのパスを横切って流れます。この練習のための一般的な名前はイコールコストマルチパスまたはECMPです。一般に、これは、IP又は含まれるヘッダにさまざまなフィールドにハッシュすることによって行われます。実際には、ネットワークコア内で、ハッシュは、IPソースおよびデスティネーションアドレスに主として又は排他的に基づくものです。このように集約フローを分割する理由は、集約フロー内に含まれる個々のフローに属するパケットの再順序付けを最小にすることです。この文書の中で、我々は転送アルゴリズムのこのタイプのための用語IP ECMPを使用しています。
For packets that contain both a label stack and an encapsulated IPv4 (or IPv6) packet, current implementations in some cases may hash on any combination of labels and IPv4 (or IPv6) source and destination addresses.
ラベルスタックとカプセル化されたIPv4（またはIPv6）の両方を含むパケットのパケットのために、いくつかのケースでは、現在の実装では、ラベルとIPv4（またはIPv6）送信元アドレスと宛先アドレスの任意の組み合わせにハッシュすることができます。
In the early days of MPLS, the payload was almost exclusively IP. Even today the overwhelming majority of carried traffic remains IP. Providers of MPLS equipment sought to continue this IP ECMP behavior. As shown above, it is not possible to know whether the payload of an MPLS packet is IP at every place where IP ECMP needs to be performed. Thus vendors have taken the liberty of guessing the payload. By inspecting the first nibble beyond the label stack, existing equipment infers that a packet is not IPv4 or IPv6 if the value of the nibble (where the IP version number would be found) is not 0x4 or 0x6 respectively. Most deployed LSRs will treat a packet whose first nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP ECMP.
MPLSの初期の頃には、ペイロードは、ほぼ全面的にIPました。今日でも行わトラフィックの圧倒的多数は、IPのまま。 MPLS機器のプロバイダは、このIP ECMPの動作を継続しようとしました。上記のように、MPLSパケットのペイロードがIP ECMPを実行する必要があるすべての場所でIPであるかどうかを知ることは不可能です。したがって、ベンダーはペイロードを推測するの自由を取りました。ラベルスタックを越えて最初のニブルを検査することによって、既存の装置は、（IPバージョン番号が見出されるであろう）ニブルの値は、それぞれを0x4または0x6にない場合、パケットはIPv4またはIPv6ではないと推定します。ほとんどの展開のLSRは、その最初のニブルのペイロードがIP ECMPの目的のためのIPv4たかのように0x4のに等しいパケットを扱います。
A consequence of this is that any application that defines an FEC that does not take measures to prevent the values 0x4 and 0x6 from occurring in the first nibble of the payload may be subject to IP ECMP and thus having their flows take multiple paths and arriving with considerable jitter and possibly out of order. While none of this is in violation of the basic service offering of IP, it is detrimental to the performance of various classes of applications. It also complicates the measurement, monitoring, and tracing of those flows.
この結果は、ペイロードの最初のニブルに発生する値を0x4と0x6に防止策をとらないFECを定義する任意のアプリケーションがIP ECMPを受ける可能性があるということであるので、それらのフローが複数のパスを取る有すると到着しますオーダーのうち、おそらくかなりのジッタと。これのどれもが、IPの基本的なサービス提供に違反していないが、それはアプリケーションの様々なクラスの性能に有害です。また、これらのフローの測定、監視、および追跡を複雑にします。
New MPLS payload types are emerging, such as those specified by the IETF PWE3 and AVT working groups. These payloads are not IP and, if specified without constraint, might be mistaken for IP.
新しいMPLSペイロードタイプは、IETF PWE3およびAVTワーキンググループによって指定されたものとして、浮上しています。これらのペイロードは、IPされていないと、制約なしに指定されている場合は、IPのために誤解されるかもしれません。
It must also be noted that LSRs that correctly identify a payload as not being IP most often will load-share traffic across multiple equal-cost paths based on the label stack. Any reserved label, no matter where it is located in the stack, may be included in the computation for load balancing. Modification of the label stack between packets of a single flow could result in re-ordering that flow. That is, were an explicit null or a router-alert label to be added to a packet, that packet could take a different path through the network.
また、注意しなければならないことを正しくIPが最も頻繁にロードシェアますトラフィックをラベルスタックに基づいて複数の等コストパス間ではないとペイロードを特定のLSR。任意の予約されたラベル、それがスタックに配置されていない問題では、負荷分散のための計算に含めてもよいです。単一のフローのパケット間のラベルスタックの変更は流れ並べ替えにつながる可能性があります。これは、明示的にnullまたはルータアラートラベルだったが、パケットに付加されるようにされ、そのパケットは、ネットワークを介して別のパスを取ることができます。
Note that for some applications, being mistaken for IPv4 may not be detrimental. The trivial case being where the payload behind the top label is a packet belonging to an MPLS IPv4 VPN. Here the real payload is IP and most (if not all) deployed equipment will locate the end of the label stack and correctly perform IP ECMP.
一部のアプリケーションでは、IPv4の誤解であることは有害ではないかもしれないことに注意してください。トップラベルの後ろにペイロードがMPLS IPv4のVPNに属するパケットである些細な場合があります。ここでは、実際のペイロードは、IPと（すべてではない）の機器は、ラベルスタックの最後を見つけ、正しくIP ECMPを実行します展開最もです。
A less obvious case is when the packets of a given flow happen to have constant values in the fields upon which IP ECMP would be performed. For example, if an Ethernet frame immediately follows the label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6, then either the first nibble will be 0x4, or it will be something else. If the nibble is not 0x4 then no IP ECMP is performed, but Label ECMP may be performed. If it is 0x4, then the constant values of the MAC addresses overlay the fields that would have been occupied by the source and destination addresses of an IP header. In this case, the input to the ECMP algorithm would be a constant value and thus the algorithm would always return the same result.
あまり目立たない場合は、所定のフローのパケットがIP ECMPが実行されるであろう時にフィールドに一定の値を有することが起こる場合があります。イーサネットフレームは、すぐにラベルに続き、LSRがIPv4上でECMPを行いますが、IPv6の上でECMPをしない場合たとえば、その後、いずれかの最初のニブルが0x4になり、またはそれが何か他のものになります。ニブルが0x4のでなければ、何のIP ECMPは実行されませんが、ラベルECMPを実行することができます。それは0x4のであれば、MACアドレスの定数値は、IPヘッダの送信元アドレスと宛先アドレスによって占められていたフィールドをオーバーレイ。この場合には、ECMPアルゴリズムへの入力は一定値となり、従って、アルゴリズムは常に同じ結果を返すことになります。
We will use the term "Application Label" to refer to a label that has been allocated with an FEC Type that is defined (or simply used) by an application. Such labels necessarily appear at the bottom of the label stack, that is, below labels associated with transporting the packet across an MPLS network. The FEC Type of the Application label defines the payload that follows. Anyone defining an application to be transported over MPLS is free to define new FEC Types and the format of the payload that will be carried.
私たちは、アプリケーションによって定義された（あるいは単に使用）されるFECタイプに割り当てられているラベルを参照するために用語「アプリケーションラベル」を使用します。そのようなラベルは必ずしもMPLSネットワーク上でパケットを輸送するに関連付けられたラベルの下にあるラベルスタックの下部に現れます。アプリケーションラベルのFECタイプは、以下のペイロードを定義します。 MPLS上で転送されるようにアプリケーションを定義する誰もが新しいFECタイプと運ばれるペイロードのフォーマットを定義して自由です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Label | Exp |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1st Nbl| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to avoid IP ECMP treatment, it is necessary that an application take precautions to not be mistaken as IP by deployed equipment that snoops on the presumed location of the IP Version field. Thus, at a minimum, the chosen format must disallow the values 0x4 and 0x6 in the first nibble of their payload.
IP ECMP処理を回避するためには、アプリケーションがIPバージョンフィールドの推定位置にスヌープ展開機器によってIPと誤解されないように予防措置をとることが必要です。このように、最低でも、選択されたフォーマットは、それらのペイロードの最初のニブルに値を0x4と0x6にを禁止しなければなりません。
It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.
アプリケーションは、0x0の、および0x1に最初のニブル値を制限における順序パケット配信に依存することが、必要とされます。これは、いくつかの将来のルーティング機器がIPのいくつかの将来のバージョン（複数可）に類似したスヌーピングをした場合、そのトラフィックフローには影響されないことを保証します。
This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.
この動作は、複数のパス間で、単一のLSPから、将来的にIPバージョンが0x0のまたは0x1ののバージョン番号で定義されている場合、このBCPに準拠機器は、1つまたは複数のMPLSヘッダを過ぎて見ることができないであろうことを意味し、loadsplitトラフィックIPv0またはIPv1ヘッダ内の特定のフィールドのハッシュに基づきます。つまり、これらのバージョン番号を使用するIPトラフィックは、不適切なloadsplittingによって引き起こされる乱れから安全だろうされていますが、パフォーマンス上の利点を得ることができないだろう。
For an example of how ECMP is avoided in Pseudowires, see [RFC4385].
ECMPがスードワイヤに回避する方法の例については、[RFC4385]を参照してください。
This memo discusses the conditions under which MPLS traffic associated with a single top-level LSP either does or does not have the possibility of being split between multiple paths, implying the possibility of mis-ordering between packets belonging to the same top-level LSP. From a security point of view, the worse that could result from a security breach of the mechanisms described here would be mis-ordering of packets, and possible corresponding loss of throughput (for example, TCP connections may in some cases reduce the window size in response to mis-ordered packets). However, in order to create even this limited result, an attacker would need to either change the configuration or implementation of a router, or change the bits on the wire as transmitted in a packet.
このメモは、単一のトップレベルのLSPに関連付けられたMPLSトラフィックがないか、同じトップレベルLSPに属するパケットとの間の誤順序の可能性を意味する、複数の経路に分割される可能性を有していないいずれかの条件を説明します。セキュリティの観点から、ここで説明されたメカニズムのセキュリティ侵害から生じることができること悪いパケットの誤順序となり、スループットの可能な対応する損失は、（例えば、TCP接続がある場合には、ウィンドウのサイズを小さくすることができます誤発注のパケットに対する応答）。しかし、この制限された結果を作成するために、攻撃者は、ルータの構成や実装を変更し、またはパケットで送信されるようワイヤ上のビットを変更するか必要であろう。
Other security issues in the deployment of MPLS are outside the scope of this document, but are discussed in other MPLS specifications, such as [RFC3031], [RFC3036], [RFC3107], [RFC3209], [RFC3478], [RFC3479], [RFC4206], [RFC4220], [RFC4221], [RFC4378], AND [RFC4379].
MPLSの配備における他のセキュリティ問題は、この文書の範囲外であるが、このような[RFC3031]、[RFC3036]、[RFC3107]、[RFC3209]、[RFC3478]、[RFC3479]などの他のMPLS仕様、に記載されています、 [RFC4206]、[RFC4220]、[RFC4221]、[RFC4378]及び[RFC4379]。
IANA has marked the value 0x1 in the IP protocol version number space as "Reserved" and placed a reference to this document to both values 0x0 and 0x1.
IANAは、「予約」としてIPプロトコルバージョン番号空間内の値は0x1をマークし、値を0x0と0x1の両方に、この文書への参照を置いています。
Note that this document does not in any way change the policies regarding the allocation of version numbers, including the possible use of the reserved numbers for some future purpose.
この文書は、どのような方法で、いくつかの将来の目的のために予約された番号の使用の可能性を含め、バージョン番号の割り当てに関する方針を変更しないことに注意してください。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y.、およびE.ローゼン、 "BGP-4でラベル情報を運ぶ"、RFC 3107、2001年5月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y.、およびR.アガルワル、 "ラベル配布プロトコルのためのグレースフルリスタートメカニズム"、RFC 3478、2003年2月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]ファレル、A.編、 "ラベル配布プロトコル（LDP）のためのフォールトトレランス"、RFC 3479、2003年2月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、ナドー、T.、およびJ.ラング、 "トラフィックエンジニアリングリンク管理情報ベース"、RFC 4220、2005年11月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221]ナドー、T.、スリニバサン、C.、およびA.ファレルは、RFC 4221、2005年11月、 "マルチプロトコルラベルは（MPLS）管理の概要を切り替えます"。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]アラン、D.、エド。、およびT.ナドー、エド。、 "（MPLS）操作と管理（OAM）をマルチプロトコルラベルスイッチングのためのフレームワーク"、RFC 4378、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、2006年2月。
Authors' Addresses
著者のアドレス
Loa Andersson Acreo AB Electrum 236 SE-146 40 Kista Sweden
ロア・アンダーソンAcreo ABエレクトラ236 SE-146 40シスタ、スウェーデン
EMail: loa@pi.se
メールアドレス：loa@pi.se
Stewart Bryant Cisco Systems 250, Longwater, Green Park, Reading, RG2 6GB, UK
スチュワートブライアントシスコシステムズ250、Longwater、グリーンパーク、読書、RG2 6ギガバイト、英国
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
ジョージツバメシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。