--- 1/draft-ietf-v6ops-renumbering-procedure-03.txt 2006-02-05 02:08:22.000000000 +0100 +++ 2/draft-ietf-v6ops-renumbering-procedure-04.txt 2006-02-05 02:08:22.000000000 +0100 @@ -1,23 +1,24 @@ + IPv6 Operations Working Group F. Baker Internet-Draft E. Lear -Expires: May 23, 2005 R. Droms +Expires: August 12, 2005 R. Droms Cisco Systems - November 22, 2004 + February 8, 2005 Procedures for Renumbering an IPv6 Network without a Flag Day - draft-ietf-v6ops-renumbering-procedure-03 + draft-ietf-v6ops-renumbering-procedure-04 Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each + of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -25,111 +26,111 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 23, 2005. + This Internet-Draft will expire on August 12, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract This 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 addressing 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 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 . . . . . . . . . . . . . . . . . 6 - 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 . . . 8 - 2.3 Configuring switches and routers 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 the use of new addresses . . . . . . . . 10 - 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11 - 2.8 Final condition: stable using the new prefix . . . . . . . 12 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Summary of the renumbering procedure . . . . . . . . . . . 4 + 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3 Summary of what must be changed . . . . . . . . . . . . . 5 + 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 6 - 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 - 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 - 3.2 Renumbering switch and router interfaces . . . . . . . . . 13 - 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 + 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 7 + 2.1 Initial condition: stable using the old prefix . . . . . . 7 + 2.2 Preparation for the renumbering process . . . . . . . . . 7 + 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 8 + 2.2.2 Mechanisms for address assignment to interfaces . . . 9 + 2.3 Configuring switches and routers for the new prefix . . . 9 + 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 10 + 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 11 + 2.6 Transition from use of the old prefix to the new prefix . 11 + 2.6.1 Transition of DNS service to the new prefix . . . . . 11 + 2.6.2 Transition to the use of new addresses . . . . . . . . 11 + 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 12 + 2.8 Final condition: stable using the new prefix . . . . . . . 13 - 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 - 4.1 Dynamic updates to DNS across administrative domains . . . 15 - 4.2 Management of the reverse zone . . . . . . . . . . . . . . 15 + 3. How to avoid shooting yourself in the foot . . . . . . . . . . 14 + 3.1 Applications affected by renumbering . . . . . . . . . . . 14 + 3.2 Renumbering switch and router interfaces . . . . . . . . . 14 + 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 15 + 3.4 Link Flaps in BGP Routing . . . . . . . . . . . . . . . . 15 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 16 + 4.1 Dynamic updates to DNS across administrative domains . . . 16 + 4.2 Management of the reverse zone . . . . . . . . . . . . . . 16 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 - 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 20 - A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . 24 + A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . 25 1. Introduction The Prussian military theorist Carl von Clausewitz [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 + 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. It may be considered an update to RFC 2072 + are multiple approaches. It may be considered an update to [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. 1.1 Summary of the renumbering procedure By "renumbering a network" we mean replacing the use of an existing (or "old") prefix throughout a network with a new prefix. Usually, both prefixes will be the same length. The procedures described in this document are, for the most part, equally applicable if the two @@ -382,27 +383,27 @@ 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: - Develop a mapping from each network and address derived from the + 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. - A similar approach involves the use of such mechanisms as DHCP + 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. @@ -529,44 +530,37 @@ The difficult operational issues in Section 2.3, Section 2.6, and Section 2.7 are in dealing with the configurations of routers and hosts which 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. -3.1 "Find all the places..." - - Long-lived communications present a problem to any application, - regardless of whether a network is renumbered. However, such events - test the resilience of the code used to survive disruptions. Many - existing applications make use of standard POSIX functions such as - gethostbyname() and getipnodebyname(), both of which use the common - "hostent" structure. If the application caches the response or for - whatever reason actually records the response on disk, recovery from - such events may prove difficult. It should be pointed out that the - above basic functions do not preserve DNS caching semantics. Any - application that requires repeated use of an IP address should either - not cache the result or make use of an appropriate function such as - the POSIX res_query(). +3.1 Applications affected by renumbering - In some cases, applications make use of manually configured IP - addresses. For instance, database servers and web servers are often - configured to LISTEN to a specific TCP port on a specific interface. - Applications should be configured with names that are translated at - startup, and then again when the interface address itself is changed. + Applications may inadvertently ignore DNS caching semantics + associated with IP addresses obtained through DNS resolution. The + result is that a long-lived application may continue to use a stale + IP address beyond the time at which the TTL for that address has + expired, even if the DNS is updated with new addresses during a + renumbering event. - In the case of infrastructure applications such as name servers and - route processes, a convenient programmatic method that abstracts - prefixes to a single point would be ideal. + For example, many existing applications make use of standard POSIX + functions such as getaddrinfo(), which do not preserve DNS caching + semantics. If the application caches the response or for whatever + reason actually records the response on disk, the application will + have no way to know when the TTL for the response has expired. Any + application that requires repeated use of an IP address should either + not cache the result or make use of an appropriate function which + also conveys the TTL of the record (e.g., getrrsetbyname()). Application designers, equipment vendors, and the Open Source community should take note. There is an opportunity to serve their customers well in this area, and network operators should take note to either develop or purchase appropriate tools. 3.2 Renumbering switch and router interfaces The configuration and operation of switches and routers are often designed to use static configuration with IP addresses or to resolve @@ -590,20 +584,51 @@ An important consideration in Section 2.3, in the case where the network being renumbered is connected to an external provider, 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]. +3.4 Link Flaps in BGP Routing + + A subtle case arises during step 2 in BGP routing when renumbering + the address(es) used to name the BGP routers. Two practices are + common: one is to identify a BGP router by a stable address such as a + loopback address; another is to use the interface address facing the + BGP peer. In each case, when adding a new prefix, a certain + ambiguity is added: the systems must choose between the addresses, + and depending on how they choose different events can happen. + + o If the existing address remains in use until removed, then this is + minimized to a routing flap on that event. + + o If both systems decide to use the address in the new prefix + simultaneously, the link flap may occur earlier in the process, + and if this is being done automatically (such as via the router + renumbering protocol) may result in route flaps throughout the + network. + + o If the two systems choose differently (one uses the old and one + the new address), a stable routing outage occurs. + + This is not addressed by proposales such as [I-D.ietf-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. + 4. Call to Action for the IETF The more automated one can make the renumbering process, the better for everyone. Sadly, there are several mechanisms that either have not been automated, or have not been automated consistently across platforms. 4.1 Dynamic updates to DNS across administrative domains The configuration files for a DNS server (such as named.conf) will @@ -707,21 +732,21 @@ 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 becomes from the fact that if ingress filtering is made too difficult - (e.g. by requiring special casing in every ISP doing it), it might + (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 an extreme care. 6. Acknowledgments This document grew out of a discussion on the IETF list. Commentary on the document came from Bill Fenner, Christian Huitema, Craig Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand, Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, @@ -733,20 +758,27 @@ Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described the ingress filtering issues. These made their way separately into [RFC3704], which should be read and understood by anyone that 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 their own "lessons learned". + 7. References 7.1 Normative References [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. @@ -772,23 +804,28 @@ 7.2 Informative References [Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989. [I-D.ietf-dnsop-ipv6-dns-issues] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", - draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress), + Internet-Draft draft-ietf-dnsop-ipv6-dns-issues-10, October 2004. + [I-D.ietf-idr-restart] + Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. + Chen, "Graceful Restart Mechanism for BGP", + Internet-Draft draft-ietf-idr-restart-10, June 2004. + [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", 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 @@ -826,38 +863,39 @@ Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: 408-526-4257 Fax: 413-473-2403 - EMail: fred@cisco.com + Email: fred@cisco.com + Eliot Lear Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US Phone: +1 408 527 4020 - EMail: lear@cisco.com + Email: lear@cisco.com Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 US Phone: +1 978 936-1674 - EMail: rdroms@cisco.com + Email: rdroms@cisco.com Appendix A. Managing Latency in the DNS The procedure in this section can be used to determine and manage the latency in updates to information a DNS resource record (RR). There are several kinds of possible delays which are ignored in these calculations: o the time it takes for the administrators to make the changes, @@ -940,18 +978,18 @@ 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. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.