idnits 2.17.1 draft-ietf-6renum-gap-analysis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2013) is 3997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2267 (ref. 'RFC2827') (Obsoleted by RFC 2827) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'RFC6275') (Obsoleted by RFC 6275) -- No information found for draft-liu-bonica-dhcpv6-slaac-problem - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft S. Jiang 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: November 10, 2013 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 W. George 9 Time Warner Cable 10 May 9, 2013 12 IPv6 Site Renumbering Gap Analysis 13 draft-ietf-6renum-gap-analysis-07.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute working 22 documents as Internet-Drafts. The list of current Internet-Drafts is 23 at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 10, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document briefly introduces the existing mechanisms that could 50 be utilized for IPv6 site renumbering and tries to cover most of the 51 explicit issues and requirements of IPv6 renumbering. Through the gap 52 analysis, the document provides a basis for future works that 53 identify and develop solutions or to stimulate such development as 54 appropriate. The gap analysis is organized by the main steps of a 55 renumbering process. 57 Table of Contents 59 1. Introduction ................................................. 4 60 2. Overall Requirements for Renumbering ......................... 4 61 3. Existing Components for IPv6 Renumbering ..................... 5 62 3.1. Relevant Protocols and Mechanisms ....................... 5 63 3.2. Management Tools ........................................ 6 64 3.3. Procedures/Policies ..................................... 7 65 4. Managing Prefixes ............................................ 7 66 4.1. Prefix Delegation ....................................... 7 67 4.2. Prefix Assignment ....................................... 7 68 5. Address Configuration ........................................ 8 69 5.1. Host Address Configuration .............................. 8 70 5.2. Router Address Configuration ............................ 9 71 6. Updating Address-relevant Entries ........................... 10 72 6.1. DNS Records Update ..................................... 10 73 6.2. In-host Server Address Update .......................... 11 74 6.3. Parameterized IP-specific Configuration ................ 11 75 7. Renumbering Event Management ................................ 13 76 7.1. Renumbering Notification ............................... 13 77 7.2. Synchronization Management ............................. 14 78 7.3. Renumbering Monitoring ................................. 14 79 8. Miscellaneous ............................................... 14 80 8.1. Multicast .............................................. 14 81 8.2. Mobility ............................................... 16 82 9. Gap Summary ................................................. 17 83 9.1. Managing Prefixes ...................................... 17 84 9.2. Address configuration .................................. 17 85 9.3. Address relevant entries update ........................ 17 86 9.4. Renumbering event management ........................... 18 87 9.5. Miscellaneous .......................................... 18 88 10. Gaps considered unsolvable ................................. 19 89 10.1. Address Configuration ................................. 19 90 10.2. Address-relevant Entries Update ....................... 19 91 10.3. Miscellaneous ......................................... 20 92 11. Security Considerations .................................... 20 93 12. IANA Considerations......................................... 21 94 13. Acknowledgments ............................................ 21 95 14. References ................................................. 21 96 14.1. Normative References .................................. 21 97 14.2. Informative References ................................ 22 99 1. Introduction 101 As introduced in [RFC5887], renumbering, especially for medium to 102 large sites and networks, is currently viewed as an expensive, 103 painful, and error-prone process, avoided by network managers as much 104 as possible. If IPv6 site renumbering continues to be considered 105 difficult, network managers will turn to Provider Independent (PI) 106 addressing for IPv6 to attempt to minimize the need for future 107 renumbering. However, widespread use of PI may create very serious 108 BGP4 scaling problems [RFC4984]. It is thus desirable to develop 109 tools and practices that may make renumbering a simpler process to 110 reduce demand for IPv6 PI space. 112 This document performs a gap analysis to provide a basis for future 113 work to identify and develop solutions or to stimulate such 114 development as appropriate. The gap analysis is organized according 115 to the main steps of a renumbering process, which include prefix 116 management, node address (re)configuration, and updating address- 117 relevant entries in various devices such as firewalls, routers and 118 servers, etc. Renumbering event management is presented independently 119 from the steps of a renumbering process, in order to identify some 120 operational and administrative gaps in renumbering. 122 This document starts from existing work in [RFC5887] and [RFC4192]. 123 This document does further analysis and identifies the valuable and 124 solvable issues, digs out of some undiscovered gaps, and gives some 125 solution suggestions. 127 Renumbering nodes with static addresses has a particular set of 128 problems, thus discussion of that space has been covered in a related 129 document [RFC6866]. 131 2. Overall Requirements for Renumbering 133 This section introduces the overall goals we want to achieve in a 134 renumbering event. In general, we need to leverage renumbering 135 automation to avoid human intervention as much as possible at 136 reasonable cost. Some existing mechanisms have already provided 137 useful ability. 139 The automation can be divided into four aspects as follows. 141 o Prefix delegation and delivery should be automatic and accurate in 142 aggregation and coordination. 144 o Address reconfiguration should be automatically achieved through 145 standard protocols with minimum human intervention. 147 o Address-relevant entry updates should be performed integrally and 148 without error. 150 o Renumbering event management is needed to provide the functions of 151 renumbering notification, synchronization, and monitoring. 153 Besides automation, session survivability is another important issue 154 during renumbering since application outage is one of the most 155 obvious impacts that make renumbering painful and expensive. Session 156 survivability is a fundamental issue that cannot be solved within 157 renumbering context only. However, IPv6's ability to overlap old and 158 new prefixes (make before break) provides an enormous advantage and 159 to use the address lifetime mechanisms in IPv6 Stateless Address 160 Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for 161 IPv6 (DHCPv6). That is fully described in [RFC4192], which provides a 162 smooth transition mechanism from old to new prefixes. In most of the 163 cases, since we can set the transition period long enough to cover 164 the on-going sessions, we consider this mechanism sufficient for 165 avoiding session brokenness issue in IPv6 site renumbering. (Please 166 note that if multiple addresses are running simultaneously on hosts, 167 the address selection [RFC6724] needs to be carefully handled.) 169 3. Existing Components for IPv6 Renumbering 171 Since renumbering is not a new issue, some protocols and mechanisms 172 have already been utilized for renumbering. There were also some 173 dedicated protocols and mechanisms developed for renumbering. This 174 section briefly reviews these existing protocols and mechanisms to 175 provide a basis for the gap analysis. 177 3.1. Relevant Protocols and Mechanisms 179 o RA messages, defined in [RFC4861], are used to deprecate/announce 180 old/new prefixes and to advertise the availability of an upstream 181 router. In renumbering, it is one of the basic mechanisms for host 182 configuration. 184 o When renumbering a host, SLAAC [RFC4862] may be used for address 185 configuration with the new prefix(es). Hosts receive RA messages 186 which contain routable prefix(es) and the address(es) of the 187 default router(s), then hosts can generate IPv6 address(es) by 188 themselves. 190 o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure 191 addresses by starting RENEW actions when the current addresses' 192 lease time are expired or they receive the reconfiguration 193 messages initiated by the DHCPv6 servers. 195 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 196 delegation of IPv6 prefixes using the DHCPv6. 198 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 199 This is a dedicated protocol for renumbering, but we are not aware 200 of it being used in real network deployment. 202 3.2. Management Tools 204 Some renumbering operations could be automatically processed by 205 management tools in order to make the renumbering process more 206 efficient and accurate. The tools may be designed specifically for 207 renumbering, or common tools could be utilized for some of the 208 renumbering operations. 210 Following are examples of these tools. 212 o IP address management (IPAM) tools. There are both commercial and 213 open-source solutions. IPAM tools are used to manage IP address 214 plans, and usually integrate the DHCPv6 and DNS services together 215 as a whole solution. Many mature commercial tools can support 216 management operations, but normally they do not have dedicated 217 renumbering functions. However, the integrated DNS/DHCPv6 services 218 and address management function can obviously facilitate the 219 renumbering process. 221 o Some organizations use third-party tools like [cfengine] to push 222 configuration to devices. This is sometimes used as a supplement 223 to vendor specific solutions. 225 o [LEROY] proposed a mechanism of macros to automatically update the 226 address-relevant entries/configurations inside the DNS, firewall, 227 etc. The macros can be delivered though SOAP protocol from a 228 network management server to the managed devices. 230 o Asset management tools/systems. These tools may provide the 231 ability of managing configuration files in nodes so that it is 232 convenient to update the address-relevant configuration in these 233 nodes. 235 3.3. Procedures/Policies 237 o [RFC4192] proposed a procedure for renumbering an IPv6 network 238 without a flag day. The document includes a set of operational 239 suggestions which can be followed step by step by network 240 administrators. 242 o [RFC6879] analyzes the enterprise renumbering events and gives the 243 recommendations among the existing renumbering mechanisms. 244 According to the different stages, renumbering considerations are 245 described in three categories: considerations and recommendations 246 during network design, for preparation of enterprise network 247 renumbering, and during renumbering operation. 249 4. Managing Prefixes 251 When renumbering an IPv6 enterprise site, the key procedural issue is 252 switching the old prefix (es) to the new one(s). A new short prefix 253 may be divided into longer ones for subnets. So we need to carefully 254 manage the prefixes to ensure they are synchronized and coordinated 255 in the whole network. 257 4.1. Prefix Delegation 259 Usually, the new short prefix(es) comes down from the operator(s) and 260 is received by DHCPv6 servers or routers inside the enterprise 261 networks (or through off-line human communication). The short 262 prefix(es) could be automatically delegated through DHCPv6-PD. Then 263 the downlink DHCPv6 servers or routers can begin advertising the 264 longer prefixes to the subnets. 266 The delegation routers might need to renumber themselves with the new 267 delegated prefixes. So there should be a mechanism informing the 268 router to renumber themselves by delegated prefixes; and there also 269 should be a mechanism for the routers to derive addresses 270 automatically based on the delegated prefixes. 272 4.2. Prefix Assignment 274 When subnet routers receive the longer prefixes, they can directly 275 assign them to the hosts. Host address configuration, rather than 276 routers, is the primary concern for prefix assignment which is 277 described in the following section 5.1. 279 5. Address Configuration 281 5.1. Host Address Configuration 283 o SLAAC/DHCPv6 interaction problems 285 Both of the DHCPv6 and Neighbor Discovery (ND) protocols have IP 286 address configuration function. They are suitable for different 287 scenarios. During renumbering, the SLAAC-configured hosts can 288 reconfigure IP addresses by receiving ND Router Advertisement (RA) 289 messages containing new prefix information. (It should be noted that, 290 the prefix delivery could be achieved through DHCPv6 according to 291 [I.D ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can 292 reconfigure addresses by initiating RENEW sessions when the current 293 addresses' lease times are expired or when they receive 294 reconfiguration messages initiated by the DHCPv6 servers. 296 Sometimes the two address configuration modes may both be available 297 in one network. This would add more or less additional complexity for 298 both the hosts and the network management. 300 With the flags defined in RA (ManagedFlag indicating the DHCPv6 301 service available in the network; OtherConfigFlag indicating other 302 configurations such as DNS/routing), the two separated address 303 configuration modes are correlated. However, the ND protocol did not 304 define the flags as prescriptive but only as advisory. This has led 305 to variation in the behavior of hosts when interpreting the flags. 306 Different operating systems have followed different approaches. (For 307 more details, please refer to [I-D.liu-bonica-dhcpv6-slaac-problem] 308 and [I-D.liu-6renum-dhcpv6-slaac-switching].) 310 The impact of ambiguous M/O flags includes the following aspects: 312 - DHCPv6-configured hosts might not be able to be renumbered by RA 314 It is unclear whether a DHCPv6 configured host will accept address 315 configuration though RA messages, especially when M flag 316 transitioning from 1 to 0; this depends on the implementation of 317 the operating system. It might not be possible for administrators 318 to only use RA messages for renumbering, since renumbering might 319 fail on some already DHCPv6-configured hosts. It means 320 administrators have to use DHCPv6 reconfiguration for some DHCPv6- 321 configured hosts. It is not convenient and DHCPv6 reconfiguration 322 is not suitable for bulk usage as analyzed in below. 324 - DHCPv6-configured hosts might not be able to learn new RA 325 prefixes 327 [RFC5887] mentioned that DHCPv6-configured hosts may want to learn 328 about the upstream availability of new prefixes or loss of prior 329 prefixes dynamically by deducing this from periodic RA messages. 330 Relevant standards ([RFC4862],[RFC3315]) are ambiguous about what 331 approach should be taken by a DHCPv6-configured host when it 332 receives RA messages containing a new prefix. Current behavior 333 depends on the operating system of the host and cannot be predicted 334 or controlled by the network. 336 - SLAAC-configured hosts might not be able to add DHCPv6 address(es) 338 The behavior when the host receives RA messages with M flag set is 339 unspecified. 341 The host may start a DHCPv6 session and receive the DHCPv6 address 342 configuration, or it may just ignore the messages. If the network 343 side wants the hosts to start DHCPv6 configuration, it is just out 344 of control of the network side. 346 o DHCPv6 reconfigure bulk usage 348 [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear to be 349 widely used for bulk renumbering purposes". 351 The reconfiguration defined in [RFC3315] needs to establish a session 352 between DHCPv6 server and client. This could be considered as a 353 stateful approach which needs much resource on the server to maintain 354 the renumbering sessions. This is probably one of the reasons that 355 DHCPv6 reconfiguration is not suitable for bulk usage. 357 Another limitation of DHCPv6 reconfiguration is that it only allows 358 the messages to be delivered to unicast addresses. So if we want to 359 use it for bulk renumbering, stateless DHCPv6 reconfiguration with 360 multicast may be needed. However, this may involve protocol 361 modification. 363 5.2. Router Address Configuration 365 o Learning new prefixes 367 As described in [RFC5887], "if a site wanted to be multihomed using 368 multiple provider-aggregated (PA) routing prefixes with one prefix 369 per upstream provider, then the interior routers would need a 370 mechanism to learn which upstream providers and prefixes were 371 currently reachable (and valid). In this case, their Router 372 Advertisement messages could be updated dynamically to only advertise 373 currently valid routing prefixes to hosts. This would be 374 significantly more complicated if the various provider prefixes were 375 of different lengths or if the site had non-uniform subnet prefix 376 lengths." 378 o Restart after renumbering 380 As [RFC2072] mentioned, some routers cache IP addresses in some 381 situations, so routers might need to be restarted as a result of site 382 renumbering. While most modern systems support a cache-clear function 383 that eliminates the need for restarts, there are always exceptions 384 that must be taken into account. 386 o Router naming 388 [RFC4192] suggests that "To better support renumbering, switches and 389 routers should use domain names for configuration wherever 390 appropriate, and they should resolve those names using the DNS when 391 the lifetime on the name expires." As [RFC5887] described, this 392 capability is not new, and currently it is present in most IPSec VPN 393 implementations. However, many administrators may need to be alerted 394 to the fact that it could be utilized to avoid manual modification 395 during renumbering. 397 6. Updating Address-relevant Entries 399 In conjunction with renumbering the nodes, any configuration or data 400 store containing previous addresses must be updated as well. Some 401 examples include DNS records and filters in various entities such as 402 ACLs in firewalls/gateways. 404 6.1. DNS Records Update 406 o Secure Dynamic DNS update 408 In real network operations, DNS update is normally achieved by 409 maintaining a DNS zone file and loading this file into the site's DNS 410 server(s). Synchronization between host renumbering and the updating 411 of its A6 or AAAA record is hard. [RFC5887] mentioned that an 412 alternative is to use Secure Dynamic DNS Update [RFC3007], in which a 413 host informs its own DNS server when it receives a new address. 415 Secure Dynamic DNS Update has been widely supported by the major DNS 416 implementations, but it hasn't been widely deployed. Normal hosts are 417 not suitable to do the update mainly because of the complexity of key 418 management issues inherited from secure DNS mechanisms, so current 419 practices usually assign the DHCP servers to act as DNS clients to 420 request the DNS server updating relevant records. However, it is 421 still not easy to use, the operational complexity of Secure Dynamic 422 DNS Update is still a gao. (But for some commercial DNS systems, the 423 operational issue may be much easier, since it could be integrated 424 with services like DHCP provided by the same vendor so that the 425 dynamic DNS update could be silently enabled.) 427 6.2. In-host Server Address Update 429 While DNS stores addresses of hosts in servers, hosts are also 430 configured with addresses of servers such as DNS server, radius 431 server. While renumbering, the hosts must update these addresses if 432 the server addresses changed. (Addresses of DHCPv6 servers do not 433 need to be updated. They are dynamically discovered using DHCPv6 434 relevant multicast addresses.) 436 The DNS server addresses for hosts could be configured by DHCPv6. In 437 stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to 438 specify valid time for the DNS configuration. But in stateful DHCPv6, 439 current protocols could not indicate hosts the valid time of DNS 440 configuration. If the DNS server has been renumbered, and the DHCP 441 lease time has not expired yet, then the hosts would still use the 442 old DNS server address(es). It might be better that the hosts could 443 renew the DHCP DNS configuration before the lease time, especially 444 there might be some extreme situations that the lease time need to be 445 long. In this case how the DHCP server could learn the proper DNS 446 configuration valid time is also an issue. 448 6.3. Parameterized IP-specific Configuration 450 Besides the DNS records and the in-host server address entries, there 451 are also many places in which the IP addresses are configured, for 452 example, filters such as ACL and routing policies. There are even 453 more sophisticated cases where the IP addresses are used for deriving 454 values, for example, using the unique portion of the loopback address 455 to generate an ISIS net ID. 457 Ideally, a layer of abstraction for IP-specific configuration within 458 various devices (routers, switches, hosts, servers, etc.) is needed. 459 However, this cannot be achieved in one step. One possible 460 improvement is to make the IP-specific configuration parameterized. 461 Two aspects of parameterized configuration could be considered to 462 achieve this. 464 o Self-contained Configuration in Individual device 466 In an ideal way, the IP addresses can be defined as a value once, and 467 then the administrators can use either keywords or variables to call 468 the value in other places such as a sort of internal inheritance in 469 CLI (command line interface) or other local configurations. This 470 makes it easier to manage a renumbering event by reducing the number 471 of places where a device's configuration must be updated. However, it 472 still means that every device needs to be touched, but only once 473 instead of having to inspect the whole configuration to ensure that 474 none of the separate places that a given IP address occurs is missed. 476 Among the current devices, some routers support defining multiple 477 loopback interfaces which can be called in other configurations. For 478 example, when defining a tunnel, it can call the defined loopback 479 interface to use its address as the local address of the tunnel. This 480 can be considered as a kind of parameterized self-contained 481 configuration. But this only applies certain use cases; it is 482 impossible to use the loopback interfaces to represent external 483 devices and it is not always possible to call loopback interfaces in 484 many other configurations. Parameterized self-contained configuration 485 is still a gap for current devices. 487 o Unified Configuration Management among Devices 489 This is a more formalized central configuration management system, 490 where all changes are made in one place and the system manages how to 491 push the changes to the individual devices. This issue contains two 492 aspects as the following. 494 - Configuration Aggregation 496 Configuration based on addresses or prefixes are usually spread in 497 various devices. As [RFC5887] described, some address configuration 498 data might be widely dispersed and much harder to find, even will 499 inevitably be found only after the renumbering event. So there's a 500 big gap for configuration aggregation, it is hard to get all the 501 relevant configurations through one place. 503 - Configuration Update Automation 505 As mentioned in section 3.2, [LEROY] proposed a mechanism which can 506 automatically update the configurations. The mechanism utilizes 507 macros suitable for various devices such as routers, firewalls. to 508 update the configurations based on the new prefix. Such automation 509 tool is valuable for renumbering because it can reduce manual 510 operation which is error-prone and inefficiency. 512 Besides the macros, [LEROY] also proposed to use SOAP to deliver 513 the macros to the devices. As well as SOAP we may consider whether 514 it is possible and suitable to use other standardized protocols 515 such as NETCONF [RFC4714]. 517 But in current real networks, most of the devices use vendor- 518 private protocols to update configurations, so it is not 519 necessarily valid to assume that there is going to be a formalized 520 configuration management system to leverage. Although there are 521 some vendor-independent tools as mentioned in section 3.2, a 522 standard and comprehensive way of uniformly updating configurations 523 in multi-vendor devices is still a big gap currently. 525 7. Renumbering Event Management 527 From the perspective of network management, renumbering is a kind of 528 event which may need additional process to make it more easy and 529 manageable. 531 7.1. Renumbering Notification 533 If hosts or servers are aware of a renumbering event happening, it 534 may benefit the relevant process. Following are several examples of 535 such additional process that may ease the renumbering. 537 o A notification mechanism may be needed to indicate to hosts that a 538 renumbering event has changed some DNS records in DNS servers 539 (normally, in an enterprise it/they is/are (a) local recursive DNS 540 server(s).), and then the hosts might want to refresh the DNS 541 cache. That mechanism may also need to indicate that such a change 542 will happen at a specific time in the future. 544 o As suggested in [RFC4192], if the DNS service can be given prior 545 notice about a renumbering event, then people could reduce the 546 delay in the transition to new IPv6 addresses, thus improve the 547 efficiency of renumbering. 549 o Router awareness: in a site with multiple domains which are 550 connected by border routers, all border routers should be aware of 551 renumbering in one domain or multiple domains, and update the 552 internal forwarding tables and the address/prefix based filters 553 accordingly to correctly handle inbound packets. 555 o Ingress filtering: ISPs normally enable ingress filter to drop 556 packets with source addresses from other ISPs at the end site 557 routers to prevent IP spoofing [RFC2827]. In a multihomed site 558 with multiple PA prefixes, the ingress router of ISP A should be 559 notified if the ISP B initiates a renumbering event in order to 560 properly update its filters to permit the new legitimate prefix 561 (es). 563 7.2. Synchronization Management 565 o DNS update synchronization 567 The DNS changes must be coordinated with the changes of node address 568 configuration. DNS has a latency issue of propagating information 569 from the server to the resolver. The latency is mainly caused by TTL 570 assigned to individual DNS records and the timing of updates from 571 primary to secondary servers [RFC4192]. Currently, there are no 572 mechanisms to deal with the latency issue. 574 7.3. Renumbering Monitoring 576 While treating renumbering as a network event, mechanisms to monitor 577 the renumbering process might be needed to inform the administrators 578 whether the renumbering has been successfully done. Considering the 579 address configuration operation might be stateless (if ND is used for 580 renumbering), it is difficult for monitoring. 582 8. Miscellaneous 584 Since multicast and mobility are special use cases which might not be 585 included in routine/common renumbering operations, they are 586 separately discussed as miscellaneous in this section. 588 8.1. Multicast 590 In the perspective of interface renumbering operations, renumbering a 591 multicast address is the same with renumbering a unicast address. So 592 this section mainly discusses the issues from the perspective of the 593 impact to the multicast application systems caused by renumbering. 595 Renumbering also has an impact on multicast. Renumbering of unicast 596 addresses affects multicast even if the multicast addresses are not 597 changed. There may also be cases where the multicast addresses need 598 to be renumbered. 600 o Renumbering of multicast sources 601 If a host that is a multicast source is renumbered, the application 602 on the host may need to be restarted for it to successfully send 603 packets with the new source address. 605 For ASM (Any-Source Multicast) the impact on a receiver is that a new 606 source appears to start sending, and it no longer receives from the 607 previous source. Whether this is an issue depends on the application, 608 but we believe it is likely to not be a major issue. 610 For SSM (Source-Specific Multicast) however, there is one significant 611 problem. The receiver needs to learn which source addresses it must 612 join. Some applications may provide their own method for learning 613 sources, where the source application may somehow signal the receiver. 615 Otherwise, the receiver may e.g. need to get new SDP information with 616 the new source address. This is similar to how to learn a new group 617 address, see the "Renumbering of multicast addresses" topic below. 619 o Renumbering of Rendezvous-Point 621 If the unicast addresses of routers in a network are renumbered, then 622 the RP (Rendezvous-Point) address is also likely to change for at 623 least some groups. An RP address is needed by PIM-SM for providing 624 ASM, and for Bidir PIM. Changing the RP address is not a major issue, 625 except that the multicast service may be impacted while the new RP 626 addresses are configured. If dynamic protocols are used for 627 distributing group-to-RP mappings, the change can be fairly quick, 628 and any impact should be only for a very brief time. However, if 629 routers are statically configured, this depends on how long it takes 630 to update all the configurations. 632 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) when 633 the first packet is received by the last-hop routers. Forwarding on 634 the SPT should not be impacted by change of IP address. Network 635 operator should be careful not deprecate the previous mapping before 636 configuring a new one, because implementations may revert to Dense 637 Mode if no RP is configured. 639 o Renumbering of multicast addresses 641 In general multicast addresses can be chosen independently of the 642 unicast addresses, and the multicast addresses can remain fixed even 643 if the unicast addresses are renumbered. However, for IPv6 there are 644 useful ways of deriving multicast addresses from unicast addresses, 645 such as unicast-prefix-based IPv6 Multicast Addresses [RFC3306] and 646 Embedded-RP IPv6 Multicast Addresses [RFC3956]. In that case the 647 multicast addresses used may have to be renumbered. 649 Renumbering group addresses may be complicated. For multicast, it is 650 common to use literal addresses, and not DNS. When multicast 651 addresses are changed, source applications need to be reconfigured 652 and restarted. 654 Multicast receivers need to learn the new group addresses to join. 656 Note that for SSM, receivers need to learn which multicast channels 657 to join. A channel is a source and group pair. This means that for an 658 SSM application, a change of source address is likely to have the 659 same effect as a change of group address. 661 Some applications may have dynamic methods of learning which groups 662 (and possibly sources) to join. If not, the application may have to 663 be reconfigured and restarted. 665 One common way for receivers to learn the necessary parameters is by 666 use of SDP. SDP information may be distributed via various 667 application protocols, or it may be from a file. An SDP file may be 668 distributed via HTTP, email etc. If a user is using a web browser and 669 clicking on a link to launch the application with the necessary data, 670 it may be a matter of closing the current application, and re- 671 clicking the link. 673 In summary, currently the multicast renumbering issues are basically 674 handled by application-specific methods. There is no standard way to 675 guarantee multicast service could live across a renumbering event. 677 8.2. Mobility 679 As described in [RFC5887], if a mobile node's home address changes 680 unexpectedly, the node can be informed of the new global routing 681 prefix used at the home site through the Mobile Prefix Solicitation 682 and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. But if the 683 mobile node is unfortunately disconnected at the time of home address 684 renumbering, it will no longer know a valid subnet anycast address 685 for its home agent, leaving it to deduce a valid address on the basis 686 of DNS information. 688 So, for Mobile IP, we need a better mechanism to handle change of 689 home agent address while mobile is disconnected. 691 9. Gap Summary 693 9.1. Managing Prefixes 695 o A mechanism informing the router to renumber themselves by 696 delegated prefixes 698 o A mechanism for the routers to derive addresses automatically 699 based on the delegated prefixes. 701 9.2. Address configuration 703 o Host address configuration 705 - DHCPv6-only management might not applicable on some of current 706 implementations 708 - DHCPv6-configured hosts might not able to be renumbered by RA on 709 some of current implementations 711 - DHCPv6-configured hosts might not able to learn new RA prefixes 712 on some of current implementations 714 - SLAAC-configured hosts might not able to add DHCPv6 address(es) 715 on some of current implementations 717 - DHCPv6 reconfigure not suitable for bulk usage 719 o Router address configuration 721 - A mechanism for interior routers in multihomed site to learn 722 which upstream providers and prefixes were currently reachable 724 - Cache-clear might need restart (rarely in modern routers) 726 - Using router domain names is not widely learned/deployed by 727 administrators 729 9.3. Address relevant entries update 731 o DNS records update 733 - Secure Dynamic DNS Update has operational complexity and seldom 734 used in real networks 736 o In-host server address update 737 - a mechanism is needed for the hosts to renew the DHCP DNS 738 configuration before the lease time when the DNS server is 739 renumbered 741 - It might be better to extend stateful DHCPv6 to indicate hosts 742 the associated DNS server valid time when making DNS 743 configuration. 745 o Parameterized IP-specific Configuration 747 - Devices don't support parameterized configuration, 748 administrators need to touch every places where IP addresses 749 were configured 751 - It is hard to get all the address-relevant configurations spread 752 in various devices through one place 754 - uniformly update configurations in multi-vendor devices is a big 755 gap currently 757 9.4. Renumbering event management 759 o Renumbering notification 761 - A mechanism to indicate hosts local recursive DNS is going to be 762 renumbered 764 - A prior notice about a renumbering event for DNS 766 - A mechanism for border routers to know internal partial 767 renumbering 769 - For multihomed sites, a mechanism to notify the egress router of 770 ISPA that egress router connecting to ISPB initiates renumbering 772 o Synchronization management 774 - DNS information propagating latency issue 776 o Renumbering monitoring 778 - Mechanisms to monitor the process and feedback of renumbering 779 may be needed 781 9.5. Miscellaneous 783 o Multicast 784 - Mechanism for SSM receivers to learn the source addresses when 785 multicast sources are renumbered 787 o Mobility 789 - A better mechanism to handle change of home agent address while 790 mobile is disconnected. 792 10. Gaps considered unsolvable 794 This section lists gaps have been identified by other documents but 795 are considered unsolvable. 797 10.1. Address Configuration 799 o RA prefix lifetime limitation 801 In section 5.5.3 of [RFC4862], it is defined that "If the received 802 Valid Lifetime is greater than 2 hours or greater than 803 RemainingLifetime, set the valid lifetime of the corresponding 804 address to the advertised Valid Lifetime." So when renumbering, if 805 the previous RemainingLifetime is longer than two hours, it is 806 impossible to reduce a prefix's lifetime less than two hours. This 807 limitation is to prevent denial-of-service attack. 809 10.2. Address-relevant Entries Update 811 o DNS entries commonly have matching Reverse DNS entries which will 812 also need to be updated during renumbering. 814 o DNS data structure optimization 816 [RFC2874] proposed an experimental A6 record type for DNS recording 817 of IPv6 address and prefix. Several extensions to DNS query and 818 processing were also proposed. With the A6 record and the extensions, 819 an IPv6 address could be defined by using multiple DNS records. This 820 feature would increase the complexity of resolvers but reduce the 821 cost of zone file maintenance, so renumbering could be easier than 822 with the AAAA record. 824 But the A6 record has not been widely used, and it has been moved to 825 historic status [RFC6563]. However, the idea of structured record to 826 separate prefix and suffix is still valuable for renumbering, but it 827 might not be able to develop a more proper new DNS record type in a 828 short time. 830 o DNS authority 831 It is often the case in enterprises that host web servers and 832 application servers on behalf of collaborators and customers that DNS 833 zones out of the administrative control of the host maintain resource 834 records concerning addresses for nodes out of their control. When the 835 service host renumbers, they do not have sufficient authority to 836 change the records. 838 It is an operational and policy issue and this document considers it 839 not suitable to be solved through technical approach or bring 840 additional protocol/mechanism to standardize the interaction between 841 DNS systems for authority negotiations. 843 10.3. Miscellaneous 845 o For transport layer, [RFC5887] said that TCP connections and UDP 846 flows are rigidly bound to a given pair of IP addresses. 848 o For application layer, in general, we can assert that any 849 implementation is at risk from renumbering if it does not check 850 whether an address is valid each time it starts session resumption 851 (e.g. a laptop wakes from sleep state). It is also more of less 852 risky when it opens a new communications session by using cached 853 addresses. 855 We considered the above two points (ID/Locator overloading in 856 transport layer & address caching in app layer) are fundamental 857 issues that might not be proper to deal with them just in terms of 858 renumbering. 860 11. Security Considerations 862 o Prefix Validation 864 Prefixes from the ISP may need authentication to prevent prefix 865 fraud. Announcing changes of site prefix to other sites (for example, 866 those that configure routers or VPNs to point to the site in 867 question) also need validation. 869 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or Secure 870 Neighbor Discovery (SEND, [RFC3971]) deployment may be needed to 871 validate prefixes. 873 o Influence on Security Controls 875 During renumbering, security controls (e.g. ACLs) protecting 876 legitimate resources should not be interrupted. For example, if some 877 addresses are in a blacklist, they should not escape from the 878 blacklist due to renumbering. 880 12. IANA Considerations 882 This draft does not request any IANA actions. 884 13. Acknowledgments 886 This work adopts significant amounts of content from [RFC5887] and 887 particularly the "DNS Authority" topic in section 10.2 is from 888 [draft-chown-v6ops-renumber-thinkabout]. Both of the two documents 889 are important input for this work, that some 890 principles/considerations applied in this work are implicitly 891 inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, 892 Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were 893 provided by Oliver Bonaventure and his student Damien Leroy. 895 Many useful comments and contributions were made by Lee Howard, 896 Robert Sparks, S. Moonesamy, Fred Baker, Eric Vyncke, Phillips 897 Matthew, Gustav Reinsberger, Teco Boot and other members of 6renum WG. 899 This document was prepared using 2-Word-v2.0.template.dot. 901 14. References 903 14.1. Normative References 905 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 906 Update", RFC 3007, November 2000. 908 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 909 M. Carney, "Dynamic Host Configuration Protocol for IPv6 910 (DHCPv6)", RFC 3315, July 2003. 912 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 913 Host Configuration Protocol (DHCP) version 6", RFC 3633, 914 December 2003. 916 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 917 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 918 November 2004. 920 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 921 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 923 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 924 "Neighbor Discovery for IP version 6 (IPv6)", RFC 925 4861,September 2007. 927 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 928 Address Autoconfiguration", RFC 4862, September 2007. 930 14.2. Informative References 932 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 933 1997. 935 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 936 Defeating Denial of Service Attacks which employ IP Source 937 Address Spoofing", RFC 2267, January 1998. 939 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 940 IPv6 Address Aggregation and Renumbering", RFC 2874, July 941 2000. 943 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 944 August 2000. 946 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 947 Multicast Addresses", RFC 3306, August 2002. 949 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 950 (DHCP) Service for IPv6", RFC 3736, April 2004. 952 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) 953 Address in an IPv6 Multicast Address", RFC 3965, November 954 2004. 956 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 957 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 958 September 2005. 960 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 961 Time Option for Dynamic Host Configuration Protocol for 962 IPv6 (DHCPv6)", RFC 4242, November 2005. 964 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 965 December 2006. 967 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 968 from the IAB Workshop on Routing and Addressing", RFC 4984, 969 September 2007. 971 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 972 Still Needs Work", RFC 5887, May 2010. 974 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 975 Historic Status", RFC 6563, May 2012. 977 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 978 "Default Address Selection for Internet Protocol Version 6 979 (IPv6)", RFC 6724, September 2012. 981 [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 982 in IPv6", RFC 3775, June 2004. 984 [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for 985 Renumbering IPv6 Hosts with Static Addresses in Enterprise 986 Networks", RFC 6866, February 2013. 988 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 989 Network Renumbering Scenarios, Considerations, and Methods", 990 RFC 6879, February 2013. 992 [I-D.ietf-dhc-secure-dhcpv6] 993 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 994 in progress, March 2012. 996 [I-D.liu-6renum-dhcpv6-slaac-switching] 997 Liu, B., "DHCPv6/SLAAC Address Configuration Switching for 998 Host Renumbering", Working in Progress, July 2012. 1000 [I-D.liu-bonica-dhcpv6-slaac-problem] 1001 Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration 1002 Interaction Problem Statement", Working in Progress, 1003 February 2013. 1005 [cfengine]http://cfengine.com/what-is-cfengine 1007 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 1008 configurations for IPv6 renumbering", International of 1009 Network Management, 2009, 1012 Authors' Addresses 1014 Bing Liu 1015 Huawei Technologies Co., Ltd 1016 Q14, Huawei Campus 1017 No.156 Beiqing Rd. 1018 Hai-Dian District, Beijing 100095 1019 P.R. China 1021 Email: leo.liubing@huawei.com 1023 Sheng Jiang 1024 Huawei Technologies Co., Ltd 1025 Q14, Huawei Campus 1026 No.156 Beiqing Rd. 1027 Hai-Dian District, Beijing 100095 1028 P.R. China 1030 Email: jiangsheng@huawei.com 1032 Brian Carpenter 1033 Department of Computer Science 1034 University of Auckland 1035 PB 92019 1036 Auckland, 1142 1037 New Zealand 1039 EMail: brian.e.carpenter@gmail.com 1041 Stig Venaas 1042 Cisco Systems 1043 Tasman Drive 1044 San Jose, CA 95134 1045 USA 1047 Email: stig@cisco.com 1048 Wesley George 1049 Time Warner Cable 1050 13820 Sunrise Valley Drive 1051 Herndon, VA 20171 1052 USA 1054 Phone: +1 703-561-2540 1055 Email: wesley.george@twcable.com