draft-ietf-dhc-rapid-commit-opt-02.txt   draft-ietf-dhc-rapid-commit-opt-03.txt 
Network Working Group S. Park Network Working Group S. Park
Internet-Draft P. Kim Internet-Draft P. Kim
Expires : October 18, 2004 Samsung Electronics May 12, 2004 Samsung Electronics.
B. Volz Expires : November 11, 2004 B. Volz
Cisco Systems, Inc. Cisco Systems, Inc.
April 19, 2004
Rapid Commit Option for DHCPv4 Rapid Commit Option for DHCPv4
draft-ietf-dhc-rapid-commit-opt-02.txt draft-ietf-dhc-rapid-commit-opt-03.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 2, line 10 skipping to change at page 2, line 10
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................................................4
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..........................................10 8. Authors' Addresses..........................................10
9. Acknowledgements............................................10 9. Acknowledgements............................................10
skipping to change at page 3, line 43 skipping to change at page 4, line 11
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. If the client supports the Rapid Commit option and physical subnet. If the client supports the Rapid Commit
intends to use the rapid commit capability, it includes a option and intends to use the rapid commit capability, it
Rapid Commit option in the DHCPDISCOVER message. The includes a Rapid Commit option in the DHCPDISCOVER message.
DHCPDISCOVER message MAY include options that suggest values The DHCPDISCOVER message MAY include options that suggest
for the network address and lease duration. BOOTP relay values for the network address and lease duration. BOOTP
agents may pass the message on to DHCP servers not on the same relay agents may pass the message on to DHCP servers not on
physical subnet. 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 21 skipping to change at page 7, line 22
the client receives neither a DHCPACK nor 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 nor a DHCPNAK message after employing receives neither a DHCPACK nor a DHCPNAK message after
the retransmission algorithm, the client reverts to INIT employing the retransmission algorithm, the client reverts to
state and restarts the initialization process. The client INIT 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
obtained the lease, it MUST use the same 'client identifier' in obtained the lease, it MUST use the same 'client identifier' in
the DHCPRELEASE message. the DHCPRELEASE message.
skipping to change at page 8, line 21 skipping to change at page 8, line 18
The Rapid Commit option is used to signal the use of the two message The Rapid Commit option is used to signal the use of the two message
exchange for address assignment. The code for the Rapid Commit exchange for address assignment. The code for the Rapid Commit
Option has to be defined (TBD). The format of the option is: Option has to be defined (TBD). The format of the option is:
Code Len Code Len
+-----+-----+ +-----+-----+
| TBD | 0 | | TBD | 0 |
+-----+-----+ +-----+-----+
A client SHOULD include this option in a DHCPDISCOVER message A client MUST include this option in a DHCPDISCOVER message if
if the client is prepared to perform the DHCPDISCOVER-DHCPACK the client is prepared to perform the DHCPDISCOVER-DHCPACK
message exchange described earlier. message exchange described earlier.
A server MUST include this option in a DHCPACK message sent in A server MUST include this option in a DHCPACK message sent in
a response to a DHCPDISCOVER message when completing the a response to a DHCPDISCOVER message when completing the
DHCPDISCOVER-DHCPACK message exchange. DHCPDISCOVER-DHCPACK message exchange.
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign a value for the Rapid Commit option code IANA is requested to assign a value for the Rapid Commit option code
in accordance with [RFC 2939]. in accordance with [RFC 2939].
skipping to change at page 10, line 10 skipping to change at page 10, line 10
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 Mobile Platform Laboratory
Samsung Electronics Samsung Electronics
Korea 416, Maetan-3dong, Yeongtong-Gu
Suwon, 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 Mobile Platform Laboratory
Samsung Electronics Samsung Electronics
Korea 416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea
Phone: +82-31-200-4635 Phone: +82-31-200-4635
Email: kimps@samsung.com Email: kimps@samsung.com
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusette Ave. 1414 Massachusette Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1-978-936-0382 Phone: +1-978-936-0382
EMail: volz@cisco.com EMail: volz@cisco.com
9. Acknowledgements 9. Acknowledgements
Special thanks to Ted Lemon and Andre Kostur for their many Special thanks to Ted Lemon and Andre Kostur for their many
valuable comments. Thanks to Ralph Droms for his review comments valuable comments. Thanks to Ralph Droms for his review comments
during WGLC. during WGLC. Thanks to Youngkeun Kim for his support on this work.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). 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.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 End of changes. 

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