RFC 7559 - Packet-Loss Resiliency for Router Solicitations 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7559
タイトル : RFC 7559 - ルーター要請のパケット損失回復力
翻訳編集 : 自動生成

[要約] RFC 7559は、ルーターソリシテーションのパケットロス耐性に関するものであり、IPv6ネットワークでのネットワークディスカバリーの信頼性を向上させることを目的としています。

Internet Engineering Task Force (IETF)                       S. Krishnan
Request for Comments: 7559                                      Ericsson
Updates: 4861                                                  D. Anipko
Category: Standards Track                                   Unaffiliated
ISSN: 2070-1721                                                D. Thaler
                                                               Microsoft
                                                                May 2015

Packet-Loss Resiliency for Router Solicitations

ルーター要請のパケット損失回復力

Abstract

概要

When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.

ホスト上のインターフェースが初期化されると、ホストはルーター要請を送信して、次の非送信請求マルチキャストルーターアドバタイズメントが受信されるまで待機する必要がある時間を最小限に抑えます。特定のシナリオでは、ホストによって送信されたこれらのルーター要請は失われる可能性があります。このドキュメントは、初期のルーター要請の喪失に対処するためのホストのメカニズムを指定します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7559.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7559で入手できます。

著作権表示

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
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  Proposed Algorithm  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Stopping the Retransmissions  . . . . . . . . . . . . . .   3
   3.  Configuring the Use of Retransmissions  . . . . . . . . . . .   4
   4.  Known Limitations . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

As specified in [RFC4861], when an interface on a host is initialized, in order to obtain Router Advertisements quickly, a host transmits up to MAX_RTR_SOLICITATIONS (3) Router Solicitation (RS) messages, each separated by at least RTR_SOLICITATION_INTERVAL (4) seconds. In certain scenarios, these Router Solicitations transmitted by the host might be lost. For example, the host is connected to a bridged residential gateway over Ethernet or Wi-Fi. LAN connectivity is achieved at interface initialization, but the upstream WAN connectivity is not active yet. In this case, the host just gives up after the initial RS retransmits.

[RFC4861]で指定されているように、ホスト上のインターフェイスが初期化されると、ルーターアドバタイズをすばやく取得するために、ホストは最大MAX_RTR_SOLICITATIONS（3）ルーター要請（RS）メッセージを送信し、それぞれが少なくともRTR_SOLICITATION_INTERVAL（4）秒で区切られます。特定のシナリオでは、ホストによって送信されたこれらのルーター要請は失われる可能性があります。たとえば、ホストはイーサネットまたはWi-Fiを介してブリッジ型住宅用ゲートウェイに接続されています。 LAN接続はインターフェイスの初期化時に実現されますが、アップストリームWAN接続はまだアクティブではありません。この場合、ホストは最初のRSが再送信した直後に諦めます。

Once the initial RSs are lost, the host gives up and assumes that there are no routers on the link as specified in Section 6.3.7 of [RFC4861]. The host will not have any form of Internet connectivity until the next unsolicited multicast Router Advertisement is received. These Router Advertisements are transmitted at most MaxRtrAdvInterval seconds apart (maximum value 1800 seconds). Thus, in the worst-case scenario a host would be without any connectivity for 30 minutes. This delay may be unacceptable in some scenarios.

最初のRSが失われると、ホストはあきらめ、[RFC4861]のセクション6.3.7で指定されているリンク上にルーターがないと想定します。ホストは、次の非送信請求マルチキャストルーターアドバタイズが受信されるまで、インターネット接続の形式を持ちません。これらのルーターアドバタイズメントは、最大MaxRtrAdvInterval秒間隔で送信されます（最大値は1800秒）。したがって、最悪のシナリオでは、ホストは30分間接続されません。この遅延は、状況によっては許容できない場合があります。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. Proposed Algorithm

2. 提案されたアルゴリズム

To achieve resiliency to packet loss, the host needs to continue retransmitting the Router Solicitations until it receives a Router Advertisement, or until it is willing to accept that no router exists. If the host continues retransmitting the RSs at RTR_SOLICITATION_INTERVAL second intervals, it may cause excessive network traffic if a large number of such hosts exists. To achieve resiliency while keeping the aggregate network traffic low, the host can use some form of exponential backoff algorithm to retransmit the RSs.

