idnits 2.17.1 draft-ietf-dhc-renumbering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '...Use of the terms MUST, SHOULD, or SHOU...' RFC 2119 keyword, line 127: '...addresses; the client MUST NOT attempt...' RFC 2119 keyword, line 153: '... MUST immediately initialize a new s...' RFC 2119 keyword, line 154: '...ld state machine SHOULD NOT attempt to...' RFC 2119 keyword, line 157: '...ires, the client MUST stop using that ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1996) is 10049 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 276, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1531 (ref. '1') (Obsoleted by RFC 1541) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Lowell Gilbert 3 DHC Working Group Epilogue Technology Corporation 4 Network Area April 1996 5 Expires October 1996 7 Graceful renumbering of networks with DHCP 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document proposes a method for improving the ability of the 31 Dynamic Host Configuration Protocol (DHCP) to assist in renumbering 32 an internet. DHCP is already capable of supporting host renumbering 33 by assigning a new address when a client attempts to renegotiate an 34 existing lease, but this proposal makes host renumbering more 35 graceful by providing for a transition period in which the client can 36 use both addresses. 38 Introduction 40 This document proposes a method for improving the ability of the 41 Dynamic Host Configuration Protocol (DHCP) to assist in renumbering an 42 internet. DHCP is already capable of supporting host renumbering by 43 assigning a new address when a client attempts to renegotiate an 44 existing lease, but this proposal makes host renumbering more graceful 45 by providing for a transition period in which the client can use both 46 addresses. This enables the client to avoid disruption of existing 47 communications that may have already bound themselves to the original 48 address. This also enables the client to avoid disruption of new 49 communications (when the existing address would no longer be valid) by 50 ensuring they are bound to the new address. 52 This proposal adds to the core DHC protocol a mechanism by which a 53 DHCP client may acquire an additional IP address to eventually replace 54 one already in use. A new option is defined for the server to start 55 this process in the client. Significant modifications to the 56 protocol's state machine are avoided by starting up a whole new state 57 machine for handling the new address. 59 Motivations 61 Host addresses may need to change for a number of reasons. For 62 example, if the address assignment scheme is based on CIDR 63 guidelines, when a site changes its provider hosts within the site 64 may need to change their addresses. 66 The intention of the mechanism described here is to allow system 67 administrators to specify a graceful transition period during 68 renumbering to minimize disruption caused by address changes, 69 particularly for hosts for which continuous availability is an 70 important factor. 72 Document Independence 74 The most important point to note about this proposal is that it can 75 be issued as a separate document from the protocol specification. 76 There are three factors that make this practical: 78 * the graceful renumbering support is optional, 80 * the graceful renumbering support will be completely impossible 81 for some existing platforms (i.e. those which aren't capable of 82 having multiple addresses at one time anyway), 84 * the graceful renumbering support doesn't in any way affect the 85 operation of hosts or servers that don't implement it. 86 Therefore, there's no good reason that it can't be split out on 87 its own, to progress on its own (separate) merits. 89 Design Goals 91 * full backward compatibility with DHCP implementations compliant 92 with RFC1541. This is essential for acceptance of new 93 implementations with the new functionality. 95 * no changes to relay agents. This is the key to the general DHCP 96 migration strategy. The simpler a relay agent is, the more 97 likely it is to be included in other network devices. 99 * minimal impact upon the standards status (and advancement) of the 100 base DHCP protocol. Acceptance of the core protocol is a 101 prerequisite for acceptance of this one. 103 Terminology: 105 Use of the terms MUST, SHOULD, or SHOULD NOT in this document implies 106 the usual meanings with respect to implementing this specification. 107 However, none of this specification need be implemented for an 108 implementation to be considered compliant with DHCP (for which 109 compliance with RFC 1541 is necessary and sufficient). 111 Requirements 113 This proposal requires that any client be capable of binding more 114 than one address to an interface at a time, and also that the client 115 be able to distinguish among these addresses for the purpose of 116 binding existing and new transport connections. It also requires 117 that any server be able to track multiple bindings per client. If 118 these requirements cannot be met, then the host in question can still 119 implement DHCP, but won't be able to implement graceful renumbering 120 support. 122 A new option (the "renumbering" option) is defined for use in DHCPACK 123 and DHCPDISCOVER messages. The length of this option is 4 octets. 124 The presence of this option in a DHCPACK indicates that the client 125 should initialize a new DHCP state machine for a new address. The 126 option shall contain a "magic cookie" value which the server can use 127 in tracking requests for new addresses; the client MUST NOT attempt 128 to interpret the value. 130 This proposal assumes that a DHCP Server would have to be configured 131 with the new (post-renumbering) addresses, prior to the 132 reconfiguration of any of the Relay Agents that point to that Server. 133 Once the Server is configured with the new addresses, the Relay 134 Agents that point to that server could be reconfigured on their own, 135 without requiring any coordination with the Server. Under those 136 conditions, this proposal can accommodate a situation where a client 137 would receive a DHCPACK with the "renumbering" option, but the Relay 138 Agent that serves the client would not be configured (yet) with a new 139 (post-renumbering) address. 141 Protocol Summary 143 A renumbering option in a DHCPACK packet requests the client to begin 144 trying to get a post-renumbering address. The post-renumbering 145 address has its own DHCP state machine, which runs in parallel with 146 the one for the pre-renumbering address (with both addresses active 147 on the interface) until the lease runs out on the pre-renumbering 148 address. Then the original state machine dies a quiet death. 150 Client behaviour 152 When a client receives the renumbering option in a DHCPACK packet, it 153 MUST immediately initialize a new state machine for handling the new 154 address. The old state machine SHOULD NOT attempt to renegotiate the 155 lease after this point, and may terminate at any time thereafter, up 156 to and including the termination of the lease. When the lease 157 expires, the client MUST stop using that address and SHOULD release 158 all resources related to that address. 160 When the new state machine is initialized, it starts in the INIT 161 state. Once it starts, it is responsible for acquiring a post- 162 renumbering address and keeping this address on the interface; the 163 responsibilities of the old state machine are now limited to deciding 164 when to terminate. 166 The renumbering option MUST be returned in the client's DHCPINIT 167 message exactly as it was included in the DHCPACK message. The state 168 machine then proceeds as normal, completely separate from the 169 original state machine. When it receives a DHCPACK (for the *new* 170 address), it SHOULD, if possible, arrange that the new address will 171 be the address used by default on that particular interface. This 172 means that any new transport connections should be bound to the new 173 address, and that datagram protocols should switch to the new address 174 as soon as practical. 176 When a client receives the renumbering option in a DHCPACK packet, 177 the client does the following: 179 (1) If the received DHCPACK packet causes the DHCP state machine 180 transition from Requesting to Bound state, then the client checks 181 whether it has another DHCP state machine. If such a machine 182 exists, then the client sends a DHCPRELEASE on the new machine, 183 and terminates the new machine. The old machine continues to 184 operate according to the normal DHCP operations. If no such (old) 185 machine exists, then the new machine starts to operate according 186 to the normal DHCP operations. 188 (2) If the DHCPACK packet is received when the state machine is 189 already in Bound, or Renewing, or Rebinding state, then the client 190 marks the state machine as "deprecated" and immediately initiates 191 another state machine. When the new state machine is initialized, 192 it starts in the INIT state. The renumbering option MUST be 193 returned in the client's DHCPINIT message exactly as it was 194 included in the DHCPACK message. The state machine then proceeds 195 as normal, completely separate from the original state machine. 196 Once the new state machine starts, it attempts to acquire a post- 197 renumbering address. If the attempt is successful, the client 198 assigns this address on the interface; the responsibilities of the 199 old state machine at that point would become limited to deciding 200 when to terminate. 202 When a client receives a DHCPACK packet without the renumbering 203 option the client does the following: 205 (1) If the received DHCPACK causes the DHCP state machine to 206 transition into the Bound state, the client checks if it has 207 another state machine which is marked as "deprecated". If yes, 208 then the client SHOULD start using the newly acquired address for 209 all the new transport connections, and that datagram protocols 210 SHOULD switch to the new address as soon as practical. The 211 existing connections are still bound to the old address (the 212 address associated with the "deprecated" state machine). The 213 "deprecated" machine SHOULD NOT attempt to renegotiate the lease 214 after this point, and may terminate at any time thereafter, up to 215 and including the termination of the lease. When the lease on the 216 address associated with the "deprecated" state machine expires, 217 the client MUST stop using that address and SHOULD release all 218 resources related to that address. 220 (2) In all other cases the client follows the standard DHCP 221 procedures. 223 Server behaviour 225 As part of its database of addresses, a DHCP server MUST maintain 226 state information for every address (or block of addresses) 227 indicating whether that address is deprecated. When a DHCPREQUEST 228 arrives, the server MUST check this state information. 230 If the address being requested is not deprecated, the server 231 continues as provided in RFC 1541. If, however, the address has been 232 deprecated the server prepares a DHCPACK using the remainder of the 233 available lease time, and in addition adds a renumbering option. The 234 method of choosing a value for the renumbering option is an 235 implentation decision. The server should be prepared to handle 236 further negotiations on the deprecated address, even though the 237 client is expected to stop such negotiations once it attempts to 238 acquire a replacement address. 240 If the server has no post-renumbering addresses available to offer to 241 the client, it SHOULD offer the previous, deprecated address, in 242 order to signal the problem to the client. 244 Relay Agent behaviour 246 The only requirement that this proposal places on relay agents is 247 that they MUST place a "new" (i.e., post-renumbering) address for 248 itself in the 'giaddr' field when passing on a DHCP message. Since 249 this can, in the worst case, be accomplished by hand-configuration, 250 modifications to relay agent software are not absolutely necessary. 252 Discussion 254 The option's cookie can be used for anything that the server wants. 255 Two obvious possibilities are that it could be common across the 256 whole renumbering, and that it could represent a binding to a 257 particular client. Because the client's new state machine starts in 258 INIT, the server will be able to gather subnet information from the 259 broadcast DHCPDISCOVER. 261 The idea behind using a new option to tell the client to initiate 262 this process is that it avoids all of the problems that I saw in 263 (Yakov Rekhter's) original version of this proposal. Those had to do 264 with figuring out when to shut down a new state machine, and with the 265 extra traffic from sending an extra DHCPDISCOVER every time you went 266 back into the BOUND state. 268 Acknowledgements 270 This document owes a great deal to Yakov Rekhter's initial 271 suggestions on the same subject. Input from both him and Ralph Droms 272 had significant further effect on the document. 274 References 276 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, 277 Bucknell University, October 1993. 279 Security Considerations 281 Security issues are not discussed in this document. 283 Author's Address 285 Lowell Gilbert 286 Lowell@Epilogue.Com