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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4242 (Proposed Standard) | |
| 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 the
Show full document text