draft-ietf-dhc-lifetime-02.txt   draft-ietf-dhc-lifetime-03.txt 
Internet Engineering Task Force S. Venaas Internet Engineering Task Force S. Venaas
Internet Draft UNINETT Internet Draft University of Southampton
Expiration Date: March 2005 Expiration Date: July 2005
T. Chown T. Chown
University of Southampton University of Southampton
B. Volz B. Volz
Cisco Systems, Inc. Cisco Systems, Inc.
September 2004 January 2005
Information Refresh Time Option for DHCPv6 Information Refresh Time Option for DHCPv6
draft-ietf-dhc-lifetime-02.txt draft-ietf-dhc-lifetime-03.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 43 skipping to change at page 1, line 43
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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 (2005). All Rights Reserved.
Abstract Abstract
This document describes a DHCPv6 option for specifying an upper bound This document describes a DHCPv6 option for specifying an upper bound
for how long a client should wait before refreshing information for how long a client should wait before refreshing information
retrieved from DHCPv6. It is used with stateless DHCPv6 as there are retrieved from DHCPv6. It is used with stateless DHCPv6 as there are
no addresses or other entities with lifetimes that can tell the no addresses or other entities with lifetimes that can tell the
client when to contact the DHCPv6 server to refresh its client when to contact the DHCPv6 server to refresh its
configuration. configuration.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3. Information refresh time option definition ................. 3 3. Information refresh time option definition ................. 3
3.1. Constants .............................................. 4 3.1. Constants .............................................. 4
3.2. Client behaviour ....................................... 4 3.2. Client behaviour ....................................... 4
3.3. Server behaviour ....................................... 5 3.3. Server behaviour ....................................... 5
3.4. Option format .......................................... 5 3.4. Option format .......................................... 5
4. IANA Considerations ........................................ 6 4. IANA Considerations ........................................ 6
5. Acknowledgements ........................................... 6 5. Acknowledgements ........................................... 6
6. Security Considerations .................................... 6 6. Security Considerations .................................... 6
7. References ................................................. 6 7. References ................................................. 6
7.1. Normative References ................................... 6 7.1. Normative References ................................... 6
7.2. Informative References ................................. 6 7.2. Informative References ................................. 7
Authors' Addresses ............................................. 7 Authors' Addresses ............................................. 7
Intellectual Property and Copyright Statements ................. 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, see [RFC 3736]. This other for other configuration data, see [RFC 3736]. This other
configuration data will typically have no associated lifetime, hence configuration data will typically have no associated lifetime, hence
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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. The client is however
free to fall back to other mechanisms if it cannot refresh the data free to fall back to other mechanisms than DHCPv6 if it cannot
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 (i.e., does not contain a Status contains configuration information, it should install that new
Code option), it should install that new configuration information configuration information after removing any previously received
after removing any previously received configuration information. It configuration information. It should also remove information that is
should also remove information that is missing from the new missing from the new information set, e.g. an option might be left
information set, e.g. an option might be left out or contain only a out or contain only a subset of what it did previously.
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 include 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 include 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
option with a value less than IRT_MINIMUM. option with a value less than IRT_MINIMUM.
As per section 5.6 of [RFC 3315], the value 0xffffffff is taken to 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 mean "infinity" and implies that the client should not refresh its
skipping to change at page 5, line 12 skipping to change at page 5, line 11
If a client contacts the server to obtain new data or refresh some If a client contacts the server to obtain new data or refresh some
existing data before the refresh time expires, then it SHOULD also existing data before the refresh time expires, then it SHOULD also
refresh all data covered by this option. refresh all data covered by this option.
When the client detects that the refresh time has expired, it SHOULD When the client detects that the refresh time has expired, it SHOULD
try to update its configuration data by sending an Information- try to update its configuration data by sending an Information-
Request as specified in section 18.1.5 of [RFC 3315], except that the 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 client MUST delay sending the first Information-Request by a random
amount of time between 0 and INF_MAX_DELAY. amount of time between 0 and INF_MAX_DELAY.
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
higher than the maximum. This also means that the maximum value is
used when the received value is "infinity". A maximum value might
make the client less vulnerable to attacks based on forged DHCP
messages. Without a maximum value, a client may be made to use wrong
information for a possibly infinite period of time. There may
however be reasons for having a very long refresh time, so it may be
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 included 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:
skipping to change at page 6, line 22 skipping to change at page 6, line 25
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, or with a large or infinite value which would minimize this threat. Another attack might be to send a very large
be no worse than a client that does not make use of this option. value, to make the client use forged information for a long period of
time. A possible maximum limit at the client is suggested, which
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 [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
skipping to change at page 7, line 8 skipping to change at page 7, line 15
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-01, draft-ietf-dhc-stateless-dhcpv6-renumbering-01,
March 2004. March 2004.
Authors' Addresses Authors' Addresses
Stig Venaas Stig Venaas
UNINETT University of Southampton
NO-7465 Trondheim School of Electronics and Computer Science
Norway Southampton, Hampshire SO17 1BJ
EMail: venaas@uninett.no United Kingdom
EMail: sv@ecs.soton.ac.uk
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.
skipping to change at page 8, line 17 skipping to change at page 8, line 23
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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. 

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