[要約] RFC 6438は、IPv6フローラベルを使用してトンネル内での等価コストマルチパスルーティングとリンク集約を行うためのものです。このRFCの目的は、IPv6ネットワークでのトンネル内のトラフィックの効率的な配信を実現することです。
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
等しいコストマルチパスルーティングにIPv6フローラベルを使用し、トンネルでのリンク集約
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-in-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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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つのノード間のいくつかのネットワークパスがルーティングシステムによって等しく良好であることがわかっている場合（容量とレイテンシの点で）、それらの間でトラフィックを共有することが望ましい場合があります。このような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
ECMPまたはLAGへの軽量アプローチの1つは次のとおりです。選択する必要があるn同様に適切なパスがある場合、同じ値を確実に持つ確かな各パケットヘッダーの定義されたフィールドセットからモジュロ（n）ハッシュ[rfc2991]を形成しますフローの持続時間を通して、結果の出力ハッシュ値を使用して、特定のパスを選択します。出力値に均一な統計分布があるようにハッシュ関数が選択された場合、この方法はNパス間でほぼ等しくトラフィックを共有します。ハッシュ入力に含まれるヘッダーフィールドが一貫している場合、特定のフローからのすべてのパケットが同じハッシュ出力値を生成するため、秩序外配信は
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.
発生しません。多数の一意のフローが関与していると仮定すると、各リンクのキューが空ではないままであるため、この方法はアイドル時間を回避する可能性があります。
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].
このドキュメントの残りの部分では、「Flow」という用語を使用して、ソースおよび宛先IPアドレスのみ{2-Tuple}またはソースIPアドレス、宛先IPアドレス、プロトコルのいずれかによって識別されるパケットのシーケンスを表します。番号、ソースポート番号、および宛先ポート番号{5-tuple}。後者はより具体的には[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、Source Addr、Protocol、Dest Port、Source Port}をハッシュ関数への入力キーとして使用して、等しいコストパスでトラフィックを均等に共有する確率を最大化します。ただし、ハッシュへの入力キーとしての輸送層情報を含めることは、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-in-IPトンネル付きシナリオでは状況が異なります。特に、ほぼすべてのハードウェアが最も外側のIPヘッダーに含まれる情報に基づいてフローを識別できるため、トンネル内のフローを識別することはより複雑です。多くのソースから多くの目的地へのトラフィックが、トンネルエンドポイント（TEP）AからTEP Bまでの単一のIP-in-IPトンネルに集約されていると仮定します（図を参照）。次に、トンネルを形成するすべてのパケットには、外側のソースアドレスAおよび外側の宛先アドレスBがあります。すべての確率で、同じポートとプロトコル番号もあります。ルーターR1とR2の間に複数のパスがあり、特定のパスを選択するためにECMPまたはLAGが適用されると、2タプルまたは5タプル（およびそのハッシュ）が一定であり、負荷共有は達成されません。偏光が発生します。 1つまたは少数のトンネルからのトラフィックの割合が高い場合、部分偏光により、R1とR2の間のパス全体に意図されているようにトラフィックは分布しません。 （MPLS [MPLS-Label]に関連する問題が発生します。）
_____ _____ _____ _____
| 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またはラグをサポートするフローラベルの使用をためらいました。実際、ほとんどのノードはフローラベルにゼロ値を設定しており、最初のルールは、パケットがソースノードを離れると、ルーティングシステムがフローラベルを変更することを間違いなく禁止しています。通常のIPv6トラフィックを考慮すると、フローラベルが通常ゼロであるという事実は、ECMPまたはラグハッシュに値が追加されないことを意味しますが、ハッシュ値の分布に害はありません。
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-in-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.
上記の2番目の2つのルールは、[RFC3697]のコンテキストで見る必要があります。これは、フローラベルを使用してルーターがフロー状態を確立する何らかの方法に関与すると仮定しています。流れ状態は、ソースから宛先までのパス上の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.
上記のトンネルの状況では、Routers R1とR2は、既知の方法で割り当てられているTEP AとTEP Bによって設定されたフローラベルに依存できます。これにより、ECMPまたはLAGメソッドは、非巡数トラフィックが非ゼロフローラベル値を持っているかどうかにかかわらず、[RFC3697]と一貫してフローラベルに基づくことができます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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またはラグハッシュに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]に従ってTEPを20ビット値に送信することにより設定する必要があります。内側パケットの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.
o これを達成するために、送信TEPは、特定のトンネルに入り、関連するフローラベルを外側のIPv6ヘッダーに書き込む必要があると判断したら、すべてのパケットをフローに分類する必要があります。ユーザーフローは、TEPを送信することで、{宛先、ソース}アドレス2タプルまたは5タプル{Dest Addr、Source Addr、Protocol、Dest Port、Source Port}によって最も単純に識別されます。現在、{dest addr、source addr、flowラベル}の3タプルを使用することにはほとんどポイントがありませんが、そうすることは将来のプルーフオプションになります。N-Tupleの選択は、送信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の発信コンポーネントリンクを決定するために使用されるハッシュアルゴリズムおよび/または次のホップに向かってラグを最小限に抑える必要があります{dest addr、source addr、flowラベル}、および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トラフィックの混合に遭遇します。このため、設計には{Protocol、Dest Port、Source Port}をECMPおよび/またはLAGハッシュアルゴリズムへの入力キーとして含める必要があります。流れ。
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またはラグに対して行うことができる最悪のことは、特定のパスを選択的に過負荷にする試みです。詳細については、[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での廊下の議論によって提案されました。JoelHalpernは初期版について重要なコメントをしました。フローラベルについての一般的な議論については、Qinwen Huに感謝しています。貴重なコメントと貢献は、ミゲル・ガルシア、ブライアン・ハーバーマン、シェン・ジャン、トーマス・ナルテン、ジャルノ・ラジャハルメ、ブライアン・ワイスなどによって行われました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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.、Conta、A.、Carpenter、B。、およびS. Deering、「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.、Carpenter、B.、Jiang、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]電気およびエレクトロニクスエンジニアの研究所、「Link Aggregation」、IEEE Standard 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] Lee、D.、Carpenter、B。、およびN. Brownlee、「UDPに対するTCP比とポート番号の観察」、2010年5月、ICIMP 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.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Thaler、D。およびC. Hopps、「UnicastおよびMulticast Next-Hop Selectionのマルチパス問題」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Bryant、S.、Filsfils、C.、Drafz、U.、Kompella、V.、Regan、J。、およびS. Amante、「MPLSパケットスイッチネットワーク上での擬似動物のフローアウェア輸送」、RFC 6391、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
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA
シェーンアマンテレベル3コミュニケーションズ、LLC 1025 Eldorado Blvd Broomfield、Co 80021 USA
EMail: shane@level3.net