idnits 2.17.1 draft-ietf-v6ops-renumbering-procedure-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 937. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 -- 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 (November 19, 2004) is 7070 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) ** Downref: Normative reference to an Informational RFC: RFC 2072 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-10 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations Working Group F. Baker 2 Internet-Draft E. Lear 3 Expires: May 20, 2005 R. Droms 4 Cisco Systems 5 November 19, 2004 7 Procedures for Renumbering an IPv6 Network without a Flag Day 8 draft-ietf-v6ops-renumbering-procedure-02 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 20, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document describes a procedure that can be used to renumber a 44 network from one prefix to another. It uses IPv6's intrinsic ability 45 to assign multiple addresses to a network interface to provide 46 continuity of network service through a "make-before-break" 47 transition, as well as addressing naming and configuration management 48 issues. It also uses other IPv6 features to minimize the effort and 49 time required to complete the transition from the old prefix to the 50 new prefix. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Summary of the renumbering procedure . . . . . . . . . . . 3 56 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3 Summary of what must be changed . . . . . . . . . . . . . 4 58 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5 60 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6 61 2.1 Initial condition: stable using the old prefix . . . . . . 6 62 2.2 Preparation for the renumbering process . . . . . . . . . 6 63 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7 64 2.2.2 Mechanisms for address assignment to interfaces . . . 8 65 2.3 Configuring switches and routers for the new prefix . . . 8 66 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9 67 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10 68 2.6 Transition from use of the old prefix to the new prefix . 10 69 2.6.1 Transition of DNS service to the new prefix . . . . . 10 70 2.6.2 Transition to the use of new addresses . . . . . . . . 10 71 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11 72 2.8 Final condition: stable using the new prefix . . . . . . . 12 74 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 75 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 76 3.2 Renumbering switch and router interfaces . . . . . . . . . 13 77 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 79 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 80 4.1 Dynamic updates to DNS across administrative domains . . . 15 81 4.2 Management of the inverse zone . . . . . . . . . . . . . . 15 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 89 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 93 A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22 95 Intellectual Property and Copyright Statements . . . . . . . . 24 97 1. Introduction 99 The Prussian military theorist Carl von Clausewitz [Clausewitz] 100 wrote, "Everything is very simple in war, but the simplest thing is 101 difficult. These difficulties accumulate and produce a friction, 102 which no man can imagine exactly who has not seen war. ... So in 103 war, through the influence of an "infinity of petty circumstances" 104 which cannot properly be described on paper, things disappoint us and 105 we fall short of the mark." Operating a network is aptly compared to 106 conducting a war. The difference is that the opponent has the futile 107 expectation that homo ignoramus will behave intelligently. 109 A "flag day" is a procedure in which the network, or a part of it, is 110 changed during a planned outage, or suddenly, causing an outage while 111 the network recovers. Avoiding outages requires the network to be 112 modified using what in mobility might be called a "make before break" 113 procedure: the network is enabled to use a new prefix while the old 114 one is still operational, operation is switched to that prefix, and 115 then the old one is taken down. 117 This document addresses the key procedural issues in renumbering an 118 IPv6 [RFC2460] network without a "flag day". The procedure is 119 straightforward to describe, but operationally can be difficult to 120 automate or execute due to issues of statically configured network 121 state, which one might aptly describe as "an infinity of petty 122 circumstances". As a result, in certain areas, this procedure is 123 necessarily incomplete, as network environments vary widely and no 124 one solution fits all. It points out a few of many areas where there 125 are multiple approaches. It may be considered an update to RFC 2072 126 [RFC2072]. This document also contains recommendations for 127 application design and network management which, if taken seriously, 128 may avoid or minimize the impact of the issues. 130 1.1 Summary of the renumbering procedure 132 By "renumbering a network" we mean replacing the use of an existing 133 (or "old") prefix throughout a network with a new prefix. Usually, 134 both prefixes will be the same length. The procedures described in 135 this document are, for the most part, equally applicable if the two 136 prefixes are not the same length. During renumbering, sub-prefixes 137 (or "link prefixes") from the old prefix, which have been assigned to 138 links throughout the network, will be replaced by link prefixes from 139 the new prefix. Interfaces on systems throughout the network will be 140 configured with IPv6 addresses from the link prefixes of the new 141 prefix, and any addresses from the old prefix in services like DNS 142 [RFC1034][RFC1035] or configured into switches and routers and 143 applications will be replaced by the appropriate addresses from the 144 new prefix. 146 The renumbering procedure described in this document can be applied 147 to part of a network as well as an organization's entire network. In 148 the case of a large organization, it may be advantageous to treat the 149 network as a collection of smaller networks. Renumbering each of the 150 smaller networks separately will make the process more manageable. 151 The process described in this document is generally applicable to any 152 network, whether it is an entire organization network or part of a 153 larger network. 155 1.2 Terminology 157 DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through 158 the use of SIG(0)[RFC2535][RFC2931] and TSIG [RFC2845] 160 DHCP prefix delegation: An extension to DHCP [RFC3315] to automate 161 the assignment of a prefix; for example from an ISP to a 162 customer[RFC3633] 164 flag day: A transition which involves a planned service outage 166 ingress/egress filters: Filters applied to a router interface 167 connected to an external organization, such as an ISP, to exclude 168 traffic with inappropriate IPv6 addresses 170 link prefix: A prefix, usually a /64 [RFC3177], assigned to a link 172 SLAC: StateLess Address AutoConfiguration [RFC2462] 174 1.3 Summary of what must be changed 176 Addresses from the old prefix that are affected by renumbering will 177 appear in a wide variety of places in the components in the 178 renumbered network. The following list gives some of the places 179 which may include prefixes or addresses that are affected by 180 renumbering, and gives some guidance about how the work required 181 during renumbering might be minimized: 183 o Link prefixes assigned to links. Each link in the network must be 184 assigned a link prefix from the new prefix. 186 o IPv6 addresses assigned to interfaces on switches and routers. 187 These addresses are typically assigned manually, as part of 188 configuring switches and routers. 190 o Routing information propagated by switches and routers 192 o Link prefixes advertised by switches and routers. [RFC2461] 193 o Ingress/egress filters. 195 o ACLs and other embedded addresses on switches and routers. 197 o IPv6 addresses assigned to interfaces on hosts. Use of StateLess 198 Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can 199 mitigate the impact of renumbering the interfaces on hosts. 201 o DNS entries. New AAAA and PTR records are added and old ones 202 removed in several phases to reflect the change of prefix. 203 Caching times are adjusted accordingly during these phases. 205 o IPv6 addresses and other configuration information provided by 206 DHCP. 208 o IPv6 addresses embedded in configuration files, applications and 209 elsewhere. Finding everything that must be updated and automating 210 the process may require significant effort, which is discussed in 211 more detail in Section 3. This process must be tailored to the 212 needs of each network. 214 1.4 Multihoming Issues 216 In addition to the considerations presented, the operational matters 217 of multihoming may need to be addressed. Networks are generally 218 renumbered for one of three reasons: the network itself is changing 219 its addressing policy and must renumber to implement the new policy 220 (for example, a company has been acquired and is changing addresses 221 to those used by its new owner), an upstream provider has changed its 222 prefixes and its customers are forced to do so at the same time, or a 223 company is changing providers and must perforce use addresses 224 assigned by the new provider. The third case is common. 226 When a company changes providers, it is common to institute an 227 overlap period, during which it is served by both providers. By 228 definition, the company is multihomed during such a period. While 229 this document is not about multihoming per se, problems can arise as 230 a result of ingress filtering policies applied by the upstream 231 provider or one of its upstream providers, so the user of this 232 document need also be cognizant of these issues. This is discussed 233 in detail, and approaches to dealing with it are described, in 234 [RFC2827] and [RFC3704]. 236 2. Detailed review of procedure 238 During the renumbering process, the network transitions through eight 239 states. In the initial state, the network uses just the prefix which 240 is to be replaced during the renumbering process. At the end of the 241 process, the old prefix has been entirely replaced by the new prefix, 242 and the network is using just the new prefix. To avoid a flag day 243 transition, the new prefix is deployed first and the network reaches 244 an intermediate state in which either prefix can be used. In this 245 state, individual hosts can make the transition to using the new 246 prefix as appropriate to avoid disruption of applications. Once all 247 of the hosts have made the transition to the new prefix, the network 248 is reconfigured so that the old prefix is no longer used in the 249 network. 251 In this discussion, we assume that an entire prefix is being replaced 252 with another entire prefix. It may be that only part of a prefix is 253 being changed, or that more than one prefix is being changed to a 254 single joined prefix. In such cases, the basic principles apply, but 255 will need to be modified to address the exact situation. This 256 procedure should be seen as a skeleton of a more detailed procedure 257 that has been tailored to a specific environment. Put simply, season 258 to taste. 260 2.1 Initial condition: stable using the old prefix 262 Initially, the network is using an old prefix in routing, device 263 interface addresses, filtering, firewalls and other systems. This is 264 a stable configuration. 266 2.2 Preparation for the renumbering process 268 The first step is to obtain the new prefix and new reverse zone from 269 the delegating authority. These delegations are performed using 270 established procedures, from either an internal or external 271 delegating authority. 273 Before any devices are reconfigured as a result of the renumbering 274 event, each link in the network must be assigned a sub-prefix from 275 the new prefix. While this assigned link prefix doesn't explicitly 276 appear in the configuration of any specific switch, router, or host, 277 the network administrator performing the renumbering procedure must 278 make these link prefix assignments prior to beginning the procedure 279 to guide the configuration of switches and routers, assignment of 280 addresses to interfaces and modifications to network services such as 281 DNS and DHCP. 283 Prior to renumbering, various processes will need to be reconfigured 284 to confirm bindings between names and addresses more frequently. In 285 normal operation, DNS name translations and DHCP bindings are often 286 given relatively long lifetimes to limit server load. In order to 287 reduce transition time from old to new prefix it may be necessary to 288 reduce the time to live (TTL) associated with DNS records and 289 increase the frequency with which DHCP clients contact the DHCP 290 server. At the same time, a procedure must be developed through 291 which other configuration parameters will be updated during the 292 transition period when both prefixes are available. 294 2.2.1 Domain Name Service 296 During the renumbering process, the DNS database must be updated to 297 add information about addresses assigned to interfaces from the new 298 prefix and to remove addresses assigned to interfaces from the old 299 prefix. The changes to the DNS must be coordinated with the changes 300 to the addresses assigned to interfaces. 302 Changes to the information in the DNS have to propagate from the 303 server at which the change was made to the resolvers where the 304 information is used. The speed of this propagation is controlled by 305 the TTL for DNS records and the frequency of updates from primary to 306 secondary servers. 308 The latency in propagating changes in the DNS can be managed through 309 the TTL assigned to individual DNS records and through the timing of 310 updates from primary to secondary servers. Appendix A gives an 311 analysis of the factors controlling the propagation delays in the 312 DNS. 314 The suggestions for reducing the delay in the transition to new IPv6 315 addresses applies when the DNS service can be given prior notice 316 about a renumbering event. However, the DNS service for a host may 317 be in a different administrative domain than the network to which the 318 host is attached. For example, a device from organization A that 319 roams to a network belonging to organization B, the device's DNS A 320 record is still managed by organization A, where the DNS service 321 won't be given advance notice of a renumbering event in organization 322 B. 324 One strategy for updating the DNS is to allow each network device to 325 manage its own DNS information through Dynamic DNS (DDNS) 326 [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly 327 recommended, and can be accomplished through the use of either TSIG, 328 and SIG(0). Both TSIG and SIG(0) require configuration and 329 distribution of keys to end hosts and name servers in advance of the 330 renumbering event. 332 2.2.2 Mechanisms for address assignment to interfaces 334 IPv6 addresses may be assigned through SLAC, DHCP, and manual 335 processes. If DHCP is used for IPv6 address assignment, there may be 336 some delay in the assignment of IPv6 addresses from the new prefix 337 because hosts using DHCP only contact the server periodically to 338 extend the lifetimes on assigned addresses. This delay can be 339 reduced in two ways: 341 o Prior to the renumbering event, the T1 parameter (which controls 342 the time at which a host using DHCP contacts the server) may be 343 reduced. 345 o The DHCP Reconfigure message may also be sent from the server to 346 the hosts to trigger the hosts to immediately contact the server. 348 2.3 Configuring switches and routers for the new prefix 350 In this step, switches and routers and services are prepared for the 351 new prefix but the new prefix is not used for any datagram 352 forwarding. Throughout this step, the new prefix is added to the 353 network infrastructure in parallel with (and without interfering 354 with) the old prefix. For example, addresses assigned from the new 355 prefix are configured in addition to any addresses from the old 356 prefix assigned to interfaces on the switches and routers. Changes 357 to the routing infrastructure for the new prefix are added in 358 parallel with the old prefix so that forwarding for both prefixes 359 operates in parallel. At the end of this step, the network is still 360 running on the old prefix but is ready to begin using the new prefix. 362 The new prefix is added to the routing infrastructure, firewall 363 filters, ingress/egress filters and other forwarding and filtering 364 functions. Routes for the new link prefixes may be injected by 365 routing protocols into the routing subsystem, but the router 366 advertisements should not cause hosts to perform SLAC on the new link 367 prefixes; in particular the "autonomous address-configuration" flag 368 [RFC2461] should not be set in the advertisements for the new link 369 prefixes. The reason hosts should not be forming addresses at this 370 point is that routing to the new addresses may not yet be stable. 372 The details of this step will depend on the specific architecture of 373 the network being renumbered and the capabilities of the components 374 that make up the network infrastructure. The effort required to 375 complete this step may be mitigated by the use of DNS, DHCP prefix 376 delegation [RFC3633] and other automated configuration tools. 378 While the new prefix is being added, it will of necessity not be 379 working everywhere in the network, and unless properly protected by 380 some means such as ingress and egress access lists, the network may 381 be attacked through the new prefix in those places where it is 382 operational. 384 Once the new prefix has been added to the network infrastructure, 385 access-lists, route-maps and other network configuration options that 386 use IP addresses should be checked to ensure that hosts and services 387 that use the new prefix will behave as they did with the old one. 388 Name services other than DNS and other services that provide 389 information that will be affected by renumbering must be updated in 390 such a way as to avoid responding with stale information. There are 391 several useful approaches to identify and augment configurations: 393 Develop a mapping from each network and address derived from the 394 old prefix to each network and address derived from the new 395 prefix. Tools such as the UNIX "sed" or "perl" utilities are 396 useful to then find and augment access-lists, route-maps, and the 397 like. 399 A similar approach involves the use of such mechanisms as DHCP 400 prefix delegation to abstract networks and addresses. 402 Switches and routers or manually configured hosts that have IPv6 403 addresses assigned from the new prefix may be used at this point to 404 test the network infrastructure. 406 Advertisement of the prefix outside its network is the last thing to 407 be configured during this phase. One wants to have all of one's 408 defenses in place before advertising the prefix, if only because the 409 prefix may come under immediate attack. 411 At the end of this phase routing, access control, and other network 412 services should work interchangeably for both old and new prefixes. 414 2.4 Adding new host addresses 416 Once the network infrastructure for the new prefix are in place and 417 tested, IPv6 addresses from the new prefix may be assigned to host 418 interfaces. These IPv6 addresses may be assigned through SLAC, DHCP, 419 and manual processes. If SLAC is used in the network, the switches 420 and routers are configured to indicate that hosts should use SLAC to 421 assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 422 address assignment, the DHCP service is configured to assign IPv6 423 addresses to hosts. 425 Once the new IPv6 addresses have been assigned to the host 426 interfaces, both the forward and reverse maps within DNS should be 427 updated for the new addresses, either through automated or manual 428 means. In particular, some clients may be able to update their 429 forward maps through DDNS, while automating the update of the reverse 430 zone may be more difficult as discussed in Section 4.2. 432 2.5 Stable use of either prefix 434 Once the network has been configured with the new prefix and has had 435 sufficient time to stabilize, it becomes a stable platform with two 436 addresses configured on each and every infrastructure component 437 interface (apart from interfaces that use only the link-local 438 address), and two non-link-local addresses are available for the use 439 of any host, one in the old prefix and one in the new. This is a 440 stable configuration. 442 2.6 Transition from use of the old prefix to the new prefix 444 When the new prefix has been fully integrated into the network 445 infrastructure and has been tested for stable operation, hosts and 446 switches and routers can begin using the new prefix. Once the 447 transition has completed the old prefix will not be in use in the 448 network. 450 2.6.1 Transition of DNS service to the new prefix 452 The DNS service is configured to use the new prefix by removing any 453 IPv6 addresses from the old prefix from the DNS server configuration. 454 External references to the DNS servers, such as in the DNS service 455 from which this DNS domain was delegated, are updated to use the IPv6 456 addresses from the new prefix. 458 2.6.2 Transition to the use of new addresses 460 When both prefixes are usable in the network, each host can make the 461 transition from using the old prefix to the new prefix at a time that 462 is appropriate for the applications on the host. If the host 463 transitions are randomized, DNS dynamic update mechanisms can better 464 scale to accommodate the changes to the DNS. 466 As services become available through addresses from the new prefix, 467 references to the hosts providing those services are updated to use 468 the new prefix. Addresses obtained through DNS will be automatically 469 updated when the DNS names are resolved. Addresses may also be 470 obtained through DHCP, and will be updated as hosts contact DHCP 471 servers. Addresses that are otherwise configured must be updated 472 appropriately. 474 It may be necessary to provide users with tools or other explicit 475 procedures to complete the transition from the use of the old prefix 476 to the new prefix, because some applications and operating system 477 functions may be configured in ways that do not use DNS at all or 478 will not use DNS to resolve a domain name to a new address once the 479 new prefix is available. For example, a device that only uses DNS to 480 resolve the name of an NTP server when the device is initialized will 481 not obtain the address from the new prefix for that server at this 482 point in the renumbering process. 484 This last point warrants repeating (in a slightly different form). 485 Applications may cache addressing information in different ways, for 486 varying lengths of time. They may cache this information in memory, 487 on a file system, or in a database. Only after careful observation 488 and consideration of one"s environment should one conclude that a 489 prefix is no longer in use. For more information on this issue, 490 please see [I-D.ietf-dnsop-ipv6-dns-issues]. 492 The transition of critical services, such as DNS, DHCP, NTP [RFC1305] 493 and important business services should be managed and tested 494 carefully to avoid service outages. Each host should take reasonable 495 precautions prior to changing to the use of the new prefix to 496 minimize the chance of broken connections. For example, utilities 497 such as netstat and network analyzers can be used to determine if any 498 existing connections to the host are still using the address from the 499 old prefix for that host. 501 Link prefixes from the old prefix in router advertisements and 502 addresses from the old prefix provided through DHCP should have their 503 preferred lifetimes set to zero at this point, so that hosts will not 504 use the old prefixes for new communications. 506 2.7 Removing the old prefix 508 Once all sessions are deemed to have completed, there will be no 509 dependence on the old prefix. It may be removed from the 510 configuration of the routing system, and from any static 511 configurations that depend on it. If any configuration has been 512 created based on DNS information, the configuration should be 513 refreshed after the old prefixes have been removed from the DNS. 515 During this phase the old prefix may be reclaimed by the provider or 516 RIR that granted it, and addresses within that prefix are removed 517 DNS. 519 In addition, DNS reverse maps for the old prefix may be removed from 520 the primary name server and the zone delegation may be removed from 521 the parent zone. Any DNS, DHCP, or SLAC timers that were changed 522 should be reset to their original values (most notably the DNS 523 forward map TTL). 525 2.8 Final condition: stable using the new prefix 527 This is equivalent to the first state, but using the new prefix. 529 3. How to avoid shooting yourself in the foot 531 The difficult operational issues in Section 2.3, Section 2.6, and 532 Section 2.7 are in dealing with the configurations of routers and 533 hosts which are not under the control of the network administrator or 534 are manually configured. Examples of such devices include voice over 535 IP (VoIP) telephones with static configuration of boot or name 536 servers, dedicated devices used in manufacturing that are configured 537 with the IP addresses for specific services, the boot servers of 538 routers and switches, etc. 540 3.1 "Find all the places..." 542 Long-lived communications present a problem to any application, 543 regardless of whether a network is renumbered. However, such events 544 test the resilience of the code used to survive disruptions. Many 545 existing applications make use of standard POSIX functions such as 546 gethostbyname() and getipnodebyname(), both of which use the common 547 "hostent" structure. If the application caches the response or for 548 whatever reason actually records the response on disk, recovery from 549 such events may prove difficult. It should be pointed out that the 550 above basic functions do not preserve DNS caching semantics. Any 551 application that requires repeated use of an IP address should either 552 not cache the result or make use of an appropriate function such as 553 the POSIX res_query(). 555 In some cases, applications make use of manually configured IP 556 addresses. For instance, database servers and web servers are often 557 configured to LISTEN to a specific TCP port on a specific interface. 558 Applications should be configured with names that are translated at 559 startup, and then again when the interface address itself is changed. 561 In the case of infrastructure applications such as name servers and 562 route processes, a convenient programmatic method that abstracts 563 prefixes to a single point would be ideal. 565 Application designers, equipment vendors, and the Open Source 566 community should take note. There is an opportunity to serve their 567 customers well in this area, and network operators should take note 568 to either develop or purchase appropriate tools. 570 3.2 Renumbering switch and router interfaces 572 The configuration and operation of switches and routers are often 573 designed to use static configuration with IP addresses or to resolve 574 domain names only once and use the resulting IP addresses until the 575 element is restarted. These static configurations complicate the 576 process of renumbering, requiring administration of all of the static 577 information and manual configuration during a renumbering event. 579 Because switches and routers are usually single-purpose devices, the 580 user interface and operating functions (software and hardware) are 581 often better integrated than independent services running on a server 582 platform. Thus, it is likely that switch vendors and router vendors 583 can design and implement consistent support for renumbering across 584 all of the functions of switches and routers. 586 To better support renumbering, switches and routers should use domain 587 names for configuration wherever appropriate, and should resolve 588 those names using the DNS when the lifetime on the name expires. 590 3.3 Ingress Filtering 592 An important consideration in Section 2.3, in the case where the 593 network being renumbered is connected to an external provider, the 594 network's ingress filtering policy and its provider's ingress 595 filtering policy. Both the network firewall's ingress filter and the 596 provider's ingress filter on the access link to the network should be 597 configured to prevent attacks that use source address spoofing. 598 Ingress filtering is considered in detail in "Ingress Filtering for 599 Multihomed Networks" [RFC3704]. 601 4. Call to Action for the IETF 603 The more automated one can make the renumbering process, the better 604 for everyone. Sadly, there are several mechanisms that either have 605 not been automated, or have not been automated consistently across 606 platforms. 608 4.1 Dynamic updates to DNS across administrative domains 610 The configuration files for a DNS server (such as named.conf) will 611 contain addresses that must be reconfigured manually during a 612 renumbering event. There is currently no easy way to automate the 613 update of these addresses, as the updates require both complex trust 614 relationships and automation to verify them. For instance, a reverse 615 zone is delegated by an upstream ISP, but there is currently no 616 mechanism to note additional delegations. 618 4.2 Management of the inverse zone 620 In networks where hosts obtain IPv6 addresses through SLAC, updates 621 of reverse zone are problematic because of lack of trust relationship 622 between administrative domain owning the prefix and the host 623 assigning the low 64 bits using SLAC. For example, suppose a host, 624 H, from organization A is connected to a network owned by 625 organization B. When H obtains a new address during a renumbering 626 event through SLAC, H will need to update its reverse entry in the 627 DNS through a DNS server from B that owns the reverse zone for the 628 new address. For H to update its reverse entry, the DNS server from 629 B must accept a DDNS request from H, requiring that an 630 inter-administrative domain trust relationship exist between H and B. 631 The IETF should develop a BCP recommendation for addressing this 632 problem. 634 5. Security Considerations 636 The process of renumbering is straightforward in theory but can be 637 difficult and dangerous in practice. The threats fall into two broad 638 categories: those arising from misconfiguration and those which are 639 actual attacks. 641 Misconfigurations can easily arise if any system in the network 642 "knows" the old prefix, or an address in it, a priori and is not 643 configured with the new prefix, or if the new prefix is configured in 644 a manner which replaces the old instead of being co-equal to it for a 645 period of time. Simplistic examples include: 647 Neglecting to reconfigure a system that is using the old prefix in 648 some static configuration: In this case, when the old prefix is 649 removed from the network, whatever feature was so configured 650 becomes inoperative - it is not configured for the new prefix, and 651 the old prefix is irrelevant. 653 Configuring a system via an IPv6 address, and replacing that old 654 address with a new address: Because the TCP connection is using the 655 old and now invalid IPv6 address, the SSH session will be 656 terminated and you will have to use SSH through the new address 657 for additional configuration changes. 659 Removing the old configuration before supplying the new: In this 660 case, it may be necessary to obtain on-site support or travel to 661 the system and access it via its console. 663 Clearly, taking the extra time to add the new prefix to the 664 configuration, allow the network to settle, and then remove the old 665 obviates this class of issue. A special consideration applies when 666 some devices are only occasionally used; the administration must 667 allow sufficiently long in Section 2.6 to ensure that their 668 likelihood of detection is sufficiently high. 670 A subtle case of this type can result when the DNS is used to 671 populate access control lists and similar security or QoS 672 configurations. DNS names used to translate between system or 673 service names and corresponding addresses are treated in this 674 procedure as providing the address in the preferred prefix, which is 675 either the old or the new prefix but not both. Such DNS names 676 provide a means in Section 2.6 to cause systems in the network to 677 stop using the old prefix to access servers or peers and cause them 678 to start using the new prefix. DNS names used for access control 679 lists, however, need to go through the same three step procedure used 680 for other access control lists, having the new prefix added to them 681 in Section 2.3 and the old prefix removed in Section 2.7. 683 It should be noted that the use of DNS names in this way is not 684 universally accepted as a solution to this problem; [RFC3871] 685 especially notes cases where static IP addresses are preferred over 686 DNS names, in order to avoid a name lookup when the naming system is 687 inaccessible or when the result of the lookup may be one of several 688 interfaces or systems. In such cases, extra care must be taken to 689 manage renumbering properly. 691 Attacks are also possible. Suppose, for example, that the new prefix 692 has been presented by a service provider, and the service provider 693 starts advertising the prefix before the customer network is ready. 694 The new prefix might be targeted in a distributed denial of service 695 attack, or a system might be broken into using an application that 696 would not cross the firewall using the old prefix, before the 697 network's defenses have been configured. Clearly, one wants to 698 configure the defenses first and only then accessibility and routing, 699 as described in Section 2.3 and Section 3.3. 701 The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic 702 DNS provides a capability for updating DNS accordingly. Managing 703 configuration items apart from those procedures is most obviously 704 straightforward if all such configurations are generated from a 705 central configuration repository or database, or if they can all be 706 read into a temporary database, changed using appropriate scripts, 707 and applied to the appropriate systems. Any place where scripted 708 configuration management is not possible or is not used must be 709 tracked and managed manually. Here, there be dragons. 711 In ingress filtering of a multihomed network, an easy solution to the 712 issues raised in Section 3.3 might recommend that ingress filtering 713 should not be done for multihomed customers or that ingress filtering 714 should be special-cased. However, this has an impact on Internet 715 security. A sufficient level of ingress filtering is needed to 716 prevent attacks using spoofed source addresses. Another problem 717 becomes from the fact that if ingress filtering is made too difficult 718 (e.g. by requiring special casing in every ISP doing it), it might 719 not be done at an ISP at all. Therefore, any mechanism depending on 720 relaxing ingress filtering checks should be dealt with an extreme 721 care. 723 6. Acknowledgments 725 This document grew out of a discussion on the IETF list. Commentary 726 on the document came from Bill Fenner, Christian Huitema, Craig 727 Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand, 728 Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, 729 Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, 730 Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain. 732 Some took it on themselves to convince the authors that the concept 733 of network renumbering as a normal or frequent procedure is daft. 734 Their comments, if they result in improved address management 735 practices in networks, may be the best contribution this note has to 736 offer. 738 Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described 739 the ingress filtering issues. These made their way separately into 740 [RFC3704], which should be read and understood by anyone that will 741 temporarily or permanently create a multihomed network by renumbering 742 from one provider to another. 744 7. References 746 7.1 Normative References 748 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 749 STD 13, RFC 1034, November 1987. 751 [RFC1035] Mockapetris, P., "Domain names - implementation and 752 specification", STD 13, RFC 1035, November 1987. 754 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 755 January 1997. 757 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 758 (IPv6) Specification", RFC 2460, December 1998. 760 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 761 Discovery for IP Version 6 (IPv6)", RFC 2461, December 762 1998. 764 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 765 Autoconfiguration", RFC 2462, December 1998. 767 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 768 M. Carney, "Dynamic Host Configuration Protocol for IPv6 769 (DHCPv6)", RFC 3315, July 2003. 771 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 772 Networks", BCP 84, RFC 3704, March 2004. 774 7.2 Informative References 776 [Clausewitz] 777 von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, 778 "On War, Chapter VII, 'Friction in War'", June 1989. 780 [I-D.ietf-dnsop-ipv6-dns-issues] 781 Durand, A., Ihren, J. and P. Savola, "Operational 782 Considerations and Issues with IPv6 DNS", 783 draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress), 784 October 2004. 786 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 787 Specification, Implementation", RFC 1305, March 1992. 789 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 790 August 1996. 792 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 793 Changes (DNS NOTIFY)", RFC 1996, August 1996. 795 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 796 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 797 April 1997. 799 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 800 RFC 2535, March 1999. 802 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 803 Defeating Denial of Service Attacks which employ IP Source 804 Address Spoofing", BCP 38, RFC 2827, May 2000. 806 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 807 Wellington, "Secret Key Transaction Authentication for DNS 808 (TSIG)", RFC 2845, May 2000. 810 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 811 SIG(0)s)", RFC 2931, September 2000. 813 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 814 Update", RFC 3007, November 2000. 816 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 817 Allocations to Sites", RFC 3177, September 2001. 819 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 820 Host Configuration Protocol (DHCP) version 6", RFC 3633, 821 December 2003. 823 [RFC3871] Jones, G., "Operational Security Requirements for Large 824 Internet Service Provider (ISP) IP Network 825 Infrastructure", RFC 3871, September 2004. 827 Authors' Addresses 829 Fred Baker 830 Cisco Systems 831 1121 Via Del Rey 832 Santa Barbara, CA 93117 833 US 835 Phone: 408-526-4257 836 Fax: 413-473-2403 837 EMail: fred@cisco.com 838 Eliot Lear 839 Cisco Systems 840 170 W. Tasman Dr. 841 San Jose, CA 95134 842 US 844 Phone: +1 408 527 4020 845 EMail: lear@cisco.com 847 Ralph Droms 848 Cisco Systems 849 200 Beaver Brook Road 850 Boxborough, MA 01719 851 US 853 Phone: +1 978 936-1674 854 EMail: rdroms@cisco.com 856 Appendix A. Managing Latency in the DNS 858 The procedure in this section can be used to determine and manage the 859 latency in updates to information a DNS resource record (RR). 861 There are several kinds of possible delays which are ignored in these 862 calculations: 864 o the time it takes for the administrators to make the changes, 866 o the time it may take to wait for the DNS update, if the 867 secondaries are only updated at regular intervals, and not 868 immediately, and 870 o the time the updating to all the secondaries takes. 872 Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer 873 updated information from the primary DNS server to any secondary 874 servers; this is a very quick update process, and the actual time to 875 update of information is not considered significant. 877 There's a target time, TC, at which we want to change the contents of 878 a DNS RR. The RR is currently configured with TTL == TTLOLD. Any 879 cached references to the RR will expire no more than TTLOLD in the 880 future. 882 At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured 883 with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to 884 push the RR to the secondaries. After the update, responses to 885 queries for the RR are returned with TTLNEW. There are still some 886 cached references with TTLOLD. 888 At time TC - TTLNEW, the RR in the primary is configured with the new 889 address. The update process is initiated to push the RR to the 890 secondaries. After the update, responses to queries for the RR 891 return the new address. All the cached references have TTLNEW. 892 Between this time and TC, responses to queries for the RR may be 893 returned with either the old address or the new address. This 894 ambiguity is acceptable, assuming the host is configured to respond 895 to both addresses. 897 At time TC all the cached references with the old address have 898 expired, and all subsequent queries will return the new address. 899 After TC (corresponding to the final state described in Section 2.8), 900 the TTL on the RR can be set to the initial value TTLOLD. 902 The network administrator can choose TTLOLD and TTLNEW to meet local 903 requirements. 905 As a concrete example, consider a case where TTLOLD is a week (168 906 hours), and TTLNEW is an hour. The preparation for the change of 907 addresses begins 169 hours before the address change. After 168 908 hours have passed and only one hour is left, the TTLNEW has 909 propagated everywhere, and one can change the address record(s). 910 These are propagated within the hour, after which one can restore TTL 911 value to a larger value. This approach minimizes time where it's 912 uncertain what kind of (address) information is returned from the 913 DNS. 915 Intellectual Property Statement 917 The IETF takes no position regarding the validity or scope of any 918 Intellectual Property Rights or other rights that might be claimed to 919 pertain to the implementation or use of the technology described in 920 this document or the extent to which any license under such rights 921 might or might not be available; nor does it represent that it has 922 made any independent effort to identify any such rights. Information 923 on the procedures with respect to rights in RFC documents can be 924 found in BCP 78 and BCP 79. 926 Copies of IPR disclosures made to the IETF Secretariat and any 927 assurances of licenses to be made available, or the result of an 928 attempt made to obtain a general license or permission for the use of 929 such proprietary rights by implementers or users of this 930 specification can be obtained from the IETF on-line IPR repository at 931 http://www.ietf.org/ipr. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights that may cover technology that may be required to implement 936 this standard. Please address the information to the IETF at 937 ietf-ipr@ietf.org. 939 Disclaimer of Validity 941 This document and the information contained herein are provided on an 942 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 943 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 944 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 945 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 946 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 947 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 949 Copyright Statement 951 Copyright (C) The Internet Society (2004). This document is subject 952 to the rights, licenses and restrictions contained in BCP 78, and 953 except as set forth therein, the authors retain all their rights. 955 Acknowledgment 957 Funding for the RFC Editor function is currently provided by the 958 Internet Society.