--- 1/draft-ietf-v6ops-renumbering-procedure-00.txt 2006-02-05 02:08:19.000000000 +0100 +++ 2/draft-ietf-v6ops-renumbering-procedure-01.txt 2006-02-05 02:08:19.000000000 +0100 @@ -1,209 +1,247 @@ IPv6 Operations Working Group F. Baker Internet-Draft E. Lear -Expires: August 5, 2004 R. Droms +Expires: January 6, 2005 R. Droms Cisco Systems - February 5, 2004 + July 8, 2004 Procedures for Renumbering an IPv6 Network without a Flag Day - draft-ietf-v6ops-renumbering-procedure-00 + draft-ietf-v6ops-renumbering-procedure-01 Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I 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. + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. + 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 August 5, 2004. + This Internet-Draft will expire on January 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the steps in a procedure that can be used to transition from the use of an existing prefix to a new prefix in a network. 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 - 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 . . . . . . . . . . . . . . . . . . . . 6 - 2.2.2 Mechanisms for address assignment to interfaces . . . . . . 7 - 2.3 Configuring network elements for the new prefix . . . . . . 7 - 2.4 Adding new host addresses . . . . . . . . . . . . . . . . . 9 - 2.5 Stable use of either prefix . . . . . . . . . . . . . . . . 9 - 2.6 Transition from use of the old prefix to the new prefix . . 9 - 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 . . . . . . . . 11 - 3. How to avoid shooting yourself in the foot . . . . . . . . . 11 - 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . . 11 - 3.2 Renumbering network elements . . . . . . . . . . . . . . . . 12 - 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 13 - 4. Call to Action for the IETF . . . . . . . . . . . . . . . . 13 - 4.1 Dynamic updates to DNS across administrative domains . . . . 13 - 4.2 Management of the inverse zone . . . . . . . . . . . . . . . 13 - 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 - Informative References . . . . . . . . . . . . . . . . . . . 16 - A. Managing Latency in the DNS . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . . 20 + 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 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 the use of new addresses . . . . . . . . 10 + 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11 + 2.8 Final condition: stable using the new prefix . . . . . . . 12 + + 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 + 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 + 3.2 Renumbering network elements . . . . . . . . . . . . . . . 13 + 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 + + 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 + 4.1 Dynamic updates to DNS across administrative domains . . . 15 + 4.2 Management of the inverse zone . . . . . . . . . . . . . . 15 + + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 + 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + + A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22 + + Intellectual Property and Copyright Statements . . . . . . . . 24 1. Introduction - The Prussian military theorist Carl von Clausewitz [20] wrote, - "Everything is very simple in war, but the simplest thing is + 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 [8] network without a "flag day". The procedure is + 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 - [6]. This document also contains recommendations for application - design and network management which, if taken seriously, may avoid or - minimize the impact of the issues. + [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 network elements and hosts 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 [1][2] or configured into network elements and - applications will be replaced by the appropriate addresses from the - new prefix. + services like DNS [RFC1034][RFC1035] or configured into network + elements 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 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. 1.2 Terminology - DDNS: Dynamic DNS [7][14]; DDNS updates can be secured through - the use of SIG(0)[11][13] and TSIG [12] + DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through + the use of SIG(0)[RFC2535][RFC2931] and TSIG [RFC2845] - DHCP prefix delegation: An extension to DHCP [16] to automate the - assignment of a prefix; for example from an ISP to a customer[17] + 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 which 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 [15], assigned to a link + link prefix: A prefix, usually a /64 [RFC3177], assigned to a link Network element: Any network device, such as a router, switch or firewall - SLAC: StateLess Address autoConfiguration [10] + 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 which - may include prefixes or addresses that are affected by renumbering, - and gives some guidance about how the work required during - renumbering might be minimized: + renumbered network. The following list gives some of the places + which may include prefixes or addresses that are affected by + renumbering, and gives some guidance about how the work required + during renumbering might be minimized: Link prefixes assigned to links: Each link in the network must be assigned a link prefix from the new prefix. IPv6 addresses assigned to interfaces on network elements: These addresses are typically assigned manually, as part of configuring network elements. Routing information propagated by network elements - Link prefixes advertised by network elements [9] + Link prefixes advertised by network elements [RFC2461] Ingress/egress filters ACLs and other embedded addresses on network elements IPv6 addresses assigned to interfaces on hosts: Use of StateLess - Address Configuration [10] (SLAC) or DHCP [16] can mitigate the - impact of renumbering the interfaces on hosts. + Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can + mitigate the impact of renumbering the interfaces on hosts. 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. IPv6 addresses and other configuration information provided by DHCP 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. While + 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 need also 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 which 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 @@ -279,34 +317,35 @@ 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, 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 network device to - manage its own DNS information through Dynamic DNS (DDNS) [7][14]. - Authentication of these DDNS updates is strongly recommended, and can - be accomplished through the use of either TSIG, and SIG(0). Both TSIG - and SIG(0) require configuration and distribution of keys to end - hosts and name servers in advance of the renumbering event. + manage its own DNS information through Dynamic DNS (DDNS) + [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly + recommended, and can be accomplished through the use of either TSIG, + and SIG(0). Both TSIG and SIG(0) require configuration and + distribution of keys to end 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: + extend the lifetimes on assigned addresses. This delay can be + reduced in two ways: o Prior to the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) can be reduced. o The DHCP Reconfigure message can be sent from the server to the hosts to cause the hosts to contact the server. immediately 2.3 Configuring network elements for the new prefix @@ -320,32 +359,32 @@ 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. The new link prefixes may be advertised by the network elements, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes; in particular the "autonomous - address-configuration" flag [9] should not be set in the + address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes. Network elements may have IPv6 addresses from the new link prefixes assigned to interfaces, taking care that this assignment does not interfere with the use of IPv6 addresses from the old prefix and does not cause the new link prefix to be advertised to hosts. 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 [17] and other automated configuration tools. + 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 @@ -444,30 +483,30 @@ 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, - please see [18]. + please see [I-D.ietf-dnsop-ipv6-dns-issues]. - The transition of critical services, such as DNS, DHCP, NTP [3] 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. + 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 @@ -502,23 +541,23 @@ with the IP addresses for specific services, the boot servers of routers and switches, etc. 3.1 "Find all the places..." Application designers frequently take short-cuts to save memory or increase responsiveness, and a common short-cut is to use static configuration of IP addresses rather than DNS translation to obtain the same. The downside of such behavior should be apparent; such a poorly designed application cannot even add or replace a server - easily, much less change servers or reorganize its address space. The - short-cut ultimately becomes expensive to maintain and hard to change - or replace. + easily, much less change servers or reorganize its address space. + The short-cut ultimately becomes expensive to maintain and hard to + change or replace. As a result, in view of the possibility that a network may need to be renumbered in the future, any application: o should obtain addresses of other systems or services from the DNS, rather then having those addresses manually configured, o must obtain a new translation if a new session is opened with the same service after the lifetime of the DNS RR expires, @@ -563,21 +602,21 @@ 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, 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" [19]. + Multihomed Networks" [RFC3704]. 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 @@ -587,91 +626,92 @@ 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 inverse 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. + 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 which 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 which replaces the old instead of being co-equal to it for a period of time. Simplistic examples include: 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 SSH to its only IPv6 address, and replacing - the old address with the new address: Because the TCP connection used - by SSH is using the old, no longer valid IPv6 address, the SSH - session will be terminated and you will have to use SSH through - the new address for additional configuration changes. + 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, allow the network to settle, and then remove the old obviates this class of issue. A special consideration applies when some devices are only occasionally used; the administration must allow sufficiently long in Section 2.6 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 the new prefix but not both. Such DNS names provide a means 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 in Section 2.3 and - the old prefix removed in Section 2.7. + 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 the new prefix but not both. Such DNS names + provide a means 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 + in Section 2.3 and the old prefix removed in Section 2.7. 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 [10] renumbers hosts. Dynamic DNS - provides a capability for updating DNS accordingly. Managing + 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 @@ -681,101 +721,112 @@ 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 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 Scott Bradner, Sean Convery, Roland - Dobbins, Peter Elford, Bill Fenner, Tony Hain, Craig Huegen, - Christian Huitema, Hans Kruse, Laurent Nicolas, Michel Py, Pekka - Savola, John Schnizlein, Fred Templin, Michael Thomas, Ole Troan, - Harald Tveit Alvestrand, Jeff Wells and Dan Wing. + 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 author 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 and Pekka Savola described the ingress filtering - issues. + Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described + the ingress filtering issues. -Informative References +7. References - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. +7.1 Normative References - [2] Mockapetris, P., "Domain names - implementation and + [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. - [3] Mills, D., "Network Time Protocol (Version 3) Specification, - Implementation", RFC 1305, March 1992. + [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, + January 1997. - [4] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August - 1996. + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. - [5] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", RFC 1996, August 1996. + [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. - [6] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January - 1997. + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. - [7] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. + [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. - [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. - [9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. +7.2 Informative References - [10] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + [Clausewitz] + von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, + "On War, Chapter VII, 'Friction in War'", June 1989. - [11] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. + [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-07 (work in progress), + May 2004. - [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, March 1992. - [13] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. - [14] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. - [15] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC - 3177, September 2001. + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. - [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. - [17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", - draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in - progress), October 2003. + [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. - [18] Durand, A. and J. Ihren, "Operational Considerations and Issues - with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-03 (work in - progress), December 2003. + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. - [19] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", draft-savola-bcp38-multihoming-update-03 (work in - progress), December 2003. + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. - [20] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On - War, Chapter VII, 'Friction in War'", June 1989. + [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. Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: 408-526-4257 @@ -808,24 +859,24 @@ 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 [5] and IXFR [4] 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. + 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's 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 @@ -854,61 +905,51 @@ 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's uncertain what kind of (address) information is returned from the DNS. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to + 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. + 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 which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -Full Copyright Statement + 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. - Copyright (C) The Internet Society (2004). All Rights Reserved. +Disclaimer of Validity - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. + 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. - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. +Copyright Statement - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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 (C) The Internet Society (2004). 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.