Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6438 Univ. of Auckland
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3
November 2011
Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in Tunnels
Abstract
抽象
The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic.
IPv6フローラベルは、その使用に一定の制限があります。この文書では、IP内のIPv6トラフィックをトンネル化、特にために、等コストマルチパスルーティングにより、リンクアグリゲーションのための負荷分散のためにフローラベルを使用している場合、これらの制限が適用方法を説明します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6438.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6438で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
1.2. Flow Label Rules . . . . . . . . . . . . . . . . . . . . . 4
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 5
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
When several network paths between the same two nodes are known by the routing system to be equally good (in terms of capacity and latency), it may be desirable to share traffic among them. Two such techniques are known as equal cost multipath (ECMP) routing and link aggregation (LAG) [IEEE802.1AX]. There are, of course, numerous possible approaches to this, but certain goals need to be met:
同じ2つのノード間の複数のネットワーク経路が（容量と待ち時間に関して）同等に良好であることがルーティングシステムによって知られている場合、それらの間でトラフィックを共有することが望ましい場合があります。二つのそのような技術は、等価コストマルチパス（ECMP）ルーティングおよびリンクアグリゲーション（LAG）IEEE802.1AX]として知られています。そこにこの多数の可能なアプローチは、もちろん、ありますが、特定の目標を満たしている必要があります。
o Maintain roughly equal share of traffic on each path. (In some cases, the multiple paths might not all have the same capacity, and the goal might be appropriately weighted traffic shares rather than equal shares. This would affect the load-sharing algorithm but would not otherwise change the argument.)
Oの各経路上のトラフィックのほぼ等しい共有を維持します。 （いくつかのケースでは、複数のパスは、すべて同じ容量を持っていないかもしれない、との目標は、むしろ等しい株式よりも適切に重み付けされたトラフィックを共有している可能性があります。これは、負荷分散アルゴリズムに影響を与えるだろうが、そうでない場合は、引数を変更しません。）
o Minimize or avoid out-of-order delivery for individual traffic flows.
O個々のトラフィックフローのためのアウトオブオーダー配信を最小化または避けます。
o Minimize idle time on any path when queue is non-empty.
キューが空でないときO任意のパス上のアイドル時間を最小限に抑えます。
There is some conflict between these goals: for example, strictly avoiding idle time could cause a small packet sent on an idle path to overtake a bigger packet from the same flow, causing out-of-order delivery.
これらの目標の間にいくつかの競合があります。たとえば、厳密にアウトオブオーダー配信を引き起こし、同じ流れから大きなパケットを追い越すためにアイドルパスに送られた小さなパケットを引き起こす可能性がアイドル時間を避けること。
One lightweight approach to ECMP or LAG is this: if there are N equally good paths to choose from, then form a modulo(N) hash [RFC2991] from a defined set of fields in each packet header that are certain to have the same values throughout the duration of a flow, and use the resulting output hash value to select a particular path. If the hash function is chosen so that the output values have a uniform statistical distribution, this method will share traffic roughly equally between the N paths. If the header fields included in the hash input are consistent, all packets from a given flow will generate the same hash output value, so out-of-order delivery will not occur. Assuming a large number of unique flows are involved, it is also probable that the method will avoid idle time, since the queue for each link will remain non-empty.
一の軽量ECMPにアプローチまたはLAGはこれです：から選択してN等しく良好なパスがある場合は、同じ値を有することが特定された各パケットのヘッダ内のフィールドの定義されたセットからモジュロ（N）ハッシュ[RFC2991]を形成します流れの期間を通して、特定のパスを選択するために、結果として得られる出力のハッシュ値を使用します。ハッシュ関数は、出力値が均一な統計的分布を有するように選択される場合、この方法は、N個のパスの間に略均等にトラフィックを共有します。ヘッダフィールドは、ハッシュ入力に含まれる場合にはアウトオブオーダー配信が発生しないように所定のフローからのすべてのパケットは、同一のハッシュ出力値を生成し、一致しています。独特のフローが多数関与していると仮定すると、各リンクのキューが空のままになりますので、この方法は、アイドル時間を避けるということも考えられます。
In the remainder of this document, we will use the term "flow" to represent a sequence of packets that may be identified by either the source and destination IP addresses alone {2-tuple} or the source IP address, destination IP address, protocol number, source port number, and destination port number {5-tuple}. It should be noted that the latter is more specifically referred to as a "microflow" in [RFC2474], but this term is not used in connection with the flow label in [RFC3697].
この文書の残りでは、我々は、単独のソースおよび宛先IPアドレス{2-タプル}またはソースIPアドレス、宛先IPアドレス、プロトコルによって識別することができるパケットのシーケンスを表すために、用語「流れ」を使用します番号、ソースポート番号、宛先ポート番号{5-タプル}。後者は、より具体的には、[RFC2474]に「マイクロフロー」と呼ばれるが、この用語は[RFC3697]でフローラベルに関連して使用されていないことに留意すべきです。
The question, then, is which header fields are used to identify a flow and serve as input keys to a modulo(N) hash algorithm. A common choice when routing general traffic is simply to use a hash of the source and destination IP addresses, i.e., the 2-tuple. This is necessary and sufficient to avoid out-of-order delivery and, with a wide variety of sources and destinations as one finds in the core of the network, often statistically sufficient to distribute the load evenly. In practice, many implementations use the 5-tuple {dest addr, source addr, protocol, dest port, source port} as input keys to the hash function, to maximize the probability of evenly sharing traffic over the equal cost paths. However, including transport-layer information as input keys to a hash may be a problem for IP fragments [RFC2991] or for encrypted traffic. Including the protocol and port numbers, totaling 40 bits, in the hash input makes the hash slightly more expensive to compute but does improve the hash distribution, due to the variable nature of ephemeral ports. Ephemeral port numbers are quite well distributed [Lee10] and will typically contribute 16 variable bits. However, in the case of IPv6, transport-layer information is inconvenient to extract, due to the variable placement of and variable length of next-headers; all implementations must be capable of skipping over next-headers, even if they are rarely present in actual traffic. In fact, [RFC2460] implies that next-headers, except hop-by-hop options, are not normally inspected by intermediate nodes in the network. This situation may be challenging for some hardware implementations, raising the potential that network equipment vendors might sacrifice the length of the fields extracted from an IPv6 header.
問題は、その後、ヘッダフィールドは、フローを識別し、モジュロ（N）ハッシュアルゴリズムへの入力キーとして機能するように使用されています。一般的なトラフィックをルーティングする一般的な選択は、ソースおよび宛先IPアドレスのハッシュ、即ち、2タプルを使用するだけです。一つはネットワークのコア内に見つけ、これは、ソースと宛先の多種多様な、均等に負荷を分散することがしばしば統計的に十分な必要とアウトオブオーダー配信を回避するのに十分であると。実際に、多くの実装は、均等等コスト・パスを介してトラフィックを共有する確率を最大にするために、ハッシュ関数への入力キーとして5タプル{DESTのADDR、ソースADDR、プロトコル、DESTポート、ソースポートを}使用します。しかしながら、ハッシュへの入力キーなどを含むトランスポートレイヤ情報は、IPフラグメント[RFC2991]または暗号化されたトラフィックのために問題となり得ます。 、プロトコル、およびポート番号を含む40ビットの合計、ハッシュ入力には計算するハッシュはやや高価になるが、エフェメラルポートの可変性質によるハッシュ分布を改善しません。エフェメラルポート番号は非常によく[Lee10]配布され、典型的には16ビット変数に貢献します。ただし、IPv6の場合には、トランスポート層の情報は、可変の配置と次のヘッダの可変長のために抽出することが不便です。すべての実装は、彼らが実際のトラフィックにはめったに存在しても、次のヘッダーをスキップすることが可能でなければなりません。実際には、[RFC2460]は次のヘッダは、ホップバイホップオプションを除き、通常はネットワーク内の中間ノードによって検査されないことを意味します。この状況は、ネットワーク機器ベンダーがIPv6ヘッダから抽出されたフィールドの長さを犠牲にするかもしれないという可能性を上昇させる、いくつかのハードウェア実装のために挑戦することができます。
It is worth noting that the possible presence of a Generic Routing Encapsulation (GRE) header [RFC2784] and the possible presence of a GRE key within that header creates a similar challenge to the possible presence of IPv6 extension headers; anything that complicates header analysis is undesirable.
それは総称ルーティングカプセル化（GRE）ヘッダ[RFC2784]及びそのヘッダ内のGREキーの存在の可能性が存在する可能性は、IPv6拡張ヘッダの存在の可能性と同様の課題を作成することは注目に値します。ヘッダ解析を複雑にするものは望ましくありません。
The situation is different in IP-in-IP tunneled scenarios. Identifying a flow inside the tunnel is more complicated, particularly because nearly all hardware can only identify flows based on information contained in the outermost IP header. Assume that traffic from many sources to many destinations is aggregated in a single IP-in-IP tunnel from tunnel endpoint (TEP) A to TEP B (see figure). Then all the packets forming the tunnel have outer source address A and outer destination address B. In all probability, they also have the same port and protocol numbers. If there are multiple paths between routers R1 and R2, and ECMP or LAG is applied to choose a particular path, the 2-tuple or 5-tuple (and its hash) will be constant, and no load sharing will be achieved, i.e., polarization will occur. If there is a high proportion of traffic from one or a small number of tunnels, traffic will not be distributed as intended across the paths between R1 and R2, due to partial polarization. (Related issues arise with MPLS [MPLS-LABEL].)
状況は、IP内IPトンネリングされたシナリオで異なっています。ほとんどすべてのハードウェアのみ、最も外側のIPヘッダに含まれる情報に基づいてフローを識別することができ、特にので、トンネル内のフローを識別することは、より複雑です。多くのソースから多くの宛先へのトラフィックが（図を参照）トンネル終点（TEP）AからTEP Bに単一IPインIPトンネルに集約されているものとします。次いで、トンネルを形成するすべてのパケットがすべての確率では、外側のソースアドレスAと外側宛先アドレスBを有し、それらは、同じポート番号とプロトコル番号を持っています。ルータR1とR2、およびECMPまたはLAGの間に複数のパスが存在する場合、2組または5タプル（およびそのハッシュ）が一定となる特定のパスを選択するために適用される、無負荷の共有が実現されず、すなわち、分極が発生します。一方からのトラフィックの高い割合又はトンネルの少数がある場合、R1とR2との間の経路を横切って意図したように、トラフィックが原因部分偏光に、配布されません。 （関連問題はMPLS [MPLSラベル]で生じます）。
_____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel
here
As noted above, for IPv6, the 5-tuple is quite inconvenient to extract due to the next-header placement. The question therefore arises whether the 20-bit flow label in IPv6 packets would be suitable for use as input to an ECMP or LAG hash algorithm, especially in the case of tunnels where the inner packet header is inaccessible. If the flow label could be used in place of the port numbers and protocol number in the 5-tuple, the implementation would be simplified.
上述したように、IPv6のため、5タプルが原因次ヘッダの配置を抽出することは非常に不便です。問題は、したがって、IPv6パケット内の20ビットのフローラベルは、特に内部パケットのヘッダにアクセスできないトンネルの場合には、ECMPまたはLAGハッシュアルゴリズムへの入力として使用するのに適しているかどうかを生じます。フローラベルは5タプルのポート番号とプロトコル番号の代わりに使用することができれば、実装が簡素化されるだろう。
The flow label was left Experimental by [RFC2460] but was better defined by [RFC3697]. We quote three rules from that RFC:
フローラベルは、[RFC2460]で実験残っていたが、より良い[RFC3697]で定義されました。私たちは、そのRFCからの3つのルールを引用します：
1. "The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."
1.「ソースによって設定されたフローラベル値は、宛先ノード（複数可）に不変送達されなければなりません」。
2. "IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes."
2.「IPv6ノードは、ソースノードによって割り当てられたフローラベル値のいずれかの数学的または他の特性を仮定してはいけません。」
3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key."
3.「ルータのパフォーマンスはフローラベル値の分布に依存すべきではない。特に、単独のフローラベルビットは、ハッシュキーの貧材料を作ります。」
These rules, especially the last one, have caused designers to hesitate about using the flow label in support of ECMP or LAG. The fact is that today most nodes set a zero value in the flow label, and the first rule definitely forbids the routing system from changing the flow label once a packet has left the source node. Considering normal IPv6 traffic, the fact that the flow label is typically zero means that it would add no value to an ECMP or LAG hash, but neither would it do any harm to the distribution of the hash values.
これらのルール、特に最後のものは、ECMPまたはLAGのサポートにフローラベルを使用することについて躊躇してデザイナーを引き起こしています。実際には、今日ほとんどのノードは、フローラベルにゼロ値を設定し、最初のルールは間違いなく一度パケットがソースノードから出たフローラベルを変更ルーティングシステムを禁止することです。通常のIPv6トラフィックを考慮すると、フローラベルは、一般的にゼロであるという事実は、それがECMPまたはLAGハッシュには値を追加していないだろうが、どちらも、それはハッシュ値の分布に害をするだろうことを意味します。
However, in the case of an IP-in-IPv6 tunnel, the TEP is itself the source node of the outer packets. Therefore, a TEP may freely set a flow label in the outer IPv6 header of the packets it sends into the tunnel.
しかし、IPインのIPv6トンネルの場合には、TEPは、外側パケットの送信元ノード自体です。したがって、TEPは、自由にそれがトンネルに送信するパケットの外側のIPv6ヘッダ内のフローラベルを設定してもよいです。
The second two rules quoted above need to be seen in the context of [RFC3697], which assumes that routers using the flow label in some way will be involved in some sort of method of establishing flow state: "To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s)." The RFC should perhaps have made clear that a router that has participated in flow state establishment can rely on properties of the resulting flow label values without further signaling. If a router knows these properties, rule 2 is irrelevant, and it can choose to deviate from rule 3.
何らかの方法でフローラベルを使用してルータがフロー状態を確立する方法のいくつかの並べ替えに関与することを前提と[RFC3697]の文脈で見ることの必要上に引用された第2のルール：「フロー特定の治療を有効にするには、流動状態は、宛先（複数の）ソースからの経路上の全てまたはIPv6ノードのサブセットに確立する必要があります「。 RFCは、おそらくフロー状態設立に参加しているルータはさらにシグナリングせずに結果のフローラベル値の性質に依存していることを明らかにしている必要があります。ルータは、これらの特性を知っている場合、ルール2は無関係であり、それはルール3から逸脱することを選択できます。
In the tunneling situation sketched above, routers R1 and R2 can rely on the flow labels set by TEP A and TEP B being assigned by a known method. This allows an ECMP or LAG method to be based on the flow label consistently with [RFC3697], regardless of whether the non-tunnel traffic carries non-zero flow label values.
上記スケッチトンネリング状況では、ルータR1及びR2は、TEP Aと公知の方法で割り当てられTEP Bによって設定されたフローラベルに依存することができます。これは関係なく、非トンネルトラフィックが非ゼロフローラベル値を運ぶかどうか、[RFC3697]とECMPまたはLAG方法が一貫フローラベルに基づいてされることを可能にします。
The IETF has recently revised RFC 3697 [RFC6437]. That revision is fully compatible with the present document and obviates the concerns resulting from the above three rules. Therefore, the present specification applies both to RFC 3697 and to RFC 6437.
IETFは最近、RFC 3697 [RFC6437]を改訂しました。そのリビジョンは、本明細書に完全に互換性があり、上記の3つのルールから生じる懸念がなくなります。したがって、本明細書は、RFC 3697及びRFC 6437の両方に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
We assume that the routers supporting ECMP or LAG (R1 and R2 in the above figure) are unaware that they are handling tunneled traffic. If it is desired to include the IPv6 flow label in an ECMP or LAG hash in the tunneled scenario shown above, the following guidelines apply:
私たちは、ECMPまたはLAG（上図のR1とR2）をサポートするルータは、彼らがトンネルトラフィックを処理していることに気づいていないことを前提としています。それは上に示したトンネリングされたシナリオではECMPまたはLAGハッシュ内のIPv6フローラベルを含めることが望まれる場合は、次のガイドラインが適用されます。
o Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel endpoints (TEPs).
O内部パケットは、その送信元アドレスと宛先アドレスは、トンネルエンドポイント（TEPS）のものである外側のIPv6パケットにカプセル化されなければなりません。
o The flow label in the outer packet SHOULD be set by the sending TEP to a 20-bit value in accordance with [RFC6437]. The same flow label value MUST be used for all packets in a single user flow, as determined by the IP header fields of the inner packet.
Oアウターパケットのフローラベルは、[RFC6437]に応じて20ビット値を送信TEPによって設定されるべきです。内部パケットのIPヘッダフィールドによって決定されるような同一のフローラベル値は、単一のユーザフロー内のすべてのパケットのために使用しなければなりません。
o To achieve this, the sending TEP MUST classify all packets into flows once it has determined that they should enter a given tunnel and then write the relevant flow label into the outer IPv6 header. A user flow could be identified by the sending TEP most simply by its {destination, source} address 2-tuple or by its 5-tuple {dest addr, source addr, protocol, dest port, source port}. At present, there would be little point in using the {dest addr, source addr, flow label} 3-tuple of the inner packet, but doing so would be a future-proof option. The choice of n-tuple is an implementation choice in the sending TEP.
それは彼らが与えられたトンネルを入力し、外側のIPv6ヘッダに関連するフローラベルを書き込むべきであると決定した後、これを達成するために、Oは、送信TEPは、フローにすべてのパケットを分類しなければなりません。ユーザフローは、{宛先、送信元アドレス} 2タプルによって、またはその5タプル{DESTのADDR、ソースADDR、プロトコル、DESTポート、送信元ポート}によって最も簡単に送信TEPによって同定することができます。現在のところ、{DESTのADDR、ソースADDR、フローラベル}インナーパケットの3組を使用するが、将来性のオプションとなりそうで少しポイントが存在することになります。 nタプルの選択は、送信TEPで実装選択です。
* As specified in [RFC6437], the flow label values should be chosen from a uniform distribution. Such values will be suitable as input to a load-balancing hash function and will be hard for a malicious third party to predict.
[RFC6437]で指定されるよう*、フローラベル値は一様分布から選択されるべきです。このような値は、負荷分散ハッシュ関数への入力として適しているであろうと、悪意のある第三者が予測するためには難しいでしょう。
* The sending TEP MAY perform stateless flow label assignment by using a suitable 20-bit hash of the inner IP header's 2-tuple or 5-tuple as the flow label value.
*送信TEPは、フローラベル値として内部IPヘッダーの2タプルまたは5タプルの適切な20ビット・ハッシュを使用して、ステートレスフローラベルの割り当てを行うことができます。
* If the inner packet is an IPv6 packet, its flow label value could also be included in this hash.
内部パケットがIPv6パケットである場合*、そのフローラベル値も、このハッシュに含めることができます。
* This stateless method creates a small probability of two different user flows hashing to the same flow label. Since [RFC6437] allows a source (the TEP in this case) to define any set of packets that it wishes as a single flow, occasionally labeling two user flows as a single flow through the tunnel is acceptable.
*このステートレス方法は、同じフローラベルにハッシュする2つの異なるユーザフローの小さな確率を作成します。 [RFC6437]ので、ソース（この場合TEP）は、それが時折トンネルを通る単一の流れが許容されるように、2人のユーザが流れる標識、単一フローとしてたいパケットの任意のセットを定義することを可能にします。
o At intermediate routers that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple. This applies whether the traffic is tunneled traffic only or a mixture of normal traffic and tunneled traffic.
O負荷分散、次のホップに向かってECMPおよび/またはLAGにおける発信コンポーネントリンクを決定するために使用されるハッシュアルゴリズムを実行し、中間ルータでMUST最小限3タプル{DESTのADDR、ソースADDR、フローラベル}とMAYを含みますまた、5タプルの残りの構成要素を含みます。これは、トラフィックはトラフィックのみまたは通常のトラフィックおよびトンネルトラフィックの混合物をトンネル化されているかどうかを適用します。
* Intermediate IPv6 router(s) will presumably encounter a mixture of tunneled traffic and normal IPv6 traffic. Because of this, the design should also include {protocol, dest port, source port} as input keys to the ECMP and/or LAG hash algorithms, to provide additional entropy for flows whose flow label is set to zero, including non-tunneled traffic flows.
*中間IPv6ルータ（複数可）、おそらくトンネルトラフィックと通常のIPv6トラフィックの混合物が発生します。この設計はまた、ECMPおよび/またはLAGハッシュアルゴリズムへの入力キーとして{プロトコル、DESTポート、ソースポートを}含める必要があるので、非トンネルトラフィックを含め、そのフローラベルゼロに設定されているフローのための追加のエントロピーを提供します流れ。
o Individual nodes in a network are free to implement different algorithms that conform to this specification without impacting the interoperability or function of the network.
Oネットワーク内の各ノードは、ネットワークの相互運用性や機能に影響を与えることなく、この仕様に準拠する異なるアルゴリズムを実装して自由です。
o Operations, Administration, and Maintenance (OAM) techniques will need to be adapted to manage ECMP and LAG based on the flow label. The issues will be similar to those that arise for MPLS [RFC4379] and pseudowires [RFC6391].
O操作、管理、および保守（OAM）の技術は、フローラベルに基づくECMPとLAGを管理するために適合させる必要があります。問題は、MPLS [RFC4379]と疑似回線[RFC6391]のために生じたものと同様であろう。
The flow label is not protected in any way and can be forged by an on-path attacker. However, it is expected that tunnel endpoints and the ECMP or LAG paths will be part of a managed infrastructure that is well protected against on-path attacks (e.g., by using IPsec between the two tunnel endpoints). Off-path attackers are unlikely to guess a valid flow label if an apparently pseudo-random and unpredictable value is used. In either case, the worst an attacker could do against ECMP or LAG is attempt to selectively overload a particular path. For further discussion, see [RFC6437].
フローラベルは、どのような方法で保護されていないとのパス攻撃者によって偽造することができます。しかしながら、トンネルエンドポイントおよびECMPまたはLAGパスがウェル（2つのトンネルエンドポイント間でIPsecを使用することにより、例えば、）にパス攻撃から保護される管理インフラストラクチャの一部であることが期待されます。オフパス攻撃者は、明らかに、擬似ランダムで予測不可能な値が使用されている場合、有効なフローラベルを推測することはほとんどありません。いずれの場合も、攻撃者はECMPまたはLAGに対して何ができる最悪の選択、特定のパスをオーバーロードしようとする試みです。さらなる議論に関しては、[RFC6437]を参照してください。
This document was suggested by corridor discussions at IETF 76. Joel Halpern made crucial comments on an early version. We are grateful to Qinwen Hu for general discussion about the flow label. Valuable comments and contributions were made by Miguel Garcia, Brian Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis, and others.
この文書では、初期のバージョンで重大なコメントが寄せられてIETF 76ジョエル・ハルパーンの廊下の議論によって示唆されました。私たちは、フローラベルに関する一般的な議論のためのQinwen胡主席に感謝しています。貴重なコメントと貢献はミゲル・ガルシア、ブライアンハーバーマン、シェン・ジャン、トーマスNarten氏、ヤルノRajahalme、ブライアン・ワイス、および他のユーザーによって行われました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437] Amante、S.、大工、B.、江、S.、およびJ. Rajahalme、 "IPv6のフローラベル仕様"、RFC 6437、2011年11月。
[IEEE802.1AX] Institute of Electrical and Electronics Engineers, "Link Aggregation", IEEE Standard 802.1AX-2008, 2008.
[IEEE802.1AX]電気電子技術者協会、 "リンクアグリゲーション"、IEEE標準802.1AX-2008、2008。
[Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of UDP to TCP Ratio and Port Numbers", Fifth International Conference on Internet Monitoring and Protection ICIMP 2010, May 2010.
[Lee10]リー、D.、大工、B.、およびN.ブラウンリー、「TCP比とポート番号にUDPの観察」、第5回国際会議、インターネットの監視と保護ICIMP 2010、2010年5月に。
[MPLS-LABEL] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", Work in Progress, May 2011.
[MPLS-LABEL] Kompella、K.、ドレイク、J.、Amante、S.、Henderickx、W.、およびL.ヨンジュン、 "MPLSフォワーディングにおけるエントロピーラベルの使用"、進歩、2011年5月での作業。
[RFC2474] 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.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]ターラー、D.およびC. Hoppsが、 "ユニキャストとマルチキャストの次ホップの選択におけるマルチパスの問題"、RFC 2991、2000年11月。
[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）データプレーン障害をスイッチ"。
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]ブライアント、S.、Filsfils、C.、Drafz、U.、Kompella、V.、リーガン、J.、およびS. Amanteは、RFC 6391の "MPLSパケット上スードワイヤの流れを考慮したトランスポートネットワークスイッチ" 、2011年11月。
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
オークランドPBのコンピュータサイエンス大学92019オークランド1142ニュージーランドのブライアン・カーペンター部門
EMail: brian.e.carpenter@gmail.com
メールアドレス：brian.e.carpenter@gmail.com
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA
シェーンAmanteレベル3コミュニケーションズ、LLC 1025エルドラドブールバードブルームフィールド、CO 80021 USA
EMail: shane@level3.net
メールアドレス：shane@level3.net