RFC4311 日本語訳

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

Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4311のノキアアップデート: 2461年のD.ターレルカテゴリ: 標準化過程マイクロソフト2005年11月

                    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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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ルータの中で負荷分割法をしないで、実際には問題が多い場合がある体系を示します。 このドキュメントは、ルータの中で効率的なファッションで異なった目的地へのトラフィックを分配できるようにRFC2461の概念的な送付アルゴリズムをアップデートします。

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).

[ノースダコタ]の概念的な送付アルゴリズムと[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]で説明されるようにまた、ソースアドレスの選択に影響して、したがって、間接的にまた、インバウンドトラフィックに使用されるルータに影響するかもしれません(ある程度)。

Hinden & Thaler             Standards Track                     [Page 1]

RFC 4311            IPv6 Host-to-Router Load Sharing       November 2005

Hindenとターレル規格はIPv6ホストからルータへの負荷分割法2005年11月にRFC4311を追跡します[1ページ]。

   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.

1つ以上の同等なルータがあるとき、ホストが彼らの外向的なトラフィックをこれらのルータに分配するのは、しばしば望ましいです。 これは、複数のルータの中で負荷を共有して、より良い性能をホストのトラフィックに提供します。

   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.

[ノースダコタ]はこの点で少しの特定の振舞いも必要としません。 実装がいつも同じルータ(例えば、リストにおける1番目)を選ぶか、またはルータを通して連続方法で循環するかもしれないのが指定します。 これらの提案の両方が問題が多いです。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?

2.  Load Sharing

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.

aであるときに、ホストは複数の同等なルータから選んで、それはいつも同じルータ(例えば、リストにおける1番目)を選ぶより同等なルータの中でむしろ異なった目的地に負荷を分配する何らかのメソッドを使用するのを選ぶSHOULDサポートです。 このメモは負荷分割法のサポートがデフォルトでつけたり消したりされるべきであるかどうかに関する姿勢を全く取りません。 その上、ルータSHOULDに負荷を分配するのを試みるホストは送付先IPアドレスをアカウントに取る(少なくとも)ハッシュベースの体系、ものが[MULTIPATH]で説明した使用するルータを選ぶためのそのようなものを使用します。

Hinden & Thaler             Standards Track                     [Page 2]

RFC 4311            IPv6 Host-to-Router Load Sharing       November 2005

Hindenとターレル規格はIPv6ホストからルータへの負荷分割法2005年11月にRFC4311を追跡します[2ページ]。

   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.

送付先アドレスのためのDestination Cache Entryが削除されない限り、与えられた送付先アドレスのためのトラフィックが同じルータを使用することに注意してください。 Destination Cache Entryが削除されても、ハッシュベースの体系と共に、与えられた送付先アドレスのためのトラフィックは時間がたつにつれて同じルータを使用するでしょう、同等なルータのリストが同じままで残っている限り。

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]で言及されるように、アプリケーションは同じくらいすべて論じ尽くすトラフィックを統合できます、負荷分割法アルゴリズムに対してサービス不能攻撃に着手して、特定のルータを積みすぎるのを可能にして。 ホストが与えられた送付先アドレスに応じることができるリモートアプリケーションでこれができさえします。 この特別なケースは同じ(単一)の次のホップがいつも選択される時です、[ノースダコタ]によって許容されたアルゴリズムなどのように。 論じ尽くすことを導入するのに、そのような攻撃は、より難しくなる場合があります。 ハッシュが予測できなければ予測できないほど、それは、どんなただ一つのルータに対してサービス不能攻撃を行うために、より困難になります。

   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.

このドキュメントの作者はエリックNordmark、ブライアン・ハーバーマン、スティーブ・デアリング、アロンシルヴァートン、クリスチャンのHuitema、およびペッカSavolaに感謝したがっています。

Hinden & Thaler             Standards Track                     [Page 3]

RFC 4311            IPv6 Host-to-Router Load Sharing       November 2005

Hindenとターレル規格はIPv6ホストからルータへの負荷分割法2005年11月にRFC4311を追跡します[3ページ]。

5.  Normative References

5. 引用規格

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

[ノースダコタ]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[ADDRSEL]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。

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

[ROUTERSEL]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、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.

[多重通路]ターレルとD.とC.ホップス、「多重通路は中でユニキャストとマルチキャスト次のホップ選択を発行する」RFC2991、2000年11月。

Authors' Addresses

作者のアドレス

   Robert Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA  94043

ロバートHindenノキア313フェアチャイルド・Driveマウンテンビュー、カリフォルニア 94043

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

以下に電話をしてください。 +1 650 625-2004 メールしてください: 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 8835年の425 703メール: dthaler@microsoft.com

Hinden & Thaler             Standards Track                     [Page 4]

RFC 4311            IPv6 Host-to-Router Load Sharing       November 2005

Hindenとターレル規格はIPv6ホストからルータへの負荷分割法2005年11月にRFC4311を追跡します[4ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Hinden & Thaler             Standards Track                     [Page 5]

Hindenとターレル標準化過程[5ページ]