[要約] RFC 6436は、IPv6フローラベル仕様の更新の理由と目的を説明しています。要約すると、このRFCは、IPv6フローラベルの使用方法と効果を改善し、ネットワークパフォーマンスの向上を図るために作成されました。
Internet Engineering Task Force (IETF) S. Amante
Request for Comments: 6436 Level 3
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
S. Jiang
Huawei
November 2011
Rationale for Update to the IPv6 Flow Label Specification
IPv6フローラベル仕様の更新の根拠
Abstract
概要
Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility.
IPv6フローラベルの使用に関するさまざまな公開された提案は、RFC 3697での元の仕様と互換性がありません。さらに、仕様の正しい解釈に関するいくつかの不確実性があるため、フローラベルではほとんど実用的ではありません。このドキュメントは、それを明確にし、いくつかの追加の柔軟性を導入するために、仕様の変更について説明し、動機付けます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6436.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6436で取得できます。
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
2. Impact of Current Specification . . . . . . . . . . . . . . . 3
3. Changes to the Specification . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
The flow label field in the IPv6 header was reserved but left Experimental by [RFC2460], which mandates only that "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet."
IPv6ヘッダーのフローラベルフィールドは予約されていましたが、[RFC2460]によって実験的になりました。これは、「フローラベルフィールドの関数をサポートしていないホストまたはルーターがパケットを発信するときにフィールドをゼロに設定するために必要であることを義務付けています。パケットを転送するときに変更されていないフィールドを渡し、パケットを受け取るときにフィールドを無視します。」
The flow label field was normatively specified by [RFC3697]. In particular, we quote three rules from that RFC:
フローラベルフィールドは、[RFC3697]によって規範的に指定されていました。特に、そのRFCから3つのルールを引用します。
a. "The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."
a. 「ソースによって設定されたフローラベル値は、宛先ノードに変更されずに配信する必要があります。」
b. "IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes."
b. 「IPv6ノードは、ソースノードによって割り当てられたフローラベル値の数学的またはその他のプロパティを想定してはなりません。」
c. "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."
c. 「ルーターのパフォーマンスは、フローラベル値の分布に依存してはなりません。特に、フローラベルビットだけで、ハッシュキーの材料が不十分になります。」
Additionally, RFC 3697 does not define the method a host should adopt by default to choose the value of the flow label, if no specific method is in use. It was expected that various signaling methods might be defined for agreeing on values of the flow label, but no such methods have been standardized, except a pre-existing option in RSVP [RFC2205].
さらに、RFC 3697は、特定の方法が使用されていない場合、ホストがデフォルトで採用する方法をデフォルトで採用するようにフローラベルの値を選択する方法を定義しません。フローラベルの値に同意するためにさまざまなシグナル伝達方法が定義される可能性がありますが、RSVP [RFC2205]の既存のオプションを除いて、そのような方法は標準化されていません。
The flow label is hardly used in practice in widespread IPv6 implementations, although some operating systems do set it [McGann05]. To some extent, this is due to the main focus being on basic deployment of IPv6, but the absence of a default method of choosing the flow label value means that most host implementations simply set it to zero. There is also anecdotal evidence that the rules quoted above have led to uncertainty about exactly what is possible. Furthermore, various use cases have been proposed that infringe one or another of the rules. None of these proposals has been accepted as a standard and in practice there is no significant deployment of any mechanism to set the flow label.
フローラベルは、広範囲にわたるIPv6実装では実際にはほとんど使用されていませんが、一部のオペレーティングシステムはそれを設定しています[McGann05]。ある程度、これはIPv6の基本的な展開に主な焦点があるためですが、フローラベル値を選択するデフォルトの方法がないことは、ほとんどのホスト実装が単にゼロに設定することを意味します。また、上記の規則が何が可能かについて正確に不確実性をもたらしたという逸話的な証拠もあります。さらに、さまざまなユースケースが提案されています。これらの提案はどれも標準として受け入れられておらず、実際にはフローラベルを設定するメカニズムの重要な展開はありません。
The intention of this document is to explain this situation in more detail and to motivate changes to RFC 3697 intended to remove the uncertainties and encourage active usage of the flow label. It does not formally update RFC 3697, but it serves as background material for [RFC6437].
このドキュメントの意図は、この状況をより詳細に説明し、不確実性を取り除き、フローラベルの積極的な使用を促進することを目的としたRFC 3697の変更を動機付けることです。RFC 3697を正式に更新するわけではありませんが、[RFC6437]の背景材料として機能します。
Rule (a) makes it impossible for the routing system to use the flow label as any form of dynamic routing tag. This was a conscious choice in the early design of IPv6, and there appears to be no practical possibility of revisiting this decision at this stage in the deployment of IPv6, which uses conventional routing mechanisms like those used for IPv4. However, this rule also makes it impossible to make any use at all of the flow label unless hosts choose to set it. It also forbids clearing the flow label for security reasons.
ルール（a）により、ルーティングシステムがフローラベルをあらゆる形式の動的ルーティングタグとして使用することを不可能にします。これはIPv6の初期設計における意識的な選択であり、IPv4に使用されるような従来のルーティングメカニズムを使用するIPv6の展開において、この段階でこの決定を再検討する実用的な可能性はないようです。ただし、このルールにより、ホストが設定を選択しない限り、フローラベルのすべてで使用することも不可能になります。また、セキュリティ上の理由でフローラベルのクリアを禁止しています。
This last point highlights the security properties, or rather the lack thereof, with regards to the flow label. The flow label field is always unprotected as it travels through the network, because there is no IPv6 header checksum, and the flow label is not included in transport pseudo-header checksums, nor in IPsec checksums. As a result, intentional and malicious changes to its value cannot be detected. Also, it could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of covert data [NIST]. If the flow label were to carry quality-of-service semantics, then like the diffserv code point [RFC2474], it would not be intrinsically trustworthy across domain boundaries. As
この最後のポイントは、フローラベルに関して、セキュリティプロパティ、またはむしろその欠如を強調しています。Flowラベルフィールドは、IPv6ヘッダーチェックサムがなく、フローラベルがトランスポート擬似ヘッダーチェックサムにもIPSECチェックサムにも含まれていないため、ネットワークを介して移動する際に常に保護されていません。その結果、その価値に対する意図的および悪意のある変更を検出することはできません。また、明らかに擬似ランダムフローラベル値が実際には秘密データ[NIST]で構成される可能性があるため、秘密のデータチャネルとして使用できます。フローラベルがサービス品質セマンティクスを運ぶ場合、DiffServコードポイント[RFC2474]のように、ドメイン境界を越えて本質的に信頼できるものではありません。として
a result, some security specialists believe that flow labels should be cleared for safety [LABEL-SEC] [NSA]. These points must be considered when discussing the immutability of the flow label across domain boundaries. In fact, the adjective "immutable" is confusing, since it implies a property that the flow label field does not actually possess. It has therefore been abandoned as a descriptive term in [RFC6437]. It is only used in the present document to explain why it has been abandoned.
その結果、一部のセキュリティスペシャリストは、安全性のためにフローラベルをクリアする必要があると考えています[ラベル-SEC] [NSA]。これらのポイントは、ドメイン境界を越えたフローラベルの不変性について議論するときに考慮する必要があります。実際、フローラベルフィールドが実際に所有していないプロパティを意味するため、形容詞の「不変」は混乱しています。したがって、[RFC6437]の記述用語として放棄されました。現在の文書でのみ使用され、なぜ放棄されたのかを説明しています。
Rule (b) appears to forbid any usage in which the bits of the flow label are encoded with a specific semantic meaning. However, the words "MUST NOT assume" are to be interpreted precisely - if a router knows by configuration or by signaling that the flow label has been assigned in a certain way, it can make use of that knowledge. It is not made clear by the rule that there is an implied distinction between stateless models (in which there is no signaling, so no specific assumption about the meaning of the flow label value can be made) and stateful models (in which there is signaling and the router has explicit knowledge about the label).
ルール（b）は、フローラベルのビットが特定のセマンティックな意味でエンコードされる使用量を禁止するように見えます。ただし、「想定してはならない」という言葉は正確に解釈されます。ルーターが構成によって知っている場合、またはフローラベルが特定の方法で割り当てられていることを知らせる場合、その知識を利用できます。ルールによって、ステートレスモデル（シグナルがないため、フローラベル値の意味について具体的な仮定が作成されない）とステートフルなモデル（シグナリングがある）の間に暗黙の区別があることは明らかにされていません。ルーターには、ラベルに関する明示的な知識があります）。
If the word "alone" is overlooked, rule (c) has sometimes been interpreted as forbidding the use of the flow label as part of a hash used by load distribution mechanisms. In this case too, the word "alone" needs to be taken into account - a router is allowed to combine the flow label value with other data in order to produce a uniformly distributed hash.
「単独」という単語が見落とされている場合、ルール（c）は、負荷分布メカニズムで使用されるハッシュの一部としてフローラベルの使用を禁止すると解釈されることがあります。この場合、「単独」という単語を考慮する必要があります - ルーターは、均一に分布したハッシュを生成するために、フローラベル値を他のデータと組み合わせることができます。
Both before and after these rules were laid down, a considerable number of proposals for use of the flow label were published that seem incompatible with them. Numerous examples and an analysis are presented in [RFC6294]. Those examples propose use cases in which some or all of the following apply:
これらの規則が定められた前と後の両方で、フローラベルの使用に関するかなりの数の提案が公開され、それらと互換性がないと思われます。[RFC6294]には、多数の例と分析が示されています。これらの例は、次の一部またはすべてが適用されるユースケースを提案しています。
o The flow label may be changed by intermediate systems.
o フローラベルは、中間システムによって変更される場合があります。
o It doesn't matter if the flow label is changed, because the receiver doesn't use it.
o レシーバーが使用していないため、フローラベルが変更されているかどうかは関係ありません。
o Some or all bits of the flow label are encoded: they have specific meanings understood by routers and switches along the path.
o フローラベルの一部またはすべてのビットはエンコードされています。それらは、パスに沿ってルーターとスイッチによって理解される特定の意味を持っています。
o The encoding is related to the required quality of service, as well as identifying a flow.
o エンコーディングは、必要なサービス品質とフローの識別に関連しています。
o The flow label is used to control forwarding or switching in some way.
o フローラベルは、何らかの方法で転送または切り替えを制御するために使用されます。
These proposals require either some form of semantics encoding in the bits of the flow label, or the ability for routers to modify the flow label, or both. Thus, they appear to infringe the rules from RFC 3697 quoted above.
これらの提案には、フローラベルのビットでエンコードする何らかの形のセマンティクス、またはルーターがフローラベルを変更する能力、またはその両方が必要です。したがって、彼らは上記のRFC 3697からのルールを侵害しているように見えます。
We can conclude that a considerable number of researchers and designers have been stymied by RFC 3697. On the other hand, some other proposals discussed in [RFC6294] appear to be compatible with RFC 3697. Several are based on the originator of a packet choosing a pseudo-random flow label for each flow, which is one option suggested in RFC 3697. Thus, we can also conclude that there is a useful role for this approach.
一方、[RFC6294]で議論されている他の提案はRFC 3697と互換性があるように見える。各フローの擬似ランダムフローラベル。これは、RFC 3697で提案されている1つのオプションです。したがって、このアプローチには有用な役割があると結論付けることもできます。
If our goal is for the flow label to be used in practice, the conflict between the various approaches creates a dilemma. There appear to be two major options:
私たちの目標が実際にフローラベルを使用することである場合、さまざまなアプローチ間の対立がジレンマを作成します。2つの主要なオプションがあるように見えます。
1. Discourage locally defined and/or stateful use of the flow label. Strengthen RFC 3697 to say that hosts should set a label value, without necessarily creating state, which would clarify and limit its possible uses. In particular, its use for load distribution and balancing would be encouraged.
1. ローカルで定義された、および/またはフローラベルの州の使用を阻止します。RFC 3697を強化して、ホストは必ずしも状態を作成せずにラベル値を設定する必要があると言うために、可能な用途を明確にし、制限します。特に、負荷分布とバランスへの使用が奨励されます。
2. Relax the rules to encourage locally defined and/or stateful use of the flow label. This approach would make the flow label completely mutable and would exclude use cases depending on strict end-to-end immutability. It would encourage applications of a pseudo-random flow label, such as load distribution, on a local basis, but it would exclude end-to-end applications.
2. ルールをリラックスさせて、フローラベルのローカルで定義されたおよび/またはステートフルな使用を促進します。このアプローチにより、フローラベルが完全に変化するようになり、厳密なエンドツーエンドの不変性に応じてユースケースを除外します。ローカルベースで、負荷分布などの擬似ランダムフローラベルのアプリケーションを促進しますが、エンドツーエンドのアプリケーションは除外されます。
There was considerable debate about these options and their variants during 2010 - 2011, with a variety of proposals in previous versions of this document and in mailing list discussions. After these discussions, there appears to be a view that simplicity should prevail, and that complicated proposals such as defining quality-of-service semantics in the flow label, or sub-dividing the flow label field into smaller sub-fields, will not prove efficient or deployable, especially in high-speed routers. There is also a clearly expressed view that using the flow label for various forms of stateless load distribution is the best simple application for it. At the same time, it is necessary to recognize that the strict immutability rule has drawbacks as noted above.
2010年から2011年にかけて、これらのオプションとそのバリエーションについてかなりの議論があり、このドキュメントの以前のバージョンとメーリングリストリストの議論でさまざまな提案がありました。これらの議論の後、シンプルさが優先されるべきであり、フローラベルのサービス品質セマンティクスを定義したり、フローラベルフィールドをより小さなサブフィールドに分割したりするなどの複雑な提案が証明されないという見解があるように見えます。特に高速ルーターでは、効率的または展開可能です。また、さまざまな形式のステートレス荷重分布にフローラベルを使用することが最適な単純なアプリケーションであるという明確な表現ビューもあります。同時に、上記のように、厳格な不変性ルールに欠点があることを認識する必要があります。
Even under the rules of RFC 3697, the flow label is intrinsically untrustworthy, because modifications en route cannot be detected. For this reason, even with the current strict immutability rule, downstream nodes cannot rely mathematically on the value being unchanged. In this sense, any use of the flow label must be viewed
RFC 3697の規則の下でも、フローラベルは本質的に信頼できません。これは、途中の変更を検出できないためです。このため、現在の厳格な不変性ルールがあっても、下流ノードは変化しない値に数学的に依存することはできません。この意味で、フローラベルの使用を表示する必要があります
as an optimization on a best-effort basis; a packet with a changed (or zero) flow label value should never cause a hard failure.
最適化としての最適化として。変化（またはゼロ）フローラベル値を備えたパケットは、困難な障害を引き起こすことはありません。
The remainder of this document discusses specific modifications to the standard, which are defined normatively in a companion document [RFC6437].
このドキュメントの残りの部分では、コンパニオンドキュメント[RFC6437]で規範的に定義されている標準の特定の変更について説明します。
Although RFC 3697 requires that the flow label be delivered unchanged, as noted above, it is not included in any transport-layer pseudo-header checksums nor in IPsec authentication [RFC4302]. Both RFC 2460 and RFC 3697 define the default flow label to be zero. At the time of writing, this is the observed value in an overwhelming proportion of IPv6 packets; the most widespread operating systems and applications do not set it, and routers do not rely on it. Thus, there is no reason to expect operational difficulties if a careful change is made to the rules of RFC 3697.
RFC 3697では、上記のようにフローラベルを変えることを要求していますが、輸送層の擬似ヘッドチェックサムにもIPSEC認証にも含まれていません[RFC4302]。RFC 2460とRFC 3697の両方が、デフォルトのフローラベルをゼロと定義しています。執筆時点では、これはIPv6パケットの圧倒的な割合で観測された値です。最も広範囲にわたるオペレーティングシステムとアプリケーションは設定されておらず、ルーターはそれに依存していません。したがって、RFC 3697のルールに慎重に変更された場合、運用上の困難を期待する理由はありません。
In particular, the facts that the label is not checksummed and rarely used mean that the "immutability" of the label can be moderated without serious operational consequences.
特に、ラベルがチェックサムされておらずめったに使用されないという事実は、ラベルの「不変性」が深刻な運用上の結果なしに緩和できることを意味します。
The purposes of the proposed changes are to remove the uncertainties left by RFC 3697, in order to encourage setting of the flow label by default, and to enable its generic use. The proposed generic use is to encourage uniformly distributed flow labels that can be used to assist load distribution or balancing. There should be no impact on existing IETF specifications other than RFC 3697 and no impact on currently operational software and hardware.
提案された変更の目的は、デフォルトでフローラベルの設定を奨励し、その一般的な使用を可能にするために、RFC 3697が残した不確実性を削除することです。提案されている一般的な使用は、負荷分布またはバランスを支援するために使用できる均一に分布するフローラベルを奨励することです。RFC 3697以外の既存のIETF仕様に影響を与えず、現在の運用ソフトウェアとハードウェアに影響を与えないはずです。
A secondary purpose is to allow changes to the flow label in a limited way, to allow hosts that do not set the flow label to benefit from it nevertheless. The fact that the flow label may in practice be changed en route is also reflected in the reformulation of the rules.
二次的な目的は、フローラベルの変更を限られた方法で許可し、それでもフローラベルを設定しないホストを許可することです。フローラベルが実際に途中で変更される可能性があるという事実は、ルールの再定式化にも反映されています。
A general description of the changes follows. The normative text is to be found in [RFC6437].
変更の一般的な説明が続きます。規範的なテキストは[RFC6437]にあります。
The definition of a flow is subtly changed from RFC 3697 to allow any node, not just the source node, to set the flow label value. However, it is recommended that sources should set a uniformly distributed flow label value in all flows, replacing the less precise recommendation made in Section 3 of RFC 3697. Both stateful and stateless methods of assigning a uniformly distributed value could be used.
フローの定義はRFC 3697から微妙に変更され、ソースノードだけでなくノードがフローラベル値を設定できるようにします。ただし、ソースはすべてのフローに均一に分散されたフローラベル値を設定し、RFC 3697のセクション3で行われたより正確ではない推奨事項を置き換えることをお勧めします。
Flow label values should be chosen such that their bits exhibit a high degree of variability, thus making them suitable for use as part of the input to a hash function used in a load distribution scheme. At the same time, third parties should have a low probability of guessing the next value that a source of flow labels will choose.
フローラベル値は、ビットが高度な変動性を示すように選択する必要があります。したがって、負荷分布スキームで使用されるハッシュ関数への入力の一部として使用するのに適しています。同時に、第三者は、フローラベルのソースが選択する次の値を推測する確率が低い必要があります。
In statistics, a discrete uniform distribution is defined as a probability distribution in which each value in a given range of equally spaced values (such as a sequence of integers) is equally likely to be chosen as the next value. The values in such a distribution exhibit both variability and unguessability. Thus, an approximation to a discrete uniform distribution is preferable as the source of flow label values. In contrast, an implementation in which flow labels are assigned sequentially is definitely not recommended, to avoid guessability.
統計では、離散均一な分布は、特定の範囲の等しく間隔値（整数のシーケンスなど）の各値が次の値として選択される可能性が高い確率分布として定義されます。このような分布の値は、変動性と不適格の両方を示しています。したがって、フローラベル値のソースとして、離散均一分布の近似が望ましい。対照的に、推測可能性を回避するために、フローラベルが順次割り当てられる実装は間違いなく推奨されません。
In practice, it is expected that a uniform distribution of flow label values will be approximated by use of a hash function or a pseudo-random number generator. Either approach will produce values that will appear pseudo-random to an external observer.
実際には、フローラベル値の均一な分布は、ハッシュ関数または擬似ランダム数ジェネレーターを使用することにより近似されると予想されます。どちらのアプローチも、外部の観察者に擬似ランダムに見える値を生成します。
Section 3 of RFC 3697 allows nodes to participate in an unspecified stateful method of flow state establishment. The changes do not remove that option, but clarify that stateless models are also possible and are the recommended default. The specific text on requirements for stateful models has been reduced to a bare minimum requirement that they do not interfere with the stateless model. To enable stateless load distribution at any point in the Internet, a node using a stateful model should never send packets whose flow label values do not conform to a uniform distribution.
RFC 3697のセクション3では、ノードが不特定のステートフルなフロー状態確立方法に参加することができます。変更はそのオプションを削除しませんが、ステートレスモデルも可能であり、推奨されるデフォルトであることを明確にします。ステートレスモデルに干渉しないという、ステートフルモデルの要件に関する特定のテキストは、最低限の要件に削減されました。インターネット内の任意の時点でステートレス負荷分布を有効にするために、ステートフルモデルを使用するノードは、フローラベル値が均一な分布に適合しないパケットを送信してはなりません。
The main novelty is that a forwarding node (typically a first-hop or ingress router) may set the flow label value if the source has not done so, according to the same recommendations that apply to the source. This might place a considerable processing load on ingress routers that choose to do so, even if they adopted a stateless method of flow identification and label assignment.
主な斬新さは、ソースに適用される同じ推奨事項に従って、ソースが行っていない場合、転送ノード（通常、最初のホップまたはイングレスルーター）がフローラベル値を設定する可能性があることです。これにより、フローの識別とラベルの割り当てのステートレス方法を採用した場合でも、それを選択するルーターを侵入するルーターにかなりの処理荷重を配置する可能性があります。
The value of the flow label, once it has been set, must not be changed. However, some qualifications are placed on this rule, to allow for the fact that the flow label is an unprotected field and might be misused. No Internet-wide mechanism can depend mathematically on immutable flow labels. The new rules require that flow labels exported to the Internet should always be either zero or uniformly distributed, but even this cannot be relied on mathematically. Use cases need to be robust against non-conforming
フローラベルの値は、設定されたら、変更してはなりません。ただし、フローラベルが保護されていないフィールドであり、誤用される可能性があるという事実を可能にするために、いくつかの資格がこの規則に掲載されています。インターネット全体のメカニズムは、不変のフローラベルに数学的に依存することはありません。新しいルールでは、インターネットにエクスポートされるフローラベルは常にゼロまたは均一に分散する必要がありますが、これも数学的に依存することはできません。ユースケースは、不適合に対して堅牢である必要があります
flow label values. This will also enhance compatibility with any legacy hosts that set the flow label according to RFC 2460 and RFC 3697.
フローラベル値。これにより、RFC 2460およびRFC 3697に従ってフローラベルを設定するレガシーホストとの互換性が向上します。
A complication that led to much discussion is the possibility that hosts inside a particular network domain might use a stateful method of setting the flow label, and that packets bearing stateful labels might then erroneously escape the domain and be received by nodes performing stateless processing, such as load balancing. This might result in undesirable operational implications (e.g., congestion, reordering) for not only the inappropriately flow-labeled packets, but also well-behaved flow-labeled packets, during forwarding at various intermediate devices. It was suggested that border routers might "correct" this problem by overwriting such labels in packets leaving the domain. However, neither domain border egress routers nor intermediate routers/devices (using a flow label, for example, as a part of an input key for a load-distribution hash) can determine by inspection that a value is not part of a uniform distribution. Thus, there is no way that such values can be detected and "corrected". Therefore, the recommendation to choose flow labels from a uniform distribution also applies to stateful schemes.
多くの議論につながった合併症は、特定のネットワークドメイン内でホストがフローラベルを設定するステートフルな方法を使用する可能性があり、ステートフルなラベルを持つパケットが誤ってドメインを逃がし、ステートレス処理を実行するノードによって受信される可能性があることです。負荷分散として。これにより、不適切にフローラベルされたパケットだけでなく、さまざまな中間デバイスでの転送中に、不適切にフローラベルされたパケットだけでなく、行儀の良いフローラベル付きパケットにも、望ましくない運用上の意味（輻輳、並べ替えなど）が発生する可能性があります。ボーダールーターは、ドメインを離れるパケットにそのようなラベルを上書きすることにより、この問題を「修正」することが示唆されました。ただし、ドメインの境界出力ルーターも中間ルーター/デバイス（たとえば、フローラベルを使用して、荷重分布ハッシュの入力キーの一部として）は、値が均一な分布の一部ではないことを検査によって決定できません。したがって、そのような値を検出して「修正」する方法はありません。したがって、均一な分布からフローラベルを選択することを推奨することは、ステートフルスキームにも適用されます。
The following are some practical consequences of the above changes:
以下は、上記の変更の実際的な結果です。
o Sending hosts that are not updated will in practice continue to send all-zero labels. If there is no label-setting router along the path taken by a packet, the label will be delivered as zero.
o 更新されていないホストを送信すると、実際にはすべてゼロのラベルが送信され続けます。パケットが撮影したパスに沿ってラベル設定ルーターがない場合、ラベルはゼロとして配信されます。
o Sending hosts conforming to the new specification will by default choose uniformly distributed labels between 1 and 0xFFFFF.
o 新しい仕様に準拠しているホストを送信すると、デフォルトでは、1〜0xfffffの間に均一に分散されたラベルが選択されます。
o Sending hosts may continue to send all-zero labels, in which case an ingress router may set uniformly distributed labels between 1 and 0xFFFFF.
o ホストの送信は引き続き全ゼロのラベルを送信することができます。この場合、侵入ルーターは1〜0xfffffの間に均一に分布したラベルを設定する場合があります。
o The flow label is no longer unrealistically asserted to be strictly immutable; it is recognized that it may, incorrectly, be changed en route. In some circumstances, this will break end-to-end usage, e.g., potential detection of third-party spoofing attacks [LABEL-SEC].
o フローラベルは、厳密に不変であると非現実的に主張されていません。誤って途中で変更される可能性があることが認識されています。状況によっては、これはエンドツーエンドの使用、たとえばサードパーティのスプーフィング攻撃の潜在的な検出[ラベル-SEC]を破壊します。
o The expected default usage of the flow label is some form of stateless load distribution, such as the ECMP/LAG usage defined in [RFC6438].
o フローラベルの予想されるデフォルト使用は、[RFC6438]で定義されているECMP/LAG使用法など、何らかの形のステートレス負荷分布です。
o If the new rules are followed, all IPv6 traffic flows on the Internet should have zero or uniformly distributed flow label values.
o 新しいルールに従うと、インターネット上のすべてのIPv6トラフィックフローには、フローラベル値がゼロまたは均一に分散された値が必要です。
From an operational viewpoint, existing IPv6 hosts that set a default (zero) flow label value and ignore the flow label on receipt will be unaffected by implementations of the new specification. In general, it is assumed that hosts will ignore the value of the flow label on receipt; it cannot be relied on as an end-to-end signal. However, this doesn't apply if a cryptographically generated label is being used to detect attackers [LABEL-SEC].
運用上の視点から、デフォルト（ゼロ）フローラベル値を設定し、領収書のフローラベルを無視する既存のIPv6ホストは、新しい仕様の実装によって影響を受けません。一般に、ホストは受領時のフローラベルの値を無視すると想定されています。エンドツーエンド信号として依存することはできません。ただし、これは、暗号化されたラベルが攻撃者[ラベル-SEC]を検出するために使用されている場合、適用されません。
Similarly, routers that ignore the flow label will be unaffected by implementations of the specification.
同様に、フローラベルを無視するルーターは、仕様の実装によって影響を受けません。
Hosts that set a default (zero) flow label but are in a domain where routers set a label as recommended in Section 3 will benefit from whatever flow label handling is used on the path.
デフォルト（ゼロ）フローラベルを設定するが、セクション3で推奨されるルーターを設定するドメインにあるホストは、パスで使用されるフローラベルの処理があらゆるものから利益を得ます。
Hosts and routers that adopt the recommended mechanism will enhance the performance of any load balancing devices that include the flow label in the hash used to select a particular path or server, even when packets leave the local domain.
推奨されるメカニズムを採用するホストとルーターは、パケットがローカルドメインを離れた場合でも、特定のパスまたはサーバーの選択に使用されるハッシュのフローラベルを含む負荷分散デバイスのパフォーマンスを強化します。
See [RFC6437] and [LABEL-SEC] for full discussion. Some useful remarks are in [Partridge].
完全な議論については、[RFC6437]および[ラベル-Sec]を参照してください。いくつかの有用な発言は[Partridge]にあります。
The authors are grateful to Qinwen Hu for general discussion about the flow label and for his work in searching the literature. Valuable comments and contributions were made by Ran Atkinson, Fred Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants in the 6man working group.
著者は、フローラベルに関する一般的な議論と、文献を捜索する彼の研究について、Qinwen Huに感謝しています。貴重なコメントと貢献は、Ran Atkinson、Fred Baker、Steve Blake、Remi Despres、Alan Ford、Fernando Gont、Brian Haberman、Tony Hain、Joel Halpern、Chris Morrow、Thomas Narten、Pekka Savola、Mark Smith、Pascal Thubert、Iljitschによって行われました。Van Beijnum、および6manワーキンググループの他の参加者。
[FLOWSWITCH] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, March 2007.
[FlowSwitch] Beckman、M。、「IPv6 Dynamic Flow Label Switching（FLS）」、2007年3月、Work in Progress。
[LABEL-SEC] Gont, F., "Security Assessment of the IPv6 Flow Label", Work in Progress, November 2010.
[ラベル-Sec] Gont、F。、「IPv6フローラベルのセキュリティ評価」、2010年11月の作業進行中。
[McGann05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defence , 2005.
[McGann05] McGann、O。およびD. Malone、「フローラベルフィルタリングの実現可能性」、コンピューターネットワーク防衛に関する欧州会議、2005年。
[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, "Guidelines for the Secure Deployment of IPv6", National Institute of Standards and Technology Special Publication 800-119, 2010, <http://csrc.nist.gov/ publications/nistpubs/800-119/sp800-119.pdf>.
[Nist] Frankel、S.、Graveman、R.、Pearce、J.、およびM. Rooks、「IPv6の安全な展開のためのガイドライン」、国立標準技術研究所特別出版800-119、2010、<HTTP：//csrc.nist.gov/ Publications/nistpubs/800-119/sp800-119.pdf>。
[NSA] Potyraj, C., "Firewall Design Considerations for IPv6", National Security Agency I733-041R-2007, 2007, <http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
[NSA] Potyraj、C。、「IPv6のファイアウォール設計上の考慮事項」、国家安全保障局I733-041R-2007、2007、<http://www.nsa.gov/ia/_files/ipv6/i733-041r-2007。pdf>。
[Partridge] Partridge, C., Arsenault, A., and S. Kent, "Information Assurance and the Transition to IP Version 6 (IPv6)", Military Communications Conference (MILCOM 2007) , 2007, <http://www.ir.bbn.com/documents/articles/ MILCOM_Paper_from_Proceedings.pdf>.
[Partridge] Partridge、C.、Arsenault、A。、およびS. Kent、「情報保証とIPバージョン6への移行（IPv6）」、軍事コミュニケーション会議（Milcom 2007）、2007、<http：// www。ir.bbn.com/documents/articles/ milcom_paper_from_proceedings.pdf>。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[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月。
[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月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, June 2011.
[RFC6294] Hu、Q。およびB. Carpenter、「IPv6フローラベルの提案されたユースケースの調査」、RFC 6294、2011年6月。
[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月。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438] Carpenter、B。およびS. Amante、「トンネルでの等しいコストマルチパスルーティングとリンク集約にIPv6フローラベルを使用」、RFC 6438、2011年11月。
A model was discussed in an earlier version of this document which defined a notion of 'flow label domain' analogous to a differentiated services domain [RFC2474]. This model would have encouraged local usage of the flow label as an alternative to any form of generic use, but it required complex rules for the behavior of domain boundary routers, and proved controversial in discussion.
モデルは、差別化されたサービスドメイン[RFC2474]に類似した「フローラベルドメイン」の概念を定義したこのドキュメントの以前のバージョンで議論されました。このモデルは、あらゆる形式の一般的な使用に代わるものとしてフローラベルのローカル使用を奨励していましたが、ドメイン境界ルーターの動作に複雑なルールが必要であり、議論において物議を醸していることが証明されました。
Two even more complex alternative approaches were also considered and rejected.
さらに2つのさらに複雑な代替アプローチも考慮され、拒否されました。
The first was to distinguish locally significant flow labels from those conforming to RFC 3697 by setting or clearing the most significant bit (MSB) of the flow label. This led to quite complicated rules, seems impossible to make fully self-consistent, and was not considered practical.
1つ目は、フローラベルの最も重要なビット（MSB）を設定またはクリアすることにより、局所的に重要なフローラベルとRFC 3697に準拠したフローラベルを区別することでした。これは非常に複雑なルールにつながり、完全に自己整合的にすることは不可能であるように思われ、実用的ではありませんでした。
The second was to use a specific differentiated services code point (DSCP) [RFC2474] in the Traffic Class octet instead of the MSB of the flow label itself, to flag a locally defined behavior. A more elaborate version of this was proposed in [FLOWSWITCH]. There are two issues with that approach. One is that DSCP values are themselves only locally significant, inconsistent with the end-to-end nature of the original flow label definition. Secondly, it seems unwise to meld the semantics of differentiated services, which are currently deployed, with the unknown future semantics of flow label usage. However, this approach, while not recommended, does not appear to violate any basic principles if applied strictly within a single differentiated services domain.
2つ目は、フローラベル自体のMSBの代わりにトラフィッククラスOctetで特定の差別化されたサービスコードポイント（DSCP）[RFC2474]を使用して、ローカルで定義された動作にフラグを立てることでした。これのより精巧なバージョンが[Flowswitch]で提案されました。そのアプローチには2つの問題があります。1つは、DSCP値自体が局所的に重要であり、元のフローラベル定義のエンドツーエンドの性質と矛盾することです。第二に、現在展開されている差別化されたサービスのセマンティクスを融合することは賢明ではないように思われます。ただし、このアプローチは推奨されませんが、単一の差別化されたサービスドメイン内に厳密に適用された場合、基本原則に違反しているようには見えません。
Authors' Addresses
著者のアドレス
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
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス大学オークランド大学PB 92019オークランド、1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
Sheng Jiang Huawei Technologies Co.、Ltd Q14、Huawei Campus No.156 Beiqing Road Hai-Dian District、Beijing 100095 P.R. China
EMail: jiangsheng@huawei.com