INTERNET-DRAFT Lowell Gilbert DHC Working Group Epilogue Technology Corporation Network Area April 1996 Expires October 1996 Graceful renumbering of networks with DHCP 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]