idnits 2.17.1 draft-ietf-6renum-enterprise-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 01, 2012) is 4254 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft B. Liu 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: March 04, 2013 B. Carpenter 5 University of Auckland 6 September 01, 2012 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-ietf-6renum-enterprise-02.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 March 04, 2013. 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 analyzes enterprise renumbering events and describes 46 the best current practice among the existing renumbering mechanisms. 47 According to the different stages of renumbering events, 48 considerations and best current practices are described in three 49 categories: during network design, for preparation of renumbering, 50 and during a renumbering operation. 52 Table of Contents 54 1. Introduction ................................................. 3 55 2. Enterprise Network Illustration for Renumbering .............. 3 56 3. Enterprise Network Renumbering Scenario Categories ........... 4 57 3.1. Renumbering Caused by External Network Factors........... 4 58 3.2. Renumbering caused by Internal Network Factors........... 5 59 4. Network Renumbering Considerations and Best Current Practices. 5 60 4.1. Considerations and Best Current Practices during Network 61 Design ....................................................... 6 62 4.2. Considerations and Best Current Practices for the Preparation 63 of Renumbering ............................................... 9 64 4.3. Considerations and Best Current Practices during Renumbering 65 Operation ................................................... 10 66 5. Security Considerations ..................................... 12 67 6. IANA Considerations ......................................... 13 68 7. Acknowledgements ............................................ 13 69 8. References .................................................. 13 70 8.1. Normative References ................................... 13 71 8.2. Informative References ................................. 14 72 Author's Addresses ............................................. 16 74 1. Introduction 76 IPv6 site renumbering is considered difficult. Network managers might 77 prefer to use Provider Independent (PI) addressing for IPv6 to 78 attempt to minimize the need for future renumbering. However, 79 widespread use of PI may create very serious BGP4 scaling problems 80 and PI space is not always available for enterprises according to the 81 RIR (Regional Internet Registry) policies. It is thus desirable to 82 develop mechanisms and practice guidelines that could make 83 renumbering a simpler process to reduce demand for IPv6 PI spaces. 85 This document undertakes scenario descriptions, including 86 documentation of current capabilities and existing BCPs, for 87 enterprise networks. It takes [RFC5887] and other relevant documents 88 as the primary input. 90 The IPv4 and IPv6 are logically separated from the perspective of 91 renumbering, regardless of overlapping of the IPv4/IPv6 networks or 92 devices. This document focuses on IPv6 only, by leaving IPv4 out of 93 scope. Dual-stack network or IPv4/IPv6 transition scenarios are out 94 of scope, too. 96 This document focuses on enterprise network renumbering, though most 97 of the analysis is also applicable to ISP network renumbering. 98 Renumbering in home networks is considered out of scope, though it 99 may also benefit from the analysis in this document. 101 The concept of enterprise network and a typical network illustration 102 are introduced first. Then, according to the different stages of 103 renumbering events, considerations and best current practices are 104 described in three categories: during network design, for preparation 105 of renumbering, and during renumbering operation. 107 2. Enterprise Network Illustration for Renumbering 109 An Enterprise Network as defined in [RFC4057] is: a network that has 110 multiple internal links, one or more router connections to one or 111 more Providers, and is actively managed by a network operations 112 entity. 114 The enterprise network architecture is illustrated in the figure 115 below. Those entities relevant to renumbering are highlighted. 117 Address reconfiguration is fulfilled either by DHCPv6 or ND 118 protocols. During the renumbering event, the DNS records need to be 119 synchronized while routing tables, ACLs and IP filtering tables in 120 various devices also need to be updated, too. 122 Static address issue is described in a dedicated draft 123 [I-D.ietf-6renum-static-problem]. 125 Uplink 1 Uplink 2 126 | | 127 +---+---+ +---+---+ 128 +---- |Gateway| --------- |Gateway| -----+ 129 | +-------+ +-------+ | 130 | Enterprise Network | 131 | +------+ +------+ +------+ | 132 | | APP | |DHCPv6| | DNS | | 133 | |Server| |Server| +Server+ | 134 | +---+--+ +---+--+ +--+---+ | 135 | | | | | 136 | ---+--+---------+------+---+- | 137 | | | | 138 | +--+---+ +---+--+ | 139 | |Router| |Router| | 140 | +--+---+ +---+--+ | 141 | | | | 142 | -+---+----+-------+---+--+- | 143 | | | | | | 144 | +-+--+ +--+-+ +--+-+ +-+--+ | 145 | |Host| |Host| |Host| |Host| | 146 | +----+ +----+ +----+ +----+ | 147 +----------------------------------------+ 148 Figure 1 Enterprise network illustration 150 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 151 stack in which a logical IPv6 plane is independent from IPv4. The 152 complicated IPv4/IPv6 co-existence scenarios are out of scope. 154 This document focuses on the unicast addresses; site-local, link- 155 local, multicast and anycast addresses are out of scope. 157 3. Enterprise Network Renumbering Scenario Categories 159 In this section, we divide enterprise network renumbering scenarios 160 into two categories defined by external and internal network factors, 161 which require renumbering for different reasons. 163 3.1. Renumbering Caused by External Network Factors 165 The most influential external network factor is the uplink ISP. 167 o The enterprise network switches to a new ISP. Of course, the 168 prefixes received from different ISPs are different. This is the 169 most common scenario. 171 Whether there is an overlap time between the old and new ISPs 172 would also influence the possibility whether the enterprise can 173 fulfill renumbering without a flag day [RFC4192]. 175 o The renumbering event may be initiated by receiving new prefixes 176 from the same uplink. This might happen if the enterprise network 177 is switched to a different location within the network topology of 178 the same ISP due to various considerations, such as commercial, 179 performance or services reasons, etc. Alternatively, the ISP 180 itself might be renumbered due to topology changes or migration to 181 a different or additional prefix. These ISP renumbering events 182 would initiate enterprise network renumbering events, of course. 184 o The enterprise network adds new uplink(s) for multihoming purposes. 185 This may not be a typical renumbering case because the original 186 addresses will not be changed. However, initial numbering may be 187 considered as a special renumbering event. The enterprise network 188 removes uplink(s) or old prefixes. 190 3.2. Renumbering caused by Internal Network Factors 192 o As companies split, merge, grow, relocate or reorganize, the 193 enterprise network architectures may need to be re-built. This 194 will trigger the internal renumbering. 196 o The enterprise network may proactively adopt a new address scheme, 197 for example by switching to a new transition mechanism or stage of 198 a transition plan. 200 o The enterprise network may reorganize its topology or subnets. 202 4. Network Renumbering Considerations and Best Current Practices 204 In order to carry out renumbering in an enterprise network, 205 systematic planning and administrative preparation are needed. 206 Carefully planning and preparation could make the renumbering process 207 smoother. 209 This section recommends some solutions or strategies for the 210 enterprise renumbering, chosen among existing mechanisms. There are 211 known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps 212 are filled in the future, the enterprise renumbering may be processed 213 more automatically, with fewer issues. 215 4.1. Considerations and Best Current Practices during Network Design 217 This section describes the consideration or issues relevant to 218 renumbering that a network architect should carefully plan when 219 building or designing a new network. 221 - Prefix Delegation 223 In a large or a multi-site enterprise network, the prefix should 224 be carefully managed, particularly during renumbering events. 225 Prefix information needs to be delegated from router to router. 226 The DHCPv6 Prefix Delegation options [RFC3633] and 227 [RFC6603] provide a mechanism for automated delegation of IPv6 228 prefixes. Normally, DHCPv6 PD options are used between the 229 internal enterprise routers, for example, a router receives 230 prefix(es) from its upstream router (may be a border gateway or 231 edge router .etc) through DHCPv6 PD options and then advertise it 232 (them) to the local hosts through RA messages. 234 - Usage of FQDN 236 In general, Fully-Qualified Domain Names (FQDNs) are recommended 237 to be used to configure network connectivity, such as tunnels, 238 whenever possible. The capability to use FQDNs as endpoint names 239 has been standardized in several RFCs, such as [RFC5996], although 240 many system/network administrators do not realize that it is there 241 and works well as a way to avoid manual modification during 242 renumbering. 244 Service Location Protocol [RFC2608] and multicast DNS with SRV 245 records for service discovery can reduce the number of places that 246 IP addresses need to be configured. But it should be noted that 247 multicast DNS is link-local only. 249 - Usage of ULA 251 Unique Local Addresses (ULAs) are defined in [RFC4193] as 252 provider-independent prefixes, and they are globally unique to 253 avoid collision. For enterprise networks, using ULA along with PA 254 can provide a logically local routing plane separated from the 255 globally routing plane. The benefit is to ensure stable and 256 specific local communication regardless of the ISP uplink failure. 257 This benefit is especially meaningful for renumbering. It mainly 258 includes three use cases as the following. 260 When renumbering, as RFC4192 suggested, it has a period to keep 261 using the old prefix(es) before the new prefix(es) is(are) stable. 263 In the process of adding new prefix(es) and deprecating old 264 prefix(es), it is not easy to keep the local communication immune 265 of global routing plane change. If we use ULA for the local 266 communication, the separated local routing plane can isolate the 267 affecting by global routing change. 269 Enterprise administrators may want to avoid the need to renumber 270 their internal-only, private nodes when they have to renumber the 271 PA addresses of the whole network because of changing ISPs, ISPs 272 restructure their address allocations, or any other reasons. In 273 these situations, ULA is an effective tool for the internal-only 274 nodes. 276 For multicast, ULA may be a way of avoiding renumbering from 277 having an impact on multicast. In most deployments multicast is 278 only used internally (intra-domain), and the addresses used for 279 multicast sources and Rendezvous-Points need not be reachable nor 280 routable externally. Hence one may at least internally make use of 281 ULA for multicast specific infrastructure. 283 - Address Types 285 This document focuses on the dynamically-configured global unicast 286 addresses in enterprise networks. They are the targets of 287 renumbering events. 289 Manual-configured addresses are not scalable in medium to large 290 sites, hence are out of scope. Manually-configured addresses/hosts 291 should be avoided as much as possible. 293 - Address configuration models 295 In IPv6 networks, there are two auto-configuration models for 296 address assignment: Stateless Address Auto-Configuration (SLAAC, 297 [RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful 298 address configuration by Dynamic Host Configuration Protocol for 299 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 300 support host-generated address model by assigning a prefix through 301 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 303 ND is considered easier to renumber by broadcasting a Router 304 Advertisement message with a new prefix. DHCPv6 can also trigger 305 the renumbering process by sending unicast RECONFIGURE messages, 306 though it may cause a large number of interactions between hosts 307 and DHCPv6 server. 309 This document has no preference between ND and DHCPv6 address 310 configuration models. It is network architects' job to decide 311 which configuration model is employed. But it should be noticed 312 that using DHCPv6 and ND together within one network, especially 313 in one subnet, may cause operational issues. For example, some 314 hosts use DHCPv6 as the default configuration model while some use 315 ND. Then the hosts' address configuration model depends on the 316 policies of operating systems and cannot be controlled by the 317 network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses 318 more details on this topic. So, in general, this document 319 recommends using DHCPv6/SLAAC independently in different subnets. 321 However, since DHCPv6 is also used to configure many other network 322 parameters, there are ND and DHCPv6 co-existence scenarios. 323 Combinations of address configuration models may coexist within a 324 single enterprise network. [I-D.ietf-savi-mix] provides 325 recommendations to avoid collisions and to review collision 326 handling in such scenarios. 328 - DNS 330 It is recommended that the site have an automatic and systematic 331 procedure for updating/synchronizing its DNS records, including 332 both forward and reverse mapping [RFC2874]. A manual on-demand 333 updating model does not scale, and increases the chance of errors. 335 Although the A6 DNS record model [RFC2874] was designed for easier 336 renumbering, it has a lot of unsolved technical issues [RFC3364]. 337 Therefore, it has been moved to experimental status [RFC3363], and 338 will move to historic status by [RFC6563] (Moving A6 to Historic 339 Status). So A6 is not recommended. 341 In order to simplify the operation procedure, the network 342 architect should combine the forward and reverse DNS updates in a 343 single procedure. 345 Often, a small site depends on its ISP's DNS system rather than 346 maintaining its own. When renumbering, this requires 347 administrative coordination between the site and its ISP. 349 The DNS synchronization may be completed through the Secure DNS 350 Dynamic Update [RFC3007]. Dynamic DNS update can be provided by 351 the DHCPv6 client or by the server on behalf of individual hosts. 352 [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and 353 servers to exchange information about the client's FQDN and about 354 who has the responsibility for updating the DNS with the 355 associated AAAA and PTR RRs. For example, if a client wants the 356 server to update the FQDN-address mapping in the DNS server, it 357 can include the Client FQDN option with proper settings in the 358 SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message 359 originated by the client. When DHCPv6 server gets this option, it 360 can use the dynamic DNS update on behalf of the client. In this 361 document, we promote to support this FQDN option. But since it's a 362 DHCPv6 option, it implies that only the DHCP-managed networks are 363 suitable for this operation. In SLAAC mode, sometimes hosts also 364 need to register addresses on a registration server, which could 365 in fact be a DHCPv6 server (as described in 366 [I-D.ietf-dhc-addr-registration]); then the server would update 367 corresponding DNS records. 369 - Security 371 Any automatic renumbering scheme has a potential exposure to 372 hijacking. Malicious entity in the network can forge prefixes to 373 renumber the hosts. So proper network security mechanisms are 374 needed. 376 For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible 377 solution, but it is complex and there's almost no real deployment 378 so far. Comparing the non-trivial deployment of SEND, RA guard 379 [RFC6105] is a light-weight alternative, which focuses on rogue 380 router advertisements proof in a L2 network. However, it also 381 hasn't been widely deployed since it hasn't been published for 382 long. 384 For DHCPv6, there are built-in secure mechanisms (like Secure 385 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 386 messages [RFC3315] could be utilized. But these security 387 mechanisms also haven't been verified by wide real deployment. 389 - Miscellaneous 391 A site or network should also avoid embedding addresses from other 392 sites or networks in its own configuration data. Instead, the 393 Fully-Qualified Domain Names should be used. Thus, these 394 connections can survive after renumbering events at other sites. 395 This also applies to host-based connectivities. 397 4.2. Considerations and Best Current Practices for the Preparation of 398 Renumbering 400 In ND, it is not possible to reduce a prefix's lifetime to below two 401 hours. So, renumbering should not be an unplanned sudden event. This 402 issue could only be avoided by early planning and preparation. 404 This section describes several recommendations for the preparation of 405 enterprise renumbering event. By adopting these recommendations, a 406 site could be renumbered more easily. However, these recommendations 407 might increase the daily traffic, server load, or burden of network 408 operation. Therefore, only those networks that are expected to be 409 renumbered soon or very frequently should adopt these 410 recommendations, with balanced consideration between daily cost and 411 renumbering cost. 413 - Reduce the address preferred time or valid time or both. 415 Long-lifetime addresses may cause issues for renumbering events. 416 Particularly, some offline hosts may reconnect using these 417 addresses after renumbering events. Shorter preferred lifetimes 418 with relatively long valid lifetimes may allow short transition 419 periods for renumbering events and avoid frequent address 420 renewals. 422 - Reduce the DNS record TTL on the local DNS server. 424 The DNS AAAA resource record TTL on the local DNS server should be 425 manipulated to ensure that stale addresses are not cached. 427 - Reduce the DNS configuration lifetime on the hosts. 429 Since the DNS server could be renumbered as well, the DNS 430 configuration lifetime on the hosts should also be reduced if 431 renumbering events are expected. In ND, The DNS configuration can 432 be done through reducing the lifetime value in RDNSS option 433 [RFC6106]. In DHCPv6, the DNS configuration option specified in 434 [RFC3646] doesn't provide lifetime attribute, but we can reduce 435 the DHCPv6 client lease time to achieve similar effect. 437 - Identify long-living sessions 439 Any applications which maintain very long transport connections 440 (hours or days) should be identified in advance, if possible. Such 441 applications will need special handling during renumbering, so it 442 is important to know that they exist. 444 4.3. Considerations and Best Current Practices during Renumbering 445 Operation 447 Renumbering events are not instantaneous events. Normally, there is a 448 transition period, in which both the old prefix and the new prefix 449 are used in the site. Better network design and management, better 450 pre-preparation and longer transition period are helpful to reduce 451 the issues during renumbering operation. 453 - Within/without a flag day 455 As is described in [RFC4192], "a 'flag day' is a procedure in 456 which the network, or a part of it, is changed during a planned 457 outage, or suddenly, causing an outage while the network 458 recovers." 460 If renumbering event is processed within a flag day, the network 461 service/connectivity will be unavailable for a period until the 462 renumbering event is completed. It is efficient and provides 463 convenience for network operation and management. But network 464 outage is usually unacceptable for end users and enterprises. A 465 renumbering procedure without a flag day provides smooth address 466 switching, but much more operational complexity and difficulty is 467 introduced. 469 - Transition period 471 If renumbering transition period is longer than all address 472 lifetimes, after which the address leases expire, each host will 473 automatically pick up its new IP address. In this case, it would 474 be the DHCPv6 server or Router Advertisement itself that 475 automatically accomplishes client renumbering. 477 Address deprecation should be associated with the deprecation of 478 associated DNS records. The DNS records should be deprecated as 479 early as possible, before the addresses themselves. 481 - Network initiative enforced renumbering 483 If the network has to enforce renumbering before address leases 484 expire, the network should initiate DHCPv6 RECONFIGURE messages. 485 For some operating systems such as Windows 7, if the hosts receive 486 RA messages with ManagedFlag=0, they'll release the DHCPv6 487 addresses and do SLAAC according to the prefix information in the 488 RA messages, so this could be another enforcement method for some 489 specific scenarios. 491 - Impact to branch/main sites 493 Renumbering in main/branch site may cause impact on branch/main 494 site communication. The routes, ingress filtering of site's 495 gateways, and DNS may need to be updated. This needs careful 496 planning and organizing. 498 - DNS record update and DNS configuration on hosts 500 DNS records on the local DNS server should be updated if hosts are 501 renumbered. If the site depends on ISP's DNS system, it should 502 report the new host's DNS records to its ISP. During the 503 transition period, both old and new DNS records are valid. If the 504 TTLs of DNS records are shorter than the transition period, an 505 administrative operation may not be necessary. 507 DNS configuration on hosts should be updated if local recursive 508 DNS servers are renumbered. During the transition period, both old 509 and new DNS server addresses may co-exist on the hosts. If the 510 lifetime of DNS configuration is shorter than the transition 511 period, name resolving failure may be reduced to minimum. A 512 notification mechanism may be needed to indicate to the hosts that 513 a renumbering event of local recursive DNS happens or is going to 514 take place. 516 - Tunnel concentrator renumbering 518 A tunnel concentrator itself might be renumbered. This change 519 should be reconfigured in relevant hosts or routers, unless the 520 configuration of tunnel concentrator was based on FQDN. However, 521 even if FQDN is used, some other tunnel-relevant configuration may 522 still exist, for example IPSec, so fail in renumbering. 524 - Connectivity session survivability 526 During the renumbering operations, connectivity sessions in IP 527 layer would break if the old address is deprecated before the 528 session ends. However, the upper layer sessions may survive by 529 using session survivability technologies, such as SHIM6 [RFC5533]. 530 As mentioned above, some long-living applications may need to be 531 handled specially. 533 5. Security Considerations 535 As noted, a site that is listed by IP address in a black list can 536 escape that list by renumbering itself. 538 Any automatic renumbering scheme has a potential exposure to 539 hijacking. Proper network security mechanisms are needed. Although 540 there are existing security mechanisms such as SEND, RA guard, secure 541 DHCPv6 etc., they haven't been widely deployed and haven't been 542 verified whether they are suitable for ensuring security while not 543 bringing too much operational complexity and cost. 545 Dynamic DNS update may bring risk of DoS attack to the DNS server. So 546 along with the update authentication, session filtering/limitation 547 may also be needed. 549 The "make-before-break" approach of [RFC4192] requires the routers 550 keep advertising the old prefixes for some time. But if the ISP 551 changes the prefixes very frequently, the co-existence of old and new 552 prefixes may cause potential risk to the enterprise routing system 553 since the old address relevant route path may already invalid and the 554 routing system just doesn't know it. However, normally enterprise 555 scenarios don't involve the extreme situation. 557 6. IANA Considerations 559 This draft does not request any IANA action. 561 7. Acknowledgements 563 This work is illuminated by RFC5887, so thank for RFC 5887 authors, 564 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 565 in by documents from Tim Chown and Fred Baker. The authors also want 566 to thank Wesley George, Olivier Bonaventure and other 6renum members 567 for valuable comments. 569 8. References 571 8.1. Normative References 573 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 574 Location Protocol, Version 2", RFC 2608, June 1999. 576 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 577 Update", RFC 3007, November 2000. 579 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 580 M. Carney, "Dynamic Host Configuration Protocol for IPv6 581 (DHCPv6)", RFC 3315, July 2003. 583 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 584 Host Configuration Protocol (DHCP) version 6", RFC 3633, 585 December 2003. 587 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 588 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 589 December 2003. 591 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 592 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 594 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 595 Addresses", RFC 4193, October 2005. 597 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 598 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 599 RFC 4706, October 2006. 601 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 602 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 603 September 2007. 605 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 606 Address Autoconfiguration", RFC 4862, September 2007. 608 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 609 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 610 September 2010. 612 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 613 "IPv6 Router Advertisement Option for DNS Configuration", 614 RFC 6106, November 2011. 616 8.2. Informative References 618 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 619 IPv6 Address Aggregation and Renumbering", RFC 2874, July 620 2000. 622 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 623 "Representing Internet Protocol version 6 (IPv6) Addresses 624 in the Domain Name System (DNS)", RFC 3363, August 2002. 626 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 627 for Internet Protocol version 6 (IPv6)", RFC 3364, August 628 2002. 630 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 631 4057, June 2005. 633 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 634 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 635 September 2005. 637 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 638 Shim Protocol for IPv6", RFC 5533, June 2009. 640 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 641 Still Needs Work", RFC 5887, May 2010. 643 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 644 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 645 February 2011. 647 [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 648 Historic Status", RFC 6563, May 2012. 650 [I-D.ietf-dhc-secure-dhcpv6] 651 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 652 in progress, March 2012. 654 [I-D.ietf-dhc-host-gen-id] 655 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 656 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 657 August, 2012. 659 [I-D.ietf-savi-mix] 660 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 661 for Mixed Address Assignment Methods Scenario", working in 662 progress, April 2012. 664 [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 665 Exclude Option for DHCPv6-based Prefix Delegation", RFC 666 6603, May 2012. 668 [I-D.ietf-dhc-addr-registration] 669 Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration 670 Solution Using DHCPv6", working in progress, May 2012. 672 [I-D.ietf-6renum-gap-analysis] 673 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 674 Analysis", working in progress, August 2012. 676 [I-D.ietf-6renum-static-problem] 677 Carpenter, B. and S. Jiang., "Problem Statement for 678 Renumbering IPv6 Hosts with Static Addresses", working in 679 progress, August 2012. 681 Author's Addresses 683 Sheng Jiang 684 Huawei Technologies Co., Ltd 685 Q14, Huawei Campus 686 No.156 Beiqing Rd. 687 Hai-Dian District, Beijing 100095 688 P.R. China 690 EMail: jiangsheng@huawei.com 692 Bing Liu 693 Huawei Technologies Co., Ltd 694 Q14, Huawei Campus 695 No.156 Beiqing Rd. 696 Hai-Dian District, Beijing 100095 697 P.R. China 699 EMail: leo.liubing@huawei.com 701 Brian Carpenter 702 Department of Computer Science 703 University of Auckland 704 PB 92019 705 Auckland, 1142 706 New Zealand 708 EMail: brian.e.carpenter@gmail.com