idnits 2.17.1 draft-ietf-6renum-gap-analysis-08.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 7 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 == Line 166 has weird spacing: '...ch, and the a...' -- The document date (June 9, 2013) is 3936 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 3775 (ref. 'RFC6275') (Obsoleted by RFC 6275) -- No information found for draft-ietf-6man-addr-select-opt - is the name correct? -- No information found for draft-ietf-dhc-secure-dhcpv6 - is the name correct? -- No information found for draft-liu-bonica-dhcpv6-slaac-problem - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 11, 2013 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 W. George 9 Time Warner Cable 10 June 9, 2013 12 IPv6 Site Renumbering Gap Analysis 13 draft-ietf-6renum-gap-analysis-08.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 December 11, 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. Its main 52 content is a gap analysis that provides a basis for future works to 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 ....................................... 8 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. Address update in scattered configurations ............. 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 .......................................... 19 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 ................................................. 22 96 14.1. Normative References .................................. 22 97 14.2. Informative References ................................ 23 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 Building upon the IPv6 enterprise renumbering scenarios described in 113 [RFC6879], this document performs a gap analysis to provide a basis 114 for future work to identify and develop solutions or to stimulate 115 such development as appropriate. The gap analysis is organized 116 according to the main steps of a renumbering process, which include 117 prefix management, node address (re)configuration, and updating 118 address-relevant entries in various devices such as firewalls, 119 routers and servers, etc. Renumbering event management is presented 120 independently from the steps of a renumbering process, in order to 121 identify some operational and administrative gaps in renumbering. 123 This document starts from existing work in [RFC5887] and [RFC4192]. 124 It does further analysis and identifies the valuable and solvable 125 issues, digs out of some undiscovered gaps, and gives some solution 126 suggestions. This document considers make-before-break approach as a 127 premise for the gap analysis, so readers should be familiar with 128 [RFC4192]. 130 Renumbering nodes with static addresses has a particular set of 131 problems, thus discussion of that space has been covered in a related 132 document [RFC6866]. 134 This document does not cover the un-planned emergency renumbering 135 cases. 137 2. Overall Requirements for Renumbering 139 This section introduces the overall goals we want to achieve in a 140 renumbering event. In general, we need to leverage renumbering 141 automation to avoid human intervention as much as possible at 142 reasonable cost. Some existing mechanisms have already provided 143 useful ability. 145 The automation can be divided into four aspects as follows. (Detailed 146 analysis of the four aspects is presented respectively in section 4 147 to section 7.) 149 o Prefix delegation and delivery should be automatic and accurate in 150 aggregation and coordination. 152 o Address reconfiguration should be automatically achieved through 153 standard protocols with minimum human intervention. 155 o Address-relevant entry updates should be performed together and 156 without error. 158 o Renumbering event management is needed to provide the functions of 159 renumbering notification, synchronization, and monitoring. 161 Besides automation, session survivability is another important issue 162 during renumbering since application outage is one of the most 163 obvious impacts that make renumbering painful and expensive. Session 164 survivability is a fundamental issue that cannot be solved within 165 renumbering context only. However, with the [RFC4192] make-before- 166 break approach, and the address lifetime mechanisms in IPv6 167 Stateless Address Autoconfiguration (SLAAC) and Dynamic Host 168 Configuration Protocol for IPv6 (DHCPv6), a smooth transition 169 mechanism from old to new prefixes is applicable. In most of the 170 cases, since we can set the transition period long enough to cover 171 the on-going sessions, we consider this mechanism sufficient for 172 avoiding session brokenness issue in IPv6 site renumbering. (Please 173 note that if multiple addresses are running simultaneously on hosts, 174 the address selection [RFC6724] needs to be carefully handled.) 176 3. Existing Components for IPv6 Renumbering 178 Since renumbering is not a new issue, some protocols and mechanisms 179 have already been utilized for renumbering. There were also some 180 dedicated protocols and mechanisms developed for renumbering. This 181 section briefly reviews these existing protocols and mechanisms to 182 provide a basis for the gap analysis. 184 3.1. Relevant Protocols and Mechanisms 186 o RA messages, defined in [RFC4861], are used to deprecate/announce 187 old/new prefixes and to advertise the availability of an upstream 188 router. In renumbering, it is one of the basic mechanisms for host 189 configuration. 191 o When renumbering a host, SLAAC [RFC4862] may be used for address 192 configuration with the new prefix(es). Hosts receive RA messages 193 which contain routable prefix(es) and the address(es) of the 194 default router(s), then hosts can generate IPv6 address(es) by 195 themselves. 197 o Hosts that are configured through DHCPv6 [RFC3315] obtain new 198 addresses through the renewal process or when they receive the 199 reconfiguration messages initiated by the DHCPv6 servers. 201 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 202 delegation of IPv6 prefixes using the DHCPv6. 204 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 205 This is a dedicated protocol for renumbering, but we are not aware 206 of it being used in real network deployment. 208 3.2. Management Tools 210 Some renumbering operations could be automatically processed by 211 management tools in order to make the renumbering process more 212 efficient and accurate. The tools may be designed specifically for 213 renumbering, or common tools could be utilized for some of the 214 renumbering operations. 216 Following are examples of these tools. 218 o IP address management (IPAM) tools. There are both commercial and 219 open-source solutions. IPAM tools are used to manage IP address 220 plans, and usually integrate the DHCPv6 and DNS services together 221 as a whole solution. Many mature commercial tools can support 222 management operations, but normally they do not have dedicated 223 renumbering functions. However, the integrated DNS/DHCPv6 services 224 and address management function can obviously facilitate the 225 renumbering process. 227 o Some organizations use third-party tools to push configuration to 228 devices. This is sometimes used as a supplement to vendor specific 229 solutions. A representative of such third-party tool is [cfengine]. 231 o [LEROY] proposed a mechanism of macros to automatically update the 232 address-relevant entries/configurations inside the DNS, firewall, 233 etc. The macros can be delivered though SOAP protocol from a 234 network management server to the managed devices. 236 o Asset management tools/systems. These tools may provide the 237 ability of managing configuration files in nodes so that it is 238 convenient to update the address-relevant configuration in these 239 nodes. 241 3.3. Procedures/Policies 243 o [RFC4192] proposed a procedure for renumbering an IPv6 network 244 without a flag day. The document includes a set of operational 245 suggestions which can be followed step by step by network 246 administrators. It should be noted that the administrators need to 247 carefully deal with the address selection issue while the old and 248 new prefixes are both available during the overlapping period in 249 [RFC4192] procedure. And the address selection policies might need 250 to be updated after renumbering. So administrator could leverage 251 the address selection policy distribution mechanism in 252 [I-D.ietf-6man-addr-select-opt]. 254 o [RFC6879] analyzes the enterprise renumbering events and gives the 255 recommendations among the existing renumbering mechanisms. 256 According to the different stages, renumbering considerations are 257 described in three categories: considerations and recommendations 258 during network design, for preparation of enterprise network 259 renumbering, and during renumbering operation. 261 4. Managing Prefixes 263 When renumbering an IPv6 enterprise site, the key procedural issue is 264 switching the old prefix (es) to the new one(s). A new short prefix 265 may be divided into longer ones for subnets. So we need to carefully 266 manage the prefixes to ensure they are synchronized and coordinated 267 in the whole network. 269 4.1. Prefix Delegation 271 For big enterprises, the new short prefix(es) usually comes down 272 through off-line human communication. But for the SOHO style SMEs 273 (Small & Medium Enterprises), the prefixes might be dynamically 274 received by DHCPv6 servers or routers inside the enterprise networks. 275 The short prefix(es) could be automatically delegated through DHCPv6- 276 PD. Then the downlink DHCPv6 servers or routers can begin advertising 277 the longer prefixes to the subnets. 279 The delegation routers might need to renumber themselves with the new 280 delegated prefixes. So there should be a mechanism informing the 281 router to renumber themselves by delegated prefixes; and there also 282 should be a mechanism for the routers to derive addresses 283 automatically based on the delegated prefixes. 285 4.2. Prefix Assignment 287 When subnet routers receive the longer prefixes, they can advertise a 288 prefix on a link to which hosts are connected. Host address 289 configuration, rather than routers, is the primary concern for prefix 290 assignment which is described in the following section 5.1. 292 5. Address Configuration 294 5.1. Host Address Configuration 296 o SLAAC/DHCPv6 interaction problems 298 Both of the DHCPv6 and Neighbor Discovery (ND) protocols have IP 299 address configuration function. They are suitable for different 300 scenarios. During renumbering, the SLAAC-configured hosts can 301 reconfigure IP addresses by receiving ND Router Advertisement (RA) 302 messages containing new prefix information. (It should be noted that, 303 the prefix delivery could be achieved through DHCPv6 according to 304 [I.D ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can 305 reconfigure addresses by initiating RENEW sessions when the current 306 addresses' lease times are expired or when they receive 307 reconfiguration messages initiated by the DHCPv6 servers. 309 Sometimes the two address configuration modes may both be available 310 in one network. This would add additional complexity for both the 311 hosts and the network management. 313 With the flags defined in RA (ManagedFlag indicating the DHCPv6 314 service available in the network; OtherConfigFlag indicating other 315 configurations such as DNS/routing), the two separated address 316 configuration modes are correlated. However, the ND protocol did not 317 define the flags as prescriptive but only as advisory. This has led 318 to variation in the behavior of hosts when interpreting the flags. 319 Different operating systems have followed different approaches. (For 320 more details, please refer to [I-D.liu-bonica-dhcpv6-slaac-problem] 321 and [I-D.liu-6renum-dhcpv6-slaac-switching].) 323 The impact of ambiguous M/O flags includes the following aspects: 325 - DHCPv6-configured hosts might not be able to be renumbered by RA 327 It is unclear whether a DHCPv6 configured host will accept address 328 configuration though RA messages, especially when M flag 329 transitioning from 1 to 0; this depends on the implementation of 330 the operating system. It might not be possible for administrators 331 to only use RA messages for renumbering, since renumbering might 332 fail on some already DHCPv6-configured hosts. It means 333 administrators have to use DHCPv6 reconfiguration for some DHCPv6- 334 configured hosts. It is not convenient and DHCPv6 reconfiguration 335 is not suitable for bulk usage as analyzed in below. 337 - DHCPv6-configured hosts might not be able to learn new RA 338 prefixes 340 [RFC5887] mentioned that DHCPv6-configured hosts may want to learn 341 about the upstream availability of new prefixes or loss of prior 342 prefixes dynamically by deducing this from periodic RA messages. 343 Relevant standards ([RFC4862],[RFC3315]) are ambiguous about what 344 approach should be taken by a DHCPv6-configured host when it 345 receives RA messages containing a new prefix. Current behavior 346 depends on the operating system of the host and cannot be predicted 347 or controlled by the network. 349 - SLAAC-configured hosts might not be able to add DHCPv6 address(es) 351 The behavior when the host receives RA messages with M flag set is 352 unspecified. 354 The host may start a DHCPv6 session and receive the DHCPv6 address 355 configuration, or it may just ignore the messages. If the network 356 side wants the hosts to start DHCPv6 configuration, it is just out 357 of control of the network side. 359 5.2. Router Address Configuration 361 o Learning new prefixes 363 As described in [RFC5887], "if a site wanted to be multihomed using 364 multiple provider-aggregated (PA) routing prefixes with one prefix 365 per upstream provider, then the interior routers would need a 366 mechanism to learn which upstream providers and prefixes were 367 currently reachable (and valid). In this case, their Router 368 Advertisement messages could be updated dynamically to only advertise 369 currently valid routing prefixes to hosts. This would be 370 significantly more complicated if the various provider prefixes were 371 of different lengths or if the site had non-uniform subnet prefix 372 lengths." 374 o Restart after renumbering 375 As [RFC2072] mentioned, some routers cache IP addresses in some 376 situations, so routers might need to be restarted as a result of site 377 renumbering. While most modern systems support a cache-clear function 378 that eliminates the need for restarts, there are always exceptions 379 that must be taken into account. 381 o Router naming 383 [RFC4192] suggests that "To better support renumbering, switches and 384 routers should use domain names for configuration wherever 385 appropriate, and they should resolve those names using the DNS when 386 the lifetime on the name expires." As [RFC5887] described, this 387 capability is not new, and currently it is present in most IPSec VPN 388 implementations. However, many administrators may need to be alerted 389 to the fact that it could be utilized to avoid manual modification 390 during renumbering. 392 6. Updating Address-relevant Entries 394 In conjunction with renumbering the nodes, any configuration or data 395 store containing previous addresses must be updated as well. Some 396 examples include DNS records and filters in various entities such as 397 ACLs in firewalls/gateways. 399 6.1. DNS Records Update 401 o Secure Dynamic DNS update 403 In real network operations, DNS update is normally achieved by 404 maintaining a DNS zone file and loading this file into the site's DNS 405 server(s). Synchronization between host renumbering and the updating 406 of its A6 or AAAA record is hard. [RFC5887] mentioned that an 407 alternative is to use Secure Dynamic DNS Update [RFC3007], in which a 408 host informs its own DNS server when it receives a new address. 410 Secure Dynamic DNS Update has been widely supported by the major DNS 411 implementations, but it hasn't been widely deployed. Normal hosts are 412 not suitable to do the update mainly because of the complexity of key 413 management issues inherited from secure DNS mechanisms, so current 414 practices usually assign the DHCP servers to act as DNS clients to 415 request the DNS server updating relevant records [RFC4704]. This 416 server-oriented approach is applicable for large numbers of hosts' 417 using secure DDNS. (In some commercial solutions, DNS service could 418 be integrated with DHCP service provided by the same vendor so that 419 the secure DDNS might be silently enabled as default.) However, there 420 is still a gap here, since the DHCP servers have to learn the 421 relevant hosts have changed their addresses and thus trigger the DDNS 422 update. If the hosts were numbered and also renumbered by DHCP, then 423 it is easy for the DHCP servers to learn the address changes; but if 424 the hosts were numbered by SLAAC, then there could be trouble. 425 [I-D.ietf-dhc-addr-registration] proposed a address registration 426 mechanism which could be used to address the latter issue; however, 427 it has not been deployed yet. 429 6.2. In-host Server Address Update 431 While DNS stores addresses of hosts in servers, hosts are also 432 configured with addresses of servers such as DNS server, radius 433 server. While renumbering, the hosts must update these addresses if 434 the server addresses changed. 436 In principle, the addresses of DHCPv6 servers do not need to be 437 updated, since they could be dynamically discovered through DHCPv6 438 relevant multicast messages. But in practice, most relay agents have 439 the alternative of being configured with DHCPv6 server address rather 440 than sending to a multicast address. So the DHCP server addresses 441 update might be an issue in practice. 443 6.3. Address update in scattered configurations 445 Besides the DNS records and the in-host server address entries, there 446 are also many places in which IP addresses are configured, for 447 example, filters such as ACL and routing policies. There are even 448 more sophisticated cases where the IP addresses are used for deriving 449 values, for example, using the unique portion of the loopback address 450 to generate an ISIS net ID. 452 In renumbering, it is annoying and error-prone to update the IP 453 addresses in all the above mentioned places. We lack a "one-stop" 454 mechanism to trigger the updates for all the subsystems on a 455 host/server, and all the external databases that refer to the IP 456 address update. We decompose the general "one-stop" gap into the 457 following two aspects. 459 o Self-contained Configuration in Individual device 461 In an ideal way, the IP addresses can be defined as a value once, and 462 then the administrators can use either keywords or variables to call 463 the value in other places such as a sort of internal inheritance in 464 CLI (command line interface) or other local configurations. This 465 makes it easier to manage a renumbering event by reducing the number 466 of places where a device's configuration must be updated. However, it 467 still means that every device needs to be touched, but only once 468 instead of having to inspect the whole configuration to ensure that 469 none of the separate places that a given IP address occurs is missed. 471 Among the current devices, some routers support defining multiple 472 loopback interfaces which can be called in other configurations. For 473 example, when defining a tunnel, it can call the defined loopback 474 interface to use its address as the local address of the tunnel. This 475 can be considered as a kind of parameterized self-contained 476 configuration. But this only applies certain use cases; it is 477 impossible to use the loopback interfaces to represent external 478 devices and it is not always possible to call loopback interfaces in 479 many other configurations. Parameterized self-contained configuration 480 is still a gap for current devices. 482 o Unified Configuration Management among Devices 484 This refers to a more formalized central configuration management 485 system, where all changes are made in one place and the system 486 manages how to push the changes to the individual devices. This issue 487 contains two aspects as the following. 489 - Configuration Aggregation 491 Configuration based on addresses or prefixes are usually spread in 492 various devices. As [RFC5887] described, some address configuration 493 data might be widely dispersed and much harder to find, even will 494 inevitably be found only after the renumbering event. So there's a 495 big gap for configuration aggregation, it is hard to get all the 496 relevant configurations through one place. 498 - Configuration Update Automation 500 As mentioned in section 3.2, [LEROY] proposed a mechanism which can 501 automatically update the configurations. The mechanism utilizes 502 macros suitable for various devices such as routers, firewalls. to 503 update the configurations based on the new prefix. Such automation 504 tool is valuable for renumbering because it can reduce manual 505 operation which is error-prone and inefficiency. 507 Besides the macros, [LEROY] also proposed to use SOAP to deliver 508 the macros to the devices. As well as SOAP we may consider whether 509 it is possible and suitable to use other standardized protocols 510 such as NETCONF [RFC4714]. 512 But in current real networks, most of the devices use vendor- 513 private protocols to update configurations, so it is not 514 necessarily valid to assume that there is going to be a formalized 515 configuration management system to leverage. Although there are 516 some vendor-independent tools as mentioned in section 3.2, a 517 standard and comprehensive way of uniformly updating configurations 518 in multi-vendor devices is still a big gap currently. 520 7. Renumbering Event Management 522 From the perspective of network management, renumbering is a kind of 523 event which may need additional process to make it more easy and 524 manageable. 526 7.1. Renumbering Notification 528 If hosts or servers are aware of a renumbering event happening, it 529 may benefit the relevant process. Following are several examples of 530 such additional process that may ease the renumbering. 532 o A notification mechanism may be needed to indicate to hosts that a 533 renumbering event has changed some DNS records in DNS servers 534 (normally, in an enterprise it/they is/are (a) local recursive DNS 535 server(s).), and then the hosts might want to refresh the DNS 536 cache. That mechanism may also need to indicate that such a change 537 will happen at a specific time in the future. 539 o As suggested in [RFC4192], if the DNS service can be given prior 540 notice about a renumbering event, then people could reduce the 541 delay in the transition to new IPv6 addresses, thus improve the 542 efficiency of renumbering. 544 o Router awareness: in a site with multiple domains which are 545 connected by border routers, all border routers should be aware of 546 renumbering in one domain or multiple domains, and update the 547 internal forwarding tables and the address/prefix based filters 548 accordingly to correctly handle inbound packets. 550 o Ingress filtering: ISPs normally enable ingress filter to drop 551 packets with source addresses from other ISPs at the end site 552 routers to prevent IP spoofing [RFC2827]. In a multihomed site 553 with multiple PA prefixes, the ingress router of ISP A should be 554 notified if the ISP B initiates a renumbering event in order to 555 properly update its filters to permit the new legitimate prefix 556 (es). For large enterprises, it might be applicable to indicate 557 this new legitimate prefix information through human communication, 558 however, for the millions of small enterprises, an automated 559 notification mechanism is needed. 561 o In the NMS (network management system), logs collected through 562 syslog, SNMP notification, IPFIX, etc. usually treat the UDP 563 message source IP addresses as the host or router IDs. When one 564 source IP address is changed, the log collectors will consider 565 that a new device appeared in the network. So a mechanism is 566 needed for the NMS applications to learn the renumbering event, so 567 that they could correlate the old and new addresses in the logs. 569 7.2. Synchronization Management 571 o DNS update synchronization 573 The DNS changes must be coordinated with the changes of node address 574 configuration. DNS has a latency issue of propagating information 575 from the server to the resolver. The latency is mainly caused by TTL 576 assigned to individual DNS records and the timing of updates from 577 primary to secondary servers [RFC4192]. 579 Ideally, during a renumbering operation, the DNS TTLs should always 580 be shorter than any other lifetime associated with an address. If the 581 TTLs were set correctly, then the DNS latency could be well 582 controlled. However, there might be some exceptional situations in 583 which the DNS TTLs were already set too long for the time available 584 to plan and execute a renumbering event. In these situations, there 585 currently are no mechanisms to deal with the already configured long 586 DNS TTLs. 588 7.3. Renumbering Monitoring 590 While treating renumbering as a network event, mechanisms to monitor 591 the renumbering process might be needed to inform the administrators 592 whether the renumbering has been successfully done. Considering the 593 address configuration operation might be stateless (if ND is used for 594 renumbering), it is difficult for monitoring. 596 8. Miscellaneous 598 Since multicast and mobility are special use cases which might not be 599 included in routine/common renumbering operations, they are 600 separately discussed as miscellaneous in this section. 602 8.1. Multicast 604 In the perspective of interface renumbering operations, renumbering a 605 multicast address is the same with renumbering a unicast address. So 606 this section mainly discusses the issues from the perspective of the 607 impact to the multicast application systems caused by renumbering. 609 Renumbering also has an impact on multicast. Renumbering of unicast 610 addresses affects multicast even if the multicast addresses are not 611 changed. There may also be cases where the multicast addresses need 612 to be renumbered. 614 o Renumbering of multicast sources 616 If a host that is a multicast source is renumbered, the application 617 on the host may need to be restarted for it to successfully send 618 packets with the new source address. 620 For ASM (Any-Source Multicast) the impact on a receiver is that a new 621 source appears to start sending, and it no longer receives from the 622 previous source. Whether this is an issue depends on the application, 623 but we believe it is likely to not be a major issue. 625 For SSM (Source-Specific Multicast) however, there is one significant 626 problem. The receiver needs to learn which source addresses it must 627 join. Some applications may provide their own method for learning 628 sources, where the source application may somehow signal the receiver. 630 Otherwise, the receiver may e.g. need to get new SDP information with 631 the new source address. This is similar to how to learn a new group 632 address, see the "Renumbering of multicast addresses" topic below. 634 o Renumbering of Rendezvous-Point 636 If the unicast addresses of routers in a network are renumbered, then 637 the RP (Rendezvous-Point) address is also likely to change for at 638 least some groups. An RP address is needed by PIM-SM for providing 639 ASM, and for Bidir PIM. Changing the RP address is not a major issue, 640 except that the multicast service may be impacted while the new RP 641 addresses are configured. If dynamic protocols are used for 642 distributing group-to-RP mappings, the change can be fairly quick, 643 and any impact should be only for a very brief time. However, if 644 routers are statically configured, this depends on how long it takes 645 to update all the configurations. 647 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) when 648 the first packet is received by the last-hop routers. Forwarding on 649 the SPT should not be impacted by change of IP address. Network 650 operator should be careful not deprecate the previous mapping before 651 configuring a new one, because implementations may revert to Dense 652 Mode if no RP is configured. 654 o Renumbering of multicast addresses 655 In general multicast addresses can be chosen independently of the 656 unicast addresses, and the multicast addresses can remain fixed even 657 if the unicast addresses are renumbered. However, for IPv6 there are 658 useful ways of deriving multicast addresses from unicast addresses, 659 such as unicast-prefix-based IPv6 Multicast Addresses [RFC3306] and 660 Embedded-RP IPv6 Multicast Addresses [RFC3956]. In that case the 661 multicast addresses used may have to be renumbered. 663 Renumbering group addresses may be complicated. For multicast, it is 664 common to use literal addresses, and not DNS. When multicast 665 addresses are changed, source applications need to be reconfigured 666 and restarted. 668 Multicast receivers need to learn the new group addresses to join. 670 Note that for SSM, receivers need to learn which multicast channels 671 to join. A channel is a source and group pair. This means that for an 672 SSM application, a change of source address is likely to have the 673 same effect as a change of group address. 675 Some applications may have dynamic methods of learning which groups 676 (and possibly sources) to join. If not, the application may have to 677 be reconfigured and restarted. 679 One common way for receivers to learn the necessary parameters is by 680 use of SDP. SDP information may be distributed via various 681 application protocols, or it may be from a file. An SDP file may be 682 distributed via HTTP, email etc. If a user is using a web browser and 683 clicking on a link to launch the application with the necessary data, 684 it may be a matter of closing the current application, and re- 685 clicking the link. 687 In summary, currently the multicast renumbering issues are basically 688 handled by application-specific methods. There is no standard way to 689 guarantee multicast service could live across a renumbering event. 691 8.2. Mobility 693 As described in [RFC5887], if a mobile node's home address changes 694 unexpectedly, the node can be informed of the new global routing 695 prefix used at the home site through the Mobile Prefix Solicitation 696 and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. But if the 697 mobile node is unfortunately disconnected at the time of home address 698 renumbering, it will no longer know a valid subnet anycast address 699 for its home agent, leaving it to deduce a valid address on the basis 700 of DNS information. 702 So, for Mobile IP, we need a better mechanism to handle change of 703 home agent address while mobile is disconnected. 705 9. Gap Summary 707 9.1. Managing Prefixes 709 o A mechanism informing the router to renumber themselves by 710 delegated prefixes 712 o A mechanism for the routers to derive addresses automatically 713 based on the delegated prefixes. 715 9.2. Address configuration 717 o Host address configuration 719 - DHCPv6-configured hosts might not able to be renumbered by RA on 720 some of current implementations 722 - DHCPv6-configured hosts might not able to learn new RA prefixes 723 on some of current implementations 725 - SLAAC-configured hosts might not able to add DHCPv6 address(es) 726 on some of current implementations 728 o Router address configuration 730 - A mechanism for interior routers in multihomed site to learn 731 which upstream providers and prefixes were currently reachable 733 - Cache-clear might need restart (rarely in modern routers) 735 - Using router domain names is not widely learned/deployed by 736 administrators 738 9.3. Address relevant entries update 740 o DNS records update 742 - For key management scalable issue, secure dynamic DNS update is 743 usually done by DHCP servers on behalf of the hosts, so it might 744 not be applicable for SLAAC-configured hosts to do secure DDNS. 746 o In-host server address update 747 - DHCP relays might be configured with DHCP server addresses 748 rather than sending multicast messages to discover the DHCP 749 server dynamically, so the DHCP server addresses update might be 750 an issue in practice. 752 o Address update in scattered configurations 754 - Devices don't support parameterized configuration, 755 administrators need to touch every places where IP addresses 756 were configured 758 - It is hard to get all the address-relevant configurations spread 759 in various devices through one place 761 - Uniformly update configurations in multi-vendor devices is a big 762 gap currently 764 9.4. Renumbering event management 766 o Renumbering notification 768 - A mechanism to indicate hosts local recursive DNS is going to be 769 renumbered 771 - A prior notice about a renumbering event for DNS 773 - A mechanism for border routers to know internal partial 774 renumbering 776 - For multihomed sites, a mechanism to notify the egress router of 777 ISPA that egress router connecting to ISPB initiates renumbering 778 is needed. 780 - A mechanism is needed for the NMS applications to learn the 781 renumbering event, so that they could correlate the old and new 782 addresses in the logs. 784 o Synchronization management 786 - DNS information propagating latency issue 788 o Renumbering monitoring 790 - Mechanisms to monitor the process and feedback of renumbering 791 might be needed. 793 9.5. Miscellaneous 795 o Multicast 797 - Mechanism for SSM receivers to learn the source addresses when 798 multicast sources are renumbered. 800 o Mobility 802 - A better mechanism to handle change of home agent address while 803 mobile is disconnected. 805 10. Gaps considered unsolvable 807 This section lists gaps have been identified by other documents but 808 are considered unsolvable. 810 10.1. Address Configuration 812 o RA prefix lifetime limitation 814 In section 5.5.3 of [RFC4862], it is defined that "If the received 815 Valid Lifetime is greater than 2 hours or greater than 816 RemainingLifetime, set the valid lifetime of the corresponding 817 address to the advertised Valid Lifetime." So when renumbering, if 818 the previous RemainingLifetime is longer than two hours, it is 819 impossible to reduce a prefix's lifetime less than two hours. This 820 limitation is to prevent denial-of-service attack. 822 10.2. Address-relevant Entries Update 824 o DNS authority 826 In an enterprise that hosts servers on behalf of collaborators and 827 customers, it is often the case that DNS zones outside the 828 administrative control of the hosting enterprise maintain resource 829 records concerning addresses for hosted nodes within its address 830 space. When the hosting enterprise renumbers, it does not have 831 sufficient authority to change those records. 833 This is an operational and policy issue. It is out of scope for this 834 document to consider a technical solution or to propose an additional 835 protocol or mechanism to standardize the interaction between DNS 836 systems for authority negotiations. 838 o DNS entries commonly have matching Reverse DNS entries which will 839 also need to be updated during renumbering. It might not be 840 possible to combine forward and reverse DNS entries update in one 841 procedure. 843 o DNS data structure optimization 845 [RFC2874] proposed an A6 record type for DNS recording of IPv6 846 address and prefix. Several extensions to DNS query and processing 847 were also proposed. A6 was designed to be a replacement for AAAA 848 record. The changes were designed to facilitate network renumbering 849 and multihoming. With the A6 record and the extensions, an IPv6 850 address could be defined by using multiple DNS records. This feature 851 would increase the complexity of resolvers but reduce the cost of 852 zone file maintenance, so renumbering could be easier than with the 853 AAAA record. 855 However, the A6 record has not been widely used, and has been shown 856 to have various problems and disadvantages (see section 2 in 857 [RFC6563]). It has been deprecated and moved to historic status by 858 [RFC6563]. The idea of a structured record to separate prefix and 859 suffix is still potentially valuable for renumbering, but avoiding 860 the problems of the A6 record would require a major development 861 effort. 863 10.3. Miscellaneous 865 o For transport layer, [RFC5887] said that TCP connections and UDP 866 flows are rigidly bound to a given pair of IP addresses. 868 o For application layer, in general, we can assert that any 869 implementation is at risk from renumbering if it does not check 870 whether an address is valid each time it starts session resumption 871 (e.g. a laptop wakes from sleep state). It is also more of less 872 risky when it opens a new communications session by using cached 873 addresses. 875 We considered the above two points (ID/Locator overloading in 876 transport layer & address caching in app layer) are fundamental 877 issues that might not be proper to deal with them just in terms of 878 renumbering. 880 11. Security Considerations 882 o Prefix Validation 883 Prefixes from the ISP may need authentication to prevent prefix 884 fraud. Announcing changes of site prefix to other sites (for example, 885 those that configure routers or VPNs to point to the site in 886 question) also need validation. 888 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or Secure 889 Neighbor Discovery (SEND, [RFC3971]) deployment may be needed to 890 validate prefixes. 892 o Influence on Security Controls 894 During renumbering, security controls (e.g. ACLs) protecting 895 legitimate resources should not be interrupted. For example, if some 896 addresses are in a blacklist, they should not escape from the 897 blacklist due to renumbering. 899 If there are DHCPv6 authentication keys associated with an IP address 900 then the keys need to be changed for continually working when the 901 addresses are renumbered. 903 Addresses in SEND certificates are going to need to get updated when 904 renumbering. During the overlap between old and new addresses, both 905 certificates must remain valid. 907 o Security Protection for Renumbering Notification 909 Section 7.1 mentions possible notification mechanisms to signal a 910 change in the DNS system or in the border routers related to a 911 renumbering event. Since DNS system and border routers are key 912 elements in any network, and they might take action according to the 913 notification, a security authentication for the renumbering 914 notification is needed. 916 o Security Protection for Configuration Update 918 Automated configuration update approaches like [LEROY] would increase 919 the risk since a bad actor with the right permission could cause 920 havoc to the networks. 922 12. IANA Considerations 924 This draft does not request any IANA actions. 926 13. Acknowledgments 928 This work adopts significant amounts of content from [RFC5887] and 929 particularly the "DNS Authority" topic in section 10.2 is from 931 [draft-chown-v6ops-renumber-thinkabout]. Both of the two documents 932 are important input for this work, that some 933 principles/considerations applied in this work are implicitly 934 inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, 935 Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were 936 provided by Oliver Bonaventure and his student Damien Leroy. 938 Many useful comments and contributions were made by Ted Lemon, Lee 939 Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit 940 Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke, 941 Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot 942 and other members of 6renum WG. 944 This document was prepared using 2-Word-v2.0.template.dot. 946 14. References 948 14.1. Normative References 950 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 951 Update", RFC 3007, November 2000. 953 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 954 M. Carney, "Dynamic Host Configuration Protocol for IPv6 955 (DHCPv6)", RFC 3315, July 2003. 957 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 958 Host Configuration Protocol (DHCP) version 6", RFC 3633, 959 December 2003. 961 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 962 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 963 November 2004. 965 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 966 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 968 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 969 "Neighbor Discovery for IP version 6 (IPv6)", RFC 970 4861,September 2007. 972 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 973 Address Autoconfiguration", RFC 4862, September 2007. 975 14.2. Informative References 977 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 978 1997. 980 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 981 Defeating Denial of Service Attacks which employ IP Source 982 Address Spoofing", RFC 2267, January 1998. 984 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 985 IPv6 Address Aggregation and Renumbering", RFC 2874, July 986 2000. 988 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 989 August 2000. 991 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 992 Multicast Addresses", RFC 3306, August 2002. 994 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) 995 Address in an IPv6 Multicast Address", RFC 3965, November 996 2004. 998 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 999 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1000 September 2005. 1002 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 1003 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 1004 RFC 4704, October 2006. 1006 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 1007 December 2006. 1009 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1010 from the IAB Workshop on Routing and Addressing", RFC 4984, 1011 September 2007. 1013 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1014 Still Needs Work", RFC 5887, May 2010. 1016 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 1017 Historic Status", RFC 6563, May 2012. 1019 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1020 "Default Address Selection for Internet Protocol Version 6 1021 (IPv6)", RFC 6724, September 2012. 1023 [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1024 in IPv6", RFC 3775, June 2004. 1026 [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for 1027 Renumbering IPv6 Hosts with Static Addresses in Enterprise 1028 Networks", RFC 6866, February 2013. 1030 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1031 Network Renumbering Scenarios, Considerations, and Methods", 1032 RFC 6879, February 2013. 1034 [I-D.ietf-6man-addr-select-opt] 1035 Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing 1036 Address Selection Policy using DHCPv6", Working in Progress, 1037 April 2013. 1039 [I-D.ietf-dhc-secure-dhcpv6] 1040 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 1041 in progress, March 2012. 1043 [I-D.ietf-dhc-addr-registration] 1044 Jiang, S., Chen G., and S. Krishnan, "A Generic IPv6 1045 Addresses Registration Solution Using DHCPv6", working in 1046 progress, February 2013. 1048 [I-D.liu-6renum-dhcpv6-slaac-switching] 1049 Liu, B., "DHCPv6/SLAAC Address Configuration Switching for 1050 Host Renumbering", Working in Progress, July 2012. 1052 [I-D.liu-bonica-dhcpv6-slaac-problem] 1053 Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration 1054 Interaction Problem Statement", Working in Progress, 1055 February 2013. 1057 [cfengine]http://cfengine.com/what-is-cfengine 1059 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 1060 configurations for IPv6 renumbering", International of 1061 Network Management, 2009, 1064 Authors' Addresses 1066 Bing Liu 1067 Huawei Technologies Co., Ltd 1068 Q14, Huawei Campus 1069 No.156 Beiqing Rd. 1070 Hai-Dian District, Beijing 100095 1071 P.R. China 1073 Email: leo.liubing@huawei.com 1075 Sheng Jiang 1076 Huawei Technologies Co., Ltd 1077 Q14, Huawei Campus 1078 No.156 Beiqing Rd. 1079 Hai-Dian District, Beijing 100095 1080 P.R. China 1082 Email: jiangsheng@huawei.com 1084 Brian Carpenter 1085 Department of Computer Science 1086 University of Auckland 1087 PB 92019 1088 Auckland, 1142 1089 New Zealand 1091 EMail: brian.e.carpenter@gmail.com 1093 Stig Venaas 1094 Cisco Systems 1095 Tasman Drive 1096 San Jose, CA 95134 1097 USA 1099 Email: stig@cisco.com 1100 Wesley George 1101 Time Warner Cable 1102 13820 Sunrise Valley Drive 1103 Herndon, VA 20171 1104 USA 1106 Phone: +1 703-561-2540 1107 Email: wesley.george@twcable.com