datatracker.ietf.org
Sign in
Version 5.7.4, 2014-11-12
Report a bug

Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
RFC 4039

Document type: RFC - Proposed Standard (March 2005; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4039 (Proposed Standard)
Responsible AD: Margaret Wasserman
Send notices to: rdroms@cisco.com, soohong.park@samsung.com, kimps@samsung.com, volz@cisco.com

Network Working Group                                            S. Park
Request for Comments: 4039                                        P. Kim
Category: Standards Track                            SAMSUNG Electronics
                                                                 B. Volz
                                                           Cisco Systems
                                                              March 2005

                      Rapid Commit Option for the
         Dynamic Host Configuration Protocol version 4 (DHCPv4)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a new Dynamic Host Configuration Protocol
   version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option,
   for obtaining IP address and configuration information using a
   2-message exchange rather than the usual 4-message exchange,
   expediting client configuration.

Table of Contents

   1. Introduction...................................................  2
   2. Requirements...................................................  2
   3. Client/Server Operations.......................................  2
      3.1.  Detailed Flow............................................  3
      3.2.  Administrative Considerations............................  6
   4. Rapid Commit Option Format.....................................  7
   5. IANA Considerations............................................  7
   6. Security Considerations........................................  7
   7. References.....................................................  7
      7.1.  Normative References.....................................  7
      7.2.  Informative References...................................  8
   8. Acknowledgements...............................................  8
   Authors' Addresses................................................  9
   Full Copyright Statement.......................................... 10

Park, et al.                Standards Track                     [Page 1]
RFC 4039             Rapid Commit Option for DHCPv4           March 2005

1.  Introduction

   In some environments, such as those in which high mobility occurs and
   the network attachment point changes frequently, it is beneficial to
   rapidly configure clients.  And, in these environments it is possible
   to more quickly configure clients because the protections offered by
   the normal (and longer) 4-message exchange may not be needed.  The
   4-message exchange allows for redundancy (multiple DHCP servers)
   without wasting addresses, as addresses are only provisionally
   assigned to a client until the client chooses and requests one of the
   provisionally assigned addresses.  The 2-message exchange may
   therefore be used when only one server is present or when addresses
   are plentiful and having multiple servers commit addresses for a
   client is not a problem.

   This document defines a new Rapid Commit option for DHCPv4, modeled
   on the DHCPv6 Rapid Commit option [RFC3315], which can be used to
   initiate a 2-message exchange to expedite client configuration in
   some environments.  A client advertises its support of this option by
   sending it in DHCPDISCOVER messages.  A server then determines
   whether to allow the 2-message exchange based on its configuration
   information and can either handle the DHCPDISCOVER as defined in
   [RFC2131] or commit the client's configuration information and
   advance to sending a DHCPACK message with the Rapid Commit option as
   defined herein.

2.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

3.  Client/Server Operations

   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 it
   in any other messages.  A client and server only use this option when
   configured to do so.

   A client that sent a DHCPDISCOVER with Rapid Commit option processes
   responses as described in [RFC2131].  However, if the client receives
   a DHCPACK message with a Rapid Commit option, it SHOULD process the
   DHCPACK immediately (without waiting for additional DHCPOFFER or

[include full document text]