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

   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.

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

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

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

   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.

   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.

   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.

   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.

   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.

      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.

   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.

   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.

   A client MUST use the refresh time IRT_MINIMUM if it receives the
   option with a value less than 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).

   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.

   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.

   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.

   The option value MUST NOT be smaller than IRT_MINIMUM.  The server
   SHOULD give a warning if it is configured with a smaller value.

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

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

   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.

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

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

   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.

   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.

   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.

   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.

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