idnits 2.17.1 draft-ietf-6renum-gap-analysis-00.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 (February 6, 2012) is 4453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5887' on line 566 == Unused Reference: 'RFC3956' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC4714' is defined on line 638, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- No information found for draft-jiang-6renum-enterprise - is the name correct? -- No information found for draft-carpenter-6renum-static-problem - is the name correct? -- No information found for draft-jiang-a6-to-historic - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft S. Jiang 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: August 9, 2012 B. Carpenter 5 University of Auckland 6 February 6, 2012 8 IPv6 Site Renumbering Gap Analysis 9 draft-ietf-6renum-gap-analysis-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 9, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document briefly introduces the existing mechanisms could be 46 utilized by IPv6 site renumbering and envisions the effort could be 47 done. This document tries to cover the most explicit issues and 48 requirements of IPv6 renumbering. Through the gap analysis, the 49 document provides a basis for future work to identify and develop 50 solutions or to stimulate such development as appropriate. The gap 51 analysis is presented following a renumbering event procedure clue. 53 Table of Contents 55 1. Introduction ............................................. 3 56 2. Overall Requirements for Renumbering ..................... 3 57 3. Existing Components for IPv6 Renumbering ................. 4 58 3.1. Relevant Protocols and Mechanisms ................... 4 59 3.2. Management Tools .................................... 5 60 3.3. Procedures/Policies ................................. 5 61 4. Managing Prefixes ........................................ 6 62 4.1. Prefix Delegation ................................... 6 63 4.2. Prefix Assignment ................................... 6 64 5. Address Configuration .................................... 6 65 5.1. Host Address Configuration .......................... 6 66 5.2. Router Address Configuration ........................ 8 67 5.3. Static Address Configuration ........................ 9 68 6. Updating Relevant Address Entries ........................ 9 69 6.1. DNS Records Update .................................. 9 70 6.2. In-host Server Address Update ...................... 10 71 6.3. Filters ............................................ 10 72 7. Renumbering Event Management ............................ 11 73 7.1. Renumbering Notification ........................... 11 74 7.2. Synchronization Management ......................... 11 75 7.3. Renumbering Monitoring.............................. 11 76 8. Miscellaneous ........................................... 12 77 8.1. Mobility ........................................... 12 78 9. Gaps considered unsolvable .............................. 12 79 9.1. Address Configuration .............................. 12 80 9.2. Address Relevant Entries Update .................... 12 81 9.3. Miscellaneous ...................................... 13 82 10. Security Considerations ................................ 13 83 11. IANA Considerations .................................... 13 84 12. References ............................................. 14 85 12.1. Normative References .............................. 14 86 12.2. Informative References ............................ 14 87 13. Acknowledgments ........................................ 15 89 1. Introduction 91 As introduced in [RFC5887], renumbering, especially for medium to 92 large sites and networks, is currently viewed as an expensive, 93 painful, and error-prone process, avoided by network managers as much 94 as possible. If IPv6 site renumbering continues to be considered 95 difficult, network managers will turn to Provider Independent (PI) 96 addressing for IPv6 to attempt to minimize the need for future 97 renumbering. However, widespread use of PI may create very serious 98 BGP4 scaling problems. It is thus desirable to develop tools and 99 practices that may make renumbering a simpler process to reduce 100 demand for IPv6 PI space. 102 This document performs a gap analysis to provide a basis for future 103 work to identify and develop solutions or to stimulate such 104 development as appropriate. The gap analysis is organized by the main 105 steps of renumbering process, which include prefix management, node 106 address (re)configuration, and updating relevant address entries in 107 various gateways, routers and servers, etc. Besides these steps, the 108 aspect of renumbering event management is presented independently, 109 which intends to help the operational/administrative process. It is 110 expected that these steps and management could cover all the aspects 111 of an renumbering event. 113 This document draws on existing work in (at least) [RFC5887], [I- 114 D.chown-v6ops-renumber-thinkabout] and [RFC4192]. Contributions from 115 [I-D.jiang-6renum-enterprise] are incorporated into the more detailed 116 analysis. Lots of issues were analyzed in RFC5887 & [I-D.chown-v6ops- 117 renumber-thinkabout], but many of them are out of 6renum scope or 118 unsolvable. This document intends to identify the valuable and 119 solvable issues, dig out of some undiscovered gaps, and tries to give 120 solution suggestions. 122 2. Overall Requirements for Renumbering 124 This section introduces the overall ultimate goals we want to achieve 125 in a renumbering event. In general, we need to leverage renumbering 126 automation to avoid human intervention as much as possible at 127 reasonable cost. Some existing mechanisms have already provided 128 useful help. Further efforts may be achieved in the future. 130 The automation can be divided into four aspects as follows, which are 131 also the gap analysis topics. 133 o Prefix delegation and delivery should be automatic and accurate in 134 aggregation and coordination. 136 o Address reconfiguration should be automatically achieved through 137 standard protocols with minimum human intervention. 139 o Updating relevant address entries should be performed integrally 140 and without error. [Open Question]Is it necessary to develop 141 automatic entries update mechanisms? If necessary, do we need 142 standard protocols/interface for it? 144 o Renumbering event management is needed to provide the functions of 145 renumbering notification, synchronization, and monitoring .etc. 147 Besides automation, session survivability is another important issue 148 during renumbering since application outage is one of the most 149 obvious impacts that make renumbering painful and expensive. We have 150 an enormous advantage in IPv6 which is the ability to overlap the old 151 and new prefixes and to use the address lifetime mechanisms in SLAAC 152 and DHCPv6. That is fully described in [RFC4192]. We consider this 153 mechanism is sufficient for session survivability issue in most of 154 the cases. 156 [Open Question]Should we consider the case of very long-lived 157 application sessions (days or weeks) which cannot be resolved by 158 [RFC4192]? 160 3. Existing Components for IPv6 Renumbering 162 Since renumbering is not a whole new issue, some protocols/mechanisms 163 have been already utilized or even be developed dedicated for 164 renumbering. However, generally current renumbering is achieved by 165 existing protocols rather than dedicated renumbering protocols. This 166 section briefly reviews these existing protocols/mechanisms to 167 provide a basis for the gap analysis. 169 3.1. Relevant Protocols and Mechanisms 171 o RA messages, defined in [RFC4861], are used to deprecate/announce 172 old/new prefixes and to advertise the availability of an upstream 173 router. In renumbering, it is one of basic mechanisms for host 174 configuration. 176 o When a host is renumbered, it may use SLAAC [RFC4862] for address 177 configuration with the new prefix. Hosts receive RA messages which 178 contain routable prefix(es) and the address(es) of the default 179 router(s), then hosts can generate IPv6 address(es) by themselves. 181 o Hosts configured through DHCPv6 [RFC3315] can reconfigure 182 addresses by initialing RENEW sessions 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 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 dedicated for 198 renumbering or just common tools could be utilized for some 199 operations in renumbering. 201 Following are samples of the tools. 203 o Address management tools. There are both commercial and open- 204 source, and even home-made solutions. 205 [Further work is needed to identify what an address management 206 tool should be able to do for improving the ability of managing a 207 network through a renumbering event.] 209 o [LEROY] proposed a mechanism of macros to automatically update the 210 address relevant entries/configurations inside the DNS, firewall, 211 etc. The macros can be delivered though SOAP protocol from a 212 network management server to the managed devices. 214 o Asset management tools/systems. These tools may provide the 215 ability of managing configuration files in nodes so that it is 216 convenient to update the address relevant configuration in these 217 nodes. 219 3.3. Procedures/Policies 221 o [RFC4192] proposed a procedure for renumbering an IPv6 network 222 without a flag day. The document includes a set of operational 223 suggestions which can be followed step by step by network 224 administrators. 226 o [I-D.jiang-6renum-enterprise] analyzes the enterprise renumbering 227 events and gives the recommendations among the existing 228 renumbering mechanisms. According to the different stages, 229 renumbering considerations are described in three categories: 230 considerations and recommendations during network design, for 231 preparation of enterprise network renumbering, and during 232 renumbering operation 234 4. Managing Prefixes 236 When renumbering an enterprise site, a short prefix may be divided 237 into longer prefixes for subnets. So we need to carefully manage the 238 prefixes for prefix delivery, delegation, aggregation, 239 synchronization, coordination, etc. 241 4.1. Prefix Delegation 243 Usually, the short prefix comes down from the operator and received 244 by DHCPv6 server or router inside the enterprise network. The short 245 prefix could be automatically delegated through DHCPv6-PD. Then the 246 downlink DHCP servers or routers can begin advertising the longer 247 prefixes to the subnets. 249 For the delegation routers, they may need to renumber themselves with 250 the delegated prefixes. We need to consider the router renumbering 251 issue which cannot be covered by DHCP-PD only. 253 4.2. Prefix Assignment 255 When subnet routers receive the longer prefixes, they can directly 256 assign them to the hosts. The prefix assignment overlaps with the 257 host address configuration, which is described in the following 258 section 5.1. 260 5. Address Configuration 262 5.1. Host Address Configuration 264 Both of the DHCPv6 and ND protocols have IP address configuration 265 function. They are suitable for different scenarios respectively. 266 During renumbering, the SLAAC-configured hosts can reconfigure IP 267 addresses by receiving ND Router Advertisement (RA) messages 268 containing new prefix information (It should be noted that, the 269 prefix delivery could be achieved through DHCP according to the new 270 IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6- 271 configured hosts can reconfigure addresses by initiating RENEW 272 sessions when the current addresses' lease time are expired or 273 receiving the reconfiguration messages initiated by the DHCPv6 274 servers. 276 o SLAAC and DHCPv6 address configuration co-existence 278 While an IPv6 site is being renumbered, both DHCPv6 and ND may 279 be used to reconfigure the host addresses. The co-existence 280 issue mainly includes following aspects: 282 - Dynamic upstream learning 284 [RFC5887] mentioned that, DHCP-configured hosts may want to 285 learn about the upstream availability of new prefixes or loss 286 of prior prefixes dynamically by deducing from periodic RA 287 messages. But there is no standard specifying what approach 288 should be taken by a DHCPv6-configured host when it receives 289 RA messages containing new prefix. It depends on the operation 290 system of the host and cannot be predicted or controlled by 291 the network. 293 - DHCP-managed hosts receiving RA messages 295 It is unclear that whether a DHCP-managed host would accept 296 configuration though RA messages, it depends on the policies 297 in the host's operating system. If it ignores the RA messages 298 and there are no DHCPv6 reconfiguration messages received 299 either, the renumbering would fail. 301 - SLAAC-configured hosts finding DHCPv6 in use 303 [RFC5887] mentioned RA message of ND protocol contains a 304 "Managed Configuration" flag to indicate DHCPv6 is in use. But 305 it is unspecified what behavior should be taken when the host 306 receives RA messages with "M" set to 1. The gap of standard 307 will cause ambiguous host behavior because it depends on the 308 operation system of the host. 310 The host may start a DHCPv6 session and receives the DHCPv6 311 address configuration. It is also possible that the host finds 312 the DHCPv6 assigned prefix is different from the prefix in the 313 RA messages, which means multiple uplinks are available or 314 there is a serious network configuration error. 316 Another possibility is that the host may receive no response 317 from any DHCPv6 servers, which means the DHCPv6 service is not 318 available and the "Managed Configuration" flag was mis- 319 configured. 321 o DHCPv6 reconfigure bulk usage 323 [RFC5887] mentioned that ''DHCPv6 reconfiguration doesn't appear 324 to be widely used for bulk renumbering purposes''. 326 The reconfiguration defined in [RFC3315] needs to establish a 327 session between DHCP server and client. This could be considered 328 as a stateful approach which needs much resource on the server 329 to maintain the renumbering sessions. This is probably one of 330 the reasons that DHCP reconfiguration is not suitable for bulk 331 usage. 333 Another limitation of reconfiguration is that it only allows th 334 e messages to be delivered to unicast addresses. So if we want 335 to use it for bulk renumbering, stateless DHCPv6 reconfiguration 336 with multicast may be needed. However, this may involve protocol 337 modification. 339 5.2. Router Address Configuration 341 o Learning new prefixes 343 As described in [RFC5887], "if a site wanted to be multihomed 344 using multiple provider-aggregated (PA) routing prefixes with 345 one prefix per upstream provider, then the interior routers 346 would need a mechanism to learn which upstream providers and 347 prefixes were currently reachable (and valid). In this case, 348 their Router Advertisement messages could be updated dynamically 349 to only advertise currently valid routing prefixes to hosts. 350 This would be significantly more complicated if the various 351 provider prefixes were of different lengths or if the site had 352 non-uniform subnet prefix lengths." 354 o Restart after renumbering 356 "Some routers cache IP addresses in some situations. So routers 357 might need to be restarted as a result of site renumbering" 358 [RFC2072]. 360 o Router naming 362 In [RFC4192], it is suggested that "To better support 363 renumbering, switches and routers should use domain names for 364 configuration wherever appropriate, and they should resolve 365 those names using the DNS when the lifetime on the name 366 expires." 367 As [RFC5887] described, this capability is not new, and at least 368 it is present in most IPsec VPN implementations. But many 369 administrators do not realize that it could be utilized to avoid 370 manual modification during renumbering. 372 In enterprise scenario, the requirement of router naming is not 373 as strong as that in ISP. So for the administrators, the 374 motivation of using router naming for easing renumbering may be 375 not strong. 377 5.3. Static Address Configuration 379 There is another draft dedicated to the static address issue. Please 380 refer to [I-D.carpenter-6renum-static-problem]. 382 6. Updating Relevant Address Entries 384 When nodes in a site have been renumbered, then all the entries in 385 the site which contain the nodes' addresses must be updated. The 386 entries mainly include DNS records and filters in various entities 387 such as ACLs in firewalls/gateways. 389 6.1. DNS Records Update 391 o Dynamic DNS update 393 For DNS records update, the most popular DNS system BIND will 394 achieve it by maintaining a DNS zone file and loading this file 395 into the site's DNS server(s). Synchronization between host 396 renumbering and the updating of its A6 or AAAA record is hard. 397 [RFC5887] mentioned that an alternative is to use Secure Dynamic 398 DNS Update [RFC3007], in which a host informs its own DNS server 399 when it receives a new address. 401 Secure Dynamic DNS Update has been widely supported by the major 402 DNS systems, but it hasn't been widely deployed, especially in 403 the host. Current practices mainly involve the DHCP servers 404 which act as clients to request the DNS server to update 405 relevant records. Normal hosts are not suitable to do this 406 mainly because of the complexity of key management issues 407 inherited from secure DNS mechanisms. But for some commercial 408 DNS systems, the Secure Dynamic DNS Update issue may be much 409 easier, since it could be integrated with services like DHCP 410 provided by the same vendor so that the dynamic DNS update could 411 be silently enabled. 413 6.2. In-host Server Address Update 415 While DNS records addresses of hosts in servers, hosts also record 416 addresses of servers such as DNS server, radius server, etc. While 417 renumbering, the hosts must update the records if the server 418 addresses changed. Addresses of DHCPv6 servers do not need to be 419 updated. They are dynamically discovered using DHCPv6 relevant 420 multicast addresses. 422 o The DNS server addresses for hosts are configured by DHCPv6. But 423 current DHCPv6 messages do not indicate to hosts the lifetimes of 424 DNS. If the DNS lifetime expired and has been renumbered, the 425 hosts may still use the old addresses. DHCPv6 should be extended 426 to indicate to hosts the associated DNS lifetimes when making DNS 427 configuration. How the DHCP server could know about the DNS 428 lifetime is another issue. 430 6.3. Filters 432 o Filters Management 434 Filters based on addresses or prefixes are usually spread in 435 various devices. As [RFC5887] described, some address 436 configuration data might be widely dispersed and much harder to 437 find, even will inevitably be found only after the renumbering 438 event. So there's a big gap for filter management. 440 In [LEROY], a server is used for managing filter update in 441 various devices. But identifying where and which of the filters 442 need to be updated during renumbering is still a gap. 444 o Filter Update Automation Operation 446 As mentioned in section 3.2, [LEROY] proposed a mechanism which 447 can automatically update the filters. The mechanism utilizes 448 macros suitable for various devices such as routers, firewalls 449 etc. to update the filter entries based on the new prefix. Such 450 automation tool is valuable for renumbering because it can 451 reduce manual operation which is error-prone and inefficiency. 453 Besides the macros, [LEROY] also proposed to use SOAP to deliver 454 the macros to the devices. As well as SOAP we may consider 455 whether it is possible and suitable to use other standardized 456 protocols such as NETCONF. 458 Update of filters based on prefixes and filters based on 459 addresses may have different requirements and methods. Address- 460 based filters may be mainly with regard to domain names while 461 prefix-based filters be relevant to more abstract entity (mask 462 e.g.). Thus, we may consider different ways to update the two 463 kinds of filters, for example, the prefix-based filters may 464 consider to be updated though DHCPv6 server, which may provide 465 better efficient. 467 7. Renumbering Event Management 469 From the perspective of network management, renumbering is a kind of 470 event which may need additional process to make the process more easy 471 and manageable. 473 7.1. Renumbering Notification 475 If hosts or servers are aware of a renumbering event happening, it 476 may help the relevant process. Following are several examples of such 477 additional process may ease the renumbering. Further contributions 478 are expected. 480 o A notification mechanism may be needed to indicate the hosts that 481 a renumbering event of local recursive DNS happen or is going to 482 take place. 484 o [RFC4192] suggests that "reducing the delay in the transition to 485 new IPv6 addresses applies when the DNS service can be given prior 486 notice about a renumbering event." Reducing delay could improve 487 the efficiency of renumbering. 489 7.2. Synchronization Management 491 o DNS update synchronization 493 DNS update synchronization focuses on the coordinating between 494 DNS and other entities/mechanisms, for example, as described in 495 [RFC5887], synchronizing the SLAAC and DNS updates, and of 496 reducing the SLAAC lease time and DNS TTL. 498 7.3. Renumbering Monitoring 500 While treating renumbering a network event, mechanisms to monitor the 501 renumbering process may be needed. Considering the address 502 configuration operation may be stateless (if ND is used for 503 renumbering), it is difficult for monitoring. But for the DNS and 504 filter update, it is quite possible to monitor the whole process. 506 8. Miscellaneous 508 8.1. Mobility 510 As [RFC5887] suggested, for Mobile IP, we need a better mechanism to 511 handle change of home agent address while mobile is disconnected. 513 9. Gaps considered unsolvable 515 This section lists gaps have been documented but are considered 516 unsolvable or out of the scope of 6renum working group. 518 9.1. Address Configuration 520 o RA prefix lifetime limitation 522 In section 5.5.3 of [RFC4862], it is defined that ''If the 523 received Valid Lifetime is greater than 2 hours or greater than 524 RemainingLifetime, set the valid lifetime of the corresponding 525 address to the advertised Valid Lifetime.'' So when renumbering, 526 if the previous RemainingLifetime is longer than two hours, it 527 is impossible to reduce a prefix's lifetime less than two hours. 528 This limitation is to prevent denial-of-service attack. 530 9.2. Address Relevant Entries Update 532 o DNS entries commonly have matching Reverse DNS entries which will 533 also need to be updated during renumbering. 535 o DNS data structure optimization 537 [RFC2874] proposed a new A6 record type for DNS recording IPv6 538 address/prefix. And several extensions on query and processing 539 were also proposed. With the A6 record and the extensions, an 540 IPv6 address can be defined by using multiple DNS records. This 541 feature increases the complexity of resolver but reduce the cost 542 of zone file maintenance. So renumbering could be easier than 543 AAAA record. But the [RFC2874] has not been widely used, and 544 currently A6 is being discussed to be moved to historic status 545 [I-D.jiang-a6-to-historic]. 547 o DNS authority 548 As described in [I-D.chown-v6ops-renumber-thinkabout], ''it is 549 often the case in enterprises that host web servers and 550 application servers on behalf of collaborators and customers 551 that DNS zones out of the administrative control of the host 552 maintain resource records concerning addresses for nodes out of 553 their control. When the service host renumbers, they do not have 554 sufficient authority to change the records.'' 556 It is an operational issue and this document considers it not 557 suitable to be solved through bring additional 558 protocol/mechanism to standardize the interaction between DNS 559 systems needs to be considered. 561 9.3. Miscellaneous 563 o For transport layer, [5887] said that TCP connections and UDP 564 flows are rigidly bound to a given pair of IP addresses. 566 o For application layer, as [5887] said, in general, we can assert 567 that any implementation is at risk from renumbering if it does not 568 check that an address is valid each time it opens a new 569 communications session. 571 10. Security Considerations 573 o Prefix Validation 575 Prefixes from the ISP may need authentication to prevent prefix 576 fraud. Announcing changes of site prefix to other sites (for example, 577 those that configure routers or VPNs to point to the site in 578 question) also need validation. 580 In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND 581 ([RFC3971], Secure Neighbor Discovery) deployment may need to 582 validate prefixes. 584 o Influence to Security Controls 586 During renumbering, security controls (e.g. ACLs) blocking access to 587 legitimate resources should not be interrupted. 589 11. IANA Considerations 591 None. 593 12. References 595 12.1. Normative References 597 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 598 August 2000. 600 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 601 IPv6 Address Aggregation and Renumbering", RFC 2874, July 602 2000. 604 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 605 Update", RFC 3007, November 2000. 607 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 608 M. Carney, "Dynamic Host Configuration Protocol for IPv6 609 (DHCPv6)", RFC 3315, July 2003. 611 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 612 Host Configuration Protocol (DHCP) version 6", RFC 3633, 613 December 2003. 615 [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point 616 (RP) Address in an IPv6 Multicast Address.", RFC 3956, 617 November 2004. 619 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 620 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 622 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 623 "Neighbor Discovery for IP version 6 (IPv6)", RFC 624 4861,September 2007. 626 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 627 Address Autoconfiguration", RFC 4862, September 2007. 629 12.2. Informative References 631 [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 632 1997. 634 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 635 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 636 September 2005. 638 [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, 639 December 2006. 641 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 642 Still Needs Work", RFC 5887, May 2010. 644 [I-D.ietf-dhc-secure-dhcpv6] 645 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 646 in progress. 648 [I-D.chown-v6ops-renumber-thinkabout] 649 Chown, T., "Things to think about when Renumbering an IPv6 650 network", Work in Progress, September 2006. 652 [I-D.jiang-6renum-enterprise] 653 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 654 Scenarios and Guidelines ", Working in 655 Progress, July 2011. 657 [I-D.carpenter-6renum-static-problem] 658 Carpenter, B., and S. Jiang, "Problem Statement for 659 Renumbering IPv6 Hosts with Static Addresses", Working in 660 Progress, October 2011. 662 [I-D.jiang-a6-to-historic] 663 Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 664 Historic Status", Working in Progress, November 2011. 666 [LEROY] Leroy, D. and O. Bonaventure, "Preparing network 667 configurations for IPv6 renumbering", International of 668 Network Management, 2009, 671 13. Acknowledgments 673 This work adopts significant amounts of content from [RFC5887] and 674 [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, 675 Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, 676 and Stig Venaas. Some useful materials were provided by Oliver 677 Bonaventure and his student Damien Leroy, thanks for them, too. 679 Useful comments and contributions were made by Wesley George, and 680 others. 682 This document was prepared using 2-Word-v2.0.template.dot. 684 Authors' Addresses 686 Bing Liu 687 Q14-4-A Building 688 Huawei Technologies Co., Ltd 689 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 690 Hai-Dian District, Beijing 691 P.R. China 692 Email: leo.liubing@huawei.com 694 Sheng Jiang 695 Q14-4-A Building 696 Huawei Technologies Co., Ltd 697 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 698 Hai-Dian District, Beijing 699 P.R. China 700 Email: shengjiang@huawei.com 702 Brian Carpenter 703 Department of Computer Science 704 University of Auckland 705 PB 92019 706 Auckland, 1142 707 New Zealand 708 EMail: brian.e.carpenter@gmail.com