idnits 2.17.1 draft-liu-6renum-gap-analysis-01.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 4 instances of too long lines in the document, the longest one being 2 characters 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 (July 11, 2011) is 4666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Gaps TBD' is mentioned on line 521, but not defined == Missing Reference: 'TBD' is mentioned on line 680, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- No information found for draft-jiang-6renum-enterprise - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: January 11, 2012 July 11, 2011 6 IPv6 Site Renumbering Gap Analysis 7 draft-liu-6renum-gap-analysis-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on January 04, 2012. 26 Copyright Notice 28 Copyright (c) 2011 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 This document briefly introduces the existing mechanisms could be 44 utilized by IPv6 site renumbering and envisions the effort could be 45 done. This document tries to cover the most explicit issues and 46 requirements of IPv6 renumbering. Through the gap analysis, the 47 document provides a basis for future work to identify and develop 48 solutions or to stimulate such development as appropriate. The gap 49 analysis is presented following a renumbering event procedure clue. 51 Table of Contents 53 1. Introduction ................................................ 3 54 2. Overall Requirements for Renumbering ........................ 3 55 3. Existing Components for IPv6 Renumbering .................... 4 56 3.1. Relevant Protocols and Mechanisms .................... 4 57 3.2. Management Tools ....................................... 4 58 3.3. Procedures/Policies .................................... 5 59 4. Managing Prefixes ........................................... 5 60 4.1. Prefix Delegation ...................................... 5 61 4.2. Prefix Assignment ...................................... 5 62 5. Address Configuration ....................................... 6 63 5.1. Host Address Configuration ............................. 6 64 5.2. Router Address Configuration ........................... 7 65 5.3. Static Address Configuration ........................... 8 66 6. Address Relevant Entries Update ............................. 9 67 6.1. DNS Records Update ..................................... 9 68 6.2. In-host Server Address Update ......................... 10 69 6.3. Filters ............................................... 10 70 7. Renumbering Event Management ............................... 11 71 7.1. Renumbering Notification .............................. 11 72 7.2. Synchronization Management ............................ 12 73 7.3. Renumbering Monitoring........................... ..... 12 74 8. Miscellaneous .............................................. 12 75 8.1. Multicast ............................................. 12 76 8.2. Mobility .............................................. 13 77 9. Gap Summary ................................................ 13 78 9.1. Managing Prefixes ..................................... 13 79 9.2. Address configuration ................................. 13 80 9.3. Address relevant entries update ....................... 14 81 9.4. Renumbering event management .......................... 15 82 10. Security Considerations ................................... 15 83 11. IANA Considerations ....................................... 16 84 12. References ................................................ 16 85 12.1. Normative References ................................. 16 86 12.2. Informative References ............................... 17 87 13. Acknowledgments ........................................... 17 89 1. Introduction 91 As introduced in [RFC5887], renumbering, especially for medium to 92 large sites and networks, is currently viewed as an expensive, 93 painful, and error-prone process, avoided by network managers as much 94 as possible. If IPv6 site renumbering continues to be considered 95 difficult, network managers will turn to Provider Independent (PI) 96 addressing for IPv6 to attempt to minimize the need for future 97 renumbering. However, widespread use of PI may create very serious 98 BGP4 scaling problems. It is thus desirable to develop tools and 99 practices that may make renumbering a simpler process to reduce 100 demand for IPv6 PI space. 102 This document performs a gap analysis to provide a basis for future 103 work to identify and develop solutions or to stimulate such 104 development as appropriate. Gap analysis draws on existing work in 105 (at least) [RFC5887] and [RFC4192]. The [I-D.jiang-6renum-enterprise] 106 contributions are incorporated into the more detailed gap analysis. 107 In this document, we discuss the overall requirements for 108 renumbering. The gap analysis is organized by the main steps of 109 renumbering process, which include the prefix management, the node 110 address (re)configuration, and address relevant entries update in 111 various gateways, routers and servers, etc. Besides the steps, a sub- 112 clause of renumbering event management is presented independently, 113 which targets to help the operational/administrative process. 115 2. Overall Requirements for Renumbering 117 This section introduces the overall ultimate goals we want to achieve 118 in renumbering event. Some existing mechanisms have already provide 119 useful help. Further efforts may be achieved in the future. 121 o Prefix delegation and delivery should be automatic and accurate in 122 aggregation and coordination. 124 o Address reconfiguration should be automatically achieved through 125 standard protocols with minimum human intervene. 127 o Address relevant entries update should be processed integrally and 128 error-prevented. [Open Question]Is it necessary to develop 129 automatic entries update mechanisms? If necessary, do we need 130 standard protocols/interface for it? 132 o [Open Question] Is it necessary/possible to develop a ''One-Click'' 133 fully automatic renumbering technology? What scenarios have the 134 potential possibility? 136 o [Open Question] Is session survivability within our scope? 138 3. Existing Components for IPv6 Renumbering 140 3.1. Relevant Protocols and Mechanisms 142 Generally, renumbering is achieved by utilizing existing protocols 143 rather than dedicated renumbering protocols. 145 o RA messages, defined in [RFC4861], are used to deprecate/announce 146 old/new prefixes and to advertise the availability of an upstream 147 router. In renumbering, it is one of basic mechanisms for host 148 configuration. 150 o When a host is renumbered, it may use SLAAC [RFC4862] for address 151 configuration with the new prefix. Hosts receive RA messages which 152 contain routable prefix(es) and the address(es) of the default 153 router(s), then hosts can generate IPv6 address(es) by themselves. 155 o Hosts configured through DHCPv6 [RFC3315] can reconfigure 156 addresses by initialing RENEW sessions when the current addresses' 157 lease time are expired or they receive the reconfiguration 158 messages initiatedinitiated by the DHCPv6 servers. 160 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 161 delegation of IPv6 prefixes using the DHCPv6. initiated 163 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 164 This is a dedicated protocol for renumbering, but has not been 165 widely used. 167 3.2. Management Tools 169 Some operations of renumbering could be automatically processed by 170 management tools in order to make the renumbering process more 171 efficient and accurate. The tools may be designed dedicated for 172 renumbering or just common tools could be utilized for some 173 operations in renumbering. 175 Following are samples of the tools. 177 o [LEROY] proposed a mechanism of macros to automatically update the 178 address relevant entries/configurations inside the DNS, firewall, 179 etc. The macros can be delivered though SOAP protocol from a 180 network management server to the managed devices. 182 o Asset management tools/systems. These tools may provide the 183 ability of managing configuration files in nodes so that it is 184 convenient to update the address relevant configuration in these 185 nodes. 187 3.3. Procedures/Policies 189 o [RFC4192] proposed a procedure for renumbering an IPv6 network 190 without a flag day. The document includes a set of operational 191 suggestions which can be followed step by step by network 192 administrators. 194 o [I-D.jiang-6renum-enterprise] analyzes the enterprise renumbering 195 events and gives the recommendations among the existing 196 renumbering mechanisms. According to the different stages, 197 renumbering considerations are described in three categories: 198 considerations and recommendations during network design, for 199 preparation of enterprise network renumbering, and during 200 renumbering operation 202 4. Managing Prefixes 204 When renumbering an enterprise site, a short prefix may be divided 205 into longer prefixes for subnets. So we need to carefully manage the 206 prefixes for prefix delivery, delegation, aggregation, 207 synchronization, coordination, etc. 209 4.1. Prefix Delegation 211 Usually, the short prefix comes down from the operator and received 212 by DHCPv6 server or router inside the enterprise network. The short 213 prefix could be automatically delegated through DHCPv6-PD. Then the 214 downlink DHCP servers or routers can begin advertising the longer 215 prefixes to the subnets. 217 4.2. Prefix Assignment 219 When subnet routers receive the longer prefixes, they can directly 220 assign them to the hosts. The prefix assignment overlaps with the 221 host address configuration, which is described in the following 222 section 5.1. 224 5. Address Configuration 226 5.1. Host Address Configuration 228 Both of the DHCPv6 and ND protocols have IP address configuration 229 function. They are suitable for different scenarios respectively. 230 During renumbering, the SLAAC-configured hosts can reconfigure IP 231 addresses by receiving ND Router Advertisement (RA) messages 232 containing new prefix information (It should be noted that, the 233 prefix delivery could be achieved through DHCP according to the new 234 IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6- 235 configured hosts can reconfigure addresses by initiating RENEW 236 sessions when the current addresses' lease time are expired or 237 receiving the reconfiguration messages initiated by the DHCPv6 238 servers. 240 o SLAAC and DHCPv6 address configuration co-existence 242 While an IPv6 site is being renumbered, both DHCPv6 and ND may 243 be used to reconfigure the host addresses. The co-existence 244 issue mainly includes following aspects: 246 - Dynamic upstream learning 248 [RFC5887] mentioned that, DHCP-configured hosts may want to 249 learn about the upstream availability of new prefixes or loss 250 of prior prefixes dynamically by deducing from periodic RA 251 messages. But there is no standard specifying what approach 252 should be taken by a DHCPv6-configured host when it receives 253 RA messages containing new prefix. It depends on the operation 254 system of the host and cannot be predicted or controlled by 255 the network. 257 - DHCP/SLAAC conflict 259 If the DHCP-managed host accepts the new prefix in RA, it may 260 violet the DHCPv6-managed policies. But if it ignores the RA 261 messages and there are no DHCPv6 reconfiguration messages 262 received either, the renumbering would fail. What is worse, 263 the host may even receive both the RA messages and DHCP-v6 264 reconfiguration messages and finds the prefixes in the two 265 protocols are different. This means serious network 266 configuration error occurring. 268 [Open Question]It is hard for the host to identify the RA 269 messages containing new prefix(es) representing adding an 270 uplink or conflict caused by network configuration mistake. 272 - SLAAC-configured hosts finding DHCPv6 in use 274 [RFC5887] mentioned RA message of ND protocol contains a 275 "Managed Configuration" flag to indicate DHCPv6 is in use. But 276 it is unspecified what behavior should be taken when the host 277 receives RA messages with "M" set to 1. The gap of standard 278 will cause ambiguous host behavior because it depends on the 279 operation system of the host. 281 The host may start a DHCPv6 session and receives the DHCPv6 282 address configuration. It is also possible that the host finds 283 the DHCPv6 assigned prefix is different from the prefix in the 284 RA messages, which means multiple uplinks are available or 285 there is a serious network configuration error. 287 Another possibility is that the host may receive no response 288 from any DHCPv6 servers, which means the DHCPv6 service is not 289 available and the "Managed Configuration" flag was mis- 290 configured. 292 o DHCPv6 reconfigure bulk usage 294 [RFC5887] mentioned that ''DHCPv6 reconfiguration doesn't appear 295 to be widely used for bulk renumbering purposes''. 296 [Open Question] Using DHCPv6 reconfiguration can be considered 297 as ''stateful'' renumbering which need sessions maintained between 298 DHCP servers and clients. So maybe it is too heavy for the 299 servers. So is it possible for bulk renumbering? Is there any 300 requirement? 302 o RA prefix lifetime limitation 304 In section 5.5.3 of [RFC4862], it is defined that ''If the 305 received Valid Lifetime is greater than 2 hours or greater than 306 RemainingLifetime, set the valid lifetime of the corresponding 307 address to the advertised Valid Lifetime.'' So when renumbering, 308 if the previous RemainingLifetime is longer than two hours, it 309 is impossible to reduce a prefix's lifetime less than two hours. 310 This limitation is to prevent denial-of-service attack. 311 [Open Question]This limitation requires renumbering to be 312 planned in advance so that an immediate renumbering event is 313 impossible. Should it be considered as a standard gap for 314 renumbering? 316 5.2. Router Address Configuration 318 o Learning new prefixes 319 As described in [RFC5887], ''if a site wanted to be multihomed 320 using multiple provider-aggregated (PA) routing prefixes with 321 one prefix per upstream provider, then the interior routers 322 would need a mechanism to learn which upstream providers and 323 prefixes were currently reachable (and valid). In this case, 324 their Router Advertisement messages could be updated dynamically 325 to only advertise currently valid routing prefixes to hosts. 326 This would be significantly more complicated if the various 327 provider prefixes were of different lengths or if the site had 328 non-uniform subnet prefix lengths.'' 330 o Restart after renumbering 332 "Some routers cache IP addresses in some situations. So routers 333 might need to be restarted as a result of site renumbering" 334 [RFC2072]. 335 After investigation, it seems (need further confirmation) this 336 caused by individual implementation and only happen on the old 337 type of routers. Therefore, it is not an issue anymore. 339 o Router naming 341 In [RFC4192], it is suggested that ''To better support 342 renumbering, switches and routers should use domain names for 343 configuration wherever appropriate, and they should resolve 344 those names using the DNS when the lifetime on the name 345 expires.'' 346 As [RFC5887] described, this capability is not new, and at least 347 it is present in most IPsec VPN implementations. But many 348 administrators do not realize that it could be utilized to avoid 349 manual modification during renumbering. 350 [Open Question]Whether it is not easy to use or just suitable in 351 few situations needs further investigation. 353 5.3. Static Address Configuration 355 Further gap analysis about static address issue could consider the 356 following suggestions (proposed by George Wesley in the mail list). 358 o Documenting how to limit the places where static addresses must be 359 used (vs FQDN or autoconf). 361 o Identifying gaps and proposing solutions in other areas to reduce 362 the number of places that static addresses are required. 364 o Documenting any gaps in [RFC4192] to make renumbering easier for a 365 statically-numbered set of hosts and potentially identifying a 366 problem statement for improving renumbering for static. 368 [Open Question]Besides the open questions above, the ULA utilization 369 issue may also need consideration. 371 6. Address Relevant Entries Update 373 When nodes in a site have been renumbered, then all the entries in 374 the site which contain the nodes' addresses must be updated. The 375 entries mainly include DNS records and filters in various entities 376 such as ACLs in firewalls/gateways. 378 6.1. DNS Records Update 380 o DNS update automation 382 For DNS records update, most sites will achieve it by 383 maintaining a DNS zone file and loading this file into the 384 site's DNS server(s). Synchronization between host renumbering 385 and the updating of its A6 or AAAA record is hard. [RFC5887] 386 mentioned that an alternative is to use Secure Dynamic DNS 387 Update [RFC3007], in which a host informs its own DNS server 388 when it receives a new address. But Secure Dynamic DNS Update 389 hasn't been widely deployed. 391 [Open Question]To popularize the [RFC3007] or to develop a 392 lightweight dedicated protocol for this need to be considered. 394 DNS entries commonly have matching Reverse DNS entries which 395 will also need to be updated during renumbering. 397 [Open Question]So synchronizing the procedures of forward and 398 reverse DNS or even combining forward and reverse DNS updates in 399 a single procedure also need to be considered. 401 o DNS data structure optimization 403 [RFC2874] proposed a new A6 record type for DNS recording IPv6 404 address/prefix. And several extensions on query and processing 405 were also proposed. With the A6 record and the extensions, an 406 IPv6 address can be defined by using multiple DNS records. This 407 feature increases the complexity of resolver but reduce the cost 408 of zone file maintenance. So renumbering could be easier than 409 AAAA record. But the [RFC2874] has not been widely used. 411 [Open Question]Is the DNS data structure optimization such as 412 [RFC2874] necessary for easing renumbering? If necessary, is the 413 optimization in [RFC2874] enough? 415 o DNS authority 417 As described in [I-D.chown-v6ops-renumber-thinkabout], ''it is 418 often the case in enterprises that host web servers and 419 application servers on behalf of collaborators and customers 420 that DNS zones out of the administrative control of the host 421 maintain resource records concerning addresses for nodes out of 422 their control. When the service host renumbers, they do not have 423 sufficient authority to change the records.'' 425 [Open Question]Whether it is only an operational issue or 426 additional protocol/mechanism is needed to standardize the 427 interaction between DNS systems needs to be considered. 429 6.2. In-host Server Address Update 431 While DNS records addresses of hosts in servers, hosts also record 432 addresses of servers such as DNS server, radius server, etc. While 433 renumbering, the hosts must update the records if the server 434 addresses changed. Addresses of DHCPv6 servers do not need to be 435 updated. They are dynamic discovered using DHCPv6 relevant multicast 436 addresses. 438 o The DNS server addresses for hosts are configured by DHCPv6. But 439 current DHCPv6 messages do not indicate hosts the lifetimes of DNS. 440 If the DNS lifetime expired and has been renumbered, the hosts may 441 still use the old addresses. DHCPv6 should be extended to indicate 442 hosts the associated DNS lifetimes when making DNS configuration. 443 How does the DHCP server could know about the DNS lifetime is 444 another issue. 446 6.3. Filters 448 o Filters Management 450 Filters based on addresses or prefixes are usually spread in 451 various devices. As [RFC5887] described, some address 452 configuration data might be widely dispersed and much harder to 453 find, even will inevitably be found only after the renumbering 454 event. So there's a big gap for filter management. 456 In [LEROY], a server is used for managing filter update in 457 various devices. But identifying where and which of the filters 458 need to be updated during renumbering is still a gap. 460 o Filter Update Automation Operation 462 As mentioned in section 3.2, [LEROY] proposed a mechanism which 463 can automatically update the filters. The mechanism utilizes 464 macros suitable for various devices such as routers, firewalls 465 etc. to update the filter entries based on the new prefix. Such 466 automation tool is valuable for renumbering because it can 467 reduce manual operation which is error-prone and inefficiency. 469 [Open Question]Besides the macros, [LEROY] also proposed to use 470 SOAP to deliver the macros to the devices. So there may be 471 requirement of protocol standardization. [LEROY] uses 472 application layer protocol while we may consider whether it is 473 possible and suitable to use network layer protocol. 475 [Open Question] Update of filters based on prefixes and filters 476 based on addresses may have different requirements and methods. 477 For example, the prefix-based filters may consider to be updated 478 though DHCPv6 server, which may provide better efficient. 480 7. Renumbering Event Management 482 From the perspective of network management, renumbering is a kind of 483 event which may need additional process to make the process more easy 484 and manageable. 486 7.1. Renumbering Notification 488 If hosts or servers are aware of a renumbering event happening, it 489 may help the relevant process. Following are several examples of such 490 additional process may ease the renumbering. Further contributions 491 are expected. 493 o A notification mechanism may be needed to indicate the hosts that 494 a renumbering event of local recursive DNS happen or is going to 495 take place. 497 o [RFC4192] suggests that ''reducing the delay in the transition to 498 new IPv6 addresses applies when the DNS service can be given prior 499 notice about a renumbering event.'' Reducing delay could improve 500 the efficiency of renumbering. 502 7.2. Synchronization Management 504 o DNS update synchronization 506 DNS update synchronization focuses on the coordinating between 507 DNS and other entities/mechanims, for example, as described in 508 [RFC5887], synchronizing the SLAAC and DNS updates, and of 509 reducing the SLAAC lease time and DNS TTL. 511 [Gaps TBD] 513 7.3. Renumbering Monitoring 515 While treating renumbering a network event, mechanisms to monitor the 516 renumbering process may be needed. Considering the address 517 configuration operation may be stateless(if ND is used for 518 renumbering), it is difficult for monitoring. But for the DNS and 519 filter update, it is quite possible to monitor the whole process. 521 [Gaps TBD] 523 8. Miscellaneous 525 8.1. Multicast 527 o The embedding of IPv6 unicast addresses into multicast addresses 528 and the embedded-RP (Rendezvous Point)[RFC3956] will cause issues 529 when renumbering. 531 As [I-D.chown-v6ops-renumber-thinkabout] described, ''If the RP 532 address changes, then the group addresses must also be changed. 533 This may happen not only when a site is renumbered, but also if 534 a site is restructured or the RP is moved within the site. The 535 embedded address is used by routers to determine the RP address. 536 Applications must use new group addresses once the RP is not 537 available on the old address.'' 539 o Changing the unicast source address of a multicast sender might 540 also be an issue for receivers. 542 As [I-D.chown-v6ops-renumber-thinkabout] described, ''If a site's 543 unicast prefix changes, then one will also need to change the 544 multicast addresses. By way of example, a site renumbering away 545 from prefix 2001:DB8:BEEF::/48" might have globally-scoped 546 multicast addresses in use under the prefix 547 "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old 548 addresses for a while, but this should be avoided since another 549 site may inherit the prefix and they may end up using the same 550 multicast addresses.'' 552 8.2. Mobility 554 o [RFC5887] suggested that, for Mobile IP, define a better mechanism 555 to handle change of home agent address while mobile is 556 disconnected. 558 9. Gap Summary 560 9.1. Managing Prefixes 562 None. (call for contributions) 564 9.2. Address configuration 566 o Host address configuration 568 - SLAAC and DHCPv6 address configuration co-existence 570 -Dynamic upsteam learning: 571 DHCP-configured host may want to learn about the upstream 572 availability of new prefixes or loss of prior prefixes 573 dynamically by deducing from periodic RA messages. 575 -DHCP/SLAAC conflict: 576 Prefixes in the two protocols' massages may be different, 577 which may be caused by serious network configuration error. A 578 diagnosis/report mechanism is needed here. 580 -SLAAC-configured hosts find DHCPv6 is in use: 581 RA messages contain a "Managed Configuration" flag to indicate 582 DHCPv6 is in use. But it is unspecified what behavior should 583 be taken when the host receives RA messages with "M" set to 1. 584 The gap of standard will cause ambiguous host behavior. 586 - DHCPv6 reconfigure bulk usage 588 Maybe it is too heavy for the server. So is it possible for 589 bulk renumbering? Is there any requirement? 591 - RA prefix lifetime limitation 593 If previous RemainingLifetime is longer than two hours, it is 594 impossible to reduce a prefix's lifetime less than two hours. 595 Is it a standard gap for renumbering? 597 o Router address configuration 599 - Learning new prefixes 601 If the site is multihoming, the interior routers would need a 602 mechanism to learn which upstream providers and prefixes were 603 currently reachable (and valid). 605 - Restart after renumbering 607 Some routers cache IP addresses in some situations. So routers 608 might need to be restarted as a result of site renumbering. 610 - Router naming 612 Using domain names for routers is suitable in some scenarios 613 but has not been widely deployed. Whether it is not easy to 614 use or just suitable in few situations needs further 615 investigation. 617 o Static address configuration 619 Further work is needed. 621 9.3. Address relevant entries update 623 o DNS records update 625 - DNS update automation 627 Synchronization between host renumbering and the updating of 628 its DNS records is hard. Forward and reverse DNS entries 629 update may need to be combined together. 631 - DNS data structure optimization 633 Is the DNS data structure optimization as A6 record [RFC2874] 634 necessary for easing renumbering? 636 - DNS authority 638 DNS zones are out of the administrative control. Authority 639 collaboration is needed. 641 o In-host server address update 642 Hosts also record addresses of servers such as DNS server 643 addresses, radius server address, etc. While renumbering, the 644 host must update the records if these server addresses changed. 646 o Filters 648 - Filters management 650 There is a gap of filter management to identify where and 651 which of the filters need to be updated during renumbering. 652 Manageable filter update may be also needed. 654 - Filter update automation operation 656 Automation update tool is valuable for renumbering, and there 657 may be requirement of protocol standardization to deliver of 658 facility the tools. 660 9.4. Renumbering event management 662 o Renumbering notification 664 If hosts/servers are aware of a renumbering event happening, it may 665 help the relevant process. A basic way is to extend current protocol 666 messages to carry the renumbering notification. 668 o Synchronization management 670 - DNS update synchronization 672 An example is synchronizing the SLAAC and DNS updates, and of 673 reducing the SLAAC lease time and DNS TTL. 675 [TBD] 677 o Renumbering monitoring 679 Mechanisms to monitor the process and feedback of renumbering may be 680 needed. [TBD] 682 10. Security Considerations 684 o Prefix Validation 686 Prefixes from the ISP may need authentication to prevent prefix 687 fraud. Announcing changes of site prefix to other sites (for example, 688 those that configure routers or VPNs to point to the site in 689 question) also need validation. 691 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND 692 ([RFC3971], Secure Neighbor Discovery) deployment may need to 693 validate prefixes. 695 o Influence to Security Controls 697 During renumbering, security controls (e.g. ACLs) blocking access to 698 legitimate resources should not be interrupted. 700 11. IANA Considerations 702 None. 704 12. References 706 12.1. Normative References 708 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 709 August 2000. 711 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 712 IPv6 Address Aggregation and Renumbering", RFC 2874, July 713 2000. 715 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 716 Update", RFC 3007, November 2000. 718 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 719 M. Carney, "Dynamic Host Configuration Protocol for IPv6 720 (DHCPv6)", RFC 3315, July 2003. 722 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 723 Host Configuration Protocol (DHCP) version 6", RFC 3633, 724 December 2003. 726 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 727 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 728 November 2004. 730 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 731 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 733 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 734 "Neighbor Discovery for IP version 6 (IPv6)", RFC 735 4861,September 2007. 737 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 738 Address Autoconfiguration", RFC 4862, September 2007. 740 12.2. Informative References 742 [RFC2072] H. Berkowitz, "Router Renumbering Guide" RFC2072 744 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 745 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 746 September 2005. 748 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 749 Still Needs Work", RFC 5887, May 2010. 751 [I-D.ietf-dhc-secure-dhcpv6] 752 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 753 in progress. 755 [I-D.chown-v6ops-renumber-thinkabout] 756 Chown, T., "Things to think about when Renumbering an IPv6 757 network", Work in Progress, September 2006. 759 [I-D.jiang-6renum-enterprise] 760 Jiang, S., and Liu B., " IPv6 Enterprise Network 761 Renumbering Scenarios and Guidelines ", Working in 762 Progress, July 2011. 764 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 765 configurations for IPv6 renumbering", International of 766 Network Management, 2009, 769 13. Acknowledgments 771 This work adopts significant amounts of content from [RFC5887] and 772 [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, 773 Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, 774 and Stig Venaas. Some useful materials were provided by Oliver 775 Bonaventure and his student Damien Leroy, thanks for them, too. 777 Useful comments and contributions were made by George Wesley, and 778 others. 780 This document was prepared using 2-Word-v2.0.template.dot. 782 Authors' Addresses 784 Bing Liu 785 Huawei Technologies Co., Ltd 786 Huawei Building, No.3 Xinxi Rd., 787 Shang-Di Information Industry Base, Hai-Dian District, Beijing 788 P.R. China 790 Email: leo.liubing@huawei.com 792 Sheng Jiang 793 Huawei Technologies Co., Ltd 794 Huawei Building, No.3 Xinxi Rd., 795 Shang-Di Information Industry Base, Hai-Dian District, Beijing 796 P.R. China 798 Email: jiangsheng@huawei.com