draft-ietf-dhc-lifetime-01.txt   draft-ietf-dhc-lifetime-02.txt 
Internet Engineering Task Force S. Venaas Internet Engineering Task Force S. Venaas
Internet Draft UNINETT Internet Draft UNINETT
Expiration Date: January 2005 Expiration Date: March 2005
T. Chown T. Chown
University of Southampton University of Southampton
July 2004 B. Volz
Cisco Systems, Inc.
Lifetime Option for DHCPv6 September 2004
draft-ietf-dhc-lifetime-01.txt Information Refresh Time Option for DHCPv6
draft-ietf-dhc-lifetime-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 44 skipping to change at page 2, line 7
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes an option for specifying a lifetime for other This document describes a DHCPv6 option for specifying an upper bound
DHCPv6 configuration options. It's mainly intended for the stateless for how long a client should wait before refreshing information
DHCPv6, but is also useful when there are no addresses or other retrieved from DHCPv6. It is used with stateless DHCPv6 as there are
entities with lifetimes that can tell the client when to contact the no addresses or other entities with lifetimes that can tell the
DHCP server to update its configuration. client when to contact the DHCPv6 server to refresh its
configuration.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Terminology ................................................ 3 2. Terminology ................................................ 3
3. Lifetime option definition ................................. 3 3. Information refresh time option definition ................. 3
3.1. Client behaviour ....................................... 3 3.1. Constants .............................................. 4
3.2. Server behaviour ....................................... 4 3.2. Client behaviour ....................................... 4
3.3. Option format .......................................... 4 3.3. Server behaviour ....................................... 5
4. IANA Considerations ........................................ 4 3.4. Option format .......................................... 5
5. Acknowledgements ........................................... 4 4. IANA Considerations ........................................ 6
6. Security Considerations .................................... 5 5. Acknowledgements ........................................... 6
7. References ................................................. 5 6. Security Considerations .................................... 6
7.1. Normative References ................................... 5 7. References ................................................. 6
7.2. Informative References ................................. 5 7.1. Normative References ................................... 6
Authors' Addresses ............................................. 5 7.2. Informative References ................................. 6
Intellectual Property and Copyright Statements ................. 6 Authors' Addresses ............................................. 7
Intellectual Property and Copyright Statements ................. 7
1. Introduction 1. Introduction
DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6
hosts. However, many hosts will use stateless autoconfiguration as hosts. However, many hosts will use stateless autoconfiguration as
specified in [RFC 2462] for address assignment, and use DHCPv6 only specified in [RFC 2462] for address assignment, and use DHCPv6 only
for other configuration data. This other configuration data will for other configuration data, see [RFC 3736]. This other
typically have no associated lifetime, hence there may be no configuration data will typically have no associated lifetime, hence
information telling a host when to update its DHCP configuration there may be no information telling a host when to refresh its DHCPv6
data. 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 may be useful in unstable environments where unexpected This option is useful in many situations:
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 - Unstable environments where unexpected changes are likely to
appropriate time when a specific service change has been made, e.g. occur.
the addition of a new NTP server, or a change of address of a DNS
server within the local network. See [RENUMREQS] for further - For planned changes, including renumbering. An administrator
details. 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
[RENUMREQS].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [RFC document are to be interpreted as described in BCP 14, RFC 2119 [RFC
2119]. 2119].
3. Lifetime option definition 3. Information refresh time option definition
The lifetime option specifies a lifetime for all configuration data The information refresh time option specifies an upper bound for how
contained in other options in an advertise or reply message that have long a client should wait before refreshing information retrieved
no associated lifetime. This means that it does not effect e.g. the from DHCPv6. It is only used in Reply messages in response to
IA Address option which contains a lifetime. 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.
3.1. Client behaviour 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 supporting this option MAY include it in the Option Request A client may contact the server before the refresh time expires.
Option (ORO) when sending messages to the DHCP server that allows ORO Reasons it may do this include the need for additional configuration
to be included. 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.
A client MUST ignore this option if the lifetime is set to zero. 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 refresh the remaining data. Because of
this, the option must only appear in the options area of the Reply
message.
If client has received a lifetime with this option, and contacts The expiry of the refresh time in itself does not in any way mean
server to receive new or update any existing data prior to its that the client should remove the data. The client should keep its
expiration, it SHOULD also update data covered by this option. If no current data while attempting to refresh it. The client is however
new lifetime is received, it MUST behave as if no value was ever free to fall back to other mechanisms if it cannot refresh the data
provided. within a reasonable amount of time.
When the client detects that the lifetime has expired, it SHOULD try When a client receives a Reply to an Information-Request that
to update its configuration data by making a new DHCP request as contains configuration information (i.e., does not contain a Status
follows. Code option), it should install that new configuration information
after removing any previously received configuration information. It
should also remove information that is missing from the new
information set, e.g. an option might be left out or contain only a
subset of what it did previously.
Before making the request it MUST wait for a random amount of time 3.1. Constants
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 We define two constants for use by the protocol. How they are used
message MUST be created and transmitted according to [RFC 3315]. is specified in the sections below.
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].
3.2. Server behaviour 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.
A server sending an Advertise or Reply message containing options, IRT_MINIMUM 600
SHOULD include this option if requested by client, or if none of the This defines a minimum value for the refresh time.
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 3.2. Client behaviour
The format of the Lifetime option is: 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 the option with value
IRT_DEFAULT was provided.
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 refresh time has expired, it SHOULD
try to update its configuration data by sending an Information-
Request as specified in section 18.1.5 of [RFC 3315], except that the
client MUST delay sending the first Information-Request by a random
amount of time between 0 and INF_MAX_DELAY.
3.3. Server behaviour
A server sending a Reply to an Information-Request message SHOULD
include this option if it is included in the ORO of the Information-
Request.
The option value MUST NOT be smaller than IRT_MINIMUM. The server
SHOULD give a warning if it is configured with a smaller value.
The option MUST only appear in the options area of Reply messages.
3.4. Option format
The format of the information refresh time option is:
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime | | information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_LIFETIME (to be decided) option-code
OPTION_INFORMATION_REFRESH_TIME (to be decided)
option-len: 4 option-len
4
lifetime: lifetime in seconds information-refresh-time
Time duration relative to the current time, expressed in units
of seconds
4. IANA Considerations 4. IANA Considerations
IANA is requested to assign an option code to the lifetime option IANA is requested to assign an option code for the information
from the DHCP option-code space defined in section "IANA refresh time option from the DHCPv6 option-code space [RFC 3315].
Considerations" of RFC 3315.
5. Acknowledgements 5. Acknowledgements
The authors thank Mat Ford, Ted Lemon, Thomas Narten, A.K. The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten,
Vijayabhaskar and Bernie Volz for valuable discussions and comments. Joe Quanaim and A.K. Vijayabhaskar for valuable discussions and
comments.
6. Security Considerations 6. Security Considerations
An attacker may be able to send a fake DHCP reply with a very low Section 23 of [RFC 3315] outlines the DHCPv6 security considerations.
lifetime value. This could make a client request new data almost This option does not change these in any significant way. An
immediately. The client will however quickly back off. attacker could send faked Reply messages with a low information
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 that does not make use of this option.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, [RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (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 7.2. Informative References
[RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering [RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering
Requirements for Stateless DHCPv6", work-in-progress, Requirements for Stateless DHCPv6", work-in-progress,
draft-ietf-dhc-stateless-dhcpv6-renumbering-00, draft-ietf-dhc-stateless-dhcpv6-renumbering-01,
March 2004. March 2004.
Authors' Addresses Authors' Addresses
Stig Venaas Stig Venaas
UNINETT UNINETT
NO-7465 Trondheim, Norway NO-7465 Trondheim
Email: venaas@uninett.no Norway
EMail: venaas@uninett.no
Tim Chown Tim Chown
University of Southampton University of Southampton
School of Electronics and Computer Science School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
EMail: tjc@ecs.soton.ac.uk EMail: tjc@ecs.soton.ac.uk
Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
EMail: volz@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/