RFC 7772 - Reducing Energy Consumption of Router Advertisements 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7772
タイトル : RFC 7772 - ルータアドバタイズメントのエネルギー消費の削減
翻訳編集 : 自動生成

[要約] RFC 7772は、ルータ広告のエネルギー消費を削減するためのガイドラインです。その目的は、ネットワークデバイスのエネルギー効率を向上させ、持続可能なネットワーキングを促進することです。

Internet Engineering Task Force (IETF)                    A. Yourtchenko
Request for Comments: 7772                                         Cisco
BCP: 202                                                      L. Colitti
Category: Best Current Practice                                   Google
ISSN: 2070-1721                                            February 2016

Reducing Energy Consumption of Router Advertisements

ルータアドバタイズメントのエネルギー消費の削減

Abstract

概要

Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.

頻繁なルーターアドバタイズメッセージは、ホストの電力消費に深刻な影響を与える可能性があります。このドキュメントでは、このような影響を回避するための運用方法を推奨しています。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

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 BCPs is available in Section 2 of RFC 5741.

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

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

著作権表示

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.  Problem Scenarios . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Solicited Multicast RAs on Large Networks . . . . . . . .   2
     2.2.  Frequent Periodic Router Advertisements . . . . . . . . .   3
   3.  Consequences  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Router Advertisement Frequency  . . . . . . . . . . . . . . .   3
   5.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Network-Side Recommendations  . . . . . . . . . . . . . .   4
     5.2.  Device-Side Recommendations . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

Routing information is communicated to IPv6 hosts by Router Advertisement (RA) messages [RFC4861]. If these messages are sent too frequently, they can severely impact power consumption on battery-powered hosts.

ルーティング情報は、ルーターアドバタイズ（RA）メッセージ[RFC4861]によってIPv6ホストに伝達されます。これらのメッセージが頻繁に送信されると、バッテリー駆動のホストの電力消費に深刻な影響を与える可能性があります。

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. Problem Scenarios

2. 問題のシナリオ

2.1. Solicited Multicast RAs on Large Networks

2.1. 大規模ネットワーク上の要請されたマルチキャストRA

On links with a large number of battery-powered devices, sending solicited multicast Router Advertisements can severely impact host power consumption. This is because every time a device joins the network, all devices on the network receive a multicast Router Advertisement. In the worst case, if devices are continually joining and leaving the network, and the network is large enough, then all devices on the network will receive solicited Router Advertisements at the maximum rate specified by Section 6.2.6 of [RFC4861], which is one every 3 seconds.

バッテリ駆動のデバイスが多数あるリンクでは、送信請求マルチキャストルーターアドバタイズを送信すると、ホストの電力消費に深刻な影響を与える可能性があります。これは、デバイスがネットワークに参加するたびに、ネットワーク上のすべてのデバイスがマルチキャストルーターアドバタイズを受信するためです。最悪の場合、デバイスが継続的にネットワークに参加し、ネットワークから離脱し、ネットワークが十分に大きい場合、ネットワーク上のすべてのデバイスは、[RFC4861]のセクション6.2.6で指定された最大レートで要請ルーター広告を受信します。 3秒ごとに1つ。

2.2. Frequent Periodic Router Advertisements

2.2. 頻繁な定期的なルーターアドバタイズメント

Some networks send periodic multicast Router Advertisements very frequently (e.g., once every few seconds). This may be due to a desire to minimize customer impact of network renumbering events, which in some large residential networks occur relatively frequently. In the presence of hosts that ignore RAs or even all IPv6 packets when in sleep mode, such networks may see a need to send RAs frequently in order to avoid leaving devices with non-functional IPv6 configurations for extended periods of time. Unfortunately, this has severe impact on battery life.

