[要約] RFC 4242は、IPv6の動的ホスト構成プロトコル（DHCPv6）の情報更新時間オプションに関するものです。このRFCの目的は、DHCPv6クライアントが情報の更新を要求するためのオプションを提供することです。
Network Working Group S. Venaas
Request for Comments: 4242 UNINETT
Category: Standards Track T. Chown
University of Southampton
B. Volz
Cisco Systems, Inc.
November 2005
Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6の動的ホスト構成プロトコルの情報の更新時間オプション（DHCPV6）
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).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.
このドキュメントでは、DHCPV6から取得された情報を更新する前にクライアントが待機する時間の上限を指定するためのIPv6（DHCPV6）オプションの動的ホスト構成プロトコルについて説明します。Stateless DHCPV6で使用されます。これは、DHCPV6サーバーに連絡して構成を更新するタイミングをクライアントに伝えることができるアドレスや他のエンティティが存在しないためです。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Information Refresh Time Option Definition ......................2
3.1. Constants ..................................................3
3.2. Client Behaviour ...........................................3
3.3. Server Behaviour ...........................................4
3.4. Option Format ..............................................5
4. IANA Considerations .............................................5
5. Acknowledgements ................................................5
6. Security Considerations .........................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts. However, many hosts will use stateless autoconfiguration as specified in [RFC2462] for address assignment, and use DHCPv6 only for other configuration data; see [RFC3736]. This other configuration data will typically have no associated lifetime, hence there may be no information telling a host when to refresh its DHCPv6 configuration data. Therefore, an option that can be used from server to client to inform the client when it should refresh the other configuration data is needed.
DHCPV6 [RFC3315]は、IPv6ホストのステートフルなオートコンフィギュレーションを指定します。ただし、多くのホストは、アドレス割り当てに[RFC2462]で指定されているStateless Autoconfigurationを使用し、他の構成データにのみDHCPV6を使用します。[RFC3736]を参照してください。この他の構成データには通常、関連する寿命はありません。したがって、DHCPV6構成データを更新するタイミングをホストに伝える情報がない場合があります。したがって、他の構成データを更新する必要があるときにクライアントに通知するためにサーバーからクライアントに使用できるオプションが必要です。
This option is useful in many situations:
このオプションは、多くの状況で役立ちます。
- Unstable environments where unexpected changes are likely to occur.
- 予期しない変更が発生する可能性が高い不安定な環境。
- For planned changes, including renumbering. An administrator can gradually decrease the time as the event nears.
- 変更を含む計画された変更の場合。管理者は、イベントが近づくにつれて徐々に時間を短縮できます。
- Limit the amount of time before new services or servers are available to the client, such as the addition of a new NTP server or a change of address of a DNS server. See [RFC4076].
- 新しいNTPサーバーの追加やDNSサーバーのアドレスの変更など、クライアントが利用できる新しいサービスまたはサーバーが利用できる前の時間を制限します。[RFC4076]を参照してください。
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 BCP 14, RFC 2119 [RFC2119].
「必須」、「必要」、「必須」、「「しなければ」、「そうしない」、「そうはならない」、「そうはならない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されていると解釈されます。
The information refresh time option specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is only used in Reply messages in response to Information-Request messages. In other messages there will usually be other options that indicate when the client should contact the server, e.g., addresses with lifetimes.
情報更新時間オプションは、DHCPV6から取得された情報を更新する前に、クライアントがどれだけ長く待つべきかについての上限を指定します。情報の要求メッセージに応じて、返信メッセージでのみ使用されます。他のメッセージでは、通常、クライアントがサーバーに連絡する必要があることを示す他のオプションがあります。たとえば、寿命のあるアドレス。
Note that it is only an upper bound. If the client has any reason to make a DHCPv6 request before the refresh time expires, it should attempt to refresh all the data.
上限のみであることに注意してください。クライアントが更新時間の有効期限が切れる前にDHCPV6要求を行う理由がある場合、すべてのデータを更新しようとする必要があります。
A client may contact the server before the refresh time expires. Reasons it may do this include the need for additional configuration parameters (such as by an application), a new IPv6 prefix announced by a router, or that it has an indication that it may have moved to a new link.
クライアントは、更新時間が期限切れになる前にサーバーに連絡する場合があります。これを行う理由には、追加の構成パラメーター（アプリケーションによる）の必要性、ルーターによって発表された新しいIPv6プレフィックス、または新しいリンクに移動した可能性があることを示していることが含まれます。
The refresh time option specifies a common refresh time for all the data. It doesn't make sense to have different refresh time values for different data, since when the client has reason to refresh some of its data, it should also refresh the remaining data. Because of this, the option must only appear in the options area of the Reply message.
更新時間オプションは、すべてのデータの共通の更新時間を指定します。異なるデータの異なる更新時間値を持つことは意味がありません。クライアントがそのデータの一部を更新する理由がある場合、残りのデータを更新する必要があるからです。このため、オプションは返信メッセージのオプション領域にのみ表示される必要があります。
The expiry of the refresh time in itself does not in any way mean that the client should remove the data. The client should keep its current data while attempting to refresh it. However, the client is free to fall back to mechanisms other than DHCPv6 if it cannot refresh the data within a reasonable amount of time.
更新時間自体の有効期限は、クライアントがデータを削除することを意味しません。クライアントは、更新しようとしている間、現在のデータを保持する必要があります。ただし、クライアントは、妥当な時間以内にデータを更新できない場合、DHCPV6以外のメカニズムに自由に戻ることができます。
When a client receives a Reply to an Information-Request that contains configuration information, it should install that new configuration information after removing any previously received configuration information. It should also remove information that is missing from the new information set, e.g., an option might be left out or contain only a subset of what it did previously.
クライアントが構成情報を含む情報要求への返信を受信したら、以前に受信した構成情報を削除した後、その新しい構成情報をインストールする必要があります。また、新しい情報セットから欠落している情報を削除する必要があります。たとえば、オプションが除外されるか、以前に行ったことのサブセットのみを含む場合があります。
We define two constants for use by the protocol. How they are used is specified in the sections below.
プロトコルで使用する2つの定数を定義します。それらの使用方法は、以下のセクションで指定されています。
IRT_DEFAULT 86400 In some cases the client uses a default refresh time IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation SHOULD allow for this value to be configurable.
IRT_DEFAULT 86400場合によっては、クライアントがデフォルトの更新時間IRT_DEFAULTを使用します。IRT_DEFAULTの推奨値は86400（24時間）です。クライアントの実装により、この値が設定可能になるようにする必要があります。
IRT_MINIMUM 600 This defines a minimum value for the refresh time.
IRT_MINIMUM 600これは、更新時間の最小値を定義します。
A client MUST request this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages.
クライアントは、dhcpv6サーバーに情報要求メッセージを送信する際に、オプションリクエストオプション（oro）でこのオプションを要求する必要があります。クライアントは、他のメッセージでOROでこのオプションを要求してはなりません。
If the Reply to an Information-Request message does not contain this option, the client MUST behave as if the option with value IRT_DEFAULT was provided.
情報requestメッセージへの返信にこのオプションが含まれていない場合、クライアントはValue IRT_DEFAULTのオプションが提供されたかのように動作する必要があります。
A client MUST use the refresh time IRT_MINIMUM if it receives the option with a value less than IRT_MINIMUM.
クライアントは、IRT_MINIMUMより少ない値でオプションを受信した場合、更新時間IRT_MINIMUMを使用する必要があります。
As per section 5.6 of [RFC3315], the value 0xffffffff is taken to mean "infinity" and implies that the client should not refresh its configuration data without some other trigger (such as detecting movement to a new link).
[RFC3315]のセクション5.6によると、値0xFFFFFFFFは「無限」を意味すると見なされ、クライアントが他のトリガー（新しいリンクへの移動を検出するなど）なしで構成データを更新してはならないことを意味します。
If a client contacts the server to obtain new data or refresh some existing data before the refresh time expires, then it SHOULD also refresh all data covered by this option.
クライアントがサーバーに連絡して新しいデータを取得するか、更新時間が期限切れになる前に既存のデータを更新する場合、このオプションでカバーされているすべてのデータを更新する必要があります。
When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information-Request as specified in section 18.1.5 of [RFC3315], except that the client MUST delay sending the first Information-Request by a random amount of time between 0 and INF_MAX_DELAY.
クライアントが更新時間の有効期限が切れていることを検出すると、[RFC3315]のセクション18.1.5で指定された情報要求を送信して、クライアントが0からINF_MAX_DELAYの間のランダムな時間の送信を遅らせる必要があります。
A client MAY have a maximum value for the refresh time, where that value is used whenever the client receives this option with a value higher than the maximum. This also means that the maximum value is used when the received value is "infinity". A maximum value might make the client less vulnerable to attacks based on forged DHCP messages. Without a maximum value, a client may be made to use wrong information for a possibly infinite period of time. There may however be reasons for having a very long refresh time, so it may be useful for this maximum value to be configurable.
クライアントは、クライアントが最大値よりも高い値でこのオプションを受信するたびにその値が使用される更新時間の最大値を持つ場合があります。これは、受信した値が「無限」である場合に最大値が使用されることも意味します。最大値は、偽造されたDHCPメッセージに基づいて、クライアントの攻撃に対する脆弱性を低下させる可能性があります。最大値がなければ、クライアントは間違った情報を使用して、おそらく無限の期間にわたって使用される場合があります。ただし、非常に長い更新時間を持つ理由があるかもしれないので、この最大値が構成可能であることが役立つかもしれません。
A server sending a Reply to an Information-Request message SHOULD include this option if it is requested in the ORO of the Information-Request.
情報リケストメッセージへの返信を送信するサーバーには、情報リケストのOROで要求されている場合は、このオプションを含める必要があります。
The option value MUST NOT be smaller than IRT_MINIMUM. The server SHOULD give a warning if it is configured with a smaller value.
オプション値は、IRT_MINIMUMよりも小さくてはなりません。サーバーは、値が小さい場合に構成されている場合は警告を発する必要があります。
The option MUST only appear in the options area of Reply messages.
オプションは、返信メッセージのオプション領域にのみ表示する必要があります。
The format of the information refresh time option is:
情報更新時間の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INFORMATION_REFRESH_TIME (32)
Option-Code option_information_refresh_time（32）
option-len 4
オプションレン4
information-refresh-time Time duration relative to the current time, expressed in units of seconds
秒単位で表現されている現在の時間と比較して、情報 - 復帰時間の期間
The IANA has assigned an option code for the information refresh time option from the DHCPv6 option-code space [RFC3315].
IANAは、DHCPV6オプションコードスペース[RFC3315]から情報更新時間オプションのオプションコードを割り当てました。
The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten, Joe Quanaim, and A.K. Vijayabhaskar for valuable discussions and comments.
著者は、マット・フォード、タトゥヤ・ジンメイ、テッド・レモン、トーマス・ナルテン、ジョー・クアナイム、A.K。貴重な議論とコメントについては、Vijayabhaskar。
Section 23 of [RFC3315] outlines the DHCPv6 security considerations. This option does not change these in any significant way. An attacker could send faked Reply messages with a low information refresh time value, which would trigger use of IRT_MINIMUM to minimize this threat. Another attack might be to send a very large value, to make the client use forged information for a long period of time. A possible maximum limit at the client is suggested, which would reduce this problem.
[RFC3315]のセクション23は、DHCPV6セキュリティに関する考慮事項の概要を示しています。このオプションは、これらを重要な方法で変更しません。攻撃者は、情報の更新時間値が低いという偽の返信メッセージを送信することができます。これにより、IRT_MINIMUMの使用がトリガーされ、この脅威が最小限に抑えられます。別の攻撃は、非常に大きな価値を送信し、クライアントに長期間鍛造情報を使用させることです。クライアントの最大制限の可能性が示唆されており、この問題を軽減します。
[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月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4076] Chown、T.、Venaas、S。、およびA. Vijayabhaskar、「IPv6（DHCPV6）のステートレス動的ホスト構成プロトコルの要件の変更要件」、RFC 4076、2005年5月。
Authors' Addresses
著者のアドレス
Stig Venaas UNINETT Trondheim NO 7465 Norway
Stig Venaas Uninett Trondheim No 7465ノルウェー
EMail: venaas@uninett.no
Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom
サウサンプトン大学エレクトロニクスおよびコンピューターサイエンス大学サウサンプトン大学サウサンプトン、ハンプシャーSO17 1BJイギリス
EMail: tjc@ecs.soton.ac.uk
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Bernard Volz Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA
EMail: volz@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。