idnits 2.17.1 draft-ietf-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 is 1 instance 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 (March 12, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5887' on line 666 == Unused Reference: 'RFC4714' is defined on line 745, 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? -- No information found for draft-jiang-a6-to-historic - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: September 13, 2012 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 March 12, 2012 10 IPv6 Site Renumbering Gap Analysis 11 draft-ietf-6renum-gap-analysis-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF). Note that other groups may also distribute working 20 documents as Internet-Drafts. The list of current Internet-Drafts is 21 at http://datatracker.ietf.org/drafts/current/. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 This Internet-Draft will expire on September 13, 2012. 30 Copyright Notice 32 Copyright (c) 2012 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Abstract 46 This document briefly introduces the existing mechanisms could be 47 utilized by IPv6 site renumbering and envisions the effort could be 48 done. This document tries to cover the most explicit issues and 49 requirements of IPv6 renumbering. Through the gap analysis, the 50 document provides a basis for future work to identify and develop 51 solutions or to stimulate such development as appropriate. The gap 52 analysis is presented following a renumbering event procedure clue. 54 Table of Contents 56 1. Introduction ................................................. 4 57 2. Overall Requirements for Renumbering ......................... 4 58 3. Existing Components for IPv6 Renumbering ..................... 5 59 3.1. Relevant Protocols and Mechanisms ....................... 5 60 3.2. Management Tools ........................................ 6 61 3.3. Procedures/Policies ..................................... 6 62 4. Managing Prefixes ............................................ 7 63 4.1. Prefix Delegation ....................................... 7 64 4.2. Prefix Assignment ....................................... 7 65 5. Address Configuration ........................................ 7 66 5.1. Host Address Configuration .............................. 7 67 5.2. Router Address Configuration ............................ 9 68 5.3. Static Address Configuration ........................... 10 69 6. Updating Relevant Address Entries ........................... 10 70 6.1. DNS Records Update ..................................... 10 71 6.2. In-host Server Address Update .......................... 11 72 6.3. Filters ................................................ 11 73 7. Renumbering Event Management ................................ 12 74 7.1. Renumbering Notification ............................... 12 75 7.2. Synchronization Management ............................. 12 76 7.3. Renumbering Monitoring ................................. 12 77 8. Miscellaneous ............................................... 13 78 8.1. Multicast .............................................. 13 79 8.2. Mobility ............................................... 15 80 9. Gaps considered unsolvable .................................. 15 81 9.1. Address Configuration .................................. 15 82 9.2. Address Relevant Entries Update ........................ 15 83 9.3. Miscellaneous .......................................... 16 84 10. Security Considerations .................................... 16 85 11. IANA Considerations......................................... 17 86 12. References ................................................. 17 87 12.1. Normative References .................................. 17 88 12.2. Informative References ................................ 17 89 13. Acknowledgments ............................................ 18 91 1. Introduction 93 As introduced in [RFC5887], renumbering, especially for medium to 94 large sites and networks, is currently viewed as an expensive, 95 painful, and error-prone process, avoided by network managers as much 96 as possible. If IPv6 site renumbering continues to be considered 97 difficult, network managers will turn to Provider Independent (PI) 98 addressing for IPv6 to attempt to minimize the need for future 99 renumbering. However, widespread use of PI may create very serious 100 BGP4 scaling problems. It is thus desirable to develop tools and 101 practices that may make renumbering a simpler process to reduce 102 demand for IPv6 PI space. 104 This document performs a gap analysis to provide a basis for future 105 work to identify and develop solutions or to stimulate such 106 development as appropriate. The gap analysis is organized by the main 107 steps of renumbering process, which include prefix management, node 108 address (re)configuration, and updating relevant address entries in 109 various gateways, routers and servers, etc. Besides these steps, the 110 aspect of renumbering event management is presented independently, 111 which intends to help the operational/administrative process. It is 112 expected that these steps and management could cover all the aspects 113 of an renumbering event. 115 This document draws on existing work in (at least) [RFC5887], [I- 116 D.chown-v6ops-renumber-thinkabout] and [RFC4192]. Contributions from 117 [I-D.jiang-6renum-enterprise] are incorporated into the more detailed 118 analysis. Lots of issues were analyzed in RFC5887 & [I-D.chown-v6ops- 119 renumber-thinkabout], but many of them are out of 6renum scope or 120 unsolvable. This document intends to identify the valuable and 121 solvable issues, dig out of some undiscovered gaps, and tries to give 122 solution suggestions. 124 2. Overall Requirements for Renumbering 126 This section introduces the overall ultimate goals we want to achieve 127 in a renumbering event. In general, we need to leverage renumbering 128 automation to avoid human intervention as much as possible at 129 reasonable cost. Some existing mechanisms have already provided 130 useful help. Further efforts may be achieved in the future. 132 The automation can be divided into four aspects as follows, which are 133 also the gap analysis topics. 135 o Prefix delegation and delivery should be automatic and accurate in 136 aggregation and coordination. 138 o Address reconfiguration should be automatically achieved through 139 standard protocols with minimum human intervention. 141 o Updating relevant address entries should be performed integrally 142 and without error. [Open Question]Is it necessary to develop 143 automatic entries update mechanisms? If necessary, do we need 144 standard protocols/interface for it? 146 o Renumbering event management is needed to provide the functions of 147 renumbering notification, synchronization, and monitoring .etc. 149 Besides automation, session survivability is another important issue 150 during renumbering since application outage is one of the most 151 obvious impacts that make renumbering painful and expensive. We have 152 an enormous advantage in IPv6 which is the ability to overlap the old 153 and new prefixes and to use the address lifetime mechanisms in SLAAC 154 and DHCPv6. That is fully described in [RFC4192]. We consider this 155 mechanism is sufficient for session survivability issue in most of 156 the cases. 158 [Open Question]Should we consider the case of very long-lived 159 application sessions (days or weeks) which cannot be resolved by 160 [RFC4192]? 162 3. Existing Components for IPv6 Renumbering 164 Since renumbering is not a whole new issue, some protocols/mechanisms 165 have been already utilized or even be developed dedicated for 166 renumbering. However, generally current renumbering is achieved by 167 existing protocols rather than dedicated renumbering protocols. This 168 section briefly reviews these existing protocols/mechanisms to 169 provide a basis for the gap analysis. 171 3.1. Relevant Protocols and Mechanisms 173 o RA messages, defined in [RFC4861], are used to deprecate/announce 174 old/new prefixes and to advertise the availability of an upstream 175 router. In renumbering, it is one of basic mechanisms for host 176 configuration. 178 o When a host is renumbered, it may use SLAAC [RFC4862] for address 179 configuration with the new prefix. Hosts receive RA messages which 180 contain routable prefix(es) and the address(es) of the default 181 router(s), then hosts can generate IPv6 address(es) by themselves. 183 o Hosts configured through DHCPv6 [RFC3315] can reconfigure 184 addresses by initialing RENEW sessions when the current addresses' 185 lease time are expired or they receive the reconfiguration 186 messages initiated by the DHCPv6 servers. 188 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 189 delegation of IPv6 prefixes using the DHCPv6. 191 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 192 This is a dedicated protocol for renumbering, but has not been 193 widely used. 195 3.2. Management Tools 197 Some operations of renumbering could be automatically processed by 198 management tools in order to make the renumbering process more 199 efficient and accurate. The tools may be designed dedicated for 200 renumbering or just common tools could be utilized for some 201 operations in renumbering. 203 Following are samples of the tools. 205 o Address management tools. There are both commercial and open- 206 source, and even home-made solutions. 207 [Further work is needed to identify what an address management 208 tool should be able to do for improving the ability of managing a 209 network through a renumbering event.] 211 o [LEROY] proposed a mechanism of macros to automatically update the 212 address relevant entries/configurations inside the DNS, firewall, 213 etc. The macros can be delivered though SOAP protocol from a 214 network management server to the managed devices. 216 o Asset management tools/systems. These tools may provide the 217 ability of managing configuration files in nodes so that it is 218 convenient to update the address relevant configuration in these 219 nodes. 221 3.3. Procedures/Policies 223 o [RFC4192] proposed a procedure for renumbering an IPv6 network 224 without a flag day. The document includes a set of operational 225 suggestions which can be followed step by step by network 226 administrators. 228 o [I-D.jiang-6renum-enterprise] analyzes the enterprise renumbering 229 events and gives the recommendations among the existing 230 renumbering mechanisms. According to the different stages, 231 renumbering considerations are described in three categories: 232 considerations and recommendations during network design, for 233 preparation of enterprise network renumbering, and during 234 renumbering operation 236 4. Managing Prefixes 238 When renumbering an enterprise site, a short prefix may be divided 239 into longer prefixes for subnets. So we need to carefully manage the 240 prefixes for prefix delivery, delegation, aggregation, 241 synchronization, coordination, etc. 243 4.1. Prefix Delegation 245 Usually, the short prefix comes down from the operator and received 246 by DHCPv6 server or router inside the enterprise network. The short 247 prefix could be automatically delegated through DHCPv6-PD. Then the 248 downlink DHCP servers or routers can begin advertising the longer 249 prefixes to the subnets. 251 For the delegation routers, they may need to renumber themselves with 252 the delegated prefixes. We need to consider the router renumbering 253 issue which cannot be covered by DHCP-PD only. 255 4.2. Prefix Assignment 257 When subnet routers receive the longer prefixes, they can directly 258 assign them to the hosts. The prefix assignment overlaps with the 259 host address configuration, which is described in the following 260 section 5.1. 262 5. Address Configuration 264 5.1. Host Address Configuration 266 Both of the DHCPv6 and ND protocols have IP address configuration 267 function. They are suitable for different scenarios respectively. 268 During renumbering, the SLAAC-configured hosts can reconfigure IP 269 addresses by receiving ND Router Advertisement (RA) messages 270 containing new prefix information (It should be noted that, the 271 prefix delivery could be achieved through DHCP according to the new 272 IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6- 273 configured hosts can reconfigure addresses by initiating RENEW 274 sessions when the current addresses' lease time are expired or 275 receiving the reconfiguration messages initiated by the DHCPv6 276 servers. 278 o SLAAC and DHCPv6 address configuration co-existence 280 While an IPv6 site is being renumbered, both DHCPv6 and ND may 281 be used to reconfigure the host addresses. The co-existence 282 issue mainly includes following aspects: 284 - Dynamic upstream learning 286 [RFC5887] mentioned that, DHCP-configured hosts may want to 287 learn about the upstream availability of new prefixes or loss 288 of prior prefixes dynamically by deducing from periodic RA 289 messages. But there is no standard specifying what approach 290 should be taken by a DHCPv6-configured host when it receives 291 RA messages containing new prefix. It depends on the operation 292 system of the host and cannot be predicted or controlled by 293 the network. 295 - DHCP-managed hosts receiving RA messages 297 It is unclear that whether a DHCP-managed host would accept 298 configuration though RA messages, it depends on the policies 299 in the host's operating system. If it ignores the RA messages 300 and there are no DHCPv6 reconfiguration messages received 301 either, the renumbering would fail. 303 - SLAAC-configured hosts finding DHCPv6 in use 305 [RFC5887] mentioned RA message of ND protocol contains a 306 "Managed Configuration" flag to indicate DHCPv6 is in use. But 307 it is unspecified what behavior should be taken when the host 308 receives RA messages with "M" set to 1. The gap of standard 309 will cause ambiguous host behavior because it depends on the 310 operation system of the host. 312 The host may start a DHCPv6 session and receives the DHCPv6 313 address configuration. It is also possible that the host finds 314 the DHCPv6 assigned prefix is different from the prefix in the 315 RA messages, which means multiple uplinks are available or 316 there is a serious network configuration error. 318 Another possibility is that the host may receive no response 319 from any DHCPv6 servers, which means the DHCPv6 service is not 320 available and the "Managed Configuration" flag was mis- 321 configured. 323 o DHCPv6 reconfigure bulk usage 325 [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear 326 to be widely used for bulk renumbering purposes". 328 The reconfiguration defined in [RFC3315] needs to establish a 329 session between DHCP server and client. This could be considered 330 as a stateful approach which needs much resource on the server 331 to maintain the renumbering sessions. This is probably one of 332 the reasons that DHCP reconfiguration is not suitable for bulk 333 usage. 335 Another limitation of reconfiguration is that it only allows th 336 e messages to be delivered to unicast addresses. So if we want 337 to use it for bulk renumbering, stateless DHCPv6 reconfiguration 338 with multicast may be needed. However, this may involve protocol 339 modification. 341 5.2. Router Address Configuration 343 o Learning new prefixes 345 As described in [RFC5887], "if a site wanted to be multihomed 346 using multiple provider-aggregated (PA) routing prefixes with 347 one prefix per upstream provider, then the interior routers 348 would need a mechanism to learn which upstream providers and 349 prefixes were currently reachable (and valid). In this case, 350 their Router Advertisement messages could be updated dynamically 351 to only advertise currently valid routing prefixes to hosts. 352 This would be significantly more complicated if the various 353 provider prefixes were of different lengths or if the site had 354 non-uniform subnet prefix lengths." 356 o Restart after renumbering 358 "Some routers cache IP addresses in some situations. So routers 359 might need to be restarted as a result of site renumbering" 360 [RFC2072]. 362 o Router naming 364 In [RFC4192], it is suggested that "To better support 365 renumbering, switches and routers should use domain names for 366 configuration wherever appropriate, and they should resolve 367 those names using the DNS when the lifetime on the name 368 expires." 369 As [RFC5887] described, this capability is not new, and at least 370 it is present in most IPsec VPN implementations. But many 371 administrators do not realize that it could be utilized to avoid 372 manual modification during renumbering. 374 In enterprise scenario, the requirement of router naming is not 375 as strong as that in ISP. So for the administrators, the 376 motivation of using router naming for easing renumbering may be 377 not strong. 379 5.3. Static Address Configuration 381 There is another draft dedicated to the static address issue. Please 382 refer to [I-D.carpenter-6renum-static-problem]. 384 6. Updating Relevant Address Entries 386 When nodes in a site have been renumbered, then all the entries in 387 the site which contain the nodes' addresses must be updated. The 388 entries mainly include DNS records and filters in various entities 389 such as ACLs in firewalls/gateways. 391 6.1. DNS Records Update 393 o Dynamic DNS update 395 For DNS records update, the most popular DNS system BIND will 396 achieve it by maintaining a DNS zone file and loading this file 397 into the site's DNS server(s). Synchronization between host 398 renumbering and the updating of its A6 or AAAA record is hard. 399 [RFC5887] mentioned that an alternative is to use Secure Dynamic 400 DNS Update [RFC3007], in which a host informs its own DNS server 401 when it receives a new address. 403 Secure Dynamic DNS Update has been widely supported by the major 404 DNS systems, but it hasn't been widely deployed, especially in 405 the host. Current practices mainly involve the DHCP servers 406 which act as clients to request the DNS server to update 407 relevant records. Normal hosts are not suitable to do this 408 mainly because of the complexity of key management issues 409 inherited from secure DNS mechanisms. But for some commercial 410 DNS systems, the Secure Dynamic DNS Update issue may be much 411 easier, since it could be integrated with services like DHCP 412 provided by the same vendor so that the dynamic DNS update could 413 be silently enabled. 415 6.2. In-host Server Address Update 417 While DNS records addresses of hosts in servers, hosts also record 418 addresses of servers such as DNS server, radius server, etc. While 419 renumbering, the hosts must update the records if the server 420 addresses changed. Addresses of DHCPv6 servers do not need to be 421 updated. They are dynamically discovered using DHCPv6 relevant 422 multicast addresses. 424 o The DNS server addresses for hosts are configured by DHCPv6. But 425 current DHCPv6 messages do not indicate to hosts the lifetimes of 426 DNS. If the DNS lifetime expired and has been renumbered, the 427 hosts may still use the old addresses. DHCPv6 should be extended 428 to indicate to hosts the associated DNS lifetimes when making DNS 429 configuration. How the DHCP server could know about the DNS 430 lifetime is another issue. 432 6.3. Filters 434 o Filters Management 436 Filters based on addresses or prefixes are usually spread in 437 various devices. As [RFC5887] described, some address 438 configuration data might be widely dispersed and much harder to 439 find, even will inevitably be found only after the renumbering 440 event. So there's a big gap for filter management. 442 In [LEROY], a server is used for managing filter update in 443 various devices. But identifying where and which of the filters 444 need to be updated during renumbering is still a gap. 446 o Filter Update Automation Operation 448 As mentioned in section 3.2, [LEROY] proposed a mechanism which 449 can automatically update the filters. The mechanism utilizes 450 macros suitable for various devices such as routers, firewalls 451 etc. to update the filter entries based on the new prefix. Such 452 automation tool is valuable for renumbering because it can 453 reduce manual operation which is error-prone and inefficiency. 455 Besides the macros, [LEROY] also proposed to use SOAP to deliver 456 the macros to the devices. As well as SOAP we may consider 457 whether it is possible and suitable to use other standardized 458 protocols such as NETCONF. 460 Update of filters based on prefixes and filters based on 461 addresses may have different requirements and methods. Address- 462 based filters may be mainly with regard to domain names while 463 prefix-based filters be relevant to more abstract entity (mask 464 e.g.). Thus, we may consider different ways to update the two 465 kinds of filters, for example, the prefix-based filters may 466 consider to be updated though DHCPv6 server, which may provide 467 better efficient. 469 7. Renumbering Event Management 471 From the perspective of network management, renumbering is a kind of 472 event which may need additional process to make the process more easy 473 and manageable. 475 7.1. Renumbering Notification 477 If hosts or servers are aware of a renumbering event happening, it 478 may help the relevant process. Following are several examples of such 479 additional process may ease the renumbering. Further contributions 480 are expected. 482 o A notification mechanism may be needed to indicate the hosts that 483 a renumbering event of local recursive DNS happen or is going to 484 take place. 486 o [RFC4192] suggests that "reducing the delay in the transition to 487 new IPv6 addresses applies when the DNS service can be given prior 488 notice about a renumbering event." Reducing delay could improve 489 the efficiency of renumbering. 491 7.2. Synchronization Management 493 o DNS update synchronization 495 DNS update synchronization focuses on the coordinating between 496 DNS and other entities/mechanisms, for example, as described in 497 [RFC5887], synchronizing the SLAAC and DNS updates, and of 498 reducing the SLAAC lease time and DNS TTL. 500 7.3. Renumbering Monitoring 502 While treating renumbering a network event, mechanisms to monitor the 503 renumbering process may be needed. Considering the address 504 configuration operation may be stateless (if ND is used for 505 renumbering), it is difficult for monitoring. But for the DNS and 506 filter update, it is quite possible to monitor the whole process. 508 8. Miscellaneous 510 8.1. Multicast 512 Renumbering also has an impact on multicast. Renumbering of unicast 513 addresses affects multicast even if the multicast addresses are not 514 changed. There may also be cases where the multicast addresses need 515 to be renumbered. 517 o Renumbering of multicast sources 519 If a host that is a multicast source is renumbered, the 520 application on the host may need to be restarted for it to 521 successfully send packets with the new source address. 523 For ASM (Any-Source Multicast) the impact on a receiver is that 524 a new source appears to start sending, and it no longer receives 525 from the previous source. Whether this is an issue depends on 526 the application, but we believe it is likely to not be a major 527 issue. 529 For SSM (Source-Specific Multicast) however, there is one 530 significant problem. The receiver needs to learn which source 531 addresses it must join. Some applications may provide their own 532 method for learning sources, where the source application may 533 somehow signal the receiver. 535 Otherwise, the receiver may e.g. need to get new SDP information 536 with the new source address. This is similar to how to learn a 537 new group address, see the "Renumbering of multicast addresses" 538 topic below. 540 o Renumbering of Rendezvous-Point and MSDP peers 542 If the unicast addresses of routers in a network are renumbered, 543 then the RP (Rendezvous-Point) address is also likely to change 544 for at least some groups. An RP address is needed by PIM-SM for 545 providing ASM, and for Bidir PIM. Changing the RP address is not 546 a major issue, except that the multicast service may be impacted 547 while the new RP addresses are configured. If dynamic protocols 548 are used for distributing group-to-RP mappings, the change can 549 be fairly quick, and any impact should be only for a very brief 550 time. However, if routers are statically configured, this 551 depends on how long it takes to update all the configurations. 553 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) 554 when the first packet is received by the last-hop routers. 555 Forwarding on the SPT should not be impacted by change of IP 556 address. Although one may have to be careful and not unconfigure 557 the previous mapping before configuring a new one, because 558 implementations may revert to Dense Mode if no RP is configured. 560 Renumbering of addresses used for MSDP peerings will require 561 peerings to be reconfigured, and be unavailable at least for a 562 brief time. 564 The impact of this is minimal. The main concern is that while 565 the peering is unavailable, one may not receive updates about 566 new sources. 568 It may help to configure a new peering before taking down the 569 existing one. 571 o Renumbering of multicast addresses 573 In general multicast addresses can be chosen independently of 574 the unicast addresses, and the multicast addresses can remain 575 fixed even if the unicast addresses are renumbered. However, for 576 IPv6 there are useful ways of deriving multicast addresses from 577 unicast addresses, such as Unicast-Prefix-based IPv6 Multicast 578 Addresses [RFC3306] and Embedded-RP IPv6 Multicast Addresses 579 [RFC3956]. In that case the multicast addresses used may have to 580 be renumbered. 582 Renumbering group addresses may be complicated. For multicast, 583 it is common to use literal addresses, and not DNS. When 584 multicast addresses are changed, source applications need to be 585 reconfigured and restarted. 587 Multicast receivers need to learn the new group addresses to 588 join. 590 Note that for SSM, receivers need to learn which multicast 591 channels to join. A channel is a source and group pair. This 592 means that for an SSM application, a change of source address is 593 likely to have the same effect as a change of group address. 595 Some applications may have dynamic methods of learning which 596 groups (and possibly sources) to join. If not, the application 597 may have to be reconfigured and restarted. 599 One common way for receivers to learn the necessary parameters 600 are by use of SDP. SDP information may be distributed via 601 various application protocols, or it may be from a file. An SDP 602 file may be distributed via HTTP, email etc. If a user is using 603 a web browser and clicking on a link to launch the application 604 with the necessary data, it may be a matter of closing the 605 current application, and re-clicking the link. 607 8.2. Mobility 609 As [RFC5887] suggested, for Mobile IP, we need a better mechanism to 610 handle change of home agent address while mobile is disconnected. 612 9. Gaps considered unsolvable 614 This section lists gaps have been documented but are considered 615 unsolvable or out of the scope of 6renum working group. 617 9.1. Address Configuration 619 o RA prefix lifetime limitation 621 In section 5.5.3 of [RFC4862], it is defined that "If the 622 received Valid Lifetime is greater than 2 hours or greater than 623 RemainingLifetime, set the valid lifetime of the corresponding 624 address to the advertised Valid Lifetime." So when renumbering, 625 if the previous RemainingLifetime is longer than two hours, it 626 is impossible to reduce a prefix's lifetime less than two hours. 627 This limitation is to prevent denial-of-service attack. 629 9.2. Address Relevant Entries Update 631 o DNS entries commonly have matching Reverse DNS entries which will 632 also need to be updated during renumbering. 634 o DNS data structure optimization 636 [RFC2874] proposed a new A6 record type for DNS recording IPv6 637 address/prefix. And several extensions on query and processing 638 were also proposed. With the A6 record and the extensions, an 639 IPv6 address can be defined by using multiple DNS records. This 640 feature increases the complexity of resolver but reduce the cost 641 of zone file maintenance. So renumbering could be easier than 642 AAAA record. But the [RFC2874] has not been widely used, and 643 currently A6 is being discussed to be moved to historic status 644 [I-D.jiang-a6-to-historic]. 646 o DNS authority 648 As described in [I-D.chown-v6ops-renumber-thinkabout], "it is 649 often the case in enterprises that host web servers and 650 application servers on behalf of collaborators and customers 651 that DNS zones out of the administrative control of the host 652 maintain resource records concerning addresses for nodes out of 653 their control. When the service host renumbers, they do not have 654 sufficient authority to change the records." 656 It is an operational issue and this document considers it not 657 suitable to be solved through bring additional 658 protocol/mechanism to standardize the interaction between DNS 659 systems needs to be considered. 661 9.3. Miscellaneous 663 o For transport layer, [5887] said that TCP connections and UDP 664 flows are rigidly bound to a given pair of IP addresses. 666 o For application layer, as [5887] said, in general, we can assert 667 that any implementation is at risk from renumbering if it does not 668 check that an address is valid each time it opens a new 669 communications session. 671 10. Security Considerations 673 o Prefix Validation 675 Prefixes from the ISP may need authentication to prevent prefix 676 fraud. Announcing changes of site prefix to other sites (for example, 677 those that configure routers or VPNs to point to the site in 678 question) also need validation. 680 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND 681 ([RFC3971], Secure Neighbor Discovery) deployment may need to 682 validate prefixes. 684 o Influence to Security Controls 686 During renumbering, security controls (e.g. ACLs) blocking access to 687 legitimate resources should not be interrupted. 689 11. IANA Considerations 691 None. 693 12. References 695 12.1. Normative References 697 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 698 August 2000. 700 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 701 IPv6 Address Aggregation and Renumbering", RFC 2874, July 702 2000. 704 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 705 Update", RFC 3007, November 2000. 707 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 708 M. Carney, "Dynamic Host Configuration Protocol for IPv6 709 (DHCPv6)", RFC 3315, July 2003. 711 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 712 Host Configuration Protocol (DHCP) version 6", RFC 3633, 713 December 2003. 715 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 716 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 717 November 2004. 719 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 720 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 722 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 723 "Neighbor Discovery for IP version 6 (IPv6)", RFC 724 4861,September 2007. 726 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 727 Address Autoconfiguration", RFC 4862, September 2007. 729 12.2. Informative References 731 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 732 1997. 734 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 735 Multicast Addresses", RFC 3306, August 2002. 737 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) 738 Address in an IPv6 Multicast Address", RFC 3965, November 739 2004. 741 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 742 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 743 September 2005. 745 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 746 December 2006. 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 B. Liu, "IPv6 Enterprise Network Renumbering 761 Scenarios and Guidelines ", Working in 762 Progress, July 2011. 764 [I-D.carpenter-6renum-static-problem] 765 Carpenter, B., and S. Jiang, "Problem Statement for 766 Renumbering IPv6 Hosts with Static Addresses", Working in 767 Progress, October 2011. 769 [I-D.jiang-a6-to-historic] 770 Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 771 Historic Status", Working in Progress, November 2011. 773 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 774 configurations for IPv6 renumbering", International of 775 Network Management, 2009, 778 13. Acknowledgments 780 This work adopts significant amounts of content from [RFC5887] and 781 [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, 782 Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, 783 and Stig Venaas. Some useful materials were provided by Oliver 784 Bonaventure and his student Damien Leroy, thanks for them, too. 786 Useful comments and contributions were made by Wesley George, and 787 others. 789 This document was prepared using 2-Word-v2.0.template.dot. 791 Authors' Addresses 793 Bing Liu 794 Q14-4-A Building 795 Huawei Technologies Co., Ltd 796 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 797 Hai-Dian District, Beijing 798 P.R. China 800 Email: leo.liubing@huawei.com 802 Sheng Jiang 803 Q14-4-A Building 804 Huawei Technologies Co., Ltd 805 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 806 Hai-Dian District, Beijing 807 P.R. China 809 Email: shengjiang@huawei.com 811 Brian Carpenter 812 Department of Computer Science 813 University of Auckland 814 PB 92019 815 Auckland, 1142 816 New Zealand 818 EMail: brian.e.carpenter@gmail.com 820 Stig Venaas 821 Cisco Systems 822 Tasman Drive 823 San Jose, CA 95134 824 USA 826 Email: stig@cisco.com