一部のネットワークは、定期的なマルチキャストルーターアドバタイズメントを非常に頻繁に（たとえば、数秒ごとに）送信します。これは、一部の大規模な住宅用ネットワークで比較的頻繁に発生する、ネットワークの再番号付けイベントによる顧客への影響を最小限に抑えたいという要望が原因である可能性があります。スリープモードのときにRAまたはすべてのIPv6パケットを無視するホストが存在する場合、そのようなネットワークでは、長期間にわたって機能しないIPv6構成のデバイスが残されないようにするために、RAを頻繁に送信する必要がある場合があります。残念ながら、これはバッテリー寿命に深刻な影響を与えます。

3. Consequences

3. 結果

Observed effects of frequently sending Router Advertisement messages to battery-powered devices include:

ルーターアドバタイズメッセージをバッテリ駆動のデバイスに頻繁に送信すると、次のような影響が見られます。

o Some hosts simply experience bad battery life on these networks and otherwise operate normally. This is frustrating for users of these networks.

o 一部のホストは、これらのネットワークでバッテリの寿命が短くなるだけで、正常に動作します。これは、これらのネットワークのユーザーにとって苛立たしいものです。

o Some hosts react by dropping all Router Advertisement messages when in power-saving mode on any network, e.g., <https://code.google.com/p/android/issues/detail?id=32662>. This causes devices to lose connectivity when in power-saving mode, potentially disrupting background network communications, because the device is no longer able to send packets or acknowledge received traffic.

o 一部のホストは、ネットワーク（例：<https://code.google.com/p/android/issues/detail?id=32662>）で省電力モードのときに、すべてのルーターアドバタイズメッセージをドロップして反応します。これにより、デバイスはパケットを送信したり、受信したトラフィックを確認したりできなくなるため、省電力モードのときにデバイスの接続が失われ、バックグラウンドのネットワーク通信が中断される可能性があります。

o Some hosts react by dropping *all* IPv6 packets when in power-saving mode, <http://www.gossamer-threads.com/lists/nsp/ ipv6/54641>. This disrupts network communications.

o 一部のホストは、省電力モードのときに、すべてのIPv6パケットをドロップして反応します<http://www.gossamer-threads.com/lists/nsp/ ipv6 / 54641>。これにより、ネットワーク通信が中断されます。

Compounding the problem, when dealing with devices that drop Router Advertisements when in power saving mode, some network administrators work around the problem by sending RAs even more frequently. This causes devices to engage in even more aggressive filtering.

問題をさらに複雑にするのは、省電力モードのときにルーターアドバタイズをドロップするデバイスを扱う場合、一部のネットワーク管理者はRAをさらに頻繁に送信することで問題を回避します。これにより、デバイスはさらに強力なフィルタリングを実行します。

4. Router Advertisement Frequency

4. ルーター通知頻度

The appropriate frequency of periodic RAs depends on how constrained the network devices are.

定期的なRAの適切な頻度は、ネットワークデバイスがどの程度制約されているかによって異なります。

o Laptop-class devices will likely experience no noticeable battery-life impact, even if RAs are sent every few seconds.

o ラップトップクラスのデバイスでは、RAが数秒ごとに送信されても、バッテリー寿命に大きな影響はありません。

o Tablets, phones, and watches experience it more noticeably. At the time of writing, current-generation devices might consume on the order of 5 mA when the main processor is asleep. Upon receiving a packet, they might consume on the order of 200 mA for 250 ms, as the packet causes the main processor to wake up, process the RA, attend to other pending tasks, and then go back to sleep. Thus, on such devices, the cost of receiving one RA will be approximately 0.014 mAh.

o タブレット、携帯電話、および時計は、それをより顕著に体験します。執筆の時点では、現在の世代のデバイスは、メインプロセッサがスリープしているときに5 mA程度消費する可能性があります。パケットを受信すると、パケットがメインプロセッサをウェイクアップし、RAを処理し、他の保留中のタスクに参加し、その後スリープ状態に戻るため、200 msのオーダーで250ミリ秒消費する可能性があります。したがって、そのようなデバイスでは、1つのRAを受信するコストは約0.014 mAhになります。

