[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                            Lowell Gilbert
DHC Working Group                        Epilogue Technology Corporation
Network Area                                                  April 1996
                                                    Expires October 1996


               Graceful renumbering of networks with DHCP
                  <draft-ietf-dhc-renumbering-00.txt>

Status of this memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This document proposes a method for improving the ability of the
   Dynamic Host Configuration Protocol (DHCP) to assist in renumbering
   an internet.  DHCP is already capable of supporting host renumbering
   by assigning a new address when a client attempts to renegotiate an
   existing lease, but this proposal makes host renumbering more
   graceful by providing for a transition period in which the client can
   use both addresses.







Gilbert                                                         [Page 1]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


Introduction

   This document proposes a method for improving the ability of the
   Dynamic Host Configuration Protocol (DHCP) to assist in renumbering an
   internet.  DHCP is already capable of supporting host renumbering by
   assigning a new address when a client attempts to renegotiate an
   existing lease, but this proposal makes host renumbering more graceful
   by providing for a transition period in which the client can use both
   addresses.  This enables the client to avoid disruption of existing
   communications that may have already bound themselves to the original
   address. This also enables the client to avoid disruption of new
   communications (when the existing address would no longer be valid) by
   ensuring they are bound to the new address.

   This proposal adds to the core DHC protocol a mechanism by which a
   DHCP client may acquire an additional IP address to eventually replace
   one already in use.  A new option is defined for the server to start
   this process in the client.  Significant modifications to the
   protocol's state machine are avoided by starting up a whole new state
   machine for handling the new address.


Motivations

   Host addresses may need to change for a number of reasons. For
   example, if the address assignment scheme is based on CIDR
   guidelines, when a site changes its provider hosts within the site
   may need to change their addresses.

   The intention of the mechanism described here is to allow system
   administrators to specify a graceful transition period during
   renumbering to minimize disruption caused by address changes,
   particularly for hosts for which continuous availability is an
   important factor.










Gilbert                                                         [Page 2]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


Document Independence

   The most important point to note about this proposal is that it can
   be issued as a separate document from the protocol specification.
   There are three factors that make this practical:

     * the graceful renumbering support is optional,

     * the graceful renumbering support will be completely impossible
       for some existing platforms (i.e. those which aren't capable of
       having multiple addresses at one time anyway),

     * the graceful renumbering support doesn't in any way affect the
       operation of hosts or servers that don't implement it.
       Therefore, there's no good reason that it can't be split out on
       its own, to progress on its own (separate) merits.


Design Goals

     * full backward compatibility with DHCP implementations compliant
       with RFC1541.  This is essential for acceptance of new
       implementations with the new functionality.

     * no changes to relay agents.  This is the key to the general DHCP
       migration strategy.  The simpler a relay agent is, the more
       likely it is to be included in other network devices.

     * minimal impact upon the standards status (and advancement) of the
       base DHCP protocol.  Acceptance of the core protocol is a
       prerequisite for acceptance of this one.


Terminology:


   Use of the terms MUST, SHOULD, or SHOULD NOT in this document implies
   the usual meanings with respect to implementing this specification.
   However, none of this specification need be implemented for an
   implementation to be considered compliant with DHCP (for which
   compliance with RFC 1541 is necessary and sufficient).



Gilbert                                                         [Page 3]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


Requirements

   This proposal requires that any client be capable of binding more
   than one address to an interface at a time, and also that the client
   be able to distinguish among these addresses for the purpose of
   binding existing and new transport connections.  It also requires
   that any server be able to track multiple bindings per client.  If
   these requirements cannot be met, then the host in question can still
   implement DHCP, but won't be able to implement graceful renumbering
   support.

   A new option (the "renumbering" option) is defined for use in DHCPACK
   and DHCPDISCOVER messages.  The length of this option is 4 octets.
   The presence of this option in a DHCPACK indicates that the client
   should initialize a new DHCP state machine for a new address.  The
   option shall contain a "magic cookie" value which the server can use
   in tracking requests for new addresses; the client MUST NOT attempt
   to interpret the value.

   This proposal assumes that a DHCP Server would have to be configured
   with the new (post-renumbering) addresses, prior to the
   reconfiguration of any of the Relay Agents that point to that Server.
   Once the Server is configured with the new addresses, the Relay
   Agents that point to that server could be reconfigured on their own,
   without requiring any coordination with the Server. Under those
   conditions, this proposal can accommodate a situation where a client
   would receive a DHCPACK with the "renumbering" option, but the Relay
   Agent that serves the client would not be configured (yet) with a new
   (post-renumbering) address.


Protocol Summary


   A renumbering option in a DHCPACK packet requests the client to begin
   trying to get a post-renumbering address.  The post-renumbering
   address has its own DHCP state machine, which runs in parallel with
   the one for the pre-renumbering address (with both addresses active
   on the interface) until the lease runs out on the pre-renumbering
   address.  Then the original state machine dies a quiet death.




Gilbert                                                         [Page 4]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


Client behaviour


   When a client receives the renumbering option in a DHCPACK packet, it
   MUST immediately initialize a new state machine for handling the new
   address.  The old state machine SHOULD NOT attempt to renegotiate the
   lease after this point, and may terminate at any time thereafter, up
   to and including the termination of the lease.  When the lease
   expires, the client MUST stop using that address and SHOULD release
   all resources related to that address.

   When the new state machine is initialized, it starts in the INIT
   state.  Once it starts, it is responsible for acquiring a post-
   renumbering address and keeping this address on the interface; the
   responsibilities of the old state machine are now limited to deciding
   when to terminate.

   The renumbering option MUST be returned in the client's DHCPINIT
   message exactly as it was included in the DHCPACK message.  The state
   machine then proceeds as normal, completely separate from the
   original state machine.  When it receives a DHCPACK (for the *new*
   address), it SHOULD, if possible, arrange that the new address will
   be the address used by default on that particular interface.  This
   means that any new transport connections should be bound to the new
   address, and that datagram protocols should switch to the new address
   as soon as practical.


   When a client receives the renumbering option in a DHCPACK packet,
   the client does the following:

      (1) If the received DHCPACK packet causes the DHCP state machine
      transition from Requesting to Bound state, then the client checks
      whether it has another DHCP state machine. If such a machine
      exists, then the client sends a DHCPRELEASE on the new machine,
      and terminates the new machine. The old machine continues to
      operate according to the normal DHCP operations.  If no such (old)
      machine exists, then the new machine starts to operate according
      to the normal DHCP operations.

      (2) If the DHCPACK packet is received when the state machine is



Gilbert                                                         [Page 5]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


      already in Bound, or Renewing, or Rebinding state, then the client
      marks the state machine as "deprecated" and immediately initiates
      another state machine. When the new state machine is initialized,
      it starts in the INIT state.  The renumbering option MUST be
      returned in the client's DHCPINIT message exactly as it was
      included in the DHCPACK message.  The state machine then proceeds
      as normal, completely separate from the original state machine.
      Once the new state machine starts, it attempts to acquire a post-
      renumbering address. If the attempt is successful, the client
      assigns this address on the interface; the responsibilities of the
      old state machine at that point would become limited to deciding
      when to terminate.

   When a client receives a DHCPACK packet without the renumbering
   option the client does the following:

      (1) If the received DHCPACK causes the DHCP state machine to
      transition into the Bound state, the client checks if it has
      another state machine which is marked as "deprecated". If yes,
      then the client SHOULD start using the newly acquired address for
      all the new transport connections, and that datagram protocols
      SHOULD switch to the new address as soon as practical.  The
      existing connections are still bound to the old address (the
      address associated with the "deprecated" state machine). The
      "deprecated" machine SHOULD NOT attempt to renegotiate the lease
      after this point, and may terminate at any time thereafter, up to
      and including the termination of the lease. When the lease on the
      address associated with the "deprecated" state machine expires,
      the client MUST stop using that address and SHOULD release all
      resources related to that address.

      (2) In all other cases the client follows the standard DHCP
      procedures.



Server behaviour


   As part of its database of addresses, a DHCP server MUST maintain
   state information for every address (or block of addresses)



Gilbert                                                         [Page 6]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


   indicating whether that address is deprecated.  When a DHCPREQUEST
   arrives, the server MUST check this state information.

   If the address being requested is not deprecated, the server
   continues as provided in RFC 1541.  If, however, the address has been
   deprecated the server prepares a DHCPACK using the remainder of the
   available lease time, and in addition adds a renumbering option.  The
   method of choosing a value for the renumbering option is an
   implentation decision.  The server should be prepared to handle
   further negotiations on the deprecated address, even though the
   client is expected to stop such negotiations once it attempts to
   acquire a replacement address.

   If the server has no post-renumbering addresses available to offer to
   the client, it SHOULD offer the previous, deprecated address, in
   order to signal the problem to the client.



Relay Agent behaviour


   The only requirement that this proposal places on relay agents is
   that they MUST place a "new" (i.e., post-renumbering) address for
   itself in the 'giaddr' field when passing on a DHCP message.  Since
   this can, in the worst case, be accomplished by hand-configuration,
   modifications to relay agent software are not absolutely necessary.



Discussion


   The option's cookie can be used for anything that the server wants.
   Two obvious possibilities are that it could be common across the
   whole renumbering, and that it could represent a binding to a
   particular client.  Because the client's new state machine starts in
   INIT, the server will be able to gather subnet information from the
   broadcast DHCPDISCOVER.

   The idea behind using a new option to tell the client to initiate



Gilbert                                                         [Page 7]


DRAFT          Graceful renumbering of networks with DHCP     April 1996


   this process is that it avoids all of the problems that I saw in
   (Yakov Rekhter's) original version of this proposal.  Those had to do
   with figuring out when to shut down a new state machine, and with the
   extra traffic from sending an extra DHCPDISCOVER every time you went
   back into the BOUND state.


Acknowledgements


   This document owes a great deal to Yakov Rekhter's initial
   suggestions on the same subject.  Input from both him and Ralph Droms
   had significant further effect on the document.


References


     [1]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
          Bucknell University, October 1993.

Security Considerations


   Security issues are not discussed in this document.

Author's Address

   Lowell Gilbert
   Lowell@Epilogue.Com














Gilbert                                                         [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/