    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)

    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.

    Copyright Notice

       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.

    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

    Venaas, et al.              Standards Track                     [Page 1]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

    1.  Introduction

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

    2.  Terminology

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

    3.  Information Refresh Time Option Definition

       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

    Venaas, et al.              Standards Track                     [Page 2]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

       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.

    3.1.  Constants

       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.

    3.2.  Client Behaviour

       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.

    Venaas, et al.              Standards Track                     [Page 3]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

       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.

    3.3.  Server Behaviour

       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.

    Venaas, et al.              Standards Track                     [Page 4]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

    3.4.  Option Format

       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

    4.  IANA Considerations

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

    5.  Acknowledgements

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

    6.  Security Considerations

       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.

    Venaas, et al.              Standards Track                     [Page 5]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

    7.  References

    7.1.  Normative References

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

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

    Venaas, et al.              Standards Track                     [Page 6]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

    Authors' Addresses

       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

    Venaas, et al.              Standards Track                     [Page 7]

    RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

    Full Copyright Statement

       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.

    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.

       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.

    Acknowledgement

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

    Venaas, et al.              Standards Track                     [Page 8]