IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 6879.
|Authors||Sheng Jiang , Brian E. Carpenter , Bing Liu|
|Last updated||2015-10-14 (Latest revision 2013-01-14)|
|RFC stream||Internet Engineering Task Force (IETF)|
|Additional resources||Mailing list discussion|
|Stream||WG state||Submitted to IESG for Publication|
|IESG||IESG state||RFC 6879 (Informational)|
|Responsible AD||Ron Bonica|
|Send notices to||(None)|
Network Working Group S. Jiang Internet Draft B. Liu Intended status: Informational Huawei Technologies Co., Ltd Expires: July 18, 2013 B. Carpenter University of Auckland January 15, 2013 IPv6 Enterprise Network Renumbering Scenarios, Considerations and Methods draft-ietf-6renum-enterprise-06.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jiang, et al. Expires July 18, 2013 [Page 1] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 Abstract This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation. Table of Contents 1. Introduction ................................................. 3 2. Enterprise Network Illustration for Renumbering .............. 3 3. Enterprise Network Renumbering Scenario Categories ........... 5 3.1. Renumbering Caused by External Network Factors .......... 5 3.2. Renumbering caused by Internal Network Factors .......... 6 4. Network Renumbering Considerations and Current Methods ....... 6 4.1. Considerations and Current Methods during Network Design. 6 4.2. Considerations and Current Methods for the Preparation of Renumbering ................................................. 10 4.3. Considerations and Current Methods during Renumbering Operation ................................................... 12 5. Security Considerations ..................................... 14 6. IANA Considerations ......................................... 14 7. Acknowledgements ............................................ 14 8. References .................................................. 15 8.1. Normative References .................................. 15 8.2. Informative References ................................. 16 Author's Addresses ............................................. 18 Jiang, et al. July 18, 2013 [Page 2] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 1. Introduction Site renumbering is difficult. Network managers frequently attempt to avoid future renumbering by numbering their network resources from Provider Independent (PI) address space. However, widespread use of PI would aggravate BGP4 scaling problems [RFC4116] and, depending on Regional Internet Registry (RIR) policies, PI space is not always available for enterprises of all sizes. Therefore, it is desirable to develop mechanisms that simplify IPv6 renumbering for enterprises. This document is an analysis of IPv6 site renumbering for enterprise networks. It undertakes scenario descriptions, including documentation of current capabilities and existing practices. The reader is assumed to be familiar with [RFC4192] and [RFC5887]. Proposals for new technology and methods are out of scope. Since IPv4 and IPv6 are logically separate from the perspective of renumbering, regardless of overlapping of the IPv4/IPv6 networks or devices, this document focuses on IPv6 only, leaving IPv4 out of scope. Dual-stack network or IPv4/IPv6 transition scenarios are out of scope, too. This document focuses on enterprise network renumbering; however, most of the analysis is also applicable to ISP network renumbering. Renumbering in home networks is out of scope, but it can also benefit from the analysis in this document. The concept of an enterprise network and a typical network illustration are introduced first. Then, current renumbering methods are introduced according to the following categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation. 2. Enterprise Network Illustration for Renumbering An Enterprise Network as defined in [RFC4057] is a network that has multiple internal links, one or more router connections to one or more Providers, and is actively managed by a network operations entity. Figure 1 provides a sample enterprise network architecture for a simple case. Those entities mainly affected by renumbering are illustrated: Jiang, et al. July 18, 2013 [Page 3] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 * Gateway: Border router, firewall, web cache, etc. * Application server (for internal or external users) * DNS and DHCP servers * Routers * Hosts (desktops etc.) Uplink 1 Uplink 2 | | +---+---+ +---+---+ +---- |Gateway| --------- |Gateway| -----+ | +-------+ +-------+ | | Enterprise Network | | +------+ +------+ +------+ | | | APP | |DHCPv6| | DNS | | | |Server| |Server| |Server| | | +---+--+ +---+--+ +--+---+ | | | | | | | ---+--+---------+------+---+- | | | | | | +--+---+ +---+--+ | | |Router| |Router| | | +--+---+ +---+--+ | | | | | | -+---+----+-------+---+--+- | | | | | | | | +-+--+ +--+-+ +--+-+ +-+--+ | | |Host| |Host| |Host| |Host| | | +----+ +----+ +----+ +----+ | +----------------------------------------+ Figure 1 Enterprise network illustration Address reconfiguration is fulfilled either by the Dynamic Host configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for IPv6 (ND) protocols. During a renumbering event, the Domain Name Service (DNS) records need to be synchronized while routing tables, Access Control Lists (ACLs) and IP filtering tables in various devices also need to be updated. It is taken for granted that applications will work entirely on the basis of DNS names, but any direct dependencies on IP addresses in application layer entities must also be updated. The issue of static addresses is described in a dedicated draft [I-D.ietf-6renum-static-problem]. Jiang, et al. July 18, 2013 [Page 4] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 The emerging cloud-based enterprise network architecture might be different with Figure 1. But it is out of the scope of this document since the it is far from mature and has not been widely deployed yet. It is assumed that IPv6 enterprise networks are IPv6-only, or dual- stack in which a logical IPv6 plane is independent from IPv4. As mentioned above, IPv4/IPv6 co-existence scenarios are out of scope. This document focuses on routable unicast addresses; link-local, multicast and anycast addresses are also out of scope. 3. Enterprise Network Renumbering Scenario Categories In this section, we divide enterprise network renumbering scenarios into two categories defined by external and internal network factors, which require renumbering for different reasons. 3.1. Renumbering Caused by External Network Factors The following ISP uplink-related events can cause renumbering: o The enterprise network switches to a new ISP. When this occurs, the enterprise stop numbering its resources from the prefix allocated by the old ISP and renumbers its resources from the prefix allocated by the new ISP. When the enterprise switches ISPs, a "flag day" renumbering event [RFC4192] may be averted if, during a transitional period, the enterprise network may number its resources from either prefix. One way to facilitate such a transitional period is for the enterprise to contract for service from both ISPs during the transition. o The renumbering event can be initiated by receiving new prefixes from the same uplink. This might happen if the enterprise network is switched to a different location within the network topology of the same ISP due to various considerations, such as commercial, performance or services reasons, etc. Alternatively, the ISP itself might be renumbered due to topology changes or migration to a different or additional prefix. These ISP renumbering events would initiate enterprise network renumbering events, of course. o The enterprise network adds new uplink(s) for multihoming purposes. This might not be a typical renumbering case because the original addresses will not be changed. However, initial numbering may be considered as a special renumbering event. The enterprise network removes uplink(s) or old prefixes. Jiang, et al. July 18, 2013 [Page 5] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 3.2. Renumbering caused by Internal Network Factors o As companies split, merge, grow, relocate or reorganize, the enterprise network architectures might need to be re-built. This will trigger partial or total internal renumbering. o The enterprise network might proactively adopt a new address scheme, for example by switching to a new transition mechanism or stage of a transition plan. o The enterprise network might reorganize its topology or subnets. 4. Network Renumbering Considerations and Current Methods In order to carry out renumbering in an enterprise network, systematic planning and administrative preparation are needed. Careful planning and preparation could make the renumbering process smoother. This section describes current solutions or strategies for enterprise renumbering, chosen among existing mechanisms. There are known gaps analyzed by [I-D.ietf-6renum-gap-analysis] and [I-D.ietf-6renum-static-problem]. If these gaps are filled in the future, enterprise renumbering can be processed more automatically, with fewer issues. 4.1. Considerations and Current Methods during Network Design This section describes the consideration or issues relevant to renumbering that a network architect should carefully plan when building or designing a new network. - Prefix Delegation In a large or a multi-site enterprise network, the prefix should be carefully managed, particularly during renumbering events. Prefix information needs to be delegated from router to router. The DHCPv6 Prefix Delegation options [RFC3633] and [RFC6603] provide a mechanism for automated delegation of IPv6 prefixes. Normally, DHCPv6 Prefix Delegation (PD) options are used between the internal enterprise routers, for example, a router receives prefix(es) from its upstream router (a border gateway or edge router etc.) through DHCPv6 PD options and then advertises it (them) to the local hosts through Router Advertisement (RA) messages. - Usage of FQDN Jiang, et al. July 18, 2013 [Page 6] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 In general, Fully-Qualified Domain Names (FQDNs) are recommended to be used to configure network connectivity, such as tunnels, servers etc. The capability to use FQDNs as endpoint names has been standardized in several RFCs, for example for IPsec [RFC5996], although many system/network administrators do not realize that it is there and works well as a way to avoid manual modification during renumbering. Note that using FQDN would rely on DNS systems. For a link local network that does not have a DNS system, multicast DNS [I-D.cheshire-dnsext-multicastdns] could be utilized. For some specific circumstances, using FQDN might not be chosen if adding DNS service in the node/network would cause undesired complexity or issues. Service discovery protocols such as Service Location Protocol [RFC2608], multicast DNS with SRV records and DNS Service Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce the number of places that IP addresses need to be configured. But it should be noted that these protocols are normally used link- local only. Network designers generally have little control over the design of application software. However, it is important to avoid any software that has built-in dependency on IP addresses instead of FQDNs [I-D.ietf-6renum-static-problem]. - Usage of Parameterized Address Configuration Besides DNS records, IP addresses might also be configured in many other places such as ACLs, various IP filters, various kinds of text-based configuration files, etc. In some cases, one IP address can be defined as a value once, and then the administrators can use either keywords or variables to call the value in other places such as a sort of internal inheritance in CLI (command line interface) or other local configurations. Among the real current devices, some routers support defining multiple loopback interfaces which can be called in other configurations. For example, when defining a tunnel, it can call the defined loopback interface to use its address as the local address of the tunnel. This kind of parameterized address configuration is recommended, since it makes managing a renumbering event easier by reducing the number of places where a device's configuration must be updated. Jiang, et al. July 18, 2013 [Page 7] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 - Usage of ULA Unique Local Addresses (ULAs) are defined in [RFC4193] as provider-independent prefixes. Since there is a 40 bits pseudo random field in the ULA prefix, there is no practical risk of collision (please refer to section 3.2.3 in [RFC4193] for more detail). For enterprise networks, using ULA simultaneously with Provider Aggregated (PA) addresses can provide a logically local routing plane separated from the global routing plane. The benefit is to ensure stable and specific local communication regardless of any ISP uplink failure. This benefit is especially meaningful for renumbering. It mainly includes three use cases described below. During the transition period, it is desirable to isolate local communication changes in the global routing plane. If we use ULA for the local communication, this isolation is achieved. Enterprise administrators might want to avoid the need to renumber their internal-only, private nodes when they have to renumber the PA addresses of the whole network because of changing ISPs, ISPs restructuring their address allocation, or any other reasons. In these situations, ULA is an effective tool for the internal-only nodes. ULA can be a way of avoiding renumbering from having an impact on multicast. In most deployments multicast is only used internally (intra-domain), and the addresses used for multicast sources and Rendezvous-Points need not be reachable nor routable externally. Hence one may at least internally make use of ULA for multicast specific infrastructure. - Address Types This document focuses on the dynamically-configured global unicast addresses in enterprise networks. They are the targets of renumbering events. Manually-configured addresses are not scalable in medium to large sites, hence should be avoided for both network elements and application servers [I-D.ietf-6renum-static-problem]. - Address configuration models In IPv6 networks, there are two auto-configuration models for address assignment after each host obtains a link-local address: Stateless Address Auto-Configuration (SLAAC, [RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful address Jiang, et al. July 18, 2013 [Page 8] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 configuration by Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 may also support the host-generated address model by assigning a prefix through DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. SLAAC is considered to support easy renumbering by broadcasting a Router Advertisement message with a new prefix. DHCPv6 can also trigger the renumbering process by sending unicast RECONFIGURE messages, though it might cause a large number of interactions between hosts and the DHCPv6 server. This document has no preference between the SLAAC and DHCPv6 address configuration models. It is the network architects' job to decide which configuration model is employed. But it should be noticed that using DHCPv6 and SLAAC together within one network, especially in one subnet, might cause operational issues. For example, some hosts use DHCPv6 as the default configuration model while some use ND. Then the hosts' address configuration model depends on the policies of operating systems and cannot be controlled by the network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses more details on this topic. So, in general, this document recommends using DHCPv6 or SLAAC independently in different subnets. However, since DHCPv6 is also used to configure many other network parameters, there are ND and DHCPv6 co-existence scenarios. Combinations of address configuration models might coexist within a single enterprise network. [I-D.ietf-savi-mix] provides recommendations to avoid collisions and to review collision handling in such scenarios. - DNS Although the A6 DNS record model [RFC2874] was designed for easier renumbering, it left many unsolved technical issues [RFC3364]. Therefore, it has been moved to historic status [RFC6563] and should not be used. Often, a small site depends on its ISP's DNS system rather than maintaining its own. When renumbering, this requires administrative coordination between the site and its ISP. It is recommended that the site have an automatic and systematic procedure for updating/synchronizing its DNS records, including both forward and reverse mapping. In order to simplify the operational procedure, the network architect should combine the forward and reverse DNS updates in a single procedure. A manual Jiang, et al. July 18, 2013 [Page 9] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 on-demand updating model does not scale, and increases the chance of errors. Either a database-driven mechanism, or Secure Dynamic DNS Update [RFC3007], or both, could be used. Dynamic DNS update can be provided by the DHCPv6 client or by the server on behalf of individual hosts. [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and servers to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated AAAA and PTR (Pointer Record) RRs (Resource Records). For example, if a client wants the server to update the FQDN-address mapping in the DNS server, it can include the Client FQDN option with proper settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. When DHCPv6 server gets this option, it can use Secure Dynamic DNS update on behalf of the client. This document suggests use of this FQDN option. However, since it is a DHCPv6 option, only the DHCP-managed hosts can make use of it. In SLAAC mode, hosts need either to use Secure Dynamic DNS Update directly, or to register addresses on a registration server. This could in fact be a DHCPv6 server (as described in [I-D.ietf-dhc-addr-registration]); then the server would update corresponding DNS records. - Security Any automatic renumbering scheme has a potential exposure to hijacking. A malicious entity in the network could forge prefixes to renumber the hosts, so proper network security mechanisms are needed. Further details are in the Security Considerations below. - Miscellaneous A site or network should also avoid embedding addresses from other sites or networks in its own configuration data. Instead, the Fully-Qualified Domain Names should be used. Thus, connections can be restored after renumbering events at other sites. This also applies to host-based connectivity. 4.2. Considerations and Current Methods for the Preparation of Renumbering In ND, it is not possible to reduce a prefix's lifetime to below two hours. So, renumbering should not be an unplanned sudden event. This issue could only be avoided by early planning and preparation. This section describes several recommendations for the preparation of enterprise renumbering event. By adopting these recommendations, Jiang, et al. July 18, 2013 [Page 10] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 a site could be renumbered more easily. However, these recommendations might increase the daily traffic, server load, or burden of network operation. Therefore, only those networks that are expected to be renumbered soon or very frequently should adopt these recommendations, with balanced consideration between daily cost and renumbering cost. - Reduce the address preferred time or valid time or both. Long-lifetime addresses might cause issues for renumbering events. Particularly, some offline hosts might reconnect using these addresses after renumbering events. Shorter preferred lifetimes with relatively long valid lifetimes may allow short transition periods for renumbering events and avoid frequent address renewals. - Reduce the DNS record TTL on the local DNS server. The DNS AAAA resource record TTL on the local DNS server should be manipulated to ensure that stale addresses are not cached. Recent research [BA2011] [JSBM2002] indicates that it is both practical and reasonable for A, AAAA, and PTR records that belong to leaf nodes of the DNS (i.e. not including the DNS root or DNS top-level domains) to be configured with very short DNS TTL values, not only during renumbering events, but also for longer- term operation. - Reduce the DNS configuration lifetime on the hosts. Since the DNS server could be renumbered as well, the DNS configuration lifetime on the hosts should also be reduced if renumbering events are expected. In ND, the DNS configuration can be done through reducing the lifetime value in RDNSS option [RFC6106]. In DHCPv6, the DNS configuration option specified in [RFC3646] doesn't provide a lifetime attribute, but we can reduce the DHCPv6 client lease time to achieve similar effect. - Identify long-living sessions Any applications which maintain very long transport connections (hours or days) should be identified in advance, if possible. Such applications will need special handling during renumbering, so it is important to know that they exist. Jiang, et al. July 18, 2013 [Page 11] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 4.3. Considerations and Current Methods during Renumbering Operation Renumbering events are not instantaneous events. Normally, there is a transition period, in which both the old prefix and the new prefix are used in the site. Better network design and management, better pre-preparation and longer transition period are helpful to reduce the issues during renumbering operation. - Within/without a flag day As is described in [RFC4192], "a 'flag day' is a procedure in which the network, or a part of it, is changed during a planned outage, or suddenly, causing an outage while the network recovers." If renumbering event is processed within a flag day, the network service/connectivity will be unavailable for a period until the renumbering event is completed. It is efficient and provides convenience for network operation and management. But network outage is usually unacceptable for end users and enterprises. A renumbering procedure without a flag day provides smooth address switching, but much more operational complexity and difficulty is introduced. - Transition period If renumbering transition period is longer than all address lifetimes, after which the address leases expire, each host will automatically pick up its new IP address. In this case, it would be the DHCPv6 server or Router Advertisement itself that automatically accomplishes client renumbering. Address deprecation should be associated with the deprecation of associated DNS records. The DNS records should be deprecated as early as possible, before the addresses themselves. - Network initiative enforced renumbering If the network has to enforce renumbering before address leases expire, the network should initiate DHCPv6 RECONFIGURE messages. For some operating systems such as Windows 7, if the hosts receive RA messages with ManagedFlag=0, they'll release the DHCPv6 addresses and do SLAAC according to the prefix information in the RA messages, so this could be another enforcement method for some specific scenarios. - Impact to branch/main sites Jiang, et al. July 18, 2013 [Page 12] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 Renumbering in main/branch site might cause impact on branch/main site communication. The routes, ingress filtering of site's gateways, and DNS might need to be updated. This needs careful planning and organizing. - DNS record update and DNS configuration on hosts DNS records on the local DNS server should be updated if hosts are renumbered. If the site depends on ISP's DNS system, it should report the new host's DNS records to its ISP. During the transition period, both old and new DNS records are valid. If the TTLs of DNS records are shorter than the transition period, an administrative operation might not be necessary. DNS configuration on hosts should be updated if local recursive DNS servers are renumbered. During the transition period, both old and new DNS server addresses might co-exist on the hosts. If the lifetime of DNS configuration is shorter than the transition period, name resolving failure may be reduced to minimum. - Tunnel concentrator renumbering A tunnel concentrator itself might be renumbered. This change should be reconfigured in relevant hosts or routers, unless the configuration of tunnel concentrator was based on FQDN. For IPSec, IKEv2 [RFC5996] defines the ID_FQDN Identification Type, which could be used to identify an IPsec VPN concentrator associated with a site's domain name. For current practice, the community needs to change its bad habit of using IPsec in an address-oriented way, and renumbering is one of the main reasons for that. - Connectivity session survivability During the renumbering operations, connectivity sessions in IP layer would break if the old address is deprecated before the session ends. However, the upper layer sessions can survive by using session survivability technologies, such as SHIM6 [RFC5533]. As mentioned above, some long-living applications may need to be handled specially. - Verification of success Jiang, et al. July 18, 2013 [Page 13] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 The renumbering operation should end with a thorough check that all network elements and hosts are using only the new prefixes and that network management and monitoring systems themselves are still operating correctly. A database clean-up may also be needed. 5. Security Considerations Any automatic renumbering scheme has a potential exposure to hijacking by an insider attack. For attacks on ND, Secure Neighbor Discovery (SEND) [RFC3971] is a possible solution, but it is complex and there is almost no real deployment at the time of writing. Compared to the non-trivial deployment of SEND, RA Guard [RFC6105] is a lightweight alternative, which focuses on preventing rogue router advertisements in a network. However, it was also not widely deployed at the time when this memo was published. For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages [RFC3315] could be utilized. But these security mechanisms also have not been verified by widespread deployment at the time of writing. A site that is listed by IP address in a black list can escape that list by renumbering itself. However, the new prefix might be back on a black list rather soon, if the root cause for being added to such a list is not corrected. In practice, the cost of renumbering will be typically much larger than the cost of getting off the black list. Dynamic DNS update might bring risk of DoS attack to the DNS server. So along with the update authentication, session filtering/limitation might also be needed. The "make-before-break" approach of [RFC4192] requires the routers keep advertising the old prefixes for some time. But if the ISP changes the prefixes very frequently, the co-existence of old and new prefixes might cause potential risk to the enterprise routing system, since the old address relevant route path might already invalid and the routing system just doesn't know it. However, normally enterprise scenarios don't involve the extreme situation. 6. IANA Considerations This draft does not request any IANA action. 7. Acknowledgements This work is inspired by RFC5887, so thank for RFC 5887 authors, Randall Atkinson and Hannu Flinck. Useful ideas were also presented Jiang, et al. July 18, 2013 [Page 14] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 in by documents from Tim Chown and Fred Baker. The authors also want to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald Bonica, other 6renum members, and several reviewers for valuable comments. 8. References 8.1. Normative References [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005. [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4706, October 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Jiang, et al. July 18, 2013 [Page 15] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli "IPv6 Router Advertisement Option for DNS Configuration", RFC 6106, November 2011. 8.2. Informative References [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002. [RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to Historic Status", RFC 6563, May 2012. [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012. [I-D.ietf-dhc-secure-dhcpv6] Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working in progress, March 2012. Jiang, et al. July 18, 2013 [Page 16] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 [I-D.ietf-dhc-host-gen-id] S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), August, 2012. [I-D.ietf-savi-mix] Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI for Mixed Address Assignment Methods Scenario", working in progress, April 2012. [I-D.ietf-dhc-addr-registration] Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration Solution Using DHCPv6", working in progress, May 2012. [I-D.ietf-6renum-gap-analysis] Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap Analysis", working in progress, August 2012. [I-D.ietf-6renum-static-problem] Carpenter, B. and S. Jiang., "Problem Statement for Renumbering IPv6 Hosts with Static Addresses", working in progress, August 2012. [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-11 (work in progress), December 2011. [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft- cheshire-dnsext-multicastdns-15 (work in progress), December 2011. [BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. 14th IEEE Global Internet Symposium (GI2011), Shanghai, China. 15 April 2011. [JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS Performance and the Effectiveness of Caching", IEEE/ACM Transactions on Networking, 10(5):589-603, 2002. Jiang, et al. July 18, 2013 [Page 17] Internet-Draft draft-ietf-6renum-enterprise-06 January 2013 Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: firstname.lastname@example.org Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: email@example.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: firstname.lastname@example.org Jiang, et al. July 18, 2013 [Page 18]