idnits 2.17.1 draft-ietf-6renum-gap-analysis-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 03, 2012) is 4252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- No information found for draft-liu-6renum-dhcpv6-slaac-switching - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft S. Jiang 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: March 04, 2013 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 September 03, 2012 10 IPv6 Site Renumbering Gap Analysis 11 draft-ietf-6renum-gap-analysis-03.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 March 04, 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 47 This document briefly introduces the existing mechanisms could be 48 utilized by IPv6 site renumbering and tries to cover most of the 49 explicit issues and requirements of IPv6 renumbering. Through the gap 50 analysis, the document provides a basis for future works that 51 identify and develop solutions or to stimulate such development as 52 appropriate. The gap analysis is presented following a renumbering 53 event procedure clue. 55 Table of Contents 57 1. Introduction ................................................. 4 58 2. Overall Requirements for Renumbering ......................... 4 59 3. Existing Components for IPv6 Renumbering ..................... 5 60 3.1. Relevant Protocols and Mechanisms ....................... 5 61 3.2. Management Tools ........................................ 6 62 3.3. Procedures/Policies ..................................... 6 63 4. Managing Prefixes ............................................ 7 64 4.1. Prefix Delegation ....................................... 7 65 4.2. Prefix Assignment ....................................... 7 66 5. Address Configuration ........................................ 7 67 5.1. Host Address Configuration .............................. 7 68 5.2. Router Address Configuration ............................ 9 69 5.3. Static Address Configuration ........................... 10 70 6. Updating Address-relevant Entries ........................... 10 71 6.1. DNS Records Update ..................................... 10 72 6.2. In-host Server Address Update .......................... 11 73 6.3. Filters ................................................ 11 74 7. Renumbering Event Management ................................ 12 75 7.1. Renumbering Notification ............................... 12 76 7.2. Synchronization Management ............................. 13 77 7.3. Renumbering Monitoring ................................. 13 78 8. Miscellaneous ............................................... 13 79 8.1. Multicast .............................................. 13 80 8.2. Mobility ............................................... 15 81 9. Gaps considered unsolvable .................................. 15 82 9.1. Address Configuration .................................. 15 83 9.2. Address-relevant Entries Update ........................ 15 84 9.3. Miscellaneous .......................................... 16 85 10. Security Considerations .................................... 16 86 11. IANA Considerations......................................... 17 87 12. Acknowledgments ............................................ 17 88 13. References ................................................. 17 89 13.1. Normative References .................................. 17 90 13.2. Informative References ................................ 18 92 1. Introduction 94 As introduced in [RFC5887], renumbering, especially for medium to 95 large sites and networks, is currently viewed as an expensive, 96 painful, and error-prone process, avoided by network managers as much 97 as possible. If IPv6 site renumbering continues to be considered 98 difficult, network managers will turn to Provider Independent (PI) 99 addressing for IPv6 to attempt to minimize the need for future 100 renumbering. However, widespread use of PI may create very serious 101 BGP4 scaling problems. It is thus desirable to develop tools and 102 practices that may make renumbering a simpler process to reduce 103 demand for IPv6 PI space. 105 This document performs a gap analysis to provide a basis for future 106 work to identify and develop solutions or to stimulate such 107 development as appropriate. The gap analysis is organized by the main 108 steps of a renumbering process, which include prefix management, node 109 address (re)configuration, and updating address-relevant entries in 110 various devices such as firewalls, routers and servers, etc. Besides 111 these steps, the aspect of renumbering event management is also 112 presented independently, which intends to identify some 113 operational/administrative gaps in renumbering. 115 This document starts from existing work in [RFC5887], 116 [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]. This document 117 does further analysis and identifies the valuable and solvable 118 issues, digs out of some undiscovered gaps, and gives some solution 119 suggestions. 121 2. Overall Requirements for Renumbering 123 This section introduces the overall ultimate goals we want to achieve 124 in a renumbering event. In general, we need to leverage renumbering 125 automation to avoid human intervention as much as possible at 126 reasonable cost. Some existing mechanisms have already provided 127 useful ability. Further efforts may be achieved in the future. 129 The automation can be divided into four aspects as follows. 131 o Prefix delegation and delivery should be automatic and accurate in 132 aggregation and coordination. 134 o Address reconfiguration should be automatically achieved through 135 standard protocols with minimum human intervention. 137 o Address-relevant entry updates should be performed integrally and 138 without error. 140 o Renumbering event management is needed to provide the functions of 141 renumbering notification, synchronization, and monitoring .etc. 143 Besides automation, session survivability is another important issue 144 during renumbering since application outage is one of the most 145 obvious impacts that make renumbering painful and expensive. Session 146 survivability is a fundamental issue that cannot solved within 147 renumbering context only, however, we have an enormous advantage in 148 IPv6 which is the ability to overlap the old and new prefixes and to 149 use the address lifetime mechanisms in SLAAC and DHCPv6. That is 150 fully described in [RFC4192], which provides a smooth transition 151 mechanism from old to new prefixes. In most of the cases, since we 152 can set the transition period long enough to cover the on-going 153 sessions, we consider this mechanism is sufficient for avoiding 154 session brokenness issue in IPv6 site renumbering. 156 3. Existing Components for IPv6 Renumbering 158 Since renumbering is not a new issue, some protocols/mechanisms have 159 been already utilized for renumbering. And there were also some 160 dedicated protocols/mechanisms developed for renumbering. This 161 section briefly reviews these existing protocols/mechanisms to 162 provide a basis for the gap analysis. 164 3.1. Relevant Protocols and Mechanisms 166 o RA messages, defined in [RFC4861], are used to deprecate/announce 167 old/new prefixes and to advertise the availability of an upstream 168 router. In renumbering, it is one of the basic mechanisms for host 169 configuration. 171 o When renumbering a host, SLAAC [RFC4862] may be used for address 172 configuration with the new prefix(es). Hosts receive RA messages 173 which contain routable prefix(es) and the address(es) of the 174 default router(s), then hosts can generate IPv6 address(es) by 175 themselves. 177 o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure 178 addresses by initialing RENEW sessions when the current addresses' 179 lease time are expired or they receive the reconfiguration 180 messages initiated by the DHCPv6 servers. 182 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 183 delegation of IPv6 prefixes using the DHCPv6. 185 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 186 This is a dedicated protocol for renumbering, but has not been 187 widely used. 189 3.2. Management Tools 191 Some operations of renumbering could be automatically processed by 192 management tools in order to make the renumbering process more 193 efficient and accurate. The tools may be designed dedicated for 194 renumbering or just common tools could be utilized for some of the 195 renumbering operations. 197 Following are samples of the tools. 199 o IPAM (IP address management) tools. There are both commercial and 200 open-source solutions. 201 IPAM is basically used for IP address plan, and integrates the 202 DHCPv6 and DNS services together as a whole solution. Many mature 203 commercial tools can even trace the management operations. But 204 normally they don't have dedicated renumbering functions. However, 205 the integrated DNS/DHCPv6 services and management operation trace 206 function can obviously facility renumbering process. 208 o [LEROY] proposed a mechanism of macros to automatically update the 209 address-relevant entries/configurations inside the DNS, firewall, 210 etc. The macros can be delivered though SOAP protocol from a 211 network management server to the managed devices. 213 o Asset management tools/systems. These tools may provide the 214 ability of managing configuration files in nodes so that it is 215 convenient to update the address-relevant configuration in these 216 nodes. 218 3.3. Procedures/Policies 220 o [RFC4192] proposed a procedure for renumbering an IPv6 network 221 without a flag day. The document includes a set of operational 222 suggestions which can be followed step by step by network 223 administrators. 225 o [I-D.ietf-6renum-enterprise] analyzes the enterprise renumbering 226 events and gives the recommendations among the existing 227 renumbering mechanisms. According to the different stages, 228 renumbering considerations are described in three categories: 229 considerations and recommendations during network design, for 230 preparation of enterprise network renumbering, and during 231 renumbering operation 233 4. Managing Prefixes 235 When renumbering an enterprise site, a short prefix may be divided 236 into longer prefixes for subnets. So we need to carefully manage the 237 prefixes for prefix delivery, delegation, aggregation, 238 synchronization, coordination, etc. 240 4.1. Prefix Delegation 242 Usually, the short prefix(es) come down from the operator(s) and 243 received by DHCPv6 servers or routers inside the enterprise networks. 244 The short prefix(es) could be automatically delegated through 245 DHCPv6-PD. Then the downlink DHCPv6 servers or routers can begin 246 advertising the longer prefixes to the subnets. 248 For the delegation routers, they may need to renumber themselves with 249 the delegated prefixes. We need to consider the router renumbering 250 issue which cannot be covered by DHCP-PD only. 252 4.2. Prefix Assignment 254 When subnet routers receive the longer prefixes, they can directly 255 assign them to the hosts. The prefix assignment overlaps with the 256 host address configuration, which is described in the following 257 section 5.1. 259 5. Address Configuration 261 5.1. Host Address Configuration 263 o SLAAC/DHCPv6 co-existence 265 Both of the DHCPv6 and ND protocols have IP address 266 configuration function. They are suitable for different 267 scenarios respectively. During renumbering, the SLAAC-configured 268 hosts can reconfigure IP addresses by receiving ND Router 269 Advertisement (RA) messages containing new prefix information 270 (It should be noted that, the prefix delivery could be achieved 271 through DHCPv6 according to the new IETF DHC WG document 272 [I.D ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can 273 reconfigure addresses by initiating RENEW sessions when the 274 current addresses' lease time are expired or receiving the 275 reconfiguration messages initiated by the DHCPv6 servers. 277 Sometimes the two address configuration modes may be both 278 available in one network. This would add more or less additional 279 complexity for both the hosts and the network management. In ND 280 protocol, there is an M (ManagedFlag) flag defined in RA 281 message, which indicates the hosts the DHCPv6 service status in 282 the network. And there is another O "OtherConfigFlag" flag 283 indicates the host to configure information such as DNS/routing 284 other than addresses. 286 So with using the flags, the two separated address configuration 287 modes are somehow correlated. But for some reasons, the ND 288 protocol didn't define the flags as prescriptive but only 289 advisory. This varies the behavior of hosts when interpreting 290 the M flag. Different operating systems had followed different 291 manners [I-D.liu-6renum-dhcpv6-slaac-switching]. 293 The impact of ambiguous M/O flags mainly includes the following 294 aspects: 296 - SLAAC/DHCPv6 preference 298 Ideally, it should be able to choose either SLAAC or DHCPv6 as 299 the default address configuration mechanism when a host gets 300 online. But it is not always available in reality. On some 301 current operating systems, DHCPv6 procedure won't start until 302 they receive RA messages with M=1. This has an implication 303 that RA messages are required for DHCPv6 management. This may 304 cause operational issues since it needs additional complexity 305 of ND/DHCPv6 co-existence unified management in a network. 307 - DHCPv6-configured hosts receiving RA messages 309 It is unclear that whether a DHCPv6 configured host would 310 accept configuration though RA messages, it depends on the 311 policies in the host's operating system. If it ignores the RA 312 messages and there are no DHCPv6 reconfiguration messages 313 received either, the renumbering would fail. 315 [RFC5887] mentioned that, DHCPv6-configured hosts may want to 316 learn about the upstream availability of new prefixes or loss 317 of prior prefixes dynamically by deducing from periodic RA 318 messages. But there is no standard specifying what approach 319 should be taken by a DHCPv6-configured host when it receives 320 RA messages containing new prefix. It depends on the operation 321 system of the host and cannot be predicted or controlled by 322 the network. 324 - SLAAC-configured hosts finding DHCPv6 in use 325 It is unspecified what behavior should be taken when the host 326 receives RA messages with "M" set. 328 The host may start a DHCPv6 session and receives the DHCPv6 329 address configuration, or it just ignores the messages. If the 330 network side wants the hosts to start DHCPv6 configuration, it 331 is just out of control of the network side. 333 o DHCPv6 reconfigure bulk usage 335 [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear 336 to be widely used for bulk renumbering purposes". 338 The reconfiguration defined in [RFC3315] needs to establish a 339 session between DHCPv6 server and client. This could be 340 considered as a stateful approach which needs much resource on 341 the server to maintain the renumbering sessions. This is 342 probably one of the reasons that DHCPv6 reconfiguration is not 343 suitable for bulk usage. 345 Another limitation of DHCPv6 reconfiguration is that it only 346 allows the messages to be delivered to unicast addresses. So if 347 we want to use it for bulk renumbering, stateless DHCPv6 348 reconfiguration with multicast may be needed. However, this may 349 involve protocol modification. 351 5.2. Router Address Configuration 353 o Learning new prefixes 355 As described in [RFC5887], "if a site wanted to be multihomed 356 using multiple provider-aggregated (PA) routing prefixes with 357 one prefix per upstream provider, then the interior routers 358 would need a mechanism to learn which upstream providers and 359 prefixes were currently reachable (and valid). In this case, 360 their Router Advertisement messages could be updated dynamically 361 to only advertise currently valid routing prefixes to hosts. 362 This would be significantly more complicated if the various 363 provider prefixes were of different lengths or if the site had 364 non-uniform subnet prefix lengths." 366 o Restart after renumbering 368 As [RFC2072] mentioned, some routers cache IP addresses in some 369 situations, so routers might need to be restarted as a result of 370 site renumbering. 372 o Router naming 374 In [RFC4192], it is suggested that "To better support 375 renumbering, switches and routers should use domain names for 376 configuration wherever appropriate, and they should resolve 377 those names using the DNS when the lifetime on the name 378 expires." 379 As [RFC5887] described, this capability is not new, and at least 380 it is present in most IPSec VPN implementations. But many 381 administrators do not realize that it could be utilized to avoid 382 manual modification during renumbering. 384 In enterprise scenario, the requirement of router naming is not 385 as strong as that in ISP. So for the administrators, the 386 motivation of using router naming for easing renumbering may be 387 not strong. 389 5.3. Static Address Configuration 391 There is another draft dedicated to the static address issue. Please 392 refer to [I-D.ietf-6renum-static-problem]. 394 6. Updating Address-relevant Entries 396 When nodes in a site have been renumbered, then all the entries in 397 the site which contain the nodes' addresses must be updated. The 398 entries mainly include DNS records and filters in various entities 399 such as ACLs in firewalls/gateways. 401 6.1. DNS Records Update 403 o Dynamic DNS update 405 For DNS records update, the most popular DNS system BIND will 406 achieve it by maintaining a DNS zone file and loading this file 407 into the site's DNS server(s). Synchronization between host 408 renumbering and the updating of its A6 or AAAA record is hard. 409 [RFC5887] mentioned that an alternative is to use Secure Dynamic 410 DNS Update [RFC3007], in which a host informs its own DNS server 411 when it receives a new address. 413 Secure Dynamic DNS Update has been widely supported by the major 414 DNS systems, but it hasn't been widely deployed, especially in 415 the host. Current practices mainly involve the DHCP servers 416 which act as clients to request the DNS server to update 417 relevant records. Normal hosts are not suitable to do this 418 mainly because of the complexity of key management issues 419 inherited from secure DNS mechanisms. But for some commercial 420 DNS systems, the Secure Dynamic DNS Update issue may be much 421 easier, since it could be integrated with services like DHCP 422 provided by the same vendor so that the dynamic DNS update could 423 be silently enabled. 425 6.2. In-host Server Address Update 427 While DNS records addresses of hosts in servers, hosts also record 428 addresses of servers such as DNS server, radius server, etc. While 429 renumbering, the hosts must update the records if the server 430 addresses changed. Addresses of DHCPv6 servers do not need to be 431 updated. They are dynamically discovered using DHCPv6 relevant 432 multicast addresses. 434 o The DNS server addresses for hosts are configured by DHCPv6. But 435 current DHCPv6 messages do not indicate to hosts the lifetimes of 436 DNS. If the DNS lifetime expired and has been renumbered, the 437 hosts may still use the old addresses. DHCPv6 should be extended 438 to indicate to hosts the associated DNS lifetimes when making DNS 439 configuration. How the DHCP server could know about the DNS 440 lifetime is another issue. 442 6.3. Filters 444 o Filters Management 446 Filters based on addresses or prefixes are usually spread in 447 various devices. As [RFC5887] described, some address 448 configuration data might be widely dispersed and much harder to 449 find, even will inevitably be found only after the renumbering 450 event. So there's a big gap for filter management. 452 In [LEROY], a server is used for managing filter update in 453 various devices. But identifying where and which of the filters 454 need to be updated during renumbering is still a gap. 456 o Filter Update Automation Operation 458 As mentioned in section 3.2, [LEROY] proposed a mechanism which 459 can automatically update the filters. The mechanism utilizes 460 macros suitable for various devices such as routers, firewalls 461 etc. to update the filter entries based on the new prefix. Such 462 automation tool is valuable for renumbering because it can 463 reduce manual operation which is error-prone and inefficiency. 465 Besides the macros, [LEROY] also proposed to use SOAP to deliver 466 the macros to the devices. As well as SOAP we may consider 467 whether it is possible and suitable to use other standardized 468 protocols such as NETCONF. 470 Update of filters based on prefixes and filters based on 471 addresses may have different requirements and methods. Address- 472 based filters may be mainly with regard to domain names while 473 prefix-based filters are relevant to more abstract entity (mask 474 e.g.). Thus, we may consider different ways to update the two 475 kinds of filters, for example, the prefix-based filters may 476 consider being updated though DHCPv6 servers, which may provide 477 better efficient. 479 7. Renumbering Event Management 481 From the perspective of network management, renumbering is a kind of 482 event which may need additional process to make it more easy and 483 manageable. 485 7.1. Renumbering Notification 487 If hosts or servers are aware of a renumbering event happening, it 488 may benefit the relevant process. Following are several examples of 489 such additional process that may ease the renumbering. 491 o A notification mechanism may be needed to indicate the hosts that 492 a renumbering event of local recursive DNS happens or is going to 493 take place. 495 o [RFC4192] suggests that "reducing the delay in the transition to 496 new IPv6 addresses applies when the DNS service can be given prior 497 notice about a renumbering event." Reducing delay could improve 498 the efficiency of renumbering. 500 o Router awareness: in a site with multiple border routers, all 501 border routers should be aware of partial renumbering in order to 502 correctly handle inbound packets. Internal forwarding tables need 503 to be updated. 505 o Border filtering: in a multihomed site, an egress router to ISP A 506 could normally filter packets with source addresses from other 507 ISPs. The egress router connecting to ISP A should be notified if 508 the egress router connecting to ISP B initiates a renumbering 509 event in order to properly update its filter function. 511 7.2. Synchronization Management 513 o DNS update synchronization 515 DNS update synchronization focuses on the coordinating between 516 DNS and other entities/mechanisms, for example, as described in 517 [RFC5887], synchronizing the SLAAC and DNS updates, and of 518 reducing the SLAAC lease time and DNS TTL. 520 7.3. Renumbering Monitoring 522 While treating renumbering as a network event, mechanisms to monitor 523 the renumbering process may be needed. Considering the address 524 configuration operation may be stateless (if ND is used for 525 renumbering), it is difficult for monitoring. But for the DNS and 526 filter update, it is quite possible to monitor the whole process. 528 8. Miscellaneous 530 8.1. Multicast 532 Renumbering also has an impact on multicast. Renumbering of unicast 533 addresses affects multicast even if the multicast addresses are not 534 changed. There may also be cases where the multicast addresses need 535 to be renumbered. 537 o Renumbering of multicast sources 539 If a host that is a multicast source is renumbered, the 540 application on the host may need to be restarted for it to 541 successfully send packets with the new source address. 543 For ASM (Any-Source Multicast) the impact on a receiver is that 544 a new source appears to start sending, and it no longer receives 545 from the previous source. Whether this is an issue depends on 546 the application, but we believe it is likely to not be a major 547 issue. 549 For SSM (Source-Specific Multicast) however, there is one 550 significant problem. The receiver needs to learn which source 551 addresses it must join. Some applications may provide their own 552 method for learning sources, where the source application may 553 somehow signal the receiver. 555 Otherwise, the receiver may e.g. need to get new SDP information 556 with the new source address. This is similar to how to learn a 557 new group address, see the "Renumbering of multicast addresses" 558 topic below. 560 o Renumbering of Rendezvous-Point 562 If the unicast addresses of routers in a network are renumbered, 563 then the RP (Rendezvous-Point) address is also likely to change 564 for at least some groups. An RP address is needed by PIM-SM for 565 providing ASM, and for Bidir PIM. Changing the RP address is not 566 a major issue, except that the multicast service may be impacted 567 while the new RP addresses are configured. If dynamic protocols 568 are used for distributing group-to-RP mappings, the change can 569 be fairly quick, and any impact should be only for a very brief 570 time. However, if routers are statically configured, this 571 depends on how long it takes to update all the configurations. 573 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) 574 when the first packet is received by the last-hop routers. 575 Forwarding on the SPT should not be impacted by change of IP 576 address. Network operator should be careful not deprecate the 577 previous mapping before configuring a new one, because 578 implementations may revert to Dense Mode if no RP is configured. 580 The impact of this is minimal. The main concern is that while 581 the peering is unavailable, one may not receive updates about 582 new sources. 584 It may help to configure a new peering before taking down the 585 existing one. 587 o Renumbering of multicast addresses 589 In general multicast addresses can be chosen independently of 590 the unicast addresses, and the multicast addresses can remain 591 fixed even if the unicast addresses are renumbered. However, for 592 IPv6 there are useful ways of deriving multicast addresses from 593 unicast addresses, such as Unicast-Prefix-based IPv6 Multicast 594 Addresses [RFC3306] and Embedded-RP IPv6 Multicast Addresses 595 [RFC3956]. In that case the multicast addresses used may have to 596 be renumbered. 598 Renumbering group addresses may be complicated. For multicast, 599 it is common to use literal addresses, and not DNS. When 600 multicast addresses are changed, source applications need to be 601 reconfigured and restarted. 603 Multicast receivers need to learn the new group addresses to 604 join. 606 Note that for SSM, receivers need to learn which multicast 607 channels to join. A channel is a source and group pair. This 608 means that for an SSM application, a change of source address is 609 likely to have the same effect as a change of group address. 611 Some applications may have dynamic methods of learning which 612 groups (and possibly sources) to join. If not, the application 613 may have to be reconfigured and restarted. 615 One common way for receivers to learn the necessary parameters 616 are by use of SDP. SDP information may be distributed via 617 various application protocols, or it may be from a file. An SDP 618 file may be distributed via HTTP, email etc. If a user is using 619 a web browser and clicking on a link to launch the application 620 with the necessary data, it may be a matter of closing the 621 current application, and re-clicking the link. 623 8.2. Mobility 625 As [RFC5887] suggested, for Mobile IP, we need a better mechanism to 626 handle change of home agent address while mobile is disconnected. 628 9. Gaps considered unsolvable 630 This section lists gaps have been documented but are considered 631 unsolvable or out of the scope of this document. 633 9.1. Address Configuration 635 o RA prefix lifetime limitation 637 In section 5.5.3 of [RFC4862], it is defined that "If the 638 received Valid Lifetime is greater than 2 hours or greater than 639 RemainingLifetime, set the valid lifetime of the corresponding 640 address to the advertised Valid Lifetime." So when renumbering, 641 if the previous RemainingLifetime is longer than two hours, it 642 is impossible to reduce a prefix's lifetime less than two hours. 643 This limitation is to prevent denial-of-service attack. 645 9.2. Address-relevant Entries Update 647 o DNS entries commonly have matching Reverse DNS entries which will 648 also need to be updated during renumbering. 650 o DNS data structure optimization 652 [RFC2874] proposed a new A6 record type for DNS recording IPv6 653 address/prefix. And several extensions on query and processing 654 were also proposed. With the A6 record and the extensions, an 655 IPv6 address can be defined by using multiple DNS records. This 656 feature increases the complexity of resolver but reduce the cost 657 of zone file maintenance. So renumbering could be easier than 658 AAAA record. But the [RFC2874] has not been widely used, and 659 currently A6 is being discussed to be moved to historic status 660 [RFC6563]. 662 o DNS authority 664 As described in [I-D.chown-v6ops-renumber-thinkabout], "it is 665 often the case in enterprises that host web servers and 666 application servers on behalf of collaborators and customers 667 that DNS zones out of the administrative control of the host 668 maintain resource records concerning addresses for nodes out of 669 their control. When the service host renumbers, they do not have 670 sufficient authority to change the records. " 672 It is an operational and policy issue and this document 673 considers it not suitable to be solved through technical 674 approach or bring additional protocol/mechanism to standardize 675 the interaction between DNS systems for authority negotiations. 677 9.3. Miscellaneous 679 o For transport layer, [RFC5887] said that TCP connections and UDP 680 flows are rigidly bound to a given pair of IP addresses. 682 o For application layer, as [RFC5887] said, in general, we can 683 assert that any implementation is at risk from renumbering if it 684 does not check that an address is valid each time it opens a new 685 communications session. 687 10. Security Considerations 689 o Prefix Validation 691 Prefixes from the ISP may need authentication to prevent prefix 692 fraud. Announcing changes of site prefix to other sites (for example, 693 those that configure routers or VPNs to point to the site in 694 question) also need validation. 696 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SEND 697 ([RFC3971], SEcure Neighbor Discovery) deployment may need to 698 validate prefixes. 700 o Influence to Security Controls 702 During renumbering, security controls (e.g. ACLs) blocking access to 703 legitimate resources should not be interrupted. 705 11. IANA Considerations 707 This draft does not request any IANA action. 709 12. Acknowledgments 711 This work adopts significant amounts of content from [RFC5887] and 712 [I-D.chown-v6ops-renumber-thinkabout], so thank for Randall Atkinson, 713 Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some useful 714 materials were provided by Oliver Bonaventure and his student Damien 715 Leroy. 717 Many useful comments and contributions were made by Lee Howard, 718 Wesley George, and members of 6renum WG. 720 This document was prepared using 2-Word-v2.0.template.dot. 722 13. References 724 13.1. Normative References 726 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 727 August 2000. 729 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 730 IPv6 Address Aggregation and Renumbering", RFC 2874, July 731 2000. 733 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 734 Update", RFC 3007, November 2000. 736 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 737 M. Carney, "Dynamic Host Configuration Protocol for IPv6 738 (DHCPv6)", RFC 3315, July 2003. 740 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 741 Host Configuration Protocol (DHCP) version 6", RFC 3633, 742 December 2003. 744 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 745 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 746 November 2004. 748 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 749 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 751 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 752 "Neighbor Discovery for IP version 6 (IPv6)", RFC 753 4861,September 2007. 755 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 756 Address Autoconfiguration", RFC 4862, September 2007. 758 13.2. Informative References 760 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 761 1997. 763 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 764 Multicast Addresses", RFC 3306, August 2002. 766 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point 767 (RP) Address in an IPv6 Multicast Address", RFC 3965, 768 November 2004. 770 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 771 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 772 September 2005. 774 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 775 Still Needs Work", RFC 5887, May 2010. 777 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 778 Historic Status", RFC 6563, May 2012. 780 [I-D.ietf-dhc-secure-dhcpv6] 781 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 782 in progress, March 2012. 784 [I-D.ietf-6renum-enterprise] 785 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 786 Scenarios and Guidelines ", Working in 787 Progress, July 2011. 789 [I-D.chown-v6ops-renumber-thinkabout] 790 Chown, T., "Things to think about when Renumbering an IPv6 791 network", Work in Progress, September 2006. 793 [I-D.ietf-6renum-static-problem] 794 Carpenter, B., and S. Jiang, "Problem Statement for 795 Renumbering IPv6 Hosts with Static Addresses", Working in 796 Progress, August 2012. 798 [I-D.liu-6renum-dhcpv6-slaac-switching] 799 Liu, B., "DHCPv6/SLAAC Address Configuration Switching for 800 Host Renumbering", Working in Progress, July 2012 802 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 803 configurations for IPv6 renumbering", International of 804 Network Management, 2009, 807 Authors' Addresses 809 Bing Liu 810 Huawei Technologies Co., Ltd 811 Q14, Huawei Campus 812 No.156 Beiqing Rd. 813 Hai-Dian District, Beijing 100095 814 P.R. China 816 Email: leo.liubing@huawei.com 818 Sheng Jiang 819 Huawei Technologies Co., Ltd 820 Q14, Huawei Campus 821 No.156 Beiqing Rd. 822 Hai-Dian District, Beijing 100095 823 P.R. China 825 Email: jiangsheng@huawei.com 827 Brian Carpenter 828 Department of Computer Science 829 University of Auckland 830 PB 92019 831 Auckland, 1142 832 New Zealand 834 EMail: brian.e.carpenter@gmail.com 836 Stig Venaas 837 Cisco Systems 838 Tasman Drive 839 San Jose, CA 95134 840 USA 842 Email: stig@cisco.com