idnits 2.17.1 draft-ietf-v6ops-renumbering-procedure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 145 has weird spacing: '...example from ...' == Line 813 has weird spacing: '...ndaries are o...' -- 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 (February 5, 2004) is 7385 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) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '3') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '8') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '9') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '10') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '12') (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '15') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '16') (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group F. Baker 3 Internet-Draft E. Lear 4 Expires: August 5, 2004 R. Droms 5 Cisco Systems 6 February 5, 2004 8 Procedures for Renumbering an IPv6 Network without a Flag Day 9 draft-ietf-v6ops-renumbering-procedure-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 5, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes the steps in a procedure that can be used to 40 transition from the use of an existing prefix to a new prefix in a 41 network. It uses IPv6's intrinsic ability to assign multiple 42 addresses to a network interface to provide continuity of network 43 service through a "make-before-break" transition, as well as 44 addressing naming and configuration management issues. It also uses 45 other IPv6 features to minimize the effort and time required to 46 complete the transition from the old prefix to the new prefix. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Summary of the renumbering procedure . . . . . . . . . . . . 3 52 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.3 Summary of what must be changed . . . . . . . . . . . . . . 4 54 2. Detailed review of procedure . . . . . . . . . . . . . . . . 5 55 2.1 Initial condition: stable using the old prefix . . . . . . . 6 56 2.2 Preparation for the renumbering process . . . . . . . . . . 6 57 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . . . . 6 58 2.2.2 Mechanisms for address assignment to interfaces . . . . . . 7 59 2.3 Configuring network elements for the new prefix . . . . . . 7 60 2.4 Adding new host addresses . . . . . . . . . . . . . . . . . 9 61 2.5 Stable use of either prefix . . . . . . . . . . . . . . . . 9 62 2.6 Transition from use of the old prefix to the new prefix . . 9 63 2.6.1 Transition of DNS service to the new prefix . . . . . . . . 10 64 2.6.2 Transition to the use of new addresses . . . . . . . . . . . 10 65 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . . 11 66 2.8 Final condition: stable using the new prefix . . . . . . . . 11 67 3. How to avoid shooting yourself in the foot . . . . . . . . . 11 68 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . . 11 69 3.2 Renumbering network elements . . . . . . . . . . . . . . . . 12 70 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 13 71 4. Call to Action for the IETF . . . . . . . . . . . . . . . . 13 72 4.1 Dynamic updates to DNS across administrative domains . . . . 13 73 4.2 Management of the inverse zone . . . . . . . . . . . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 77 Informative References . . . . . . . . . . . . . . . . . . . 16 78 A. Managing Latency in the DNS . . . . . . . . . . . . . . . . 18 79 Intellectual Property and Copyright Statements . . . . . . . 20 81 1. Introduction 83 The Prussian military theorist Carl von Clausewitz [20] wrote, 84 "Everything is very simple in war, but the simplest thing is 85 difficult. These difficulties accumulate and produce a friction, 86 which no man can imagine exactly who has not seen war. ... So in war, 87 through the influence of an "infinity of petty circumstances" which 88 cannot properly be described on paper, things disappoint us and we 89 fall short of the mark." Operating a network is aptly compared to 90 conducting a war. The difference is that the opponent has the futile 91 expectation that homo ignoramus will behave intelligently. 93 A "flag day" is a procedure in which the network, or a part of it, is 94 changed during a planned outage, or suddenly, causing an outage while 95 the network recovers. Avoiding outages requires the network to be 96 modified using what in mobility might be called a "make before break" 97 procedure: the network is enabled to use a new prefix while the old 98 one is still operational, operation is switched to that prefix, and 99 then the old one is taken down. 101 This document addresses the key procedural issues in renumbering an 102 IPv6 [8] network without a "flag day". The procedure is 103 straightforward to describe, but operationally can be difficult to 104 automate or execute due to issues of statically configured network 105 state, which one might aptly describe as "an infinity of petty 106 circumstances". As a result, in certain areas, this procedure is 107 necessarily incomplete, as network environments vary widely and no 108 one solution fits all. It points out a few of many areas where there 109 are multiple approaches. It may be considered an update to RFC 2072 110 [6]. This document also contains recommendations for application 111 design and network management which, if taken seriously, may avoid or 112 minimize the impact of the issues. 114 1.1 Summary of the renumbering procedure 116 By "renumbering a network" we mean replacing the use of an existing 117 (or "old") prefix throughout a network with a new prefix. Usually, 118 both prefixes will be the same length. The procedures described in 119 this document are, for the most part, equally applicable if the two 120 prefixes are not the same length. During renumbering, sub-prefixes 121 (or "link prefixes") from the old prefix, which have been assigned to 122 links throughout the network, will be replaced by link prefixes from 123 the new prefix. Interfaces on network elements and hosts throughout 124 the network will be configured with IPv6 addresses from the link 125 prefixes of the new prefix, and any addresses from the old prefix in 126 services like DNS [1][2] or configured into network elements and 127 applications will be replaced by the appropriate addresses from the 128 new prefix. 130 The renumbering procedure described in this document can be applied 131 to part of a network as well as an organization's entire network. In 132 the case of a large organization, it may be advantageous to treat the 133 network as a collection of smaller networks. Renumbering each of the 134 smaller networks separately will make the process more manageable. 135 The process described in this document is generally applicable to any 136 network, whether it is an entire organization network or part of a 137 larger network. 139 1.2 Terminology 141 DDNS: Dynamic DNS [7][14]; DDNS updates can be secured through 142 the use of SIG(0)[11][13] and TSIG [12] 144 DHCP prefix delegation: An extension to DHCP [16] to automate the 145 assignment of a prefix; for example from an ISP to a customer[17] 147 flag day: A transition which involves a planned service outage 149 ingress/egress filters: Filters applied to a router interface 150 connected to an external organization, such as an ISP, to exclude 151 traffic with inappropriate IPv6 addresses 153 link prefix: A prefix, usually a /64 [15], assigned to a link 155 Network element: Any network device, such as a router, switch or 156 firewall 158 SLAC: StateLess Address autoConfiguration [10] 160 1.3 Summary of what must be changed 162 Addresses from the old prefix that are affected by renumbering will 163 appear in a wide variety of places in the components in the 164 renumbered network. The following list gives some of the places which 165 may include prefixes or addresses that are affected by renumbering, 166 and gives some guidance about how the work required during 167 renumbering might be minimized: 169 Link prefixes assigned to links: Each link in the network must be 170 assigned a link prefix from the new prefix. 172 IPv6 addresses assigned to interfaces on network elements: These 173 addresses are typically assigned manually, as part of configuring 174 network elements. 176 Routing information propagated by network elements 178 Link prefixes advertised by network elements [9] 180 Ingress/egress filters 182 ACLs and other embedded addresses on network elements 184 IPv6 addresses assigned to interfaces on hosts: Use of StateLess 185 Address Configuration [10] (SLAC) or DHCP [16] can mitigate the 186 impact of renumbering the interfaces on hosts. 188 DNS entries: New AAAA and PTR records are added and old ones removed 189 in several phases to reflect the change of prefix. Caching times 190 are adjusted accordingly during these phases. 192 IPv6 addresses and other configuration information provided by DHCP 194 IPv6 addresses embedded in configuration files, applications and 195 elsewhere: Finding everything that must be updated and automating the 196 process may require significant effort, which is discussed in more 197 detail in Section 3. This process must be tailored to the needs 198 of each network. 200 2. Detailed review of procedure 202 During the renumbering process, the network transitions through eight 203 states. In the initial state, the network uses just the prefix which 204 is to be replaced during the renumbering process. At the end of the 205 process, the old prefix has been entirely replaced by the new prefix, 206 and the network is using just the new prefix. To avoid a flag day 207 transition, the new prefix is deployed first and the network reaches 208 an intermediate state in which either prefix can be used. In this 209 state, individual hosts can make the transition to using the new 210 prefix as appropriate to avoid disruption of applications. Once all 211 of the hosts have made the transition to the new prefix, the network 212 is reconfigured so that the old prefix is no longer used in the 213 network. 215 In this discussion, we assume that an entire prefix is being replaced 216 with another entire prefix. It may be that only part of a prefix is 217 being changed, or that more than one prefix is being changed to a 218 single joined prefix. In such cases, the basic principles apply, but 219 will need to be modified to address the exact situation. This 220 procedure should be seen as a skeleton of a more detailed procedure 221 that has been tailored to a specific environment. Put simply, season 222 to taste. 224 2.1 Initial condition: stable using the old prefix 226 Initially, the network is using an old prefix in routing, device 227 interface addresses, filtering, firewalls and other systems. This is 228 a stable configuration. 230 2.2 Preparation for the renumbering process 232 The first step is to obtain the new prefix and new reverse zone from 233 the delegating authority. These delegations are performed using 234 established procedures, from either an internal or external 235 delegating authority. 237 Before any devices are reconfigured as a result of the renumbering 238 event, each link in the network must be assigned a sub-prefix from 239 the new prefix. While this assigned link prefix doesn't explicitly 240 appear in the configuration of any specific network element or host, 241 the network administrator performing the renumbering procedure must 242 make these link prefix assignments prior to beginning the procedure 243 to guide the configuration of network elements, assignment of 244 addresses to interfaces and modifications to network services such as 245 DNS and DHCP. 247 Prior to renumbering, various processes will need to be reconfigured 248 to confirm bindings between names and addresses more frequently. In 249 normal operation, DNS name translations and DHCP bindings are often 250 given relatively long lifetimes to limit server load. In order to 251 reduce transition time from old to new prefix it may be necessary to 252 reduce the time to live (TTL) associated with DNS records and 253 increase the frequency with which DHCP clients contact the DHCP 254 server. At the same time, a procedure must be developed through 255 which other configuration parameters will be updated during the 256 transition period when both prefixes are available. 258 2.2.1 Domain Name Service 260 During the renumbering process, the DNS database must be updated to 261 add information about addresses assigned to interfaces from the new 262 prefix and to remove addresses assigned to interfaces from the old 263 prefix. The changes to the DNS must be coordinated with the changes 264 to the addresses assigned to interfaces. 266 Changes to the information in the DNS have to propagate from the 267 server at which the change was made to the resolvers where the 268 information is used. The speed of this propagation is controlled by 269 the TTL for DNS records and the frequency of updates from primary to 270 secondary servers. 272 The latency in propagating changes in the DNS can be managed through 273 the TTL assigned to individual DNS records and through the timing of 274 updates from primary to secondary servers. Appendix A gives an 275 analysis of the factors controlling the propagation delays in the 276 DNS. 278 The suggestions for reducing the delay in the transition to new IPv6 279 addresses applies when the DNS service can be given prior notice 280 about a renumbering event. However, the DNS service for a host may 281 be in a different administrative domain than the network to which the 282 host is attached. For example, a device from organization A that 283 roams to a network belonging to organization B, the device's DNS A 284 record is still managed by organization A, where the DNS service 285 won't be given advance notice of a renumbering event in organization 286 B. 288 One strategy for updating the DNS is to allow each network device to 289 manage its own DNS information through Dynamic DNS (DDNS) [7][14]. 290 Authentication of these DDNS updates is strongly recommended, and can 291 be accomplished through the use of either TSIG, and SIG(0). Both TSIG 292 and SIG(0) require configuration and distribution of keys to end 293 hosts and name servers in advance of the renumbering event. 295 2.2.2 Mechanisms for address assignment to interfaces 297 IPv6 addresses may be assigned through SLAC, DHCP, and manual 298 processes. If DHCP is used for IPv6 address assignment, there may be 299 some delay in the assignment of IPv6 addresses from the new prefix 300 because hosts using DHCP only contact the server periodically to 301 extend the lifetimes on assigned addresses. This delay can be reduced 302 in two ways: 304 o Prior to the renumbering event, the T1 parameter (which controls 305 the time at which a host using DHCP contacts the server) can be 306 reduced. 308 o The DHCP Reconfigure message can be sent from the server to the 309 hosts to cause the hosts to contact the server. immediately 311 2.3 Configuring network elements for the new prefix 313 In this step, network elements and services are prepared for the new 314 prefix but the new prefix is not used for any datagram forwarding. 315 Throughout this step, the new prefix is added to the network 316 infrastructure in parallel with (and without interfering with) the 317 old prefix. For example, addresses assigned from the new prefix are 318 configured in addition to any addresses from the old prefix assigned 319 to interfaces on the network elements. Changes to the routing 320 infrastructure for the new prefix are added in parallel with the old 321 prefix so that forwarding for both prefixes operates in parallel. At 322 the end of this step, the network is still running on the old prefix 323 but is ready to begin using the new prefix. 325 The new prefix is added to the routing infrastructure, firewall 326 filters, ingress/egress filters and other forwarding and filtering 327 functions. The new link prefixes may be advertised by the network 328 elements, but the router advertisements should not cause hosts to 329 perform SLAC on the new link prefixes; in particular the "autonomous 330 address-configuration" flag [9] should not be set in the 331 advertisements for the new link prefixes. Network elements may have 332 IPv6 addresses from the new link prefixes assigned to interfaces, 333 taking care that this assignment does not interfere with the use of 334 IPv6 addresses from the old prefix and does not cause the new link 335 prefix to be advertised to hosts. 337 The details of this step will depend on the specific architecture of 338 the network being renumbered and the capabilities of the components 339 that make up the network infrastructure. The effort required to 340 complete this step may be mitigated by the use of DNS, DHCP prefix 341 delegation [17] and other automated configuration tools. 343 While the new prefix is being added, it will of necessity not be 344 working everywhere in the network, and unless properly protected by 345 some means such as ingress and egress access lists, the network may 346 be attacked through the new prefix in those places where it is 347 operational. 349 Once the new prefix has been added to the network infrastructure, 350 access-lists, route-maps and other network configuration options that 351 use IP addresses should be checked to ensure that hosts and services 352 that use the new prefix will behave as they did with the old one. 353 Name services other than DNS and other services that provide 354 information that will be affected by renumbering must be updated in 355 such a way as to avoid responding with stale information. There are 356 several useful approaches to identify and augment configurations: 358 Develop a mapping from each network and address derived from the 359 old prefix to each network and address derived from the new 360 prefix. Tools such as the UNIX "sed" or "perl" utilities are 361 useful to then find and augment access-lists, route-maps, and the 362 like. 364 A similar approach involves the use of such mechanisms as DHCP 365 prefix delegation to abstract networks and addresses. 367 Network elements or manually configured hosts that have IPv6 368 addresses assigned from the new prefix may be used at this point to 369 test the network infrastructure. 371 Advertisement of the prefix outside its network is the last thing to 372 be configured during this phase. One wants to have all of one's 373 defenses in place before advertising the prefix, if only because the 374 prefix may come under immediate attack. 376 At the end of this phase routing, access control, and other network 377 services should work interchangeably for both old and new prefixes. 379 2.4 Adding new host addresses 381 Once the network infrastructure for the new prefix are in place and 382 tested, IPv6 addresses from the new prefix may be assigned to host 383 interfaces. These IPv6 addresses may be assigned through SLAC, DHCP, 384 and manual processes. If SLAC is used in the network, the network 385 elements are configured to indicate that hosts should use SLAC to 386 assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 387 address assignment, the DHCP service is configured to assign IPv6 388 addresses to hosts. 390 Once the new IPv6 addresses have been assigned to the host 391 interfaces, both the forward and reverse maps within DNS should be 392 updated for the new addresses, either through automated or manual 393 means. In particular, some clients may be able to update their 394 forward maps through DDNS, while automating the update of the reverse 395 zone may be more difficult as discussed in Section 4.2. 397 2.5 Stable use of either prefix 399 Once the network has been configured with the new prefix and has had 400 sufficient time to stabilize, it becomes a stable platform with two 401 addresses configured on each and every infrastructure component 402 interface (apart from interfaces that use only the link-local 403 address), and two non-link-local addresses are available for the use 404 of any host, one in the old prefix and one in the new. This is a 405 stable configuration. 407 2.6 Transition from use of the old prefix to the new prefix 409 When the new prefix has been fully integrated into the network 410 infrastructure and has been tested for stable operation, hosts and 411 network elements can begin using the new prefix. Once the transition 412 has completed the old prefix will not be in use in the network. 414 2.6.1 Transition of DNS service to the new prefix 416 The DNS service is configured to use the new prefix by removing any 417 IPv6 addresses from the old prefix from the DNS server configuration. 418 External references to the DNS servers, such as in the DNS service 419 from which this DNS domain was delegated, are updated to use the IPv6 420 addresses from the new prefix. 422 2.6.2 Transition to the use of new addresses 424 When both prefixes are usable in the network, each host can make the 425 transition from using the old prefix to the new prefix at a time that 426 is appropriate for the applications on the host. If the host 427 transitions are randomized, DNS dynamic update mechanisms can better 428 scale to accommodate the changes to the DNS. 430 As services become available through addresses from the new prefix, 431 references to the hosts providing those services are updated to use 432 the new prefix. Addresses obtained through DNS will be automatically 433 updated when the DNS names are resolved. Addresses may also be 434 obtained through DHCP, and will be updated as hosts contact DHCP 435 servers. Addresses that are otherwise configured must be updated 436 appropriately. 438 It may be necessary to provide users with tools or other explicit 439 procedures to complete the transition from the use of the old prefix 440 to the new prefix, because some applications and operating system 441 functions may be configured in ways that do not use DNS at all or 442 will not use DNS to resolve a domain name to a new address once the 443 new prefix is available. For example, a device that only uses DNS to 444 resolve the name of an NTP server when the device is initialized will 445 not obtain the address from the new prefix for that server at this 446 point in the renumbering process. 448 This last point warrants repeating (in a slightly different form). 449 Applications may cache addressing information in different ways, for 450 varying lengths of time. They may cache this information in memory, 451 on a file system, or in a database. Only after careful observation 452 and consideration of one"s environment should one conclude that a 453 prefix is no longer in use. For more information on this issue, 454 please see [18]. 456 The transition of critical services, such as DNS, DHCP, NTP [3] and 457 important business services should be managed and tested carefully to 458 avoid service outages. Each host should take reasonable precautions 459 prior to changing to the use of the new prefix to minimize the chance 460 of broken connections. For example, utilities such as netstat and 461 network analyzers can be used to determine if any existing 462 connections to the host are still using the address from the old 463 prefix for that host. 465 Link prefixes from the old prefix in router advertisements and 466 addresses from the old prefix provided through DHCP should have their 467 preferred lifetimes set to zero at this point, so that hosts will not 468 use the old prefixes for new communications. 470 2.7 Removing the old prefix 472 Once all sessions are deemed to have completed, there will be no 473 dependence on the old prefix. It may be removed from the 474 configuration of the routing system, and from any static 475 configurations that depend on it.If any configuration has been 476 created based on DNS information, the configuration should be 477 refreshed after the old prefixes have been removed from the DNS. 479 During this phase the registries are informed that the old prefix is 480 no longer in use, and addresses within that prefix are removed from A 481 records associated with name servers and the corresponding name 482 server configurations. 484 In addition, DNS reverse maps for the old prefix may be removed from 485 the primary name server and the zone delegation may be removed from 486 the parent zone. Any DNS, DHCP, or SLAC timers that were changed 487 should be reset to their original values (most notably the DNS 488 forward map TTL). 490 2.8 Final condition: stable using the new prefix 492 This is equivalent to the first state, but using the new prefix. 494 3. How to avoid shooting yourself in the foot 496 The difficult operational issues in Section 2.3, Section 2.6, and 497 Section 2.7 are in dealing with the configurations of routers and 498 hosts which are not under the control of the network administrator or 499 are manually configured. Examples of such devices include voice over 500 IP (VoIP) telephones with static configuration of boot or name 501 servers, dedicated devices used in manufacturing that are configured 502 with the IP addresses for specific services, the boot servers of 503 routers and switches, etc. 505 3.1 "Find all the places..." 507 Application designers frequently take short-cuts to save memory or 508 increase responsiveness, and a common short-cut is to use static 509 configuration of IP addresses rather than DNS translation to obtain 510 the same. The downside of such behavior should be apparent; such a 511 poorly designed application cannot even add or replace a server 512 easily, much less change servers or reorganize its address space. The 513 short-cut ultimately becomes expensive to maintain and hard to change 514 or replace. 516 As a result, in view of the possibility that a network may need to be 517 renumbered in the future, any application: 519 o should obtain addresses of other systems or services from the DNS, 520 rather then having those addresses manually configured, 522 o must obtain a new translation if a new session is opened with the 523 same service after the lifetime of the DNS RR expires, 525 o when addresses are configured rather than translated, should 526 provide a convenient programmatic method to reconfigure the 527 addresses that can be executed using a script or its equivalent. 529 Application designers, equipment vendors, and the Open Source 530 community should take note. There is an opportunity to serve their 531 customers well in this area, and network operators should take note 532 to either develop or purchase appropriate tools. 534 3.2 Renumbering network elements 536 The configuration and operation of network elements may be designed 537 to use static configuration with IP addresses or resolve domain names 538 only once and use the resulting IP addresses until the element is 539 restarted. These static configurations complicate the process of 540 renumbering, requiring administration of all of the static 541 information and manual configuration during a renumbering event. 543 Because network elements are usually single-purpose devices, the user 544 interface and operating functions (software and hardware) are often 545 better integrated than independent services running on a server 546 platform. Thus, it is likely that network element vendors can design 547 and implement consistent support for renumbering across all of the 548 functions of network elements. 550 To better support renumbering, network elements can: 552 o use domain names for configuration wherever possible, and should 553 resolve those names using the DNS when the lifetime on the name 554 expires 556 o provide uniform support for renumbering in all user interface and 557 configuration mechanisms, such as replacement of one prefix with 558 another through a single command 560 o reconfigure services provided by the network element, such as 561 router advertisements and DHCP, for a new prefix with a single 562 command 564 3.3 Ingress Filtering 566 An important consideration in Section 2.3, in the case where the 567 network being renumbered is connected to an external provider, the 568 network's ingress filtering policy and its provider's ingress 569 filtering policy. Both the network firewall's ingress filter and the 570 provider's ingress filter on the access link to the network should be 571 configured to prevent attacks that use source address spoofing. 572 Ingress filtering is considered in detail in "Ingress Filtering for 573 Multihomed Networks" [19]. 575 4. Call to Action for the IETF 577 The more automated one can make the renumbering process, the better 578 for everyone. Sadly, there are several mechanisms that either have 579 not been automated, or have not been automated consistently across 580 platforms. 582 4.1 Dynamic updates to DNS across administrative domains 584 The configuration files for a DNS server (such as named.conf) will 585 contain addresses that must be reconfigured manually during a 586 renumbering event. There is currently no easy way to automate the 587 update of these addresses, as the updates require both complex trust 588 relationships and automation to verify them. For instance, a reverse 589 zone is delegated by an upstream ISP, but there is currently no 590 mechanism to note additional delegations. 592 4.2 Management of the inverse zone 594 In networks where hosts obtain IPv6 addresses through SLAC, updates 595 of reverse zone are problematic because of lack of trust relationship 596 between administrative domain owning the prefix and the host 597 assigning the low 64 bits using SLAC. For example, suppose a host, H, 598 from organization A is connected to a network owned by organization 599 B. When H obtains a new address during a renumbering event through 600 SLAC, H will need to update its reverse entry in the DNS through a 601 DNS server from B that owns the reverse zone for the new address. For 602 H to update its reverse entry, the DNS server from B must accept a 603 DDNS request from H, requiring that an inter-administrative domain 604 trust relationship exist between H and B. The IETF should develop a 605 BCP recommendation for addressing this problem. 607 5. Security Considerations 609 The process of renumbering is straightforward in theory but can be 610 difficult and dangerous in practice. The threats fall into two broad 611 categories: those arising from misconfiguration and those which are 612 actual attacks. 614 Misconfigurations can easily arise if any system in the network 615 "knows" the old prefix, or an address in it, a priori and is not 616 configured with the new prefix, or if the new prefix is configured in 617 a manner which replaces the old instead of being co-equal to it for a 618 period of time. Simplistic examples include: 620 Neglecting to reconfigure a system that is using the old prefix in 621 some static configuration: In this case, when the old prefix is 622 removed from the network, whatever feature was so configured 623 becomes inoperative - it is not configured for the new prefix, and 624 the old prefix is irrelevant. 626 Configuring a system via SSH to its only IPv6 address, and replacing 627 the old address with the new address: Because the TCP connection used 628 by SSH is using the old, no longer valid IPv6 address, the SSH 629 session will be terminated and you will have to use SSH through 630 the new address for additional configuration changes. 632 Removing the old configuration before supplying the new: In this 633 case, it may be necessary to obtain on-site support or travel to 634 the system and access it via its console. 636 Clearly, taking the extra time to add the new prefix to the 637 configuration, allow the network to settle, and then remove the old 638 obviates this class of issue. A special consideration applies when 639 some devices are only occasionally used; the administration must 640 allow sufficiently long in Section 2.6 to ensure that their 641 likelihood of detection is sufficiently high. 643 A subtle case of this type can result when the DNS is used to 644 populate access control lists and similar security or QoS 645 configurations. DNS names used to translate between system or service 646 names and corresponding addresses are treated in this procedure as 647 providing the address in the preferred prefix, which is either the 648 old or the new prefix but not both. Such DNS names provide a means in 649 Section 2.6 to cause systems in the network to stop using the old 650 prefix to access servers or peers and cause them to start using the 651 new prefix. DNS names used for access control lists, however, need to 652 go through the same three step procedure used for other access 653 control lists, having the new prefix added to them in Section 2.3 and 654 the old prefix removed in Section 2.7. 656 Attacks are also possible. Suppose, for example, that the new prefix 657 has been presented by a service provider, and the service provider 658 starts advertising the prefix before the customer network is ready. 659 The new prefix might be targeted in a distributed denial of service 660 attack, or a system might be broken into using an application that 661 would not cross the firewall using the old prefix, before the 662 network's defenses have been configured. Clearly, one wants to 663 configure the defenses first and only then accessibility and routing, 664 as described in Section 2.3 and Section 3.3. 666 The SLAC procedure described in [10] renumbers hosts. Dynamic DNS 667 provides a capability for updating DNS accordingly. Managing 668 configuration items apart from those procedures is most obviously 669 straightforward if all such configurations are generated from a 670 central configuration repository or database, or if they can all be 671 read into a temporary database, changed using appropriate scripts, 672 and applied to the appropriate systems. Any place where scripted 673 configuration management is not possible or is not used must be 674 tracked and managed manually. Here, there be dragons. 676 In ingress filtering of a multihomed network, an easy solution to the 677 issues raised in Section 3.3 might recommend that ingress filtering 678 should not be done for multihomed customers or that ingress filtering 679 should be special-cased. However, this has an impact on Internet 680 security. A sufficient level of ingress filtering is needed to 681 prevent attacks using spoofed source addresses. Another problem 682 becomes from the fact that if ingress filtering is made too difficult 683 (e.g. by requiring special casing in every ISP doing it), it might 684 not be done at an ISP at all. Therefore, any mechanism depending on 685 relaxing ingress filtering checks should be dealt with an extreme 686 care. 688 6. Acknowledgments 690 This document grew out of a discussion on the IETF list. Commentary 691 on the document came from Scott Bradner, Sean Convery, Roland 692 Dobbins, Peter Elford, Bill Fenner, Tony Hain, Craig Huegen, 693 Christian Huitema, Hans Kruse, Laurent Nicolas, Michel Py, Pekka 694 Savola, John Schnizlein, Fred Templin, Michael Thomas, Ole Troan, 695 Harald Tveit Alvestrand, Jeff Wells and Dan Wing. 697 Some took it on themselves to convince the author that the concept of 698 network renumbering as a normal or frequent procedure is daft. Their 699 comments, if they result in improved address management practices in 700 networks, may be the best contribution this note has to offer. 702 Christian Huitema and Pekka Savola described the ingress filtering 703 issues. 705 Informative References 707 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 708 13, RFC 1034, November 1987. 710 [2] Mockapetris, P., "Domain names - implementation and 711 specification", STD 13, RFC 1035, November 1987. 713 [3] Mills, D., "Network Time Protocol (Version 3) Specification, 714 Implementation", RFC 1305, March 1992. 716 [4] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 717 1996. 719 [5] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 720 (DNS NOTIFY)", RFC 1996, August 1996. 722 [6] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 723 1997. 725 [7] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 726 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 727 April 1997. 729 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 730 Specification", RFC 2460, December 1998. 732 [9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 733 for IP Version 6 (IPv6)", RFC 2461, December 1998. 735 [10] Thomson, S. and T. Narten, "IPv6 Stateless Address 736 Autoconfiguration", RFC 2462, December 1998. 738 [11] Eastlake, D., "Domain Name System Security Extensions", RFC 739 2535, March 1999. 741 [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 742 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 743 2845, May 2000. 745 [13] Eastlake, D., "DNS Request and Transaction Signatures ( 746 SIG(0)s)", RFC 2931, September 2000. 748 [14] Wellington, B., "Secure Domain Name System (DNS) Dynamic 749 Update", RFC 3007, November 2000. 751 [15] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 752 3177, September 2001. 754 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 755 Carney, "Dynamic Host Configuration Protocol for IPv6 756 (DHCPv6)", RFC 3315, July 2003. 758 [17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", 759 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in 760 progress), October 2003. 762 [18] Durand, A. and J. Ihren, "Operational Considerations and Issues 763 with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-03 (work in 764 progress), December 2003. 766 [19] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 767 Networks", draft-savola-bcp38-multihoming-update-03 (work in 768 progress), December 2003. 770 [20] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On 771 War, Chapter VII, 'Friction in War'", June 1989. 773 Authors' Addresses 775 Fred Baker 776 Cisco Systems 777 1121 Via Del Rey 778 Santa Barbara, CA 93117 779 US 781 Phone: 408-526-4257 782 Fax: 413-473-2403 783 EMail: fred@cisco.com 785 Eliot Lear 786 Cisco Systems 787 170 W. Tasman Dr. 788 San Jose, CA 95134 789 US 791 Phone: +1 408 527 4020 792 EMail: lear@cisco.com 793 Ralph Droms 794 Cisco Systems 795 200 Beaver Brook Road 796 Boxborough, MA 01719 797 US 799 Phone: +1 978 936-1674 800 EMail: rdroms@cisco.com 802 Appendix A. Managing Latency in the DNS 804 The procedure in this section can be used to determine and manage the 805 latency in updates to information a DNS resource record (RR). 807 There are several kinds of possible delays which are ignored in these 808 calculations: 810 o the time it takes for the administrators to make the changes, 812 o the time it may take to wait for the DNS update, if the 813 secondaries are only updated at regular intervals, and not 814 immediately, and 816 o the time the updating to all the secondaries takes. 818 Assume the use of NOTIFY [5] and IXFR [4] to transfer updated 819 information from the primary DNS server to any secondary servers; 820 this is a very quick update process, and the actual time to update of 821 information is not considered significant. 823 There's a target time, TC, at which we want to change the contents of 824 a DNS RR. The RR is currently configured with TTL == TTLOLD. Any 825 cached references to the RR will expire no more than TTLOLD in the 826 future. 828 At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured 829 with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to 830 push the RR to the secondaries. After the update, responses to 831 queries for the RR are returned with TTLNEW. There are still some 832 cached references with TTLOLD. 834 At time TC - TTLNEW, the RR in the primary is configured with the new 835 address. The update process is initiated to push the RR to the 836 secondaries. After the update, responses to queries for the RR 837 return the new address. All the cached references have TTLNEW. 838 Between this time and TC, responses to queries for the RR may be 839 returned with either the old address or the new address. This 840 ambiguity is acceptable, assuming the host is configured to respond 841 to both addresses. 843 At time TC all the cached references with the old address have 844 expired, and all subsequent queries will return the new address. 845 After TC (corresponding to the final state described in Section 2.8), 846 the TTL on the RR can be set to the initial value TTLOLD. 848 The network administrator can choose TTLOLD and TTLNEW to meet local 849 requirements. 851 As a concrete example, consider a case where TTLOLD is a week (168 852 hours), and TTLNEW is an hour. The preparation for the change of 853 addresses begins 169 hours before the address change. After 168 854 hours have passed and only one hour is left, the TTLNEW has 855 propagated everywhere, and one can change the address record(s). 856 These are propagated within the hour, after which one can restore TTL 857 value to a larger value. This approach minimizes time where it's 858 uncertain what kind of (address) information is returned from the 859 DNS. 861 Intellectual Property Statement 863 The IETF takes no position regarding the validity or scope of any 864 intellectual property or other rights that might be claimed to 865 pertain to the implementation or use of the technology described in 866 this document or the extent to which any license under such rights 867 might or might not be available; neither does it represent that it 868 has made any effort to identify any such rights. Information on the 869 IETF's procedures with respect to rights in standards-track and 870 standards-related documentation can be found in BCP-11. Copies of 871 claims of rights made available for publication and any assurances of 872 licenses to be made available, or the result of an attempt made to 873 obtain a general license or permission for the use of such 874 proprietary rights by implementors or users of this specification can 875 be obtained from the IETF Secretariat. 877 The IETF invites any interested party to bring to its attention any 878 copyrights, patents or patent applications, or other proprietary 879 rights which may cover technology that may be required to practice 880 this standard. Please address the information to the IETF Executive 881 Director. 883 Full Copyright Statement 885 Copyright (C) The Internet Society (2004). All Rights Reserved. 887 This document and translations of it may be copied and furnished to 888 others, and derivative works that comment on or otherwise explain it 889 or assist in its implementation may be prepared, copied, published 890 and distributed, in whole or in part, without restriction of any 891 kind, provided that the above copyright notice and this paragraph are 892 included on all such copies and derivative works. However, this 893 document itself may not be modified in any way, such as by removing 894 the copyright notice or references to the Internet Society or other 895 Internet organizations, except as needed for the purpose of 896 developing Internet standards in which case the procedures for 897 copyrights defined in the Internet Standards process must be 898 followed, or as required to translate it into languages other than 899 English. 901 The limited permissions granted above are perpetual and will not be 902 revoked by the Internet Society or its successors or assignees. 904 This document and the information contained herein is provided on an 905 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 906 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 907 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 908 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 909 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 911 Acknowledgment 913 Funding for the RFC Editor function is currently provided by the 914 Internet Society.