idnits 2.17.1 draft-jiang-6renum-enterprise-01.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 (September 29, 2011) is 4594 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3633' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC3364' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-pd-exclude' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.jiang-dnsext-a6-to-historic' is defined on line 665, 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- No information found for draft-jiang-dnsext-a6-to-historic - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: Best Current Practice Huawei Technologies Co., Ltd 4 Expires: March 18, 2012 B. Carpenter 5 University of Auckland 6 September 29, 2011 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-jiang-6renum-enterprise-01.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 18, 2012. 28 Copyright Notice 30 Copyright (c) 2011 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. A gap inventory is listed at the 51 end of this document. 53 Table of Contents 55 1. Introduction ................................................. 3 56 2. Enterprise Network Illustration for Renumbering .............. 3 57 3. Enterprise Network Renumbering Scenario Categories ........... 4 58 3.1. Renumbering caused by External Network Factors........... 4 59 3.2. Renumbering caused by Internal Network Factors........... 5 60 4. Network Renumbering Considerations and Best Current Practise.. 5 61 4.1. Considerations and Best Current Practice during Network 62 Design ....................................................... 6 63 4.2. Considerations and Best Current Practice for the Preparation 64 of Renumbering ............................................... 9 65 4.3. Considerations and Best Current Practice during Renumbering 66 Operation ................................................... 10 67 5. Gap Inventory ............................................... 12 68 6. Security Considerations ..................................... 12 69 7. IANA Considerations ......................................... 13 70 8. Acknowledgements ............................................ 13 71 9. Change Log [RFC Editor please remove] ....................... 13 72 10. References ................................................. 13 73 10.1. Normative References .................................. 13 74 10.2. Informative References ................................ 14 75 Author's Addresses ............................................. 16 77 1. Introduction 79 IPv6 site renumbering is considered difficult. Network managers 80 currently prefer to Provider Independent (PI) addressing for IPv6 to 81 attempt to minimize the need for future renumbering. However, 82 widespread use of PI may create very serious BGP4 scaling problems. 83 It is thus desirable to develop tools and practices that may make 84 renumbering a simpler process to reduce demand for IPv6 PI space. In 85 any case, renumbering may be necessary for other reasons. 87 This document undertakes scenario descriptions, including 88 documentation of current capabilities and existing BCPs, for 89 enterprise networks. It takes the analysis conclusions from [RFC5887] 90 and other relevant documents as the primary input. 92 This document focuses on IPv6 only, by leaving IPv4 out of scope. 93 Dual-stack network or IPv4/IPv6 transition scenarios are out of scope, 94 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. A gap inventory is 106 listed at the end of this document. 108 2. Enterprise Network Illustration for Renumbering 110 An Enterprise Network as defined in [RFC4057] is: a network that has 111 multiple internal links, one or more router connections to one or 112 more Providers, and is actively managed by a network operations 113 entity. 115 The enterprise network architecture is illustrated in the figure 116 below. Those entities relevant to renumbering are highlighted. 118 Address reconfiguration is fulfilled either by DHCPv6 or ND 119 protocols. Static address assignment is not considered in this 120 version. During the renumbering event, the DNS records need to be 121 synchronized while routing tables, ACLs and IP filtering tables in 122 various gateways also need to be updated, too. 124 Uplink 1 Uplink 2 125 | | 126 +---+---+ +---+---+ 127 +---- |Gateway| --------- |Gateway| -----+ 128 | +-------+ +-------+ | 129 | Enterprise Network | 130 | +------+ +------+ +------+ | 131 | | APP | |DHCPv6| | DNS | | 132 | |Server| |Server| +Server+ | 133 | +---+--+ +---+--+ +--+---+ | 134 | | | | | 135 | ---+--+---------+------+---+- | 136 | | | | 137 | +--+---+ +---+--+ | 138 | |Router| |Router| | 139 | +--+---+ +---+--+ | 140 | | | | 141 | -+---+----+-------+---+--+- | 142 | | | | | | 143 | +-+--+ +--+-+ +--+-+ +-+--+ | 144 | |Host| |Host| |Host| |Host| | 145 | +----+ +----+ +----+ +----+ | 146 +----------------------------------------+ 147 Figure 1 Enterprise network illustration 149 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 150 stack in which a logical IPv6 plane is independent from IPv4. The 151 complicated IPv4/IPv6 co-existence scenarios are out of scope. 153 This document focuses on the unicast addresses; site-local, link- 154 local, multicast and anycast addresses are out of scope. 156 3. Enterprise Network Renumbering Scenario Categories 158 In this section, we divide enterprise network renumbering scenarios 159 into two categories defined by external and internal network factors, 160 which require renumbering for different reasons. 162 3.1. Renumbering caused by External Network Factors 164 The most influential external network factor is the uplink ISP. 166 o The enterprise network switches to a new ISP. Of course, the 167 prefixes received from different ISPs are different. This is the 168 most common scenario. 170 Whether there is an overlap time between the old and new ISPs 171 would also influence the possibility whether the enterprise can 172 fulfill renumbering without a flag day [RFC4192]. 174 o The renumbering event may be initiated by receiving new prefixes 175 from the same uplink. The typical scenario is that the DHCPv6 176 server in the ISP delegates a new prefix to the enterprise network. 177 This might happen if the enterprise network is switched to a 178 different location within the network topology of the same ISP due 179 to various considerations, such as commercial, performance or 180 services reasons, etc. Alternatively, the ISP itself might be 181 renumbered due to topology changes or migration to a different or 182 additional prefix. These ISP renumbering events would initiate 183 enterprise network renumbering events, of course. 185 o The enterprise network adds new uplink(s) for multihoming 186 purposes. This may not a typical renumbering because the original 187 addresses will not be changed. However, initial numbering may be 188 considered as a special renumbering event. If the administrators 189 only want part of the network to have multiple prefixes, the 190 renumbering process should be carefully managed. 192 o The enterprise network removes uplink(s) or old prefixes. 194 3.2. Renumbering caused by Internal Network Factors 196 o As companies split, merge, grow, relocate or reorganize, the 197 enterprise network architectures may need to be re-built. This 198 will trigger the internal renumbering. 200 o The enterprise network may proactively adopt a new address scheme, 201 for example by switching to a new transition mechanism or stage of 202 a transition plan. 204 o The enterprise network may reorganize its topology or subnets. 206 4. Network Renumbering Considerations and Best Current Practices 208 In order to carry out renumbering in an enterprise network, 209 systematic planning and administrative preparation are needed. 210 Carefully planning and preparation could make the renumbering process 211 smoother. 213 This section tries to give the recommended solutions or strategies 214 for the enterprise renumbering, chosen among existing mechanisms. 215 There are known gaps analyzed by [I-D.liu-6renum-gap-analysis]. If 216 these gaps are filled in the future, the enterprise renumbering may 217 be processed more automatically, with fewer issues. 219 4.1. Considerations and Best Current Practices during Network Design 221 This section describes the consideration or issues relevant to 222 renumbering that a network architect should carefully plan when 223 building or designing a new network. 225 - Prefix Delegation 227 In a large or a multi-site enterprise network, the prefix should 228 be carefully managed, particularly during renumbering events. 229 Prefix information needs to be delegated from router to router. 230 The DHCPv6 Prefix Delegation options [RFC3633, I-D.ietf-dhc-pd- 231 exclude] provide a mechanism for automated delegation of IPv6 232 prefixes. DHCPv6 PD options may also be used between the 233 enterprise routers and their upstream ISPs. 235 - Usage of FQDN 237 It is recommended that Fully-Qualified Domain Names (FQDNs) should 238 be used to configure network connectivity, such as tunnels, 239 whenever possible. The capability to use FQDNs as endpoint names 240 has been standardized in several RFCs, such as [RFC5996], although 241 many system/network administrators do not realize that it is there 242 and works well as a way to avoid manual modification during 243 renumbering. 245 Service Location Protocol [RFC2608] and multicast DNS with SRV 246 records for service discovery can reduce the number of places that 247 IP addresses need to be configured. 249 - Address Types 251 This document focuses on the dynamically-configured global unicast 252 addresses in enterprise networks. They are the targets of 253 renumbering events. 255 Manual-configured addresses are not scalable in medium to large 256 sites, hence are out of scope. However, some hosts such as servers 257 may need static addresses. Manual-configured addresses/hosts 258 should be avoided as much as possible. 260 Unique Local Addresses (ULA, [RFC4193]) may be used for local 261 communications, usually inside of enterprise networks. They can be 262 sufficient for any host that is accessible only inside the 263 enterprise network and has no need for external communication 264 [RFC4864]. Normally, they do not need to be changed during a 265 global prefix renumbering event. However, they may need to be 266 renumbered in some rare scenarios, quite separate from the global 267 prefix renumbering. 269 - Address configuration models 271 In IPv6 networks, there are two auto-configuration models for 272 address assignment: Stateless Address Auto-Configuration (SLAAC) 273 by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful 274 address configuration by Dynamic Host Configuration Protocol for 275 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 276 support host-generated address model by assigning a prefix through 277 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 279 ND is considered easier to renumber by broadcasting a Router 280 Advertisement message with a new prefix. DHCPv6 can also trigger 281 the renumbering process by sending unicast RECONFIGURE messages, 282 though it may cause a large number of interactions between hosts 283 and DHCPv6 server. 285 In principle, an enterprise network should choose only one address 286 configuration model and employ either ND or DHCPv6. This document 287 has no preference between ND and DHCPv6 address configuration 288 models. It is network architects' job to decide which 289 configuration model is employed. Even in a large network that 290 contains several subnets, it is better not to mix the two address 291 configuration models, though using them independently in different 292 subnets may partly reduce the risk. 294 However, since DHCPv6 is also used to configure many other network 295 parameters, there are ND and DHCPv6 co-existence scenarios. 296 Combinations of address configuration models may coexist within a 297 single enterprise network. [I-D.ietf-savi-mix] provides 298 recommendations to avoid collisions and to review collision 299 handling in such scenarios. 301 - DNS 303 It is recommended that the site have an automatic and systematic 304 procedure for updating/synchronising its DNS records, including 305 both forward and reverse mapping [RFC2874]. A manual on-demand 306 updating model is considered as a harmful source of problems in a 307 renumbering event. 309 Although the A6 DNS record model [RFC2874] was designed for easier 310 renumbering, it has a lot of unsolved technical issues [RFC3364, 311 I-D.jiang-dnsext-a6-to-historic]. Therefore, it has been moved to 312 experimental status [RFC3363]. It is not recommended. 314 In order to simplify the operation procedure, the network 315 architect should combine the forward and reverse DNS updates in a 316 single procedure. 318 Often, a small site depends on its ISP's DNS system rather than 319 maintaining its own. When renumbering, this requires 320 administrative coordination between the site and its ISP. 322 The DNS synchronization may be completed through the Secure DNS 323 Dynamic Update [RFC3007]. Alternatively, a DHCPv6 server could 324 update host DNS records following the operations defined by 325 [RFC4704]. In a model including SLAAC, host addresses may be 326 registered on an address registration server, which could in fact 327 be a DHCPv6 server; then the server would update corresponding DNS 328 records. 330 - Security 332 Any automatic renumbering scheme has a potential exposure to 333 hijacking at the moment that a new address is announced. Proper 334 network security mechanisms should be employed. Secure Neighbor 335 Discovery (SEND, [RFC3971]), which is not widely deployed, is 336 recommended to replace ND if this is considered to be a serious 337 threat. DHCPv6 built-in secure mechanisms, like Secure DHCPv6 [I- 338 D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 339 [RFC3315] are recommended. 341 - Miscellaneous 343 A site or network should also avoid embedding addresses from other 344 sites or networks in its own configuration data. Instead, the 345 Fully-Qualified Domain Names should be used. Thus, these 346 connectivities can survive after renumbering events at other sites. 347 This also applies to host-based connectivities. 349 4.2. Considerations and Best Current Practices for the Preparation of 350 Renumbering 352 It is not possible to reduce a prefix's lifetime to below two hours. 353 So, renumbering should not be an unplanned sudden event. This issue 354 could only be avoided by early planning and preparation. 356 This section describes several recommendations for the preparation of 357 enterprise renumbering event. By adopting these recommendations, a 358 site could be renumbered more easily. However, these recommendations 359 are not cost free. They might increase the daily burden of network 360 operation. Therefore, only those networks that are expected to be 361 renumbered soon or very frequently should adopt these recommendations, 362 with balanced consideration between daily cost and renumbering cost. 364 - Reduce the address preferred time or valid time or both. 366 Long-lifetime addresses may cause issues for renumbering events. 367 Particularly, some offline hosts may reconnect using these 368 addresses after renumbering events. Shorter preferred lifetimes 369 with relatively long valid lifetimes may allow short transition 370 periods for renumbering events and avoid frequent address 371 renewals. 373 - Reduce the DNS record TTL on the local DNS server. 375 The DNS AAAA resource record TTL on the local DNS server should be 376 manipulated to ensure that stale addresses are not cached. 378 - Reduce the DNS configuration lifetime on the hosts. 380 Since the DNS server could be renumbered as well, the DNS 381 configuration lifetime on the hosts should also be reduced if 382 renumbering events are expected. The DNS configuration can be done 383 through either ND [RFC6106] or DHCPv6 [RFC3646]. 385 - Identify long-living sessions 387 Any applications which maintain very long transport connections 388 (hours or days) should be identified in advance, if possible. Such 389 applications will need special handling during renumbering, so it 390 is important to know that they exist. 392 4.3. Considerations and Best Current Practices during Renumbering 393 Operation 395 Renumbering events are not instantaneous events. Normally, there is a 396 transition period, in which both the old prefix and the new prefix 397 are used in the site. Better network design and management, better 398 pre-preparation and longer transition period are helpful to reduce 399 the issues during renumbering operation. 401 - Within/without a flag day 403 As is described in [RFC4192], "a 'flag day' is a procedure in 404 which the network, or a part of it, is changed during a planned 405 outage, or suddenly, causing an outage while the network 406 recovers." 408 If renumbering event is processed within a flag day, the network 409 service/connectivity will be out for a period till the renumbering 410 event is completed. It is efficient and provides convenience for 411 network operation and management. But network outage is usually 412 unacceptable for end users and enterprises. A renumbering 413 procedure without a flag day provides smooth address switching, 414 but much more operational complexity and difficulty is introduced. 416 - Transition period 418 If renumbering transition period is longer than all address 419 lifetimes, after which the address leases expire, each host will 420 automatically pick up its new IP address. In this case, it would 421 be the DHCPv6 server or Router Advertisement itself that 422 automatically accomplishes client renumbering. 424 Address deprecation should be associated with the deprecation of 425 associated DNS records. The DNS records should be deprecated as 426 early as possible, before the addresses themselves. 428 - Network initiative enforced renumbering 430 If the network has to enforce renumbering before address leases 431 expire, the network should initiate enforcement messages, either 432 in Router Advertisement messages or DHCPv6 RECONFIGURE messages. 434 - Impact to branch/main sites 436 Renumbering in main/branch site may cause impact on branch/main 437 site communication. The routes, ingress filtering of site's 438 gateways, and DNS may need to be updated. This needs careful 439 planning and organizing. 441 - DNS record update and DNS configuration on hosts 443 DNS records on the local DNS server should be updated if hosts are 444 renumbered. If the site depends on ISP's DNS system, it should 445 report the new host's DNS records to its ISP. During the 446 transition period, both old and new DNS records are valid. If the 447 TTL of DNS records is shorter than the transition period, an 448 administrative operation may not be necessary. 450 DNS configuration on hosts should be updated if local recursive 451 DNS servers are renumbered. During the transition period, both old 452 and new DNS server addresses may co-exist on the hosts. If the 453 lifetime of DNS configuration is shorter than the transition 454 period, name resolving failure may be reduced to minimum. A 455 notification mechanism may be needed to indicate to the hosts that 456 a renumbering event of local recursive DNS happens or is going to 457 take place. 459 - Router awareness 461 In a site with multiple border routers, all border routers should 462 be aware of partial renumbering in order to correctly handle 463 inbound packets. Internal forwarding tables need to be updated. 465 - Border filtering 467 In a multihomed site, an egress router to ISP A could normally 468 filter packets with source addresses from other ISPs. The egress 469 router connecting to ISP A should be notified if the egress router 470 connecting to ISP B initiates a renumbering event in order to 471 properly update its filter function. 473 - Tunnel concentrator renumbering 475 A tunnel concentrator itself might be renumbered. This change 476 should be reconfigured in relevant hosts or routers, unless the 477 configuration of tunnel concentrator was based on FQDN. 479 - Connectivity session survivability 481 During the renumbering operations, connectivity sessions in IP 482 layer would break if the old address is deprecated before the 483 session ends. However, the upper layer sessions may survive by 484 using session survivability technologies, such as SHIM6 [RFC5533]. 486 As mentioned above, some long-living applications may need to be 487 handled specially. 489 5. Gap Inventory 491 This section lists a few issues that still appear to remain 492 unsolvable (also see [I-D.liu-6renum-gap-analysis]). Some of them may 493 be inherently unsolvable. 495 - Some environments like embedded systems might not use DHCPv6 or 496 SLAAC and even configuration scripts might not be an option. 497 This creates special problems that no general-purpose solution 498 is likely to address. 500 - TCP and UDP flows can't survive a renumbering event at either 501 end. 503 - The embedding of IPv6 unicast addresses into multicast 504 addresses and the embedded-RP (Rendezvous Point) [RFC3956] will 505 cause issues when renumbering. 507 - Changing the unicast source address of a multicast sender might 508 also be an issue for receivers. 510 - When a renumbering event takes place, entries in the state 511 table of tunnel concentrator that happen to contain the old 512 addresses will become invalid and will eventually time out. 513 However, this can be considered as harmless though it takes 514 resources on these devices for a while. 516 - A site that is listed in an IP black list can escape that list 517 by renumbering itself. The site itself of course will not 518 report its renumbering and the black list may not be able to 519 monitor or discover the renumbering event. 521 - Multihomed sites, using SLAAC for one address prefix and DHCPv6 522 for another, would clearly create a risk of inconsistent host 523 behaviour and operational confusion. 525 6. Security Considerations 527 As noted, a site that is listed by IP address in a black list can 528 escape that list by renumbering itself. 530 Any automatic renumbering scheme has a potential exposure to 531 hijacking at the moment that a new address is announced. Proper 532 network security mechanisms should be employed. SEND is recommended 533 to replace ND. Alternatively, certain lightweight renumbering 534 specific security mechanism may be developed in the future. DHCPv6 535 build-in secure mechanisms, like Secure DHCPv6 536 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 537 [RFC3315] are recommended. 539 The security configuration updates will need to be made in two stages 540 (immediately before and immediately after the event). 542 7. IANA Considerations 544 This draft does not request any IANA action. 546 8. Acknowledgements 548 This work is illuminated by RFC5887, so thank for RFC 5887 authors, 549 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 550 in by documents from Tim Chown and Fred Baker. The authors also want 551 to thank Wesley George, Olivier Bonaventure and other 6renum members 552 for valuable comments. 554 9. Change Log [RFC Editor please remove] 556 draft-jiang-6renum-enterprise-00, original version, 2011-07-01 558 draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail 559 list discussions, 2011-10-09 561 10. References 563 10.1. Normative References 565 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 566 Location Protocol, Version 2", RFC 2608, June 1999. 568 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 569 Update", RFC 3007, November 2000. 571 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 572 M. Carney, "Dynamic Host Configuration Protocol for IPv6 573 (DHCPv6)", RFC 3315, July 2003. 575 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 576 Host Configuration Protocol (DHCP) version 6", RFC 3633, 577 December 2003. 579 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 580 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 581 December 2003. 583 [RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous 584 Point (RP) Address in an IPv6 Multicast Address", RFC 3956, 585 November 2004 587 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 588 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 590 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 591 Addresses", RFC 4193, October 2005. 593 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 594 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 595 RFC 4706, October 2006. 597 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 598 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 599 September 2007. 601 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 602 Address Autoconfiguration", RFC 4862, September 2007. 604 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 605 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 606 September 2010. 608 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 609 "IPv6 Router Advertisement Option for DNS Configuration", 610 RFC 6106, November 2011. 612 10.2. Informative References 614 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 615 IPv6 Address Aggregation and Renumbering", RFC 2874, July 616 2000. 618 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 619 "Representing Internet Protocol version 6 (IPv6) Addresses 620 in the Domain Name System (DNS)", RFC 3363, August 2002. 622 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 623 for Internet Protocol version 6 (IPv6)", RFC 3364, August 624 2002. 626 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 627 4057, June 2005. 629 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 630 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 631 September 2005. 633 [RFC4864] Van de Velde, G., T. Hain, R. Droms, B. Carpenter, E. Klein, 634 Local Network Protection for IPv6", RFC 4864, May 2007. 636 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 637 Shim Protocol for IPv6", RFC 5533, June 2009. 639 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 640 Still Needs Work", RFC 5887, May 2010. 642 [I-D.ietf-dhc-secure-dhcpv6] 643 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 644 in progress. 646 [I-D.ietf-dhc-host-gen-id] 647 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 648 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 649 April, 2011. 651 [I-D.ietf-savi-mix] 652 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 653 for Mixed Address Assignment Methods Scenario", working in 654 progress. 656 [I-D.ietf-dhc-pd-exclude] 657 J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 658 Exclude Option for DHCPv6-based Prefix Delegation", working 659 in progress. 661 [I-D.liu-6renum-gap-analysis] 662 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 663 Analysis", working in progress. 665 [I-D.jiang-dnsext-a6-to-historic] 666 Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 667 Historic Status", working in progress. 669 Author's Addresses 671 Sheng Jiang 672 Huawei Technologies Co., Ltd 673 Huawei Building, No.3 Xinxi Rd., 674 Shang-Di Information Industry Base, Hai-Dian District, Beijing 675 P.R. China 676 EMail: jiangsheng@huawei.com 678 Bing Liu 679 Huawei Technologies Co., Ltd 680 Huawei Building, No.3 Xinxi Rd., 681 Shang-Di Information Industry Base, Hai-Dian District, Beijing 682 P.R. China 683 EMail: leo.liubing@huawei.com 685 Brian Carpenter 686 Department of Computer Science 687 University of Auckland 688 PB 92019 689 Auckland, 1142 690 New Zealand 691 EMail: brian.e.carpenter@gmail.com