Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 4242
Document | Type |
RFC - Proposed Standard
(November 2005; No errata)
Obsoleted by RFC 8415
|
|
---|---|---|---|
Authors | Stig Venaas , Bernie Volz , Tim Chown | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4242 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | rdroms@cisco.com |
Network Working Group S. Venaas Request for Comments: 4242 UNINETT Category: Standards Track T. Chown University of Southampton B. Volz Cisco Systems, Inc. November 2005 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................2 3. Information Refresh Time Option Definition ......................2 3.1. Constants ..................................................3 3.2. Client Behaviour ...........................................3 3.3. Server Behaviour ...........................................4 3.4. Option Format ..............................................5 4. IANA Considerations .............................................5 5. Acknowledgements ................................................5 6. Security Considerations .........................................5 7. References ......................................................6 7.1. Normative References .......................................6 7.2. Informative References .....................................6 Venaas, et al. Standards Track [Page 1] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 1. Introduction DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts. However, many hosts will use stateless autoconfiguration as specified in [RFC2462] for address assignment, and use DHCPv6 only for other configuration data; see [RFC3736]. This other configuration data will typically have no associated lifetime, hence there may be no information telling a host when to refresh its DHCPv6 configuration data. Therefore, an option 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 many situations: - Unstable environments where unexpected changes are likely to occur. - For planned changes, including renumbering. An administrator can gradually decrease the time as the event nears. - Limit the amount of time before new services or servers are available to the client, such as the addition of a new NTP server or a change of address of a DNS server. See [RFC4076]. 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 [RFC2119]. 3. Information Refresh Time Option Definition The information refresh time option specifies an upper bound for 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 that indicate when the client should contact the server, e.g., addresses with lifetimes. Note that it is only an upper bound. If the client has any reason to make a DHCPv6 request before the refresh time expires, it should attempt to refresh all the data. A client may contact the server before the refresh time expires. Reasons it may do this include the need for additional configuration Venaas, et al. Standards Track [Page 2] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 parameters (such as by an application), a new IPv6 prefix announced by a router, or that it has an indication that it may have moved to a new link. The refresh time option specifies a common refresh time for all theShow full document text