Independent Submission Q. Hu
Request for Comments: 6294 B. Carpenter
Category: Informational Univ. of Auckland
ISSN: 2070-1721 June 2011
Survey of Proposed Use Cases for the IPv6 Flow Label
Abstract
抽象
The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised.
IPv6プロトコルは、すべてのパケットヘッダ内のフローラベルを含むが、このフィールドは、実際には使用されません。本論文では、フローラベルの標準を説明し、それが提起実装の問題について説明します。その後、フローラベルを使用するための様々な公表の提案について説明し、それらのほとんどが標準と矛盾していることを示しています。この問題に対処する方法を簡単に検討されています。また、標準が改訂されるべきかどうかを疑問視。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6294.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6294で取得することができます。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. A Brief History of the Flow Label . . . . . . . . . . . . 2
1.2. The Flow Label and Quality of Service . . . . . . . . . . 3
2. Flow Label Definition and Issues . . . . . . . . . . . . . . . 4
2.1. Flow Label Properties . . . . . . . . . . . . . . . . . . 4
2.2. Dependency Prohibition . . . . . . . . . . . . . . . . . . 5
2.3. Other Issues . . . . . . . . . . . . . . . . . . . . . . . 5
3. Documented Proposals for the Flow Label . . . . . . . . . . . 6
3.1. Specify the Flow Label as a Pseudo-Random Value . . . . . 7
3.1.1. End-to-End QoS Provisioning . . . . . . . . . . . . . 7
3.1.2. Load-Balancing . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Security Nonce . . . . . . . . . . . . . . . . . . . . 8
3.2. Specify QoS Parameters in the Flow Label . . . . . . . . . 8
3.3. Use Flow Label Hop-by-Hop to Control Switching . . . . . . 9
3.4. Diffserv Use of IPv6 Flow Label . . . . . . . . . . . . . 12
3.5. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
IPv6 is being introduced to overcome the address shortage of the current IPv4 protocol, but it also offers a new feature, i.e., the Flow Label field in the IPv6 packet header. The flow label is not encrypted by IPsec and is present in all fragments. However, it is used very little in practice, for reasons discussed below and in [Amante11]. After a short introduction, this document summarizes the current specification of the IPv6 flow label and some open issues about its use in Section 2. Section 3 describes and analyzes various proposals that have been made for its use. Finally, Section 4 discusses the implications and attempts to draw conclusions.
IPv6は現在のIPv4プロトコルのアドレス不足を克服するために導入されているが、それはまた、新しい機能、IPv6パケットヘッダーで、すなわち、フローラベルフィールドを提供しています。フローラベルは、IPsecで暗号化され、すべてのフラグメント中に存在していません。しかし、それは下にして、[Amante11]で説明する理由のために、実際にはほとんど使用されています。短い導入後、この文書は、IPv6フローラベルの現在の仕様をまとめ、第2節第3節では、その使用に関するいくつかの未解決の問題は、その使用のために作られてきた様々な提案を説明し、分析します。最後に、第4節では、意味を説明し、結論を出すしようとします。
The Flow Label field occupies bits 12 through 31 of the IPv6 packet header. It provides a potential way to mark a packet, identify a flow, and look up the corresponding flow state. This field is always present in an IPv6 header, so a phrase such as "a packet with no flow label" refers to a packet whose Flow Label field contains 20 zero bits, i.e., a flow label whose value is zero.
フローラベルフィールドは、IPv6パケットヘッダ31を介してビット12を占有します。これは、パケットをマークフローを識別し、対応するフローの状態を調べるための潜在的な方法を提供します。このフィールドは、IPv6ヘッダ内に常に存在しているので、そのような「ノーフローラベル付きパケット」などの語句は、そのフローラベルフィールドは、20ビットのゼロ、すなわち、値がゼロのフローラベルを含むパケットをいいます。
The original proposal for a flow label has been attributed to Dave Clark [Deering93], who proposed that it should contain a pseudo-random value. A Flow Label field was included in the packet header during the preliminary design of IPv6, which followed an intense period of debate about several competing proposals. The final choice was made in 1994 [RFC1752]. In particular, the IETF rejected a proposal known as the Common Architecture for Next Generation Internet Protocol (CATNIP) [RFC1707], which included so-called 'cache handles' to identify the next hop in high-performance routers. Thus, CATNIP introduced the notion of a header field that would be shared by all packets belonging to a flow, to control packet forwarding on a hop-by-hop basis. We recognize this today as a precursor of the MPLS label [RFC3031].
フローラベルのための当初の提案は、それが擬似ランダム値を含めるべきであると提案したデイヴ・クラーク[Deering93]、に起因しています。フローラベルフィールドは、いくつかの競合の提案に関する議論の激しい時代に続いたIPv6の予備設計、時のパケットヘッダに含まれていました。最終的な選択は、1994 [RFC1752]で行われました。特に、IETFは、高性能ルータの次ホップを識別するために、いわゆる「キャッシュ・ハンドル」を含ま次世代インターネットプロトコル（CATNIP）[RFC1707]のための共通のアーキテクチャとして知られている提案を拒否しました。したがって、CATNIPは、ホップバイホップに基づいてパケットの転送を制御するために、フローに属するすべてのパケットによって共有されるヘッダフィールドの概念を導入しました。私たちは、MPLSラベル[RFC3031]の前駆体として、今日これを認識しています。
The IETF decided instead to develop a proposal known as the Simple Internet Protocol plus (SIPP) [RFC1710] into IP version 6. SIPP included "labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-time' service" [RFC1710]. In 1994, this used a 28-bit Flow Label field. In 1995, it was down to 24 bits [RFC1883], and it was finally reduced to 20 bits [RFC2460] to accommodate the IPv6 Traffic Class, which is fully compatible with the IPv4 Type of Service byte.
IETFは、バージョン6 SIPPは、特定のトラフィックに属するパケットの」標識は、このような非として送信者のリクエスト特別な取り扱い、そのために 『流れ』に含まIPに簡単なインターネットプロトコルとして知られている提案を開発する代わりに決めプラス（SIPP）[RFC1710]サービスまたは「リアルタイム」サービス」の-default品質[RFC1710]。 1994年に、これは28ビットのフローラベルフィールドを使用していました。 1995年に、それは、ダウン24ビット[RFC1883]にしたところ、最終的にサービスバイトのIPv4のタイプと完全に互換性がIPv6のトラフィッククラスを収容するために20ビット[RFC2460]に減少しました。
There was considerable debate in the IETF about the very purpose of the flow label. Was it to be a handle for fast switching, as in CATNIP, or was it to be meaningful to applications and used to specify quality of service? Must it be set by the sending host, or could it be set by routers? Could it be modified en route, or must it be delivered with no change?
フローラベルの非常に目的についてIETFにはかなりの議論がありました。 CATNIPのように、それは高速スイッチングのためのハンドルであることだった、またはそれがアプリケーションにとって意味のあることだったとサービスの品質を指定するために使用？それは、送信側ホストで設定しなければならない、またはそれがルータによって設定されるだろうか？それが途中で変更することができ、またはそれは変更なしで送達されなければなりませんか？
Because of these uncertainties, and more urgent work, the flow label was consistently ignored by implementors, and today is set to zero in almost every IPv6 packet. In fact, [RFC2460] defined it as "experimental and subject to change". There was considerable preliminary work, such as [Metzler00], [Conta01a], [Conta01b], and [Hagino01]. The ensuing proposed standard "IPv6 Flow Label Specification" (RFC 3697) [RFC3697] intended to clarify this situation by providing precise boundary conditions for use of the flow label. However, this has not proved successful in promoting use of the flow label in practice, as a result of which 20 bits are unused in every IPv6 packet header.
そのためこれらの不確実性、そしてより緊急の仕事で、フローラベルは一貫して実装によって無視され、今日ではほとんどすべてのIPv6パケットでゼロに設定されています。実際には、[RFC2460]は、「実験と変更すること」として定義されます。 [Hagino01]があり、このような[Metzler00]としてかなりの準備作業は、[Conta01b]、[Conta01a]、だった、と。その後の提案された標準の「IPv6フローラベル仕様」（RFC 3697）[RFC3697]フローラベルを使用するための正確な境界条件を提供することにより、このような状況を明確にすることを意図し。しかしながら、これは、20ビットがすべてのIPv6パケットヘッダに使用されていない、その結果として、実際にフローラベルの使用を促進するのに成功していません。
Developments in high-speed switch design, and the success of MPLS, have largely obviated consideration of the flow label for high-speed switching. Thus, although various use cases for the flow label have been proposed, most of them assume that it should be used principally to support the provision of quality of service (QoS). For many years, it has been recognized that real-time Internet traffic requires a different QoS from general data traffic, and this remains true in the era of network neutrality. Thus, an alternative to uniform best-effort service is needed, requiring packets to be classified as belonging to a particular class of service or flow. Currently, this leads to a layer violation problem, since a 5-tuple is often used to classify each packet. The 5-tuple includes source and destination addresses, port numbers, and the transport protocol type, so when we want to forward or process packets, we need to extract information from the layer above IP. This may be impossible when packets are encrypted such that port numbers are hidden, or when packets are fragmented, so the layer violation is not an academic concern. The flow label, being exempt from IPsec encryption and being replicated in packet fragments, avoids this difficulty. It has therefore attracted attention from the designers of new approaches to QoS.
高速スイッチの設計、およびMPLSの成功の発展は、主に高速スイッチングのためのフローラベルを考慮することを回避しています。フローラベルのためのさまざまな使用例が提案されているがこのように、それらのほとんどは、サービス品質（QoS）の提供をサポートするために主に使用されるべきであることを前提としています。長年にわたり、リアルタイムのインターネットトラフィックは、一般的なデータトラフィックは異なるQoSを要求することが認められているが、これはネットワーク中立性の時代に真のまま。したがって、均一なベストエフォート型のサービスに対する代替は、サービス又はフローの特定のクラスに属するものとして分類されるべきパケットを要求する、必要とされます。 5タプルは、多くの場合、各パケットを分類するために使用されているので、現在、これは、層違反の問題につながります。 5タプルは、我々はパケットを転送又は処理するときに、我々はIP上の層からの情報を抽出する必要があり、送信元および宛先アドレス、ポート番号、トランスポートプロトコルのタイプを含みます。パケットはポート番号が隠されているように暗号化されている場合、またはレイヤ違反が学術的な問題ではないので、パケットは、断片化されたときにこれができない場合があります。フローラベルは、IPsec暗号化を免除され、パケットのフラグメントに複製され、この問題を回避することができます。したがって、新しいアプローチのデザイナーからのQoSに注目を集めています。
RFC 3697 [RFC3697] standardizes properties of the flow label, including the following:
RFC 3697 [RFC3697]は、以下を含むフローラベルのプロパティを、標準化：
o If the packets are not part of any flow, the flow label value is zero.
パケットが任意のフローの一部ではない場合はO、フローラベル値はゼロです。
o The 3-tuple {source address, destination address, flow label} uniquely identifies which packets belong to which particular flow.
3タプル{送信元アドレス、宛先アドレス、フローラベル} oを一意にパケットがどの特定のフローに属するかを識別する。
o Packets can receive flow-specific treatment if the node has been set up with flow-specific state.
ノードは、フロー固有の状態で設定されている場合、Oパケットはフロー特定の治療を受けることができます。
o The flow label set by the source node must be delivered to the destination node; i.e., it is an end-to-end label.
Oソースノードによって設定されたフローラベルは、宛先ノードに配信されなければなりません。すなわち、それは、エンド・ツー・エンドのラベルです。
o The same pair of source and destination addresses must not use the same flow label value again within a timeout of at least 120 seconds.
O送信元アドレスと宛先アドレスの同じ組が、少なくとも120秒のタイムアウト時間内に再度同じフローラベル値を使用してはなりません。
One effect of the second of these rules is to avoid the layer violation problem mentioned in Section 1. By using the 3-tuple, we only use the IP layer to classify packets, without needing any transport-layer information. This may reduce the lookup time if flow-based treatment is required and will work even with IPsec encryption and fragmentation. Therefore, for traffic needing other than best-effort service, such as real-time applications, the flow label can be set to different values to represent different flows, and each node forwarding or receiving the packets may provide different flow-specific treatments by looking at the flow label value. This is more fine-grained than differentiated services (Diffserv) [Carpenter02] [RFC2474] but need not be less efficient.
これらの規則の第二の効果の一つは、3つのタプルを使用することにより第1節で述べた層違反の問題を回避するために、我々は唯一の任意のトランスポート層の情報を必要とせずに、パケットを分類するためにIPレイヤを使用しています。これは、フローベースの治療が必要な場合は、検索時間を減らすことができるとさえIPsec暗号化および断片化で動作します。したがって、トラフィックは、リアルタイムアプリケーションなどのベストエフォートサービス以外の必要のために、フローラベルは、異なるフローを表すために異なる値に設定することができ、パケットを転送又は受信する各ノードは、見ることによって、異なるフロー固有の治療法を提供することができますフローラベル値で。これは、[RFC2474] [Carpenter02]よりきめの細かい差別化サービス（DiffServ）のよりもですが、あまり効果的である必要はありません。
An additional important rule in the standard [RFC3697] effectively forbids any encoding of meaning in the bits of the flow label. To be exact, the standard states that "IPv6 nodes MUST NOT assume any mathematical or other properties of the flow label values assigned by source nodes". This rule is aimed at the case where a packet from a source using a particular encoding scheme for the flow label reaches a node that is using a different scheme. If, by chance, the bit pattern in the flow label is meaningful in both schemes, the receiver would misinterpret the flow label. Therefore, in the absence of other information, the receiver must not assume anything about the meaning of the value of the flow label.
標準[RFC3697]に追加の重要なルール効果フローラベルのビットに意味のいずれかの符号化を禁止します。正確には、「IPv6のノードがソースノードによって割り当てられたフローラベル値の任意の数学的または他の特性を仮定してはいけません」という標準状態。このルールは、フローラベルのための特定の符号化スキームを使用して、ソースからのパケットは、異なるスキームを使用しているノードに到達した場合を目的としています。 、偶然、フローラベルのビットパターンは、両方のスキームでは意味がある場合、受信機は、フローラベルを誤って解釈するでしょう。そのため、他の情報が存在しない場合に、受信機は、フローラベルの値の意味について何も仮定してはいけません。
The standard [RFC3697] also states that "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". The problem this rule is intended to avoid is that if a source uses one method of choosing flow labels (e.g., counting up from 1), any router that assumes another method (e.g., pseudo-randomness) may not perform as intended.
標準[RFC3697]も「ルータの性能は、フローラベル値の分布に依存すべきではない。特に、単独でフローラベルビットがハッシュキーの乏しい材料を作る」と述べています。このルールは、回避することが意図されている問題は、ソース（例えば、1からカウントアップ）フローラベルを選択する1つの方法を使用する場合は意図したように、他の方法（例えば、擬似ランダム）を想定している任意のルータが実行しない可能性があることです。
Note that there is no easy escape from the combination of these two prohibitions, which we will call the dependency prohibition. Unlike Diffserv code points, flow labels are not locally significant within a single administrative domain; they must be preserved end-to-end. In general, a router cannot know whether a particular packet originated in a host supporting a specific usage of the flow label. Therefore, any method that breaks one or both of these rules will only work if there is some way for a router to determine which sources use the same scheme as itself.
私たちは、依存関係の禁止を呼び出します。これらの二つの禁止、の組み合わせから簡単な脱出がないことに注意してください。 Diffservのコードポイントとは異なり、フローラベルは、単一の管理ドメイン内で局所的に有意ではありません。彼らは、エンドツーエンドを保存しなければなりません。一般的には、ルータが特定のパケットは、フローラベルの具体的な使用方法をサポートするホストに由来するかどうかを知ることはできません。ソース自体と同じスキームを使用するかを決定するためのルータのためのいくつかの方法がある場合したがって、一つまたはこれらのルールの両方を破壊する任意の方法でのみ動作します。
The interpretation of the dependency rule can be subtle and is not spelled out in [RFC3697]. A node must not assume properties of the flow label -- but it may know them by construction or by signaling. The bits of the flow label alone are poor material for a hash key -- but they may be combined with bits from other sources, to provide uniformly distributed hash outputs.
依存関係ルールの解釈が微妙なことができて、[RFC3697]で綴られていません。ノードは、フローラベルの性質を仮定してはいけません - しかし、それは建設によってまたはシグナリングすることによって、それらを知っている可能性があります。単独のフローラベルのビットは、ハッシュキーの乏しい材料である - それらは均一に分布したハッシュ出力を提供するために、他のソースからのビットと組み合わせることができます。
[RFC3697] does not discuss how to use the flow label most effectively. This remains the major open issue, but some authors propose that the label should be used with reserved bandwidth to achieve customized QoS provision. Coupled with admission control at the edge router, this could limit congestion. However, as we will see below, this is not the only proposed use.
[RFC3697]最も効果的にフローラベルを使用する方法については説明しません。これは、主要な未解決の問題のままですが、いくつかの著者は、ラベルがカスタマイズされたQoS提供を実現するために予約された帯域幅で使用されるべきであると提案しています。エッジルータにおけるアドミッション制御と相まって、これは、輻輳を制限する可能性があります。私たちは以下を参照されますようしかし、これが唯一の目的とする用途ではありません。
We now introduce some other open issues.
私たちは今、他のいくつかの未解決の問題を紹介します。
o Unknown flow labels: [RFC1809] proposed that when a router receives a datagram with an unknown flow label, it should treat it as zero. However, the standard [RFC3697] is silent on this issue. Indeed, some methods of flow state establishment might choose to use an unknown label as the trigger for creating flow state.
O不明なフローラベル：[RFC1809]は、ルータが未知のフローラベルを持つデータグラムを受信したとき、それはゼロとして扱うべきであると提案しました。しかし、標準[RFC3697]は、この問題について沈黙しています。確かに、フロー状態設立のいくつかの方法が流動状態を作成するためのトリガーとして、未知のラベルを使用することを選択するかもしれません。
o Deleting old flow labels: When a flow finishes, how does the router know the flow label has expired? Should this be based on a timeout, on observation of the transport layer, or on explicit signaling? [RFC3697] defines a timeout (120 seconds) that effectively imposes a maximum lifetime on flow label state in a router. This implies that flow labeling is inappropriate for very intermittent flows, unless there is some mechanism to refresh router state. In contrast, [Banerjee02] suggested that a router should send an ICMP message to the source prior to deleting a particular label. The source node may then send a KEEPALIVE message to the router; if it does not, the router will release that label.
古いフローラベルを削除する○：フローが終了すると、どのようにルータがフローラベルの有効期限が切れている知っているのですか？これは、トランスポート層の観察上、または明示的シグナリングに、タイムアウトに基づいている必要がありますか？ [RFC3697]は有効ルータにフローラベル状態の最大寿命を課しタイムアウト（120秒）を定義します。これは、ルータの状態をリフレッシュするためにいくつかのメカニズムがない限り、フローラベルは、非常に断続的な流れには不適切であることを意味します。対照的に、[Banerjee02]ルータは、事前特定のラベルを削除するソースにICMPメッセージを送信する必要があることを示唆しました。ソースノードは、ルータにキープアライブメッセージを送信することができます。そうでない場合、ルータはそのラベルを解放します。
o Choosing when to set the flow label: For what kinds of applications should we set up non-zero flow labels? [RFC1809] suggested not setting it for short flows containing few bytes but using it for long TCP connections and some real-time applications.
私たちは非ゼロフローラベルを設定する必要があり、アプリケーションのどのような種類のために：フローラベルを設定する際に選択するO？ [RFC1809]は数バイトを含む短いフローのためにそれを設定することが、長いTCPコネクションと、いくつかのリアルタイムアプリケーションのためにそれを使用していない提案しました。
o Can we modify the flow label? [RFC3697] states that the flow label must be delivered unchanged. There are several advantages of immutable flow labels, apart from respecting the standard: the rule is easy to understand, does not require extra processing in routers or a signaling protocol, and allows for very simple host implementations. Also, it is straightforward for hosts and routers to simply ignore the flow label. However, this rule does appear to exclude any MPLS-like or CATNIP-like use for optimized packet switching. Some of the proposed mechanisms described below contradict this by suggesting that switches should change the flow label for routing purposes.
oお客様は、フローラベルを変更することはできますか？ [RFC3697]はフローラベルをそのまま配信しなければならないと述べています。不変のフローラベルのいくつかの利点がありますが、離れて標準を尊重するから：ルールは、ルータやシグナリングプロトコルで余分な処理を必要としない、理解しやすく、非常に単純なホスト実装が可能になります。ホストとルータは、単にフローラベルを無視するためにも、それは簡単です。しかし、このルールは、最適化されたパケット交換のための任意のMPLS状またはCATNIP-などの使用を除外するように見えるん。以下に記載する提案の機構の一部は、スイッチは、ルーティングの目的でフローラベルを変更する必要があることを示唆することによって、これを矛盾します。
In the following, we do not intend to recommend or criticize various proposals. This section shows the variety of proposals that have been published, and whether they are compatible with the existing standard. These proposals almost all assume that the flow label's main purpose is to support QoS, and their flow label mechanisms are entangled with QoS mechanisms. We describe the proposals in five broad, and somewhat overlapping, categories, i.e.,
以下では、お勧めや様々な提案を批判するつもりはありません。このセクションでは、公表されている種々の提案を示しており、彼らは既存の標準と互換性があるかどうか。これらの提案は、ほとんどすべては、フローラベルの主な目的は、QoSをサポートすることで、そのフローラベルメカニズムがQoSメカニズムに巻き込まれていることを前提としています。私たちは、すなわち、5、広範な、とやや重複カテゴリの提案を説明し、
1. using pseudo-random flow label values for various purposes (for example, to improve routing performance when retrieving cached routing state);
1.（キャッシュされたルーティング状態を取得する場合、例えば、ルーティング性能を向上させるために）様々な目的のために、擬似ランダムフローラベル値を用いて、
2. defining specific QoS requirements as parameters embedded in the flow label field;
フローラベルフィールドに埋め込まれたパラメータとして特定のQoS要件を定義する2。
4. using the flow label specifically to extend the existing differentiated services QoS architecture;
4.既存の差別化サービスのQoSアーキテクチャを拡張するために、具体的フローラベルを使用しました。
Among the proposals described in the following five sections, various methods are proposed to set up the flow label value. It should be noted that some of these proposals embody novel and perhaps controversial approaches to QoS provision, and these cannot readily be separated from their use of the flow label. We give a reasonable amount of technical detail for some of the proposals, to show the extent to which they propose detailed semantics for the flow label value.
次の5つのセクションで説明した提案の中で、様々な方法がフローラベル値を設定することが提案されています。これらの提案のいくつかは、QoS提供の小説、おそらく論争のアプローチを具現化することに留意すべきであり、これらは容易にフローラベルの利用から分離することはできません。我々は、彼らがフローラベル値の詳細なセマンティクスを提案する度合いを示すように、提案のいくつかのための技術的な詳細の合理的な量を与えます。
As our first example, [Lin06] specifies a 17-bit pseudo-random value. The figure below shows the proposed flow label structure.
最初の例として、[Lin06]は17ビットの擬似ランダム値を指定します。下の図は、提案されたフローラベル構造を示しています。
o The Label Flag (LF) bit: 1 means this type of flow label is present. We note that this encoding is incompatible with the dependency prohibition in [RFC3697], since a source that does not use this method may also set the LF bit.
ラベルフラグ（LF）ビット○：1フローラベルのこのタイプが存在することを意味します。我々は、この方法を使用していないソースもLFのビットを設定することができるので、この符号化は、[RFC3697]に依存禁止と互換性がないことに注意してください。
o The Label Type (LT): 2 bits; describes the type of packet.
Oラベルタイプ（LT）：2ビット。パケットの種類を説明しています。
o The Label Number (LN): randomly generated by the source node.
Oラベル番号（LN）：ランダムソースノードによって生成されました。
[Lin06] also describes a signaling process between source, routing, and destination nodes based on this label structure and on the IPv6 Traffic Class byte, in order to reserve and release router resources for a given flow within a given class of traffic. The pseudo-random LN value is used to uniquely identify a given flow.
[Lin06]また、トラフィックの指定されたクラス内の所定のフローのためのルータのリソースを予約し、解放するために、このラベル構造上およびIPv6のトラフィッククラスのバイトに基づいて、ソース、ルーティング、および宛先ノード間のシグナリングの方法を記載しています。擬似ランダムLN値が一意に与えられたフローを識別するために使用されます。
Flow Label Specification (figure simplified from [Lin06])
フローラベル仕様（[Lin06]から単純化された図）
+--+----+-----------------------------+
| 1| 2 | 17 bits |
+--+----+-----------------------------+
|LF| LT | LN |
+--+----+-----------------------------+
LF 0 Disable 1 Enable LT 00 Flow label requested by source 01 Flow label returned by destination 10 Flow label for data delivery 11 Flow label terminates connection LN Random number created by source
LF 0ディセーブル1は、データ配信のために11フローラベルは、ソースによって作成された接続LN乱数を終了先10フローラベルによって返されたソース01フローラベルによって要求されたLT 00フローラベルを有効にします
There have been numerous informal discussions of using pseudo-random flow labels to allow load-balancing or at least load-sharing. This would be achieved by including the flow label value among the fields in each packet header used as input to a modulo(N) hash used to select among N alternative paths. However, concerns about the interpretation of the dependency prohibition have generally prevented such proposals from being written up until recently [Carpenter11].
負荷分散または少なくとも負荷分散を可能にするために、擬似ランダムフローラベルを使用して、多数の非公式協議が行われてきました。これはモジュロ（N）ハッシュへの入力は、N個の代替経路の中から選択するために使用されるように使用される各パケットのヘッダ内のフィールドのうちフローラベル値を含むことによって達成されます。しかし、依存関係の禁止の解釈についての懸念は、一般的に、最近[Carpenter11]まで書かれているから、このような提案を妨げてきました。
Another proposal for a pseudo-random flow label value is [Blake09]. This states that off-path spoofing attacks have become a big issue for TCP and other transport-layer applications, and proposes that in IPv6 we should set a random value in the flow label to make the packet header more complex and less easy for the attacker to guess. The two ends of the session will agree on flow label values during the SYN/ACK exchange, but off-path attackers will be unlikely to guess the agreed value. Naturally, on-path attackers who can observe the flow labels in use can trivially defeat this protection. This proposal does not involve using the flow label value to retrieve routing state.
擬似ランダムフローラベル値のための別の提案は、[Blake09]です。これは、オフパススプーフィング攻撃は、TCPや他のトランスポート層アプリケーションのための大きな問題となっていると述べ、およびIPv6に、我々は攻撃者のためのパケットヘッダはより複雑であまり簡単にするために、フローラベルにランダムな値を設定すべきであると提案しています推測する。セッションの両端には、SYN / ACK交換中にフローラベル値に同意しますが、オフパス攻撃者が合意された値を推測する可能性は低いだろう。当然のことながら、使用中のフローラベルを観察することができます上のパス攻撃者が自明この保護を倒すことができます。この提案は、状態のルーティングを取得するために、フローラベル値を使用して関与していません。
[Prakash04] proposes to utilize the flow label to indicate required QoS parameters in detail. It uses the first few bits of the Flow Label field as codes to support different approaches, as summarized in the following table. Again, this is incompatible with the dependency prohibition in [RFC3697], since a source that does not use this method may also set the first two bits to non-zero.
【Prakash04】詳細に必要なQoSパラメータを示すために、フローラベルを利用することを提案します。これは、以下の表にまとめたように、異なるアプローチをサポートするためのコードとしてフローラベルフィールドの最初の数ビットを使用しています。この方法を使用していないソースは、非ゼロに最初の2ビットを設定することができるので、再び、これは、[RFC3697]に依存禁止と互換性がありません。
Classification for various approaches (from [Prakash04])
（[Prakash04]から）様々なアプローチの分類
Bit Pattern Approach
------------------------------------------------------------------
00 No QoS requirement (Default QoS value)
01 Pseudo-Random value used for the value of Flow-Label
10 Support for Direct Parametric Representation
1100 Support for the DiffServ Model
1101 Reserved for future use
111 Reserved for future use
This method allows a pseudo-random option but also adds options for a direct QoS request and for Diffserv. In the direct QoS parameters approach, 18 bits are used to encode requirements for one-way delay, IP delay variation, bandwidth, and one-way packet loss. The proposal appears to assume that the Resource Reservation Protocol (RSVP) [RFC2205] mechanisms are used to actually implement these QoS parameters.
この方法は、擬似ランダムオプションを可能にするだけでなく、直接のQoS要求のためとDiffservのためのオプションが追加されます。直接的QoSパラメータのアプローチでは、18ビットが一方向遅延、IP遅延変動、帯域幅、及び一方向パケット損失の要件を符号化するために使用されます。提案は、リソース予約プロトコル（RSVP）[RFC2205]メカニズムが実際にこれらのQoSパラメータを実装するために使用されていることを前提とするように見えます。
This proposal allows the use of the flow label for various important QoS models, so the end user and service provider can choose the most suitable model for their situation; [Prakash04] claims that "The proposed approach results in a simple, scalable, modular and generic implementation to provide for QoS using the IPv6 flow label field".
エンドユーザとサービスプロバイダが自分の状況に最も適したモデルを選択することができますので、この提案は、様々な重要なQoSモデルのフローラベルを使用することができます。 [Prakash04]「のIPv6フローラベルフィールドを使用してQoSを提供するために、簡単なスケーラブル、モジュラーおよび一般的な実装で提案されたアプローチの結果」と主張しています。
Similarly, [Lee04] defines the Flow Label field in five parts, with the first 3 bits used as an approach type. The authors define two approaches: a "random" scheme and a "hybrid" scheme. If the first 3 bits equal "001", the flow label will be used as the random identifier of the flow, but if they equal "101", the remaining bits will include a hybrid QoS requirement for this packet, subdivided into traffic type (stringent or best-effort), bandwidth, buffer, and delay requirements. Once again, the dependency prohibition in [RFC3697] is broken. This proposal also includes throughput monitoring and dynamic capacity allocation. Effectively, this proposal uses the flow label both to signal Intserv-like QoS requirements and to classify traffic into Diffserv-like virtual label-switched paths. Packets with a "random" flow label are mapped into a generic (best-effort) virtual path.
同様に、[Lee04]アプローチ型として使用される最初の3ビットと、5つの部分でフローラベルフィールドを定義します。 「ランダム」スキームと「ハイブリッド」スキーム：著者は、二つのアプローチを定義します。最初の3ビットが「001」に等しい場合、フローラベルは、フローのランダムな識別子として使用されるであろうが、彼らは「101」に等しい場合、残りのビットは（トラフィックタイプに細分、このパケットのハイブリッドQoS要求を含むであろう）厳しいまたはベストエフォート、帯域幅、バッファ、および遅延要求。再度、[RFC3697]に依存禁止が壊れています。この提案はまた、スループットの監視および動的容量割り当てを含みます。事実上、この提案はイントサーブのようなQoS要件を合図するとDiffservのような仮想ラベルスイッチパスにトラフィックを分類するために、両方のフローラベルを使用しています。 「ランダム」フローラベルを持つパケットは、ジェネリック（ベストエフォート）の仮想パスにマップされます。
[Chakravorty08b] and [Chakravorty08a] describe an architectural framework called "IPv6 Label Switching Architecture" (6LSA). In 6LSA, network components identify a flow by looking at the Flow Label field in the IPv6 packet header; all packets with the same flow label must receive the same treatment and be sent to the same next hop. However, 6LSA resembles MPLS by considering that a label only has meaning between 6LSA routers and setting the flow label at each hop. If the original source sets a non-zero flow label, there is no mechanism to restore it before delivery: a fundamental breach of [RFC3697]. The authors of [Chakravorty08b] did at one stage discuss using an IPv6 hop-by-hop option to correct this problem, but this has not been documented. This is a more serious incompatibility than simply breaking the dependency prohibition.
[Chakravorty08b]と[Chakravorty08a] "IPv6のラベル・スイッチング・アーキテクチャ"（6LSA）と呼ばれるアーキテクチャフレームワークについて説明します。 6LSAでは、ネットワーク構成要素は、IPv6パケットヘッダーのフローラベルフィールドを見ることによって、フローを識別します。同じフローラベルを持つすべてのパケットが同じ治療を受けなければならないと同じ次のホップに送られます。しかし、6LSAは、ラベルのみ6LSAルータ間を意味し、各ホップでフローラベルを設定していることを考慮することにより、MPLSに似ています。 [RFC3697]の基本的な違反：元のソースが非ゼロのフローラベルを設定した場合は、出荷前にそれを復元するメカニズムはありません。 [Chakravorty08b]の著者は、1つの段階では、この問題を修正するために、IPv6のホップバイホップオプションを使用して議論しましたが、これは、文書化されていません。これは、単純に依存禁止を壊すよりも深刻な非互換性です。
Unlike traditional routing algorithms, but like MPLS, 6LSA packets are classified into a Forwarding Equivalence Class (FEC), and routers forward packets on different paths by looking at the FEC. Like previous solutions, this solution divides the Flow Label field into three parts. The first 3 bits identify the FEC, which will help the router or 6LSA nodes to group the IP packets that receive the same forwarding treatment and forward them on the same virtual path. The following 4 bits describe the application type, and the final 13 bits (defined by each node or a group of nodes) specify the hop-specific label. From the table below, we can see the FEC has 6 major categories, each with up to 16 subcategories.
伝統的なルーティングアルゴリズムとは異なり、しかしようなMPLS、6LSAパケットが転送等価クラス（FEC）に分類され、ルータがFECを見て異なる経路でパケットを転送します。以前のソリューションと同様に、このソリューションは、三つの部分にフローラベルフィールドを分割します。最初の3ビットは、グループに同一の転送処理を受け、同じ仮想パスでそれらを転送するIPパケットをルータまたは6LSAノードを助けるFECを識別する。次の4ビットは、アプリケーションタイプを記述し、（各ノードまたはノードのグループによって定義された）最終的な13ビットがホップ特定のラベルを指定します。下の表から、我々は最大16個のサブカテゴリで、FECは、6つの主要なカテゴリがあり、それぞれを見ることができます。
Flow Label Specification (shortened from [Chakravorty08b])
（[Chakravorty08b]から短縮）フローラベル仕様
+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits) | Next 4 Bits | Purpose |
+--------------------------+-------------+--------------------------+
| No FEC (000) | 0000 | |
| Domain Specific (000) | 0001 - 1111 | |
| ------------------------ | | |
| VPN (001) | 0001 | (IPSec - Tunnel Mode) |
| | 0010 | (IPSec - Transport Mode) |
| | 0011 | (Special Encryption) |
| | 0100 | (VRF) |
| | 0101 | (End Network Specific) |
| | 0110 - 1111 | (Reserved) |
| ------------------------ | | |
| TE Subset/ | 0001 | (DiffServ) |
| QoS Enhancement (010) | 0010 | (RSVP) |
. . .
| | 1111 | (Reserved) |
| ------------------------ | | |
| Encapsulation (011) | 0001 | (IPv6 in IPv6) |
| | 0010 | (IPv4 in IPv6) |
| | 0011 | (Other in IPv6) |
| | 0100 | (Enterprise Specific) |
| | 0101 - 1111 | (Reserved) |
| ------------------------ | | |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) |
+--------------------------+-------------+--------------------------+
The authors claim that fast switching using 20-bit labels instead of 128-bit IPv6 addresses will provide memory and processing savings, as well as network management advantages. "It also allows a network management entity updating available label tables, across the network to reduce man-in-the-middle attacks [sic]" [Chakravorty08b].
著者らは、高速スイッチング、メモリ及び処理の節約、ならびにネットワーク管理上の利点を提供する20ビット・ラベルの代わりに、128ビットのIPv6アドレスを使用することを主張します。 「また、man-in-the-middle攻撃を軽減するために、ネットワークを介して、利用できるラベルテーブルを更新するネットワーク管理エンティティを可能にする[原文]」[Chakravorty08b]。
We note that a similar proposal for QoS-based switching of IPv6 packets [Roberts05] is designed to use a hop-by-hop option, which has not so far been allocated by the IETF. Proposals related to this have been discussed by the Telecommunications Industry Association and the ITU-T [Adams08].
私たちは、IPv6パケット[Roberts05]のQoSベースのスイッチングのために同様の提案がこれまでにIETFによって割り当てられていないホップバイホップオプションを使用するように設計されていることに注意してください。これに関連した提案は、米国電気通信工業会とITU-T [Adams08]で議論されています。
We also note that router lookup efficiency was a major concern at the time when Clark first proposed a flow label [Deering93], but with the advent of very large scale integrated circuits capable of rapid lookup in a routing table, most vendors no longer express such concern.
我々はまた、ルータの検索効率の点に注意してください。クラークは、最初の[Deering93]フローラベルを提案しませんが、ルーティングテーブルの急速な検索が可能非常に大規模集積回路の出現で、ほとんどのベンダーは、もはやそのように表現する時に主要な関心事でした懸念。
[Banerjee02] uses the Flow Label field as a replacement for the IPv6 Traffic Class field; this proposal suggests the incoming flow label can indicate the QoS requirement by matching a Diffserv classifier. The authors have used the first three bits to indicate this, and the following 16 bits to indicate a Differentiated Services Per-Hop Behavior Identification code (Diffserv PHB-ID) [RFC3140]; the last bit is reserved for future use. This method too breaks the dependency prohibition in [RFC3697].
[Banerjee02] IPv6のトラフィッククラスフィールドの代替として、フローラベルフィールドを使用しています。この提案は、着信フローラベルは、Diffservの分類器を照合することによってQoS要件を示すことができます示唆しています。著者らは、このことを示すために、最初の3ビットを使用している、そして次の16ビットは、ホップ単位動作識別コード（DiffservのPHB-ID）[RFC3140]差別化サービスを指示します。最後のビットは将来の使用のために予約されています。この方法では、あまりにも[RFC3697]での依存関係の禁止を破ります。
[Beckman07a] blends the flow label as an MPLS-like switching tag with Diffserv. Unlike 6LSA, the method attempts to bypass the dependency prohibition by using one bit in the Diffserv Code Point [RFC2474] to indicate that the flow label is a switching tag. In this way, a router can determine whether the flow label conforms to [RFC3697] or to [Beckman07a]. In [Beckman07b], the same author proposes using the flow label as a way of compressing IPv6 headers by hashing the addresses into the flow label, again using the Diffserv Code Point to mark the packets accordingly.
【Beckman07a】MPLS状のDiffservでタグを切り換えるようにフローラベルをブレンド。 6LSAとは異なり、この方法は、フローラベルスイッチングタグであることを示すために、Diffservのコードポイント[RFC2474]に1ビットを使用して、依存関係禁止を迂回しようと試みます。このように、ルータは、フローラベルは[RFC3697]または[Beckman07a]に準拠しているかどうかを判定することができます。 【Beckman07b]において、同じ著者はそれに応じてパケットをマークするDiffservのコードポイントを使用して再度、フローラベルにアドレスをハッシュすることによってIPv6のヘッダを圧縮する方法として、フローラベルを使用して提案しています。
The Integrated Services QoS architecture [RFC1633] specifies that the flow label may be used as a packet filter [RFC2205]. At least one implementation supported this [Braden10].
統合サービスのQoSアーキテクチャ[RFC1633]は、フローラベルはパケットフィルタ[RFC2205]として使用することができることを指定します。少なくとも一つの実装は、[Braden10]これを支持しました。
We are not aware of any proposals combining the flow label with the Next Steps in Signaling (NSIS) [RFC4080] architecture.
我々は（NSIS）[RFC4080]のアーキテクチャを合図に次のステップにフローラベルを組み合わせて任意の提案を認識していません。
[Donley11] proposes a use case whereby certain flows encapsulated in a particular type of IPv4-in-IPv6 tunnel would be distinguished at the remote end of the tunnel by a specific flow label value. This would allow a service provider to deliver a tailored quality of service. This usage appears to be completely compatible with [RFC3697].
【Donley11]特定のフローは、IPv4インのIPv6トンネルは、特定のフローラベル値によってトンネルのリモートエンドで区別される特定のタイプの中に封入されるユースケースを提案しています。これは、サービスプロバイダがサービスの仕立て品質を提供できるようになります。この用法は[RFC3697]と完全に互換性があるように見えます。
There has been some discussion of possible flow label use in both the ROLL (Routing Over Low power and Lossy networks) [RPL-07] and MEXT (Mobility EXTensions for IPv6) working groups of the IETF. Such uses tend to encode specific local meanings or routing-related tags in the label, so they appear to infringe the dependency prohibition or the immutability of the Flow Label field. The ROLL group has indeed most recently opted not to use the Flow Label field for these reasons, despite having to add the undesirable overhead of an IPv6 hop-by-hop option instead [RPL]. Similarly, MEXT has defined a new mobility option to support flow bindings [RFC6089] rather than using the IPv6 Flow Label field.
いくつかの（低消費電力とロッシーネットワーク上でルーティング）ROLLの両方で可能なフローラベルの使用についての考察[RPL-07]と文部科学省（IPv6のモビリティの拡張機能）IETFのワーキンググループがありました。このような用途には、ラベルに特定のローカルな意味やルーティング関連タグをコード化する傾向があるので、彼らは、依存関係の禁止やフローラベルフィールドの不変性を侵害するように見えます。 ROLLグループは、確かに最近のIPv6ホップバイホップオプションの代わりに[RPL]の望ましくないオーバーヘッドを追加することにもかかわらず、これらの理由のためにフローラベルフィールドを使用しないことを選んだしました。同様に、文部科学省ではなく、IPv6のフローラベルフィールドを使用するよりも、フローバインディングをサポートする新しいモビリティオプション[RFC6089]を定義しました。
Three aspects of the current standard [RFC3697] have caused problems for many designers:
現在の標準[RFC3697]の三つの側面には、多くのデザイナーのための問題を引き起こしています：
2. "Nodes MUST NOT assume any mathematical or other properties of the Flow Label"
2.「ノードは、フローラベルの任意の数学的または他の特性を仮定してはいけません」
3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values"
3.「ルータのパフォーマンスは、フローラベル値の分布に依存すべきではありません」
Taken together, these rules essentially forbid any encoding of the semantics of a flow, or of any information about its path, in the flow label. This was intentional, in accordance with the stateless nature of the Internet architecture and with the end-to-end principle [Saltzer84], [RFC3724]. It was also felt that QoS encoding via Diffserv was sufficient and that the requirement for high-speed switching could be met by MPLS. But this means that the majority of the proposals described above breach the standard and the intent of the standard. The authors often appear to be using the flow label either as an MPLS-like switching handle or as an encoded QoS signal.
まとめると、これらのルールは、基本的にフローラベルに、またはそのパスに関する情報の流れの意味のいずれかのエンコーディングを禁止しています。これは、インターネットアーキテクチャのステートレスな性質に従っておよびエンド・ツー・エンド原理[Saltzer84]、[RFC3724]で、意図的でした。それはまた、Diffservの経由のQoS符号化が十分であったと感じたと高速スイッチングのための要件は、MPLSによって満たすことができること。しかし、これは提案の大半は違反の上の標準と標準の意図を説明したことを意味します。著者は、多くの場合、MPLSのようなスイッチングハンドルとしてまたはエンコードされたQoS信号のいずれかとしてフローラベルを使用しているように見えます。
In contrast, a few documents mentioned above do appear to respect the rules of RFC 3697. These are [Blake09], [Donley11], [Carpenter11], [Beckman07a], and [Beckman07b]. Additionally, [Lin06] would have joined this list if it had not assigned three flag bits in the Flow Label field. Although predating RFC 3697, the Integrated Services usage [RFC2205] also seems to be compatible.
対照的に、上述したいくつかのドキュメントは、RFC 3697.これら【Blake09]であり、[Donley11]、[Carpenter11]、[Beckman07a]、および[Beckman07b]のルールを尊重するように見えるん。それはフローラベルフィールドに3つのフラグビットが割り当てられていなかった場合はさらに、[Lin06]このリストに参加しています。 RFC 3697より以前のが、統合サービスの使用[RFC2205]も互換性があるように思われます。
What would other designers need to do, if they wish to respect RFC 3697? There appear to be two choices. One is to simply accept the existing rules at face value, as in the proposals just listed. This limits the application of the flow label. It can, for example, be used as a nonce or as part of the material for a hash used to share load among alternate paths. It cannot be the only material for such a hash, because of the dependency prohibition. The flow label could also be used consistently with RFC 3697, if an application designer so chose, as a way to associate all packets belonging to a given application session between two hosts, across multiple transport sessions. This, however, would presumably exclude using the flow label to govern routing decisions in any way, and would have widespread implications that have never been explored.
彼らはRFC 3697を尊重したい場合はどのような他の設計者は、実行する必要がありますか？二つの選択肢があるように思われます。一つは単純にリストされた提案のように、額面で既存のルールを受け入れることです。これは、フローラベルの適用を制限します。これは、例えば、ナンスとして、または代替パス間で負荷を共有するために使用されるハッシュの材料の一部として使用することができます。これは、理由の依存禁止のため、そのようなハッシュのための唯一の材料とすることはできません。アプリケーション設計者がそう選択した場合、フローラベルはまた、複数のトランスポートセッションで2つのホスト間の所与のアプリケーションセッションに属するすべてのパケットを関連付ける方法として、RFC 3697で一貫して使用することができます。これは、しかし、おそらくどのような方法でルーティングの決定を支配するためにフローラベルを使用して除外され、探求されたことがない広範な意味合いを持っているでしょう。
The other choice, for designers who wish to use the flow label to control switching or QoS directly, is to bypass the rules within a given domain (a set of cooperating nodes) in a way that nodes outside the domain cannot detect. In this case, any deviation from RFC 3697 has no possible effect outside the domain in question.
他の選択肢は、直接スイッチングまたはQoS制御するためのフローラベルを使用する設計者のために、ドメイン外のノードが検出できないような方法で与えられたドメイン（ノードの協力のセット）内のルールをバイパスすることです。この場合には、RFC 3697からの偏差は、問題のドメインの外に何可能な効果を有しません。
An example scheme to emulate the immutability of labels is as follows. Within the domain, all hosts set the label to zero, the routers set and interpret the label in any way they wish, and the last-hop router always sets the label back to zero. If a packet arrives from outside the domain with a non-zero label, there is a method (such as a special Diffserv code point) to mark this packet so that its label would be ignored and delivered unchanged. An alternative approach would be to define a hop-by-hop option to carry the original flow label across the domain, so that it could be changed within the domain but restored before forwarding the packet beyond the domain.
次のようにラベルの不変性をエミュレートする例方式があります。ドメイン内では、すべてのホストがルータが設定され、ゼロにラベルを設定し、彼らが望むどのような方法でラベルを解釈し、そして最後のホップルータは常にゼロに戻ってラベルを設定します。パケットが非ゼロのラベルを持つドメインの外部から到着した場合、そのラベルは無視され、不変送達されるように、このパケットをマークする（例えば、特別のDiffservコードポイントのような）方法があります。別のアプローチは、それがドメイン内で変更が、ドメインを超えてパケットを転送する前に復元することができるように、ドメイン全体に元のフローラベルを運ぶためにホップバイホップオプションを定義することです。
If a domain allows mutable labels in such a way, it may safely ignore the dependency prohibition, and it may set the bits in the label according to locally defined rules. Within the domain, the label could be used as desired, and most of the proposed designs discussed above could be "rescued".
ドメインは、そのような方法で変更可能な標識を可能にする場合は、安全に依存禁止を無視することができる、それがローカルに定義されたルールに従って、ラベルのビットを設定してもよいです。ドメイン内で必要に応じて、ラベルを使用することができ、そして上記の提案の設計のほとんどは「救出」することができます。
However, given the considerable number of designers who have proposed solutions incompatible with RFC 3697, the relatively few designs using the standard rules, and the failure of designs such as ROLL and MEXT to make use of the flow label, it seems reasonable to ask whether the RFC 3697 standard has value.
しかし、RFC 3697との互換性のないソリューションを提案してきたデザイナーのかなりの数を考えると、標準的な規則を使用して、比較的少数の設計、および、そのようなフローラベルを利用するROLLや文部科学省などの設計の失敗は、するかどうかを尋ねるために合理的なようですRFC 3697標準には、値を持っています。
The flow label is not protected in any way and can be forged by an on-path attacker. Off-path attackers may be able to guess a valid flow label unless a pseudo-random value is used. Specific usage models for the flow label need to allow for these exposures. For further discussion, see [RFC3697].
フローラベルは、どのような方法で保護されていないとのパス攻撃者によって偽造することができます。擬似ランダム値が使用されていない限り、オフ・パス攻撃者は、有効なフローラベルを推測することができるかもしれません。フローラベルのための具体的な使用モデルは、これらのエクスポージャーを可能にする必要があります。さらなる議論に関しては、[RFC3697]を参照してください。
An invaluable review of this document was performed by Bob Braden. Helpful comments were made by Sheng Jiang.
このドキュメントの貴重なレビューはボブブレーデンによって行われました。有益なコメントはシェン・ジャンによって作られました。
[Adams08] Adams, J., Joung, J., and J. Song, "Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow", Work in Progress, June 2008.
【Adams08]アダムス、J.、Joung、J.、およびJ.ソング、「進行およびフロー状態認識基準の将来の発展、およびフローに関連するデータにノードまたはエンドシステムに警告するための提案」、ProgressのWork 2008年6月。
[Amante11] Amante, S., Carpenter, B., and S. Jiang, "Rationale for update to the IPv6 flow label specification", Work in Progress, May 2011.
[Amante11] Amante、S.、大工、B.、およびS.江、 "IPv6のフローラベル仕様への更新のための理論的根拠"、進歩、2011年5月での作業。
[Banerjee02] Banerjee, R., Malhotra, S., and M. M, "A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using a hybrid approach", Work in Progress, April 2002.
[Banerjee02]バネルジー、R.、マルホトラ、S.、およびM. M、進歩、2002年4月に、作業「ハイブリッドアプローチを使用してサービスの効率的な品質を提供するためのIPv6フローラベルを使用するために修正仕様」。
[Beckman07a] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, February 2007.
[Beckman07a]ベックマン、M.、 "IPv6のダイナミックフローラベル・スイッチング（FLS）"、進歩、2007年2月での作業。
[Beckman07b] Beckman, M., "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Work in Progress, November 2006.
[Beckman07b]ベックマン、M.、 "IPv6のヘッダ圧縮緩和プロトコル（IPv6のAMP）アドレッシングを経由して"、進歩、2006年11月に作業を。
[Blake09] Blake, S., "Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks", Work in Progress, October 2009.
[Blake09]ブレイク、S.、進歩、2009年10月に、ワーク「オフパススプーフィング攻撃を防御するためのトランスポート・レイヤナンスなどのIPv6フローラベルの使用」。
[Braden10] Braden, R., "Private Communication", 2010.
[Braden10]ブレーデン、R.、 "プライベート・コミュニケーション"、2010年。
[Carpenter02] Carpenter, B. and K. Nichols, "Differentiated Services in the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
【Carpenter02]カーペンター、B.及びK.ニコルズ、 "インターネットで差別化サービス"、PROC IEEE 90（9）1479年から1494年2002年。
[Carpenter11] Carpenter, B. and S. Amante, "Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels", Work in Progress, May 2011.
【Carpenter11]カーペンター、B.及びS. Amante、「トンネル内等コストマルチパスルーティング及びリンクアグリゲーションのIPv6フローラベルの使用」、進歩、2011年5月に働いています。
[Chakravorty08a] Chakravorty, S., "Challenges of IPv6 Flow Label implementation", Proc IEEE MILCOM2008, 2008.
[Chakravorty08a] Chakravorty、S.、 "IPv6のフローラベルの実装の課題"、PROC IEEE MILCOM2008、2008。
[Chakravorty08b] Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label Switching Architecture", Work in Progress, July 2008.
[Chakravorty08b] Chakravorty、S.、ブッシュ、J.、およびJ.バウンド、 "スイッチングアーキテクチャのIPv6ラベル"、進歩、2008年7月に作業。
[Conta01a] Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow Label Specification", Work in Progress, July 2001.
[Conta01a]コンタ、A.およびB.大工、「IPv6のフローラベル仕様の提案」、進歩、2001年7月での作業。
[Conta01b] Conta, A. and J. Rajahalme, "A model for Diffserv use of the IPv6 Flow Label Specification", Work in Progress, November 2001.
[Conta01b]コンタ、A.、およびJ. Rajahalme、「IPv6のフローラベル仕様のDiffservの使用のためのモデル」、進歩、2001年11月の作品。
[Deering93] Deering, S., "SIPP Overview and Issues", Minutes of the Joint Sessions of the SIP and PIP Working Groups, November 1993.
[Deering93]デアリング、S.、「SIPPの概要と課題」、SIPの合同セッションとPIPワーキンググループ、1993年11月の議事録。
[Donley11] Donley, C. and K. Erichsen, "Using the Flow Label with Dual-Stack Lite", Work in Progress, January 2011.
[Donley11] Donley、C.およびK.エリクセン、進歩、2011年1月の作業「デュアルスタックLiteでフローラベルを使用します」。
[Hagino01] Hagino, J., "Socket API for IPv6 flow label field", Work in Progress, April 2001.
[Hagino01]萩野、J.、 "IPv6のフローラベルフィールドのソケットAPI"、進歩、2001年4月に作業。
[Lee04] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real-Time Traffic Using IPv6 Flow Labels", Lecture Notes in Computer Science Vol. 3043, 2004.
[Lee04]リー、I.およびS.キム、コンピュータサイエンス巻で講義ノートの「IPv6フローラベルを用いたリアルタイムトラフィックのQoS改善スキーム」。 3043、2004。
[Lin06] Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS Provisioning by Flow Label in IPv6", JCIS , 2006.
[Lin06]林、C.、ツェン、P.、およびW.黄 "エンドツーエンドのQoSプロビジョニングIPv6におけるフローラベルによって"、JCIS、2006。
[Metzler00] Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 flow label", Work in Progress, November 2000.
【Metzler00]メッツラー、J.及びS. Hauth「のIPv6フローラベルのエンド・ツー・エンドの利用」、進歩、2000年11月に働いています。
[Prakash04] Prakash, B., "Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet", University of Colorado (M.Sc. Thesis), 2004.
【Prakash04】プラカシュ、B.、「インターネット上のサービスの望ましい品質を示すために、IPv6ヘッダーの20ビットのフローラベルフィールドを使用する」、コロラド大学（修士論文）2004。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, October 1994.
[RFC1707]マクガバン、M.とR.ウルマン、 "CATNIP：インターネットのための共通のアーキテクチャ"、RFC 1707、1994年10月。
[RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994.
[RFC1710] HindenとR.、 "簡単なインターネットプロトコルプラス白書"、RFC 1710、1994年10月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752]ブラドナー、S.およびA.マンキン、 "IP次世代プロトコルのための勧告"、RFC 1752、1995年1月。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
[RFC1809]ウズラ、C.、 "IPv6ではフローラベルフィールドを使用して"、RFC 1809、1995年6月。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 1883、1995年12月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]黒、D.、つば、S.、大工、B.、およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
[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月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724]ケンプ、J.、エド、Austeinと、R.、エド、およびIAB、「中東の台頭とエンドツーエンドの未来：インターネットアーキテクチャの進化に反省」。。、RFC 3724 、2004年3月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011.
[RFC6089] Tsirtsis、G.、ソリマン、H.、Montavont、N.、Giaretta、G.、およびK. Kuladinithi、 "モバイルIPv6やネットワークモビリティにおけるフローバインディング（NEMO）基本サポート"、RFC 6089、2011年1月。
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
[RPL]冬、T.、エド。、Thubert、P.、エド。、ブラント、A.、Clausenの、T.、ホイ、J.、ケルシー、R.、リーバイス、P.、ピスター教授、K.、Struik 、R.、およびJ. Vasseur、「RPL：低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル」、進歩、2011年3月に作業。
[RPL-07] Winter, T., Ed. and P. Thubert, Ed., "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2010.
[RPL-07]冬、T.、エド。 。とP. Thubert、エド、「RPL：低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル」、進歩、2010年3月での作業。
[Roberts05] Roberts, L. and J. Harford, "In-Band QoS Signaling for IPv6", Work in Progress, July 2005.
"インバンドIPv6のQoSシグナリング" [Roberts05]ロバーツ、L.及びJ.ハーフォード、進歩、2005年7月ワーク。
[Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments in System Design", ACM TOCS 2 (4) 277-288, 1984.
【Saltzer84] Saltzer、J.、リード、D.、およびD.クラーク、 "システム設計におけるエンド・ツー・エンドの引数"、ACM TOCS 2（4）、277-288、1984。
Authors' Addresses
著者のアドレス
Qinwen Hu Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
オークランドPB 92019オークランド1142ニュージーランドのコンピュータサイエンス大学のQinwen胡教室
EMail: qhu009@aucklanduni.ac.nz
メールアドレス：qhu009@aucklanduni.ac.nz
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