draft-ietf-dhc-lifetime-00.txt   draft-ietf-dhc-lifetime-01.txt 
Internet Engineering Task Force S. Venaas Internet Engineering Task Force S. Venaas
Internet Draft UNINETT Internet Draft UNINETT
Expiration Date: September 2004 Expiration Date: January 2005
T. Chown T. Chown
University of Southampton University of Southampton
March 2004 July 2004
Lifetime Option for DHCPv6 Lifetime Option for DHCPv6
draft-ietf-dhc-lifetime-00.txt draft-ietf-dhc-lifetime-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. 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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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 (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes an option for specifying a lifetime for other This document describes an option for specifying a lifetime for other
DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6 configuration options. It's mainly intended for the stateless
DHCPv6, but also useful when there are no addresses or other entities DHCPv6, but is also useful when there are no addresses or other
with lifetimes that can tell the client when to contact the DHCP entities with lifetimes that can tell the client when to contact the
server to update its configuration. DHCP server to update 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. Lifetime option definition ................................. 3
3.1. Client behaviour ....................................... 3 3.1. Client behaviour ....................................... 3
3.2. Server behaviour ....................................... 4 3.2. Server behaviour ....................................... 4
3.3. Option format .......................................... 4 3.3. Option format .......................................... 4
4. IANA Considerations ........................................ 4 4. IANA Considerations ........................................ 4
5. Acknowledgments ............................................ 4 5. Acknowledgements ........................................... 4
6. Security Considerations .................................... 5 6. Security Considerations .................................... 5
7. References ................................................. 5 7. References ................................................. 5
7.1. Normative References ................................... 5 7.1. Normative References ................................... 5
7.2. Informative References ................................. 5 7.2. Informative References ................................. 5
Authors' Addresses ............................................. 5 Authors' Addresses ............................................. 5
Intellectual Property and Copyright Statements ................. 6
1. Introduction 1. Introduction
DHCPv6 [RFC 3315] has been defined for IPv6 hosts wishing to use DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6
stateful autoconfiguration. However, many hosts will use stateless hosts. However, many hosts will use stateless autoconfiguration as
autoconfiguration as specified in [RFC 2462] for address assignment, specified in [RFC 2462] for address assignment, and use DHCPv6 only
and use DHCPv6 only for other configuration data. This other for other configuration data. This other configuration data will
configuration data will typically have no associated lifetime, hence typically have no associated lifetime, hence there may be no
there may be no information telling a host when to update its DHCP information telling a host when to update its DHCP configuration
configuration data. data.
This option may be useful in unstable environments where unexpected This option may be useful in unstable environments where unexpected
changes are likely to occur, or for planned changes, including changes are likely to occur, or for planned changes, including
renumbering where an administrator can gradually decrease the value renumbering where an administrator can gradually decrease the value
as the event nears. as the event nears.
It may also be useful to allow the client to detect within an It may also be useful to allow the client to detect within an
appropriate time when a specific service change has been made, e.g. appropriate time when a specific service change has been made, e.g.
the addition of a new NTP server, or a change of address of a DNS the addition of a new NTP server, or a change of address of a DNS
server within the local network. See [RENUMREQS] for further server within the local network. See [RENUMREQS] for further
skipping to change at page 3, line 25 skipping to change at page 3, line 25
contained in other options in an advertise or reply message that have contained in other options in an advertise or reply message that have
no associated lifetime. This means that it does not effect e.g. the no associated lifetime. This means that it does not effect e.g. the
IA Address option which contains a lifetime. IA Address option which contains a lifetime.
3.1. Client behaviour 3.1. Client behaviour
A client supporting this option MAY include it in the Option Request A client supporting this option MAY include it in the Option Request
Option (ORO) when sending messages to the DHCP server that allows ORO Option (ORO) when sending messages to the DHCP server that allows ORO
to be included. to be included.
A client MUST ignore this option if the lifetime is set to zero.
If client has received a lifetime with this option, and contacts If client has received a lifetime with this option, and contacts
server to receive new or update any existing data prior to its server to receive new or update any existing data prior to its
expiration, it SHOULD also update data covered by this option. If no expiration, it SHOULD also update data covered by this option. If no
new lifetime is received, it MUST behave as if no value was ever new lifetime is received, it MUST behave as if no value was ever
provided. provided.
When the client detects that the lifetime has expired, it must do as When the client detects that the lifetime has expired, it SHOULD try
to update its configuration data by making a new DHCP request as
follows. follows.
First it MUST ignore or remove the existing lifetime value. If it Before making the request it MUST wait for a random amount of time
does not receive a new value in a later request, it MUST behave as if between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315].
no value was ever provided.
Next it MUST wait for a random amount of time between 0 and
INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315].
Finally it must make a new DHCP request, updating the current
configuration. This request will usually be an Information-request
Message. If client fails to receive a valid response from a server,
it MUST retransmit the message according to the retransmission rules
specified in [RFC 3315].
If the update fails, the current configuration must be kept as if no Then it can make the DHCP request to update the configuration. The
lifetime was ever provided. message MUST be created and transmitted according to [RFC 3315].
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 3.2. Server behaviour
A server sending an Advertise or Reply message containing options, A server sending an Advertise or Reply message containing options,
SHOULD include this option if requested by client, or if none of the SHOULD include this option if requested by client, or if none of the
options contained in the message have associated lifetimes. The options contained in the message have associated lifetimes. The
option MAY also be used in other cases when server sends Advertise or 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 Reply messages. It MUST not be used when server sends other types of
messages. messages. The lifetime MUST be non-zero.
3.3. Option format 3.3. Option format
The format of the Lifetime option is: The format of the Lifetime 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_LIFETIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 38 skipping to change at page 4, line 38
option-len: 4 option-len: 4
lifetime: lifetime in seconds lifetime: lifetime in 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 to the lifetime option
from the DHCP option-code space defined in section "IANA from the DHCP option-code space defined in section "IANA
Considerations" of RFC 3315. Considerations" of RFC 3315.
5. Acknowledgments 5. Acknowledgements
The authors thank Mat Ford, A.K. Vijayabhaskar and Bernie Volz for The authors thank Mat Ford, Ted Lemon, Thomas Narten, A.K.
valuable discussions and comments. Vijayabhaskar and Bernie Volz for valuable discussions and comments.
6. Security Considerations 6. Security Considerations
An attacker could send a fake DHCP reply with a very low lifetime An attacker may be able to send a fake DHCP reply with a very low
value. This could make a client request new data almost immediately. lifetime value. This could make a client request new data almost
The value is however not kept when the next request is made. immediately. The client will however quickly back off.
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.
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-chown-dhc-stateless-dhcpv6-renumbering-00, draft-ietf-dhc-stateless-dhcpv6-renumbering-00,
November 2003. March 2004.
Authors' Addresses Authors' Addresses
Stig Venaas Stig Venaas
UNINETT UNINETT
NO-7465 Trondheim, Norway NO-7465 Trondheim, Norway
Email: venaas@uninett.no 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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
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 (2004). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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