In order to limit the amount of power used to receive Router Advertisements to, say, 2% of idle power (i.e., to impact idle battery life by no more than 2%), the average power budget for receiving RAs must be no more than 0.1 mA, or approximately 7 RAs per hour. Due to background multicast loss and the tendency of current devices to rate-limit multicast when asleep, many of these RAs might not reach the device. Thus, the minimum lifetimes for RA configuration parameters such as default router lifetime might reasonably be 5-10 times the RA period, or roughly 45-90 minutes.

ルータアドバタイズを受信するために使用される電力量を、たとえばアイドル電力の2％に制限する（つまり、アイドルバッテリの寿命に2％以下の影響を与える）ために、RAを受信するための平均電力バジェットは、 0.1 mA、または1時間あたり約7 RA。バックグラウンドでのマルチキャスト損失と、現在のデバイスがスリープ時にマルチキャストをレート制限する傾向があるため、これらのRAの多くはデバイスに到達しない可能性があります。したがって、デフォルトのルータライフタイムなどのRA設定パラメータの最小ライフタイムは、合理的にはRA期間の5〜10倍、つまり約45〜90分です。

An impact of 2% relative to measured idle current is negligible, since on this sort of device average power consumption is typically much higher than idle power consumption.

この種のデバイスの平均電力消費量は通常、アイドル電力消費量よりもはるかに高いため、測定されたアイドル電流に対して2％の影響は無視できます。

o Specialized devices in non-general-purpose networks such as sensor networks might have tighter requirements. In these environments, even longer RA intervals might be appropriate.

o センサーネットワークなどの非汎用ネットワークの専用デバイスには、より厳しい要件がある場合があります。これらの環境では、さらに長いRA間隔が適切な場合があります。

5. Recommendations

5. 推奨事項

5.1. Network-Side Recommendations

5.1. ネットワーク側の推奨事項

1. Router manufacturers SHOULD allow network administrators to configure the routers to respond to Router Solicitations with unicast Router Advertisements if:

1. ルーターメーカーは、ネットワーク管理者がユニキャストルーターアドバタイズでルーター要請に応答するようにルーターを構成できるようにする必要があります（SHOULD）。

* The Router Solicitation's source address is not the unspecified address, and:

* ルーター要請の送信元アドレスは不特定のアドレスではなく、次のとおりです。

* The solicitation contains a valid Source Link-Layer Address option.

* 要請には、有効な送信元リンク層アドレスオプションが含まれています。

2. Administrators of networks that serve large numbers (tens or hundreds) of battery-powered devices SHOULD enable this behavior.

2. 多数（数十または数百）のバッテリ駆動デバイスを提供するネットワークの管理者は、この動作を有効にする必要があります（SHOULD）。

3. Networks that serve battery-powered devices SHOULD NOT send multicast RAs too frequently (see Section 4) unless the information in the RA packet has substantially changed. If there is a desire to ensure that hosts pick up configuration changes quickly, those networks MAY send frequent Router Advertisements for a limited period of time (e.g., not more than one minute) immediately after a configuration change.

3.バッテリ駆動のデバイスを提供するネットワークは、RAパケットの情報が大幅に変更されない限り、マルチキャストRAを頻繁に送信しないでください（セクション4を参照）。ホストが構成の変更を迅速に取得できるようにしたい場合、これらのネットワークは構成変更の直後に限られた期間（たとえば、1分以内）に頻繁にルーター通知を送信できます（MAY）。

No protocol changes are required. Responding to Router Solicitations with unicast Router Advertisements is already allowed by Section 6.2.6 of [RFC4861], and Router Advertisement intervals are already configurable by the administrator to a wide range of values.

