Internet Engineering Task Force                                S. Venaas
Internet Draft                                                   UNINETT
Expiration Date: January March 2005
                                                                T. Chown
                                               University of Southampton

                                                               July

                                                                 B. Volz
                                                     Cisco Systems, Inc.

                                                          September 2004

                       Lifetime

               Information Refresh Time Option for DHCPv6

                     draft-ietf-dhc-lifetime-01.txt

                     draft-ietf-dhc-lifetime-02.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes an a DHCPv6 option for specifying a lifetime for other
   DHCPv6 configuration options.  It's mainly intended an upper bound
   for the stateless
   DHCPv6, but how long a client should wait before refreshing information
   retrieved from DHCPv6.  It is also useful when used with stateless DHCPv6 as there are
   no addresses or other entities with lifetimes that can tell the
   client when to contact the
   DHCP DHCPv6 server to update refresh its
   configuration.

Table of Contents

   1.  Introduction  ...............................................   2
   2.  Terminology  ................................................   3
   3.  Lifetime  Information refresh time option definition  .................................  .................   3
     3.1.  Constants  ..............................................   4
     3.2.  Client behaviour  .......................................   3
     3.2.   4
     3.3.  Server behaviour  .......................................   4
     3.3.   5
     3.4.  Option format  ..........................................   4   5
   4.  IANA Considerations  ........................................   4   6
   5.  Acknowledgements  ...........................................   4   6
   6.  Security Considerations  ....................................   5   6
   7.  References  .................................................   5   6
     7.1.  Normative References  ...................................   5   6
     7.2.  Informative References  .................................   5   6
   Authors' Addresses  .............................................   5   7
   Intellectual Property and Copyright Statements  .................   6   7

1. Introduction

   DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6
   hosts.  However, many hosts will use stateless autoconfiguration as
   specified in [RFC 2462] for address assignment, and use DHCPv6 only
   for other configuration data. data, see [RFC 3736].  This other
   configuration data will typically have no associated lifetime, hence
   there may be no information telling a host when to update refresh its DHCP DHCPv6
   configuration data.

   This  Therefore, an option may 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 unstable many situations:

       - Unstable environments where unexpected changes are likely to occur, or for
         occur.

       - For planned changes, including
   renumbering where an renumbering.  An administrator
         can gradually decrease the value time as the event nears.

   It may also be useful to allow

       - Limit the client to detect within an
   appropriate amount of time when a specific service change has been made, e.g. before new services or servers are
         available to the client, such as the addition of a new NTP server,
         server or a change of address of a DNS
   server within the local network. server.  See [RENUMREQS] for further
   details.
         [RENUMREQS].

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 [RFC
   2119].

3. Lifetime Information refresh time option definition

   The lifetime information refresh time option specifies a lifetime an upper bound for all configuration data
   contained 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 in an advertise or reply message that have
   no associated lifetime.  This means that it does not effect e.g. indicate when the
   IA Address option which contains a lifetime.

3.1. Client behaviour

   A client supporting this option MAY include should contact the
   server, e.g. addresses with lifetimes.

   Note that it in is only an upper bound.  If the Option Request
   Option (ORO) when sending messages client has any reason to
   make a DHCPv6 request before the DHCP server that allows ORO refresh time expires, it should
   attempt to be included. refresh all the data.

   A client MUST ignore this option if may contact the lifetime is set to zero.

   If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its
   expiration, before the refresh time expires.
   Reasons it SHOULD 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 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 update 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 covered by this option.  If no while attempting to refresh it.  The client is however
   free to fall back to other mechanisms 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 (i.e., does not contain a Status
   Code option), it should install that new lifetime configuration information
   after removing any previously received configuration information.  It
   should also remove information that is received, 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 include this option in the Option Request Option (ORO)
   when sending Information-Request messages to the DHCPv6 server.  A
   client MUST NOT include 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 no the option with value
   IRT_DEFAULT was ever 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 [RFC 3315], 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 lifetime refresh time has expired, it SHOULD
   try to update its configuration data by making a new DHCP request sending an Information-
   Request as
   follows.

   Before making specified in section 18.1.5 of [RFC 3315], except that the request it
   client MUST wait for delay sending the first Information-Request by a random
   amount of time between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].

   Then it can make the DHCP request to update the configuration.  The
   message MUST be created and transmitted according to [RFC 3315].
   E.g. for an Information-request message it must be done according to
   the rules for creation and transmission of Information-request
   messages in section 18.1.5 of [RFC 3315].

3.2.

3.3. Server behaviour

   A server sending an Advertise or a Reply to an Information-Request message containing options, SHOULD
   include this option if requested by client, or if none of the
   options contained it is included in the message have associated lifetimes. ORO of the Information-
   Request.

   The option MAY also be used in other cases when server sends Advertise or
   Reply messages.  It value MUST not NOT be used when smaller than IRT_MINIMUM.  The server sends other types of
   messages.
   SHOULD give a warning if it is configured with a smaller value.

   The lifetime option MUST be non-zero.

3.3. only appear in the options area of Reply messages.

3.4. Option format

   The format of the Lifetime 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_LIFETIME          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           lifetime                    information-refresh-time                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code: OPTION_LIFETIME

     option-code
          OPTION_INFORMATION_REFRESH_TIME (to be decided)

      option-len:

     option-len
          4

      lifetime:    lifetime

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

4. IANA Considerations

   IANA is requested to assign an option code to for the lifetime information
   refresh time option from the DHCP DHCPv6 option-code space defined in section "IANA
   Considerations" of RFC 3315. [RFC 3315].

5. Acknowledgements

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

6. Security Considerations

   Section 23 of [RFC 3315] outlines the DHCPv6 security considerations.
   This option does not change these in any significant way.  An
   attacker may be able to could send a fake DHCP reply faked Reply messages with a very low
   lifetime value.  This could make information
   refresh time value, which would trigger use of IRT_MINIMUM to
   minimize this threat, or with a large or infinite value which would
   be no worse than a client request new data almost
   immediately.  The client will however quickly back off. that does not make use of this option.

7. References

7.1. Normative References

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

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

   [RFC 3315]  R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins,
               M. Carney, "Dynamic Host Configuration Protocol for IPv6
               (DHCPv6)", RFC 3315, July 2003.

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

7.2. Informative References

   [RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering
               Requirements for Stateless DHCPv6", work-in-progress,
               draft-ietf-dhc-stateless-dhcpv6-renumbering-00,
               draft-ietf-dhc-stateless-dhcpv6-renumbering-01,
               March 2004.

Authors' Addresses

   Stig Venaas
   UNINETT
   NO-7465 Trondheim, Trondheim
   Norway
   Email:
   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

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgement

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