idnits 2.17.1 draft-ietf-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 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 (July 16, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.jiang-6renum-enterprise' is mentioned on line 117, but not defined -- Looks like a reference, but probably isn't: '5887' on line 690 == Unused Reference: 'RFC4714' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-6renum-dhcpv6-slaac-switching' is defined on line 796, 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-carpenter-6renum-static-problem - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 14, 2013 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 July 16, 2012 10 IPv6 Site Renumbering Gap Analysis 11 draft-ietf-6renum-gap-analysis-02.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 January 14, 2013. 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 ................................................. 3 57 2. Overall Requirements for Renumbering ......................... 3 58 3. Existing Components for IPv6 Renumbering ..................... 4 59 3.1. Relevant Protocols and Mechanisms ....................... 4 60 3.2. Management Tools ........................................ 5 61 3.3. Procedures/Policies .................................... 5 62 4. Managing Prefixes ............................................ 6 63 4.1. Prefix Delegation ....................................... 6 64 4.2. Prefix Assignment ....................................... 6 65 5. Address Configuration ........................................ 6 66 5.1. Host Address Configuration .............................. 6 67 5.2. Router Address Configuration ............................ 8 68 5.3. Static Address Configuration ............................ 9 69 6. Updating Relevant Address Entries ............................ 9 70 6.1. DNS Records Update ...................................... 9 71 6.2. In-host Server Address Update .......................... 10 72 6.3. Filters ................................................ 10 73 7. Renumbering Event Management ................................ 11 74 7.1. Renumbering Notification ............................... 11 75 7.2. Synchronization Management ............................. 12 76 7.3. Renumbering Monitoring ................................. 12 77 8. Miscellaneous ............................................... 12 78 8.1. Multicast .............................................. 12 79 8.2. Mobility ............................................... 14 80 9. Gaps considered unsolvable .................................. 14 81 9.1. Address Configuration .................................. 14 82 9.2. Address Relevant Entries Update ........................ 15 83 9.3. Miscellaneous .......................................... 15 84 10. Security Considerations .................................... 16 85 11. IANA Considerations......................................... 16 86 12. References ................................................. 16 87 12.1. Normative References .................................. 16 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 3. Existing Components for IPv6 Renumbering 160 Since renumbering is not a whole new issue, some protocols/mechanisms 161 have been already utilized or even be developed dedicated for 162 renumbering. However, generally current renumbering is achieved by 163 existing protocols rather than dedicated renumbering protocols. This 164 section briefly reviews these existing protocols/mechanisms to 165 provide a basis for the gap analysis. 167 3.1. Relevant Protocols and Mechanisms 169 o RA messages, defined in [RFC4861], are used to deprecate/announce 170 old/new prefixes and to advertise the availability of an upstream 171 router. In renumbering, it is one of basic mechanisms for host 172 configuration. 174 o When a host is renumbered, it may use SLAAC [RFC4862] for address 175 configuration with the new prefix. Hosts receive RA messages which 176 contain routable prefix(es) and the address(es) of the default 177 router(s), then hosts can generate IPv6 address(es) by themselves. 179 o Hosts configured through DHCPv6 [RFC3315] can reconfigure 180 addresses by initialing RENEW sessions when the current addresses' 181 lease time are expired or they receive the reconfiguration 182 messages initiated by the DHCPv6 servers. 184 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 185 delegation of IPv6 prefixes using the DHCPv6. 187 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 188 This is a dedicated protocol for renumbering, but has not been 189 widely used. 191 3.2. Management Tools 193 Some operations of renumbering could be automatically processed by 194 management tools in order to make the renumbering process more 195 efficient and accurate. The tools may be designed dedicated for 196 renumbering or just common tools could be utilized for some 197 operations in renumbering. 199 Following are samples of the tools. 201 o IPAM (IP address management) tools. There are both commercial and 202 open-source solutions. 203 IPAM is basically used for IP address plan Normally, the solutions 204 integrated DHCP and DNS together. Many mature commercial tools can 205 also trace the management operations. But normally they don't have 206 dedicated renumbering functions. However, the integrated DHN/DHCP 207 services and management operation trace function can obviously 208 facility renumbering process. 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.ietf-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 o SLAAC/DHCPv6 co-existence 267 Both of the DHCPv6 and ND protocols have IP address 268 configuration function. They are suitable for different 269 scenarios respectively. During renumbering, the SLAAC-configured 270 hosts can reconfigure IP addresses by receiving ND Router 271 Advertisement (RA) messages containing new prefix information 272 (It should be noted that, the prefix delivery could be achieved 273 through DHCP according to the new IETF DHC WG document [I.D 274 ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can 275 reconfigure addresses by initiating RENEW sessions when the 276 current addresses' lease time are expired or receiving the 277 reconfiguration messages initiated by the DHCPv6 servers.SLAAC 278 and DHCPv6 address configuration co-existence 280 Sometimes the two address configuration modes may be both 281 available in one network. This would add more or less additional 282 complexity for both the hosts and the network management. In ND 283 protocol, there is a M (ManagedFlag) flag defined in RA message, 284 which indicates the hosts the DHCPv6 service status in the 285 network. And there is another O "OtherConfigFlag" flag indicates 286 the host to configure information such as DNS/routing other than 287 addresses. 289 So with using the flags, the two separated address configuration 290 modes are somehow correlated. But for some reason, the ND 291 protocol didn't define the flags as prescriptive but only 292 advisory. This varies the behavior of hosts when interpreting 293 the M flag. Different operating systems had followed different 294 manners. (Editor's note: there's another draft [I-D.liu-6renum- 295 dhcpv6-slaac-switching] dedicated to discuss this issue and some 296 test results of different OS behavior was provided) 298 The impact of ambiguous M/O flagsmainly includes the following 299 aspects: 301 - SLAAC/DHCPv6 preference 303 When a host gets online, it will SLAAC or DHCPv6 as the 304 default. But for some operating systems, they won't start 305 DHCPv6 session until they receive RA messages with M=1. This 306 has a implication that RA messages are required for DHCPv6 307 management. This may cause operational issues since it needs 308 additional complexity of ND/DHCPv6 co-existence unified 309 management in a network. 311 - DHCPv6-configured hosts receiving RA messages 313 It is unclear that whether a DHCPv6 configured host would 314 accept configuration though RA messages, it depends on the 315 policies in the host's operating system. If it ignores the RA 316 messages and there are no DHCPv6 reconfiguration messages 317 received either, the renumbering would fail. 319 [RFC5887] mentioned that, DHCPv6-configured hosts may want to 320 learn about the upstream availability of new prefixes or loss 321 of prior prefixes dynamically by deducing from periodic RA 322 messages. But there is no standard specifying what approach 323 should be taken by a DHCPv6-configured host when it receives 324 RA messages containing new prefix. It depends on the operation 325 system of the host and cannot be predicted or controlled by 326 the network. 328 - SLAAC-configured hosts finding DHCPv6 in use 330 It is unspecified what behavior should be taken when the host 331 receives RA messages with "M" set. 333 The host may start a DHCPv6 session and receives the DHCPv6 334 address configuration, or it just ignores the messages. If the 335 network side wants the hosts to start DHCPv6 configuration, it 336 is just out of control of the network side. 338 o DHCPv6 reconfigure bulk usage 340 [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear 341 to be widely used for bulk renumbering purposes". 343 The reconfiguration defined in [RFC3315] needs to establish a 344 session between DHCP server and client. This could be considered 345 as a stateful approach which needs much resource on the server 346 to maintain the renumbering sessions. This is probably one of 347 the reasons that DHCP reconfiguration is not suitable for bulk 348 usage. 350 Another limitation of reconfiguration is that it only allows th 351 e messages to be delivered to unicast addresses. So if we want 352 to use it for bulk renumbering, stateless DHCPv6 reconfiguration 353 with multicast may be needed. However, this may involve protocol 354 modification. 356 5.2. Router Address Configuration 358 o Learning new prefixes 360 As described in [RFC5887], "if a site wanted to be multihomed 361 using multiple provider-aggregated (PA) routing prefixes with 362 one prefix per upstream provider, then the interior routers 363 would need a mechanism to learn which upstream providers and 364 prefixes were currently reachable (and valid). In this case, 365 their Router Advertisement messages could be updated dynamically 366 to only advertise currently valid routing prefixes to hosts. 368 This would be significantly more complicated if the various 369 provider prefixes were of different lengths or if the site had 370 non-uniform subnet prefix lengths." 372 o Restart after renumbering 374 "Some routers cache IP addresses in some situations. So routers 375 might need to be restarted as a result of site renumbering" 376 [RFC2072]. 378 o Router naming 380 In [RFC4192], it is suggested that "To better support 381 renumbering, switches and routers should use domain names for 382 configuration wherever appropriate, and they should resolve 383 those names using the DNS when the lifetime on the name 384 expires." 385 As [RFC5887] described, this capability is not new, and at least 386 it is present in most IPsec VPN implementations. But many 387 administrators do not realize that it could be utilized to avoid 388 manual modification during renumbering. 390 In enterprise scenario, the requirement of router naming is not 391 as strong as that in ISP. So for the administrators, the 392 motivation of using router naming for easing renumbering may be 393 not strong. 395 5.3. Static Address Configuration 397 There is another draft dedicated to the static address issue. Please 398 refer to [I-D.carpenter-6renum-static-problem]. 400 6. Updating Relevant Address Entries 402 When nodes in a site have been renumbered, then all the entries in 403 the site which contain the nodes' addresses must be updated. The 404 entries mainly include DNS records and filters in various entities 405 such as ACLs in firewalls/gateways. 407 6.1. DNS Records Update 409 o Dynamic DNS update 411 For DNS records update, the most popular DNS system BIND will 412 achieve it by maintaining a DNS zone file and loading this file 413 into the site's DNS server(s). Synchronization between host 414 renumbering and the updating of its A6 or AAAA record is hard. 416 [RFC5887] mentioned that an alternative is to use Secure Dynamic 417 DNS Update [RFC3007], in which a host informs its own DNS server 418 when it receives a new address. 420 Secure Dynamic DNS Update has been widely supported by the major 421 DNS systems, but it hasn't been widely deployed, especially in 422 the host. Current practices mainly involve the DHCP servers 423 which act as clients to request the DNS server to update 424 relevant records. Normal hosts are not suitable to do this 425 mainly because of the complexity of key management issues 426 inherited from secure DNS mechanisms. But for some commercial 427 DNS systems, the Secure Dynamic DNS Update issue may be much 428 easier, since it could be integrated with services like DHCP 429 provided by the same vendor so that the dynamic DNS update could 430 be silently enabled. 432 6.2. In-host Server Address Update 434 While DNS records addresses of hosts in servers, hosts also record 435 addresses of servers such as DNS server, radius server, etc. While 436 renumbering, the hosts must update the records if the server 437 addresses changed. Addresses of DHCPv6 servers do not need to be 438 updated. They are dynamically discovered using DHCPv6 relevant 439 multicast addresses. 441 o The DNS server addresses for hosts are configured by DHCPv6. But 442 current DHCPv6 messages do not indicate to hosts the lifetimes of 443 DNS. If the DNS lifetime expired and has been renumbered, the 444 hosts may still use the old addresses. DHCPv6 should be extended 445 to indicate to hosts the associated DNS lifetimes when making DNS 446 configuration. How the DHCP server could know about the DNS 447 lifetime is another issue. 449 6.3. Filters 451 o Filters Management 453 Filters based on addresses or prefixes are usually spread in 454 various devices. As [RFC5887] described, some address 455 configuration data might be widely dispersed and much harder to 456 find, even will inevitably be found only after the renumbering 457 event. So there's a big gap for filter management. 459 In [LEROY], a server is used for managing filter update in 460 various devices. But identifying where and which of the filters 461 need to be updated during renumbering is still a gap. 463 o Filter Update Automation Operation 465 As mentioned in section 3.2, [LEROY] proposed a mechanism which 466 can automatically update the filters. The mechanism utilizes 467 macros suitable for various devices such as routers, firewalls 468 etc. to update the filter entries based on the new prefix. Such 469 automation tool is valuable for renumbering because it can 470 reduce manual operation which is error-prone and inefficiency. 472 Besides the macros, [LEROY] also proposed to use SOAP to deliver 473 the macros to the devices. As well as SOAP we may consider 474 whether it is possible and suitable to use other standardized 475 protocols such as NETCONF. 477 Update of filters based on prefixes and filters based on 478 addresses may have different requirements and methods. Address- 479 based filters may be mainly with regard to domain names while 480 prefix-based filters be relevant to more abstract entity (mask 481 e.g.). Thus, we may consider different ways to update the two 482 kinds of filters, for example, the prefix-based filters may 483 consider to be updated though DHCPv6 server, which may provide 484 better efficient. 486 7. Renumbering Event Management 488 From the perspective of network management, renumbering is a kind of 489 event which may need additional process to make the process more easy 490 and manageable. 492 7.1. Renumbering Notification 494 If hosts or servers are aware of a renumbering event happening, it 495 may help the relevant process. Following are several examples of such 496 additional process may ease the renumbering. Further contributions 497 are expected. 499 o A notification mechanism may be needed to indicate the hosts that 500 a renumbering event of local recursive DNS happen or is going to 501 take place. 503 o [RFC4192] suggests that "reducing the delay in the transition to 504 new IPv6 addresses applies when the DNS service can be given prior 505 notice about a renumbering event." Reducing delay could improve 506 the efficiency of renumbering. 508 o Router awareness: in a site with multiple border routers, all 509 border routers should be aware of partial renumbering in order to 510 correctly handle inbound packets. Internal forwarding tables need 511 to be updated. 513 o Border filtering: in a multihomed site, an egress router to ISP A 514 could normally filter packets with source addresses from other 515 ISPs. The egress router connecting to ISP A should be notified if 516 the egress router connecting to ISP B initiates a renumbering 517 event in order to properly update its filter function. 519 7.2. Synchronization Management 521 o DNS update synchronization 523 DNS update synchronization focuses on the coordinating between 524 DNS and other entities/mechanisms, for example, as described in 525 [RFC5887], synchronizing the SLAAC and DNS updates, and of 526 reducing the SLAAC lease time and DNS TTL. 528 7.3. Renumbering Monitoring 530 While treating renumbering a network event, mechanisms to monitor the 531 renumbering process may be needed. Considering the address 532 configuration operation may be stateless (if ND is used for 533 renumbering), it is difficult for monitoring. But for the DNS and 534 filter update, it is quite possible to monitor the whole process. 536 8. Miscellaneous 538 8.1. Multicast 540 Renumbering also has an impact on multicast. Renumbering of unicast 541 addresses affects multicast even if the multicast addresses are not 542 changed. There may also be cases where the multicast addresses need 543 to be renumbered. 545 o Renumbering of multicast sources 547 If a host that is a multicast source is renumbered, the 548 application on the host may need to be restarted for it to 549 successfully send packets with the new source address. 551 For ASM (Any-Source Multicast) the impact on a receiver is that 552 a new source appears to start sending, and it no longer receives 553 from the previous source. Whether this is an issue depends on 554 the application, but we believe it is likely to not be a major 555 issue. 557 For SSM (Source-Specific Multicast) however, there is one 558 significant problem. The receiver needs to learn which source 559 addresses it must join. Some applications may provide their own 560 method for learning sources, where the source application may 561 somehow signal the receiver. 563 Otherwise, the receiver may e.g. need to get new SDP information 564 with the new source address. This is similar to how to learn a 565 new group address, see the "Renumbering of multicast addresses" 566 topic below. 568 o Renumbering of Rendezvous-Point 570 If the unicast addresses of routers in a network are renumbered, 571 then the RP (Rendezvous-Point) address is also likely to change 572 for at least some groups. An RP address is needed by PIM-SM for 573 providing ASM, and for Bidir PIM. Changing the RP address is not 574 a major issue, except that the multicast service may be impacted 575 while the new RP addresses are configured. If dynamic protocols 576 are used for distributing group-to-RP mappings, the change can 577 be fairly quick, and any impact should be only for a very brief 578 time. However, if routers are statically configured, this 579 depends on how long it takes to update all the configurations. 581 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) 582 when the first packet is received by the last-hop routers. 583 Forwarding on the SPT should not be impacted by change of IP 584 address. Although one may have to be careful and not unconfigure 585 the previous mapping before configuring a new one, because 586 implementations may revert to Dense Mode if no RP is configured. 588 The impact of this is minimal. The main concern is that while 589 the peering is unavailable, one may not receive updates about 590 new sources. 592 It may help to configure a new peering before taking down the 593 existing one. 595 o Renumbering of multicast addresses 597 In general multicast addresses can be chosen independently of 598 the unicast addresses, and the multicast addresses can remain 599 fixed even if the unicast addresses are renumbered. However, for 600 IPv6 there are useful ways of deriving multicast addresses from 601 unicast addresses, such as Unicast-Prefix-based IPv6 Multicast 602 Addresses [RFC3306] and Embedded-RP IPv6 Multicast Addresses 603 [RFC3956]. In that case the multicast addresses used may have to 604 be renumbered. 606 Renumbering group addresses may be complicated. For multicast, 607 it is common to use literal addresses, and not DNS. When 608 multicast addresses are changed, source applications need to be 609 reconfigured and restarted. 611 Multicast receivers need to learn the new group addresses to 612 join. 614 Note that for SSM, receivers need to learn which multicast 615 channels to join. A channel is a source and group pair. This 616 means that for an SSM application, a change of source address is 617 likely to have the same effect as a change of group address. 619 Some applications may have dynamic methods of learning which 620 groups (and possibly sources) to join. If not, the application 621 may have to be reconfigured and restarted. 623 One common way for receivers to learn the necessary parameters 624 are by use of SDP. SDP information may be distributed via 625 various application protocols, or it may be from a file. An SDP 626 file may be distributed via HTTP, email etc. If a user is using 627 a web browser and clicking on a link to launch the application 628 with the necessary data, it may be a matter of closing the 629 current application, and re-clicking the link. 631 8.2. Mobility 633 As [RFC5887] suggested, for Mobile IP, we need a better mechanism to 634 handle change of home agent address while mobile is disconnected. 636 9. Gaps considered unsolvable 638 This section lists gaps have been documented but are considered 639 unsolvable or out of the scope of 6renum working group. 641 9.1. Address Configuration 643 o RA prefix lifetime limitation 645 In section 5.5.3 of [RFC4862], it is defined that "If the 646 received Valid Lifetime is greater than 2 hours or greater than 647 RemainingLifetime, set the valid lifetime of the corresponding 648 address to the advertised Valid Lifetime." So when renumbering, 649 if the previous RemainingLifetime is longer than two hours, it 650 is impossible to reduce a prefix's lifetime less than two hours. 651 This limitation is to prevent denial-of-service attack. 653 9.2. Address Relevant Entries Update 655 o DNS entries commonly have matching Reverse DNS entries which will 656 also need to be updated during renumbering. 658 o DNS data structure optimization 660 [RFC2874] proposed a new A6 record type for DNS recording IPv6 661 address/prefix. And several extensions on query and processing 662 were also proposed. With the A6 record and the extensions, an 663 IPv6 address can be defined by using multiple DNS records. This 664 feature increases the complexity of resolver but reduce the cost 665 of zone file maintenance. So renumbering could be easier than 666 AAAA record. But the [RFC2874] has not been widely used, and 667 currently A6 is being discussed to be moved to historic status 668 [RFC6563]. 670 o DNS authority 672 As described in [I-D.chown-v6ops-renumber-thinkabout], "it is 673 often the case in enterprises that host web servers and 674 application servers on behalf of collaborators and customers 675 that DNS zones out of the administrative control of the host 676 maintain resource records concerning addresses for nodes out of 677 their control. When the service host renumbers, they do not have 678 sufficient authority to change the records." 680 It is an operational issue and this document considers it not 681 suitable to be solved through bring additional 682 protocol/mechanism to standardize the interaction between DNS 683 systems needs to be considered. 685 9.3. Miscellaneous 687 o For transport layer, [5887] said that TCP connections and UDP 688 flows are rigidly bound to a given pair of IP addresses. 690 o For application layer, as [5887] said, in general, we can assert 691 that any implementation is at risk from renumbering if it does not 692 check that an address is valid each time it opens a new 693 communications session. 695 10. Security Considerations 697 o Prefix Validation 699 Prefixes from the ISP may need authentication to prevent prefix 700 fraud. Announcing changes of site prefix to other sites (for example, 701 those that configure routers or VPNs to point to the site in 702 question) also need validation. 704 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND 705 ([RFC3971], Secure Neighbor Discovery) deployment may need to 706 validate prefixes. 708 o Influence to Security Controls 710 During renumbering, security controls (e.g. ACLs) blocking access to 711 legitimate resources should not be interrupted. 713 11. IANA Considerations 715 None. 717 12. References 719 12.1. Normative References 721 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 722 August 2000. 724 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 725 IPv6 Address Aggregation and Renumbering", RFC 2874, July 726 2000. 728 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 729 Update", RFC 3007, November 2000. 731 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 732 M. Carney, "Dynamic Host Configuration Protocol for IPv6 733 (DHCPv6)", RFC 3315, July 2003. 735 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 736 Host Configuration Protocol (DHCP) version 6", RFC 3633, 737 December 2003. 739 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 740 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 741 November 2004. 743 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 744 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 746 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 747 "Neighbor Discovery for IP version 6 (IPv6)", RFC 748 4861,September 2007. 750 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 751 Address Autoconfiguration", RFC 4862, September 2007. 753 12.2. Informative References 755 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 756 1997. 758 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 759 Multicast Addresses", RFC 3306, August 2002. 761 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) 762 Address in an IPv6 Multicast Address", RFC 3965, November 763 2004. 765 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 766 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 767 September 2005. 769 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 770 December 2006. 772 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 773 Still Needs Work", RFC 5887, May 2010. 775 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 776 Historic Status", RFC 6563, May 2012. 778 [I-D.ietf-dhc-secure-dhcpv6] 779 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 780 in progress. 782 [I-D.ietf-6renum-enterprise] 783 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 784 Scenarios and Guidelines ", Working in 785 Progress, July 2011. 787 [I-D.chown-v6ops-renumber-thinkabout] 788 Chown, T., "Things to think about when Renumbering an IPv6 789 network", Work in Progress, September 2006. 791 [I-D.carpenter-6renum-static-problem] 792 Carpenter, B., and S. Jiang, "Problem Statement for 793 Renumbering IPv6 Hosts with Static Addresses", Working in 794 Progress, October 2011. 796 [I-D.liu-6renum-dhcpv6-slaac-switching] 797 Liu, B., "DHCPv6/SLAAC Address Configuration Switching for 798 Host Renumbering", Working in Progress, July 2012 800 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 801 configurations for IPv6 renumbering", International of 802 Network Management, 2009, 805 13. Acknowledgments 807 This work adopts significant amounts of content from [RFC5887] and 808 [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, 809 Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, 810 and Stig Venaas. Some useful materials were provided by Oliver 811 Bonaventure and his student Damien Leroy, thanks for them, too. 813 Many useful comments and contributions were made by Lee Howard, 814 Wesley George, etc. 816 This document was prepared using 2-Word-v2.0.template.dot. 818 Authors' Addresses 820 Bing Liu 821 Q14-4-A Building 822 Huawei Technologies Co., Ltd 823 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 824 Hai-Dian District, Beijing 825 P.R. China 827 Email: leo.liubing@huawei.com 829 Sheng Jiang 830 Q14-4-A Building 831 Huawei Technologies Co., Ltd