Network Working Group R. Elz Internet Draft University of Melbourne Expiration Date: September 1999 March 1999 The Process of Renumbering draft-ietf-ipngwg-renum-process-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Note that the first paragraph of this section is a meaningless bureaucratic requirement of the IESG. It is provided so as to satisfy those bureaucratic requirements, and serves no other purpose whatever. Information as to any intellectual property rights, beyond the right to redistribute this document and make use of it for the purposes of an internet draft, should be sought in other parts of this document. This entire section has been prepended to this document automatically during formatting without any direct involvement by the author(s) of this draft. No assumption should be made that the authors have assented to any of it. Elz [Expires September 1999] [Page 1] Internet Draft draft-ietf-ipngwg-renum-process-00.txt March 1999 Abstract This document discusses the process of renumbering an Internet Node. While it is not protocol specific, as such, it is expected that some of the mechanisms proposed will never be defined, or deployed, for IPv4. Hence this may serve mostly as a template mechanism for the process of renumbering an IPv6 site. 1. Introduction Much has been written [...] on the subject of renumbering a site, and its difficulties. This document does not consider that issue, and assumes that the results of the lessons learned from those experiences, and the benefits of IPv6 including stateless autoconfiguration via neighbour discovery [] and router renumbering [] will make the task of renumbering a site, internally, a tractable problem. However, of itself, this is insufficient to fully complete a renumbering task. Aside from the site itself, there is the problem of others, typically unknown to the site itself, who have knowledge of its old address, and need to be informed of any address changes and then make the necessary updates. This document describes the a series of steps which, if followed, will permit all parties on the internet with a need to know of address changes to detect the change, and update their knowledge, in such a way that the address change can be made gracefully. 2. The Steps The overall process of renumbering can be described by the following sequence of events: [1] Someone/something determines that a new set of addresses will be needed for some set of hosts/nets. The details of how, and by whom, this decision is made are beyond the scope of this document. [2] That info is communicated to the owner of (the net admin, human or otherwise, of) the set of hosts involved. Whether this is automated via some protocol or other, or is done via more mundane method, is not important here. [3] Some kind of DNS (or some kind of database) entry is updated showing the new set of addresses as additional addresses for the entity involved. This dadatase does not yet exists. Its creation seems to be necesary for orderly Elz [Expires September 1999] [Page 2] Internet Draft draft-ietf-ipngwg-renum-process-00.txt March 1999 renumbering. [4] Routers and other filter lists (etc) are updated to make the new addresses equivalent to the old ones (all around the internet, not just at the entity being renumbered.) This presumes that the routers, or the manager or configuration system that configures the routers, use keys into the database postulated in the previous step when configuring references to address spaces, and translate those to the corresponding numeric values as needed, along with "time to live" values to cause regular retranslation of the keys to address values. [5] The new addresses are distributed to the hosts/routers that are being renumbered. The precise mechanism by which this is accomplished is unimportant here, however it seems likely that [Router-renum] might be used to distribute the new addresses to routers, followed by appropriate Router Advertisments [RFCmmm] to distribute the new addresses to the hosts. The old addresses should be marked as deprecated at the same time. This will cause those hosts to start originating connections from the new addresses one assumes. [6] The DNS is updated with the new addresses for the things that have been renumbered. This will gradually cause incoming connections to start using the new addresses as new translations of names to addresses are done, and the old cached address values gradually disappear. [7] The old addresses are removed from the DNS so no new connections will be initiated to the old addresses. [8] The old addresses are withdrawn from RA adverts, so the renumbered hosts stop accepting and using them. [9] The database mentioned in 3 is updated to remove the old addresses from the list of addresses belonging to the entity that has been renumbered. [10] Step 4 naturally repeats as time to lives expire, with the translation of keys to addresses now using only the new addreses. [11] The address block that is no longer in use is returned to the free pool and is thus now available for assignment elsewhere. Elz [Expires September 1999] [Page 3] Internet Draft draft-ietf-ipngwg-renum-process-00.txt March 1999 3. Time Lines The steps of the previous section must be completed in order. However, some require delays to allow proper propogation of changed information around the internet. The database mentioned in step 3 needs to associate a time to live with each value. Then steps 4 and 10 need to be given at least that time to complete. Note that if the DNS implements the database, the relevant time for steps 4 and 10 is the sum of the TTL field of the DNS for the resource records used, and the zone propogation time from primary server to secondary servers, as set in the Start of Authority resource record. Typically an implementation of this scheme would allow twice the expected necessary delay. The delay required at step 5 will depend upon the size of the part of the network being renumbered. As this is entirely confined to the site being renumbered, it can determine when it has finished. Step 6 can proceed concurrently with step 5, to the extent that as each node gains its new addreses it can immediately enter them in the DNS. This permits the use of techniques like [DynDNS] to allow DNS updates to be performed by the renumbered hosts. Similarly, step 7 can proceed concurrently with step 6, in that old addresses can be deleted from the DNS as the new ones are added, if desired. After the last DNS update of step 7 is made, that is, the last of the old addresses is deleted from the DNS, the minimum delay before step 8 is the DNS zone propogation and cache TTL delay. Typically a much longer delay will occur at this point to allow connections already established to remain operational. Until the connection identifiers are separated frin the addresses, or a mechanism is created to allow the connection identifiers to be altered during the life of a connection, a considerable delay is likely to be required here. In gthe worst cases this delay could amount to months, or even years. Of course, it will be bounded by the period during which the old addresses will be permitted to remain. When that time expires, and assuming the additional mechanism does not exist, old connections will simply have to be broken. Step 8 is essentially a repeat of step 4, and should take an equivalent period. Similarly, step 9 uses the same procedures as step 5. As soon as step 11 is completed, the whole procedure has finished. Elz [Expires September 1999] [Page 4] Internet Draft draft-ietf-ipngwg-renum-process-00.txt March 1999 4. Requirements 5. Security Considerations 6. Example 7. References Authors' Addresses Elz [Expires September 1999] [Page 5]