idnits 2.17.1 draft-ietf-6renum-enterprise-04.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 == Line 568 has weird spacing: '... system since...' -- The document date (November 28, 2012) is 4166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3363' is defined on line 640, 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) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 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: May 27, 2013 B. Carpenter 5 University of Auckland 6 November 28, 2012 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-ietf-6renum-enterprise-04.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 May 27, 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 events that cause renumbering and describes 46 the best renumbering practice. Best practices are described in three 47 categories: those applicable during network design, those applicable 48 during preparation for renumbering, and those applicable during the 49 renumbering operation. 51 Table of Contents 53 1. Introduction ................................................. 3 54 2. Enterprise Network Illustration for Renumbering .............. 3 55 3. Enterprise Network Renumbering Scenario Categories ........... 4 56 3.1. Renumbering Caused by External Network Factors........... 4 57 3.2. Renumbering caused by Internal Network Factors........... 5 58 4. Network Renumbering Considerations and Best Current Practices. 5 59 4.1. Considerations and Best Current Practices during Network 60 Design ....................................................... 6 61 4.2. Considerations and Best Current Practices for the Preparation 62 of Renumbering .............................................. 10 63 4.3. Considerations and Best Current Practices during Renumbering 64 Operation ................................................... 11 65 5. Security Considerations ..................................... 13 66 6. IANA Considerations ......................................... 13 67 7. Acknowledgements ............................................ 13 68 8. References .................................................. 13 69 8.1. Normative References ................................... 13 70 8.2. Informative References ................................. 15 71 Author's Addresses ............................................. 17 73 1. Introduction 75 Site renumbering is difficult. Network managers frequently attempt to 76 avoid renumbering by numbering their network resources from Provider 77 Independent (PI) address space. However, widespread use of PI might 78 create serious BGP4 scaling problems and according to Regional 79 Internet Registry (RIR) policies, PI space is not always available 80 for enterprises Therefore, it is desirable to develop mechanisms that 81 simplify IPv6 renumbering. 83 This document undertakes scenario descriptions, including 84 documentation of current capabilities and existing BCPs, for 85 enterprise networks. It takes [RFC5887] and other relevant documents 86 as the primary input. 88 Since the IPv4 and IPv6 are logically separated from the perspective 89 of renumbering, regardless of overlapping of the IPv4/IPv6 networks 90 or devices, this document focuses on IPv6 only, by leaving IPv4 out 91 of scope. Dual-stack network or IPv4/IPv6 transition scenarios are 92 out of scope, too. 94 This document focuses on enterprise network renumbering, however, 95 most of the analysis is also applicable to ISP network renumbering. 96 Renumbering in home networks is out of scope, but it can also benefit 97 from the analysis in this document. 99 The concept of enterprise network and a typical network illustration 100 are introduced first. Then, best renumbering practices are introduced 101 according to the following categories: those applicable during 102 network design, those applicable during preparation for renumbering, 103 and those applicable during the renumbering operation. 105 2. Enterprise Network Illustration for Renumbering 107 An Enterprise Network as defined in [RFC4057] is: a network that has 108 multiple internal links, one or more router connections to one or 109 more Providers, and is actively managed by a network operations 110 entity. 112 Figure 1 provides a sample enterprise network architecture. Those 113 entities relevant to renumbering are highlighted. 115 Address reconfiguration is fulfilled either by Dynamic Host 116 configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for 117 IPv6 (ND) protocols. During the renumbering event, the Domain Name 118 Service (DNS) records need to be synchronized while routing tables, 119 Access Control Lists (ACLs) and IP filtering tables in various 120 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. 152 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 following ISP uplink-related events can cause renumbering: 167 o The enterprise network switches to a new ISP. When this occurs, 168 the enterprise stop numbering its resources form the prefix 169 allocated by the old ISP and renumbers its resources from the 170 prefix allocated by the new ISP. 172 When the enterprise switches ISPs, a "flag day" renumbering event 173 [RFC4192] may be averted if, during a transitional period, the 174 enterprise network may number its resources from either prefix. 175 One way to facilitate such a transitional period is for the 176 enterprise to contract for service from both ISPs during the 177 transition. 179 o The renumbering event can be initiated by receiving new prefixes 180 from the same uplink. This might happen if the enterprise network 181 is switched to a different location within the network topology of 182 the same ISP due to various considerations, such as commercial, 183 performance or services reasons, etc. Alternatively, the ISP 184 itself might be renumbered due to topology changes or migration to 185 a different or additional prefix. These ISP renumbering events 186 would initiate enterprise network renumbering events, of course. 188 o The enterprise network adds new uplink(s) for multihoming purposes. 189 This might not be a typical renumbering case because the original 190 addresses will not be changed. However, initial numbering may be 191 considered as a special renumbering event. The enterprise network 192 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 might need to be re-built. This 198 will trigger the internal renumbering. 200 o The enterprise network might proactively adopt a new address 201 scheme, for example by switching to a new transition mechanism or 202 stage of a transition plan. 204 o The enterprise network might 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 recommends some solutions or strategies for the 214 enterprise renumbering, chosen among existing mechanisms. There are 215 known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps 216 are filled in the future, the enterprise renumbering can be processed 217 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] and 231 [RFC6603] provide a mechanism for automated delegation of IPv6 232 prefixes. Normally, DHCPv6 PD options are used between the 233 internal enterprise routers, for example, a router receives 234 prefix (es) from its upstream router (might be a border gateway or 235 edge router .etc) through DHCPv6 PD options and then advertise it 236 (them) to the local hosts through RA messages. 238 - Usage of FQDN 240 In general, Fully-Qualified Domain Names (FQDNs) are recommended 241 to be used to configure network connectivity, such as tunnels, 242 servers etc. The capability to use FQDNs as endpoint names has 243 been standardized in several RFCs, such as [RFC5996], although 244 many system/network administrators do not realize that it is there 245 and works well as a way to avoid manual modification during 246 renumbering. 248 Note that, using FQDN would rely on DNS systems. For a link local 249 network that does not have a DNS system, multicast DNS 250 [I-D.cheshire-dnsext-multicastdns] could be utilized. For some 251 specific circumstances, using FQDN might not be proper if adding 252 DNS service in the node/network would cause un-desired complexity 253 or issues. 255 Service discovery protocols such as Service Location Protocol 256 [RFC2608], multicast DNS with SRV records and DNS Service 257 Discovery [I-D.cheshire-dnsext-dns-sd] can engage using FQDN and 258 reduce the number of places that IP addresses need to be 259 configured. But it should be noted that these protocols are 260 normally used link-local only. 262 - Usage of ULA 264 Unique Local Addresses (ULAs) are defined in [RFC4193] as 265 provider-independent prefixes. And since there is a 40 bits pseudo 266 random field in the ULA prefix, there is no practical risk of 267 collision (please refer to section 3.2.3 in [RFC4193] for more 268 detail). For enterprise networks, using ULA along with PA can 269 provide a logically local routing plane separated from the 270 globally routing plane. The benefit is to ensure stable and 271 specific local communication regardless of the ISP uplink failure. 272 This benefit is especially meaningful for renumbering. It mainly 273 includes three use cases as the following. 275 During the transition period, it is desirable to isolate local 276 communication changes in the global routing plane. If we use ULA 277 for the local communication, this isolation is achieved. 279 Enterprise administrators might want to avoid the need to renumber 280 their internal-only, private nodes when they have to renumber the 281 PA addresses of the whole network because of changing ISPs, ISPs 282 restructuring their address allocation, or any other reasons. In 283 these situations, ULA is an effective tool for the internal-only 284 nodes. 286 For multicast, ULA can be a way of avoiding renumbering from 287 having an impact on multicast. In most deployments multicast is 288 only used internally (intra-domain), and the addresses used for 289 multicast sources and Rendezvous-Points need not be reachable nor 290 routable externally. Hence one may at least internally make use of 291 ULA for multicast specific infrastructure. 293 - Address Types 295 This document focuses on the dynamically-configured global unicast 296 addresses in enterprise networks. They are the targets of 297 renumbering events. 299 Manual-configured addresses are not scalable in medium to large 300 sites, hence are out of scope. Manually-configured addresses/hosts 301 should be avoided as much as possible. 303 - Address configuration models 304 In IPv6 networks, there are two auto-configuration models for 305 address assignment: Stateless Address Auto-Configuration (SLAAC, 306 [RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful 307 address configuration by Dynamic Host Configuration Protocol for 308 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 309 support host-generated address model by assigning a prefix through 310 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 312 ND is considered easier to renumber by broadcasting a Router 313 Advertisement message with a new prefix. DHCPv6 can also trigger 314 the renumbering process by sending unicast RECONFIGURE messages, 315 though it might cause a large number of interactions between hosts 316 and DHCPv6 server. 318 This document has no preference between ND and DHCPv6 address 319 configuration models. It is network architects' job to decide 320 which configuration model is employed. But it should be noticed 321 that using DHCPv6 and ND together within one network, especially 322 in one subnet, might cause operational issues. For example, some 323 hosts use DHCPv6 as the default configuration model while some use 324 ND. Then the hosts' address configuration model depends on the 325 policies of operating systems and cannot be controlled by the 326 network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses 327 more details on this topic. So, in general, this document 328 recommends using DHCPv6/SLAAC independently in different subnets. 330 However, since DHCPv6 is also used to configure many other network 331 parameters, there are ND and DHCPv6 co-existence scenarios. 332 Combinations of address configuration models might coexist within 333 a single enterprise network. [I-D.ietf-savi-mix] provides 334 recommendations to avoid collisions and to review collision 335 handling in such scenarios. 337 - DNS 339 It is recommended that the site have an automatic and systematic 340 procedure for updating/synchronizing its DNS records, including 341 both forward and reverse mapping [RFC2874]. A manual on-demand 342 updating model does not scale, and increases the chance of errors. 344 Although the A6 DNS record model [RFC2874] was designed for easier 345 renumbering, it left many unsolved technical issues [RFC3364]. 346 Therefore, it has been moved to historic status [RFC6563] and is 347 not recommended. 349 In order to simplify the operational procedure, the network 350 architect should combine the forward and reverse DNS updates in a 351 single procedure. 353 Often, a small site depends on its ISP's DNS system rather than 354 maintaining its own. When renumbering, this requires 355 administrative coordination between the site and its ISP. 357 The DNS synchronization can be completed through the Secure DNS 358 Dynamic Update [RFC3007]. Dynamic DNS update can be provided by 359 the DHCPv6 client or by the server on behalf of individual hosts. 360 [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and 361 servers to exchange information about the client's FQDN and about 362 who has the responsibility for updating the DNS with the 363 associated AAAA and PTR (Pointer Record) RRs (Resource Records). 364 For example, if a client wants the server to update the FQDN- 365 address mapping in the DNS server, it can include the Client FQDN 366 option with proper settings in the SOLICIT with Rapid Commit, 367 REQUEST, RENEW, and REBIND message originated by the client. When 368 DHCPv6 server gets this option, it can use the dynamic DNS update 369 on behalf of the client. In this document, we promote to support 370 this FQDN option. But since it's a DHCPv6 option, it implies that 371 only the DHCP-managed networks are suitable for this operation. In 372 SLAAC mode, sometimes hosts also need to register addresses on a 373 registration server, which could in fact be a DHCPv6 server (as 374 described in [I-D.ietf-dhc-addr-registration]); then the server 375 would update corresponding DNS records. 377 - Security 379 Any automatic renumbering scheme has a potential exposure to 380 hijacking. Malicious entity in the network can forge prefixes to 381 renumber the hosts. So proper network security mechanisms are 382 needed. 384 For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible 385 solution, but it is complex and there's almost no real deployment 386 so far. Comparing the non-trivial deployment of SEND, RA guard 387 [RFC6105] is a light-weight alternative, which focuses on rogue 388 router advertisements proof in a L2 network. However, it also 389 hasn't been widely deployed since it hasn't been published for 390 long. 392 For DHCPv6, there are built-in secure mechanisms (like Secure 393 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 394 messages [RFC3315] could be utilized. But these security 395 mechanisms also haven't been verified by wide real deployment. 397 - Miscellaneous 399 A site or network should also avoid embedding addresses from other 400 sites or networks in its own configuration data. Instead, the 401 Fully-Qualified Domain Names should be used. Thus, these 402 connections can survive after renumbering events at other sites. 403 This also applies to host-based connectivity. 405 4.2. Considerations and Best Current Practices for the Preparation of 406 Renumbering 408 In ND, it is not possible to reduce a prefix's lifetime to below two 409 hours. So, renumbering should not be an unplanned sudden event. This 410 issue could only be avoided by early planning and preparation. 412 This section describes several recommendations for the preparation of 413 enterprise renumbering event. By adopting these recommendations, a 414 site could be renumbered more easily. However, these recommendations 415 might increase the daily traffic, server load, or burden of network 416 operation. Therefore, only those networks that are expected to be 417 renumbered soon or very frequently should adopt these recommendations, 418 with balanced consideration between daily cost and renumbering cost. 420 - Reduce the address preferred time or valid time or both. 422 Long-lifetime addresses might cause issues for renumbering events. 423 Particularly, some offline hosts might reconnect using these 424 addresses after renumbering events. Shorter preferred lifetimes 425 with relatively long valid lifetimes may allow short transition 426 periods for renumbering events and avoid frequent address renewals. 428 - Reduce the DNS record TTL on the local DNS server. 430 The DNS AAAA resource record TTL on the local DNS server should be 431 manipulated to ensure that stale addresses are not cached. 433 Recent research [BA2011] [JSBM2002] indicates that it is both 434 practical and reasonable for A, AAAA, and PTR records that belong 435 to leaf nodes of the DNS (i.e. not including the DNS root or DNS 436 top-level domains) to be configured with very short DNS TTL values, 437 not only during renumbering events, but also for longer-term 438 operation. 440 - Reduce the DNS configuration lifetime on the hosts. 442 Since the DNS server could be renumbered as well, the DNS 443 configuration lifetime on the hosts should also be reduced if 444 renumbering events are expected. In ND, The DNS configuration can 445 be done through reducing the lifetime value in RDNSS option 446 [RFC6106]. In DHCPv6, the DNS configuration option specified in 447 [RFC3646] doesn't provide lifetime attribute, but we can reduce 448 the DHCPv6 client lease time to achieve similar effect. 450 - Identify long-living sessions 452 Any applications which maintain very long transport connections 453 (hours or days) should be identified in advance, if possible. Such 454 applications will need special handling during renumbering, so it 455 is important to know that they exist. 457 4.3. Considerations and Best Current Practices during Renumbering 458 Operation 460 Renumbering events are not instantaneous events. Normally, there is a 461 transition period, in which both the old prefix and the new prefix 462 are used in the site. Better network design and management, better 463 pre-preparation and longer transition period are helpful to reduce 464 the issues during renumbering operation. 466 - Within/without a flag day 468 As is described in [RFC4192], "a 'flag day' is a procedure in 469 which the network, or a part of it, is changed during a planned 470 outage, or suddenly, causing an outage while the network 471 recovers." 473 If renumbering event is processed within a flag day, the network 474 service/connectivity will be unavailable for a period until the 475 renumbering event is completed. It is efficient and provides 476 convenience for network operation and management. But network 477 outage is usually unacceptable for end users and enterprises. A 478 renumbering procedure without a flag day provides smooth address 479 switching, but much more operational complexity and difficulty is 480 introduced. 482 - Transition period 484 If renumbering transition period is longer than all address 485 lifetimes, after which the address leases expire, each host will 486 automatically pick up its new IP address. In this case, it would 487 be the DHCPv6 server or Router Advertisement itself that 488 automatically accomplishes client renumbering. 490 Address deprecation should be associated with the deprecation of 491 associated DNS records. The DNS records should be deprecated as 492 early as possible, before the addresses themselves. 494 - Network initiative enforced renumbering 496 If the network has to enforce renumbering before address leases 497 expire, the network should initiate DHCPv6 RECONFIGURE messages. 498 For some operating systems such as Windows 7, if the hosts receive 499 RA messages with ManagedFlag=0, they'll release the DHCPv6 500 addresses and do SLAAC according to the prefix information in the 501 RA messages, so this could be another enforcement method for some 502 specific scenarios. 504 - Impact to branch/main sites 506 Renumbering in main/branch site might cause impact on branch/main 507 site communication. The routes, ingress filtering of site's 508 gateways, and DNS might need to be updated. This needs careful 509 planning and organizing. 511 - DNS record update and DNS configuration on hosts 513 DNS records on the local DNS server should be updated if hosts are 514 renumbered. If the site depends on ISP's DNS system, it should 515 report the new host's DNS records to its ISP. During the 516 transition period, both old and new DNS records are valid. If the 517 TTLs of DNS records are shorter than the transition period, an 518 administrative operation might not be necessary. 520 DNS configuration on hosts should be updated if local recursive 521 DNS servers are renumbered. During the transition period, both old 522 and new DNS server addresses might co-exist on the hosts. If the 523 lifetime of DNS configuration is shorter than the transition 524 period, name resolving failure may be reduced to minimum. 526 - Tunnel concentrator renumbering 528 A tunnel concentrator itself might be renumbered. This change 529 should be reconfigured in relevant hosts or routers, unless the 530 configuration of tunnel concentrator was based on FQDN. 532 For IPSec, [RFC2230] defines the KX (Key eXchange) record, which 533 could be used to help locate the domain-name for an IPsec VPN 534 concentrator associated with a site's domain name. For current 535 practice, the community needs to change its bad habit of using 536 IPsec in an address-oriented way, and renumbering is one of the 537 main reasons for that. 539 - Connectivity session survivability 541 During the renumbering operations, connectivity sessions in IP 542 layer would break if the old address is deprecated before the 543 session ends. However, the upper layer sessions can survive by 544 using session survivability technologies, such as SHIM6 [RFC5533]. 545 As mentioned above, some long-living applications may need to be 546 handled specially. 548 5. Security Considerations 550 As noted, a site that is listed by IP address in a black list can 551 escape that list by renumbering itself. 553 Any automatic renumbering scheme has a potential exposure to 554 hijacking. Proper network security mechanisms are needed. Although 555 there are some existing security mechanisms such as SEND, RA guard, 556 secure DHCPv6 etc., they haven't been widely deployed and haven't 557 been verified whether they are not bringing too much operational 558 complexity and cost. 560 Dynamic DNS update might bring risk of DoS attack to the DNS server. 561 So along with the update authentication, session filtering/limitation 562 might also be needed. 564 The "make-before-break" approach of [RFC4192] requires the routers 565 keep advertising the old prefixes for some time. But if the ISP 566 changes the prefixes very frequently, the co-existence of old and new 567 prefixes might cause potential risk to the enterprise routing 568 system since the old address relevant route path might already 569 invalid and the routing system just doesn't know it. However, 570 normally enterprise scenarios don't involve the extreme situation. 572 6. IANA Considerations 574 This draft does not request any IANA action. 576 7. Acknowledgements 578 This work is illuminated by RFC5887, so thank for RFC 5887 authors, 579 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 580 in by documents from Tim Chown and Fred Baker. The authors also want 581 to thank Wesley George, Olivier Bonaventure and other 6renum members 582 for valuable comments. 584 8. References 586 8.1. Normative References 588 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 589 Location Protocol, Version 2", RFC 2608, June 1999. 591 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 592 Update", RFC 3007, November 2000. 594 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 595 M. Carney, "Dynamic Host Configuration Protocol for IPv6 596 (DHCPv6)", RFC 3315, July 2003. 598 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 599 Host Configuration Protocol (DHCP) version 6", RFC 3633, 600 December 2003. 602 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 603 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 604 December 2003. 606 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 607 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 609 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 610 Addresses", RFC 4193, October 2005. 612 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 613 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 614 RFC 4706, October 2006. 616 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 617 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 618 September 2007. 620 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 621 Address Autoconfiguration", RFC 4862, September 2007. 623 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 624 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 625 September 2010. 627 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 628 "IPv6 Router Advertisement Option for DNS Configuration", 629 RFC 6106, November 2011. 631 8.2. Informative References 633 [RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS", 634 RFC 2230, November 1997. 636 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 637 IPv6 Address Aggregation and Renumbering", RFC 2874, July 638 2000. 640 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 641 "Representing Internet Protocol version 6 (IPv6) Addresses 642 in the Domain Name System (DNS)", RFC 3363, August 2002. 644 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 645 for Internet Protocol version 6 (IPv6)", RFC 3364, August 646 2002. 648 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 4057, 649 June 2005. 651 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 652 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 653 September 2005. 655 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 656 Shim Protocol for IPv6", RFC 5533, June 2009. 658 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 659 Still Needs Work", RFC 5887, May 2010. 661 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 662 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 663 February 2011. 665 [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 666 Historic Status", RFC 6563, May 2012. 668 [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 669 Exclude Option for DHCPv6-based Prefix Delegation", RFC 670 6603, May 2012. 672 [I-D.ietf-dhc-secure-dhcpv6] 673 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 674 in progress, March 2012. 676 [I-D.ietf-dhc-host-gen-id] 677 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 678 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 679 August, 2012. 681 [I-D.ietf-savi-mix] 682 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 683 for Mixed Address Assignment Methods Scenario", working in 684 progress, April 2012. 686 [I-D.ietf-dhc-addr-registration] 687 Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration 688 Solution Using DHCPv6", working in progress, May 2012. 690 [I-D.ietf-6renum-gap-analysis] 691 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 692 Analysis", working in progress, August 2012. 694 [I-D.ietf-6renum-static-problem] 695 Carpenter, B. and S. Jiang., "Problem Statement for 696 Renumbering IPv6 Hosts with Static Addresses", working in 697 progress, August 2012. 699 [I-D.cheshire-dnsext-dns-sd] 700 Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", 701 draft-cheshire-dnsext-dns-sd-11 (work in progress), 702 December 2011. 704 [I-D.cheshire-dnsext-multicastdns] 705 Cheshire, S. and M. Krochmal, "Multicast DNS", draft- 706 cheshire-dnsext-multicastdns-15 (work in progress), 707 December 2011. 709 [BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. 710 14th IEEE Global Internet Symposium (GI2011), Shanghai, 711 China. 15 April 2011. 713 [JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS 714 Performance and the Effectiveness of Caching", IEEE/ACM 715 Transactions on Networking, 10(5):589-603, 2002. 717 Author's Addresses 719 Sheng Jiang 720 Huawei Technologies Co., Ltd 721 Q14, Huawei Campus 722 No.156 Beiqing Rd. 723 Hai-Dian District, Beijing 100095 724 P.R. China 726 EMail: jiangsheng@huawei.com 728 Bing Liu 729 Huawei Technologies Co., Ltd 730 Q14, Huawei Campus 731 No.156 Beiqing Rd. 732 Hai-Dian District, Beijing 100095 733 P.R. China 735 EMail: leo.liubing@huawei.com 737 Brian Carpenter 738 Department of Computer Science 739 University of Auckland 740 PB 92019 741 Auckland, 1142 742 New Zealand 744 EMail: brian.e.carpenter@gmail.com