プロトコルの変更は必要ありません。 [RFC4861]のセクション6.2.6により、ユニキャストルーターアドバタイズメントによるルーター要請への応答は既に許可されており、ルーターアドバタイズメントの間隔は、管理者が幅広い値に設定できます。

5.2. Device-Side Recommendations

5.2. デバイス側の推奨事項

1. Maintaining IPv6 connectivity requires that hosts be able to receive periodic multicast RAs [RFC4861]. Therefore, hosts that process unicast packets sent while they are asleep MUST also process multicast RAs sent while they are asleep. Battery-powered hosts MAY rate-limit identical RAs if they are sent too frequently.

1. IPv6接続を維持するには、ホストが定期的なマルチキャストRA [RFC4861]を受信できる必要があります。したがって、スリープ中に送信されたユニキャストパケットを処理するホストは、スリープ中に送信されたマルチキャストRAも処理する必要があります。バッテリ駆動のホストは、送信頻度が高すぎる場合、同一のRAをレート制限する場合があります。

2. Battery-powered devices that do not intend to maintain IPv6 connectivity while asleep SHOULD either disconnect from the network, abandoning all IPv6 configuration on that network, or perform Detecting Network Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up.

2. スリープ中にIPv6接続を維持するつもりのないバッテリ駆動のデバイスは、ネットワークから切断し、そのネットワーク上のすべてのIPv6構成を放棄するか、ウェイクアップ時にIPv6（DNAv6）手順[RFC6059]でネットワーク接続の検出を実行する必要があります。

6. Security Considerations

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

Misconfigured or malicious hosts sending rogue Router Advertisements [RFC6104] can also severely impact power consumption on battery-powered hosts if they send a significant number of such messages. Any IPv6 network where there is potential for misconfigured or malicious hosts should take appropriate countermeasures to mitigate the problem.

不正なルーターアドバタイズメント[RFC6104]を送信する設定ミスや悪意のあるホストは、このようなメッセージを大量に送信すると、バッテリー駆動のホストの電力消費に深刻な影響を与える可能性があります。誤って構成されたホストまたは悪意のあるホストの可能性があるIPv6ネットワークは、問題を軽減するために適切な対策を講じる必要があります。

7. References

7. 参考文献

7.1. Normative References

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

[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>。

[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.

[RFC6059] Krishnan、S。およびG. Daley、「IPv6でネットワーク接続を検出するための簡単な手順」、RFC 6059、DOI 10.17487 / RFC6059、2010年11月、<http://www.rfc-editor.org/info/rfc6059 >。

7.2. Informative References

7.2. 参考引用

[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, DOI 10.17487/RFC6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.

[RFC6104] Chown、T。およびS. Venaas、「Rogue IPv6 Router Advertisement Problem Statement」、RFC 6104、DOI 10.17487 / RFC6104、2011年2月、<http://www.rfc-editor.org/info/rfc6104>。

Acknowledgements

謝辞

The authors wish to thank Steven Barth, Frank Bulk, David Farmer, Igor Gashinsky, Ray Hunter, Erik Kline, Erik Nordmark, Alexandru Petrescu, Libor Polcak, Mark Smith, Jinmei Tatuya, and James Woodyatt for feedback and helpful suggestions.

著者は、フィードバックと有益な提案をしてくれたSteven Barth、Frank Bulk、David Farmer、Igor Gashinsky、Ray Hunter、Erik Kline、Erik Nordmark、Alexandru Petrescu、Libor Polcak、Mark Smith、Jinmei Tatuya、James Woodyattに感謝します。

Authors' Addresses

著者のアドレス

Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem, 1831 Belgium

Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem、1831ベルギー

   Phone: +32 2 704 5494
   Email: ayourtch@cisco.com

Lorenzo Colitti Google Roppongi 6-10-1 Minato, Tokyo 106-6126 Japan

ぉれんぞこぃっちごおｇぇろっぽんぎ６ー１０ー１みなと、ときょ１０６ー６１２６じゃぱん

   Email: lorenzo@google.com