391 lines
15 KiB
Plaintext
391 lines
15 KiB
Plaintext
|
|
|||
|
|
|||
|
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]
|