idnits 2.17.1 draft-ietf-ipngwg-renum-process-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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. 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 (March 1999) is 9173 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) -- Missing reference section? '1' on line 79 looks like a reference -- Missing reference section? '2' on line 84 looks like a reference -- Missing reference section? '3' on line 89 looks like a reference -- Missing reference section? '4' on line 95 looks like a reference -- Missing reference section? '5' on line 106 looks like a reference -- Missing reference section? 'Router-renum' on line 109 looks like a reference -- Missing reference section? 'RFCmmm' on line 111 looks like a reference -- Missing reference section? '6' on line 117 looks like a reference -- Missing reference section? '7' on line 123 looks like a reference -- Missing reference section? '8' on line 126 looks like a reference -- Missing reference section? '9' on line 129 looks like a reference -- Missing reference section? '10' on line 133 looks like a reference -- Missing reference section? '11' on line 137 looks like a reference -- Missing reference section? 'DynDNS' on line 162 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Elz 3 Internet Draft University of Melbourne 4 Expiration Date: September 1999 5 March 1999 7 The Process of Renumbering 9 draft-ietf-ipngwg-renum-process-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Note that the first paragraph of this section is a meaningless 33 bureaucratic requirement of the IESG. It is provided so as to 34 satisfy those bureaucratic requirements, and serves no other purpose 35 whatever. Information as to any intellectual property rights, beyond 36 the right to redistribute this document and make use of it for the 37 purposes of an internet draft, should be sought in other parts of 38 this document. 40 This entire section has been prepended to this document automatically 41 during formatting without any direct involvement by the author(s) of 42 this draft. No assumption should be made that the authors have 43 assented to any of it. 45 Abstract 47 This document discusses the process of renumbering an Internet Node. 48 While it is not protocol specific, as such, it is expected that some 49 of the mechanisms proposed will never be defined, or deployed, for 50 IPv4. Hence this may serve mostly as a template mechanism for the 51 process of renumbering an IPv6 site. 53 1. Introduction 55 Much has been written [...] on the subject of renumbering a site, and 56 its difficulties. This document does not consider that issue, and 57 assumes that the results of the lessons learned from those 58 experiences, and the benefits of IPv6 including stateless 59 autoconfiguration via neighbour discovery [] and router renumbering 60 [] will make the task of renumbering a site, internally, a tractable 61 problem. 63 However, of itself, this is insufficient to fully complete a 64 renumbering task. Aside from the site itself, there is the problem 65 of others, typically unknown to the site itself, who have knowledge 66 of its old address, and need to be informed of any address changes 67 and then make the necessary updates. 69 This document describes the a series of steps which, if followed, 70 will permit all parties on the internet with a need to know of 71 address changes to detect the change, and update their knowledge, in 72 such a way that the address change can be made gracefully. 74 2. The Steps 76 The overall process of renumbering can be described by the following 77 sequence of events: 79 [1] Someone/something determines that a new set of addresses 80 will be needed for some set of hosts/nets. The details of 81 how, and by whom, this decision is made are beyond the 82 scope of this document. 84 [2] That info is communicated to the owner of (the net admin, 85 human or otherwise, of) the set of hosts involved. 86 Whether this is automated via some protocol or other, or 87 is done via more mundane method, is not important here. 89 [3] Some kind of DNS (or some kind of database) entry is 90 updated showing the new set of addresses as additional 91 addresses for the entity involved. This dadatase does not 92 yet exists. Its creation seems to be necesary for orderly 93 renumbering. 95 [4] Routers and other filter lists (etc) are updated to make 96 the new addresses equivalent to the old ones (all around 97 the internet, not just at the entity being renumbered.) 98 This presumes that the routers, or the manager or 99 configuration system that configures the routers, use keys 100 into the database postulated in the previous step when 101 configuring references to address spaces, and translate 102 those to the corresponding numeric values as needed, along 103 with "time to live" values to cause regular retranslation 104 of the keys to address values. 106 [5] The new addresses are distributed to the hosts/routers 107 that are being renumbered. The precise mechanism by which 108 this is accomplished is unimportant here, however it seems 109 likely that [Router-renum] might be used to distribute the 110 new addresses to routers, followed by appropriate Router 111 Advertisments [RFCmmm] to distribute the new addresses to 112 the hosts. The old addresses should be marked as 113 deprecated at the same time. This will cause those hosts 114 to start originating connections from the new addresses 115 one assumes. 117 [6] The DNS is updated with the new addresses for the things 118 that have been renumbered. This will gradually cause 119 incoming connections to start using the new addresses as 120 new translations of names to addresses are done, and the 121 old cached address values gradually disappear. 123 [7] The old addresses are removed from the DNS so no new 124 connections will be initiated to the old addresses. 126 [8] The old addresses are withdrawn from RA adverts, so the 127 renumbered hosts stop accepting and using them. 129 [9] The database mentioned in 3 is updated to remove the old 130 addresses from the list of addresses belonging to the 131 entity that has been renumbered. 133 [10] Step 4 naturally repeats as time to lives expire, with the 134 translation of keys to addresses now using only the new 135 addreses. 137 [11] The address block that is no longer in use is returned to 138 the free pool and is thus now available for assignment 139 elsewhere. 141 3. Time Lines 143 The steps of the previous section must be completed in order. 144 However, some require delays to allow proper propogation of changed 145 information around the internet. 147 The database mentioned in step 3 needs to associate a time to live 148 with each value. Then steps 4 and 10 need to be given at least that 149 time to complete. Note that if the DNS implements the database, the 150 relevant time for steps 4 and 10 is the sum of the TTL field of the 151 DNS for the resource records used, and the zone propogation time from 152 primary server to secondary servers, as set in the Start of Authority 153 resource record. Typically an implementation of this scheme would 154 allow twice the expected necessary delay. 156 The delay required at step 5 will depend upon the size of the part of 157 the network being renumbered. As this is entirely confined to the 158 site being renumbered, it can determine when it has finished. 160 Step 6 can proceed concurrently with step 5, to the extent that as 161 each node gains its new addreses it can immediately enter them in the 162 DNS. This permits the use of techniques like [DynDNS] to allow DNS 163 updates to be performed by the renumbered hosts. 165 Similarly, step 7 can proceed concurrently with step 6, in that old 166 addresses can be deleted from the DNS as the new ones are added, if 167 desired. After the last DNS update of step 7 is made, that is, the 168 last of the old addresses is deleted from the DNS, the minimum delay 169 before step 8 is the DNS zone propogation and cache TTL delay. 170 Typically a much longer delay will occur at this point to allow 171 connections already established to remain operational. Until the 172 connection identifiers are separated frin the addresses, or a 173 mechanism is created to allow the connection identifiers to be 174 altered during the life of a connection, a considerable delay is 175 likely to be required here. In gthe worst cases this delay could 176 amount to months, or even years. Of course, it will be bounded by 177 the period during which the old addresses will be permitted to 178 remain. When that time expires, and assuming the additional 179 mechanism does not exist, old connections will simply have to be 180 broken. 182 Step 8 is essentially a repeat of step 4, and should take an 183 equivalent period. Similarly, step 9 uses the same procedures as 184 step 5. 186 As soon as step 11 is completed, the whole procedure has finished. 188 4. Requirements 190 5. Security Considerations 192 6. Example 194 7. References 196 Authors' Addresses