Internet Engineering Task Force S. Venaas
Internet Draft UNINETT
Expiration Date: January 2005
T. Chown
University of Southampton
July 2004
Lifetime Option for DHCPv6
draft-ietf-dhc-lifetime-01.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
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes an option for specifying a lifetime for other
DHCPv6 configuration options. It's mainly intended for the stateless
DHCPv6, but is also useful when there are no addresses or other
entities with lifetimes that can tell the client when to contact the
DHCP server to update its configuration.
Venaas & Chown [Expires January 2005] [Page 1]
Internet Draft draft-ietf-dhc-lifetime-01.txt July 2004
Table of Contents
1. Introduction ............................................... 2
2. Terminology ................................................ 3
3. Lifetime option definition ................................. 3
3.1. Client behaviour ....................................... 3
3.2. Server behaviour ....................................... 4
3.3. Option format .......................................... 4
4. IANA Considerations ........................................ 4
5. Acknowledgements ........................................... 4
6. Security Considerations .................................... 5
7. References ................................................. 5
7.1. Normative References ................................... 5
7.2. Informative References ................................. 5
Authors' Addresses ............................................. 5
Intellectual Property and Copyright Statements ................. 6
1. Introduction
DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6
hosts. However, many hosts will use stateless autoconfiguration as
specified in [RFC 2462] for address assignment, and use DHCPv6 only
for other configuration data. This other configuration data will
typically have no associated lifetime, hence there may be no
information telling a host when to update its DHCP configuration
data.
This option may be useful in unstable environments where unexpected
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
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
server within the local network. See [RENUMREQS] for further
details.
Venaas & Chown [Expires January 2005] [Page 2]
Internet Draft draft-ietf-dhc-lifetime-01.txt July 2004
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 [RFC
2119].
3. Lifetime option definition
The lifetime option specifies a lifetime for all configuration data
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
IA Address option which contains a lifetime.
3.1. Client behaviour
A client supporting this option MAY include it in the Option Request
Option (ORO) when sending messages to the DHCP server that allows ORO
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
server to receive new or update any existing data prior to its
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
provided.
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.
Before making the request it MUST wait for a random amount of time
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
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].
Venaas & Chown [Expires January 2005] [Page 3]
Internet Draft draft-ietf-dhc-lifetime-01.txt July 2004
3.2. Server behaviour
A server sending an Advertise or Reply message containing options,
SHOULD include this option if requested by client, or if none of the
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
The format of the Lifetime option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LIFETIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_LIFETIME (to be decided)
option-len: 4
lifetime: lifetime in seconds
4. IANA Considerations
IANA is requested to assign an option code to the lifetime option
from the DHCP option-code space defined in section "IANA
Considerations" of RFC 3315.
5. Acknowledgements
The authors thank Mat Ford, Ted Lemon, Thomas Narten, A.K.
Vijayabhaskar and Bernie Volz for valuable discussions and comments.
Venaas & Chown [Expires January 2005] [Page 4]
Internet Draft draft-ietf-dhc-lifetime-01.txt July 2004
6. Security Considerations
An attacker may be able to send a fake DHCP reply with a very low
lifetime value. This could make a client request new data almost
immediately. The client will however quickly back off.
7. References
7.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins,
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
7.2. Informative References
[RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, "Renumbering
Requirements for Stateless DHCPv6", work-in-progress,
draft-ietf-dhc-stateless-dhcpv6-renumbering-00,
March 2004.
Authors' Addresses
Stig Venaas
UNINETT
NO-7465 Trondheim, Norway
Email: venaas@uninett.no
Tim Chown
University of Southampton
School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Venaas & Chown [Expires January 2005] [Page 5]
Internet Draft draft-ietf-dhc-lifetime-01.txt July 2004
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.
Venaas & Chown [Expires January 2005] [Page 6]
