idnits 2.17.1 draft-baker-ipv6-renumber-procedure-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: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 93 has weird spacing: '...forward to de...' -- 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 (April 10, 2003) is 7679 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: '5' is defined on line 405, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 425, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 429, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '9') (Obsoleted by RFC 4862) -- No information found for draft-ietf-ipngwg-ipaddressassign - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Expires: October 9, 2003 April 10, 2003 6 Procedures for Renumbering an IPv6 Network without a Flag Day 7 draft-baker-ipv6-renumber-procedure-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 9, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document addresses the key procedural issues in renumbering an 38 IPv6 network. In certain areas, it is necessarily incomplete; it 39 points out those areas, however. It may be considered an update to 40 RFC 2072. It presumes the use of IPv6 Autoconfiguration as described 41 in RFC 2894. 43 Requirements Language 45 This document is not intended to be a requirements document, but a 46 starting point for a plan that a network operator might use to 47 renumber a network. As such, one could argue that requirements 48 language is inappropriate. However, a few recommendations in 49 application design or in procedural execution arise, which suggest 50 requirements. In those contexts, requirements language is used. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [1]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 5 60 2.1 Initial condition: stable using the old prefix . . . . . . . . 5 61 2.2 Adding the new prefix . . . . . . . . . . . . . . . . . . . . 5 62 2.3 Stable routing both prefixes . . . . . . . . . . . . . . . . . 5 63 2.4 Shutting down the use of the old prefix . . . . . . . . . . . 6 64 2.5 Removing the old prefix . . . . . . . . . . . . . . . . . . . 7 65 2.6 Final condition: stable using the new prefix . . . . . . . . . 7 66 3. "Find all the places..." . . . . . . . . . . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 Normative References . . . . . . . . . . . . . . . . . . . . . 12 70 Informative References . . . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . 15 74 1. Introduction 76 The Prussian military theorist Carl von Clausewitz [13] wrote, 77 "Everything is very simple in war, but the simplest thing is 78 difficult. These difficulties accumulate and produce a friction, 79 which no man can imagine exactly who has not seen war. ... So in war, 80 through the influence of an infinity of petty circumstances, which 81 cannot properly be described on paper, things disappoint us, and we 82 fall short of the mark." Operating a network is aptly compared to 83 conducting a war. The difference is that the opponent, who would 84 sometimes appear to be the customer who pays the bills, is the 85 futility of the expectation that homo ignoramus will behave 86 intelligently. A monograph on the subject by Hardin [14] calls this 87 the "Tragedy of the Commons", it results when a shortcut is taken 88 because of perceived immediate utility to the perpetrator and a lack 89 of responsibility for the side effects or latent ramifications of the 90 shortcut. 92 This document addresses the key procedural issues in renumbering an 93 IPv6 network. The procedure is straightforward to describe, but 94 operationally can be difficult to automate or execute due to issues 95 of statically configured network state, which one might aptly 96 describe as "an infinity of petty circumstances". As a result, in 97 certain areas, this procedure is necessarily incomplete; it points 98 out those areas, however. It may be considered an update to RFC 2072 99 [6]. For this reason also, this document contains recommendations for 100 application design and network management which, if taken seriously, 101 may avoid or minimize the impact of the issues. 103 RFC 2072 [6] describes the implications of renumbering in an IPv4 104 network. A number of issues are raised, not the least of which is 105 that while IPv4 in no sense precludes the configuration of more than 106 one prefix on an interface in an equal sense, IPv4 equipment usually 107 does not provide this capability. The net result is that changing a 108 subnet's prefix calls for a "flag day" - an epochal point in time, 109 before which one set of realities apply and after which another 110 disjoint set of realities apply - on the subnet, and changing a 111 network's base prefix calls for a flag day for the network. IPv6 112 intentionally calls for and provides the ability to configure 113 multiple prefixes on the same interface, and provides facilities for 114 the direct renumbering of those interfaces; as a result, it is 115 possible to reconfigure an IPv6 network without a flag day. However, 116 doing so requires planning and serious attention to detail. 118 The network, during renumbering, progresses through a series of 119 states which must be carefully considered from a policy perspective 120 to ensure that they are consistent at all times with the policies of 121 the administration. The network may be viewed as being in one of six 122 phases: 124 Stable using the old prefix: Initially, of course, the network is 125 using a prefix for in its routing, for its servers, and for other 126 systems in its network. This is a stable configuration. 128 Adding the new prefix: It is necessary to add the new prefix, but 129 while the new prefix is being added, it will of necessity not be 130 working everywhere in the network. Routing to various sub-prefixes 131 will be configured over a period of time varying from minutes to 132 hours depending on the size of the network and the degree of 133 automation used in reconfiguration. 135 Stable routing two prefixes: Once the network has been configured 136 with the new prefix and has had sufficient time to stabilize, it 137 becomes a stable platform with two addresses for every device, one 138 in the old prefix and one in the new. Sessions are opened with the 139 addresses in the old prefix; the new is idle. 141 Shutting down the use of the old prefix: DNS [3][4] is changed to 142 reflect addresses in the new prefix, and any manual address 143 configuration that used the old prefix must be modified to use the 144 new prefix. 146 Removing the old prefix: Once all sessions are deemed to have 147 completed, there will be no dependence on the old prefix. It may 148 be removed from the configuration of the system. 150 Stable using the new prefix: Equivalent to the initial state, but 151 using the new prefix. 153 This procedure identifies the considerations involved in taking the 154 network from phase to phase. 156 2. Detailed review of procedure 158 In this discussion, we assume that an entire prefix is being replaced 159 with another entire prefix. It may be that only part of a prefix is 160 being changed, or that more than one prefix is being changed to a 161 single joined prefix. In such cases, the principles apply, but will 162 need to be modified to address the exact situation. This procedure 163 should be seen as a skeleton of the procedure that would in fact be 164 applied. 166 2.1 Initial condition: stable using the old prefix 168 Initially, the network is using a given prefix for in its routing, 169 for its servers, and for other systems in its network. This is a 170 stable configuration. 172 2.2 Adding the new prefix 174 It is necessary to add the new prefix, but while the new prefix is 175 being added, it will of necessity not be working everywhere in the 176 network, and unless properly protected, it can be used to attack the 177 network in those places where it is operational. Routing to various 178 sub-prefixes will be configured over a period of time varying from 179 minutes to hours depending on the size of the network and the degree 180 of automation used in reconfiguration. 182 "Adding the new prefix" involves, at minimum, configuring the 183 relevant routers to use it and letting hosts autoconfigure new 184 addresses in the new prefix using IPv6 Autoconfiguration [2]. 185 Practically speaking, networks often have other knowledge of 186 addresses; they show up in route maps, access lists, access control 187 files and databases on hosts, and so on. The action here is to "find 188 all the places that the prefix has to be added, and add it." 190 Note that, to the extent that it is practicable, it is desirable to 191 use DNS [3][4] as the source of one's addresses, if only because it 192 consolidates the places needing change. 194 Advertisement of the prefix outside its network is the last thing to 195 be configured during this phase. One wants to have all of one's 196 defenses in place before advertising the prefix, if only because the 197 prefix may come under immediate attack. 199 2.3 Stable routing both prefixes 201 Once the network has been configured with the new prefix and has had 202 sufficient time to stabilize, it becomes a stable platform with two 203 addresses configured on each and every infrastructure component 204 interface (apart from serial interfaces that use only the link local 205 address), and two addresses available for the use of any end system, 206 one in the old prefix and one in the new. However, due to DNS [3][4] 207 advertisement and history, sessions are opened with the addresses in 208 the old prefix; the new is idle. This is a stable configuration. 210 2.4 Shutting down the use of the old prefix 212 While in this stable routing state, DNS [3][4] is changed to reflect 213 addresses in the new prefix, and any manual address configuration 214 that used the old prefix must be modified to use the new prefix. This 215 may include direct knowledge of addresses in neighboring networks, 216 justified perhaps by a belief that the Domain Name Service can be 217 unreliable at times, or in web pages. A key part of this conversion 218 process is that the routers are instructed to advertise that the new 219 prefix is preferred in autoconfiguration [2]; end systems may choose 220 to form a new address only when the router indicates that the new 221 prefix is preferred. 223 The reconfiguration capabilities of network devices, to make this 224 happen, must be well designed in advance; this is the Achilles Heel 225 of this operation. Ideally, every address in the network that is not 226 obtained using DNS (initial boot servers, name servers, call 227 managers, extranet peers, etc) should be reconfigurable via DHCP [7], 228 periodic configuration download, or another well defined procedure. 229 Absent this, renumbering the network can become a very expensive 230 manual process. 232 All DNS records have a lifetime, and the process of reconfiguration 233 takes time, so during this phase one must presume that some systems 234 are opening connections to the old prefix and some to the new. Even 235 after such information has aged out of the system, those sessions 236 have a lifetime; the administrator must decide when sufficient 237 sessions have completed that remaining sessions are unimportant. 238 Systems which have been statically configured and whose 239 reconfiguration has been overlooked will also continue using the old 240 prefix. During a renumbering event, it would be worthwhile to "sniff" 241 the network in front of key servers, looking for systems which are 242 still using the old prefix, in order both to determine when such 243 access has ceased and to identify unchanged systems. This will not 244 detect passive use (such as in an access list), but will help 245 identify active use. 247 Note that, to the extent that it is practicable, it is desirable to 248 use DNS as the source of one's addresses, if only because it 249 consolidates the places needing change. 251 2.5 Removing the old prefix 253 Once all sessions are deemed to have completed, there will be no 254 dependence on the old prefix. It may be removed from the 255 configuration of the routing system, and from any static 256 configurations that depend on it. 258 2.6 Final condition: stable using the new prefix 260 This is equivalent to the first state, but using the new prefix. 262 3. "Find all the places..." 264 The difficult operational issues in steps two (Section 2.2), four 265 (Section 2.4), five (Section 2.5) are in dealing with the 266 configurations of hosts which are not under the control of the 267 network administrator or are manually configured. Examples of such 268 devices include VoIP telephones with static configuration of boot or 269 name servers, scanning devices used by manufacturing partners in 270 support of "just in time" purchasing, manufacturing, or shipping 271 activities, the boot servers of routers and switches, and so on. 272 Application designers frequently take short-cuts to save memory or 273 increase responsiveness, and a common short-cut is to use static 274 configuration of IP addresses rather than DNS translation to obtain 275 the same. The downside of such behavior should be apparent; such a 276 poorly designed application cannot even add or replace a server 277 easily, much less change servers or reorganize its address space. The 278 short-cut ultimately becomes very expensive to maintain and very hard 279 to replace. 281 As a result, in view of the possibility that a network may need to be 282 renumbered in the future, any application and any platform that runs 283 on an IP stack, whether IPv4 or IPv6: 285 o SHOULD obtain its addresses from DNS by translating an appropriate 286 name, 288 o MUST obtain a new translation if a new session is opened with the 289 same service after the address lifetime expires, 291 o when addresses are configured rather than translated, MUST provide 292 a convenient programmatic method (such as DHCP [7]) to reconfigure 293 the addresses that can be executed using a script or its 294 equivalent 296 Application designers, equipment vendors, and the Open Source 297 community should take note. There is an opportunity to serve their 298 customers well in this area, and network operators should take note 299 to either develop or purchase appropriate tools. 301 4. Security Considerations 303 The process of renumbering is straightforward in theory but can be 304 difficult and dangerous in practice. The threats fall into two broad 305 categories: those arising from misconfiguration and those which are 306 actual attacks. 308 Misconfigurations can easily arise if any system in the network 309 "knows" the old prefix, or an address in it, a priori and is not 310 configured with the new prefix, or if the new prefix is configured in 311 a manner which replaces the old instead of being co-equal to it for a 312 period of time. Simplistic examples include 314 o You forget to reconfigure a system which is using the old prefix 315 in some static configuration. In this case, when the old prefix is 316 removed from the network, whatever feature was so configured 317 becomes inoperative - it is not configured for the new prefix, and 318 the old prefix is irrelevant. 320 o You are configuring a system via SSH to its only IPv6 address. You 321 change that address, simultaneously removing the old configuration 322 and replacing it with the new. Clearly, the underlying TCP will 323 now be unable to deliver segments to the system under 324 configuration, and configuration will not be able to continue 325 until it is possible to log into the system using its new address. 327 o Similarly, imagine that one removes the old configuration before 328 supplying the new. In this case, it may be necessary to obtain 329 on-site support or travel to the system and access it via its 330 console. 332 Clearly, taking the extra time to add the new prefix to the 333 configuration, allow the network to settle, and then remove the old 334 obviates this class of issue. A special consideration applies when a 335 class of devices are only occasionally used and require this 336 reconfiguration; the administration must allow suficiently long in 337 step four (Section 2.4) to ensure that their liklihood of detection 338 is sufficiently high. 340 A subtle case of this type can result when the DNS is used to 341 populate access control lists and similar security or QoS 342 configurations. DNS names used to translate between system or service 343 names and corresponding addresses are treated in this procedure as 344 providing the address in the preferred prefix, which is either the 345 old or the new prefix but not both. Such DNS names provide a means in 346 step four (Section 2.4) to cause systems in the network to stop using 347 the old prefix to access servers or peers and cause them to start 348 using the new prefix. DNS names used for access control lists, 349 however, need to go through the same three step procedure used for 350 other access control lists, having the new prefix added to them in 351 step two (Section 2.2) and the old prefix removed in step five 352 (Section 2.5). 354 Attacks are also possible. Suppose, for example, that the new prefix 355 has been presented by a service provider, and the service provider 356 starts advertising the prefix before the customer network is ready. 357 The new prefix might be targeted in a distributed denial of service 358 attack, or a system might be broken into using an application that 359 would not cross the firewall using the old prefix, before the 360 network's defenses have been configured. Clearly, one wants to 361 configure the defenses first and only then accessibility and routing. 363 RFC 2894 [2] partially automates the renumbering of router interfaces 364 in IPv6 networks, and the autoconfiguration procedure in RFC 2462 [9] 365 build on that to renumber the hosts. Dynamic DNS [8][10] provides a 366 capability for updating DNS accordingly. Managing configuration items 367 apart from those procedures is most obviously straightforward if all 368 such configurations are generated from a central configuration 369 repository or database, or if they can all be read into a temporary 370 database, changed using appropriate scripts, and applied to the 371 appropriate systems. Any place where scripted configuration 372 management is not possible or is not used must be tracked and managed 373 manually. Here, there be dragons. 375 5. Acknowledgements 377 This document grew out of a discussion on the IETF list. Jeroen 378 Massar, Eliot Lear, and Michel Participated in that discussion. 380 Commentary on the initial draft came from Craig Huegen, Peter Elford, 381 Roland Dobbins, Dan Wing, Harald Tveit Alvestrand, Jeff Wells, John 382 Schnizlein, Laurent Nicolas, Michael Thomas, Ole Troan, Sean Convery, 383 Tony Hain, and Scott Bradner. Specifically, the first three named 384 took it on themselves to convince the author that the concept of 385 network renumbering as a normal or frequent procedure is daft. Their 386 comments, if they result in improved address management practices in 387 networks, may be the best contribution this note has to offer. 389 Normative References 391 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 392 Levels", BCP 14, RFC 2119, March 1997. 394 [2] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 395 2000. 397 Informative References 399 [3] Mockapetris, P., "Domain names - concepts and facilities", STD 400 13, RFC 1034, November 1987. 402 [4] Mockapetris, P., "Domain names - implementation and 403 specification", STD 13, RFC 1035, November 1987. 405 [5] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: 406 Why would I want it and what is it anyway?", RFC 2071, January 407 1997. 409 [6] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 410 1997. 412 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 413 March 1997. 415 [8] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 416 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 417 April 1997. 419 [9] Thomson, S. and T. Narten, "IPv6 Stateless Address 420 Autoconfiguration", RFC 2462, December 1998. 422 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 423 Update", RFC 3007, November 2000. 425 [11] Lemon, T. and S. Cheshire, "Encoding Long Options in the 426 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 427 November 2002. 429 [12] Blanchet, M., "A flexible method for managing the assignment of 430 bites of an IPv6 address block", 431 draft-ietf-ipngwg-ipaddressassign-02 (work in progress), March 432 2001. 434 [13] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On 435 War, Chapter VII, 'Friction in War'", June 1989. 437 [14] Hardin, G., "The Tragedy of the Commons", Science 438 162(1968):1243-1248, June 1989. 440 Author's Address 442 Fred Baker 443 Cisco Systems 444 1121 Via Del Rey 445 Santa Barbara, CA 93117 446 US 448 Phone: 408-526-4257 449 Fax: 413-473-2403 450 EMail: fred@cisco.com 452 Intellectual Property Statement 454 The IETF takes no position regarding the validity or scope of any 455 intellectual property or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; neither does it represent that it 459 has made any effort to identify any such rights. Information on the 460 IETF's procedures with respect to rights in standards-track and 461 standards-related documentation can be found in BCP-11. Copies of 462 claims of rights made available for publication and any assurances of 463 licenses to be made available, or the result of an attempt made to 464 obtain a general license or permission for the use of such 465 proprietary rights by implementors or users of this specification can 466 be obtained from the IETF Secretariat. 468 The IETF invites any interested party to bring to its attention any 469 copyrights, patents or patent applications, or other proprietary 470 rights which may cover technology that may be required to practice 471 this standard. Please address the information to the IETF Executive 472 Director. 474 Full Copyright Statement 476 Copyright (C) The Internet Society (2003). All Rights Reserved. 478 This document and translations of it may be copied and furnished to 479 others, and derivative works that comment on or otherwise explain it 480 or assist in its implementation may be prepared, copied, published 481 and distributed, in whole or in part, without restriction of any 482 kind, provided that the above copyright notice and this paragraph are 483 included on all such copies and derivative works. However, this 484 document itself may not be modified in any way, such as by removing 485 the copyright notice or references to the Internet Society or other 486 Internet organizations, except as needed for the purpose of 487 developing Internet standards in which case the procedures for 488 copyrights defined in the Internet Standards process must be 489 followed, or as required to translate it into languages other than 490 English. 492 The limited permissions granted above are perpetual and will not be 493 revoked by the Internet Society or its successors or assignees. 495 This document and the information contained herein is provided on an 496 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 497 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 498 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 499 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 500 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Acknowledgement 504 Funding for the RFC Editor function is currently provided by the 505 Internet Society.