DHCP reconfigure extension
RFC 3203

Document Type RFC - Proposed Standard (December 2001; No errata)
Updated by RFC 6704
Authors Yves T'Joens  , Peter De Schrijver  , Christian Hublet 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3203 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         Y. T'Joens
Request for Comments: 3203                                     C. Hublet
Category: Standards Track                                        Alcatel
                                                         P. De Schrijver
                                                           December 2001

                       DHCP reconfigure extension

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 (2001).  All Rights Reserved.


   This document defines extensions to DHCP (Dynamic Host Configuration
   Protocol) to allow dynamic reconfiguration of a single host triggered
   by the DHCP server (e.g., a new IP address and/or local configuration
   parameters).  This is achieved by introducing a unicast FORCERENEW
   message which forces the client to the RENEW state.  The behaviour
   for hosts using the DHCP INFORM message to obtain configuration
   information is also described.

1. Introduction

   The procedures as described within this document allow the dynamic
   reconfiguration of individual hosts.

1.1 Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2. DHCP force renew

   This section describes the FORCERENEW message extension.

T'Joens, et al.             Standards Track                     [Page 1]
RFC 3203               DHCP reconfigure extension          December 2001

2.1 Terminology

   DHCP client : host to be reconfigured using DHCP.

   DHCP server : server which configured the DHCP client.

2.2 Force renew procedures

   The DHCP server sends a unicast FORCERENEW message to the client.
   Upon receipt of the unicast FORCERENEW message, the client will
   change its state to the RENEW state, and will then try to renew its
   lease according to normal DHCP procedures.  If the server wants to
   assign a new IP address to the client, it will reply to the DHCP
   REQUEST with a DHCP NAK.  The client will then go back to the init
   state and broadcast a DHCP DISCOVER message.  The server can now
   assign a new IP address to the client by replying with a DHCP OFFER.
   If the FORCERENEW message is lost, the DHCP server will not receive a
   DHCP REQUEST from the client and it should retransmit the FORCERENEW
   message using an exponential backoff algorithm.  Depending on the
   bandwidth of the network between server and client, the server should
   choose a delay.  This delay grows exponentially as retransmissions
   fail.  The amount of retransmissions should be limited.

   The procedures described above assume the server to send a unicast
   FORCERENEW message to the client.  Receipt of a multicast FORCERENEW
   message by the client should be silently discarded.

   It can be that a client has obtained a network address through some
   other means (e.g., manual configuration) and has used a DHCP INFORM
   request to obtain other local configuration parameters.  Such clients
   should respond to the receipt of a unicast FORCERENEW message with a
   new DHCP INFORM request so as to obtain a potential new set of local
   configuration parameters.  Note that the usage of these procedures
   are limited to the set of options that are eligible for configuration
   by DHCP and should not override manually configured parameters.

   Note further that usage of the FORCERENEW message to reconfigure a
   client address or local configuration parameters can lead to the
   interruption of active sessions, and that as such these  procedures
   should be used in controlled circumstances.

T'Joens, et al.             Standards Track                     [Page 2]
RFC 3203               DHCP reconfigure extension          December 2001

2.3 Example usage

2.3.1 Embedded DHCP clients

   The autoconfiguration of home gateways (more generically Network
   Termination equipment) for public networking purposes can be achieved
   through means of DHCP, as described in [DSL_autoconf].  In order to
   allow service changes or service interruption, the FORCERENEW message
   can trigger the home gateway to contact the DHCP server, prior to the
   expiry of the lease.

2.3.2 Hospitality service scenario

   In self provisioned networks, e.g., hotel rooms, the hotel owned DHCP
   server can hand out limited use IP addresses, that allows the
   customer to consume local services or select external services from a
Show full document text