[要約] RFC 4928は、MPLSネットワークでの等価コスト多経路処理の回避に関するガイドラインです。その目的は、ネットワークのパフォーマンスを向上させ、トラフィックの均等な分散を実現することです。
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
MPLSネットワークでの等しいコストマルチパストリートメントを回避します
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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）によって識別されます。したがって、ボトムのほとんどのラベルのラベルバインディングがわからない場合、ペイロードタイプを知ることはできません。ラベルスタックを処理しているLSRは、処理する必要があるラベルのバインディングを知る必要があるため、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は、最初のニブルが0x4に等しいパケットを、IP ECMPの目的でペイロードがIPv4であるかのように扱います。
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.
IETF PWE3およびAVTワーキンググループによって指定されたものなど、新しいMPLSペイロードタイプが出現しています。これらのペイロードは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ではないとペイロードを正しく識別するLSRSが、ラベルスタックに基づいて複数の等しいコストパスにわたってロードシェアトラフィックをロードすることに注意する必要があります。スタック内の場所に関係なく、予約済みのラベルは、負荷分散のための計算に含まれる場合があります。単一のフローのパケット間のラベルスタックの変更により、その流れが再注文される可能性があります。つまり、パケットに追加される明示的なヌルまたはルーターアラートラベルで、そのパケットはネットワークを通して別のパスをとることができました。
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.
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.
この動作は、将来、IPバージョンが0x0または0x1のバージョン番号で定義されている場合、このBCPに準拠した機器が過去の1つ以上のMPLSヘッダーを見ることができず、複数のパスにわたって単一のLSPからのロードスプリットトラフィックを見ることができないことを意味します。IPv0またはIPv1ヘッダーの特定のフィールドのハッシュに基づいています。つまり、これらのバージョン番号を採用するIPトラフィックは、不適切なロードスプリッティングによって引き起こされる障害から安全ですが、パフォーマンスの利点も得ることができません。
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]、[RFC3107]、[RFC3209]、[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] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「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. Rosen、「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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479] Farrel、A.、ed。、「ラベル分布プロトコル（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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、Nadeau、T。、およびJ. Lang、「トラフィックエンジニアリングリンク管理情報ベース」、RFC 4220、2005年11月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221] Nadeau、T.、Srinivasan、C。、およびA. Farrel、「Multiprotocol Label Switching（MPLS）管理概要」、RFC 4221、2005年11月。
[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] Allan、D.、ed。、およびT. Nadeau、ed。、「マルチプロトコルラベルスイッチング（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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
Authors' Addresses
著者のアドレス
Loa Andersson Acreo AB Electrum 236 SE-146 40 Kista Sweden
Loa Andersson Acreo AB Electrum 236 SE-146 40 Kista Sweden
EMail: loa@pi.se
Stewart Bryant Cisco Systems 250, Longwater, Green Park, Reading, RG2 6GB, UK
スチュワートブライアントシスコシステム250、ロングウォーター、グリーンパーク、リーディング、RG2 6GB、英国
EMail: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
George Swallow Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719
EMail: swallow@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。