Internet Engineering Task Force S. Venaas Internet Draft UNINETT Expiration Date: September 2004 T. Chown University of Southampton March 2004 Lifetime Option for DHCPv6 draft-ietf-dhc-lifetime-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. Abstract This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but 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 September 2004] [Page 1] Internet Draft draft-ietf-dhc-lifetime-00.txt March 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. Acknowledgments ............................................ 4 6. Security Considerations .................................... 5 7. References ................................................. 5 7.1. Normative References ................................... 5 7.2. Informative References ................................. 5 Authors' Addresses ............................................. 5 1. Introduction DHCPv6 [RFC 3315] has been defined for IPv6 hosts wishing to use stateful autoconfiguration. 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 September 2004] [Page 2] Internet Draft draft-ietf-dhc-lifetime-00.txt March 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. 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 must do as follows. First it MUST ignore or remove the existing lifetime value. If it does not receive a new value in a later request, it MUST behave as if no value was ever provided. Next it MUST wait for a random amount of time between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. Finally it must make a new DHCP request, updating the current configuration. This request will usually be an Information-request Message. If client fails to receive a valid response from a server, it MUST retransmit the message according to the retransmission rules specified in [RFC 3315]. If the update fails, the current configuration must be kept as if no lifetime was ever provided. Venaas & Chown [Expires September 2004] [Page 3] Internet Draft draft-ietf-dhc-lifetime-00.txt March 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. 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. Acknowledgments The authors thank Mat Ford, A.K. Vijayabhaskar and Bernie Volz for valuable discussions and comments. Venaas & Chown [Expires September 2004] [Page 4] Internet Draft draft-ietf-dhc-lifetime-00.txt March 2004 6. Security Considerations An attacker could send a fake DHCP reply with a very low lifetime value. This could make a client request new data almost immediately. The value is however not kept when the next request is made. 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-chown-dhc-stateless-dhcpv6-renumbering-00, November 2003. 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 September 2004] [Page 5]