パケット損失に対する回復力を実現するには、ホストは、ルーター通知を受信するまで、またはルーターが存在しないことを受け入れる意思があるまで、ルーター要請を再送信し続ける必要があります。ホストがRSをRTR_SOLICITATION_INTERVAL秒間隔で再送信し続ける場合、そのようなホストが多数存在すると、過度のネットワークトラフィックが発生する可能性があります。集約ネットワークトラフィックを低く保ちながら回復力を実現するために、ホストは、何らかの形式の指数バックオフアルゴリズムを使用してRSを再送信できます。

Hosts complying to this specification MUST use the exponential backoff algorithm for retransmits that is described in Section 14 of [RFC3315] in order to continuously retransmit the Router Solicitations until a Router Advertisement is received. The hosts SHOULD use the following variables as input to the retransmission algorithm:

この仕様に準拠するホストは、[RFC3315]のセクション14で説明されている再送に指数バックオフアルゴリズムを使用して、ルーターアドバタイズメントが受信されるまでルーター要請を継続的に再送信する必要があります。ホストは、再送信アルゴリズムへの入力として次の変数を使用する必要があります（SHOULD）。

IRT (Initial Retransmission Time): 4 seconds MRT (Maximum Retransmission Time): 3600 seconds MRC (Maximum Retransmission Count): 0 MRD (Maximum Retransmission Duration): 0

IRT（初期再送時間）：4秒MRT（最大再送時間）：3600秒MRC（最大再送回数）：0 MRD（最大再送時間）：0

The initial value IRT was chosen to be in line with the current retransmission interval (RTR_SOLICITATION_INTERVAL) that is specified by [RFC4861], and the maximum retransmission time MRT was chosen to be in line with the new value of SOL_MAX_RT as specified by [RFC7083]. This is to ensure that the short-term behavior of the RSs is similar to what is experienced in current networks, and that longer-term persistent retransmission behavior trends towards being similar to that of DHCPv6 [RFC3315] [RFC7083].

初期値IRTは、[RFC4861]で指定されている現在の再送信間隔（RTR_SOLICITATION_INTERVAL）と一致するように選択され、最大再送信時間MRTは、[RFC7083]で指定されているSOL_MAX_RTの新しい値と一致するように選択されました。これは、RSの短期的な動作が現在のネットワークで経験される動作と同様であり、長期的な永続的な再送信動作がDHCPv6 [RFC3315] [RFC7083]の動作と同様であることを保証するためです。

2.1. Stopping the Retransmissions

2.1. 再送信の停止

On multicast-capable links, the hosts following this specification SHOULD stop retransmitting the RSs when Router Discovery is successful (i.e., an RA with a non-zero Router Lifetime that results in a default route is received). If an RA is received from a router and it does not result in a default route (i.e., Router Lifetime is zero), the host MUST continue retransmitting the RSs.

マルチキャスト対応リンクでは、この仕様に従うホストは、ルーター発見が成功した場合（つまり、ルーターのライフタイムがゼロ以外であり、デフォルトのルートになるRAが受信された場合）、RSの再送信を停止する必要があります（SHOULD）。 RAがルーターから受信され、デフォルトルートにならない場合（つまり、ルーターのライフタイムがゼロ）、ホストはRSの再送信を継続する必要があります。

On non-multicast links, the hosts following this specification MUST continue retransmitting the RSs even after an RA that results in a default route is received. This is required because, in such links, sending an RA can only be triggered by an RS. Please note that such links have special mechanisms for sending RSs as well. For example, the mechanism specified in Section 8.3.4 of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] unicasts the RSs to specific routers.

非マルチキャストリンクでは、この仕様に従うホストは、デフォルトルートとなるRAを受信した後でも、RSの再送信を継続する必要があります。このようなリンクでは、RAの送信はRSによってのみトリガーできるため、これが必要です。このようなリンクには、RSを送信するための特別なメカニズムもあることに注意してください。たとえば、サイト内自動トンネルアドレスプロトコル（ISATAP）[RFC5214]のセクション8.3.4で指定されたメカニズムは、RSを特定のルーターにユニキャストします。

3. Configuring the Use of Retransmissions

