idnits 2.17.1 draft-huitema-ipv6-renumber-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: ---------------------------------------------------------------------------- ** 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? == 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 20 instances of lines with control characters in the document. ** The abstract seems to contain references ([DISPRE], [RFC2462], [Bradner,1996], [RFC2894], [RFC1886], [RFC2874]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 12, 2001) is 8325 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? 'RFC2874' on line 315 looks like a reference -- Missing reference section? 'RFC1886' on line 318 looks like a reference -- Missing reference section? 'RFC2462' on line 321 looks like a reference -- Missing reference section? 'RFC2894' on line 324 looks like a reference -- Missing reference section? 'RFC 2462' on line 111 looks like a reference -- Missing reference section? 'DISPRE' on line 327 looks like a reference -- Missing reference section? 'Bradner' on line 283 looks like a reference -- Missing reference section? '1996' on line 283 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires January 12, 2002 July 12, 2001 5 IPv6 Site Renumbering 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 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 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 There has been recently a lot of the discussion in the IPNG, NGTRANS 31 and DNSEXT working group about the level at which IPv6 shall support 32 renumbering. A specific question is whether we need special support 33 in the DNS to enable renumbering, as specified in [RFC2874], or if 34 the simpler mechanisms specified in [RFC1886] are sufficient. In 35 order to organize the discussion, this memo presents a set of 36 realistic renumbering scenarios, discusses the possible frequency at 37 which such scenarios can be repeated, presents some tools that can 38 be used to organize the renumbering, and summarizes the operational 39 requirements that have to be met by any renumbering solution. 41 1 Introduction 43 There has been recently a lot of the discussion in the IPNG, NGTRANS 44 and DNSEXT working group about the level at which IPv6 shall support 45 renumbering. A specific question is whether we need special support 46 in the DNS to enable renumbering, as specified in [RFC2874], or if 47 the simpler mechanisms specified in [RFC1886] are sufficient. In 48 order to facilitate the discussion, this memo presents a set of 49 realistic renumbering scenarios, and then analyzes requirements and 50 potential solutions. 52 The purpose of the exercise is to evaluate how the current "IPv6 and 53 DNS toolbox" can be used to facilitate renumbering. In addition to 54 the two possible DNS formats mentioned above, the toolbox includes 55 "IPv6 Stateless Address Autoconfiguration" [RFC2462] and "Router 56 Renumbering for IPv6" [RFC2894]. We do not detail here the operation 57 of the DNS in each of the scenarios - this is left as an exercise 58 for the DNSEXT working group. 60 2 Description of the scenarios 62 In this version of the memo, the renumbering scenarios are broadly 63 sketched. For example, we say nothing of "static address filters" 64 used for QoS and security purposes; we may guess that these could be 65 updated as a side effect of router renumbering, but we would be 66 better off with a real specification. The purpose of the exercise, 67 however, is to provide five realistic renumbering scenarios. 69 2.1 Scenario 1, first connection 71 A site is currently isolated. The internal subnets have been 72 numbered using "site local" addresses. The site joins the IPv6 73 Internet. The site managers use "Router Renumbering for IPv6" 74 [RFC2894] to automatically inform the internal routers that they 75 should start advertising the new prefix. The hosts receive a router 76 advertisement and automatically create a global address as specified 77 in [RFC2462]. 79 Most sites will do this once. In many case, the first connection of 80 a site to the IPv6 Internet will be through a tunneling solution, 81 such as "6to4". For the purpose of the exercise, we will consider a 82 tunneled connection as just another connection, that happens to use 83 a virtual link instead of a dedicated interface. 85 2.2 Scenario 2, disconnection 87 A site is currently connected to the Internet. The site managers 88 plan to disconnect. This occurs in two phases, first deprecating the 89 old prefix, then removing it. Both phases are implemented using 90 "Router Renumbering for IPv6" [RFC2894] and "IPv6 Stateless Address 91 Autoconfiguration" [RFC2462]. 93 2.3 Scenario 3, multi-homing 95 A site is connected to the Internet through a single provider. The 96 site managers set a contract with another provider, and obtain a new 97 prefix. The site managers use "Router Renumbering for IPv6" 98 [RFC2894] to automatically inform the internal routers that they 99 should start advertising the new prefix. The hosts receive a router 100 advertisement and automatically create a second global address as 101 specified in "IPv6 Stateless Address Autoconfiguration" [RFC2462]. 103 2.4 Scenario 4, removing a provider 105 A site is connected to the Internet through two providers. The site 106 managers want to terminate the contract with one of these providers. 108 This occurs in two phases, first deprecating the old prefix, then 109 removing it. Both phases are implemented using "Router Renumbering 110 for IPv6" [RFC2894] and "IPv6 Stateless Address Autoconfiguration" 111 [RFC 2462]. 113 2.5 Scenario 5, time-of-day preference 115 A site is connected to the Internet through two providers. These 116 providers use different tariffs. The site managers desire that one 117 of the providers be preferred during working hours, say from 9:00 am 118 to 5:00 pm, and another be preferred during the rest of the day. 119 They use "Router Renumbering for IPv6" [RFC2894] at critical times 120 (9:00 am, 5:00 pm) to deprecate one of the global prefixes and 121 promote the other. The hosts receive router advertisements and heed 122 them as specified in "IPv6 Stateless Address Autoconfiguration" 123 [RFC2462]. 125 There are few sub cases here: 127 - time of day preference along with actual renumbering of hosts 128 - time of day preference only reflected in DNS (no renumbering) 129 - time of day preference for subset of services 130 - load balancing by advertising subset of links 132 The second case is the one that probably is going to be used most as 133 that has the lowest impact and eliminates the DNS TTL issue that a 134 host can remove address before the last cached DNS entry has 135 expired. 137 3 Renumbering requirements 139 The discussion of the renumbering scenarios in the IPNG and NGTRANS 140 working group unearthed a number of operational requirements that 141 must be met by any renumbering solution. These requirements include 142 continuous addressability, DNS security, network stability, and also 143 a minimum frequency. In addition, we list here a non-requirement, 144 the automatic support of the fusion between several sites. 146 3.1 Continuous addressability 148 Since DNS records may linger in various caches for the duration of 149 their TTL, IPv6 addresses should remain valid for at least as long 150 as the TTL of the DNS record. In fact, we observe that it is also 151 desirable to maintain usability of an "old" prefix for some time 152 after it has ceased being advertised in the DNS, in order to allow 153 existing connections to terminate. 155 This is addressed in the scenarios 2 and 4 through a two phase 156 approach: first deprecate a prefix, then at the end of the TTL 157 remove it. In IPv6, if an address prefix is deprecated, the host can 158 continue using it for existing connections or existing associations, 159 but should use only the preferred prefixes when initiating new 160 connections. In order to meet the TTL requirements, the hosts not 161 refuse new connections on deprecated prefixes. 163 3.2 DNS server load upon renumbering 165 When it comes to creating new addresses, or deprecating them, we 166 really have two choices. One possibility is to let the hosts use 167 dynamic DNS updates to create or update AAAA or A6 records on the 168 fly; another possibility is to have the site managers update the 169 AAAA or A6 records in a reference file. We have to analyse the 170 benefit/cost of AAAA/A6 in this context. 172 A particularly nasty consequence can occur if many hosts create new 173 addresses and attempt almost simultaneous DNS updates. This 174 phenomenon is discussed in [DISPRE], and a possible solution is 175 presented in conjunction with the use of A6 records. 177 3.3 The DNS security requirement 179 One additional concern is the interaction between renumbering, AAAA, 180 and DNSSEC -- specifically, the cost of re-signing a zone with new 181 addresses. The careful system administrator would do this after the 182 new prefix was known, but before the new prefix started to be used. 183 The effort required to re-sign scales linearly with the number of 184 RR's changed. Fortunately, this task is parallelizable; however, 185 the processors doing the work must be trusted with the zone's 186 private key. Folks with appropriate levels of paranoia likely won't 187 want to do much else with this hardware besides maintain the 188 zone(s). 190 As an unscientific test, during the DNSEXT meeting in Minneapolis 191 Bill Sommerfeld took the mit.edu zone (with about 82000 hosts), 192 synthesized AAAA records for all hosts, and signed it using the 193 tools included with a recent bind 9 release. His recollection was 194 that signing the synthesized zone took roughly 90 minutes on his 195 laptop -- a 333mhz Celeron, which averages to about 1000 signatures 196 per minute on this system, or maybe 3000 signatures per minute per 197 GHz of CPU. In the absence of DNAME, a roughly similar re-signing 198 effort is required for PTR zones: we would thus need two signatures 199 per address, one for AAAA, one on PTR. In these conditions, we are 200 down to 1500 addresses per minute per GHZ of CPU. 202 Renumbering a million-address network would take a bit over 11 GHz- 203 hours of cpu time just for the dnssec signatures alone; whether 204 anyone would actually want to renumber a million-nodes network is 205 indeed debatable. 207 Note that resigning needs to be complete before the RR's can be 208 replaced -- i.e., the time for renumbering to be complete is the 209 resigning time plus the TTL... 211 3.4 Name servers 213 To avoid cyclical references or "can opener-in-can" situations for 214 records pointed to by NS records, name servers basically must have 215 address records that provide their entire address, i.e. either AAAA 216 record or A6 records with a null length prefix. This means that, in 217 any renumbering scenario, individual records will have to be 218 published for the site's name servers, even if A6 is used. 220 3.5 Non requirement: fusion of sites 222 During the mailing list discussions, it was decided to not consider 223 a very specific type of renumbering: the merging of independent 224 sites. This is a noticeably different case, where the internal 225 numbering of a site may need to be radically altered, and a new 226 addressing plan needs to be created. 228 Fortunately though, this one generally is a rare event, is usually 229 known and can be planned for well in advance, and the disruptions 230 that occur are usually occurring in all kinds of other fields as 231 well, not just the network, so people tend to be a little more 232 forgiving (eg: people are more likely to curse when the merged 233 payroll division doesn't manage to get anyone's salary paid on time, 234 than when the net is flaky for half a day due to the numbering 235 changes not having propagated properly). 237 4 Security Considerations 239 This memo presents renumbering scenarios. Renumbering has 240 implications on security, since it forces the use of new addresses 241 and may invalidate previous bindings between names and addresses. 242 Secure bindings may require the use of DNS security; the effects of 243 renumbering on DNS security is discussed in section 3.3. 245 5 IANA Considerations 247 This document does not call for an IANA action. 249 6 Copyright 251 The following copyright notice is copied from RFC 2026 [Bradner, 252 1996], Section 10.4, and describes the applicable copyright for this 253 document. 255 Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved. 257 This document and translations of it may be copied and furnished to 258 others, and derivative works that comment on or otherwise explain it 259 or assist in its implementation may be prepared, copied, published 260 and distributed, in whole or in part, without restriction of any 261 kind, provided that the above copyright notice and this paragraph 262 are included on all such copies and derivative works. However, this 263 document itself may not be modified in any way, such as by removing 264 the copyright notice or references to the Internet Society or other 265 Internet organizations, except as needed for the purpose of 266 developing Internet standards in which case the procedures for 267 copyrights defined in the Internet Standards process must be 268 followed, or as required to translate it into languages other than 269 English. 271 The limited permissions granted above are perpetual and will not be 272 revoked by the Internet Society or its successors or assignees. 274 This document and the information contained herein is provided on an 275 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 276 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 277 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 278 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 279 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 7 Intellectual Property 283 The following notice is copied from RFC 2026 [Bradner, 1996], 284 Section 10.4, and describes the position of the IETF concerning 285 intellectual property claims made against this document. 287 The IETF takes no position regarding the validity or scope of any 288 intellectual property or other rights that might be claimed to 289 pertain to the implementation or use other technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; neither does it represent that it 292 has made any effort to identify any such rights. Information on the 293 IETF's procedures with respect to rights in standards-track and 294 standards-related documentation can be found in BCP-11. Copies of 295 claims of rights made available for publication and any assurances 296 of licenses to be made available, or the result of an attempt made 297 to obtain a general license or permission for the use of such 298 proprietary rights by implementers or users of this specification 299 can be obtained from the IETF Secretariat. 301 The IETF invites any interested party to bring to its attention any 302 copyrights, patents or patent applications, or other proprietary 303 rights which may cover technology that may be required to practice 304 this standard. Please address the information to the IETF Executive 305 Director. 307 8 Acknowledgements 309 This memo incorporates text submitted to the working group lists by 310 Bill Sommerfeld, Robert Elz, and Jun-ichiro itojun Hagino. Olafur 311 Gudmundsson was instrumental in prodding the author to submit it 312 before the deadline. 314 9 References 315 [RFC2874] M. Crawford, C. Huitema, "DNS Extensions to Support IPv6 316 Address Aggregation and Renumbering", RFC 2874, July 2000. 318 [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP 319 version 6", RFC 1886, December 1995. 321 [RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address 322 Autoconfiguration", RFC 2462, December 1998. 324 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 325 August 2000. 327 [DISPRE] M. Crawford, "Discovery of Resource Records Designating 328 IPv6 Address prefixes", Work in progress, November 2000. 330 10 Author's Addresses 332 Christian Huitema 333 Microsoft Corporation 334 One Microsoft Way 335 Redmond, WA 98052-6399 337 Email: huitema@microsoft.com