draft-ietf-dhc-lifetime-03.txt   rfc4242.txt 
Internet Engineering Task Force S. Venaas Network Working Group S. Venaas
Internet Draft University of Southampton Request for Comments: 4242 UNINETT
Expiration Date: July 2005 Category: Standards Track T. Chown
T. Chown
University of Southampton University of Southampton
B. Volz B. Volz
Cisco Systems, Inc. Cisco Systems, Inc.
November 2005
January 2005 Information Refresh Time Option for
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Information Refresh Time Option for DHCPv6
draft-ietf-dhc-lifetime-03.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 Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html 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 Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a DHCPv6 option for specifying an upper bound This document describes a Dynamic Host Configuration Protocol for
for how long a client should wait before refreshing information IPv6 (DHCPv6) option for specifying an upper bound for how long a
retrieved from DHCPv6. It is used with stateless DHCPv6 as there are client should wait before refreshing information retrieved from
no addresses or other entities with lifetimes that can tell the DHCPv6. It is used with stateless DHCPv6 as there are no addresses
client when to contact the DHCPv6 server to refresh its or other entities with lifetimes that can tell the client when to
configuration. 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 .....................................................2
3. Information refresh time option definition ................. 3 3. Information Refresh Time Option Definition ......................2
3.1. Constants .............................................. 4 3.1. Constants ..................................................3
3.2. Client behaviour ....................................... 4 3.2. Client Behaviour ...........................................3
3.3. Server behaviour ....................................... 5 3.3. Server Behaviour ...........................................4
3.4. Option format .......................................... 5 3.4. Option Format ..............................................5
4. IANA Considerations ........................................ 6 4. IANA Considerations .............................................5
5. Acknowledgements ........................................... 6 5. Acknowledgements ................................................5
6. Security Considerations .................................... 6 6. Security Considerations .........................................5
7. References ................................................. 6 7. References ......................................................6
7.1. Normative References ................................... 6 7.1. Normative References .......................................6
7.2. Informative References ................................. 7 7.2. Informative References .....................................6
Authors' Addresses ............................................. 7
Intellectual Property and Copyright Statements ................. 7
1. Introduction 1. Introduction
DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts.
hosts. However, many hosts will use stateless autoconfiguration as However, many hosts will use stateless autoconfiguration as specified
specified in [RFC 2462] for address assignment, and use DHCPv6 only in [RFC2462] for address assignment, and use DHCPv6 only for other
for other configuration data, see [RFC 3736]. This other configuration data; see [RFC3736]. This other configuration data
configuration data will typically have no associated lifetime, hence will typically have no associated lifetime, hence there may be no
there may be no information telling a host when to refresh its DHCPv6 information telling a host when to refresh its DHCPv6 configuration
configuration data. Therefore, an option that can be used from data. Therefore, an option that can be used from server to client to
server to client to inform the client when it should refresh the inform the client when it should refresh the other configuration data
other configuration data is needed. is needed.
This option is useful in many situations: This option is useful in many situations:
- Unstable environments where unexpected changes are likely to - Unstable environments where unexpected changes are likely to
occur. occur.
- For planned changes, including renumbering. An administrator - For planned changes, including renumbering. An administrator
can gradually decrease the time as the event nears. can gradually decrease the time as the event nears.
- Limit the amount of time before new services or servers are - Limit the amount of time before new services or servers are
available to the client, such as the addition of a new NTP available to the client, such as the addition of a new NTP
server or a change of address of a DNS server. See server or a change of address of a DNS server. See [RFC4076].
[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
2119]. [RFC2119].
3. Information refresh time option definition 3. Information Refresh Time Option Definition
The information refresh time option specifies an upper bound for how The information refresh time option specifies an upper bound for how
long a client should wait before refreshing information retrieved long a client should wait before refreshing information retrieved
from DHCPv6. It is only used in Reply messages in response to from DHCPv6. It is only used in Reply messages in response to
Information-Request messages. In other messages there will usually Information-Request messages. In other messages there will usually
be other options that indicate when the client should contact the be other options that indicate when the client should contact the
server, e.g. addresses with lifetimes. server, e.g., addresses with lifetimes.
Note that it is only an upper bound. If the client has any reason to 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 make a DHCPv6 request before the refresh time expires, it should
attempt to refresh all the data. attempt to refresh all the data.
A client may contact the server before the refresh time expires. A client may contact the server before the refresh time expires.
Reasons it may do this include the need for additional configuration Reasons it may do this include the need for additional configuration
parameters (such as by an application), a new IPv6 prefix announced 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 by a router, or that it has an indication that it may have moved to a
link. new link.
The refresh time option specifies a common refresh time for all the The refresh time option specifies a common refresh time for all the
data. It doesn't make sense to have different refresh time values data. It doesn't make sense to have different refresh time values
for different data, since when the client has reason to refresh some for different data, since when the client has reason to refresh some
of its data, it should also refresh the remaining data. Because of 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 this, the option must only appear in the options area of the Reply
message. message.
The expiry of the refresh time in itself does not in any way mean 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 that the client should remove the data. The client should keep its
current data while attempting to refresh it. The client is however current data while attempting to refresh it. However, the client is
free to fall back to other mechanisms than DHCPv6 if it cannot free to fall back to mechanisms other than DHCPv6 if it cannot
refresh the data within a reasonable amount of time. refresh the data within a reasonable amount of time.
When a client receives a Reply to an Information-Request that When a client receives a Reply to an Information-Request that
contains configuration information, it should install that new contains configuration information, it should install that new
configuration information after removing any previously received configuration information after removing any previously received
configuration information. It should also remove information that is configuration information. It should also remove information that is
missing from the new information set, e.g. an option might be left missing from the new information set, e.g., an option might be left
out or contain only a subset of what it did previously. out or contain only a subset of what it did previously.
3.1. Constants 3.1. Constants
We define two constants for use by the protocol. How they are used We define two constants for use by the protocol. How they are used
is specified in the sections below. is specified in the sections below.
IRT_DEFAULT 86400 IRT_DEFAULT 86400
In some cases the client uses a default refresh time In some cases the client uses a default refresh time
IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400
(24 hours). The client implementation SHOULD allow for this (24 hours). The client implementation SHOULD allow for this
value to be configurable. value to be configurable.
IRT_MINIMUM 600 IRT_MINIMUM 600
This defines a minimum value for the refresh time. This defines a minimum value for the refresh time.
3.2. Client behaviour 3.2. Client Behaviour
A client MUST request this option in the Option Request Option (ORO) A client MUST request this option in the Option Request Option (ORO)
when sending Information-Request messages to the DHCPv6 server. A when sending Information-Request messages to the DHCPv6 server. A
client MUST NOT request this option in the ORO in any other messages. client MUST NOT request this option in the ORO in any other messages.
If the Reply to an Information-Request message does not contain this If the Reply to an Information-Request message does not contain this
option, the client MUST behave as if the option with value option, the client MUST behave as if the option with value
IRT_DEFAULT was provided. IRT_DEFAULT was provided.
A client MUST use the refresh time IRT_MINIMUM if it receives the A client MUST use the refresh time IRT_MINIMUM if it receives the
skipping to change at page 5, line 21 skipping to change at page 4, line 33
A client MAY have a maximum value for the refresh time, where that A client MAY have a maximum value for the refresh time, where that
value is used whenever the client receives this option with a value value is used whenever the client receives this option with a value
higher than the maximum. This also means that the maximum value is higher than the maximum. This also means that the maximum value is
used when the received value is "infinity". A maximum value might used when the received value is "infinity". A maximum value might
make the client less vulnerable to attacks based on forged DHCP make the client less vulnerable to attacks based on forged DHCP
messages. Without a maximum value, a client may be made to use wrong messages. Without a maximum value, a client may be made to use wrong
information for a possibly infinite period of time. There may information for a possibly infinite period of time. There may
however be reasons for having a very long refresh time, so it may be however be reasons for having a very long refresh time, so it may be
useful for this maximum value to be configurable. useful for this maximum value to be configurable.
3.3. Server behaviour 3.3. Server Behaviour
A server sending a Reply to an Information-Request message SHOULD A server sending a Reply to an Information-Request message SHOULD
include this option if it is requested in the ORO of the Information- include this option if it is requested in the ORO of the Information-
Request. Request.
The option value MUST NOT be smaller than IRT_MINIMUM. The server The option value MUST NOT be smaller than IRT_MINIMUM. The server
SHOULD give a warning if it is configured with a smaller value. SHOULD give a warning if it is configured with a smaller value.
The option MUST only appear in the options area of Reply messages. The option MUST only appear in the options area of Reply messages.
3.4. Option format 3.4. Option Format
The format of the information refresh time option is: 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-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time | | information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code option-code
OPTION_INFORMATION_REFRESH_TIME (to be decided) OPTION_INFORMATION_REFRESH_TIME (32)
option-len option-len
4 4
information-refresh-time information-refresh-time
Time duration relative to the current time, expressed in units Time duration relative to the current time, expressed in units
of seconds of seconds
4. IANA Considerations 4. IANA Considerations
IANA is requested to assign an option code for the information The IANA has assigned an option code for the information refresh time
refresh time option from the DHCPv6 option-code space [RFC 3315]. option from the DHCPv6 option-code space [RFC3315].
5. Acknowledgements 5. Acknowledgements
The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten, The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten,
Joe Quanaim and A.K. Vijayabhaskar for valuable discussions and Joe Quanaim, and A.K. Vijayabhaskar for valuable discussions and
comments. comments.
6. Security Considerations 6. Security Considerations
Section 23 of [RFC 3315] outlines the DHCPv6 security considerations. Section 23 of [RFC 3315] outlines the DHCPv6 security considerations.
This option does not change these in any significant way. An This option does not change these in any significant way. An
attacker could send faked Reply messages with a low information attacker could send faked Reply messages with a low information
refresh time value, which would trigger use of IRT_MINIMUM to refresh time value, which would trigger use of IRT_MINIMUM to
minimize this threat. Another attack might be to send a very large minimize this threat. Another attack might be to send a very large
value, to make the client use forged information for a long period of value, to make the client use forged information for a long period of
time. A possible maximum limit at the client is suggested, which time. A possible maximum limit at the client is suggested, which
would reduce this problem. would reduce this problem.
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 [RFC2462] Thomson, S. and 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, [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC 3736] R. Droms, "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (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 [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
Requirements for Stateless DHCPv6", work-in-progress, Requirements for Stateless Dynamic Host Configuration
draft-ietf-dhc-stateless-dhcpv6-renumbering-01, Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
March 2004.
Authors' Addresses Authors' Addresses
Stig Venaas Stig Venaas
University of Southampton UNINETT
School of Electronics and Computer Science Trondheim NO 7465
Southampton, Hampshire SO17 1BJ Norway
United Kingdom
EMail: sv@ecs.soton.ac.uk 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 Bernard Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
EMail: volz@cisco.com EMail: volz@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 8, line 11 skipping to change at page 8, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
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 (2005). 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 Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 33 change blocks. 
111 lines changed or deleted 91 lines changed or added

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