RFC 4311 - IPv6 Host-to-Router Load Sharing 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4311
タイトル : RFC 4311 - IPv6ホストからルーターへの負荷共有
翻訳編集 : 自動生成

[要約] RFC 4311は、IPv6ホストとルーター間の負荷分散に関する標準化された手法を提供します。このRFCの目的は、IPv6ネットワークでの負荷分散の効果的な実装を促進することです。

Network Working Group                                          R. Hinden
Request for Comments: 4311                                         Nokia
Updates: 2461                                                  D. Thaler
Category: Standards Track                                      Microsoft
                                                           November 2005

IPv6 Host-to-Router Load Sharing

IPv6ホストからルーターへの負荷共有

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.

元のIPv6概念送信アルゴリズムは、同等のIPv6ルーター間で負荷共有を行わず、実際には問題になる可能性のあるスキームを提案します。このドキュメントは、RFC 2461の概念的な送信アルゴリズムを更新して、さまざまな宛先へのトラフィックを効率的にルーターに配布できるようにします。

1. Introduction

1. はじめに

In the conceptual sending algorithm in [ND] and in the optional extension in [ROUTERSEL], a next hop is chosen when no destination cache entry exists for an off-link destination or when communication through an existing router is failing. Normally, a router is selected the first time traffic is sent to a specific destination IP address. Subsequent traffic to the same destination address continues to use the same router unless there is some reason to change to a different router (e.g., a redirect message is received, or the router is found to be unreachable).

[nd]および[routersel]のオプションの拡張機能の概念的送信アルゴリズムでは、オフリンクの宛先に宛先キャッシュエントリが存在しない場合、または既存のルーターを通じて通信が失敗した場合に次のホップが選択されます。通常、トラフィックが特定の宛先IPアドレスに送信されるときに、ルーターが選択されます。同じ宛先アドレスへの後続のトラフィックは、別のルーターに変更する理由がない限り、同じルーターを使用し続けます（たとえば、リダイレクトメッセージが受信されるか、ルーターが到達できないことがわかります）。

In addition, as described in [ADDRSEL], the choice of next hop may also affect the choice of source address, and hence indirectly (and to a lesser extent) may affect the router used for inbound traffic as well.

さらに、[addrsel]で説明されているように、次のホップの選択もソースアドレスの選択に影響する可能性があるため、インバウンドトラフィックに使用されるルーターにも間接的に（そしてそれほどではないが）影響する可能性があります。

In both the base sending algorithm and in the optional extension, sometimes a host has a choice of multiple equivalent routers for a destination. That is, all other factors are equal and a host must break a tie via some implementation-specific means.

両方のベース送信アルゴリズムとオプションの拡張機能では、ホストが宛先に複数の等価ルーターを選択できる場合があります。つまり、他のすべての要因は等しく、ホストはいくつかの実装固有の手段を介してネクタイを破る必要があります。

It is often desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host's traffic.

多くの場合、これらのルーター間に発信トラフィックを分配するホストをホストする複数の同等のルーターがある場合、それは望ましいことがよくあります。これにより、複数のルーター間で負荷が共有され、ホストのトラフィックによりパフォーマンスが向上します。

On the other hand, load sharing can be undesirable in situations where sufficient capacity is available through a single router and the traffic patterns could be more predictable by using a single router; in particular, this helps to diagnose connectivity problems beyond the first-hop routers.

一方、単一のルーターを介して十分な容量が利用可能であり、単一のルーターを使用することでトラフィックパターンをより予測可能にする可能性のある状況では、負荷共有は望ましくない場合があります。特に、これにより、最初のホップルーターを超えた接続性の問題を診断するのに役立ちます。

[ND] does not require any particular behavior in this respect. It specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic.

[nd]は、この点で特定の動作を必要としません。実装は、常に同じルーター（例：リストの最初のもの）を選択するか、ラウンドロビンの方法でルーターをサイクリングすることができることを指定します。これらの提案は両方とも問題があります。

Clearly, always choosing the same router does not provide load sharing. Some problems with load sharing using naive tie-breaking techniques such as round-robin and random are discussed in [MULTIPATH]. While the destination cache provides some stability since the determination is not per packet, cache evictions or timeouts can still result in unstable or unpredictable paths over time, lowering the performance and making it harder to diagnose problems. Round-robin selection may also result in synchronization issues among hosts, where in the worst case the load is concentrated on one router at a time.

明らかに、常に同じルーターを選択しても、負荷共有は提供されません。ラウンドロビンやランダムなどの素朴なタイブレイクテクニックを使用した負荷共有に関するいくつかの問題については、[MultiPath]で説明しています。宛先キャッシュはパケットごとに決定がないため安定性を提供しますが、キャッシュの立ち退きまたはタイムアウトは、時間の経過とともに不安定なパスまたは予測不可能なパスをもたらし、パフォーマンスを低下させ、問題の診断を難しくする可能性があります。ラウンドロビンの選択は、ホスト間で同期の問題をもたらす可能性があり、最悪の場合、負荷は一度に1つのルーターに集中します。

