[要約] RFC 6294は、IPv6フローラベルの提案された使用事例に関する調査であり、その目的はIPv6フローラベルの有用性と適用範囲を評価することです。
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
IPv6フローラベルの提案されたユースケースの調査
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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パケットヘッダーのビット12〜31を占めています。パケットをマークし、フローを識別し、対応するフロー状態を検索する潜在的な方法を提供します。このフィールドは常に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].
フローラベルの当初の提案は、デイブクラーク[ディアリング93]に起因しており、彼はそれに擬似ランダム価値を含めるべきだと提案しました。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は、代わりに、Simple Internet Protocol Plus（SIPP）[RFC1710]として知られる提案をIPバージョン6に開発することを決定しました。SIPPには、SIPPには「特定のトラフィック「フロー」に属するパケットのラベル付け」に含まれています。 - デフォルトサービスの品質または「リアルタイム」サービス」[RFC1710]。1994年、これは28ビットフローラベルフィールドを使用しました。1995年には、24ビット[RFC1883]に減少し、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]はそれを「実験的および変化の対象」と定義しました。[Metzler00]、[conta01a]、[conta01b]、[hagino01]など、かなりの予備作業がありました。その後の提案された標準「IPv6フローラベル仕様」（RFC 3697）[RFC3697]は、フローラベルを使用するための正確な境界条件を提供することにより、この状況を明確にすることを目的としています。ただし、これは実際にフローラベルの使用を促進することに成功していないことを証明していません。その結果、すべてのIPv6パケットヘッダーで20ビットが使用されていません。
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.
高速スイッチ設計の開発とMPLの成功により、高速スイッチングのフローラベルの考慮事項が大部分を占めています。したがって、フローラベルのさまざまなユースケースが提案されていますが、それらのほとんどは、主にサービス品質（QoS）の提供をサポートするために使用する必要があると想定しています。長年にわたり、リアルタイムのインターネットトラフィックには一般的なデータトラフィックとは異なるQOが必要であり、これはネットワーク中立性の時代に当てはまることが認識されてきました。したがって、均一なベストエフォートサービスに代わるものが必要であり、特定のクラスのサービスまたはフローに属するものとしてパケットを分類する必要があります。現在、これはレイヤー違反の問題につながります。これは、各パケットを分類するために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.
o 3タプル{ソースアドレス、宛先アドレス、フローラベル}は、どのパケットがどの特定のフローに属しているかを一意に識別します。
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.
これらのルールの2番目の効果は、セクション1で述べたレイヤー違反の問題を回避することです。3タプルを使用することにより、IPレイヤーを使用して、輸送層の情報を必要とせずにパケットを分類します。これにより、フローベースの治療が必要な場合はルックアップ時間が短縮され、IPSECの暗号化と断片化があっても機能します。したがって、リアルタイムアプリケーションなどのベストエフォルトサービス以外のトラフィックが必要な場合、フローラベルは異なるフローを表すために異なる値に設定できます。フローラベル値で。これは、差別化されたサービス（diffserv）[carpenter02] [rfc2474]よりも細かく密集していますが、効率が低下する必要はありません。
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.
これら2つの禁止の組み合わせから簡単な脱出はないことに注意してください。これは依存関係を禁止すると呼びます。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.
o 古いフローラベルの削除：フローが終了したとき、ルーターはフローラベルの有効期限が切れていることをどのように知っていますか？これは、タイムアウト、輸送層の観察、または明示的なシグナル伝達に基づいている必要がありますか？[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;
2. フローラベルフィールドに埋め込まれたパラメーターとして特定のQoS要件を定義します。
3. using the flow label to control packet switching;
3. フローラベルを使用してパケットスイッチングを制御します。
4. using the flow label specifically to extend the existing differentiated services QoS architecture;
4. フローラベルを使用して、既存の差別化されたサービスQoSアーキテクチャを拡張するために特別に使用します。
5. other uses.
5. その他の用途。
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.
o ラベルフラグ（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有効LT 00フローラベルソース01フローラベルデータ配信のために宛先10フローラベルが返されるフローラベル
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]です。これは、Path Off Path Spoofing Attackが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パラメーターを詳細に示すためにフローラベルを利用することを提案しています。次の表に要約されているように、さまざまなアプローチをサポートするために、フローラベルフィールドの最初の数ビットをコードとして使用します。繰り返しますが、これは[RFC3697]の依存関係禁止と互換性がありません。この方法を使用しないソースは、最初の2ビットを非ゼロに設定する可能性があるためです。
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]は5つの部分でフローラベルフィールドを定義し、最初の3ビットはアプローチタイプとして使用されます。著者は、「ランダム」スキームと「ハイブリッド」スキームの2つのアプローチを定義します。最初の3ビットが「001」に等しい場合、フローラベルはフローのランダム識別子として使用されますが、「101」に等しい場合、残りのビットにはこのパケットのハイブリッドQOS要件が含まれ、トラフィックタイプに細分化されます（厳しいまたはベストエフォルト）、帯域幅、バッファ、および遅延要件。繰り返しになりますが、[RFC3697]の依存性禁止が壊れています。この提案には、スループットの監視と動的容量の割り当ても含まれます。事実上、この提案はフローラベルを使用して、IntServのような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ルーターの間にのみ意味があることを考慮してMPLに似ており、各ホップでフローラベルを設定します。元のソースがゼロ以外のフローラベルを設定している場合、配信前にそれを復元するメカニズムはありません。[RFC3697]の基本的な違反です。[chakravorty08b]の著者は、ある段階でこの問題を修正するために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つの部分に分割します。最初の3ビットはFECを識別します。これにより、ルーターまたは6LSAノードが同じ転送処理を受けるIPパケットをグループ化し、同じ仮想パスで転送するのに役立ちます。次の4ビットはアプリケーションタイプを説明し、最後の13ビット（各ノードまたはノードのグループで定義）がホップ固有のラベルを指定します。以下の表から、FECには6つの主要なカテゴリがあり、それぞれが最大16のサブカテゴリを備えていることがわかります。
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].
著者らは、128ビットIPv6アドレスの代わりに20ビットラベルを使用した高速スイッチングは、メモリと処理の節約、およびネットワーク管理の利点を提供すると主張しています。「また、ネットワーク全体で利用可能なラベルテーブルを更新するネットワーク管理エンティティが、中間の攻撃を削減する[sic]を削減することもできます」[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によってこれまで割り当てられていないホップバイホップオプションを使用するように設計されていることに注意してください。これに関連する提案は、Telecommunications Industry Associationおよび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]では、同じ著者は、アドレスをフローラベルにハッシュすることにより、IPv6ヘッダーを圧縮する方法としてフローラベルを使用することを提案します。これは、diffservコードポイントを使用してパケットをマークするために再び使用します。
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]として使用できることを指定しています。少なくとも1つの実装がこれをサポートしました[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-in-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.
IETFのワーキンググループのワーキンググループのロール（低電力と損失ネットワークのルーティング）[RPL-07]とMEXT（IPv6のモビリティエクステンション）の両方で、フローラベルの使用の可能性についていくつかの議論がありました。このような用途は、ラベル内の特定のローカル意味またはルーティング関連タグをエンコードする傾向があるため、依存関係の禁止またはフローラベルフィールドの不変性を侵害しているように見えます。ロールグループは、実際には、これらの理由でフローラベルフィールドを使用しないことを選択しました。同様に、MEXTは、IPv6フローラベルフィールドを使用するのではなく、フローバインディング[RFC6089]をサポートする新しいモビリティオプションを定義しています。
Three aspects of the current standard [RFC3697] have caused problems for many designers:
現在の標準[RFC3697]の3つの側面は、多くのデザイナーに問題を引き起こしました。
1. The immutability of labels
1. ラベルの不変性
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]です。さらに、[LIN06]は、フローラベルフィールドに3つのフラグビットを割り当てなかった場合、このリストに参加していました。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つの選択肢があるようです。1つは、リストされている提案のように、既存のルールを額面通りに単純に受け入れることです。これにより、フローラベルの適用が制限されます。たとえば、ノンセとして、または代替パス間で負荷を共有するために使用されるハッシュの材料の一部として使用できます。依存関係の禁止のため、このようなハッシュの唯一の材料ではありません。フローラベルは、アプリケーションデザイナーが複数の輸送セッションで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を直接制御したい設計者にとって、もう1つの選択肢は、ドメインの外側のノードが検出できない方法で、特定のドメイン内のルール（協力ノードのセット）内のルールをバイパスすることです。この場合、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と互換性のないソリューションを提案したデザイナーのかなりの数を考えると、標準ルールを使用した比較的少数のデザイン、およびロールやMEXTなどの設計がフローラベルを使用できないことを故障させると、合理的であるかどうかを尋ねるのは妥当なようです。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.
この文書の貴重なレビューは、ボブ・ブレーデンによって実行されました。有用なコメントは、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] Adams、J.、Joung、J。、およびJ. Song、「フロー状態の覚醒基準の進歩と将来の開発、およびフローに関連するデータに関するノードまたはエンドシステムを警告する提案」、進行中の作業、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.、Carpenter、B。、およびS. Jiang、「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] Banerjee、R.、Malhotra、S。、およびM. M、「ハイブリッドアプローチを使用して効率的なサービス品質を提供するためのIPv6フローラベルを使用するための修正された仕様」、2002年4月、進行中の作業。
[Beckman07a] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, February 2007.
[Beckman07a] Beckman、M。、「IPv6 Dynamic Flow Label Switching（FLS）」、Work in Progress、2007年2月。
[Beckman07b] Beckman, M., "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Work in Progress, November 2006.
[Beckman07b] Beckman、M。、「Mitigation Protocol（IPv6 AMP）のアドレス指定によるIPv6ヘッダー圧縮」、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] Blake、S。、「Path Off-Pathのスポーフ攻撃から防御するための輸送層のNonceとしてのIPv6フローラベルの使用」、2009年10月、進行中の作業。
[Braden10] Braden, R., "Private Communication", 2010.
[Braden10] Braden、R。、「Private Communication」、2010。
[Carpenter02] Carpenter, B. and K. Nichols, "Differentiated Services in the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
[Carpenter02] Carpenter、B。およびK. Nichols、「インターネットでの差別化されたサービス」、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] Carpenter、B。and 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.、Bush、J。、およびJ. Bound、「IPv6ラベルスイッチングアーキテクチャ」、2008年7月の作業。
[Conta01a] Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow Label Specification", Work in Progress, July 2001.
[conta01a] conta、A。and B. carpenter、「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] conta、A。およびJ. rajahalme、「IPv6フローラベル仕様の拡散使用のモデル」、2001年11月、進行中の作業。
[Deering93] Deering, S., "SIPP Overview and Issues", Minutes of the Joint Sessions of the SIP and PIP Working Groups, November 1993.
[Deering93] Deering、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。and K. Erichsen、「フローラベルをデュアルスタックLiteで使用する」、2011年1月の作業。
[Hagino01] Hagino, J., "Socket API for IPv6 flow label field", Work in Progress, April 2001.
[Hagino01] Hagino、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] Lee、I。、およびS. Kim、「IPv6フローラベルを使用したリアルタイムトラフィックのQoS改善スキーム」、コンピューターサイエンスの講義ノートVol。3043、2004。
[Lin06] Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS Provisioning by Flow Label in IPv6", JCIS , 2006.
[Lin06] Lin、C.、Tseng、P。、およびW. Hwang、「IPv6のフローラベルによるエンドツーエンドQoSプロビジョニング」、JCIS、2006。
[Metzler00] Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 flow label", Work in Progress, November 2000.
[Metzler00] Metzler、J。およびS. Hauth、「IPv6フローラベルのエンドツーエンドの使用」、2000年11月、Work in Progress。
[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] Prakash、B。、「IPv6ヘッダーの20ビットフローラベルフィールドを使用して、インターネット上の望ましいサービス品質を示す」、コロラド大学（M.Sc. Thesis）、2004。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, October 1994.
[RFC1707] McGovern、M。およびR. Ullmann、「Catnip：インターネットの共通アーキテクチャ」、RFC 1707、1994年10月。
[RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994.
[RFC1710] Hinden、R。、「Simple Internet Protocol Plus White Paper」、RFC 1710、1994年10月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752] Bradner、S。およびA. Mankin、「IP Next Generation Protocolの推奨」、RFC 1752、1995年1月。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
[RFC1809] Partridge、C。、「IPv6でフローラベルフィールドを使用」、RFC 1809、1995年6月。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883] Deering、S。およびR. Hinden、「Internet Protocol、Version 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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Black、D.、Brim、S.、Carpenter、B。、およびF. Le Faucheur、「Per Hopの動作識別コード」、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.、Conta、A.、Carpenter、B。、およびS. Deering、「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] Kempf、J.、ed。、Austein、R.、ed。、and 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] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「シグナルの次のステップ（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.、Soliman、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] Winter、T.、Ed。、Thubert、P.、Ed。、Brandt、A.、Clausen、T.、Hui、J.、Kelsey、R.、Levis、P.、Pister、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] Winter、T.、ed。and P. Thubert、ed。、「RPL：IPv6 Routing Protocol for Now Power and Losy Networks」、2010年3月、進行中の作業。
[Roberts05] Roberts, L. and J. Harford, "In-Band QoS Signaling for IPv6", Work in Progress, July 2005.
[Roberts05] Roberts、L。およびJ. Harford、「IPv6のインバンドQoSシグナリング」、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.、Reed、D。、およびD. Clark、「システム設計におけるエンドツーエンドの議論」、ACM TOCS 2（4）277-288、1984。
Authors' Addresses
著者のアドレス
Qinwen Hu Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Qinwen Huコンピュータサイエンス大学オークランドPB 92019オークランド1142ニュージーランド
EMail: 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