[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 4192

IPv6 Operations Working Group                                   F. Baker
Internet-Draft                                                   E. Lear
Expires: August 5, 2004                                         R. Droms
                                                           Cisco Systems
                                                        February 5, 2004


     Procedures for Renumbering an IPv6 Network without a Flag Day
               draft-ietf-v6ops-renumbering-procedure-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   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 Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 5, 2004.

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.






Baker, et al.            Expires August 5, 2004                 [Page 1]


Internet-Draft         Renumbering IPv6 Networks           February 2004


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



















Baker, et al.            Expires August 5, 2004                 [Page 2]


Internet-Draft         Renumbering IPv6 Networks           February 2004


1. Introduction

   The Prussian military theorist Carl von Clausewitz [20] wrote,
   "Everything is very simple in war, but the simplest thing is
   difficult. These difficulties accumulate and produce a friction,
   which no man can imagine exactly who has not seen war. ... So in war,
   through the influence of an "infinity of petty circumstances" which
   cannot properly be described on paper, things disappoint us and we
   fall short of the mark." Operating a network is aptly compared to
   conducting a war. The difference is that the opponent has the futile
   expectation that homo ignoramus will behave intelligently.

   A "flag day" is a procedure in which the network, or a part of it, is
   changed during a planned outage, or suddenly, causing an outage while
   the network recovers. Avoiding outages requires the network to be
   modified using what in mobility might be called a "make before break"
   procedure: the network is enabled to use a new prefix while the old
   one is still operational, operation is switched to that prefix, and
   then the old one is taken down.

   This document addresses the key procedural issues in renumbering an
   IPv6 [8] 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.

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.



Baker, et al.            Expires August 5, 2004                 [Page 3]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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]

   DHCP prefix delegation: An extension to DHCP [16] to automate the
      assignment of a prefix; for example  from an ISP to a customer[17]

   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

   Network element: Any network device, such as a router, switch or
      firewall

   SLAC:        StateLess Address autoConfiguration [10]


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:

   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.





Baker, et al.            Expires August 5, 2004                 [Page 4]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   Routing information propagated by network elements

   Link prefixes advertised by network elements  [9]

   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.

   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.


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
   prefix as appropriate to avoid disruption of applications.  Once all
   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.



Baker, et al.            Expires August 5, 2004                 [Page 5]


Internet-Draft         Renumbering IPv6 Networks           February 2004


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 doesn't explicitly
   appear in the configuration of any specific network element 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 network elements, 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.

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.




Baker, et al.            Expires August 5, 2004                 [Page 6]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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, 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.

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:

   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

   In this step, network elements 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



Baker, et al.            Expires August 5, 2004                 [Page 7]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   to interfaces on the network elements. 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. 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
   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.

   While the new prefix is being added, it will of necessity not be
   working everywhere in the network, and unless properly protected by
   some means such as ingress and egress access lists, the network may
   be attacked through the new prefix in those places where it is
   operational.

   Once the new prefix has been added to the network infrastructure,
   access-lists, route-maps and other network configuration options that
   use IP addresses should be checked to ensure that hosts and services
   that use the new prefix will behave as they did with the old one.
   Name services other than DNS and other services that provide
   information that will be affected by renumbering must be updated in
   such a way as to avoid responding with stale information. There are
   several useful approaches to identify and augment configurations:

      Develop a mapping from each network and address derived from the
      old prefix to each network and address derived from the new
      prefix. Tools such as the UNIX "sed" or "perl" utilities are
      useful to then find and augment access-lists, route-maps, and the
      like.

      A similar approach involves the use of such mechanisms as DHCP
      prefix delegation to abstract networks and addresses.




Baker, et al.            Expires August 5, 2004                 [Page 8]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   Network elements 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 are in place and
   tested, IPv6 addresses from the new prefix may be assigned to host
   interfaces. These IPv6 addresses may be assigned through SLAC, DHCP,
   and manual processes. If SLAC is used in the network, the network
   elements 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 IPv6
   addresses to hosts.

   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, while automating the update of the reverse
   zone may be more difficult as discussed in Section 4.2.

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 and
   network elements can begin using the new prefix. Once the transition
   has completed the old prefix will not be in use in the network.





Baker, et al.            Expires August 5, 2004                 [Page 9]


Internet-Draft         Renumbering IPv6 Networks           February 2004


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 the 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
   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].

   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