In the remainder of this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

このドキュメントの残りの部分では、キーワードは「必要はない」、「必須」、「必要」、「しなければ」、「そうしない」、「ははは」、「はない」、「推奨」、「5月」、および「オプション」は、[RFC2119]で説明されているように解釈されます。

2. 負荷共有

When a host chooses from multiple equivalent routers, it SHOULD support choosing using some method that distributes load for different destinations among the equivalent routers rather than always choosing the same router (e.g., the first in the list). This memo takes no stance on whether the support for load sharing should be turned on or off by default. Furthermore, a host that does attempt to distribute load among routers SHOULD use a hash-based scheme that takes (at least) the destination IP address into account, such as those described in [MULTIPATH], for choosing a router to use.

ホストが複数の等価ルーターから選択する場合、常に同じルーターを選択するのではなく、同等のルーター間で異なる宛先の負荷を分配する何らかの方法を使用して選択することをサポートする必要があります（例：リストの最初のもの）。このメモは、デフォルトで負荷共有のサポートをオンまたはオフにするかどうかについての姿勢を取りません。さらに、ルーター間で負荷を分配しようとするホストは、使用するルーターを選択するために[MultiPath]に記載されているような宛先IPアドレスを考慮に入れるハッシュベースのスキームを使用する必要があります。

Note that traffic for a given destination address will use the same router as long as the Destination Cache Entry for the destination address is not deleted. With a hash-based scheme, traffic for a given destination address will use the same router over time even if the Destination Cache Entry is deleted, as long as the list of equivalent routers remains the same.

特定の宛先アドレスのトラフィックは、宛先アドレスの宛先キャッシュエントリが削除されていない限り、同じルーターを使用することに注意してください。ハッシュベースのスキームを使用すると、特定の宛先アドレスのトラフィックは、同等のルーターのリストが同じままである限り、宛先キャッシュエントリが削除されている場合でも、時間の経過とともに同じルーターを使用します。

3. Security Considerations

3. セキュリティに関する考慮事項

As mentioned in [MULTIPATH], when next-hop selection is predictable, an application can synthesize traffic that will all hash the same, making it possible to launch a denial-of-service attack against the load-sharing algorithm, and overload a particular router. This can even be done by a remote application that can cause a host to respond to a given destination address. A special case of this is when the same (single) next-hop is always selected, such as in the algorithm allowed by [ND]. Introducing hashing can make such an attack more difficult; the more unpredictable the hash is, the harder it becomes to conduct a denial-of-service attack against any single router.

[MultiPath]で述べたように、Next-Hopの選択が予測可能な場合、アプリケーションはすべて同じものをハッシュするトラフィックを合成し、負荷共有アルゴリズムに対するサービス拒否攻撃を開始し、特定のものに過負荷にすることができます。ルーター。これは、ホストが特定の宛先アドレスに応答する可能性のあるリモートアプリケーションでも実行できます。これの特別なケースは、[nd]で許可されているアルゴリズムのように、同じ（単一の）ネクストホップが常に選択される場合です。ハッシュを導入すると、このような攻撃がより困難になる可能性があります。ハッシュが予測できないほど、単一のルーターに対するサービス拒否攻撃を実施するのが難しくなります。

However, a malicious local application can bypass the algorithm for its own traffic by using mechanisms such as raw sockets, and remote attackers can still overload the routers directly. Hence, the mechanisms discussed herein have no significant incremental impact on Internet infrastructure security.

ただし、悪意のあるローカルアプリケーションは、生のソケットなどのメカニズムを使用して、独自のトラフィックのアルゴリズムをバイパスできます。また、リモート攻撃者はルーターに直接オーバーロードできます。したがって、ここで説明するメカニズムは、インターネットインフラストラクチャのセキュリティに大きな影響を与えることはありません。

4. Acknowledgements

4. 謝辞

The authors of this document would like to thank Erik Nordmark, Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, and Pekka Savola.

この文書の著者は、Erik Nordmark、Brian Haberman、Steve Deering、Aron Silverton、Christian Huitema、Pekka Savolaに感謝します。

5. Normative References

5. 引用文献

[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

[ND] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[ADDRSEL] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

[Addrsel] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。

[ROUTERSEL] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.

[Routersel] Draves、R。and D. Thaler、「デフォルトのルーターの好みとより固有のルート」、RFC 4191、2005年11月。

6. Informative References

6. 参考引用

[MULTIPATH] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.

[Multipath] Thaler、D。およびC. Hopps、「UnicastおよびMulticast Next-Hop Selectionのマルチパスの問題」、RFC 2991、2000年11月。

Authors' Addresses

著者のアドレス

Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043

ロバートヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043

   Phone: +1 650 625-2004
   EMail: bob.hinden@nokia.com

Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052

Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052

   Phone: +1 425 703 8835
   EMail: dthaler@microsoft.com

Full Copyright Statement

完全な著作権声明

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。