idnits 2.17.1 draft-ietf-6renum-gap-analysis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 12, 2012) is 4151 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: 3 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: June 11, 2013 B. Carpenter 5 University of Auckland 6 S. Venaas 7 Cisco Systems 8 W. George 9 Time Warner Cable 10 December 12, 2012 12 IPv6 Site Renumbering Gap Analysis 13 draft-ietf-6renum-gap-analysis-05.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute working 22 documents as Internet-Drafts. The list of current Internet-Drafts is 23 at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 11, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document briefly introduces the existing mechanisms that could 50 be utilized for IPv6 site renumbering and tries to cover most of the 51 explicit issues and requirements of IPv6 renumbering. Through the gap 52 analysis, the document provides a basis for future works that 53 identify and develop solutions or to stimulate such development as 54 appropriate. The gap analysis is presented following a renumbering 55 event procedure summary. 57 Table of Contents 59 1. Introduction ................................................. 4 60 2. Overall Requirements for Renumbering ......................... 4 61 3. Existing Components for IPv6 Renumbering ..................... 5 62 3.1. Relevant Protocols and Mechanisms ....................... 5 63 3.2. Management Tools ........................................ 6 64 3.3. Procedures/Policies ..................................... 6 65 4. Managing Prefixes ............................................ 7 66 4.1. Prefix Delegation ....................................... 7 67 4.2. Prefix Assignment ....................................... 7 68 5. Address Configuration ........................................ 7 69 5.1. Host Address Configuration .............................. 7 70 5.2. Router Address Configuration ............................ 9 71 5.3. Static Address Configuration ........................... 10 72 6. Updating Address-relevant Entries ........................... 10 73 6.1. DNS Records Update ..................................... 10 74 6.2. In-host Server Address Update .......................... 11 75 6.3. Parameterized IP-specific Configuration ................ 11 76 7. Renumbering Event Management ................................ 13 77 7.1. Renumbering Notification ............................... 13 78 7.2. Synchronization Management ............................. 14 79 7.3. Renumbering Monitoring ................................. 14 80 8. Miscellaneous ............................................... 14 81 8.1. Multicast .............................................. 14 82 8.2. Mobility ............................................... 16 83 9. Gaps considered unsolvable .................................. 16 84 9.1. Address Configuration .................................. 16 85 9.2. Address-relevant Entries Update ........................ 16 86 9.3. Static address issues .................................. 17 87 9.4. Miscellaneous .......................................... 18 88 10. Security Considerations .................................... 18 89 11. IANA Considerations........................................ 18 90 12. Acknowledgments ........................................... 18 91 13. References ................................................ 19 92 13.1. Normative References ................................. 19 93 13.2. Informative References ............................... 19 95 1. Introduction 97 As introduced in [RFC5887], renumbering, especially for medium to 98 large sites and networks, is currently viewed as an expensive, 99 painful, and error-prone process, avoided by network managers as much 100 as possible. If IPv6 site renumbering continues to be considered 101 difficult, network managers will turn to Provider Independent (PI) 102 addressing for IPv6 to attempt to minimize the need for future 103 renumbering. However, widespread use of PI may create very serious 104 BGP4 scaling problems. It is thus desirable to develop tools and 105 practices that may make renumbering a simpler process to reduce 106 demand for IPv6 PI space. 108 This document performs a gap analysis to provide a basis for future 109 work to identify and develop solutions or to stimulate such 110 development as appropriate. The gap analysis is organized by the main 111 steps of a renumbering process, which include prefix management, node 112 address (re)configuration, and updating address-relevant entries in 113 various devices such as firewalls, routers and servers, etc. Besides 114 these steps, the aspect of renumbering event management is also 115 presented independently, which intends to identify some 116 operational/administrative gaps in renumbering. 118 This document starts from existing work in [RFC5887], 119 [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]. This document 120 does further analysis and identifies the valuable and solvable issues, 121 digs out of some undiscovered gaps, and gives some solution 122 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 ability. Further efforts may be achieved in the future. 132 The automation can be divided into four aspects as follows. 134 o Prefix delegation and delivery should be automatic and accurate in 135 aggregation and coordination. 137 o Address reconfiguration should be automatically achieved through 138 standard protocols with minimum human intervention. 140 o Address-relevant entry updates should be performed integrally and 141 without error. 143 o Renumbering event management is needed to provide the functions of 144 renumbering notification, synchronization, and monitoring etc. 146 Besides automation, session survivability is another important issue 147 during renumbering since application outage is one of the most 148 obvious impacts that make renumbering painful and expensive. Session 149 survivability is a fundamental issue that cannot solved within 150 renumbering context only; however, we have an enormous advantage in 151 IPv6 which is the ability to overlap the old and new prefixes and to 152 use the address lifetime mechanisms in IPv6 Stateless Address 153 Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for 154 IPv6 (DHCPv6). That is fully described in [RFC4192], which provides a 155 smooth transition mechanism from old to new prefixes. In most of the 156 cases, since we can set the transition period long enough to cover 157 the on-going sessions, we consider this mechanism is sufficient for 158 avoiding session brokenness issue in IPv6 site renumbering. 160 3. Existing Components for IPv6 Renumbering 162 Since renumbering is not a new issue, some protocols and mechanisms 163 have already been utilized for renumbering. There were also some 164 dedicated protocols and mechanisms developed for renumbering. This 165 section briefly reviews these existing protocols and mechanisms to 166 provide a basis for the gap analysis. 168 3.1. Relevant Protocols and Mechanisms 170 o RA messages, defined in [RFC4861], are used to deprecate/announce 171 old/new prefixes and to advertise the availability of an upstream 172 router. In renumbering, it is one of the basic mechanisms for host 173 configuration. 175 o When renumbering a host, SLAAC [RFC4862] may be used for address 176 configuration with the new prefix(es). Hosts receive RA messages 177 which contain routable prefix(es) and the address(es) of the 178 default router(s), then hosts can generate IPv6 address(es) by 179 themselves. 181 o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure 182 addresses by starting RENEW actions when the current addresses' 183 lease time are expired or they receive the reconfiguration 184 messages initiated by the DHCPv6 servers. 186 o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 187 delegation of IPv6 prefixes using the DHCPv6. 189 o [RFC2894] defined standard ICMPv6 messages for router renumbering. 190 This is a dedicated protocol for renumbering, but it has not been 191 widely used. 193 3.2. Management Tools 195 Some operations of renumbering could be automatically processed by 196 management tools in order to make the renumbering process more 197 efficient and accurate. The tools may be designed specifically for 198 renumbering, or common tools could be utilized for some of the 199 renumbering operations. 201 Following are examples of these tools. 203 o IP address management (IPAM) tools. There are both commercial and 204 open-source solutions. An IPAM is basically used to manage an IP 205 address plan, and it integrates the DHCPv6 and DNS services 206 together as a whole solution. Many mature commercial tools can 207 support management operations, but normally they do not have 208 dedicated renumbering functions. However, the integrated 209 DNS/DHCPv6 services and address management function can obviously 210 facilitate the renumbering process. 212 o [LEROY] proposed a mechanism of macros to automatically update the 213 address-relevant entries/configurations inside the DNS, firewall, 214 etc. The macros can be delivered though SOAP protocol from a 215 network management server to the managed devices. 217 o Asset management tools/systems. These tools may provide the 218 ability of managing configuration files in nodes so that it is 219 convenient to update the address-relevant configuration in these 220 nodes. 222 3.3. Procedures/Policies 224 o [RFC4192] proposed a procedure for renumbering an IPv6 network 225 without a flag day. The document includes a set of operational 226 suggestions which can be followed step by step by network 227 administrators. 229 o [I-D.ietf-6renum-enterprise] analyzes the enterprise renumbering 230 events and gives the recommendations among the existing 231 renumbering mechanisms. According to the different stages, 232 renumbering considerations are described in three categories: 233 considerations and recommendations during network design, for 234 preparation of enterprise network renumbering, and during 235 renumbering operation 237 4. Managing Prefixes 239 When renumbering an enterprise site, a short prefix may be divided 240 into longer prefixes for subnets. So we need to carefully manage the 241 prefixes for prefix delivery, delegation, aggregation, 242 synchronization, coordination, etc. 244 4.1. Prefix Delegation 246 Usually, the short prefix(es) come down from the operator(s) and are 247 received by DHCPv6 servers or routers inside the enterprise networks. 248 The short prefix(es) could be automatically delegated through DHCPv6- 249 PD. Then the downlink DHCPv6 servers or routers can begin advertising 250 the longer prefixes to the subnets. 252 For the delegation routers, they may need to renumber themselves with 253 the delegated prefixes. We need to consider the router renumbering 254 issue, which cannot be covered by DHCP-PD only. 256 4.2. Prefix Assignment 258 When subnet routers receive the longer prefixes, they can directly 259 assign them to the hosts. The prefix assignment overlaps with the 260 host address configuration, which is described in the following 261 section 5.1. 263 5. Address Configuration 265 5.1. Host Address Configuration 267 o SLAAC/DHCPv6 co-existence 269 Both of the DHCPv6 and Neighbor Discovery (ND) protocols have an 270 IP address configuration function. They are suitable for 271 different scenarios respectively. During renumbering, the SLAAC- 272 configured hosts can reconfigure IP addresses by receiving ND 273 Router Advertisement (RA) messages containing new prefix 274 information. It should be noted that, the prefix delivery could 275 be achieved through DHCPv6 according to the new IETF DHC WG 276 document [I.D ietf-dhc-host-gen-id]. The DHCPv6-configured hosts 277 can reconfigure addresses by initiating RENEW sessions when the 278 current addresses' lease times are expired or when they receive 279 reconfiguration messages initiated by the DHCPv6 servers. 281 Sometimes the two address configuration modes may both be 282 available in one network. This would add more or less additional 283 complexity for both the hosts and the network management. In ND 284 protocol, there is an M (ManagedFlag) flag defined in RA message, 285 which indicates the hosts the DHCPv6 service status in the 286 network. And there is another O (OtherConfigFlag) flag 287 indicating the host to configure information such as DNS/routing 288 other than addresses. 290 Using these flags, the two separated address configuration modes 291 are somehow correlated. However, the ND protocol did not define 292 the flags as prescriptive but only as advisory. This has led to 293 variation in the behavior of hosts when interpreting the M flag. 294 Different operating systems follow different approaches 295 [I-D.liu-6renum-dhcpv6-slaac-switching]. 297 The impact of ambiguous M/O flags mainly includes the following 298 aspects: 300 - SLAAC/DHCPv6 preference 302 Ideally, it should be possible to choose either SLAAC or 303 DHCPv6 as the default address configuration mechanism when a 304 host goes online, but this is not always available in reality. 305 On some current operating systems, DHCPv6 procedure will not 306 start until they receive RA messages with M=1. This has an 307 implication that RA messages are required for DHCPv6 308 management. This may cause operational issues since it needs 309 additional complexity in ND/DHCPv6 co-existence to achieve 310 unified management in a network. 312 - DHCPv6-configured hosts receiving RA messages 314 It is unclear whether a DHCPv6 configured host will accept 315 configuration though RA messages; this depends on the policies 316 in the host's operating system. If it ignores the RA messages 317 and there are no DHCPv6 reconfiguration messages received 318 either, renumbering would fail. 320 [RFC5887] mentioned that DHCPv6-configured hosts may want to 321 learn about the upstream availability of new prefixes or loss 322 of prior prefixes dynamically by deducing this from periodic 323 RA messages. But there is no standard specifying what approach 324 should be taken by a DHCPv6-configured host when it receives 325 RA messages containing a new prefix. It depends on the 326 operating system of the host and cannot be predicted or 327 controlled by the network. 329 - SLAAC-configured hosts finding DHCPv6 in use 331 It is unspecified what behavior should be taken when the host 332 receives RA messages with "M" set. 334 The host may start a DHCPv6 session and receive the DHCPv6 335 address configuration, or it may just ignore the messages. If 336 the network side wants the hosts to start DHCPv6 configuration, 337 it is just out of control of the network side. 339 o DHCPv6 reconfigure bulk usage 341 [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear 342 to be widely used for bulk renumbering purposes". 344 The reconfiguration defined in [RFC3315] needs to establish a 345 session between DHCPv6 server and client. This could be 346 considered as a stateful approach which needs much resource on 347 the server to maintain the renumbering sessions. This is 348 probably one of the reasons that DHCPv6 reconfiguration is not 349 suitable for bulk usage. 351 Another limitation of DHCPv6 reconfiguration is that it only 352 allows the messages to be delivered to unicast addresses. So if 353 we want to use it for bulk renumbering, stateless DHCPv6 354 reconfiguration with multicast may be needed. However, this may 355 involve protocol modification. 357 5.2. Router Address Configuration 359 o Learning new prefixes 361 As described in [RFC5887], "if a site wanted to be multihomed 362 using multiple provider-aggregated (PA) routing prefixes with 363 one prefix per upstream provider, then the interior routers 364 would need a mechanism to learn which upstream providers and 365 prefixes were currently reachable (and valid). In this case, 366 their Router Advertisement messages could be updated dynamically 367 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 As [RFC2072] mentioned, some routers cache IP addresses in some 375 situations, so routers might need to be restarted as a result of 376 site renumbering. 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." As [RFC5887] described, this capability is not new, 385 and at least it is present in most IPSec VPN implementations. 386 But many administrators do not realize that it could be utilized 387 to avoid manual modification during renumbering. 389 In enterprise scenario, the requirement of router naming is not 390 as strong as that in ISP. So for the administrators, the 391 motivation of using router naming for easing renumbering may be 392 not strong. 394 5.3. Static Address Configuration 396 There is another document dedicated to the static address issue. 397 Please refer to [I-D.ietf-6renum-static-problem]. 399 6. Updating Address-relevant Entries 401 When nodes in a site have been renumbered, then all the entries in 402 the site which contain the nodes' addresses must be updated. The 403 entries mainly include DNS records and filters in various entities 404 such as ACLs in firewalls/gateways. 406 6.1. DNS Records Update 408 o Dynamic DNS update 410 For DNS records update, the most popular DNS system, BIND, will 411 achieve it by maintaining a DNS zone file and loading this file 412 into the site's DNS server(s). Synchronization between host 413 renumbering and the updating of its A6 or AAAA record is hard. 414 [RFC5887] mentioned that an alternative is to use Secure Dynamic 415 DNS Update [RFC3007], in which a host informs its own DNS server 416 when it receives a new address. 418 Secure Dynamic DNS Update has been widely supported by the major 419 DNS systems, but it hasn't been widely deployed, especially in 420 the host. Current practices mainly involve the DHCP servers 421 which act as clients to request the DNS server to update 422 relevant records. Normal hosts are not suitable to do this 423 mainly because of the complexity of key management issues 424 inherited from secure DNS mechanisms. But for some commercial 425 DNS systems, the Secure Dynamic DNS Update issue may be much 426 easier, since it could be integrated with services like DHCP 427 provided by the same vendor so that the dynamic DNS update could 428 be silently enabled. 430 6.2. In-host Server Address Update 432 While DNS records addresses of hosts in servers, hosts also record 433 addresses of servers such as DNS server, radius server, etc. While 434 renumbering, the hosts must update the records if the server 435 addresses changed. Addresses of DHCPv6 servers do not need to be 436 updated. They are dynamically discovered using DHCPv6 relevant 437 multicast addresses. 439 o The DNS server addresses for hosts are configured by DHCPv6. But 440 current DHCPv6 messages do not indicate to hosts the lifetimes of 441 DNS. If the DNS lifetime expired and a host has been renumbered, 442 other hosts may still use the old addresses. DHCPv6 should be 443 extended to indicate to hosts the associated DNS lifetimes when 444 making DNS configuration. How the DHCP server could know about the 445 DNS lifetime is another issue. 447 6.3. Parameterized IP-specific Configuration 449 Besides the DNS records and the in-host server address entries, there 450 are also many places in which the IP addresses are configured, for 451 example, filters such as ACL and routing policies, etc. There are 452 even more sophisticated cases where the IP addresses are used for 453 deriving values, for example, using the unique portion of the 454 loopback address to generate an ISIS net ID. 456 Ideally, a layer of abstraction for IP-specific configuration within 457 various devices (routers, switches, hosts, servers, etc.) is needed. 458 However, this cannot be achieved in one step. One possible 459 improvement is to make the IP-specific configuration parameterized. 460 Two aspects of parameterized configuration could be considered to 461 achieve this. 463 o Self-contained Configuration in Individual device 465 In an ideal way, the IP addresses can be defined as a value once, 466 and then the administrators can use either keywords or variables 467 to call the value in other places such as a sort of internal 468 inheritance in CLI (command line interface) or other local 469 configurations. This makes it easier to manage a renumbering 470 event by reducing the number of places where a device's 471 configuration must be updated. However, it still means that 472 every device needs to be touched, but only once instead of 473 having to inspect the whole configuration to ensure that none of 474 the separate places that a given IP address occurs is missed. 476 Among the real current devices, some routers support defining 477 multiple loopback interfaces which can be called in other 478 configurations. For example, when defining a tunnel, it can call 479 the defined loopback interface to use its address as the local 480 address of the tunnel. This can be considered as a kind of 481 parameterized self-contained configuration. But this only 482 applies certain use cases; it is impossible to use the loopback 483 interfaces to represent external devices and it is not always 484 possible to call loopback interfaces in many other 485 configurations. Parameterized self-contained configuration is 486 still a gap for current devices. 488 o Unified Configuration Management among Devices 490 This is a more formalized central configuration management 491 system, where all changes are made in one place and the system 492 manages how to push the changes to the individual devices. This 493 issue contains two aspects as the following. 495 - Configuration Aggregation 497 Configuration based on addresses or prefixes are usually 498 spread in various devices. As [RFC5887] described, some 499 address configuration data might be widely dispersed and much 500 harder to find, even will inevitably be found only after the 501 renumbering event. So there's a big gap for configuration 502 aggregation. 504 - Configuration Update Automation 506 As mentioned in section 3.2, [LEROY] proposed a mechanism 507 which can automatically update the entries. The mechanism 508 utilizes macros suitable for various devices such as routers, 509 firewalls etc. to update the entries based on the new prefix. 511 Such automation tool is valuable for renumbering because it 512 can reduce manual operation which is error-prone and 513 inefficiency. 515 Besides the macros, [LEROY] also proposed to use SOAP to 516 deliver the macros to the devices. As well as SOAP we may 517 consider whether it is possible and suitable to use other 518 standardized protocols such as NETCONF [RFC4714]. 520 But in current real networks, most of the devices use vendor- 521 private protocols to update configurations, so it is not 522 necessarily valid to assume that there is going to be a 523 formalized configuration management system to leverage. It is 524 a big gap currently. 526 7. Renumbering Event Management 528 From the perspective of network management, renumbering is a kind of 529 event which may need additional process to make it more easy and 530 manageable. 532 7.1. Renumbering Notification 534 If hosts or servers are aware of a renumbering event happening, it 535 may benefit the relevant process. Following are several examples of 536 such additional process that may ease the renumbering. 538 o A notification mechanism may be needed to indicate the hosts that 539 a renumbering event of local recursive DNS happens or is going to 540 take place. 542 o [RFC4192] suggests that "reducing the delay in the transition to 543 new IPv6 addresses applies when the DNS service can be given prior 544 notice about a renumbering event." Reducing delay could improve 545 the efficiency of renumbering. 547 o Router awareness: in a site with multiple border routers, all 548 border routers should be aware of partial renumbering in order to 549 correctly handle inbound packets. Internal forwarding tables need 550 to be updated. 552 o Border filtering: in a multihomed site, an egress router to ISP A 553 could normally filter packets with source addresses from other 554 ISPs. The egress router connecting to ISP A should be notified if 555 the egress router connecting to ISP B initiates a renumbering 556 event in order to properly update its filter function. 558 7.2. Synchronization Management 560 o DNS update synchronization 562 DNS update synchronization focuses on the coordinating between 563 DNS and other entities/mechanisms, for example, as described in 564 [RFC5887], synchronizing the SLAAC and DNS updates, and of 565 reducing the SLAAC lease time and DNS TTL. 567 7.3. Renumbering Monitoring 569 While treating renumbering as a network event, mechanisms to monitor 570 the renumbering process may be needed. Considering the address 571 configuration operation may be stateless (if ND is used for 572 renumbering), it is difficult for monitoring. But for the DNS and 573 filter update, it is quite possible to monitor the whole process. 575 8. Miscellaneous 577 8.1. Multicast 579 Renumbering also has an impact on multicast. Renumbering of unicast 580 addresses affects multicast even if the multicast addresses are not 581 changed. There may also be cases where the multicast addresses need 582 to be renumbered. 584 o Renumbering of multicast sources 586 If a host that is a multicast source is renumbered, the 587 application on the host may need to be restarted for it to 588 successfully send packets with the new source address. 590 For ASM (Any-Source Multicast) the impact on a receiver is that 591 a new source appears to start sending, and it no longer receives 592 from the previous source. Whether this is an issue depends on 593 the application, but we believe it is likely to not be a major 594 issue. 596 For SSM (Source-Specific Multicast) however, there is one 597 significant problem. The receiver needs to learn which source 598 addresses it must join. Some applications may provide their own 599 method for learning sources, where the source application may 600 somehow signal the receiver. 602 Otherwise, the receiver may e.g. need to get new SDP information 603 with the new source address. This is similar to how to learn a 604 new group address, see the "Renumbering of multicast addresses" 605 topic below. 607 o Renumbering of Rendezvous-Point 609 If the unicast addresses of routers in a network are renumbered, 610 then the RP (Rendezvous-Point) address is also likely to change 611 for at least some groups. An RP address is needed by PIM-SM for 612 providing ASM, and for Bidir PIM. Changing the RP address is not 613 a major issue, except that the multicast service may be impacted 614 while the new RP addresses are configured. If dynamic protocols 615 are used for distributing group-to-RP mappings, the change can 616 be fairly quick, and any impact should be only for a very brief 617 time. However, if routers are statically configured, this 618 depends on how long it takes to update all the configurations. 620 For PIM-SM one typically switches to SPT (Shortest-Path-Tree) 621 when the first packet is received by the last-hop routers. 622 Forwarding on the SPT should not be impacted by change of IP 623 address. Network operator should be careful not deprecate the 624 previous mapping before configuring a new one, because 625 implementations may revert to Dense Mode if no RP is configured. 627 The impact of this is minimal. The main concern is that while 628 the peering is unavailable, one may not receive updates about 629 new sources. 631 It may help to configure a new peering before taking down the 632 existing one. 634 o Renumbering of multicast addresses 636 In general multicast addresses can be chosen independently of 637 the unicast addresses, and the multicast addresses can remain 638 fixed even if the unicast addresses are renumbered. However, for 639 IPv6 there are useful ways of deriving multicast addresses from 640 unicast addresses, such as unicast-prefix-based IPv6 Multicast 641 Addresses [RFC3306] and Embedded-RP IPv6 Multicast Addresses 642 [RFC3956]. In that case the multicast addresses used may have to 643 be renumbered. 645 Renumbering group addresses may be complicated. For multicast, 646 it is common to use literal addresses, and not DNS. When 647 multicast addresses are changed, source applications need to be 648 reconfigured and restarted. 650 Multicast receivers need to learn the new group addresses to 651 join. 653 Note that for SSM, receivers need to learn which multicast 654 channels to join. A channel is a source and group pair. This 655 means that for an SSM application, a change of source address is 656 likely to have the same effect as a change of group address. 658 Some applications may have dynamic methods of learning which 659 groups (and possibly sources) to join. If not, the application 660 may have to be reconfigured and restarted. 662 One common way for receivers to learn the necessary parameters 663 are by use of SDP. SDP information may be distributed via 664 various application protocols, or it may be from a file. An SDP 665 file may be distributed via HTTP, email etc. If a user is using 666 a web browser and clicking on a link to launch the application 667 with the necessary data, it may be a matter of closing the 668 current application, and re-clicking the link. 670 8.2. Mobility 672 As [RFC5887] suggested, for Mobile IP, we need a better mechanism to 673 handle change of home agent address while mobile is disconnected. 675 9. Gaps considered unsolvable 677 This section lists gaps have been documented but are considered 678 unsolvable or out of the scope of this document. 680 9.1. Address Configuration 682 o RA prefix lifetime limitation 684 In section 5.5.3 of [RFC4862], it is defined that "If the 685 received Valid Lifetime is greater than 2 hours or greater than 686 RemainingLifetime, set the valid lifetime of the corresponding 687 address to the advertised Valid Lifetime." So when renumbering, 688 if the previous RemainingLifetime is longer than two hours, it 689 is impossible to reduce a prefix's lifetime less than two hours. 690 This limitation is to prevent denial-of-service attack. 692 9.2. Address-relevant Entries Update 694 o DNS entries commonly have matching Reverse DNS entries which will 695 also need to be updated during renumbering. 697 o DNS data structure optimization 699 [RFC2874] proposed an experimental A6 record type for DNS 700 recording of IPv6 address and prefix. Several extensions to DNS 701 query and processing were also proposed. With the A6 record and 702 the extensions, an IPv6 address could be defined by using 703 multiple DNS records. This feature would increase the complexity 704 of resolvers but reduce the cost of zone file maintenance, so 705 renumbering could be easier than with the AAAA record. But the 706 A6 record has not been widely used, and it has been moved to 707 historic status [RFC6563]. 709 o DNS authority 711 As described in [I-D.chown-v6ops-renumber-thinkabout], "it is 712 often the case in enterprises that host web servers and 713 application servers on behalf of collaborators and customers 714 that DNS zones out of the administrative control of the host 715 maintain resource records concerning addresses for nodes out of 716 their control. When the service host renumbers, they do not have 717 sufficient authority to change the records. " 719 It is an operational and policy issue and this document 720 considers it not suitable to be solved through technical 721 approach or bring additional protocol/mechanism to standardize 722 the interaction between DNS systems for authority negotiations. 724 9.3. Static address issues 726 In [I-D.ietf-6renum-static-problem], there are several open issues 727 listed at the end, which are as below: 729 o Is minor residual loss of ongoing transport sessions during 730 renumbering operationally acceptable? 732 o Can automatic network element renumbering can be performed without 733 interrupting user sessions? 735 o Do any software licensing systems require manual intervention? 737 The former two questions are about session survivability which is not 738 only static address specific. As described in section 2, this 739 document generally considers [RFC4192] is sufficient for avoiding 740 session brokenness issue in IPv6 site renumbering in most of the 741 cases. 743 9.4. Miscellaneous 745 o For transport layer, [RFC5887] said that TCP connections and UDP 746 flows are rigidly bound to a given pair of IP addresses. 748 o For application layer, as [RFC5887] said, in general, we can 749 assert that any implementation is at risk from renumbering if it 750 does not check that an address is valid each time it opens a new 751 communications session. 753 10. Security Considerations 755 o Prefix Validation 757 Prefixes from the ISP may need authentication to prevent prefix 758 fraud. Announcing changes of site prefix to other sites (for example, 759 those that configure routers or VPNs to point to the site in 760 question) also need validation. 762 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or Secure 763 Neighbor Discovery (SEND, [RFC3971]) deployment may need to validate 764 prefixes. 766 o Influence on Security Controls 768 During renumbering, security controls (e.g. ACLs) blocking access to 769 legitimate resources should not be interrupted. 771 11. IANA Considerations 773 This draft does not request any IANA action. 775 12. Acknowledgments 777 This work adopts significant amounts of content from [RFC5887] and 778 [I-D.chown-v6ops-renumber-thinkabout], so thanks go to Randall 779 Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some 780 useful materials were provided by Oliver Bonaventure and his student 781 Damien Leroy. 783 Many useful comments and contributions were made by Lee Howard, and 784 members of 6renum WG. 786 This document was prepared using 2-Word-v2.0.template.dot. 788 13. References 790 13.1. Normative References 792 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 793 August 2000. 795 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 796 IPv6 Address Aggregation and Renumbering", RFC 2874, July 797 2000. 799 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 800 Update", RFC 3007, November 2000. 802 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 803 M. Carney, "Dynamic Host Configuration Protocol for IPv6 804 (DHCPv6)", RFC 3315, July 2003. 806 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 807 Host Configuration Protocol (DHCP) version 6", RFC 3633, 808 December 2003. 810 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 811 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 812 November 2004. 814 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 815 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 817 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 818 "Neighbor Discovery for IP version 6 (IPv6)", RFC 819 4861,September 2007. 821 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 822 Address Autoconfiguration", RFC 4862, September 2007. 824 13.2. Informative References 826 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 827 1997. 829 [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 830 Multicast Addresses", RFC 3306, August 2002. 832 [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) 833 Address in an IPv6 Multicast Address", RFC 3965, November 834 2004. 836 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 837 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 838 September 2005. 840 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 841 December 2006. 843 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 844 Still Needs Work", RFC 5887, May 2010. 846 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 847 Historic Status", RFC 6563, May 2012. 849 [I-D.ietf-dhc-secure-dhcpv6] 850 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 851 in progress, March 2012. 853 [I-D.ietf-6renum-enterprise] 854 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 855 Scenarios and Guidelines ", Working in 856 Progress, July 2011. 858 [I-D.chown-v6ops-renumber-thinkabout] 859 Chown, T., "Things to think about when Renumbering an IPv6 860 network", Work in Progress, September 2006. 862 [I-D.ietf-6renum-static-problem] 863 Carpenter, B., and S. Jiang, "Problem Statement for 864 Renumbering IPv6 Hosts with Static Addresses", Working in 865 Progress, August 2012. 867 [I-D.liu-6renum-dhcpv6-slaac-switching] 868 Liu, B., "DHCPv6/SLAAC Address Configuration Switching for 869 Host Renumbering", Working in Progress, July 2012 871 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 872 configurations for IPv6 renumbering", International of 873 Network Management, 2009, 876 Authors' Addresses 878 Bing Liu 879 Huawei Technologies Co., Ltd 880 Q14, Huawei Campus 881 No.156 Beiqing Rd. 882 Hai-Dian District, Beijing 100095 883 P.R. China 885 Email: leo.liubing@huawei.com 887 Sheng Jiang 888 Huawei Technologies Co., Ltd 889 Q14, Huawei Campus 890 No.156 Beiqing Rd. 891 Hai-Dian District, Beijing 100095 892 P.R. China 894 Email: jiangsheng@huawei.com 896 Brian Carpenter 897 Department of Computer Science 898 University of Auckland 899 PB 92019 900 Auckland, 1142 901 New Zealand 903 EMail: brian.e.carpenter@gmail.com 905 Stig Venaas 906 Cisco Systems 907 Tasman Drive 908 San Jose, CA 95134 909 USA 911 Email: stig@cisco.com 912 Wesley George 913 Time Warner Cable 914 13820 Sunrise Valley Drive 915 Herndon, VA 20171 916 USA 918 Phone: +1 703-561-2540 919 Email: wesley.george@twcable.com 921 Liu, et