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]