Baker, et al.            Expires August 5, 2004                [Page 10]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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 registries are informed that the old prefix is
   no longer in use, and addresses within that prefix are removed from A
   records associated with name servers and the corresponding name
   server configurations.

   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.

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 which are not under the control of the network administrator or
   are manually configured. Examples of such devices include voice over
   IP (VoIP) telephones with static configuration of boot or name
   servers, dedicated devices used in manufacturing that are configured
   with the IP addresses for specific services, the boot servers of
   routers and switches, etc.

3.1 "Find all the places..."

   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



Baker, et al.            Expires August 5, 2004                [Page 11]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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.

   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,

   o  when addresses are configured rather than translated, should
      provide a convenient programmatic method to reconfigure the
      addresses that can be executed using a script or its equivalent.

   Application designers, equipment vendors, and the Open Source
   community should take note. There is an opportunity to serve their
   customers well in this area, and network operators should take note
   to either develop or purchase appropriate tools.

3.2 Renumbering network elements

   The configuration and operation of network elements may be designed
   to use static configuration with IP addresses or 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 network elements 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 network element vendors can design
   and implement consistent support for renumbering across all of the
   functions of network elements.

   To better support renumbering, network elements can:

   o  use domain names for configuration wherever possible, and should
      resolve those names using the DNS when the lifetime on the name
      expires

   o  provide uniform support for renumbering in all user interface and
      configuration mechanisms, such as replacement of one prefix with



Baker, et al.            Expires August 5, 2004                [Page 12]


Internet-Draft         Renumbering IPv6 Networks           February 2004


      another through a single command

   o  reconfigure services provided by the network element, such as
      router advertisements and DHCP, for a new prefix with a single
      command


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].

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 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



Baker, et al.            Expires August 5, 2004                [Page 13]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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.

   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



Baker, et al.            Expires August 5, 2004                [Page 14]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   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
   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
   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.

   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.



Baker, et al.            Expires August 5, 2004                [Page 15]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   Christian Huitema and Pekka Savola described the ingress filtering
   issues.

Informative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]   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.

   [4]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
         1996.

   [5]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
         (DNS NOTIFY)", RFC 1996, August 1996.

   [6]   Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
         1997.

   [7]   Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [8]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [9]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [10]  Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [11]  Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [12]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
         2845, May 2000.

   [13]  Eastlake, D., "DNS Request and Transaction Signatures (
         SIG(0)s)", RFC 2931, September 2000.

   [14]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.



Baker, et al.            Expires August 5, 2004                [Page 16]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   [15]  IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC
         3177, September 2001.

   [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.

   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
         draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in
         progress), October 2003.

   [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.

   [19]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
         Networks", draft-savola-bcp38-multihoming-update-03 (work in
         progress), December 2003.

   [20]  von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On
         War, Chapter VII, 'Friction in War'", June 1989.


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
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 527 4020
   EMail: lear@cisco.com







Baker, et al.            Expires August 5, 2004                [Page 17]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   Ralph Droms
   Cisco Systems
   200 Beaver Brook Road
   Boxborough, MA  01719
   US

   Phone: +1 978 936-1674
   EMail: rdroms@cisco.com

Appendix A. Managing Latency in the DNS

   The procedure in this section can be used to determine and manage the
   latency in updates to information a DNS resource record (RR).

   There are several kinds of possible delays which are ignored in these
   calculations:

   o  the time it takes for the administrators to make the changes,

   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.

   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
   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



Baker, et al.            Expires August 5, 2004                [Page 18]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   to both addresses.

   At time TC all the cached references with the old address have
   expired, and all subsequent queries will return the new address.
   After TC (corresponding to the final state described in Section 2.8),
   the TTL on the RR can be set to the initial value TTLOLD.

   The network administrator can choose TTLOLD and TTLNEW to meet local
   requirements.

   As a concrete example, consider a case where TTLOLD is a week (168
   hours), and TTLNEW is an hour.  The preparation for the change of
   addresses begins 169 hours before the address change.  After 168
   hours have passed and only one hour is left, the TTLNEW has
   propagated everywhere, and one can change the address record(s).
   These are propagated within the hour, after which one can restore TTL
   value to a larger value.  This approach minimizes time where it's
   uncertain what kind of (address) information is returned from the
   DNS.
































Baker, et al.            Expires August 5, 2004                [Page 19]


Internet-Draft         Renumbering IPv6 Networks           February 2004


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
   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.

   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

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   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.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   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



Baker, et al.            Expires August 5, 2004                [Page 20]


Internet-Draft         Renumbering IPv6 Networks           February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Baker, et al.            Expires August 5, 2004                [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/