diff options
Diffstat (limited to 'doc/rfc/rfc4192.txt')
| -rw-r--r-- | doc/rfc/rfc4192.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4192.txt b/doc/rfc/rfc4192.txt new file mode 100644 index 0000000..b401b86 --- /dev/null +++ b/doc/rfc/rfc4192.txt @@ -0,0 +1,1235 @@ + + + + + + +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). + +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 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. + + + + + + + + + + + + + + + + + + + + +Baker, et al. Informational [Page 1] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +Table of Contents + + 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 + +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 + conducting a war. The difference is that the opponent has the futile + expectation that homo ignoramus will behave intelligently. + + + + + +Baker, et al. Informational [Page 2] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +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 + prefixes are not the same length. During renumbering, sub-prefixes + (or "link prefixes") from the old prefix, which have been assigned to + links throughout the network, will be replaced by link prefixes from + the new prefix. Interfaces on systems throughout the network will be + configured with IPv6 addresses from the link prefixes of the new + prefix, and any addresses from the old prefix in services like DNS + [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. + + + + + + +Baker, et al. Informational [Page 3] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +1.2. Terminology + + DDNS: Dynamic DNS [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]. + +1.3. Summary of What Must Be Changed + + Addresses from the old prefix that are affected by renumbering will + appear in a wide variety of places in the components in the + renumbered network. The following list gives some of the places that + may include prefixes or addresses that are affected by renumbering, + and gives some guidance about how the work required during + renumbering might be minimized: + + o Link prefixes assigned to links. Each link in the network must be + assigned a link prefix from the new prefix. + + o IPv6 addresses assigned to interfaces on switches and routers. + These addresses are typically assigned manually, as part of + configuring switches and routers. + + o Routing information propagated by switches and routers. + + o Link prefixes advertised by switches and routers [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. + + + + +Baker, et al. Informational [Page 4] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +1.4. Multihoming Issues + + In addition to the considerations presented, the operational matters + of multihoming may need to be addressed. Networks are generally + renumbered for one of three reasons: the network itself is changing + its addressing policy and must renumber to implement the new policy + (for example, a company has been acquired and is changing addresses + to those used by its new owner), an upstream provider has changed its + prefixes and its customers are forced to do so at the same time, or a + company is changing providers and must perforce use addresses + assigned by the new provider. The third case is common. + + When a company changes providers, it is common to institute an + overlap period, during which it is served by both providers. By + definition, the company is multihomed during such a period. Although + this document is not about multihoming per se, problems can arise as + a result of ingress filtering policies applied by the upstream + provider or one of its upstream providers, so the user of this + document also needs to be cognizant of these issues. This is + discussed in detail, and approaches to dealing with it are described, + in [RFC2827] and [RFC3704]. + +2. Detailed Review of Procedure + + During the renumbering process, the network transitions through eight + states. In the initial state, the network uses just the prefix that + is to be replaced during the renumbering process. At the end of the + process, the old prefix has been entirely replaced by the new prefix, + and the network is using just the new prefix. To avoid a flag day + transition, the new prefix is deployed first and the network reaches + an intermediate state in which either prefix can be used. In this + state, individual hosts can make the transition to using the new + prefix as appropriate to avoid disruption of applications. Once all + + + + + +Baker, et al. Informational [Page 5] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +2.1. Initial Condition: Stable Using the Old Prefix + + Initially, the network is using an old prefix in routing, device + interface addresses, filtering, firewalls, and other systems. This + is a stable configuration. + +2.2. Preparation for the Renumbering Process + + The first step is to obtain the new prefix and new reverse zone from + the delegating authority. These delegations are performed using + established procedures, from either an internal or external + delegating authority. + + Before any devices are reconfigured as a result of the renumbering + event, each link in the network must be assigned a sub-prefix from + the new prefix. While this assigned link prefix does not explicitly + appear in the configuration of any specific switch, router, or host, + the network administrator performing the renumbering procedure must + make these link prefix assignments prior to beginning the procedure + to guide the configuration of switches and routers, assignment of + addresses to interfaces, and modifications to network services such + as DNS and DHCP. + + Prior to renumbering, various processes will need to be reconfigured + to confirm bindings between names and addresses more frequently. In + normal operation, DNS name translations and DHCP bindings are often + given relatively long lifetimes to limit server load. In order to + reduce transition time from old to new prefix, it may be necessary to + reduce the time to live (TTL) associated with DNS records and + increase the frequency with which DHCP clients contact the DHCP + server. At the same time, a procedure must be developed through + which other configuration parameters will be updated during the + transition period when both prefixes are available. + + + + + +Baker, et al. Informational [Page 6] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +2.2.1. Domain Name Service + + During the renumbering process, the DNS database must be updated to + add information about addresses assigned to interfaces from the new + prefix and to remove addresses assigned to interfaces from the old + prefix. The changes to the DNS must be coordinated with the changes + to the addresses assigned to interfaces. + + Changes to the information in the DNS have to propagate from the + server at which the change was made to the resolvers where the + information is used. The speed of this propagation is controlled by + the TTL for DNS records and the frequency of updates from primary to + secondary servers. + + The latency in propagating changes in the DNS can be managed through + the TTL assigned to individual DNS records and through the timing of + updates from primary to secondary servers. 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. + +2.2.2. Mechanisms for Address Assignment to Interfaces + + IPv6 addresses may be assigned through SLAC, DHCP, and manual + processes. If DHCP is used for IPv6 address assignment, there may be + some delay in the assignment of IPv6 addresses from the new prefix + because hosts using DHCP only contact the server periodically to + extend the lifetimes on assigned addresses. This delay can be + reduced in two ways: + + + + + + +Baker, et al. Informational [Page 7] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +2.3. Configuring Network Elements for the New Prefix + + In this step, switches and routers and services are prepared for the + new prefix but the new prefix is not used for any datagram + forwarding. Throughout this step, the new prefix is added to the + network infrastructure in parallel with (and without interfering + with) the old prefix. For example, addresses assigned from the new + prefix are configured in addition to any addresses from the old + prefix assigned to interfaces on the switches and routers. Changes + to the routing infrastructure for the new prefix are added in + parallel with the old prefix so that forwarding for both prefixes + operates in parallel. At the end of this step, the network is still + running on the old prefix but is ready to begin using the new prefix. + + The new prefix is added to the routing infrastructure, firewall + filters, ingress/egress filters, and other forwarding and filtering + functions. Routes for the new link prefixes may be injected by + routing protocols into the routing subsystem, but the router + advertisements should not cause hosts to perform SLAC on the new link + prefixes; in particular the "autonomous address-configuration" flag + [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 + + + +Baker, et al. Informational [Page 8] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +2.4. Adding New Host Addresses + + Once the network infrastructure for the new prefix is in place and + tested, IPv6 addresses from the new prefix may be assigned to host + interfaces while the addresses from the old prefix are retained on + those interfaces. The new IPv6 addresses may be assigned through + SLAC, DHCP, and manual processes. If SLAC is used in the network, + the switches and routers are configured to indicate that hosts should + use SLAC to assign IPv6 addresses from the new prefix. If DHCP is + used for IPv6 address assignment, the DHCP service is configured to + assign addresses from both prefixes to hosts. The addresses from the + new prefixes will not be used until they are inserted into the DNS. + + Once the new IPv6 addresses have been assigned to the host + interfaces, both the forward and reverse maps within DNS should be + updated for the new addresses, either through automated or manual + means. In particular, some clients may be able to update their + forward maps through DDNS, but automating the update of the reverse + zone may be more difficult as discussed in Section 4.2. + + + + + + + +Baker, et al. Informational [Page 9] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +2.5. Stable Use of Either Prefix + + Once the network has been configured with the new prefix and has had + sufficient time to stabilize, it becomes a stable platform with two + addresses configured on each and every infrastructure component + interface (apart from interfaces that use only the link-local + address), and two non-link-local addresses are available for the use + of any host, one in the old prefix and one in the new. This is a + stable configuration. + +2.6. Transition from Use of the Old Prefix to the New Prefix + + When the new prefix has been fully integrated into the network + infrastructure and has been tested for stable operation, hosts, + switches, and routers can begin using the new prefix. Once the + transition has completed, the old prefix will not be in use in the + network. + +2.6.1. Transition of DNS Service to the New Prefix + + The DNS service is configured to use the new prefix by removing any + IPv6 addresses from the old prefix from the DNS server configuration. + External references to the DNS servers, such as in the DNS service + from which this DNS domain was delegated, are updated to use the IPv6 + addresses from the new prefix. + +2.6.2. Transition to Use of New Addresses + + When both prefixes are usable in the network, each host can make the + transition from using the old prefix to the new prefix at a time that + is appropriate for the applications on the host. If the host + transitions are randomized, DNS dynamic update mechanisms can better + scale to accommodate the changes to the DNS. + + As services become available through addresses from the new prefix, + references to the hosts providing those services are updated to use + the new prefix. Addresses obtained through DNS will be automatically + updated when the DNS names are resolved. Addresses may also be + obtained through DHCP and will be updated as hosts contact DHCP + servers. Addresses that are otherwise configured must be updated + appropriately. + + It may be necessary to provide users with tools or other explicit + procedures to complete the transition from the use of the old prefix + to the new prefix, because some applications and operating system + functions may be configured in ways that do not use DNS at all or + will not use DNS to resolve a domain name to a new address once the + new prefix is available. For example, a device that only uses DNS to + + + +Baker, et al. Informational [Page 10] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +2.7. Removing the Old Prefix + + Once all sessions are deemed to have completed, there will be no + dependence on the old prefix. It may be removed from the + configuration of the routing system and from any static + configurations that depend on it. If any configuration has been + created based on DNS information, the configuration should be + refreshed after the old prefixes have been removed from the DNS. + + During this phase, the old prefix may be reclaimed by the provider or + Regional Internet Registry that granted it, and addresses within that + prefix are removed from the DNS. + + In addition, DNS reverse maps for the old prefix may be removed from + the primary name server and the zone delegation may be removed from + the parent zone. Any DNS, DHCP, or SLAC timers that were changed + should be reset to their original values (most notably the DNS + forward map TTL). + +2.8. Final Condition: Stable Using the New Prefix + + This is equivalent to the first state, but using the new prefix. + + + +Baker, et al. Informational [Page 11] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +3. How to Avoid Shooting Yourself in the Foot + + 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 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. + +3.1. Applications Affected by Renumbering + + 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. + + 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 that 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 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 + domain names only once and use the resulting IP addresses until the + element is restarted. These static configurations complicate the + process of renumbering, requiring administration of all of the static + information and manual configuration during a renumbering event. + + Because switches and routers are usually single-purpose devices, the + user interface and operating functions (software and hardware) are + often better integrated than independent services running on a server + platform. Thus, it is likely that switch vendors and router vendors + + + + +Baker, et al. Informational [Page 12] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +3.3. Ingress Filtering + + An important consideration in 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]. + +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), it may result in route flaps throughout the + network. + + o If the two systems choose differently (one uses the old address + and one uses the new address), a stable routing outage occurs. + + This is not addressed by proposals such as [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. + + + +Baker, et al. Informational [Page 13] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +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 + contain addresses that must be reconfigured manually during a + renumbering event. There is currently no easy way to automate the + update of these addresses, as the updates require both complex trust + relationships and automation to verify them. For instance, a reverse + zone is delegated by an upstream ISP, but there is currently no + mechanism to note additional delegations. + +4.2. Management of the Reverse Zone + + In networks where hosts obtain IPv6 addresses through SLAC, updates + of reverse zone are problematic because of lack of trust relationship + between administrative domain owning the prefix and the host + assigning the low 64 bits using SLAC. For example, suppose a host, + H, from organization A is connected to a network owned by + organization B. When H obtains a new address during a renumbering + event through SLAC, H will need to update its reverse entry in the + DNS through a DNS server from B that owns the reverse zone for the + new address. For H to update its reverse entry, the DNS server from + B must accept a DDNS request from H, requiring that an inter- + administrative domain trust relationship exist between H and B. The + IETF should develop a BCP recommendation for addressing this problem. + +5. Security Considerations + + The process of renumbering is straightforward in theory but can be + difficult and dangerous in practice. The threats fall into two broad + categories: those arising from misconfiguration and those that are + actual attacks. + + Misconfigurations can easily arise if any system in the network + "knows" the old prefix, or an address in it, a priori and is not + configured with the new prefix, or if the new prefix is configured in + a manner that replaces the old instead of being co-equal to it for a + period of time. Simplistic examples include the following: + + + + + + + +Baker, et al. Informational [Page 14] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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 + + + +Baker, et al. Informational [Page 15] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +6. Acknowledgements + + 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, + Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, + Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain. + + Some took it on themselves to convince the authors that the concept + of network renumbering as a normal or frequent procedure is daft. + 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 who will + + + +Baker, et al. Informational [Page 16] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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". + +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. + + [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. + +7.2. Informative References + + [Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. + Brodie, "On War, Chapter VII, 'Friction in War'", June + 1989. + + + + + + +Baker, et al. Informational [Page 17] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + [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. + + + + + +Baker, et al. Informational [Page 18] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Baker, et al. Informational [Page 19] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +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 that are ignored in these + calculations: + + o the time it takes for the administrators to make the changes; + + o the time it may take to wait for the DNS update, if the + secondaries are only updated at regular intervals, and not + immediately; and + + o the time the updating to all the secondaries takes. + + Assume the use of NOTIFY [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. + + + +Baker, et al. Informational [Page 20] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + + 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. + +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 + + + Eliot Lear + Cisco Systems GmbH + Glatt-com 2nd Floor + CH-8301 Glattzentrum + Switzerland + + Phone: +41 1 878 9200 + 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 + + + + + + + + + + +Baker, et al. Informational [Page 21] + +RFC 4192 Renumbering IPv6 Networks September 2005 + + +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- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Baker, et al. Informational [Page 22] + |