draft-ietf-dhc-rapid-commit-opt-01.txt   draft-ietf-dhc-rapid-commit-opt-02.txt 
Network Working Group S. Park Network Working Group S. Park
Internet-Draft P. Kim Internet-Draft P. Kim
Expires : 11 September 2004 Samsung Electronics. Expires : October 18, 2004 Samsung Electronics
B. Volz B. Volz
10 March 2004 Cisco Systems, Inc.
April 19, 2004
Rapid Commit Option for DHCPv4 Rapid Commit Option for DHCPv4
draft-ietf-dhc-rapid-commit-opt-01.txt draft-ietf-dhc-rapid-commit-opt-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 all provisions of Section 10 of RFC2026
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.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress". 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
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
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 defines a new DHCPv4 option, modeled on the DHCPv6 This document defines a new DHCPv4 option, modeled on the DHCPv6
Rapid Commit option, for obtaining IP address and configuration Rapid Commit option, for obtaining IP address and configuration
information using a 2-message exchange rather than the usual 4- information using a 2-message exchange rather than the usual 4-
message exchange, expediting client configuration. message exchange, expediting client configuration.
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction.................................................2
2. Requirements.................................................3 2. Requirements.................................................3
3. Client/Server Operations.....................................3 3. Client/Server Operations.....................................3
3.1 Detailed Flow................................................3 3.1 Detailed Flow................................................3
3.2 Administrative Considerations................................7 3.2 Administrative Considerations................................7
4. Rapid Commit Option Format...................................8 4. Rapid Commit Option Format...................................8
5. IANA Considerations..........................................8 5. IANA Considerations..........................................8
6. Security Considerations......................................8 6. Security Considerations......................................8
7. References...................................................9 7. References...................................................9
7.1 Normative References.........................................9 7.1 Normative References.........................................9
7.2 Informative References.......................................9 7.2 Informative References.......................................9
8. Authors' Addresses...........................................9 8. Authors' Addresses..........................................10
9. Acknowledgements............................................10 9. Acknowledgements............................................10
1. Introduction 1. Introduction
In some environments, such as those in which high mobility occurs In some environments, such as those in which high mobility occurs
and the network attachment point changes frequently, it is benefical and the network attachment point changes frequently, it is benefical
to rapidly configure clients. And, in these environments it is to rapidly configure clients. And, in these environments it is
possible to more quickly configure clients because the protections possible to more quickly configure clients because the protections
offered by the normal (and longer) 4-message exchange may not be offered by the normal (and longer) 4-message exchange may not be
needed. The 4-message exchange allows for redundancy (multiple DHCP needed. The 4-message exchange allows for redundancy (multiple DHCP
skipping to change at page 3, line 13 skipping to change at page 3, line 13
as defined herein. as defined herein.
2. Requirements 2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC 2119] document, are to be interpreted as described in [RFC 2119]
3. Client/Server Operations 3. Client/Server Operations
A client that supports the Rapid Commit option SHOULD include it in If a client that supports the Rapid Commit option intends to use
the rapid commit capability, it includes a Rapid Commit option in
DHCPDISCOVER messages that it sends. The client MUST NOT include DHCPDISCOVER messages that it sends. The client MUST NOT include
it in any other messages. A cilent and server only use this option it in any other messages. A client and server only use this option
when configured to do so. when configured to do so.
A client that sent a DHCPDISCOVER with Rapid Commit option processes A client that sent a DHCPDISCOVER with Rapid Commit option processes
responses as described in [RFC 2131]. However, if the client responses as described in [RFC 2131]. However, if the client
receives a DHCPACK message with a Rapid Commit option, it SHOULD receives a DHCPACK message with a Rapid Commit option, it SHOULD
process the DHCPACK immediately (without waiting for additional process the DHCPACK immediately (without waiting for additional
DHCPOFFER or DHCPACK messages) and use the address and DHCPOFFER or DHCPACK messages) and use the address and
configuration information contained therein. configuration information contained therein.
A server that supports the Rapid Commit option MAY respond to a A server that supports the Rapid Commit option MAY respond to a
skipping to change at page 3, line 42 skipping to change at page 3, line 43
List option [RFC 2132]. List option [RFC 2132].
All other DHCP operations are as documented in [RFC 2131]. All other DHCP operations are as documented in [RFC 2131].
3.1 Detailed Flow 3.1 Detailed Flow
The following is a revised Section 3.1 of [RFC 2131] that includes The following is a revised Section 3.1 of [RFC 2131] that includes
handling of the Rapid Commit option. handling of the Rapid Commit option.
1. The client broadcasts a DHCPDISCOVER message on its local 1. The client broadcasts a DHCPDISCOVER message on its local
physical subnet and SHOULD include the Rapid Commit option if physical. If the client supports the Rapid Commit option and
it supports this option. The DHCPDISCOVER message MAY include intends to use the rapid commit capability, it includes a
options that suggest values for the network address and lease Rapid Commit option in the DHCPDISCOVER message. The
duration. BOOTP relay agents may pass the message on to DHCP DHCPDISCOVER message MAY include options that suggest values
servers not on the same physical subnet. for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same
physical subnet.
2. Each server may respond with either a DHCPOFFER message or a 2. Each server may respond with either a DHCPOFFER message or a
DHCPACK message with Rapid Commit option (the latter only if DHCPACK message with Rapid Commit option (the latter only if
the DHCPDISCOVER contained a Rapid Commit option and the the DHCPDISCOVER contained a Rapid Commit option and the
server's configuration policies allow use of Rapid Commit) server's configuration policies allow use of Rapid Commit)
that includes an available network address in the 'yiaddr' that includes an available network address in the 'yiaddr'
field (and other configuration parameters in DHCP options). field (and other configuration parameters in DHCP options).
Servers sending a DHCPOFFER need not reserve the offered Servers sending a DHCPOFFER need not reserve the offered
network address, although the protocol will work more network address, although the protocol will work more
efficiently if the server avoids allocating the offered efficiently if the server avoids allocating the offered
skipping to change at page 7, line 9 skipping to change at page 7, line 11
that the address is already in use (e.g., through the use of that the address is already in use (e.g., through the use of
ARP), the client MUST send a DHCPDECLINE message to the server ARP), the client MUST send a DHCPDECLINE message to the server
and restarts the configuration process. The client SHOULD wait and restarts the configuration process. The client SHOULD wait
a minimum of ten seconds before restarting the configuration a minimum of ten seconds before restarting the configuration
process to avoid excessive network traffic in case of looping. process to avoid excessive network traffic in case of looping.
If the client receives a DHCPNAK message, the client restarts If the client receives a DHCPNAK message, the client restarts
the configuration process. the configuration process.
The client times out and retransmits the DHCPREQUEST message if The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK or a DHCPNAK message. the client receives neither a DHCPACK nor a DHCPNAK message.
The client retransmits the DHCPREQUEST according to the The client retransmits the DHCPREQUEST according to the
retransmission algorithm in section 4.1 of [RFC 2131]. The retransmission algorithm in section 4.1 of [RFC 2131]. The
client should choose to retransmit the DHCPREQUEST enough times client should choose to retransmit the DHCPREQUEST enough times
to give adequate probability of contacting the server without to give adequate probability of contacting the server without
causing the client (and the user of that client) to wait overly causing the client (and the user of that client) to wait overly
long before giving up; e.g., a client retransmitting as long before giving up; e.g., a client retransmitting as
described in section 4.1 of [RFC 2131] might retransmit the described in section 4.1 of [RFC 2131] might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds, DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing receives neither a DHCPACK nor a DHCPNAK message after employing
the retransmission algorithm, the client reverts to INIT the retransmission algorithm, the client reverts to INIT
state and restarts the initialization process. The client state and restarts the initialization process. The client
SHOULD notify the user that the initialization process has SHOULD notify the user that the initialization process has
failed and is restarting. failed and is restarting.
6. The client may choose to relinquish its lease on a network 6. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. The address by sending a DHCPRELEASE message to the server. The
client identifies the lease to be released with its 'client client identifies the lease to be released with its 'client
identifier', or 'chaddr' and network address in the DHCPRELEASE identifier', or 'chaddr' and network address in the DHCPRELEASE
message. If the client used a 'client identifier' when it message. If the client used a 'client identifier' when it
skipping to change at page 9, line 35 skipping to change at page 10, line 8
[RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP [RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP
Messages, RFC 3118, June 2001. Messages, RFC 3118, June 2001.
[RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol [RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol
for IPv6, RFC 3315, July 2003. for IPv6, RFC 3315, July 2003.
8. Authors' Addresses 8. Authors' Addresses
Soohong Daniel Park Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics Mobile Platform Laboratory
416, Maetan-3Dong, Paldal-Gu, Suwon Samsung Electronics
Gyeonggi-Do, Korea Korea
Phone: +82-31-200-4508 Phone: +82-31-200-4508
EMail: soohong.park@samsung.com EMail: soohong.park@samsung.com
Pyungsoo Kim Pyungsoo Kim
Mobile Platform Laboratory, SAMSUNG Electronics Mobile Platform Laboratory
416, Maetan-3Dong, Paldal-Gu, Suwon Samsung Electronics
Gyeonggi-Do, Korea Korea
Phone: +82-31-200-4635 Phone: +82-31-200-4635
Email: kimps@samsung.com Email: kimps@samsung.com
Bernie Volz Bernie Volz
116 Hawkins Pond Road Cisco Systems, Inc.
Center Harbor, NH 03226-3103 1414 Massachusette Ave.
Boxborough, MA 01719
USA USA
Phone: +1-603-968-3062 Phone: +1-978-936-0382
EMail: volz@metrocast.net EMail: volz@cisco.com
9. Acknowledgements 9. Acknowledgements
Special thanks to Ted Lemon, Andre Kostur and Ralph Droms for Special thanks to Ted Lemon and Andre Kostur for their many
their many valuable comments. valuable comments. Thanks to Ralph Droms for his review comments
during WGLC.
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (C) The Internet Society (2004). This document is subject
intellectual property or other rights that might be claimed to to the rights, licenses and restrictions contained in BCP 78 and
pertain to the implementation or use of the technology described in except as set forth therein, the authors retain all their rights.
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any This document and the information contained herein are provided on
copyrights, patents or patent applications, or other proprietary an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
rights which may cover technology that may be required to practice REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
this standard. Please address the information to the IETF Executive INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
Director. 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.
Full Copyright Statement Intellectual Property
Copyright (C) The Internet Society (2004). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use
and distributed, in whole or in part, without restriction of any of such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph specification can be obtained from the IETF on-line IPR repository
are included on all such copies and derivative works. However, this at http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention
revoked by the Internet Society or its successors or assignees. 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.
This document and the information contained herein is provided on an Acknowledgement
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
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/