[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-venaas-dhc-lifetime) 00 01 02 03 RFC 4242

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

                                                               July 2004


                       Lifetime Option for DHCPv6

                     draft-ietf-dhc-lifetime-01.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 option for specifying a lifetime for other
   DHCPv6 configuration options.  It's mainly intended for the stateless
   DHCPv6, but is also useful when there are no addresses or other
   entities with lifetimes that can tell the client when to contact the
   DHCP server to update its configuration.




Venaas & Chown           [Expires January 2005]                 [Page 1]

Internet Draft       draft-ietf-dhc-lifetime-01.txt            July 2004


Table of Contents

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




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.  This other configuration data will
   typically have no associated lifetime, hence there may be no
   information telling a host when to update its DHCP configuration
   data.

   This option may be useful in unstable environments where unexpected
   changes are likely to occur, or for planned changes, including
   renumbering where an administrator can gradually decrease the value
   as the event nears.

   It may also be useful to allow the client to detect within an
   appropriate time when a specific service change has been made, e.g.
   the addition of a new NTP server, or a change of address of a DNS
   server within the local network.  See [RENUMREQS] for further
   details.











Venaas & Chown           [Expires January 2005]                 [Page 2]

Internet Draft       draft-ietf-dhc-lifetime-01.txt            July 2004


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 option definition

   The lifetime option specifies a lifetime for all configuration data
   contained in other options in an advertise or reply message that have
   no associated lifetime.  This means that it does not effect e.g. the
   IA Address option which contains a lifetime.


3.1. Client behaviour

   A client supporting this option MAY include it in the Option Request
   Option (ORO) when sending messages to the DHCP server that allows ORO
   to be included.

   A client MUST ignore this option if 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, it SHOULD also update data covered by this option.  If no
   new lifetime is received, it MUST behave as if no value was ever
   provided.

   When the client detects that the lifetime has expired, it SHOULD try
   to update its configuration data by making a new DHCP request as
   follows.

   Before making the request it MUST wait for 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].









Venaas & Chown           [Expires January 2005]                 [Page 3]

Internet Draft       draft-ietf-dhc-lifetime-01.txt            July 2004


3.2. Server behaviour

   A server sending an Advertise or Reply message containing options,
   SHOULD include this option if requested by client, or if none of the
   options contained in the message have associated lifetimes.  The
   option MAY also be used in other cases when server sends Advertise or
   Reply messages.  It MUST not be used when server sends other types of
   messages.  The lifetime MUST be non-zero.


3.3. Option format

   The format of the Lifetime 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-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           lifetime                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code: OPTION_LIFETIME (to be decided)

      option-len:  4

      lifetime:    lifetime in seconds


4. IANA Considerations

   IANA is requested to assign an option code to the lifetime option
   from the DHCP option-code space defined in section "IANA
   Considerations" of RFC 3315.


5. Acknowledgements

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











Venaas & Chown           [Expires January 2005]                 [Page 4]

Internet Draft       draft-ietf-dhc-lifetime-01.txt            July 2004


6. Security Considerations

   An attacker may be able to send a fake DHCP reply with a very low
   lifetime value.  This could make a client request new data almost
   immediately.  The client will however quickly back off.


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.

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,
               March 2004.

Authors' Addresses

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










Venaas & Chown           [Expires January 2005]                 [Page 5]

Internet Draft       draft-ietf-dhc-lifetime-01.txt            July 2004


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.





Venaas & Chown           [Expires January 2005]                 [Page 6]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/