3. 再送信の使用の構成

Implementations of this specification are encouraged to provide a configuration option to enable or disable potentially infinite RS retransmissions. If a configuration option is provided, it MUST enable RS retransmissions by default. Providing an option to enable/ disable retransmissions on a per-interface basis allows network operators to configure RS behavior in the most applicable way for each connected link.

この仕様の実装では、潜在的に無限のRS再送信を有効または無効にする構成オプションを提供することが推奨されます。構成オプションが提供されている場合、デフォルトでRS再送信を有効にする必要があります。インターフェイスごとに再送信を有効/無効にするオプションを提供することで、ネットワークオペレーターは、接続された各リンクに対して最も適切な方法でRSの動作を構成できます。

4. Known Limitations

4. 既知の制限

When an IPv6-capable host attaches to a network that does not have IPv6 enabled, it transmits 3 (MAX_RTR_SOLICITATIONS) Router Solicitations as specified in [RFC4861]. If it receives no Router Advertisements, it assumes that there are no routers present on the link and it ceases to send further RSs. With the mechanism specified in this document, the host will continue to retransmit RSs indefinitely at the rate of approximately 1 RS per hour. It is unclear how to differentiate between such a network with no IPv6 routers and a link where an IPv6 router is temporarily unreachable but could become reachable in the future.

IPv6対応のホストが、IPv6が有効になっていないネットワークに接続する場合、[RFC4861]で指定されているように3（MAX_RTR_SOLICITATIONS）ルーター要請を送信します。ルーターアドバタイズを受信しない場合、リンク上にルーターが存在しないと見なし、それ以上のRSの送信を中止します。このドキュメントで指定されているメカニズムにより、ホストは1時間あたり約1 RSのレートでRSを無制限に再送信し続けます。 IPv6ルーターのないこのようなネットワークと、IPv6ルーターが一時的に到達不能であるが将来到達可能になる可能性があるリンクとをどのように区別するかは不明です。

5. Security Considerations

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

This document does not present any additional security issues beyond those discussed in [RFC4861] and those RFCs that update [RFC4861].

このドキュメントでは、[RFC4861]で説明されている問題や[RFC4861]を更新するRFC以外のセキュリティ上の問題については説明していません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。

[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, <http://www.rfc-editor.org/info/rfc7083>.

[RFC7083] Droms、R。、「SOL_MAX_RTおよびINF_MAX_RTのデフォルト値への変更」、RFC 7083、DOI 10.17487 / RFC7083、2013年11月、<http://www.rfc-editor.org/info/rfc7083>。

6.2. Informative References

6.2. 参考引用

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.

[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、DOI 10.17487 / RFC5214、2008年3月、<http：//www.rfc -editor.org/info/rfc5214>。

Acknowledgements

謝辞

The authors would like to thank Steve Baillargeon, Erik Kline, Andrew Yourtchenko, Ole Troan, Erik Nordmark, Lorenzo Colitti, Thomas Narten, Ran Atkinson, Allison Mankin, Les Ginsberg, Brian Carpenter, Barry Leiba, Brian Haberman, Spencer Dawkins, Alia Atlas, Stephen Farrell, and Mehmet Ersue for their reviews and suggestions that made this document better.

著者は、スティーブベイルラーゴン、エリッククライン、アンドリューユアチェンコ、オレトローン、エリックノードマーク、ロレンゾコリッティ、トーマスナルテン、ランアトキンソン、アリソンマンキン、レギンズバーグ、ブライアンカーペンター、バリーレイバ、ブライアンハーバーマン、スペンサードーキンス、アリアアトラスに感謝します、Stephen Farrell、およびMehmet Ersueのレビューおよびこのドキュメントを改善するための提案

Authors' Addresses

著者のアドレス

Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada

Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルの町、QCカナダ

   Phone: +1 514 345 7900 x42871
   EMail: suresh.krishnan@ericsson.com

Dmitry Anipko Unaffiliated

ドミトリー・アニプコ

   Phone: +1 425 442 6356
   EMail: dmitry.anipko@gmail.com

Dave Thaler Microsoft One Microsoft Way Redmond, WA United States

デイブターラーマイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州アメリカ合衆国

   EMail: dthaler@microsoft.com