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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（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
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.
一部のオペレーティングシステムは、[McGann05]に設定しないものの、フローラベルはほとんど、広範なIPv6の実装で実際に使用されていません。ある程度、これは、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 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.
この最後の点は、フローラベルに関して、セキュリティプロパティ、またはむしろその欠如を強調しています。フローラベルフィールドは、ネットワークを通過するようになしIPv6ヘッダチェックサムがないため、常に保護され、そしてフローラベルは、トランスポート疑似ヘッダチェックサムで、またIPsecのチェックサムに含まれていません。その結果、その値に意図的かつ悪質な変化を検出することができません。明らかに、擬似ランダムフローラベル値が実際に秘密データ[NIST]から成る可能性があるため、また、それは、秘密データチャネルとして使用することができます。フローラベルは、サービス品質のセマンティクスを運ぶためにした場合は、DiffServのコードポイント[RFC2474]のように、それはドメインの境界を越えて、本質的に信頼できるものではありません。その結果、一部のセキュリティ専門家は、フローラベルは[LABEL-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.
私たちは、研究者やデザイナーの相当数が、一方RFC 3697.によって窮地に立たされていると結論することができ、[RFC6294]で議論他のいくつかの提案がRFCいくつか3697.と互換性があるように思われる選択パケットの発信元に基づいています擬似ランダム一つの選択肢は、このようにRFC 3697.で提案された各フローのためのフローラベルは、我々はまた、このアプローチのために有用な役割があることを結論付けることができます。
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:
私たちの目標は、実際に使用されるフローラベルのためであれば、様々なアプローチ間の対立はジレンマを作成します。二つの主要なオプションがあるように表示されます。
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.
このドキュメントの以前のバージョンでは、リストの議論を郵送での種々の提案で、2011 - これらのオプションとその亜種についてかなりの議論が2010年にありました。これらの議論の後、シンプルさは、このような、フローラベルでのサービス品質のセマンティクスを定義する、またはより小さなサブフィールドにフローラベルフィールドをサブ分割するなどの複雑な提案が証明していないだろう、とすることを優先すべきであるという意見があるように見えます効率的か、展開、特に高速ルータインチステートレス負荷分散の様々な形のためのフローラベルを使用すると、そのための最善の簡単なアプリケーションであることを明確に表現ビューもあります。同時に、上述のように厳密な不変性ルールは欠点を有していることを認識する必要があります。
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 as an optimization on a best-effort basis; a packet with a changed (or zero) flow label value should never cause a hard failure.
途中で変更が検出できないためにも、RFC 3697のルールの下で、フローラベルは、本質的に信頼できません。このような理由から、でも現在の厳しい不変のルールで、下流のノードは変わらないという値に数学的に依存することはできません。この意味では、フローラベルの使用はベストエフォートベースで最適化として表示する必要があります。変更（またはゼロ）フローラベル値を持つパケットは、ハード障害を引き起こすことはありません。
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.
第2の目的は、それにもかかわらず、そこから利益のためにフローラベルを設定していないホストを許可する、限られた方法で、フローラベルの変更を可能にすることです。フローラベルは、実際には途中で変更することができるという事実はまた、ルールの改質に反映されます。
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.
統計では、離散的に均一な分布は、（例えば、整数のシーケンスとして）等間隔の値の所定の範囲内の各値は次の値として選択することが等しく可能性である確率分布として定義されます。そのような分布の値は可変とunguessabilityの両方を示します。このように、離散的な一様分布の近似は、フローラベル値のソースとして好適です。間違いなくお勧めしませんこれとは対照的に、ラベルを流れている実装が推測可能性を避けるために、順番に割り当てられています。
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.
デフォルトでは1と0xFFFFFの間に均一に分布したラベルを選択する新しい仕様に準拠したホストを送信するO。
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は、フローラベルはもはや非現実的厳密不変であることを表明されていません。間違って、途中で変更することができることが認識されています。いくつかの状況では、これは、例えば、エンドツーエンドの使用、サードパーティのスプーフィング攻撃[LABEL-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ホスト。一般に、ホストがレシートのフローラベルの値を無視することが想定されます。それは、エンド・ツー・エンドの信号として当てにすることはできません。暗号的に生成されたラベルは、攻撃者[LABEL-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]と[LABEL-SEC]を参照してください。いくつかの有用な発言は[パートリッジ]です。
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胡主席に感謝しています。貴重なコメントと貢献は蘭アトキンソン、フレッド・ベイカー、スティーブ・ブレイク、レミ・デプレ、アラン・フォード、フェルナンドGont、ブライアンハーバーマン、トニーハイン、ジョエル・ハルパーン、クリス・モロー、トーマスNarten氏、ペッカSavola、マーク・スミス、パスカルThubert、Iljitschによって作られましたバンBeijnum、および6manワーキンググループの他の参加者。
[FLOWSWITCH] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, March 2007.
[流れスイッチ]ベックマン、M.、 "IPv6のダイナミックフローラベル・スイッチング（FLS）"、進歩、2007年3月に作業。
[LABEL-SEC] Gont, F., "Security Assessment of the IPv6 Flow Label", Work in Progress, November 2010.
[LABEL-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.マローン、「フローラベルフィルタリングの実現可能性」、コンピュータネットワーク防衛、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]フランケル、S.、Graveman、R.、ピアース、J.、およびM.ルックス、 "IPv6のの安全な展開のためのガイドライン"、国立標準技術研究所特別刊行物800から119、2010、<のhttp： //csrc.nist.gov/出版/ 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のファイアウォールの設計上の考慮事項"、国家安全保障局（NSA）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>.
[ヤマウズラ]ウズラ、C.、Arsenault、A.、およびS.ケント、 "情報保証と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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[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月。
[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月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、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]胡、Q.及びB.大工、 "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.、大工、B.、江、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]大工、B.とS. Amante、「トンネル内イコールコストマルチパスルーティングおよびリンクアグリゲーションのためのIPv6フローラベルの使用」、RFC 6438、2011年11月。
Appendix A. Alternative Approaches
付録A.代替アプローチ
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.
二つのより複雑な代替アプローチも考慮し、拒否されました。
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.
最初は、フローラベルの最上位ビット（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.
第二は、フラグを、代わりにフローラベル自体のMSBのトラフィッククラスのオクテット内でローカルに定義された動作を特定差別化サービスコードポイント（DSCP）[RFC2474]を使用することでした。これのより精巧なバージョンは[流れスイッチ]で提案されました。そのアプローチには2つの問題があります。一つは、DSCP値は、元のフローラベル定義のエンド・ツー・エンドの自然と自分自身だけローカルで有効な、矛盾しているということです。第二に、現在、フローラベルの使用量の未知の将来のセマンティクスで、配備されている差別化サービス、の意味をメルドする愚かなようです。しかし、このアプローチは、推奨されていないが、厳密に単一差別化サービスのドメイン内で適用された場合に任意の基本原則に違反することは表示されません。
Authors' Addresses
著者のアドレス
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
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
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
HU AはキャンパスNO.156は愛緑道H -Dイアン地区、北京100095中華人民共和国私もあるSが共同クロス江HU A技術である、株式会社Q14、
EMail: jiangsheng@huawei.com
メールアドレス：jiangsheng@huawei.com