Network Working Group F. Baker Request for Comments: 4192 Cisco Systems Updates: 2072 E. Lear Category: Informational Cisco Systems GmbH R. Droms Cisco Systems September 2005 Procedures for Renumbering an IPv6 Network without a Flag Day Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.
1. Introduction ....................................................2 1.1. Summary of the Renumbering Procedure .......................3 1.2. Terminology ................................................4 1.3. Summary of What Must Be Changed ............................4 1.4. Multihoming Issues .........................................5 2. Detailed Review of Procedure ....................................5 2.1. Initial Condition: Stable Using the Old Prefix .............6 2.2. Preparation for the Renumbering Process ....................6 2.2.1. Domain Name Service .................................7 2.2.2. Mechanisms for Address Assignment to Interfaces .....7 2.3. Configuring Network Elements for the New Prefix ............8 2.4. Adding New Host Addresses ..................................9 2.5. Stable Use of Either Prefix ...............................10 2.6. Transition from Use of the Old Prefix to the New Prefix ...10 2.6.1. Transition of DNS Service to the New Prefix ........10 2.6.2. Transition to Use of New Addresses .................10 2.7. Removing the Old Prefix ...................................11 2.8. Final Condition: Stable Using the New Prefix ..............11 3. How to Avoid Shooting Yourself in the Foot .....................12 3.1. Applications Affected by Renumbering ......................12 3.2. Renumbering Switch and Router Interfaces ..................12 3.3. Ingress Filtering .........................................13 3.4. Link Flaps in BGP Routing .................................13 4. Call to Action for the IETF ....................................14 4.1. Dynamic Updates to DNS Across Administrative Domains ......14 4.2. Management of the Reverse Zone ............................14 5. Security Considerations ........................................14 6. Acknowledgements ...............................................16 7. References .....................................................17 7.1. Normative References ......................................17 7.2. Informative References ....................................17 Appendix A. Managing Latency in the DNS ..........................20 Clausewitz] wrote, "Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.... So in war, through the influence of an 'infinity of petty circumstances' which cannot properly be described on paper, things disappoint us and we fall short of the mark". Operating a network is aptly compared to conducting a war. The difference is that the opponent has the futile expectation that homo ignoramus will behave intelligently.
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. Avoiding outages requires the network to be modified using what in mobility might be called a "make before break" procedure: the network is enabled to use a new prefix while the old one is still operational, operation is switched to that prefix, and then the old one is taken down. This document addresses the key procedural issues in renumbering an IPv6 [RFC2460] network without a "flag day". The procedure is straightforward to describe, but operationally can be difficult to automate or execute due to issues of statically configured network state, which one might aptly describe as "an infinity of petty circumstances". As a result, in certain areas, this procedure is necessarily incomplete, as network environments vary widely and no one solution fits all. It points out a few of many areas where there are multiple approaches. This document updates [RFC2072]. This document also contains recommendations for application design and network management, which, if taken seriously, may avoid or minimize the impact of the issues. RFC1034][RFC1035] or configured into switches and routers and applications will be replaced by the appropriate addresses from the new prefix. The renumbering procedure described in this document can be applied to part of a network as well as to an organization's entire network. In the case of a large organization, it may be advantageous to treat the network as a collection of smaller networks. Renumbering each of the smaller networks separately will make the process more manageable. The process described in this document is generally applicable to any network, whether it is an entire organization network or part of a larger network.
RFC2136][RFC3007] updates can be secured through the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG [RFC2845]. DHCP prefix delegation: An extension to DHCP [RFC3315] to automate the assignment of a prefix, for example, from an ISP to a customer [RFC3633]. flag day: A transition that involves a planned service outage. ingress/egress filters: Filters applied to a router interface connected to an external organization, such as an ISP, to exclude traffic with inappropriate IPv6 addresses. link prefix: A prefix, usually a /64 [RFC3177], assigned to a link. SLAC: StateLess Address AutoConfiguration [RFC2462]. RFC2461]. o Ingress/egress filters. o ACLs and other embedded addresses on switches and routers. o IPv6 addresses assigned to interfaces on hosts. Use of StateLess Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can mitigate the impact of renumbering the interfaces on hosts.
o DNS entries. New AAAA and PTR records are added and old ones removed in several phases to reflect the change of prefix. Caching times are adjusted accordingly during these phases. o IPv6 addresses and other configuration information provided by DHCP. o IPv6 addresses embedded in configuration files, applications, and elsewhere. Finding everything that must be updated and automating the process may require significant effort, which is discussed in more detail in Section 3. This process must be tailored to the needs of each network. RFC2827] and [RFC3704].
of the hosts have made the transition to the new prefix, the network is reconfigured so that the old prefix is no longer used in the network. In this discussion, we assume that an entire prefix is being replaced with another entire prefix. It may be that only part of a prefix is being changed, or that more than one prefix is being changed to a single joined prefix. In such cases, the basic principles apply, but will need to be modified to address the exact situation. This procedure should be seen as a skeleton of a more detailed procedure that has been tailored to a specific environment. Put simply, season to taste.
Appendix A gives an analysis of the factors controlling the propagation delays in the DNS. The suggestions for reducing the delay in the transition to new IPv6 addresses applies when the DNS service can be given prior notice about a renumbering event. However, the DNS service for a host may be in a different administrative domain than the network to which the host is attached. For example, a device from organization A that roams to a network belonging to organization B, but the device's DNS A record is still managed by organization A, where the DNS service won't be given advance notice of a renumbering event in organization B. One strategy for updating the DNS is to allow each system to manage its own DNS information through Dynamic DNS (DDNS) [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly recommended and can be accomplished through TSIG and SIG(0). Both TSIG and SIG(0) require configuration and distribution of keys to hosts and name servers in advance of the renumbering event.
o Prior to the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) may be reduced. o The DHCP Reconfigure message may also be sent from the server to the hosts to trigger the hosts to contact the server immediately. RFC2461] should not be set in the advertisements for the new link prefixes. The reason hosts should not be forming addresses at this point is that routing to the new addresses may not yet be stable. The details of this step will depend on the specific architecture of the network being renumbered and the capabilities of the components that make up the network infrastructure. The effort required to complete this step may be mitigated by the use of DNS, DHCP prefix delegation [RFC3633], and other automated configuration tools. While the new prefix is being added, it will of necessity not be working everywhere in the network, and unless properly protected by some means such as ingress and egress access lists, the network may be attacked through the new prefix in those places where it is operational. Once the new prefix has been added to the network infrastructure, access-lists, route-maps, and other network configuration options that use IP addresses should be checked to ensure that hosts and services that use the new prefix will behave as they did with the old one. Name services other than DNS and other services that provide
information that will be affected by renumbering must be updated in such a way as to avoid responding with stale information. There are several useful approaches to identify and augment configurations: o Develop a mapping from each network and address derived from the old prefix to each network and address derived from the new prefix. Tools such as the UNIX "sed" or "perl" utilities are useful to then find and augment access-lists, route-maps, and the like. o A similar approach involves the use of such mechanisms as DHCP prefix delegation to abstract networks and addresses. Switches and routers or manually configured hosts that have IPv6 addresses assigned from the new prefix may be used at this point to test the network infrastructure. Advertisement of the prefix outside its network is the last thing to be configured during this phase. One wants to have all of one's defenses in place before advertising the prefix, if only because the prefix may come under immediate attack. At the end of this phase, routing, access control, and other network services should work interchangeably for both old and new prefixes. Section 4.2.
resolve the name of an NTP server when the device is initialized will not obtain the address from the new prefix for that server at this point in the renumbering process. This last point warrants repeating (in a slightly different form). Applications may cache addressing information in different ways, for varying lengths of time. They may cache this information in memory, on a file system, or in a database. Only after careful observation and consideration of one's environment should one conclude that a prefix is no longer in use. For more information on this issue, see [DNSOP]. The transition of critical services such as DNS, DHCP, NTP [RFC1305], and important business services should be managed and tested carefully to avoid service outages. Each host should take reasonable precautions prior to changing to the use of the new prefix to minimize the chance of broken connections. For example, utilities such as netstat and network analyzers can be used to determine if any existing connections to the host are still using the address from the old prefix for that host. Link prefixes from the old prefix in router advertisements and addresses from the old prefix provided through DHCP should have their preferred lifetimes set to zero at this point, so that hosts will not use the old prefixes for new communications.
Section 2.3, Section 2.6, and Section 2.7 are in dealing with the configurations of routers and hosts that are not under the control of the network administrator or are manually configured. Examples of such devices include Voice over IP (VoIP) telephones with static configuration of boot or name servers, dedicated devices used in manufacturing that are configured with the IP addresses for specific services, the boot servers of routers and switches, etc.
can design and implement consistent support for renumbering across all of the functions of switches and routers. To better support renumbering, switches and routers should use domain names for configuration wherever appropriate, and they should resolve those names using the DNS when the lifetime on the name expires. Section 2.3, in the case where the network being renumbered is connected to an external provider, is the network's ingress filtering policy and its provider's ingress filtering policy. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing. Ingress filtering is considered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704]. IDR-RESTART], as it changes the "name" of the system, making the matter not one of a flap in an existing relationship but (from BGP's perspective) the replacement of one routing neighbor with another. Ideally, one should bring up the new BGP connection for the new address while the old remains stable and in use, and only then take down the old. In this manner, while there is a TCP connection flap, routing remains stable.
Neglecting to reconfigure a system that is using the old prefix in some static configuration: in this case, when the old prefix is removed from the network, whatever feature was so configured becomes inoperative - it is not configured for the new prefix, and the old prefix is irrelevant. Configuring a system via an IPv6 address, and replacing that old address with a new address: because the TCP connection is using the old and now invalid IPv6 address, the SSH session will be terminated and you will have to use SSH through the new address for additional configuration changes. Removing the old configuration before supplying the new: in this case, it may be necessary to obtain on-site support or travel to the system and access it via its console. Clearly, taking the extra time to add the new prefix to the configuration, allowing the network to settle, and then removing the old obviates this class of issue. A special consideration applies when some devices are only occasionally used; the administration must allow a sufficient length of time in Section 2.6 or apply other verification procedures to ensure that their likelihood of detection is sufficiently high. A subtle case of this type can result when the DNS is used to populate access control lists and similar security or QoS configurations. DNS names used to translate between system or service names and corresponding addresses are treated in this procedure as providing the address in the preferred prefix, which is either the old or new prefix but not both. Such DNS names provide a means, as described in Section 2.6, to cause systems in the network to stop using the old prefix to access servers or peers and cause them to start using the new prefix. DNS names used for access control lists, however, need to go through the same three-step procedure used for other access control lists, having the new prefix added to them as discussed in Section 2.3 and the old prefix removed as discussed in Section 2.7. It should be noted that the use of DNS names in this way is not universally accepted as a solution to this problem; [RFC3871] especially notes cases where static IP addresses are preferred over DNS names, in order to avoid a name lookup when the naming system is inaccessible or when the result of the lookup may be one of several interfaces or systems. In such cases, extra care must be taken to manage renumbering properly. Attacks are also possible. Suppose, for example, that the new prefix has been presented by a service provider, and the service provider
starts advertising the prefix before the customer network is ready. The new prefix might be targeted in a distributed denial of service attack, or a system might be broken into using an application that would not cross the firewall using the old prefix, before the network's defenses have been configured. Clearly, one wants to configure the defenses first and only then accessibility and routing, as described in Section 2.3 and Section 3.3. The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic DNS provides a capability for updating DNS accordingly. Managing configuration items apart from those procedures is most obviously straightforward if all such configurations are generated from a central configuration repository or database, or if they can all be read into a temporary database, changed using appropriate scripts, and applied to the appropriate systems. Any place where scripted configuration management is not possible or is not used must be tracked and managed manually. Here, there be dragons. In ingress filtering of a multihomed network, an easy solution to the issues raised in Section 3.3 might recommend that ingress filtering should not be done for multihomed customers or that ingress filtering should be special-cased. However, this has an impact on Internet security. A sufficient level of ingress filtering is needed to prevent attacks using spoofed source addresses. Another problem comes from the fact that if ingress filtering is made too difficult (e.g., by requiring special-casing in every ISP doing it), it might not be done at an ISP at all. Therefore, any mechanism depending on relaxing ingress filtering checks should be dealt with with extreme care. RFC3704], which should be read and understood by anyone who will
temporarily or permanently create a multihomed network by renumbering from one provider to another. In addition, the 6NET consortium, notably Alan Ford, Bernard Tuy, Christian Schild, Graham Holmes, Gunter Van de Velde, Mark Thompson, Nick Lamb, Stig Venaas, Tim Chown, and Tina Strauf, took it upon themselves to test the procedure. Some outcomes of that testing have been documented here, as they seemed of immediate significance to the procedure; 6NET will also be documenting its own "lessons learned". [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [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. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989.
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress, October 2004. [IDR-RESTART] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
RFC1996] and IXFR [RFC1995] to transfer updated information from the primary DNS server to any secondary servers; this is a very quick update process, and the actual time to update of information is not considered significant. There is a target time, TC, at which we want to change the contents of a DNS RR. The RR is currently configured with TTL == TTLOLD. Any cached references to the RR will expire no more than TTLOLD in the future. At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to push the RR to the secondaries. After the update, responses to queries for the RR are returned with TTLNEW. There are still some cached references with TTLOLD. At time TC - TTLNEW, the RR in the primary is configured with the new address. The update process is initiated to push the RR to the secondaries. After the update, responses to queries for the RR return the new address. All the cached references have TTLNEW. Between this time and TC, responses to queries for the RR may be returned with either the old address or the new address. This ambiguity is acceptable, assuming the host is configured to respond to both addresses. At time TC, all the cached references with the old address have expired, and all subsequent queries will return the new address. After TC (corresponding to the final state described in Section 2.8), the TTL on the RR can be set to the initial value TTLOLD. The network administrator can choose TTLOLD and TTLNEW to meet local requirements.
As a concrete example, consider a case where TTLOLD is a week (168 hours) and TTLNEW is an hour. The preparation for the change of addresses begins 169 hours before the address change. After 168 hours have passed and only one hour is left, the TTLNEW has propagated everywhere, and one can change the address record(s). These are propagated within the hour, after which one can restore TTL value to a larger value. This approach minimizes time where it is uncertain what kind of (address) information is returned from the DNS.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.