DHCPv6に対する情報リフレッシュ時間オプション

広告

広告

原文

最終更新
2006-11-15T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/rfc4242.html#source

DHCPv6に対する情報リフレッシュ時間オプション(和訳)

最終更新
2006-11-15T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/rfc4242.html#translation

当文書の位置付け

   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.

当文書はインターネットコミュニティに役立つであろうインターネット標準プロトコルを提供するものであり、改良のための議論や提案を求めるものである。当プロトコル標準化の状況と現状については"Internet Official Protocol Standards"(STD1)の最新版を参照のこと。尚、当文書の配布に制限は設けていない。

   Copyright (C) The Internet Society (2005).

概要

   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で検索された情報を更新する前にクライアントがどれ位の時間待機しなければならないかとの上限を指定するための、DHCPv6オプションについて触れるものである。これは、その設定を更新するためにDHCPv6サーバへ接続する際にクライアントが教えることのできる生存時間を持つアドレスや他の要素がないようなDHCPv6に用いられる。

目次

省略。原文を参照。

1. 序論

   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]で定義されたようなステートレスな自動設定を用い、他の設定データのみを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].

このオプションは多くの状況で有用である:

2. 用語

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

当文書内で登場するMUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONALの意味は、BCP 14及びRFC 2119[RFC2119]の通り解釈するものとする。

3. 情報リフレッシュ時間オプション定義

   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から検索された情報を更新する前にクライアントがどれ位の時間待機しなければならないかとの上限を指定するための、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.

クライアントが設定情報を含む情報要求への応答を受け取る際、設定情報を受信したことによってその古い情報を削除する前に新しい設定情報を適用すべきである。また新しい情報の集合から不正な情報を削除すべきである。例えば、オプションは以前の情報のサブ集合のみを含むかもしれない。

3.1. 共通項目

   We define two constants for use by the protocol.  How they are used
   is specified in the sections below.

      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_MINIMUM 600
         This defines a minimum value for the refresh time.

プロトコルによって用いられる2つの定数を定義する。これらがいかに用いられるかは以下の章で定義する。

IRT_DEFAULT 86400
場合によって、クライアントは更新時間の初期値であるIRT_DEFAULTを用いる。IRT_DEFAULTとして推奨される値は86400(24時間)である。クライアントの実装はこの値を設定可能とすべきである(SHOULD)。
IRT_MINIMUM 600
これは更新時間の最小値を定義するものである。

3.2. クライアントの処理

   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にこのオプションを要求しなければならない(MUST)。クライアントは、他のメッセージでOROにこのオプションを要求してはならない(MUST NOT)。

   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.

情報要求メッセージへの応答がこのオプションを含まない場合、クライアントはIRT_DEFAULTがオプションの値として指定されたとして処理をしなければならない(MUST)。

   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を更新時間として用いなければならない(MUST)。

   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.

クライアントが新たなデータを得るかもしくは更新時間の前に既存のデータを更新するためにサーバへ接続する場合、このオプションによってカバーされる全てのデータも更新すべきである(SHOULD)。

   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.

更新時間の終了をクライアントが検知する際、クライアントが0からINF_MAX_DELAYの間の任意の時間によって最初の情報要求を送信することを遅らせなければならない(MUST)場合を除き、[RFC3315]の18.1.5章に定義されるような情報要求を送信することによってその設定データの更新を行うべきである(SHOULD)。

   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.

クライアントが最大値より高い値を持つこのオプションを受信した場合はいつでも、更新時間の最大値を用いるとよい(MAY)。これはまた、受信した値が"無限大"であった場合に最大値が用いられることを意味する。最大値は、偽造されたDHCPメッセージを基にする攻撃に対するセキュリティの上昇をクライアントにもたらすかもしれない。最大値がなければ、クライアントはおそらく永久に誤った情報を用いつづけるだろう。しかし、非常に長い更新時間を持つ理由があるかもしれず、設定可能なこれの最大値は役立つかもしれない。

3.3 サーバの処理

   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が要求されたのであればこのオプションを含むべきである(SHOULD)。

   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よりも小さくてはならない(MUST NOT)。サーバはそれよりも小さい値の設定に際し警告を発すべきである(SHOULD)。

   The option MUST only appear in the options area of Reply messages.

オプションは、応答メッセージのオプションエリアでのみ用いられなければならない(MUST)。

3.4. オプションフォーマット

   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-len
         4

      information-refresh-time
         Time duration relative to the current time, expressed in units
         of seconds

情報リフレッシュ時間オプションのフォーマットは次の通り:(図省略/原文を参照)

option-code
OPTION_INFORMATION_REFRESH_TIME (32)
option-len
4
information-refresh-time
現在時刻からの持続時間を秒単位で表す。

4. IANAによる考察

   The IANA has assigned an option code for the information refresh time
   option from the DHCPv6 option-code space [RFC3315].

IANAは、DHCPv6オプションコード空間[RFC3315]から情報更新時間オプションで用いるオプションコードを割り当てた。

5. 謝辞

   The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten,
   Joe Quanaim, and A.K. Vijayabhaskar for valuable discussions and
   comments.

多大なる議論とコメントを頂いたMat Ford氏、Tatuya Jinmei氏、Ted Lemon氏、Thomas Narten氏、Joe Quanaim氏、A.K. Vijayabhaskar氏に謝辞を述べる。

6. 安全性への配慮

   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を用いることによる、小さい情報更新時間の値を持つ偽の応答メッセージを送信することができた。別の攻撃は、クライアントに長期間偽造された情報を用いさせるために、非常に長い期間を送信するかもしれない。クライアントの取り得る最大値は、この問題を縮小することを示唆する。

7. 参考文献

7.1. 標準リファレンス

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

   [RFC2462]   Thomson, S. and T. Narten, "IPv6 Stateless Address
               Autoconfiguration", RFC 2462, December 1998.

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

   [RFC3736]   Droms, R., "Stateless Dynamic Host Configuration Protocol
               (DHCP) Service for IPv6", RFC 3736, April 2004.

7.2. 参考リファレンス

   [RFC4076]   Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
               Requirements for Stateless Dynamic Host Configuration
               Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.

著者への連絡先

   Stig Venaas
   UNINETT
   Trondheim  NO 7465
   Norway

   EMail: venaas@uninett.no


   Tim Chown
   University of Southampton
   School of Electronics and Computer Science
   Southampton, Hampshire  SO17 1BJ
   United Kingdom

   EMail: tjc@ecs.soton.ac.uk


   Bernard Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   EMail: volz@cisco.com
   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.

当文書は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.

当文書及び文書内の情報は無保証で提供され、寄稿者、寄稿者が代表となる組織、もしあれば寄稿者を後援する組織、インターネット学会及びIETFは、当文書がいかなる権利も侵害していないという保証、商業利用や特定目的に対する適合性への保証、更にはこれらに限らずあらゆる保証について明示的にも暗黙的にも保証をしていない。

知的所有権

   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は当文書で提供する技術の実装や他の技術の使用に対して主張される知的所有権、その他の権利や効力または適用範囲、更にそれらの権利に基づく全てのライセンスが利用可能であるか否かについては一切関与をしない。これらに関して全ての権利が明確となるよう調査が行われているわけではない。文書の権利に関るIETFの手続きについてはBCP78とBCP79で閲覧可能である。

   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開示情報のコピーや利用可能なライセンスの保証、本仕様の実装者やユーザがそれらの一般ライセンスや使用許諾を得るための手順は、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 まで情報をお寄せ頂きたい。

謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC編集者の職務に対する資金供給は、現在インターネット学会から提供されている。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月15日 最終更新:2006年11月27日