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
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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で概念的送信アルゴリズムを更新します。
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].
この文書の残りの部分では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL"、 "べきではない" "べきである" "ないものと"、 "推奨"、 "MAY"、および「OPTIONAL」は、[RFC2119]に記載されているように解釈されるべきです。
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.
与えられた宛先アドレスのトラフィックは限り宛先アドレスの宛先キャッシュエントリが削除されていないのと同じルータを使用することに注意してください。ハッシュベースの方式では、与えられた宛先アドレスのトラフィックが宛先キャッシュエントリが削除された場合でも、時間をかけて同じルータを使用する限り、同等のルータのリストは同じままとして。
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]で述べたように、ネクストホップの選択が予測可能であるとき、アプリケーションは、それが可能な負荷分散アルゴリズムに対するサービス拒否攻撃を開始すること、すべてが同じをハッシュしますトラフィックを合成し、特定をオーバーロードすることができますルータ。これも、ホストが特定の宛先アドレスに応答させることができ、リモート・アプリケーションによって行うことができます。同じ（単一）のネクストホップは、常にそのような[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.
しかし、悪意のあるローカルアプリケーションは、このような生のソケットなどの機構を使用することにより、自身のトラフィックのためのアルゴリズムをバイパスすることができ、リモート攻撃者は依然として直接ルータが過負荷にすることができます。したがって、本明細書で論じる機構は、インターネットインフラストラクチャのセキュリティ上の有意な増分影響を及ぼしません。
The authors of this document would like to thank Erik Nordmark, Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, and Pekka Savola.
本書の著者はエリックNordmarkと、ブライアンハーバーマン、スティーブデアリング、アロンシルバートン、クリスチャンのHuitema、およびペッカSavolaに感謝したいと思います。
[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.シンプソン、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[ROUTERSEL] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[ROUTERSEL] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。
[MULTIPATH] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[MULTIPATH]ターラー、D.およびC. Hoppsが、 "ユニキャストとマルチキャストの次ホップの選択におけるマルチパスの問題"、RFC 2991、2000年11月。
Authors' Addresses
著者のアドレス
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043
ロバートHindenとノキア313フェアチャイルドドライブマウンテンビュー、CA 94043
Phone: +1 650 625-2004 EMail: bob.hinden@nokia.com
電話：+1 650 625-2004 Eメール：bob.hinden@nokia.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。