[要約] 要約：RFC 7098は、サーバーファーム内での負荷分散にIPv6フローラベルを使用する方法について説明しています。 目的：このRFCの目的は、IPv6フローラベルを使用してサーバーファーム内の負荷を均等に分散し、ネットワークの効率とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7098 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
W. Tarreau
HAProxy Technologies, Inc.
January 2014
Using the IPv6 Flow Label for Load Balancing in Server Farms
サーバーファームでの負荷分散にIPv6フローラベルを使用する
Abstract
概要
This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.
このドキュメントでは、現在指定されているIPv6フローラベルを使用して、大規模サーバーファームのレイヤー3/4（L3 / 4）の負荷分散と分散を強化する方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7098.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7098で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Flow Label Specification . . . . . . . . . . . . . 2
3. Summary of Server Farm Load-Balancing Techniques . . . . . . 4
4. Applying the Flow Label to Layer 3/4 Load Balancing . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
The IPv6 flow label has been redefined [RFC6437] and is now a recommended IPv6 node requirement [RFC6434]. Its use for load sharing in multipath routing has been specified [RFC6438]. Another scenario in which the flow label could be used is in load distribution for large server farms. Load distribution is a slightly more general term than load balancing, but the latter is more commonly used. In the context of a server farm, both terms refer to mechanisms that distribute the workload of a server farm among different servers in order to optimize performance. Server load balancing commonly applies to HTTP traffic, but most of the techniques described would apply to other upper-layer applications as well. This document starts with brief introductions to the flow label and to server load-balancing techniques, and then describes how the flow label can be used to enhance load balancers operating on IP packets and TCP sessions, commonly known as layer 3/4 load balancers.
IPv6フローラベルは再定義され[RFC6437]、現在は推奨されるIPv6ノード要件[RFC6434]です。マルチパスルーティングでのロードシェアリングへの使用は指定されています[RFC6438]。フローラベルを使用できる別のシナリオは、大規模サーバーファームの負荷分散です。負荷分散は、負荷分散よりも少し一般的な用語ですが、後者がより一般的に使用されます。サーバーファームのコンテキストでは、どちらの用語も、パフォーマンスを最適化するためにサーバーファームのワークロードを複数のサーバーに分散するメカニズムを指します。サーバーの負荷分散は一般にHTTPトラフィックに適用されますが、説明されている手法のほとんどは他の上位層アプリケーションにも適用されます。このドキュメントでは、フローラベルとサーバーロードバランシング手法の概要を紹介し、フローラベルを使用して、一般にレイヤ3/4ロードバランサーと呼ばれるIPパケットとTCPセッションで動作するロードバランサーを強化する方法について説明します。
The motivation for this approach is to improve the performance of most types of layer 3/4 load balancers, especially for traffic including multiple IPv6 extension headers and in particular for fragmented packets. Fragmented packets, often the result of customers reaching the load balancer via a VPN with a limited MTU, are a common performance problem.
このアプローチの動機は、特に複数のIPv6拡張ヘッダーを含むトラフィック、特にフラグメント化されたパケットについて、ほとんどのタイプのレイヤー3/4ロードバランサーのパフォーマンスを向上させることです。断片化されたパケットは、多くの場合、顧客がMTUが制限されたVPNを介してロードバランサーに到達した結果であり、一般的なパフォーマンスの問題です。
The IPv6 flow label [RFC6437] is a 20-bit field included in every IPv6 header [RFC2460]. It is recommended to be supported in all IPv6 nodes by [RFC6434]. There is additional background material in [RFC6436] and [RFC6294]. According to its definition, the flow label should be set to a constant value for a given traffic flow (such as an HTTP connection), and that value will belong to a uniform statistical distribution, making it potentially valuable for load-balancing purposes.
IPv6フローラベル[RFC6437]は、すべてのIPv6ヘッダー[RFC2460]に含まれる20ビットのフィールドです。 [RFC6434]によってすべてのIPv6ノードでサポートされることが推奨されます。 [RFC6436]と[RFC6294]には追加の背景資料があります。その定義によれば、フローラベルは特定のトラフィックフロー（HTTP接続など）に対して一定の値に設定する必要があり、その値は均一な統計分布に属しているため、負荷分散の目的で潜在的に価値があります。
Any device that has access to the IPv6 header has access to the flow label, and it is at a fixed position in every IPv6 packet. In contrast, transport-layer information, such as the port numbers, is not always in a fixed position, since it follows any IPv6 extension headers that may be present. In fact, the logic of finding the transport header is always more complex for IPv6 than for IPv4, due to the absence of an Internet Header Length field in IPv6. Additionally, if packets are fragmented, the flow label will be present in all fragments, but the transport header will only be in one packet. Therefore, within the lifetime of a given transport-layer connection, the flow label can be a more convenient "handle" than the port number for identifying that particular connection.
IPv6ヘッダーにアクセスできるすべてのデバイスはフローラベルにアクセスでき、すべてのIPv6パケットの固定位置にあります。対照的に、ポート番号などのトランスポート層情報は、存在する可能性のあるIPv6拡張ヘッダーの後に続くため、常に固定位置にあるとは限りません。実際、IPv6にはインターネットヘッダーの長さフィールドがないため、トランスポートヘッダーを見つけるロジックは常にIPv4よりもIPv6の方が複雑です。さらに、パケットがフラグメント化されている場合、フローラベルはすべてのフラグメントに存在しますが、トランスポートヘッダーは1つのパケットにのみ存在します。したがって、特定のトランスポート層接続の存続期間内で、フローラベルは、その特定の接続を識別するためのポート番号よりも便利な「ハンドル」になります。
According to RFC 6437, source hosts should set the flow label; however, if they do not (i.e., its value is zero), forwarding nodes (such as the first-hop router) may set it instead. In both cases, the flow label value must be constant for a given transport session, normally identified by the IPv6 and Transport header 5-tuple. By default, the flow label value should be calculated by a stateless algorithm. The resulting value should form part of a statistically uniform distribution, regardless of which node sets it.
RFC 6437によると、送信元ホストはフローラベルを設定する必要があります。ただし、そうでない場合（つまり、その値がゼロの場合）は、転送ノード（ファーストホップルーターなど）が代わりに設定する場合があります。どちらの場合も、フローラベル値は特定のトランスポートセッションで一定である必要があり、通常はIPv6およびトランスポートヘッダー5タプルによって識別されます。デフォルトでは、フローラベル値はステートレスアルゴリズムによって計算されます。結果の値は、どのノードが設定するかに関係なく、統計的に均一な分布の一部を形成する必要があります。
It is recognized that at the time of writing, very few traffic flows include a non-zero flow label value. The mechanism described below is one that can be added to existing load-balancing mechanisms, so that it will become effective as more and more flows contain a non-zero label. Even if the flow label is chosen from an imperfectly uniform distribution, it will nevertheless increase the information entropy of the IPv6 header as a whole. This allows for progressive introduction of load balancing based on the flow label.
執筆時点では、ゼロ以外のフローラベル値を含むトラフィックフローはほとんどないことが認識されています。以下で説明するメカニズムは、既存のロードバランシングメカニズムに追加できるものであり、ゼロ以外のラベルを含むフローが増えるにつれて効果的になります。フローラベルが不完全な均一分布から選択された場合でも、IPv6ヘッダーの情報エントロピーは全体として増加します。これにより、フローラベルに基づいてロードバランシングを段階的に導入できます。
If the recommendations in Section 3 of RFC 6437 are followed for traffic from a given source accessing a well-known TCP port at a given destination, the flow label can act as a substitute for the port numbers as far as a load balancer is concerned, and it can be found at a fixed position in the layer 3 header even if extension headers are present.
RFC 6437のセクション3の推奨事項に従って、特定の送信元からのトラフィックが特定の宛先の既知のTCPポートにアクセスする場合、フローラベルは、ロードバランサーに関する限り、ポート番号の代わりとして機能できます。また、拡張ヘッダーが存在する場合でも、レイヤー3ヘッダーの固定位置にあります。
The flow label is defined as an end-to-end component of the IPv6 header, but there are three qualifications to this:
フローラベルはIPv6ヘッダーのエンドツーエンドコンポーネントとして定義されますが、これには3つの条件があります。
1. Until the IPv6 flow label specification in RFC 6437 is widely implemented as recommended by RFC 6434, the flow label will often be set to the default value of zero.
1. RFC 6437のIPv6フローラベル仕様がRFC 6434の推奨に従って広く実装されるまで、フローラベルは多くの場合、デフォルト値のゼロに設定されます。
2. Because of the recommendation to use a stateless algorithm to calculate the label, there is a low (but non-zero) probability that two simultaneous flows from the same source to the same destination have the same flow label value despite having different transport-protocol port numbers.
2. ステートレスアルゴリズムを使用してラベルを計算することが推奨されているため、トランスポートプロトコルポートが異なっていても、同じ送信元から同じ宛先への2つの同時フローが同じフローラベル値を持つ確率は低い（ただしゼロではない）番号。
3. The Flow Label field is in an unprotected part of the IPv6 header, which means that intentional or unintentional changes to its value cannot be easily detected by a receiver.
3. フローラベルフィールドは、IPv6ヘッダーの保護されていない部分にあります。つまり、その値に対する意図的または意図的でない変更は、受信者によって簡単に検出できません。
The first two points are addressed below in Section 4 and the third in Section 5.
最初の2つのポイントについては、以下のセクション4で説明し、3つ目はセクション5で説明します。
Load balancing for server farms is achieved by a variety of methods, often used in combination [Tarreau]. This section gives a general overview of common methods, although the flow label is not relevant to all of them. The actual load-balancing algorithm (the choice of which server to use for a new client session) is irrelevant to this discussion. We give examples for HTTP, but analogous techniques may be used for other application protocols.
サーバーファームの負荷分散は、さまざまな方法で実現され、しばしば組み合わせて使用されます[Tarreau]。このセクションでは、フローラベルがすべてのメソッドに関連しているわけではありませんが、一般的なメソッドの概要を説明します。実際の負荷分散アルゴリズム（新しいクライアントセッションに使用するサーバーの選択）は、この説明とは関係ありません。 HTTPの例を示しますが、他のアプリケーションプロトコルでも同様の手法を使用できます。
o The simplest method is using the DNS to return different server addresses for a single name such as www.example.com to different users. This is typically done by rotating the order in which different addresses within the server site are listed by the relevant authoritative DNS server, on the assumption that the client will pick the first one. Routing may be configured such that the different addresses are handled by different ingress routers. Several variants of this load-balancing mechanism exist, such as expecting some clients to use all the advertised addresses when multiple connections are involved, or directing the traffic to multiple sites, also known as global load balancing. None of these mechanisms are in the scope of this document, and the proposal in this document does not affect their usability nor aim to replace them, so they will not be discussed further.
o 最も簡単な方法は、DNSを使用して、www.example.comなどの単一の名前の異なるサーバーアドレスを異なるユーザーに返すことです。これは通常、クライアントが最初のアドレスを選択すると仮定して、サーバーサイト内のさまざまなアドレスが関連する権威あるDNSサーバーによってリストされる順序をローテーションすることによって行われます。ルーティングは、異なるアドレスが異なる入力ルーターによって処理されるように構成できます。このロードバランシングメカニズムにはいくつかのバリアントが存在します。たとえば、複数の接続が関係する場合に一部のクライアントがすべてのアドバタイズされたアドレスを使用することを期待したり、グローバルロードバランシングとも呼ばれる複数のサイトにトラフィックを転送したりします。これらのメカニズムはいずれもこのドキュメントの範囲外であり、このドキュメントの提案はそれらのユーザビリティに影響を与えることも、それらを置き換えることも目的としないため、それらについてさらに説明しません。
o Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm. The reverse proxy will present a single IP address to the world, communicated to clients by a single AAAA record. For each new client session (an incoming TCP connection and HTTP request), it will pick a particular server and proxy the session to it. The act of proxying should be more efficient and less resource-intensive than the act of serving the required content. The proxy must retain TCP state and proxy state for the duration of the session. This TCP state could, potentially, include the incoming flow label value.
o HTTPサーバーの別の方法は、サーバーファームの前でレイヤー7リバースプロキシを操作することです。リバースプロキシは、単一のIPアドレスを世界に提示し、単一のAAAAレコードによってクライアントに通知されます。新しいクライアントセッション（着信TCP接続とHTTP要求）ごとに、特定のサーバーを選択し、そのサーバーにセッションをプロキシします。プロキシの行為は、必要なコンテンツを提供する行為よりも効率的で、リソース消費が少ないはずです。プロキシは、セッションの期間中、TCP状態とプロキシ状態を保持する必要があります。このTCP状態には、着信フローラベル値が含まれる可能性があります。
o A component of some load-balancing systems is an SSL reverse proxy farm. The individual SSL proxies handle all cryptographic aspects and exchange unencrypted HTTP with the actual servers. Thus, from the load-balancing point of view, this really looks just like a server farm, except that it's specialized for HTTPS. Each proxy will retain SSL and TCP and maybe HTTP state for the duration of the session, and the TCP state could potentially include the flow label.
o 一部の負荷分散システムのコンポーネントは、SSLリバースプロキシファームです。個々のSSLプロキシはすべての暗号化の側面を処理し、暗号化されていないHTTPを実際のサーバーと交換します。したがって、負荷分散の観点から見ると、これはHTTPSに特化していることを除いて、サーバーファームと同じように見えます。各プロキシは、セッションの期間中、SSLとTCP、および場合によってはHTTP状態を保持し、TCP状態にはフローラベルが含まれる可能性があります。
o Finally the "front end" of many load-balancing systems is a layer 3/4 load balancer. While it can be a dedicated device, it is also a standard function of some network switches or routers (e.g. using Equal-Cost Multipath Routing (ECMP) [RFC2991]). In this case, it is the layer 3/4 load balancer whose IP address is published as the primary AAAA record for the service. All client sessions will pass through this device. Depending on the specific scenario, the balancer will assign new sessions among the actual application servers, across an SSL proxy farm, or among a set of layer 7 proxies. In all cases, the layer 3/4 load balancer has to classify incoming packets very quickly and choose the target server or proxy so as to ensure persistence. 'Persistence' is defined as the guarantee that a given client session will run to completion on a single server. The layer 3/4 load balancer therefore needs to inspect each incoming packet to classify it. There are two common types of layer 3/4 load balancers, the totally stateless ones which only act on single packets, generally involving a per-packet hashing of easy-to-find information such as the source address and/or port into a server number, and the stateful ones that take the routing decision on the very first packets of a session and maintain the same direction for all packets belonging to the same session. Clearly, both types of layer 3/4 balancers could inspect and make use of the flow label value.
o 最後に、多くのロードバランシングシステムの「フロントエンド」は、レイヤー3/4ロードバランサーです。専用デバイスにすることもできますが、一部のネットワークスイッチまたはルーターの標準機能でもあります（たとえば、等コストマルチパスルーティング（ECMP）[RFC2991]を使用）。この場合、IPアドレスがサービスのプライマリAAAAレコードとして公開されるのは、レイヤー3/4ロードバランサーです。すべてのクライアントセッションはこのデバイスを通過します。特定のシナリオに応じて、バランサーは実際のアプリケーションサーバー間、SSLプロキシファーム全体、または一連のレイヤー7プロキシ間で新しいセッションを割り当てます。すべての場合において、レイヤー3/4ロードバランサーは、受信パケットを非常に迅速に分類し、永続性を確保するためにターゲットサーバーまたはプロキシを選択する必要があります。 「持続性」は、特定のクライアントセッションが単一のサーバー上で完了するまで実行されることを保証するものとして定義されます。したがって、レイヤー3/4ロードバランサーは、各着信パケットを検査して分類する必要があります。レイヤー3/4ロードバランサーには2つの一般的なタイプがあり、単一のパケットでのみ動作する完全にステートレスなロードバランサーです。通常、ソースアドレスやサーバーへのポートなどの見つけやすい情報のパケットごとのハッシュが含まれます。番号、およびセッションの最初のパケットでルーティング決定を行い、同じセッションに属するすべてのパケットに対して同じ方向を維持するステートフルなもの。明らかに、両方のタイプのレイヤー3/4バランサーがフローラベル値を検査して利用できます。
Our focus is on how the balancer identifies a particular flow. For clarity, note that two aspects of layer 3/4 load balancers are not affected by use of the flow label to identify sessions:
バランサーが特定のフローを識別する方法に焦点を当てています。明確にするために、レイヤー3/4ロードバランサーの2つの側面は、セッションを識別するフローラベルの使用による影響を受けないことに注意してください。
1. Balancers use various techniques to redirect traffic to a specific target server.
1. バランサーは、さまざまな手法を使用して、トラフィックを特定のターゲットサーバーにリダイレクトします。
+ All servers are configured with the same IP address, they are all on the same LAN, and the load balancer sends directly to their individual MAC addresses. In this case, return packets from the server to the client are sent back without passing through the balancer, a technique known as direct server return, but we are not concerned here with the return packets.
+ すべてのサーバーは同じIPアドレスで構成され、それらはすべて同じLAN上にあり、ロードバランサーは個々のMACアドレスに直接送信します。この場合、サーバーからクライアントへの返信パケットはバランサーを経由せずに送り返されます。これはサーバーの直接返信と呼ばれる手法ですが、ここでは返信パケットについては関係ありません。
+ All servers are configured with the same IP address, treated locally as an anycast address by layer 3 ECMP routing.
+ すべてのサーバーは同じIPアドレスで構成され、レイヤー3 ECMPルーティングによってローカルでエニーキャストアドレスとして扱われます。
+ Each server has its own IP address, and the balancer uses an IP-in-IP tunnel to reach it.
+ 各サーバーには独自のIPアドレスがあり、バランサーはIP-in-IPトンネルを使用してそれに到達します。
+ Each server has its own IP address, and the balancer performs NAPT (Network Address and Port Translation) to deliver the client's packets to that address.
+ 各サーバーには独自のIPアドレスがあり、バランサーはNAPT（ネットワークアドレスとポート変換）を実行して、クライアントのパケットをそのアドレスに配信します。
+ The choice between these methods is not affected by use of the flow label.
+ これらの方法の選択は、フローラベルの使用による影響を受けません。
2. A layer 3/4 balancer must correctly handle Path MTU Discovery by forwarding relevant ICMPv6 packets in both directions. This too is not directly affected by use of the flow label. It should be noted that there may be difficulty correlating an ICMPv6 "Packet too big" response with the session it refers to, but that is out of the scope of the present document.
2. レイヤー3/4バランサーは、関連するICMPv6パケットを両方向に転送することにより、Path MTU Discoveryを正しく処理する必要があります。これもフローラベルの使用による直接的な影響は受けません。 ICMPv6の「パケットが大きすぎます」応答とそれが参照するセッションとの関連付けが困難な場合があることに注意してください。ただし、これは本書の範囲外です。
The following diagram, inspired by [Tarreau], shows a layout with various methods in use together. (Below, "ASIC" stands for "Application-Specific Integrated Circuit".)
次の図は、[Tarreau]に着想を得たもので、さまざまな方法を組み合わせて使用したレイアウトを示しています。 （以下、「ASIC」は「特定用途向け集積回路」の略です。）
___________________________________________
( )
( Clients in the Internet )
(___________________________________________)
| |
------------ DNS-based ------------
| Ingress | load splitting | Ingress |
| router | affects | router |
------------ routing ------------
___|____________________________|___
| |
| |
| |
------------ ------------
| L3/4 ASIC| | L3/4 ASIC|
| balancer | | balancer |
------------ ------------
| load |
| spreading |
__________|________________________|___________
| | | |
------------ ------------ -------- --------
|HTTP proxy|...|HTTP proxy| | SSL |...| SSL |
| balancer | | balancer | | proxy| | proxy|
------------ ------------ -------- --------
____|_____________|_____________|_________|_____
| | | | |
-------- -------- -------- -------- --------
|HTTP | |HTTP | |HTTP | |HTTP | |HTTP |
|server| |server| |server| |server| |server|
-------- -------- -------- -------- --------
From the previous paragraphs, we can identify several points in this diagram where the flow label might be relevant:
前の段落から、フローラベルが関連する可能性があるこの図のいくつかのポイントを特定できます。
1. Layer 3/4 load balancers.
1. レイヤー3/4ロードバランサー。
2. SSL proxies.
2. SSLプロキシ。
3. HTTP proxies.
3. HTTPプロキシ。
However, usage by the proxies seems unlikely to affect performance, because they must in any case process the application-layer header, so in this document we focus only on layer 3/4 balancers.
ただし、プロキシによる使用は、アプリケーション層のヘッダーを処理する必要があるため、パフォーマンスに影響を与える可能性は低いと考えられるため、このドキュメントでは、レイヤー3/4バランサーのみに焦点を当てます。
The suggested model for using the flow label to enhance an layer 3/4 load-balancing mechanism is as follows:
フローラベルを使用してレイヤ3/4ロードバランシングメカニズムを強化するための推奨モデルは次のとおりです。
o We are only concerned with IPv6 traffic in which the flow label value has been set according to [RFC6437]. If the flow label of an incoming packet is zero, load balancers will continue to use the transport header in the traditional way. As the use of the flow label becomes more prevalent according to RFC 6434, load balancers, and therefore users, will reap a growing performance benefit.
o ここでは、[RFC6437]に従ってフローラベル値が設定されているIPv6トラフィックのみを扱います。着信パケットのフローラベルがゼロの場合、ロードバランサーは従来の方法でトランスポートヘッダーを引き続き使用します。フローラベルの使用がRFC 6434に従って普及するにつれて、ロードバランサー、つまりユーザーは、パフォーマンスの向上を享受します。
o If the flow label of an incoming packet is non-zero, layer 3/4 load balancers can use the 2-tuple {source address, flow label} as the session key for whatever load distribution algorithm they support. Alternatively, they might use the 3-tuple {dest address, source address, flow label}, especially if the server farm supports multiple server IP addresses, but using the 3-tuple will be significantly quicker than searching for the transport port numbers later in the packet. Moreover, the transport-layer information such as the source port is not repeated in fragments, which generally prevents stateless load balancers from supporting fragmented traffic since they generally cannot reassemble fragments.
o 着信パケットのフローラベルがゼロ以外の場合、レイヤー3/4ロードバランサーは、サポートする負荷分散アルゴリズムのセッションキーとして2タプル{送信元アドレス、フローラベル}を使用できます。または、サーバーファームが複数のサーバーIPアドレスをサポートしている場合は特に、3つのタプル{宛先アドレス、送信元アドレス、フローラベル}を使用できますが、3つのタプルを使用すると、後でトランスポートポート番号を検索するよりもはるかに高速になります。パケット。さらに、送信元ポートなどのトランスポート層情報はフラグメントで繰り返されないため、通常、ステートレスロードバランサーはフラグメントを再構成できないため、フラグメント化されたトラフィックをサポートできません。
A stateless layer 3/4 load balancer would simply apply a hash algorithm to the 2-tuple or 3-tuple on all packets in order to select the same target server consistently for a given flow. Needless to say, the hash algorithm has to be well chosen for its purpose, but this problem is common to several forms of stateless load balancing. The discussion in [RFC6438] applies.
ステートレスレイヤー3/4ロードバランサーは、特定のフローに対して一貫して同じターゲットサーバーを選択するために、すべてのパケットの2タプルまたは3タプルにハッシュアルゴリズムを適用するだけです。言うまでもなく、ハッシュアルゴリズムはその目的のために適切に選択する必要がありますが、この問題はステートレスロードバランシングのいくつかの形式に共通しています。 [RFC6438]の議論が適用されます。
A stateful layer 3/4 load balancer would apply its usual load distribution algorithm to the first packet of a session, and store the {tuple, server} association in a table so that subsequent packets belonging to the same session are forwarded to the same server. Thus, for all subsequent packets of the session, it can ignore all IPv6 extension headers, which should lead to a performance benefit. Whether this benefit is valuable will depend on engineering details of the specific load balancer.
ステートフルレイヤー3/4ロードバランサーは、通常の負荷分散アルゴリズムをセッションの最初のパケットに適用し、{tuple、server}の関連付けをテーブルに保存して、同じセッションに属する後続のパケットが同じサーバーに転送されるようにします。したがって、セッションの後続のすべてのパケットでは、すべてのIPv6拡張ヘッダーを無視できるため、パフォーマンスが向上します。このメリットが有益かどうかは、特定のロードバランサーのエンジニアリングの詳細に依存します。
Note that such a balancer will not identify new transport sessions from the same source that use the same flow label; they will be delivered to the same server. This is like the behavior of existing hash-based layer 4 balancers that always send similarly hashed packets to the same destination. However, a global state table in a flow label balancer cannot be shared between multiple services if these services rely on transport-layer information, since the goal of using the flow label is to avoid looking up that information.
このようなバランサーは、同じフローラベルを使用する同じソースからの新しいトランスポートセッションを識別しないことに注意してください。それらは同じサーバーに配信されます。これは、同じようにハッシュされたパケットを常に同じ宛先に送信する既存のハッシュベースのレイヤー4バランサーの動作に似ています。ただし、フローラベルを使用する目的はその情報の検索を回避することであるため、フローラベルバランサーのグローバルステートテーブルは、トランスポートレイヤー情報に依存している複数のサービス間で共有できません。
A related issue is that the balancer will not detect FIN/ACK sequences at the end of sessions. Therefore, it will rely on inactivity timers to delete session state. However, all existing balancers must maintain such timers to deal with hung sessions, and the practical impact on memory utilization is unlikely to be significant.
関連する問題は、バランサーがセッションの最後にFIN / ACKシーケンスを検出しないことです。したがって、セッションステートを削除するには、非アクティブタイマーに依存します。ただし、既存のすべてのバランサーは、ハングしたセッションに対処するためにこのようなタイマーを維持する必要があり、メモリー使用率への実際的な影響はそれほど大きくありません。
o Layer 3/4 balancers that redirect the incoming packets by NAPT are not expected to obtain any saving of time by using the flow label, because they have no choice but to follow the extension header chain in order to locate and modify the port number and transport checksum. The same would apply to balancers that perform TCP state tracking for any reason.
o NAPTによって着信パケットをリダイレクトするレイヤー3/4バランサーは、フローラベルを使用して時間を節約することは期待されていません。これは、ポート番号とトランスポートを見つけて変更するために拡張ヘッダーチェーンに従う必要があるためです。チェックサム。同じことが、何らかの理由でTCP状態の追跡を実行するバランサーにも当てはまります。
o Note that correct handling of ICMPv6 for Path MTU Discovery requires the layer 3/4 balancer to keep state for the client source address, independently of either the port numbers or the flow label.
o パスMTUディスカバリーのICMPv6を正しく処理するには、ポート番号やフローラベルに関係なく、レイヤー3/4バランサーがクライアントの送信元アドレスの状態を維持する必要があることに注意してください。
o SSL and HTTP proxies, if present, should forward the flow label value towards the server. This usually has no performance benefit, but it is consistent with the general model for the flow label described in RFC 6437.
o SSLおよびHTTPプロキシが存在する場合は、フローラベル値をサーバーに転送する必要があります。これには通常、パフォーマンス上の利点はありませんが、RFC 6437で説明されているフローラベルの一般的なモデルと一致しています。
It should be noted that the performance benefit, if any, depends entirely on engineering trade-offs in the design of the layer 3/4 balancer. An extra test is needed to check if the label is non-zero, but if there is a non-zero label, all logic for handling extension headers can be skipped except for the first packet of a new flow. Since the identifying state to be stored is only the tuple and the server identifier, storage requirements will be reduced. Additionally, the method will work for fragmented traffic and for flows where the transport information is missing (unknown transport protocol) or obfuscated (e.g., IPsec). Traffic reaching the load balancer via a VPN is particularly prone to the fragmentation issue, due to MTU size issues. For some load-balancer designs, these are very significant advantages.
パフォーマンスのメリットは、もしあれば、レイヤー3/4バランサーの設計におけるエンジニアリングのトレードオフに完全に依存することに注意してください。ラベルがゼロ以外であるかどうかを確認するには、追加のテストが必要ですが、ゼロ以外のラベルがある場合は、新しいフローの最初のパケットを除いて、拡張ヘッダーを処理するためのすべてのロジックをスキップできます。格納される識別状態はタプルとサーバー識別子のみであるため、ストレージ要件が軽減されます。さらに、この方法は、断片化されたトラフィックや、トランスポート情報が欠落している（不明なトランスポートプロトコル）、または難読化されている（IPsecなど）フローに対して機能します。 VPNを介してロードバランサーに到達するトラフィックは、MTUサイズの問題により、特にフラグメンテーションの問題が発生しやすくなります。一部のロードバランサー設計では、これらは非常に重要な利点です。
In the unlikely event of two simultaneous flows from the same source address having the same flow label value, the two flows would end up assigned to the same server, where they would be distinguished as normal by their port numbers. There are approximately one million possible flow label values, and if the rules for flow label generation [RFC6437] are followed, this would be a statistically rare event, and would not damage the overall load-balancing effect. Moreover, with a million possible label values, it is very likely that there will be many more flow label values than servers at most sites, so it is already expected that multiple flow label values will end up on the same server for a given client IP address.
同じフローラベル値を持つ同じ送信元アドレスからの2つの同時フローというまれなイベントでは、2つのフローは同じサーバーに割り当てられ、ポート番号によって通常と区別されます。約100万の可能なフローラベル値があり、フローラベル生成のルール[RFC6437]に従っている場合、これは統計的にまれなイベントであり、全体的な負荷分散効果に影響を与えません。さらに、100万の可能なラベル値を使用すると、ほとんどのサイトのサーバーよりも多くのフローラベル値が存在する可能性が非常に高いため、複数のフローラベル値が特定のクライアントIPの同じサーバーに配置されることがすでに予想されています。住所。
In the case that many thousands of clients are hidden behind the same large-scale NAPT with a single shared IP address, the assumption of low probability of conflicts might become incorrect, unless flow label values are random enough to avoid following similar sequences for all clients. This is not expected to be a factor for IPv6 anyway, since there is no need to implement large-scale NAPT with address sharing [RFC4864]. The probability of conflicts is low for sites that implement network prefix translation [RFC6296], since this technique provides a different address for each client.
何千ものクライアントが単一の共有IPアドレスを持つ同じ大規模なNAPTの背後に隠れている場合、フローラベルの値がすべてのクライアントで同様のシーケンスをたどらないように十分にランダムでない限り、競合の可能性が低いという仮定は正しくない可能性があります。 。いずれにしても、アドレス共有を使用した大規模なNAPT [RFC4864]を実装する必要がないため、これはIPv6の要因とはなりません。この手法はクライアントごとに異なるアドレスを提供するため、ネットワークプレフィックス変換[RFC6296]を実装するサイトでは、競合の可能性は低くなります。
Security aspects of the flow label are discussed in [RFC6437]. As noted there, a malicious source or man-in-the-middle could disturb load balancing by manipulating flow labels. This risk already exists today where the source address and port are used as a hashing key in layer 3/4 load balancers, as well as where a persistence cookie is used in HTTP to designate a server. It even exists on layer 3 components that only rely on the source address to select a destination, making them more DDoS-prone. Nevertheless, all these methods are currently used because the benefits for load balancing and persistence hugely outweigh the risks. The flow label does not significantly alter this situation.
フローラベルのセキュリティの側面については、[RFC6437]で説明されています。そこに記載されているように、悪意のあるソースまたは中間者がフローラベルを操作することにより、ロードバランシングを妨害する可能性があります。このリスクは、ソースアドレスとポートがレイヤー3/4ロードバランサーのハッシュキーとして使用されているほか、HTTPで永続化Cookieがサーバーを指定するために使用されている場所にすでに存在しています。レイヤ3コンポーネント上にも存在し、送信元アドレスにのみ依存して宛先を選択するため、DDoSが発生しやすくなります。それにもかかわらず、ロードバランシングと永続性の利点がリスクをはるかに上回るため、これらすべての方法が現在使用されています。フローラベルはこの状況を大幅に変更しません。
Specifically, the IPv6 flow label specification [RFC6437] states that "stateless classifiers should not use the flow label alone to control load distribution, and stateful classifiers should include explicit methods to detect and ignore suspect flow label values." The former point is answered by also using the source address. The latter point is more complex. If the risk is considered serious, the site ingress router or the layer 3/4 balancer should use a suitable heuristic to verify incoming flows with non-zero flow label values. If a flow from a given source address and port number does not have a constant flow label value, it is suspect and should be dropped. This would deal with both intentional and accidental changes to the flow label.
具体的には、IPv6フローラベル仕様[RFC6437]には、「ステートレス分類子はフローラベルのみを使用して負荷分散を制御するべきではなく、ステートフル分類子は疑わしいフローラベル値を検出して無視する明示的なメソッドを含める必要がある」と記載されています。前者についても発信元アドレスを用いて回答します。後者の点はより複雑です。リスクが深刻であると考えられる場合、サイトの入口ルーターまたはレイヤー3/4バランサーは、適切なヒューリスティックを使用して、ゼロ以外のフローラベル値を持つ着信フローを検証する必要があります。特定の送信元アドレスとポート番号からのフローに一定のフローラベル値がない場合は、疑わしいため、ドロップする必要があります。これは、フローラベルの意図的な変更と偶発的な変更の両方に対応します。
A malicious source or man-in-the-middle could generate a flow in which the flow label is constant but the transport port numbers in some packets are invalid. Such packets, if load-balanced only on the basis of the flow label, could reach the target server and create a single-source DoS attack on its TCP engine.
悪意のあるソースまたは中間者が、フローラベルが一定であるが一部のパケットのトランスポートポート番号が無効であるフローを生成する可能性があります。このようなパケットは、フローラベルに基づいてのみ負荷分散されると、ターゲットサーバーに到達し、TCPエンジンに単一ソースのDoS攻撃を引き起こす可能性があります。
RFC 6437 notes in its Security Considerations that if the covert channel risk is considered significant, a firewall might rewrite non-zero flow labels. As long as this is done as described in RFC 6437, it will not invalidate the mechanisms described above.
RFC 6437のセキュリティに関する考慮事項では、隠れチャネルリスクが重大であると見なされた場合、ファイアウォールがゼロ以外のフローラベルを書き換える可能性があると記載されています。これがRFC 6437の説明に従って行われている限り、上記のメカニズムは無効になりません。
The flow label may be of use in protecting against DDoS attacks against servers. As noted in RFC 6437, a source should generate flow label values that are hard to predict, most likely by including a secret nonce in the hash used to generate each label. The attacker does not know the nonce and therefore has no way to invent flow labels that will all target the same server, even with knowledge of both the hash algorithm and the load-balancing algorithm. Still, it is important to understand that it is always trivial to force a load balancer to stick to the same server during an attack, so the security of the whole solution must not rely on the unpredictability of the flow label values alone, but should include defensive measures like most load balancers already have against abnormal use of source addresses or session cookies.
フローラベルは、サーバーに対するDDoS攻撃からの保護に役立つ場合があります。 RFC 6437に記載されているように、ソースは、各ラベルの生成に使用されるハッシュにシークレットナンスを含めることにより、予測が困難なフローラベル値を生成する必要があります。攻撃者はナンスを知らないため、ハッシュアルゴリズムとロードバランシングアルゴリズムの両方を知っていても、すべて同じサーバーをターゲットとするフローラベルを作成する方法はありません。それでも、攻撃中にロードバランサーを強制的に同じサーバーに固定することは常に簡単であることを理解することが重要です。そのため、ソリューション全体のセキュリティは、フローラベル値のみの予測不能性に依存してはならず、ほとんどのロードバランサーのような防御策は、送信元アドレスまたはセッションCookieの異常な使用に対してすでに持っています。
New flows are assigned to a server according to any of the usual algorithms available on the load balancer (e.g., least connections, round robin, etc.). The association between the 2-tuple {source address, flow label} and the server is stored in a table (often called stick table) so that future traffic from the same source using the same flow label can be sent to the same server. This method is more robust against a loss of server and also makes it harder for an attacker to target a specific server, because the association between a flow label value and a server is not known externally.
新しいフローは、ロードバランサーで使用可能な通常のアルゴリズム（最小接続、ラウンドロビンなど）に従ってサーバーに割り当てられます。 2タプル{送信元アドレス、フローラベル}とサーバー間の関連付けは、同じフローラベルを使用する同じ送信元からの同じトラフィックを同じサーバーに送信できるように、テーブル（多くの場合、スティックテーブル）に格納されます。この方法は、サーバーの損失に対してより堅牢であり、フローラベル値とサーバー間の関連付けが外部で認識されていないため、攻撃者が特定のサーバーを標的にすることを困難にします。
In the case that a stateless hash function is used to assign client packets to specific servers, it may be advisable to use a cryptographic hash function of some kind, to ensure that an attacker cannot predict the behavior of the load balancer.
ステートレスハッシュ関数を使用してクライアントパケットを特定のサーバーに割り当てる場合、攻撃者がロードバランサーの動作を予測できないように、何らかの暗号ハッシュ関数を使用することをお勧めします。
Valuable comments and contributions were made by Fred Baker, Olivier Bonaventure, Ben Campbell, Lorenzo Colitti, Linda Dunbar, Donald Eastlake, Joel Jaeggli, Gurudeep Kamat, Warren Kumari, Julia Renouard, Julius Volz, and others.
貴重なコメントと寄稿は、フレッド・ベイカー、オリビエ・ボナベンチャー、ベン・キャンベル、ロレンゾ・コリッティ、リンダ・ダンバー、ドナルド・イーストレイク、ジョエル・ジャグリ、グルディープ・カマット、ウォーレン・クマリ、ジュリア・レヌアール、ジュリアス・ヴォルツなどによって行われました。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、J。Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、2011年11月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]ターラー、D。およびC.ホップ、「ユニキャストおよびマルチキャストのネクストホップ選択におけるマルチパスの問題」、RFC 2991、2000年11月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, June 2011.
[RFC6294] Hu、Q。、およびB. Carpenter、「IPv6フローラベルの使用例の調査」、RFC 6294、2011年6月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for Update to the IPv6 Flow Label Specification", RFC 6436, November 2011.
[RFC6436]アマンテ、S。、カーペンター、B。、およびS.ジャン、「IPv6フローラベル仕様の更新の根拠」、RFC 6436、2011年11月。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438]カーペンター、B。およびS.アマンテ、「トンネルでの等コストマルチパスルーティングおよびリンク集約のためのIPv6フローラベルの使用」、RFC 6438、2011年11月。
[Tarreau] Tarreau, W., "Making applications scalable with load balancing", 2006, <http://1wt.eu/articles/2006_lb/>.
[タロー]タロー、W。、「負荷分散でアプリケーションをスケーラブルにする」、2006、<http://1wt.eu/articles/2006_lb/>。
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
S横江hu Aはテクノロジー株式会社Q14、hu Aはキャンパスno.156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com
Willy Tarreau HAProxy Technologies, Inc. R&D Network Products 3 rue du petit Robinson 78350 Jouy-en-Josas France
ウィリータローHAProxy Technologies、Inc. R＆D Network Products 3 rue du petit Robinson 78350 Jouy-en-Josas France
EMail: willy@haproxy.com