idnits 2.17.1 draft-ietf-v6ops-renumbering-procedure-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 933. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 949), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 8, 2004) is 7232 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-07 -- 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: 12 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: January 6, 2005 R. Droms 4 Cisco Systems 5 July 8, 2004 7 Procedures for Renumbering an IPv6 Network without a Flag Day 8 draft-ietf-v6ops-renumbering-procedure-01 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 6, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes the steps in a procedure that can be used to 42 transition from the use of an existing prefix to a new prefix in a 43 network. It uses IPv6's intrinsic ability to assign multiple 44 addresses to a network interface to provide continuity of network 45 service through a "make-before-break" transition, as well as 46 addressing naming and configuration management issues. It also uses 47 other IPv6 features to minimize the effort and time required to 48 complete the transition from the old prefix to the new prefix. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Summary of the renumbering procedure . . . . . . . . . . . 3 54 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.3 Summary of what must be changed . . . . . . . . . . . . . 4 56 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5 58 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6 59 2.1 Initial condition: stable using the old prefix . . . . . . 6 60 2.2 Preparation for the renumbering process . . . . . . . . . 6 61 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7 62 2.2.2 Mechanisms for address assignment to interfaces . . . 8 63 2.3 Configuring network elements for the new prefix . . . . . 8 64 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9 65 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10 66 2.6 Transition from use of the old prefix to the new prefix . 10 67 2.6.1 Transition of DNS service to the new prefix . . . . . 10 68 2.6.2 Transition to the use of new addresses . . . . . . . . 10 69 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11 70 2.8 Final condition: stable using the new prefix . . . . . . . 12 72 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 73 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 74 3.2 Renumbering network elements . . . . . . . . . . . . . . . 13 75 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 77 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 78 4.1 Dynamic updates to DNS across administrative domains . . . 15 79 4.2 Management of the inverse zone . . . . . . . . . . . . . . 15 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 87 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 91 A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22 93 Intellectual Property and Copyright Statements . . . . . . . . 24 95 1. Introduction 97 The Prussian military theorist Carl von Clausewitz [Clausewitz] 98 wrote, "Everything is very simple in war, but the simplest thing is 99 difficult. These difficulties accumulate and produce a friction, 100 which no man can imagine exactly who has not seen war. ... So in 101 war, through the influence of an "infinity of petty circumstances" 102 which cannot properly be described on paper, things disappoint us and 103 we fall short of the mark." Operating a network is aptly compared to 104 conducting a war. The difference is that the opponent has the futile 105 expectation that homo ignoramus will behave intelligently. 107 A "flag day" is a procedure in which the network, or a part of it, is 108 changed during a planned outage, or suddenly, causing an outage while 109 the network recovers. Avoiding outages requires the network to be 110 modified using what in mobility might be called a "make before break" 111 procedure: the network is enabled to use a new prefix while the old 112 one is still operational, operation is switched to that prefix, and 113 then the old one is taken down. 115 This document addresses the key procedural issues in renumbering an 116 IPv6 [RFC2460] network without a "flag day". The procedure is 117 straightforward to describe, but operationally can be difficult to 118 automate or execute due to issues of statically configured network 119 state, which one might aptly describe as "an infinity of petty 120 circumstances". As a result, in certain areas, this procedure is 121 necessarily incomplete, as network environments vary widely and no 122 one solution fits all. It points out a few of many areas where there 123 are multiple approaches. It may be considered an update to RFC 2072 124 [RFC2072]. This document also contains recommendations for 125 application design and network management which, if taken seriously, 126 may avoid or minimize the impact of the issues. 128 1.1 Summary of the renumbering procedure 130 By "renumbering a network" we mean replacing the use of an existing 131 (or "old") prefix throughout a network with a new prefix. Usually, 132 both prefixes will be the same length. The procedures described in 133 this document are, for the most part, equally applicable if the two 134 prefixes are not the same length. During renumbering, sub-prefixes 135 (or "link prefixes") from the old prefix, which have been assigned to 136 links throughout the network, will be replaced by link prefixes from 137 the new prefix. Interfaces on network elements and hosts throughout 138 the network will be configured with IPv6 addresses from the link 139 prefixes of the new prefix, and any addresses from the old prefix in 140 services like DNS [RFC1034][RFC1035] or configured into network 141 elements and applications will be replaced by the appropriate 142 addresses from the new prefix. 144 The renumbering procedure described in this document can be applied 145 to part of a network as well as an organization's entire network. In 146 the case of a large organization, it may be advantageous to treat the 147 network as a collection of smaller networks. Renumbering each of the 148 smaller networks separately will make the process more manageable. 149 The process described in this document is generally applicable to any 150 network, whether it is an entire organization network or part of a 151 larger network. 153 1.2 Terminology 155 DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through 156 the use of SIG(0)[RFC2535][RFC2931] and TSIG [RFC2845] 158 DHCP prefix delegation: An extension to DHCP [RFC3315] to automate 159 the assignment of a prefix; for example from an ISP to a 160 customer[RFC3633] 162 flag day: A transition which involves a planned service outage 164 ingress/egress filters: Filters applied to a router interface 165 connected to an external organization, such as an ISP, to exclude 166 traffic with inappropriate IPv6 addresses 168 link prefix: A prefix, usually a /64 [RFC3177], assigned to a link 170 Network element: Any network device, such as a router, switch or 171 firewall 173 SLAC: StateLess Address AutoConfiguration [RFC2462] 175 1.3 Summary of what must be changed 177 Addresses from the old prefix that are affected by renumbering will 178 appear in a wide variety of places in the components in the 179 renumbered network. The following list gives some of the places 180 which may include prefixes or addresses that are affected by 181 renumbering, and gives some guidance about how the work required 182 during renumbering might be minimized: 184 Link prefixes assigned to links: Each link in the network must be 185 assigned a link prefix from the new prefix. 187 IPv6 addresses assigned to interfaces on network elements: These 188 addresses are typically assigned manually, as part of configuring 189 network elements. 191 Routing information propagated by network elements 193 Link prefixes advertised by network elements [RFC2461] 195 Ingress/egress filters 197 ACLs and other embedded addresses on network elements 199 IPv6 addresses assigned to interfaces on hosts: Use of StateLess 200 Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can 201 mitigate the impact of renumbering the interfaces on hosts. 203 DNS entries: New AAAA and PTR records are added and old ones removed 204 in several phases to reflect the change of prefix. Caching times 205 are adjusted accordingly during these phases. 207 IPv6 addresses and other configuration information provided by DHCP 209 IPv6 addresses embedded in configuration files, applications and 210 elsewhere: Finding everything that must be updated and automating the 211 process may require significant effort, which is discussed in more 212 detail in Section 3. This process must be tailored to the needs 213 of each network. 215 1.4 Multihoming Issues 217 In addition to the considerations presented, the operational matters 218 of multihoming may need to be addressed. Networks are generally 219 renumbered for one of three reasons: the network itself is changing 220 its addressing policy and must renumber to implement the new policy 221 (for example, a company has been acquired and is changing addresses 222 to those used by its new owner), an upstream provider has changed its 223 prefixes and its customers are forced to do so at the same time, or a 224 company is changing providers and must perforce use addresses 225 assigned by the new provider. The third case is common. 227 When a company changes providers, it is common to institute an 228 overlap period, during which it is served by both providers. By 229 definition, the company is multihomed during such a period. While 230 this document is not about multihoming per se, problems can arise as 231 a result of ingress filtering policies applied by the upstream 232 provider or one of its upstream providers, so the user of this 233 document need also be cognizant of these issues. This is discussed 234 in detail, and approaches to dealing with it are described, in 235 [RFC2827] and [RFC3704]. 237 2. Detailed review of procedure 239 During the renumbering process, the network transitions through eight 240 states. In the initial state, the network uses just the prefix which 241 is to be replaced during the renumbering process. At the end of the 242 process, the old prefix has been entirely replaced by the new prefix, 243 and the network is using just the new prefix. To avoid a flag day 244 transition, the new prefix is deployed first and the network reaches 245 an intermediate state in which either prefix can be used. In this 246 state, individual hosts can make the transition to using the new 247 prefix as appropriate to avoid disruption of applications. Once all 248 of the hosts have made the transition to the new prefix, the network 249 is reconfigured so that the old prefix is no longer used in the 250 network. 252 In this discussion, we assume that an entire prefix is being replaced 253 with another entire prefix. It may be that only part of a prefix is 254 being changed, or that more than one prefix is being changed to a 255 single joined prefix. In such cases, the basic principles apply, but 256 will need to be modified to address the exact situation. This 257 procedure should be seen as a skeleton of a more detailed procedure 258 that has been tailored to a specific environment. Put simply, season 259 to taste. 261 2.1 Initial condition: stable using the old prefix 263 Initially, the network is using an old prefix in routing, device 264 interface addresses, filtering, firewalls and other systems. This is 265 a stable configuration. 267 2.2 Preparation for the renumbering process 269 The first step is to obtain the new prefix and new reverse zone from 270 the delegating authority. These delegations are performed using 271 established procedures, from either an internal or external 272 delegating authority. 274 Before any devices are reconfigured as a result of the renumbering 275 event, each link in the network must be assigned a sub-prefix from 276 the new prefix. While this assigned link prefix doesn't explicitly 277 appear in the configuration of any specific network element or host, 278 the network administrator performing the renumbering procedure must 279 make these link prefix assignments prior to beginning the procedure 280 to guide the configuration of network elements, assignment of 281 addresses to interfaces and modifications to network services such as 282 DNS and DHCP. 284 Prior to renumbering, various processes will need to be reconfigured 285 to confirm bindings between names and addresses more frequently. In 286 normal operation, DNS name translations and DHCP bindings are often 287 given relatively long lifetimes to limit server load. In order to 288 reduce transition time from old to new prefix it may be necessary to 289 reduce the time to live (TTL) associated with DNS records and 290 increase the frequency with which DHCP clients contact the DHCP 291 server. At the same time, a procedure must be developed through 292 which other configuration parameters will be updated during the 293 transition period when both prefixes are available. 295 2.2.1 Domain Name Service 297 During the renumbering process, the DNS database must be updated to 298 add information about addresses assigned to interfaces from the new 299 prefix and to remove addresses assigned to interfaces from the old 300 prefix. The changes to the DNS must be coordinated with the changes 301 to the addresses assigned to interfaces. 303 Changes to the information in the DNS have to propagate from the 304 server at which the change was made to the resolvers where the 305 information is used. The speed of this propagation is controlled by 306 the TTL for DNS records and the frequency of updates from primary to 307 secondary servers. 309 The latency in propagating changes in the DNS can be managed through 310 the TTL assigned to individual DNS records and through the timing of 311 updates from primary to secondary servers. Appendix A gives an 312 analysis of the factors controlling the propagation delays in the 313 DNS. 315 The suggestions for reducing the delay in the transition to new IPv6 316 addresses applies when the DNS service can be given prior notice 317 about a renumbering event. However, the DNS service for a host may 318 be in a different administrative domain than the network to which the 319 host is attached. For example, a device from organization A that 320 roams to a network belonging to organization B, the device's DNS A 321 record is still managed by organization A, where the DNS service 322 won't be given advance notice of a renumbering event in organization 323 B. 325 One strategy for updating the DNS is to allow each network device to 326 manage its own DNS information through Dynamic DNS (DDNS) 327 [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly 328 recommended, and can be accomplished through the use of either TSIG, 329 and SIG(0). Both TSIG and SIG(0) require configuration and 330 distribution of keys to end hosts and name servers in advance of the 331 renumbering event. 333 2.2.2 Mechanisms for address assignment to interfaces 335 IPv6 addresses may be assigned through SLAC, DHCP, and manual 336 processes. If DHCP is used for IPv6 address assignment, there may be 337 some delay in the assignment of IPv6 addresses from the new prefix 338 because hosts using DHCP only contact the server periodically to 339 extend the lifetimes on assigned addresses. This delay can be 340 reduced in two ways: 342 o Prior to the renumbering event, the T1 parameter (which controls 343 the time at which a host using DHCP contacts the server) can be 344 reduced. 346 o The DHCP Reconfigure message can be sent from the server to the 347 hosts to cause the hosts to contact the server. immediately 349 2.3 Configuring network elements for the new prefix 351 In this step, network elements and services are prepared for the new 352 prefix but the new prefix is not used for any datagram forwarding. 353 Throughout this step, the new prefix is added to the network 354 infrastructure in parallel with (and without interfering with) the 355 old prefix. For example, addresses assigned from the new prefix are 356 configured in addition to any addresses from the old prefix assigned 357 to interfaces on the network elements. Changes to the routing 358 infrastructure for the new prefix are added in parallel with the old 359 prefix so that forwarding for both prefixes operates in parallel. At 360 the end of this step, the network is still running on the old prefix 361 but is ready to begin using the new prefix. 363 The new prefix is added to the routing infrastructure, firewall 364 filters, ingress/egress filters and other forwarding and filtering 365 functions. The new link prefixes may be advertised by the network 366 elements, but the router advertisements should not cause hosts to 367 perform SLAC on the new link prefixes; in particular the "autonomous 368 address-configuration" flag [RFC2461] should not be set in the 369 advertisements for the new link prefixes. Network elements may have 370 IPv6 addresses from the new link prefixes assigned to interfaces, 371 taking care that this assignment does not interfere with the use of 372 IPv6 addresses from the old prefix and does not cause the new link 373 prefix to be advertised to hosts. 375 The details of this step will depend on the specific architecture of 376 the network being renumbered and the capabilities of the components 377 that make up the network infrastructure. The effort required to 378 complete this step may be mitigated by the use of DNS, DHCP prefix 379 delegation [RFC3633] and other automated configuration tools. 381 While the new prefix is being added, it will of necessity not be 382 working everywhere in the network, and unless properly protected by 383 some means such as ingress and egress access lists, the network may 384 be attacked through the new prefix in those places where it is 385 operational. 387 Once the new prefix has been added to the network infrastructure, 388 access-lists, route-maps and other network configuration options that 389 use IP addresses should be checked to ensure that hosts and services 390 that use the new prefix will behave as they did with the old one. 391 Name services other than DNS and other services that provide 392 information that will be affected by renumbering must be updated in 393 such a way as to avoid responding with stale information. There are 394 several useful approaches to identify and augment configurations: 396 Develop a mapping from each network and address derived from the 397 old prefix to each network and address derived from the new 398 prefix. Tools such as the UNIX "sed" or "perl" utilities are 399 useful to then find and augment access-lists, route-maps, and the 400 like. 402 A similar approach involves the use of such mechanisms as DHCP 403 prefix delegation to abstract networks and addresses. 405 Network elements or manually configured hosts that have IPv6 406 addresses assigned from the new prefix may be used at this point to 407 test the network infrastructure. 409 Advertisement of the prefix outside its network is the last thing to 410 be configured during this phase. One wants to have all of one's 411 defenses in place before advertising the prefix, if only because the 412 prefix may come under immediate attack. 414 At the end of this phase routing, access control, and other network 415 services should work interchangeably for both old and new prefixes. 417 2.4 Adding new host addresses 419 Once the network infrastructure for the new prefix are in place and 420 tested, IPv6 addresses from the new prefix may be assigned to host 421 interfaces. These IPv6 addresses may be assigned through SLAC, DHCP, 422 and manual processes. If SLAC is used in the network, the network 423 elements are configured to indicate that hosts should use SLAC to 424 assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 425 address assignment, the DHCP service is configured to assign IPv6 426 addresses to hosts. 428 Once the new IPv6 addresses have been assigned to the host 429 interfaces, both the forward and reverse maps within DNS should be 430 updated for the new addresses, either through automated or manual 431 means. In particular, some clients may be able to update their 432 forward maps through DDNS, while automating the update of the reverse 433 zone may be more difficult as discussed in Section 4.2. 435 2.5 Stable use of either prefix 437 Once the network has been configured with the new prefix and has had 438 sufficient time to stabilize, it becomes a stable platform with two 439 addresses configured on each and every infrastructure component 440 interface (apart from interfaces that use only the link-local 441 address), and two non-link-local addresses are available for the use 442 of any host, one in the old prefix and one in the new. This is a 443 stable configuration. 445 2.6 Transition from use of the old prefix to the new prefix 447 When the new prefix has been fully integrated into the network 448 infrastructure and has been tested for stable operation, hosts and 449 network elements can begin using the new prefix. Once the transition 450 has completed the old prefix will not be in use in the network. 452 2.6.1 Transition of DNS service to the new prefix 454 The DNS service is configured to use the new prefix by removing any 455 IPv6 addresses from the old prefix from the DNS server configuration. 456 External references to the DNS servers, such as in the DNS service 457 from which this DNS domain was delegated, are updated to use the IPv6 458 addresses from the new prefix. 460 2.6.2 Transition to the use of new addresses 462 When both prefixes are usable in the network, each host can make the 463 transition from using the old prefix to the new prefix at a time that 464 is appropriate for the applications on the host. If the host 465 transitions are randomized, DNS dynamic update mechanisms can better 466 scale to accommodate the changes to the DNS. 468 As services become available through addresses from the new prefix, 469 references to the hosts providing those services are updated to use 470 the new prefix. Addresses obtained through DNS will be automatically 471 updated when the DNS names are resolved. Addresses may also be 472 obtained through DHCP, and will be updated as hosts contact DHCP 473 servers. Addresses that are otherwise configured must be updated 474 appropriately. 476 It may be necessary to provide users with tools or other explicit 477 procedures to complete the transition from the use of the old prefix 478 to the new prefix, because some applications and operating system 479 functions may be configured in ways that do not use DNS at all or 480 will not use DNS to resolve a domain name to a new address once the 481 new prefix is available. For example, a device that only uses DNS to 482 resolve the name of an NTP server when the device is initialized will 483 not obtain the address from the new prefix for that server at this 484 point in the renumbering process. 486 This last point warrants repeating (in a slightly different form). 487 Applications may cache addressing information in different ways, for 488 varying lengths of time. They may cache this information in memory, 489 on a file system, or in a database. Only after careful observation 490 and consideration of one"s environment should one conclude that a 491 prefix is no longer in use. For more information on this issue, 492 please see [I-D.ietf-dnsop-ipv6-dns-issues]. 494 The transition of critical services, such as DNS, DHCP, NTP [RFC1305] 495 and important business services should be managed and tested 496 carefully to avoid service outages. Each host should take reasonable 497 precautions prior to changing to the use of the new prefix to 498 minimize the chance of broken connections. For example, utilities 499 such as netstat and network analyzers can be used to determine if any 500 existing connections to the host are still using the address from the 501 old prefix for that host. 503 Link prefixes from the old prefix in router advertisements and 504 addresses from the old prefix provided through DHCP should have their 505 preferred lifetimes set to zero at this point, so that hosts will not 506 use the old prefixes for new communications. 508 2.7 Removing the old prefix 510 Once all sessions are deemed to have completed, there will be no 511 dependence on the old prefix. It may be removed from the 512 configuration of the routing system, and from any static 513 configurations that depend on it.If any configuration has been 514 created based on DNS information, the configuration should be 515 refreshed after the old prefixes have been removed from the DNS. 517 During this phase the registries are informed that the old prefix is 518 no longer in use, and addresses within that prefix are removed from A 519 records associated with name servers and the corresponding name 520 server configurations. 522 In addition, DNS reverse maps for the old prefix may be removed from 523 the primary name server and the zone delegation may be removed from 524 the parent zone. Any DNS, DHCP, or SLAC timers that were changed 525 should be reset to their original values (most notably the DNS 526 forward map TTL). 528 2.8 Final condition: stable using the new prefix 530 This is equivalent to the first state, but using the new prefix. 532 3. How to avoid shooting yourself in the foot 534 The difficult operational issues in Section 2.3, Section 2.6, and 535 Section 2.7 are in dealing with the configurations of routers and 536 hosts which are not under the control of the network administrator or 537 are manually configured. Examples of such devices include voice over 538 IP (VoIP) telephones with static configuration of boot or name 539 servers, dedicated devices used in manufacturing that are configured 540 with the IP addresses for specific services, the boot servers of 541 routers and switches, etc. 543 3.1 "Find all the places..." 545 Application designers frequently take short-cuts to save memory or 546 increase responsiveness, and a common short-cut is to use static 547 configuration of IP addresses rather than DNS translation to obtain 548 the same. The downside of such behavior should be apparent; such a 549 poorly designed application cannot even add or replace a server 550 easily, much less change servers or reorganize its address space. 551 The short-cut ultimately becomes expensive to maintain and hard to 552 change or replace. 554 As a result, in view of the possibility that a network may need to be 555 renumbered in the future, any application: 557 o should obtain addresses of other systems or services from the DNS, 558 rather then having those addresses manually configured, 560 o must obtain a new translation if a new session is opened with the 561 same service after the lifetime of the DNS RR expires, 563 o when addresses are configured rather than translated, should 564 provide a convenient programmatic method to reconfigure the 565 addresses that can be executed using a script or its equivalent. 567 Application designers, equipment vendors, and the Open Source 568 community should take note. There is an opportunity to serve their 569 customers well in this area, and network operators should take note 570 to either develop or purchase appropriate tools. 572 3.2 Renumbering network elements 574 The configuration and operation of network elements may be designed 575 to use static configuration with IP addresses or resolve domain names 576 only once and use the resulting IP addresses until the element is 577 restarted. These static configurations complicate the process of 578 renumbering, requiring administration of all of the static 579 information and manual configuration during a renumbering event. 581 Because network elements are usually single-purpose devices, the user 582 interface and operating functions (software and hardware) are often 583 better integrated than independent services running on a server 584 platform. Thus, it is likely that network element vendors can design 585 and implement consistent support for renumbering across all of the 586 functions of network elements. 588 To better support renumbering, network elements can: 590 o use domain names for configuration wherever possible, and should 591 resolve those names using the DNS when the lifetime on the name 592 expires 594 o provide uniform support for renumbering in all user interface and 595 configuration mechanisms, such as replacement of one prefix with 596 another through a single command 598 o reconfigure services provided by the network element, such as 599 router advertisements and DHCP, for a new prefix with a single 600 command 602 3.3 Ingress Filtering 604 An important consideration in Section 2.3, in the case where the 605 network being renumbered is connected to an external provider, the 606 network's ingress filtering policy and its provider's ingress 607 filtering policy. Both the network firewall's ingress filter and the 608 provider's ingress filter on the access link to the network should be 609 configured to prevent attacks that use source address spoofing. 610 Ingress filtering is considered in detail in "Ingress Filtering for 611 Multihomed Networks" [RFC3704]. 613 4. Call to Action for the IETF 615 The more automated one can make the renumbering process, the better 616 for everyone. Sadly, there are several mechanisms that either have 617 not been automated, or have not been automated consistently across 618 platforms. 620 4.1 Dynamic updates to DNS across administrative domains 622 The configuration files for a DNS server (such as named.conf) will 623 contain addresses that must be reconfigured manually during a 624 renumbering event. There is currently no easy way to automate the 625 update of these addresses, as the updates require both complex trust 626 relationships and automation to verify them. For instance, a reverse 627 zone is delegated by an upstream ISP, but there is currently no 628 mechanism to note additional delegations. 630 4.2 Management of the inverse zone 632 In networks where hosts obtain IPv6 addresses through SLAC, updates 633 of reverse zone are problematic because of lack of trust relationship 634 between administrative domain owning the prefix and the host 635 assigning the low 64 bits using SLAC. For example, suppose a host, 636 H, from organization A is connected to a network owned by 637 organization B. When H obtains a new address during a renumbering 638 event through SLAC, H will need to update its reverse entry in the 639 DNS through a DNS server from B that owns the reverse zone for the 640 new address. For H to update its reverse entry, the DNS server from 641 B must accept a DDNS request from H, requiring that an 642 inter-administrative domain trust relationship exist between H and B. 643 The IETF should develop a BCP recommendation for addressing this 644 problem. 646 5. Security Considerations 648 The process of renumbering is straightforward in theory but can be 649 difficult and dangerous in practice. The threats fall into two broad 650 categories: those arising from misconfiguration and those which are 651 actual attacks. 653 Misconfigurations can easily arise if any system in the network 654 "knows" the old prefix, or an address in it, a priori and is not 655 configured with the new prefix, or if the new prefix is configured in 656 a manner which replaces the old instead of being co-equal to it for a 657 period of time. Simplistic examples include: 659 Neglecting to reconfigure a system that is using the old prefix in 660 some static configuration: In this case, when the old prefix is 661 removed from the network, whatever feature was so configured 662 becomes inoperative - it is not configured for the new prefix, and 663 the old prefix is irrelevant. 665 Configuring a system via an IPv6 address, and replacing that old 666 address with a new address: Because the TCP connection is using the 667 old and now invalid IPv6 address, the SSH session will be 668 terminated and you will have to use SSH through the new address 669 for additional configuration changes. 671 Removing the old configuration before supplying the new: In this 672 case, it may be necessary to obtain on-site support or travel to 673 the system and access it via its console. 675 Clearly, taking the extra time to add the new prefix to the 676 configuration, allow the network to settle, and then remove the old 677 obviates this class of issue. A special consideration applies when 678 some devices are only occasionally used; the administration must 679 allow sufficiently long in Section 2.6 to ensure that their 680 likelihood of detection is sufficiently high. 682 A subtle case of this type can result when the DNS is used to 683 populate access control lists and similar security or QoS 684 configurations. DNS names used to translate between system or 685 service names and corresponding addresses are treated in this 686 procedure as providing the address in the preferred prefix, which is 687 either the old or the new prefix but not both. Such DNS names 688 provide a means in Section 2.6 to cause systems in the network to 689 stop using the old prefix to access servers or peers and cause them 690 to start using the new prefix. DNS names used for access control 691 lists, however, need to go through the same three step procedure used 692 for other access control lists, having the new prefix added to them 693 in Section 2.3 and the old prefix removed in Section 2.7. 695 Attacks are also possible. Suppose, for example, that the new prefix 696 has been presented by a service provider, and the service provider 697 starts advertising the prefix before the customer network is ready. 698 The new prefix might be targeted in a distributed denial of service 699 attack, or a system might be broken into using an application that 700 would not cross the firewall using the old prefix, before the 701 network's defenses have been configured. Clearly, one wants to 702 configure the defenses first and only then accessibility and routing, 703 as described in Section 2.3 and Section 3.3. 705 The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic 706 DNS provides a capability for updating DNS accordingly. Managing 707 configuration items apart from those procedures is most obviously 708 straightforward if all such configurations are generated from a 709 central configuration repository or database, or if they can all be 710 read into a temporary database, changed using appropriate scripts, 711 and applied to the appropriate systems. Any place where scripted 712 configuration management is not possible or is not used must be 713 tracked and managed manually. Here, there be dragons. 715 In ingress filtering of a multihomed network, an easy solution to the 716 issues raised in Section 3.3 might recommend that ingress filtering 717 should not be done for multihomed customers or that ingress filtering 718 should be special-cased. However, this has an impact on Internet 719 security. A sufficient level of ingress filtering is needed to 720 prevent attacks using spoofed source addresses. Another problem 721 becomes from the fact that if ingress filtering is made too difficult 722 (e.g. by requiring special casing in every ISP doing it), it might 723 not be done at an ISP at all. Therefore, any mechanism depending on 724 relaxing ingress filtering checks should be dealt with an extreme 725 care. 727 6. Acknowledgments 729 This document grew out of a discussion on the IETF list. Commentary 730 on the document came from Bill Fenner, Christian Huitema, Craig 731 Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand, 732 Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, 733 Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, 734 Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain. 736 Some took it on themselves to convince the author that the concept of 737 network renumbering as a normal or frequent procedure is daft. Their 738 comments, if they result in improved address management practices in 739 networks, may be the best contribution this note has to offer. 741 Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described 742 the ingress filtering issues. 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-07 (work in progress), 784 May 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 Authors' Addresses 825 Fred Baker 826 Cisco Systems 827 1121 Via Del Rey 828 Santa Barbara, CA 93117 829 US 831 Phone: 408-526-4257 832 Fax: 413-473-2403 833 EMail: fred@cisco.com 834 Eliot Lear 835 Cisco Systems 836 170 W. Tasman Dr. 837 San Jose, CA 95134 838 US 840 Phone: +1 408 527 4020 841 EMail: lear@cisco.com 843 Ralph Droms 844 Cisco Systems 845 200 Beaver Brook Road 846 Boxborough, MA 01719 847 US 849 Phone: +1 978 936-1674 850 EMail: rdroms@cisco.com 852 Appendix A. Managing Latency in the DNS 854 The procedure in this section can be used to determine and manage the 855 latency in updates to information a DNS resource record (RR). 857 There are several kinds of possible delays which are ignored in these 858 calculations: 860 o the time it takes for the administrators to make the changes, 862 o the time it may take to wait for the DNS update, if the 863 secondaries are only updated at regular intervals, and not 864 immediately, and 866 o the time the updating to all the secondaries takes. 868 Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer 869 updated information from the primary DNS server to any secondary 870 servers; this is a very quick update process, and the actual time to 871 update of information is not considered significant. 873 There's a target time, TC, at which we want to change the contents of 874 a DNS RR. The RR is currently configured with TTL == TTLOLD. Any 875 cached references to the RR will expire no more than TTLOLD in the 876 future. 878 At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured 879 with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to 880 push the RR to the secondaries. After the update, responses to 881 queries for the RR are returned with TTLNEW. There are still some 882 cached references with TTLOLD. 884 At time TC - TTLNEW, the RR in the primary is configured with the new 885 address. The update process is initiated to push the RR to the 886 secondaries. After the update, responses to queries for the RR 887 return the new address. All the cached references have TTLNEW. 888 Between this time and TC, responses to queries for the RR may be 889 returned with either the old address or the new address. This 890 ambiguity is acceptable, assuming the host is configured to respond 891 to both addresses. 893 At time TC all the cached references with the old address have 894 expired, and all subsequent queries will return the new address. 895 After TC (corresponding to the final state described in Section 2.8), 896 the TTL on the RR can be set to the initial value TTLOLD. 898 The network administrator can choose TTLOLD and TTLNEW to meet local 899 requirements. 901 As a concrete example, consider a case where TTLOLD is a week (168 902 hours), and TTLNEW is an hour. The preparation for the change of 903 addresses begins 169 hours before the address change. After 168 904 hours have passed and only one hour is left, the TTLNEW has 905 propagated everywhere, and one can change the address record(s). 906 These are propagated within the hour, after which one can restore TTL 907 value to a larger value. This approach minimizes time where it's 908 uncertain what kind of (address) information is returned from the 909 DNS. 911 Intellectual Property Statement 913 The IETF takes no position regarding the validity or scope of any 914 Intellectual Property Rights or other rights that might be claimed to 915 pertain to the implementation or use of the technology described in 916 this document or the extent to which any license under such rights 917 might or might not be available; nor does it represent that it has 918 made any independent effort to identify any such rights. Information 919 on the procedures with respect to rights in RFC documents can be 920 found in BCP 78 and BCP 79. 922 Copies of IPR disclosures made to the IETF Secretariat and any 923 assurances of licenses to be made available, or the result of an 924 attempt made to obtain a general license or permission for the use of 925 such proprietary rights by implementers or users of this 926 specification can be obtained from the IETF on-line IPR repository at 927 http://www.ietf.org/ipr. 929 The IETF invites any interested party to bring to its attention any 930 copyrights, patents or patent applications, or other proprietary 931 rights that may cover technology that may be required to implement 932 this standard. Please address the information to the IETF at 933 ietf-ipr@ietf.org. 935 Disclaimer of Validity 937 This document and the information contained herein are provided on an 938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 940 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 941 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 942 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Copyright Statement 947 Copyright (C) The Internet Society (2004). This document is subject 948 to the rights, licenses and restrictions contained in BCP 78, and 949 except as set forth therein, the authors retain all their rights. 951 Acknowledgment 953 Funding for the RFC Editor function is currently provided by the 954 Internet Society.