datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

DHCP reconfigure extension
RFC 3203

Document type: RFC - Proposed Standard (December 2001)
Updated by RFC 6704
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 3203 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                         Y. T'Joens
Request for Comments: 3203                                     C. Hublet
Category: Standards Track                                        Alcatel
                                                         P. De Schrijver
                                                                    Mind
                                                           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.

Abstract

   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   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

[include full document text]