Internet Engineering Task Force S. Venaas Internet Draft UNINETT Expiration Date:
JanuaryMarch 2005 T. Chown University of Southampton JulyB. Volz Cisco Systems, Inc. September 2004 LifetimeInformation Refresh Time Option for DHCPv6 draft-ietf-dhc-lifetime-01.txtdraft-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 ana DHCPv6 option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intendedan upper bound for the stateless DHCPv6, buthow long a client should wait before refreshing information retrieved from DHCPv6. It is also useful whenused with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPDHCPv6 server to updaterefresh its configuration. Table of Contents 1. Introduction ............................................... 2 2. Terminology ................................................ 3 3. LifetimeInformation 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 .......................................... 45 4. IANA Considerations ........................................ 46 5. Acknowledgements ........................................... 46 6. Security Considerations .................................... 56 7. References ................................................. 56 7.1. Normative References ................................... 56 7.2. Informative References ................................. 56 Authors' Addresses ............................................. 57 Intellectual Property and Copyright Statements ................. 67 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 updaterefresh its DHCPDHCPv6 configuration data. ThisTherefore, an option maythat 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 unstablemany situations: - Unstable environments where unexpected changes are likely to occur, or foroccur. - For planned changes, including renumbering where anrenumbering. An administrator can gradually decrease the valuetime as the event nears. It may also be useful to allow- Limit the client to detect within an appropriateamount 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. LifetimeInformation refresh time option definition The lifetimeinformation refresh time option specifies a lifetimean upper bound for all configuration data containedhow 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 meansthat it does not effect e.g.indicate when the IA Address option which contains a lifetime. 3.1. Client behaviour Aclient supporting this option MAY includeshould contact the server, e.g. addresses with lifetimes. Note that it inis only an upper bound. If the Option Request Option (ORO) when sending messagesclient has any reason to make a DHCPv6 request before the DHCP server that allows OROrefresh time expires, it should attempt to be included.refresh all the data. A client MUST ignore this option ifmay contact the lifetime is set to zero. If client has received a lifetime with this option, and contactsserver to receive new or update any existing data prior to its expiration,before the refresh time expires. Reasons it SHOULDmay 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 updaterefresh 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 nowhile 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 lifetimeconfiguration 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 nothe option with value IRT_DEFAULT was everprovided. 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 lifetimerefresh time has expired, it SHOULD try to update its configuration data by making a new DHCP requestsending an Information- Request as follows. Before makingspecified in section 18.1.5 of [RFC 3315], except that the request itclient MUST wait fordelay 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]. 184.108.40.206. Server behaviour A server sending an Advertise ora Reply to an Information-Request message containing options,SHOULD include this option if requested by client, or if none of the options containedit 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. Itvalue MUST notNOT be used whensmaller than IRT_MINIMUM. The server sends other types of messages.SHOULD give a warning if it is configured with a smaller value. The lifetimeoption MUST be non-zero. 3.3.only appear in the options area of Reply messages. 3.4. Option format The format of the Lifetimeinformation 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_LIFETIMEoption-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetimeinformation-refresh-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_LIFETIMEoption-code OPTION_INFORMATION_REFRESH_TIME (to be decided) option-len:option-len 4 lifetime: lifetimeinformation-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 tofor the lifetimeinformation refresh time option from the DHCPDHCPv6 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 Volzfor 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 tocould send a fake DHCP replyfaked Reply messages with a verylow lifetime value. This could makeinformation 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: firstname.lastname@example.org Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: email@example.com Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA EMail: firstname.lastname@example.org 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- email@example.com. 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.