idnits 2.17.1 draft-liu-6renum-gap-analysis-02.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 2 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 (October 31, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 613, but not defined -- Looks like a reference, but probably isn't: '5887' on line 821 == Unused Reference: 'RFC4714' is defined on line 682, but no explicit reference was found in the text ** 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? -- No information found for draft-carpenter-6renum-static-problem - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: May 1, 2012 B . Carpenter 5 University of Auckland 6 October 31, 2011 8 IPv6 Site Renumbering Gap Analysis 9 draft-liu-6renum-gap-analysis-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on May 1, 2012. 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document briefly introduces the existing mechanisms could be 46 utilized by IPv6 site renumbering and envisions the effort could be 47 done. This document tries to cover the most explicit issues and 48 requirements of IPv6 renumbering. Through the gap analysis, the 49 document provides a basis for future work to identify and develop 50 solutions or to stimulate such development as appropriate. The gap 51 analysis is presented following a renumbering event procedure clue. 53 Table of Contents 55 1. Introduction ................................................. 3 56 2. Overall Requirements for Renumbering ......................... 3 57 3. Existing Components for IPv6 Renumbering ..................... 4 58 3.1. Relevant Protocols and Mechanisms ....................... 4 59 3.2. Management Tools ........................................ 5 60 3.3. Procedures/Policies ..................................... 5 61 4. Managing Prefixes ............................................ 6 62 4.1. Prefix Delegation ....................................... 6 63 4.2. Prefix Assignment ....................................... 6 64 5. Address Configuration ........................................ 6 65 5.1. Host Address Configuration .............................. 6 66 5.2. Router Address Configuration ............................ 8 67 5.3. Static Address Configuration ............................ 9 68 6. Address Relevant Entries Update .............................. 9 69 6.1. DNS Records Update ...................................... 9 70 6.2. In-host Server Address Update .......................... 10 71 6.3. Filters ................................................ 10 72 7. Renumbering Event Management ................................ 11 73 7.1. Renumbering Notification ............................... 11 74 7.2. Synchronization Management ............................. 11 75 7.3. Renumbering Monitoring ................................. 11 76 8. Miscellaneous ............................................... 12 77 9. Gap Summary ................................................. 12 78 9.1. Managing Prefixes ...................................... 12 79 9.2. Address configuration .................................. 12 80 9.3. Address relevant entries update ........................ 13 81 9.4. Renumbering event management ........................... 14 82 10. Security Considerations .................................... 14 83 11. IANA Considerations......................................... 14 84 12. References ................................................. 15 85 12.1. Normative References .................................. 15 86 12.2. Informative References ................................ 15 87 13. Acknowledgments ............................................ 16 88 Appendix A. Other Documented Gaps .............................. 17 90 1. Introduction 92 As introduced in [RFC5887], renumbering, especially for medium to 93 large sites and networks, is currently viewed as an expensive, 94 painful, and error-prone process, avoided by network managers as much 95 as possible. If IPv6 site renumbering continues to be considered 96 difficult, network managers will turn to Provider Independent (PI) 97 addressing for IPv6 to attempt to minimize the need for future 98 renumbering. However, widespread use of PI may create very serious 99 BGP4 scaling problems. It is thus desirable to develop tools and 100 practices that may make renumbering a simpler process to reduce 101 demand for IPv6 PI space. 103 This document performs a gap analysis to provide a basis for future 104 work to identify and develop solutions or to stimulate such 105 development as appropriate. The gap analysis is organized by the main 106 steps of renumbering process, which include prefix management, node 107 address (re)configuration, and updating relevant address entries in 108 various gateways, routers and servers, etc. Besides these steps, the 109 aspect of renumbering event management is presented independently, 110 which intends to help the operational/administrative process. It is 111 expected that these steps and management could cover all the aspects 112 of an renumbering event. 114 This document draws on existing work in (at least) [RFC5887], [I- 115 D.chown-v6ops-renumber-thinkabout] and [RFC4192]. Contributions from 116 [I-D.jiang-6renum-enterprise] are incorporated into the more detailed 117 analysis. Lots of issues were analyzed in RFC5887 & [I-D.chown-v6ops- 118 renumber-thinkabout], but many of them are out of 6renum scope or 119 unsolvable. This document intends to identify the valuable and 120 solvable issues, dig out of some undiscovered gaps, and tries to give 121 solution suggestions. 123 2. Overall Requirements for Renumbering 125 This section introduces the overall ultimate goals we want to achieve 126 in a renumbering event. In general, we need to leverage renumbering 127 automation to avoid human intervention as much as possible at 128 reasonable cost. Some existing mechanisms have already provided 129 useful help. Further efforts may be achieved in the future. 131 The automation can be divided into four aspects as follows, which are 132 also the gap analysis topics. 134 o Prefix delegation and delivery should be automatic and accurate in 135 aggregation and coordination. 137 o Address reconfiguration should be automatically achieved through 138 standard protocols with minimum human intervention. 140 o Updating relevant address entries should be performed integrally 141 and without error. [Open Question]Is it necessary to develop 142 automatic entries update mechanisms? If necessary, do we need 143 standard protocols/interface for it? 145 o Renumbering event management is needed to provide the functions of 146 renumbering notification, synchronization, and monitoring .etc. 148 Besides automation, session survivability is another important issue 149 during renumbering since application outage is one of the most 150 obvious impacts that make renumbering painful and expensive. We have 151 an enormous advantage in IPv6 which is the ability to overlap the old 152 and new prefixes and to use the address lifetime mechanisms in SLAAC 153 and DHCPv6. That is fully described in [RFC4192]. We consider this 154 mechanism is sufficient for session survivability issue in most of 155 the cases. 157 [Open Question]Should we consider the case of very long-lived 158 application sessions (days or weeks) which cannot be resolved by 159 [RFC4192]? 161 3. Existing Components for IPv6 Renumbering 163 Since renumbering is not a whole new issue, some protocols/mechanisms 164 have been already utilized or even be developed dedicated for 165 renumbering. However, generally current renumbering is achieved by 166 existing protocols rather than dedicated renumbering protocols. This 167 section briefly reviews these existing protocols/mechanisms to 168 provide a basis for the gap analysis. 170 3.1. Relevant Protocols and Mechanisms 172 o RA messages, defined in [RFC4861], are used to deprecate/announce 173 old/new prefixes and to advertise the availability of an upstream 174 router. In renumbering, it is one of basic mechanisms for host 175 configuration. 177 o When a host is renumbered, it may use SLAAC [RFC4862] for address 178 configuration with the new prefix. Hosts receive RA messages which 179 contain routable prefix(es) and the address(es) of the default 180 router(s), then hosts can generate IPv6 address(es) by themselves. 182 o Hosts configured through DHCPv6 [RFC3315] can reconfigure 183 addresses by initialing RENEW sessions when the current addresses' 184 lease time are expired or they receive the reconfiguration 185 messages initiated by the DHCPv6 servers. 187 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 188 delegation of IPv6 prefixes using the DHCPv6. 190 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 191 This is a dedicated protocol for renumbering, but has not been 192 widely used. 194 3.2. Management Tools 196 Some operations of renumbering could be automatically processed by 197 management tools in order to make the renumbering process more 198 efficient and accurate. The tools may be designed dedicated for 199 renumbering or just common tools could be utilized for some 200 operations in renumbering. 202 Following are samples of the tools. 204 o Address management tools. There are both commercial and open- 205 source, and even home-made solutions. 206 [Further work is needed to identify what an address management 207 tool should be able to do for improving the ability of managing a 208 network through a renumbering event.] 210 o [LEROY] proposed a mechanism of macros to automatically update the 211 address relevant entries/configurations inside the DNS, firewall, 212 etc. The macros can be delivered though SOAP protocol from a 213 network management server to the managed devices. 215 o Asset management tools/systems. These tools may provide the 216 ability of managing configuration files in nodes so that it is 217 convenient to update the address relevant configuration in these 218 nodes. 220 3.3. Procedures/Policies 222 o [RFC4192] proposed a procedure for renumbering an IPv6 network 223 without a flag day. The document includes a set of operational 224 suggestions which can be followed step by step by network 225 administrators. 227 o [I-D.jiang-6renum-enterprise] analyzes the enterprise renumbering 228 events and gives the recommendations among the existing 229 renumbering mechanisms. According to the different stages, 230 renumbering considerations are described in three categories: 231 considerations and recommendations during network design, for 232 preparation of enterprise network renumbering, and during 233 renumbering operation 235 4. Managing Prefixes 237 When renumbering an enterprise site, a short prefix may be divided 238 into longer prefixes for subnets. So we need to carefully manage the 239 prefixes for prefix delivery, delegation, aggregation, 240 synchronization, coordination, etc. 242 4.1. Prefix Delegation 244 Usually, the short prefix comes down from the operator and received 245 by DHCPv6 server or router inside the enterprise network. The short 246 prefix could be automatically delegated through DHCPv6-PD. Then the 247 downlink DHCP servers or routers can begin advertising the longer 248 prefixes to the subnets. 250 For the delegation routers, they may need to renumber themselves with 251 the delegated prefixes. We need to consider the router renumbering 252 issue which cannot be covered by DHCP-PD only. 254 4.2. Prefix Assignment 256 When subnet routers receive the longer prefixes, they can directly 257 assign them to the hosts. The prefix assignment overlaps with the 258 host address configuration, which is described in the following 259 section 5.1. 261 5. Address Configuration 263 5.1. Host Address Configuration 265 Both of the DHCPv6 and ND protocols have IP address configuration 266 function. They are suitable for different scenarios respectively. 267 During renumbering, the SLAAC-configured hosts can reconfigure IP 268 addresses by receiving ND Router Advertisement (RA) messages 269 containing new prefix information (It should be noted that, the 270 prefix delivery could be achieved through DHCP according to the new 271 IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6- 272 configured hosts can reconfigure addresses by initiating RENEW 273 sessions when the current addresses' lease time are expired or 274 receiving the reconfiguration messages initiated by the DHCPv6 275 servers. 277 o SLAAC and DHCPv6 address configuration co-existence 279 While an IPv6 site is being renumbered, both DHCPv6 and ND may 280 be used to reconfigure the host addresses. The co-existence 281 issue mainly includes following aspects: 283 - Dynamic upstream learning 285 [RFC5887] mentioned that, DHCP-configured hosts may want to 286 learn about the upstream availability of new prefixes or loss 287 of prior prefixes dynamically by deducing from periodic RA 288 messages. But there is no standard specifying what approach 289 should be taken by a DHCPv6-configured host when it receives 290 RA messages containing new prefix. It depends on the operation 291 system of the host and cannot be predicted or controlled by 292 the network. 294 - DHCP-managed hosts receiving RA messages 296 It is unclear that whether a DHCP-managed host would accept 297 configuration though RA messages, it depends on the policies 298 in the host's operating system. If it ignores the RA messages 299 and there are no DHCPv6 reconfiguration messages received 300 either, the renumbering would fail. 302 - SLAAC-configured hosts finding DHCPv6 in use 304 [RFC5887] mentioned RA message of ND protocol contains a 305 "Managed Configuration" flag to indicate DHCPv6 is in use. But 306 it is unspecified what behavior should be taken when the host 307 receives RA messages with "M" set to 1. The gap of standard 308 will cause ambiguous host behavior because it depends on the 309 operation system of the host. 311 The host may start a DHCPv6 session and receives the DHCPv6 312 address configuration. It is also possible that the host finds 313 the DHCPv6 assigned prefix is different from the prefix in the 314 RA messages, which means multiple uplinks are available or 315 there is a serious network configuration error. 317 Another possibility is that the host may receive no response 318 from any DHCPv6 servers, which means the DHCPv6 service is not 319 available and the "Managed Configuration" flag was mis- 320 configured. 322 o DHCPv6 reconfigure bulk usage 324 [RFC5887] mentioned that ''DHCPv6 reconfiguration doesn't appear 325 to be widely used for bulk renumbering purposes''. 327 The reconfiguration defined in [RFC3315] needs to establish a 328 session between DHCP server and client. This could be considered 329 as a stateful approach which needs much resource on the server 330 to maintain the renumbering sessions. This is probably one of 331 the reasons that DHCP reconfiguration is not suitable for bulk 332 usage. 334 Another limitation of reconfiguration is that it only allows th 335 e messages to be delivered to unicast addresses. So if we want 336 to use it for bulk renumbering, stateless DHCPv6 reconfiguration 337 with multicast may be needed. However, this may involve protocol 338 modification. 340 5.2. Router Address Configuration 342 o Learning new prefixes 344 As described in [RFC5887], "if a site wanted to be multihomed 345 using multiple provider-aggregated (PA) routing prefixes with 346 one prefix per upstream provider, then the interior routers 347 would need a mechanism to learn which upstream providers and 348 prefixes were currently reachable (and valid). In this case, 349 their Router Advertisement messages could be updated dynamically 350 to only advertise currently valid routing prefixes to hosts. 351 This would be significantly more complicated if the various 352 provider prefixes were of different lengths or if the site had 353 non-uniform subnet prefix lengths." 355 o Restart after renumbering 357 "Some routers cache IP addresses in some situations. So routers 358 might need to be restarted as a result of site renumbering" 359 [RFC2072]. 361 o Router naming 363 In [RFC4192], it is suggested that "To better support 364 renumbering, switches and routers should use domain names for 365 configuration wherever appropriate, and they should resolve 366 those names using the DNS when the lifetime on the name 367 expires." 368 As [RFC5887] described, this capability is not new, and at least 369 it is present in most IPsec VPN implementations. But many 370 administrators do not realize that it could be utilized to avoid 371 manual modification during renumbering. 373 In enterprise scenario, the requirement of router naming is not 374 as strong as that in ISP. So for the administrators, the 375 motivation of using router naming for easing renumbering may be 376 not enough. 377 [Open Question]Whether it is not easy to use or just suitable in 378 few situations needs further investigation. 380 5.3. Static Address Configuration 382 There is another draft dedicated to the static address issue. Please 383 refer to [I-D.carpenter-6renum-static-problem]. 385 6. Updating Relevant Address Entries 387 When nodes in a site have been renumbered, then all the entries in 388 the site which contain the nodes' addresses must be updated. The 389 entries mainly include DNS records and filters in various entities 390 such as ACLs in firewalls/gateways. 392 6.1. DNS Records Update 394 o Dynamic DNS update 396 For DNS records update, most sites will achieve it by 397 maintaining a DNS zone file and loading this file into the 398 site's DNS server(s). Synchronization between host renumbering 399 and the updating of its A6 or AAAA record is hard. [RFC5887] 400 mentioned that an alternative is to use Secure Dynamic DNS 401 Update [RFC3007], in which a host informs its own DNS server 402 when it receives a new address. 404 Secure Dynamic DNS Update has been widely supported by the major 405 DNS systems, but it hasn't been widely deployed, especially in 406 the host. Current practices mainly involve the DHCP servers 407 which act as clients to request the DNS server to update 408 relevant records. Normal hosts are not suitable to do this 409 mainly because of the complexity of key management issues 410 inherited from secure DNS mechanisms. 412 6.2. In-host Server Address Update 414 While DNS records addresses of hosts in servers, hosts also record 415 addresses of servers such as DNS server, radius server, etc. While 416 renumbering, the hosts must update the records if the server 417 addresses changed. Addresses of DHCPv6 servers do not need to be 418 updated. They are dynamically discovered using DHCPv6 relevant 419 multicast addresses. 421 o The DNS server addresses for hosts are configured by DHCPv6. But 422 current DHCPv6 messages do not indicate to hosts the lifetimes of 423 DNS. If the DNS lifetime expired and has been renumbered, the 424 hosts may still use the old addresses. DHCPv6 should be extended 425 to indicate to hosts the associated DNS lifetimes when making DNS 426 configuration. How the DHCP server could know about the DNS 427 lifetime is another issue. 429 6.3. Filters 431 o Filters Management 433 Filters based on addresses or prefixes are usually spread in 434 various devices. As [RFC5887] described, some address 435 configuration data might be widely dispersed and much harder to 436 find, even will inevitably be found only after the renumbering 437 event. So there's a big gap for filter management. 439 In [LEROY], a server is used for managing filter update in 440 various devices. But identifying where and which of the filters 441 need to be updated during renumbering is still a gap. 443 o Filter Update Automation Operation 445 As mentioned in section 3.2, [LEROY] proposed a mechanism which 446 can automatically update the filters. The mechanism utilizes 447 macros suitable for various devices such as routers, firewalls 448 etc. to update the filter entries based on the new prefix. Such 449 automation tool is valuable for renumbering because it can 450 reduce manual operation which is error-prone and inefficiency. 452 Besides the macros, [LEROY] also proposed to use SOAP to deliver 453 the macros to the devices. As well as SOAP we may consider 454 whether it is possible and suitable to use other standardized 455 protocols such as NETCONF. 457 Update of filters based on prefixes and filters based on 458 addresses may have different requirements and methods. Address- 459 based filters may be mainly with regard to domain names while 460 prefix-based filters be relevant to more abstract entity (mask 461 e.g.). Thus, we may consider different ways to update the two 462 kinds of filters, for example, the prefix-based filters may 463 consider to be updated though DHCPv6 server, which may provide 464 better efficient. 466 7. Renumbering Event Management 468 From the perspective of network management, renumbering is a kind of 469 event which may need additional process to make the process more easy 470 and manageable. 472 7.1. Renumbering Notification 474 If hosts or servers are aware of a renumbering event happening, it 475 may help the relevant process. Following are several examples of such 476 additional process may ease the renumbering. Further contributions 477 are expected. 479 o A notification mechanism may be needed to indicate the hosts that 480 a renumbering event of local recursive DNS happen or is going to 481 take place. 483 o [RFC4192] suggests that "reducing the delay in the transition to 484 new IPv6 addresses applies when the DNS service can be given prior 485 notice about a renumbering event." Reducing delay could improve 486 the efficiency of renumbering. 488 7.2. Synchronization Management 490 o DNS update synchronization 492 DNS update synchronization focuses on the coordinating between 493 DNS and other entities/mechanisms, for example, as described in 494 [RFC5887], synchronizing the SLAAC and DNS updates, and of 495 reducing the SLAAC lease time and DNS TTL. 497 7.3. Renumbering Monitoring 499 While treating renumbering a network event, mechanisms to monitor the 500 renumbering process may be needed. Considering the address 501 configuration operation may be stateless (if ND is used for 502 renumbering), it is difficult for monitoring. But for the DNS and 503 filter update, it is quite possible to monitor the whole process. 505 8. Miscellaneous 507 [TBD] 509 9. Gap Summary 511 9.1. Managing Prefixes 513 [TBD] 515 9.2. Address configuration 517 o Host address configuration 519 - SLAAC and DHCPv6 address configuration co-existence 521 -Dynamic upstream learning: 522 DHCP-configured host may want to learn about the upstream 523 availability of new prefixes or loss of prior prefixes 524 dynamically by deducing from periodic RA messages. 526 -DHCP-managed hosts receiving RA messages: 527 It is unclear that whether a DHCP-managed host would accept 528 configuration though RA messages, it depends on the policies 529 in the host's operating system. 531 -SLAAC-configured hosts find DHCPv6 is in use: 532 RA messages contain a "Managed Configuration" flag to indicate 533 DHCPv6 is in use. But it is unspecified what behavior should 534 be taken when the host receives RA messages with "M" set to 1. 535 The gap of standard will cause ambiguous host behavior. 537 - DHCPv6 reconfigure bulk usage 539 If we want to use it for bulk renumbering, stateless DHCPv6 540 reconfiguration with multicast may be needed. However, this 541 may involve protocol modification. 543 o Router address configuration 545 - Learning new prefixes 546 If the site is multihoming, the interior routers would need a 547 mechanism to learn which upstream providers and prefixes were 548 currently reachable (and valid). 550 - Restart after renumbering 552 Some routers cache IP addresses in some situations. So routers 553 might need to be restarted as a result of site renumbering. 555 - Router naming 557 Using domain names for routers is suitable in some scenarios 558 but has not been widely deployed. The motivation of using 559 router naming for easing renumbering in enterprise networks 560 may be not enough. 562 o Static address configuration 564 Please refer to [I-D.carpenter-6renum-static-problem]. 566 9.3. Address relevant entries update 568 o DNS records update 570 - DNS update automation 572 Synchronization between host renumbering and the updating of 573 its DNS records is hard. Forward and reverse DNS entries 574 update may need to be combined together. 576 o In-host server address update 578 Hosts also record addresses of servers such as DNS server 579 addresses, radius server address, etc. While renumbering, the 580 host must update the records if these server addresses changed. 582 o Filters 584 - Filters management 586 There is a gap of filter management to identify where and 587 which of the filters need to be updated during renumbering. 588 Manageable filter update may be also needed. 590 - Filter update automation operation 591 Automation update tool is valuable for renumbering, and there 592 may be requirement of protocol standardization to deliver of 593 facility the tools. 595 9.4. Renumbering event management 597 o Renumbering notification 599 If hosts/servers are aware of a renumbering event happening, it may 600 help the relevant process. A basic way is to extend current protocol 601 messages to carry the renumbering notification. 603 o Synchronization management 605 - DNS update synchronization 607 An example is synchronizing the SLAAC and DNS updates, and of 608 reducing the SLAAC lease time and DNS TTL. [TBD] 610 o Renumbering monitoring 612 Mechanisms to monitor the process and feedback of renumbering may be 613 needed. [TBD] 615 10. Security Considerations 617 o Prefix Validation 619 Prefixes from the ISP may need authentication to prevent prefix 620 fraud. Announcing changes of site prefix to other sites (for example, 621 those that configure routers or VPNs to point to the site in 622 question) also need validation. 624 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND 625 ([RFC3971], Secure Neighbor Discovery) deployment may need to 626 validate prefixes. 628 o Influence to Security Controls 630 During renumbering, security controls (e.g. ACLs) blocking access to 631 legitimate resources should not be interrupted. 633 11. IANA Considerations 635 None. 637 12. References 639 12.1. Normative References 641 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 642 August 2000. 644 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 645 IPv6 Address Aggregation and Renumbering", RFC 2874, July 646 2000. 648 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 649 Update", RFC 3007, November 2000. 651 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 652 M. Carney, "Dynamic Host Configuration Protocol for IPv6 653 (DHCPv6)", RFC 3315, July 2003. 655 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 656 Host Configuration Protocol (DHCP) version 6", RFC 3633, 657 December 2003. 659 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 660 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 661 November 2004. 663 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 664 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 666 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 667 "Neighbor Discovery for IP version 6 (IPv6)", RFC 668 4861,September 2007. 670 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 671 Address Autoconfiguration", RFC 4862, September 2007. 673 12.2. Informative References 675 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 676 1997. 678 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 679 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 680 September 2005. 682 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 683 December 2006. 685 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 686 Still Needs Work", RFC 5887, May 2010. 688 [I-D.ietf-dhc-secure-dhcpv6] 689 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 690 in progress. 692 [I-D.chown-v6ops-renumber-thinkabout] 693 Chown, T., "Things to think about when Renumbering an IPv6 694 network", Work in Progress, September 2006. 696 [I-D.jiang-6renum-enterprise] 697 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 698 Scenarios and Guidelines ", Working in 699 Progress, July 2011. 701 [I-D.carpenter-6renum-static-problem] 702 Carpenter, B., and S. Jiang, "Problem Statement for 703 Renumbering IPv6 Hosts with Static Addresses", Working in 704 Progress, October 2011. 706 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 707 configurations for IPv6 renumbering", International of 708 Network Management, 2009, 711 13. Acknowledgments 713 This work adopts significant amounts of content from [RFC5887] and 714 [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, 715 Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, 716 and Stig Venaas. Some useful materials were provided by Oliver 717 Bonaventure and his student Damien Leroy, thanks for them, too. 719 Useful comments and contributions were made by Wesley George, and 720 others. 722 This document was prepared using 2-Word-v2.0.template.dot. 724 Appendix A. Other Documented Gaps 726 This appendix lists gaps have been documented but are considered not 727 in the scope of this gap analysis. 729 A.1 Address Configuration 731 o RA prefix lifetime limitation 733 In section 5.5.3 of [RFC4862], it is defined that ''If the 734 received Valid Lifetime is greater than 2 hours or greater than 735 RemainingLifetime, set the valid lifetime of the corresponding 736 address to the advertised Valid Lifetime.'' So when renumbering, 737 if the previous RemainingLifetime is longer than two hours, it 738 is impossible to reduce a prefix's lifetime less than two hours. 739 This limitation is to prevent denial-of-service attack. 740 [Open Question]This limitation requires renumbering to be 741 planned in advance so that an immediate renumbering event is 742 impossible. Should it be considered as a standard gap for 743 renumbering? 745 A.2 Address Relevant Entries Update 747 o DNS entries commonly have matching Reverse DNS entries which will 748 also need to be updated during renumbering. 750 o [Open Question]So synchronizing the procedures of forward and 751 reverse DNS or even combining forward and reverse DNS updates in a 752 single procedure also need to be considered. 754 o DNS data structure optimization 756 [RFC2874] proposed a new A6 record type for DNS recording IPv6 757 address/prefix. And several extensions on query and processing 758 were also proposed. With the A6 record and the extensions, an 759 IPv6 address can be defined by using multiple DNS records. This 760 feature increases the complexity of resolver but reduce the cost 761 of zone file maintenance. So renumbering could be easier than 762 AAAA record. But the [RFC2874] has not been widely used. 764 [Open Question]Is the DNS data structure optimization such as 765 [RFC2874] necessary for easing renumbering? If necessary, is the 766 optimization in [RFC2874] enough? 768 o DNS authority 769 As described in [I-D.chown-v6ops-renumber-thinkabout], ''it is 770 often the case in enterprises that host web servers and 771 application servers on behalf of collaborators and customers 772 that DNS zones out of the administrative control of the host 773 maintain resource records concerning addresses for nodes out of 774 their control. When the service host renumbers, they do not have 775 sufficient authority to change the records.'' 777 [Open Question]Whether it is only an operational issue or 778 additional protocol/mechanism is needed to standardize the 779 interaction between DNS systems needs to be considered. 781 A.3 Miscellaneous 783 A.3.1 Multicast 785 o The embedding of IPv6 unicast addresses into multicast addresses 786 and the embedded-RP (Rendezvous Point)[RFC3956] will cause issues 787 when renumbering. 789 As [I-D.chown-v6ops-renumber-thinkabout] described, ''If the RP 790 address changes, then the group addresses must also be changed. 791 This may happen not only when a site is renumbered, but also if 792 a site is restructured or the RP is moved within the site. The 793 embedded address is used by routers to determine the RP address. 794 Applications must use new group addresses once the RP is not 795 available on the old address.'' 797 o Changing the unicast source address of a multicast sender might 798 also be an issue for receivers. 800 As [I-D.chown-v6ops-renumber-thinkabout] described, ''If a site's 801 unicast prefix changes, then one will also need to change the 802 multicast addresses. By way of example, a site renumbering away 803 from prefix 2001:DB8:BEEF::/48" might have globally-scoped 804 multicast addresses in use under the prefix 805 "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old 806 addresses for a while, but this should be avoided since another 807 site may inherit the prefix and they may end up using the same 808 multicast addresses.'' 810 A.3.2 Mobility 812 o [RFC5887] suggested that, for Mobile IP, define a better mechanism 813 to handle change of home agent address while mobile is 814 disconnected. 816 A.3.3 Non-network issues 818 o For transport layer, [5887] said that TCP connections and UDP 819 flows are rigidly bound to a given pair of IP addresses. 821 o For application layer, as [5887] said, in general, we can assert 822 that any implementation is at risk from renumbering if it does not 823 check that an address is valid each time it opens a new 824 communications session. 826 Authors' Addresses 828 Bing Liu 829 Q14-4-A Building 830 Huawei Technologies Co., Ltd 831 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 832 Hai-Dian District, Beijing 833 P.R. China 835 Email: leo.liubing@huawei.com 837 Sheng Jiang 838 Q14-4-A Building 839 Huawei Technologies Co., Ltd 840 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 841 Hai-Dian District, Beijing 842 P.R. China 844 Email: shengjiang@huawei.com 846 Brian Carpenter 847 Department of Computer Science 848 University of Auckland 849 PB 92019 850 Auckland, 1142 851 New Zealand 853 EMail: brian.e.carpenter@gmail.com