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

Versions: 00 01 02 03 04 05

Network Working Group                                           T. Chown
Internet-Draft                                               M. Thompson
Expires: April 18, 2005                                          A. Ford
                                           University of Southampton, UK
                                                        October 18, 2004



         Things to think about when Renumbering an IPv6 network
                draft-chown-v6ops-renumber-thinkabout-00


Status of this Memo


   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.


   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 April 18, 2005.


Copyright Notice


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


Abstract


   This memo presents a summary of scenarios, issues for consideration
   and IPv6-specific tools for IPv6 network renumbering, i.e.  achieving
   the transition from the use of an existing network prefix to a new
   prefix in an IPv6 network.  Its focus lies not in the procedure for
   renumbering, but as a set of "things to think about" when undertaking
   such a renumbering exercise.  The document is not intended to be
   complete at the -00 phase, and will be enhanced as further
   operational experience is gathered.




Chown, et al.            Expires April 18, 2005                 [Page 1]


Internet-Draft        Renumbering an IPv6 network           October 2004



Table of Contents


   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1  Past IPv4 Renumbering studies in the PIER WG . . . . . . .   4
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   Renumbering Event Triggers . . . . . . . . . . . . . . . . .   5
     3.1  Change of uplink prefix  . . . . . . . . . . . . . . . . .   5
       3.1.1  Migration to new provider  . . . . . . . . . . . . . .   6
       3.1.2  Dial on Demand . . . . . . . . . . . . . . . . . . . .   6
       3.1.3  Provider migration and upstream renumbering  . . . . .   6
       3.1.4  IPv6 transition  . . . . . . . . . . . . . . . . . . .   7
     3.2  Change of internal topology  . . . . . . . . . . . . . . .   7
     3.3  Acquisition or merger  . . . . . . . . . . . . . . . . . .   7
     3.4  Network mobility . . . . . . . . . . . . . . . . . . . . .   8
   4.   Renumbering Requirements . . . . . . . . . . . . . . . . . .   8
     4.1  Minimal disruption . . . . . . . . . . . . . . . . . . . .   8
     4.2  Session survivability  . . . . . . . . . . . . . . . . . .   8
       4.2.1  Short-term session survivability . . . . . . . . . . .   9
       4.2.2  Medium-term session survivability  . . . . . . . . . .   9
       4.2.3  Long-term session survivability  . . . . . . . . . . .   9
   5.   IPv6 Enablers for Renumbering  . . . . . . . . . . . . . . .  10
     5.1  Multi-addressing . . . . . . . . . . . . . . . . . . . . .  10
       5.1.1  Border filtering . . . . . . . . . . . . . . . . . . .  10
       5.1.2  Duration of overlap  . . . . . . . . . . . . . . . . .  11
     5.2  Router Advertisement Lifetimes . . . . . . . . . . . . . .  11
     5.3  Stateful Configuration with DHCPv6 . . . . . . . . . . . .  11
     5.4  Router Renumbering . . . . . . . . . . . . . . . . . . . .  12
     5.5  Prefix Delegation  . . . . . . . . . . . . . . . . . . . .  13
     5.6  Anycast addressing . . . . . . . . . . . . . . . . . . . .  13
     5.7  Multicast  . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.8  Fixed length subnets . . . . . . . . . . . . . . . . . . .  14
     5.9  Multi-homing techniques  . . . . . . . . . . . . . . . . .  14
       5.9.1  Relevance of multi-homing to renumbering . . . . . . .  15
       5.9.2  Current situation with IPv6 multi-homing . . . . . . .  15
     5.10   Unique Local Addressing  . . . . . . . . . . . . . . . .  16
       5.10.1   Private addressing . . . . . . . . . . . . . . . . .  17
     5.11   Mobile IPv6  . . . . . . . . . . . . . . . . . . . . . .  17
       5.11.1   Visited site renumbers when mobile . . . . . . . . .  17
       5.11.2   Home site renumbers when mobile  . . . . . . . . . .  17
       5.11.3   Home site renumbers when disconnected  . . . . . . .  18
   6.   Factors affecting the Renumbering Solution . . . . . . . . .  18
     6.1  With or without a flag day . . . . . . . . . . . . . . . .  18
     6.2  Frequency of renumbering episodes  . . . . . . . . . . . .  18
     6.3  Availability of old prefix . . . . . . . . . . . . . . . .  19
     6.4  Freshness of service data  . . . . . . . . . . . . . . . .  19
     6.5  DNS and explicitly specified IP addresses  . . . . . . . .  20
     6.6  Dual-stack network?  . . . . . . . . . . . . . . . . . . .  20
     6.7  Merging networks . . . . . . . . . . . . . . . . . . . . .  21




Chown, et al.            Expires April 18, 2005                 [Page 2]


Internet-Draft        Renumbering an IPv6 network           October 2004



     6.8  Embedded prefix data . . . . . . . . . . . . . . . . . . .  21
     6.9  Scalability issues . . . . . . . . . . . . . . . . . . . .  22
     6.10   Equipment administrative ownership . . . . . . . . . . .  22
     6.11   Support for Mobility?  . . . . . . . . . . . . . . . . .  23
     6.12   Stateless and Stateful address considerations  . . . . .  23
     6.13   IPv6 NAT Avoidance . . . . . . . . . . . . . . . . . . .  24
     6.14   Policy and Configuration adaption  . . . . . . . . . . .  24
       6.14.1   Packet filters, Firewalls and ACLs . . . . . . . . .  25
       6.14.2   Monitoring tools . . . . . . . . . . . . . . . . . .  26
   7.   Application and service-oriented Issues  . . . . . . . . . .  26
     7.1  Shims and sockets  . . . . . . . . . . . . . . . . . . . .  26
     7.2  Explicitly named IP addresses  . . . . . . . . . . . . . .  27
     7.3  API dilemna  . . . . . . . . . . . . . . . . . . . . . . .  28
     7.4  Server Sockets . . . . . . . . . . . . . . . . . . . . . .  29
   8.   IETF Call to Arms  . . . . . . . . . . . . . . . . . . . . .  29
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  30
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  30
   11.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  30
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  30
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  30
   12.2   Informative References . . . . . . . . . . . . . . . . . .  31
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  33
        Intellectual Property and Copyright Statements . . . . . . .  34





























Chown, et al.            Expires April 18, 2005                 [Page 3]


Internet-Draft        Renumbering an IPv6 network           October 2004



1.  Introduction


   This memo presents a summary of scenarios, issues for consideration
   and IPv6-specific tools for IPv6 network renumbering, i.e.  achieving
   the transition from the use of an existing network prefix to a new
   prefix in an IPv6 network.  This document does not relate the
   procedures for IPv6 renumbering; for such a procedure the reader is
   referred to [1].  The authors plan to use this document, together
   with ongoing operational experience, to refine [1] where necessary,
   to promote that guide from Informational to BCP.


1.1  Past IPv4 Renumbering studies in the PIER WG


   A number of years ago (1996-1997), the Procedures for Internet/
   Enterprise Renumbering (PIER) WG spent time considering the issues
   for IPv4 renumbering.  The WG produced three RFC documents.  In
   RFC1916 [2], a "call to arms" for input on renumbering techniques was
   made.  RFC2071 [3] documents why IPv4 renumbering is required.
   Interestingly, many, but not all, of the drivers have changed with
   respect to IPv6.  In RFC2072 [4], a Router Renumbering Guide, some
   operational procedures are given, much as they are in Baker [1] for
   IPv6.


   Reflection on RFC2071 is interesting, witness the quote: "It is also
   envisioned that Network Address Translation (NAT) devices will be
   developed to assist in the IPv4 to IPv6 transition, or perhaps
   supplant the need to renumber the majority of interior networks
   altogether, but that is beyond the scope of this document."   That
   need however is still very strong, particularly given the lack of
   Provider Independent (PI) address space in IPv6 (in IPv4, PI address
   space exists mainly for historical, pre-CIDR reasons).


   RFC2072 is more interesting in the context of this document.  Some is
   certainly relevant, though much is not, due to the inherent changes
   in IPv6.  For example, there is no CIDR and address aggregation is
   given as mandate.  Also, IPv6 subnets are in effect fixed length (/
   64), so local administrators do not need to resize subnets to
   maximize use of address space as they do in IPv4.


   One core message from RFC2072 that holds true today is that of
   section 4 where the observation is made that renumbering networks
   whilst remaining the same hierarchy of subnets (i.e.  the cardinality
   of the set of prefixes to renumber remains constant) is the 'easiest'
   scenario to renumber; when each "old" prefix can be mapped to a
   single "new" prefix.


   A distinction of this work is that, where the PIER working group
   consider the transition from IPv4 to IPv6 addressing as a renumbering




Chown, et al.            Expires April 18, 2005                 [Page 4]


Internet-Draft        Renumbering an IPv6 network           October 2004



   scenario, we strictly consider only the renumbering from IPv6
   prefixes to other IPv6 prefixes and leave transition to well
   documented techniques such as those from the IPv6 Operations (v6ops)
   working group.


   We will analyse RFC2072 in more detail in updates of this document.


2.  Terminology


   The following terminology is used in this document (to be expanded in
   future revisions):


   o  Site: A network that is undergoing a renumbering procedure,
      ranging from SOHO through to enterprise.


   o  flag day: A transition that involves a planned service outage.



3.  Renumbering Event Triggers


   This section details typical actions that result in the need for a
   renumbering event, and thus define the scenarios for renumbering.


   In many instances, in particular those where no "flag day" is
   involved, the process of renumbering will inevitably lead to a
   scenario where hosts are multi-addressed or multi-homed as part of
   the renumbering procedure.  The relationship between renumbering and
   multi-homing is discussed later in this document.


   In other instances, e.g.  a change in the IPv4 address offered by a
   provider to a site using 6to4 [9], the change offers no overlap in
   external connectivity or addressing, and thus there is no
   multi-homing overlap.


   Triggers may be provider-initiated or customer-initiated.


   Triggers and scenarios for IPv4 renumbering are discussed in RFC2071,
   but many of these are no longer relevant, and in IPv6 some new
   triggers exist, e.g.  those related to network mobility or IPv6
   transition tools.


3.1  Change of uplink prefix


   One of the most common causes for renumbering will be a change in the
   site's upstream provider.  As per RFC3177 [10], the typical
   allocation for an IPv6 site is a /48 size prefix taken from the
   globally aggregated address space of the site's provider.  With IPv6,
   sites are highly unlikely to be able to obtain provider independent




Chown, et al.            Expires April 18, 2005                 [Page 5]


Internet-Draft        Renumbering an IPv6 network           October 2004



   (PI) address space, as have in some cases been obtained in the past
   with IPv4.  Rather, sites use provider assigned (PA) addressing.  As
   a result, if a site changes provider, it must also change its IPv6 PA
   prefix.


3.1.1  Migration to new provider


   In the simplest case, the customer is triggering the renumbering by
   choosing to change the site's upstream provider to a new ISP and thus
   a new PA IPv6 prefix range.  This may simply be in the form of
   selecting a new commercial provider, although there are several other
   possible scenarios, such as changing from a dial-up to a broadband
   connection, or moving from a community wireless connection to a fixed
   broadband connection.


3.1.2  Dial on Demand


   A site may connect intermittently to its upstream provider.  In such
   cases the prefix allocated by the provider may change with each
   connection, as it often does in the case of single IPv4 address
   allocations to SOHO customers today.  Thus the site may receive a
   prefix still in its provider PA range, but the prefix may vary with
   each connection, causing a renumbering event.


   Dynamically assigned IP addresses are common today with dial-up and
   ISDN Internet connections, and to a lesser extent some broadband
   products, particularly cable modems.  Usually with dynamically
   assigned IP addresses on broadband products, the address is only
   likely to change when the customer reconnects, which could be very
   infrequently.


   This case can be mitigated by encouraging ISPs to offer static IPv6
   prefixes to customers.  Where /48 prefixes are provided, a large ISP
   may be forced to require significantly more than the "default" /32
   allocation from an RIR to an ISP to be able to service its present
   and future customer base.  With always-on more common in new
   deployments, provider re-allocation should be less common; however
   the practice of reallocating IPv4 addresses in SOHO broadband
   networks is not uncommon in current broadband ISPs.


3.1.3  Provider migration and upstream renumbering


   A site's upstream provider may need to renumber, due for example to a
   change in its network topology or the need to migrate to a different
   or additional prefix from its Regional Internet Registry (RIR).  This
   will in turn trigger the renumbering of the end site.


   Such renumbering events would be expected to be rare, but it should




Chown, et al.            Expires April 18, 2005                 [Page 6]


Internet-Draft        Renumbering an IPv6 network           October 2004



   be noted that RIR-assigned IPv6 address space is not owned by an ISP.


3.1.4  IPv6 transition


   During transition to IPv6, there are several scenarios where a site
   may have to renumber.  For example, if the site uses 6to4 for access
   and its IPv4 address is dynamically assigned, an IPv6 renumbering
   event will be triggered when the site's IPv4 address changes.


   Another likely renumbering event would be the change of transition
   mechanism, such as from 6to4 to a static IPv6-in-IPv4 tunnel, or from
   any one of those mechanisms to a native IPv6 link.  When changing
   from 6to4 (2002::/16) addresses to native global aggregatable unicast
   addresses (under 2001::/16), renumbering would be unavoidable.  When
   migrating from a tunnelled to a native connection, renumbering may
   not be necessary if the same prefix can be routed natively, however
   this would be provider-dependent.


   In addition, there are likely to be many cases of network renumbering
   occurring when the old 6bone prefix (3FFE::/16) is phased out as per
   RFC3701 [11], and networks still using it will have to renumber.


   Finally, there is at least one transition mechanism, ISATAP [12],
   that uses specially crafted host EUI-64 format addresses.  Should a
   site migrate from ISATAP to use either conventional EUI-64 addressing
   (via stateless address autoconfiguration or perhaps DHCPv6), then
   renumbering would be required at least in the host part of addresses.


3.2  Change of internal topology


   A site may need to renumber all or part of its internal network due
   to a change of topology, such as creating more or less specific
   subnets, or acquiring a larger IPv6 address allocation.  Motivations
   for splitting a link into separate subnets may to meet security
   demands on a particular link (policy for link-based access control
   rules), or for link load management by shuffling popular services to
   more appropriate locations in the local topology.  Link-merging may
   be due to department restructuring within the hosting orgnisation,
   for example.


3.3  Acquisition or merger


   Two networks may need to merge to one due to the acquisition or
   merger of two organisations or companies.  Such a reorganisation may
   require one or more parts of the new network to renumber to the
   primary PA IPv6 prefix.






Chown, et al.            Expires April 18, 2005                 [Page 7]


Internet-Draft        Renumbering an IPv6 network           October 2004



3.4  Network mobility


   This covers various cases of network mobility, where a static or
   nomadic network may obtain different uplink connectivity over time,
   and thus be assigned different IPv6 PA prefixes as the topology
   changes.  One example is the "traditional" NEMO network [13], another
   may be a community wireless network where different sets of nodes
   gain uplink connectivity - typically to the same provider - at
   different times.


4.  Renumbering Requirements


   In this section we enumerate potential specific goals or requirements
   for sites or users undergoing an IPv6 renumber event.


4.1  Minimal disruption


   The renumbering event should cause minimal disruption to the routine
   operation of the network being renumbered, and the users of that
   network.


   Disruption is a hard term to quantify in a generic way, but it can be
   expressed by factors such as:


   o  Application sessions being terminated


   o  Security controls (e.g.  ACLs) blocking access to legitimate
      resources


   o  Unreachability of nodes or networks


   o  Name resolution, directory and configuration services providing
      invalid (out-of-date) address data


   o  Limitation of network management visibility


   o  ...  (more in future revisions)



4.2  Session survivability


   The concept of session survivability is catered for by [1] in that
   new sessions adopt either old or new prefix based on the state of the
   renumbering process.  However, other approaches to renumbering
   networks may be appropriate in certain deployments, such as where
   "flag days" are unavoidable or where two live prefixes are being
   "swapped".  In these cases, further consideration for existing
   sessions (their longevity, frequency, independence across




Chown, et al.            Expires April 18, 2005                 [Page 8]


Internet-Draft        Renumbering an IPv6 network           October 2004



   interactions, etc.) is required.


   Some protocols are specifically geared to aid session survivability,
   e.g.  the Stream Control Transmission Protocol (SCTP) [14], and may
   prove valuable in mission-critical renumbering scenarios, in
   particular the extension that enables the dynamic addition and
   removal of IP addresses from an SCTP endpoint association [15].


   Sessions may be administratively maintained, such as NFS mounts for
   user filestore, or they may be user-driven, e.g.  long-running ssh
   sessions.


   In general, it is important to consider how TCP and the applications
   above it handle the connection failures that may result from a change
   in address.


   There are different classes of session duration, as described in the
   following sections.


4.2.1  Short-term session survivability


   A typical short-term session would involve a request-response
   protocol, such as HTTP, where a new network connection is initiated
   per transaction, or at worst for a small transaction set.  In such
   cases the migration to a new network prefix is transparent: the
   client can use the new prefix in new transactions without
   consequence.  Some applications, however, may be skewed by such a
   shift in connection source for the same entity 'user', for example
   applications that use recent connection history as a cue to identity
   (e.g.  POP-before-SMTP as used by many dial-on-demand ISP customers
   [32]), or for applications that care about connection statistics (the
   same user web-browsing "session" may be split into two where a
   renumbering event occurs in-between client transactions).


4.2.2  Medium-term session survivability


   A medium-term session is typified by an application or service that
   may persist for perhaps a period of a few minutes up to a period of a
   day or so.  This might involve a TCP-based application that is left
   running during a working day, such as an interactive shell (SSH) or a
   large file download.


4.2.3  Long-term session survivability


   Long term sessions may typically run for several days, if not weeks
   or months.  These might typically include TCP-based NFS mounts, or
   long-running TCP applications.  Sessions in this context may also
   include those applications that, once started, do not re-resolve




Chown, et al.            Expires April 18, 2005                 [Page 9]


Internet-Draft        Renumbering an IPv6 network           October 2004



   names and so repeatedly open new connections or send new datagrams to
   the same (as bound at time of initialisation) address throughout
   their execution lifetime.  Even if at API-level applications do
   attempt to re-resolve the symbol to which they desire to connect, the
   behaviour of the resolvers is unclear as to whether mappings are
   refreshed from the naming service, and as such even if the
   renumbering site does update it's DNS (or NIS, LDAP database etc.),
   the local result may indeed be cached without any indication passed
   back up to the application as to how 'old' said binding information
   is.


5.  IPv6 Enablers for Renumbering


   This section documents features of IPv6, or IP-related technologies
   not previously (or widely) available for IPv4, that assist in
   renumbering.


5.1  Multi-addressing


   As per RFC2373 [16], IPv6 hosts may be multi-addressed.  This means
   that multiple unicast addresses can be assigned and active on the
   same interface.  These addresses can have different reachabilities
   ('scopes' such as link-local or global), different statuses including
   'preferred' and 'deprecated', and may be ephemeral in nature (such as
   care-of addresses when attached to a foreign network [17].  RFC3484
   address selection semantics [5] determine which of the "MxN" address
   pairs to use for communication in the general case.


   During a renumbering episode, the addition of an extra address for an
   endpoint does not add significantly to the complexity, and the
   (source and destination) address selection mechanisms specified by
   RFC3484 hold (but are currently at varying stages of implementation
   in operating systems).  RFC3484 also specifies policy hooks to allow
   administrative override of the default address selection behaviour,
   for example to specifically lock-down a source prefix to select for a
   set of particular destinations.  Where this policy-based address
   selection was designed for transition from IPv4 and early IPv6
   multi-homing considerations, it is perceived likely to be of benefit
   to bespoke renumbering tool development.


   Experiments to validate the correctness of common IPv6
   implementations with regards RFC3484 and other aspects in the context
   of renumbering are on-going and will be reported in future versions
   of this memo.


5.1.1  Border filtering


   One caveat that arises when assigning multiple globally reachable




Chown, et al.            Expires April 18, 2005                [Page 10]


Internet-Draft        Renumbering an IPv6 network           October 2004



   addresses to node interfaces is that of site ingress filtering: not
   only is it the norm for sites to filter at their border router
   traffic that is not destined to local subnets, but it is also
   increasingly common for sites to filter on egress to prevent
   administratively local addresses (such as the, now deprecated,
   site-local prefix) 'leaking' traffic or for malconfigured hosts (e.g.
   visitors with manually configured stacks without Mobile IPv6) from
   sourcing traffic that cannot be routed back.


5.1.2  Duration of overlap


   A key operational decision when renumbering is enforced due to a
   change in connectivity provider is how long to sustain the overlap of
   two live prefixes.  The trade-off to be made is the cost of
   maintaining two contracts with separate providers against the
   'smoothness' of the transition to the new prefix as regards local
   administration overheads, service migration, etc.  Where larger
   corporations can likely suffer the increased financial costs, SMEs
   and SOHOs might consider as little as one month's overlap too
   expensive, and so Baker's State 5 (Stable use of either prefix) [1]
   unattainable


   In some cases, there may be technical reasons for the overlap to not
   be feasible, such as with xDSL provision where the new service is a
   drop-in replacement for the old and the two cannot co-exist (for
   example, because the provision of the service requires the whole
   circuit resource from exchange to customer).


5.2  Router Advertisement Lifetimes


   RFC2462 (IPv6 Stateless Autoconfiguration) [6] specifies the
   technique for expiring assigned prefixes and then invalidating them,
   such that a network has opportunity to gracefully withdraw a prefix
   from service whilst not terminally disrupting on-going applications
   that use addresses under it.  Section 5.5.4 of RFC2462 in particular
   details the procedure for deprecation and subsequent invalidation.


   By mandating as a node requirement the ability to phase out addresses
   assigned to an interface, network renumbering is readily facilitated:
   subnet routers update the pre-existing prefix and mark them as
   'deprecated' with a scheduled time for expiration and then advertise
   (when appropriate) the new prefix that should be chosen for all
   outgoing communications.


5.3  Stateful Configuration with DHCPv6


   As opposed to stateless autoconfiguration, IPv6 stateful or managed
   configuration can be achieved through the deployment of DHCPv6.




Chown, et al.            Expires April 18, 2005                [Page 11]


Internet-Draft        Renumbering an IPv6 network           October 2004



   Factors concerning the impact of stateful and stateless configuration
   are considered in Section 6.12.


   Section 18.1.8 of [18] details how a node should respond to the
   receipt of stateful configuration data from a DHCPv6 server where the
   lifetime indicated has expired (is zero).  Section 19.4.1 details how
   clients should respond to being instructed by DHCPv6 servers to
   reconfigure (potentially forceful renumbering).  Section 22.6 details
   how prefix validity time is conveyed (c.f.  the equivalent data in
   SLAAC's Router Advertisement).


5.4  Router Renumbering


   RFC2894 [7] defines a mechanism for renumbering IPv6 routers
   throughout a network using a bespoke ICMP message type for
   manipulating the set of prefixes deployed throughout subnets.
   Through the use of prefix matching and a rudimentary algebra for
   bit-wise manipulation of prefix data bound to router interfaces, the
   mechanism enables administrators to affect every router within a
   scope from a single administration workstation.


   The approach utilises multicast communication to the all-routers
   address, FF05::2, scoped to the entire 'site' as determined by router
   filter policy to distribute configuration updates to all (compliant)
   routers.  The mechanism also works with more specific addressing
   modalities, such as link-local multicast (FF02::2) to reach all
   routers on a specific link, or directed unicast to affect a specific
   router instance.


   Example use cases cited are for deploying global routing prefixes
   across a hierarchical network where site-locals already exist
   (presumably updated now to Unique Local Addresses), and for
   renumbering from an existing prefix to another in a similar manner to
   that proposed by Baker (i.e.  the deployment of a new prefix
   alongside the existing one, which is deprecated and subsequently
   expired and removed - using the same mechanism described.


   Note that RFC2894 was developed before the shift in recommendation
   away from the [TNS]LA address allocations of RFC2373, although the
   techniques documented for renumbering the global routing prefix and
   subnet ID components in the updated address allocation
   recommendations (RFC3513) are not affected by the architectural
   change.


   As with other prefix assignment techniques, it is the responsibility
   of the node to correctly deprecate and then expire the use of a
   previously assigned prefix as defined by the IPv6 Neighbour Discovery
   protocol, RFC2461 [8], section 4.6.2 describing the Prefix




Chown, et al.            Expires April 18, 2005                [Page 12]


Internet-Draft        Renumbering an IPv6 network           October 2004



   Information option in particular.


5.5  Prefix Delegation


   Where stateless autoconfiguration enables hosts to request prefixes
   from link-attached routers, prefix delegation enables routers to
   request a prefix for advertising from superior routers, i.e.  routers
   closer to the top of the prefix hierarchy - typically topologically
   closer, therefore, to the provider.  Once the router has been
   delegated prefix(es), it can begin advertising it to the connected
   subnet (perhaps even multi-link) with indicators for hosts to use
   stateful (DHCPv6) or stateless address autoconfiguration as per
   RFC2461.


   There have been two principal approaches to prefix delegation
   proposed: HPD (Hierarchical Prefix Delegation for IPv6), which
   proposed the use of bespoke ICMPv6 messages for prefix delegation,
   and IPv6 Prefix Options for Dynamic Host Configuration Protocol [19],
   which defines a DHCPv6 option type.  Of the two approaches, the
   DHCPv6-based approach has received wide support and is on the
   standards track.


5.6  Anycast addressing


   Syntactically indistinguishable from unicast addresses, 'anycast'
   offers nodes a mean to route traffic toward the topologically nearest
   instance of a service (as represented by an IP address), relying on
   the routing infrastructure to deliver appropriately.  RFC2526 [20]
   defines a set of reserved subnet anycast addresses within the highest
   128 values of the 64 bit IID space.  Of that space, currently only
   three are used, of which one is actively used and is for discovery of
   Mobile IPv6 Home-Agents.  At the current time there are no 'global'
   well-known unicast addresses assigned by IANA.


   In order to participate using anycast, nodes need to be configured as
   routers (to comply with RFC2373 [16]) and exchange routing
   information about the reachability of the specific anycast address.
   This extra level of administration requirement is negligible in the
   context of services as the services themselves would need
   configuration anyway.


   There have been proposals to define globally well-known anycast
   addresses for core services, such as the DNS [21].  Anycast scales
   with regard subnet-anycast in the sense that the global routing
   prefix used to direct packets to an anycast node within a site is no
   different from any other host, and therefore nothing 'special' in the
   global routing architecture is required - only locally within the
   site does the multi-node nature of anycast need to be considered.




Chown, et al.            Expires April 18, 2005                [Page 13]


Internet-Draft        Renumbering an IPv6 network           October 2004



   However, for global well-known anycast addresses to be defined,
   host-specific routes will need to be advertised and distributed
   throughout the entire Internet.  As acknowledged by section 2.6 of
   [22], this presents a severe scaling limit and it is expected that
   support for global anycast sets may be unavailable or very
   restricted.


5.7  Multicast


   IPv6 supports an enriched model of multicast compared to IPv4 in that
   there are well-defined scopes for multicast communication that are
   readily expressed in the protocol's addressing architecture.
   Multicast features much more prominently in the core specification,
   for example it is the enabling technology for the Neighbour Discovery
   protocol (a much more efficient approach to layer 2 address discovery
   than compared to ARP with IPv4).


   Where multicast is used to discover the availability of core services
   (e.g.  all DHCPv6 servers in a site will join FF02::1:3), the effect
   of renumbering the unicast address of those services will mean that
   the services are still readily discoverable without resorting to a
   (bespoke or otherwise) service location protocol to continue to
   function - particularly if ULAs are not deployed locally as per
   Section 5.10.


5.8  Fixed length subnets


   The IAB/IESG recommendations for IPv6 address allocations [10]
   details some of the motivations behind the change in the addressing
   architecture of IPv6 since its inception, and asserts the current
   state of a 64-bit 'network' part (the prefix) and a 64-bit 'host'
   part (the interface identifier).  Fixing the lower 64 bits to be
   exclusive of routing topology significantly reduces the
   administrative load associated with renumbering and re-subnetting as
   experienced with IPv4 networks previously, for example, to get better
   address utilisation efficiency as networks evolve and provider
   address allocations changed.


   The recommendations also discuss what length of network prefix should
   be allocated to sites, typically provisioning for 16-bits of subnet
   space in which sites can build their topology.  Having such a large
   address space for sites to divide up at their discretion alleviates
   many of the drivers for renumbering discussed during the PIER working
   group's lifetime [3].


5.9  Multi-homing techniques


   A multi-homed site is a site which has multiple upstream providers.




Chown, et al.            Expires April 18, 2005                [Page 14]


Internet-Draft        Renumbering an IPv6 network           October 2004



   A site may be multi-homed for various reasons, however the most
   common are to provide redundancy in case of failure, to increase
   bandwidth, and to provide more varied, optimal routes for certain
   destinations.


   In renumbering, multi-homing will either be a temporary state, during
   the transition, or be a permanent feature of the network
   configuration, which may be being altered during the renumbering.


5.9.1  Relevance of multi-homing to renumbering


   As discussed in section 2, and in particular section 2.5, of [1],
   during the renumbering procedure there will be a period where both
   the old and the new prefixes are stable and valid for the network.
   During such a period, the network will therefore be multi-homed, and
   as such many of the issues relating to multi-homing in IPv6 are also
   relevant, albeit in a small capacity, to the renumbering procedure.
   A stable multi-homed situation must therefore be a requirement for
   renumbering without a 'flag day'.


   In such a situation, however, the multi-homed state will not be
   permanent, and will only exist for the duration for which it is
   required, i.e.  for the period during the renumbering procedure when
   both prefixes should be valid.


   Renumbering can also occur, however, in a network that is already
   multi-homed, for example with redundant links to multiple providers.
   Such a site may wish to renumber for any of the situations given in
   the earlier section, as well as renumbering because of changes in the
   number of upstream providers.  Until the best practice for such a
   situation is defined, however, its effect on renumbering is not a
   focus of this document.


5.9.2  Current situation with IPv6 multi-homing


   Unlike IPv4 multi-homing, where PI address space is relatively easy
   to obtain and thus a site can broadcast its own routing information,
   most IPv6 addresses will be PA addresses and thus the site will have
   no control over routing information.  Multi-homing in IPv6 therefore
   does not necessarily exist in the same way as in IPv4 and the <http:/
   /www.ietf.org/html.charters/multi6-charter.html> working group exists
   to try to find a solution.  Current solutions [23] examine the
   potential for using identifiers within IP to identify a host, as
   opposed to an IP address, so that connections can continue unhindered
   across renumbering events.  Such solutions are, however, very much in
   their infancy and as yet do not provide a stable solution to this
   problem.





Chown, et al.            Expires April 18, 2005                [Page 15]


Internet-Draft        Renumbering an IPv6 network           October 2004



5.10  Unique Local Addressing


   Section 5 of [24] suggests that the use of Local IPv6 addresses in a
   site results in making communication using these addresses
   independent of renumbering a site's provider based global addresses.
   It also points out that a renumbering episode is not triggered when
   merging multiple sites that have deployed centrally assigned unique
   local addresses[25] because the FC00::/8 ULA prefix assures global
   uniqueness.


   When merging two sites that have both deployed FD00::/8 locally
   assigned ULA prefixes, the chance of collision is inherently small
   given the pseudo-random global-ID determination algorithm of [24].
   Consideration of possible collisions may be prudent however unlikely
   the occurrence may be.


   With reference to section 2 of [1], the adoption of ULA to assist in
   network renumbering can be considered a 'seasoning' of Baker's
   renumbering procedure: where interaction between local nodes and
   their services cannot suffer the inherent issues observed when
   migrating to a new aggregatable global unicast prefix, the use of
   FC00::/7 unique local addresses may offer an appropriately stable and
   reliable solution.  The use of ULAs in single-site networks (e.g.
   SOHO) appears straightforward and of immediate benefit with regards
   renumbering episodes triggered by uplink connectivity changes.  How
   their use scales to multi-site (e.g.  Enterprise or use in ISP or
   transit networks) is not so evident.


   The use of ULAs may not necessarily be accompanied by PA addresses.
   If addresses under a PA global routing prefix are not used, some form
   of IPv6 NAT or application layer gateway deployment will be required
   for ULA-only nodes internal to the network to communicate with
   external nodes that are not part of the same ULA topology, that is
   destination nodes that are not part of the same administrative domain
   from which the ULA allocation of the local node is made, nor part of
   a predetermined routing agreement between two organisations utilising
   different ULAs for nodes within their own sites.  ULAs are not
   intended to be routed globally.


   If addresses under a global routing prefix are also deployed, then
   nodes will need to cater for being multi-addressed, e.g.  follow the
   principles laid out in RFC3484 [5].  The administrator should ideally
   be able to set local policy such that nodes use ULAs for intranet
   communications and global addresses for extranet communications.  The
   use of ULAs internally would in principle mitigate against global
   address renumbering of nodes.


   ULAs appear to lend themselves particularly well for long-lived




Chown, et al.            Expires April 18, 2005                [Page 16]


Internet-Draft        Renumbering an IPv6 network           October 2004



   sessions (from the categorisation Section 4.2.3) whose nature is
   intra-site, for example local filestore mounts over TCP-mounted NFS:
   With clients using ULA source addresses to mount filestore using the
   ULA of an NFS server, both client and server can have their global
   routing prefix renumbered without consequence to ongoing local
   connections.


5.10.1  Private addressing


   Whilst not a recommended standards-compliant deployment, sites may
   choose to deploy - or 'keep' deployed in the case of renumbered
   prefixes - otherwise-valid global routing prefixes that they have not
   been allocated by the registries.  Providing that these addresses are
   never routed off-site, such behaviour does not impinge on other sites
   at all except that site that is later allocated the prefix (or
   sub-prefix therefrom) being mis-used.  This is somewhat akin to
   site-local addressing and suffers the very same issues that have
   resulted in that particular architecture of addresses being
   officially deprecated from use.


5.11  Mobile IPv6


   Mobile IPv6 (MIPv6) [17] specifies routing support to permit an IPv6
   host to continue using its "permanent" home address as it moves
   around the Internet.  Mobile IPv6 supports transparency above the IP
   layer, including maintenance of active TCP connections and UDP port
   bindings.  There are a number of issues to take into account when
   renumbering episodes occur where Mobile IPv6 is deployed:


5.11.1  Visited site renumbers when mobile


   When a node is mobile and attached to a foreign network it, like any
   other node on the link, is subject to prefix renumbering at that
   site.  Detecting a new prefix through the receipt of router
   advertisements, the mobile node can then re-bind with its home agent
   informing it of its care-of address - just as if it had detached from
   the foreign network and migrated elsewhere.  Where the node receives
   forewarning of the renumbering episode, the Mobility specification
   suggests that the node explicitly solicits an update of the prefix
   information on its home network


5.11.2  Home site renumbers when mobile


   When mobile, a host can still be contacted at its original (home)
   address.  Should the home network renumber whilst the node is away
   but active (i.e.  having bound to the home agent and registered a
   live care-of address), then it can be informed of the new global
   routing prefix used at the home site through the Mobile Prefix




Chown, et al.            Expires April 18, 2005                [Page 17]


Internet-Draft        Renumbering an IPv6 network           October 2004



   Solicitation and Mobile Prefix Advertisement ICMPv6 messages
   (sections 6.7 and 6.8 of RFC3775 respectively).


5.11.3  Home site renumbers when disconnected


   Finally, if a mobile node is detached (i.e.  no binding with the home
   agent exists with the node present on a foreign network) and the home
   network renumbers, the recommended procedure - documented as an
   appendix to the mobility specification and therefore not necessarily
   proven - is to fall back to alternative methods of 'rediscovering'
   its home network, using the DNS to find the new global routing prefix
   for the home network and therefore the Home Agent's subnet anycast
   address, 'guessing' at what the node's new home address would be on
   the basis of a 64 bit prefix and 64 bit interface identifier, and
   then  attempting to perform registration to bind its new location.


6.  Factors affecting the Renumbering Solution


   There are many aspects of the renumbering procedure that may benefit
   from the development of bespoke renumbering tools (scripts, etc.),
   likely to result from the study of the experimental scenarios
   associated with this work.  This section investigates the various
   factors that should be considered for developing such tools.


6.1  With or without a flag day


   A network may be renumbered with or without a flag day.  In the
   context of this document we are focusing on without a flag day,
   although many of the issues will still apply when renumbering is
   effected with a flag day.


   Despite the similarities, because there is an outage of services when
   renumbering with a flag day, it is not necessary to ensure continuity
   of network connections, and almost all reconfiguration can be done
   during the outage, thus greatly simplifying the task of renumbering.


6.2  Frequency of renumbering episodes


   The many different renumbering scenarios, discussed in Section 3, can
   have vastly different frequencies of renumbering events.  In the case
   of a provider offering only dynamically assigned IP addresses, it
   could be very frequent, for example as frequent as 'per-connection'
   for dial-on-demand services, or weekly for some broadband services.
   Such renumbering events usually only occur when a customer reconnects
   to such services or are explicitly cited in a subscription agreement
   and as such are often pre-determined.


   The renumbering of a site due to upstream renumbering is relevant to




Chown, et al.            Expires April 18, 2005                [Page 18]


Internet-Draft        Renumbering an IPv6 network           October 2004



   all connections from a small dial-up link to a large enterprise.  It
   is of particular interest since the end user has no control over the
   timing or frequency of the renumbering events.  It is expected,
   however, that such events are likely to be very infrequent.


   The other irregular renumbering events are those that occur due to
   end user migrating, either to a new provider, or to a new address
   allocation of their choosing.  The timing of such an event is
   therefore often within the control of the end user (within reason),
   and are also likely to be one-off events, or at the very least,
   highly infrequent.


6.3  Availability of old prefix


   The length of time for which the old prefix remains available has
   impacts on how long can be allowed for the renumbering procedure, and
   the maximum time for which existing sessions could continue.  If end
   users have control over the renumbering procedure (such as when
   changing provider), then they can continue providing the old prefix
   for as long as required, within reason (such as cost aspects).  This
   heavily mitigates the issues of session survivability, and relaxes
   the speed at which hosts must be reconfigured.


   If the end users do not have such control, such as when the upstream
   provider forces the renumbering, the availability of the old prefix
   is determined entirely by the upstream provider's willingness to
   continue providing it, which is likely to be based on the
   technicalities of their own renumbering situation.  The end user
   should therefore not rely on retaining the old prefix for a
   relatively long period of time.  In addition, many situations, such
   as dial-on-demand with dynamic IP addresses, and nomadic networks,
   will lose their old prefix quickly, if not almost instantaneously.


   It would be possible to continue using the old prefix internally,
   even when the external connectivity for that prefix is no longer
   active, for example to keep access to core services such as DNS
   servers while the transition is taking place.  This should, however,
   be considered bad practice in case of route leaking and application
   confusion, and should only be used as a last resort to ensure
   internal continuity of service, if the availability of the old prefix
   is too short to allow a full transition to take place.


6.4  Freshness of service data


   One of the largest issues when renumbering a network will be the
   effect on applications that are already running.  In particular,
   applications that periodically contact a particular host may do an
   initial hostname lookup, and cache the result for use throughout the




Chown, et al.            Expires April 18, 2005                [Page 19]


Internet-Draft        Renumbering an IPv6 network           October 2004



   lifetime of the program.  In such a situation, there is no way for
   the application to find out that the host in question has been
   renumbered, and it should stop using its already cached address.  It
   is therefore recommended that applications should regularly request
   hostname lookups for the desired hosts, leaving the caching to the
   resolver.  It is then up to the resolver to ensure that resource
   record TTLs are observed, and its cached response is updated as
   necessary.


   Despite this, there is still a serious issue in that there is no
   method of caching resolvers knowing when a renumbering event is going
   to take place.  If a typical RR's TTL is one day, then that should be
   reduced not less than a day before the renumbering event, so that
   resolvers will more frequently check for changed records.  This will
   work successfully for a pre-planned renumbering event, but problems
   of stale, cached records will exist if the renumbering event is
   unplanned (e.g.  by receiving a new router advertisement from
   upstream).


   There are also cases where the use of a resolver is not practical,
   such as with packet filter rules.  If a packet filter has been
   configured with explicit hostnames, these are translated to IP
   addresses for fast packet matching.  Such a packet filter is likely
   to need to be reloaded for the DNS changes to be recognised.


   A similar problem exists when a nameserver is renumbered.  If the
   operating system's resolver has cached the nameserver address, it
   will at some point find it unavailable.  To mitigate this problem, it
   is suggested that at least one off-site nameserver is included in the
   configuration.  In addition, well-known anycast addresses (see
   Section 5.6) could be used, so that the client's DNS configuration
   does not need to be changed at all during the renumbering event.


6.5  DNS and explicitly specified IP addresses


   The basic process of renumbering, involving the introduction of a new
   prefix and the deprecation and eventual removal of the old prefix,
   could be hypothetically handled by a special tool, with no manual
   intervention.  Such a tool would have to become significantly more
   complex in order to handle all the cases where IP addresses are
   explicitly specified (a comprehensive list is given in Section
   Section 7.2).  Other particularly notable cases that could be changed
   with a tool, were it to be developed, include DNS zone files and
   DHCPv6 configuration.


6.6  Dual-stack network?


   There are several issues to consider when renumbering a dual-stacked




Chown, et al.            Expires April 18, 2005                [Page 20]


Internet-Draft        Renumbering an IPv6 network           October 2004



   network.  In the simplest case, the IPv4 addresses will be remaining
   the same while the IPv6 addresses are renumbered.  This could, for
   example, be due to an upstream renumbering, a change of IPv6
   transition method (such as a tunnel), or a topology change.  In such
   a case, the IPv4 connectivity remains unchanged, and as such can be
   used as a fallback during the renumbering to assist with session
   continuity, DNS services, etc.


   The other case is when the IPv4 network is being renumbered along
   with the IPv6 network.  Again this could be due to an upstream
   change, a network reconfiguration, or because the two are
   inter-linked - such as with the 6to4 transition mechanism.  In this
   case, it is unlikely that the existence of IPv4 on the network can be
   used for any advantage, and instead many of the same issues are
   likely to be found when renumbering the IPv4 network as for the IPv6
   network, except for the fact that more of the renumbering must be
   manually configured, for example by reconfiguring the stateful IPv4
   DHCP configuration, or even manually configuring IPv4 addresses.


6.7  Merging networks


   Renumbering of all or part of a network due to merging two or more
   smaller networks has many of the concerns already discussed, but it
   may not affect the whole network.  For example, multiple disparate
   networks may be merged together as one entirely new subnet, and thus
   all hosts must be renumbered; but it is also possible that one of the
   networks in the merger retains its prefix, and the other network(s)
   merge with it.


   When the networks merge, the router advertises itself, and the new
   prefix if appropriate, to the new hosts, and Duplicate Address
   Detection (DAD, see Section 5.4 of [6]) must be applied by the new
   hosts to ensure they are not taking addresses already assigned to the
   existing hosts.  Things become a little more complicated, however, in
   the case of link-local addresses.  Hosts are unlikely to re-run the
   DAD algorithm on their link-local addresses after a network merge, so
   there is the possibility of an address conflict.  However, as is
   noted in RFC2462, DAD is not completely reliable, and as such it
   cannot be assumed that initially after a network merge all link-local
   addresses will be unique.


6.8  Embedded prefix data


   IPv6 global routing prefixes can also appear 'embedded' in other
   addressing within a site, and consideration needs to be given to how
   those nodes that use - particularly serve - those addresses
   transition to the new prefix being deployed.





Chown, et al.            Expires April 18, 2005                [Page 21]


Internet-Draft        Renumbering an IPv6 network           October 2004



   One such example are those addresses as per RFC3306 [26], which
   specifies how unicast prefixes can be embedded into multicast
   addresses for the purposes of enabling network operators to identify
   their multicast addresses without the need for an inter-domain
   allocation protocol.  By way of example, a site renumbering away from
   prefix "2001:db8:beef::/48" might have globally-scoped multicast
   addresses in use under the prefix "ff3e:30:2001:db8:beef::/96".  How
   those multicast sources re-source their group addresses requires
   consideration.


6.9  Scalability issues


   During the renumbering transition, there will be a time when two
   prefixes are valid for use.  At this point, there will be a
   considerable amount of configuration that will have to be
   (temporarily) duplicated.  In particular, routing entries on the
   hosts will be doubled, and there will, for a short period, be two
   forward records for every hostname.  Security is another key
   scalability issue.  All access control lists, packet filters, etc,
   will need to be updated to cope with the multiple addresses that each
   host will have.  This could have a noticeable impact on packet filter
   performance, especially if it lead to, for example, the doubling of
   several hundred firewall rules.


   The scalability issues created by the increase in configuration to
   cope with the temporary existence of multiple addresses per host adds
   a complexity in management, but how much so is up to the end-users
   themselves.  A user may choose to do direct transitions of some
   services (such as web servers) from one IP address to another,
   without going through a stage where the service is available on
   either address.  While that is not strictly providing a fully
   seamless transition, it could significantly reduce the management
   complexity, without a significant impact on service, especially if
   the DNS updates are rapid.


   It should also be noted that during a renumbering event, since the
   DNS resource record TTLs are significantly shorter, the primary DNS
   servers for the domains will receive significantly more queries, as
   resolvers do not cache the responses for so long, and regularly check
   back with the master.


6.10  Equipment administrative ownership


   The question of who owns and administers (also, who is authorised to
   administer) the site's access router is an issue in some renumbering
   situations.  In the enterprise scenarios, the liaison between the end
   users and remote admins is likely to be relatively easy; this is less
   likely to be the case for a SOHO scenario.  This is not likely to be




Chown, et al.            Expires April 18, 2005                [Page 22]


Internet-Draft        Renumbering an IPv6 network           October 2004



   a major issue, however, since SOHO renumbering is likely to only be
   required if the remote admins deem it necessary, or if the end user
   is sufficiently technically competent and decides to renumber their
   own network.


6.11  Support for Mobility?


   Renumbering a network which has mobile IPv6 active is a potentially
   complex issue to think about.  In particular, can changed router
   advertisements correctly reach the mobile nodes, and can they be
   correctly renumbered, like a node on the local network? In addition,
   an even more complex issue is what happens when the home agent
   renumbers? Is it possible for the mobile nodes to be informed and
   correctly renumber and continue, or will the link be irretrievably
   broken?


6.12  Stateless and Stateful address considerations


   Most IPv6 networks are likely to be configured using StateLess
   Address AutoConfiguration [6], and in order to work through the
   multi-staged process as documented by Baker [1], the new prefix is
   introduced via router advertisements, and then the old prefix is
   deprecated, and finally removed.


   Initially the router advertisements will contain only the prefix of
   the old network, then for a time they will contain both the old and
   the new, but with a shorter lifetime on the old prefix to indicate
   that it is deprecated.  Finally the router advertisements will
   contain only the new prefix.


   Some IPv6 networks will be configured, at least in part, by Stateful
   Address AutoConfiguration, using DHCPv6 [18].  Here, clients will
   query the DHCPv6 server and be assigned IPv6 addresses with a given
   lifetime.


   The key difference between SLAAC and SAAC, at least from the
   renumbering point-of-view, is that SLAAC is both a 'push' and 'pull'
   protocol (the server can broadcast router advertisements, and the
   clients can request them), where as DHCPv6 is only a 'pull' protocol
   (the server only responds when it is queried by the client).  This
   makes renumbering more complex under a DHCPv6 system, since it should
   be planned in advance, as the lifetimes of the DHCPv6 address
   assignments must be reduced before the event, so that the clients can
   respond in a timely manner and acquire addresses from the new prefix.


   Sometimes, DHCPv6 will be used alongside SLAAC.  SLAAC will provide
   the address assignment, and DHCPv6 will provide additional host
   configuration options, such as DNS servers.  If any of the DHCPv6




Chown, et al.            Expires April 18, 2005                [Page 23]


Internet-Draft        Renumbering an IPv6 network           October 2004



   options are directly related to the IPv6 addresses being renumbered,
   then the configuration must be changed at the appropriate time during
   the renumbering event, even though it itself does not handle the
   address assignments.  Clients of the configuration protocol should
   poll the service to obtain potentially updated ancillary data, such
   as suggested by [27].


   Where DHCPv6 has been employed, careful consideration about the
   configuration of the service is required such that administrators can
   be confident that clients will re-contact the service to refresh
   their configuration data.  As alluded to in sections 22.4 and 22.5 of
   [18], the configurable timers that offer servers the ability to
   control when clients recontacts the server about its configuration
   can be set such that clients rarely (if ever!) connect to validate
   their configuration set.


6.13  IPv6 NAT Avoidance


   RFC2072 stated: "Network address translation (NAT) is a valuable
   technique for renumbering, or even for avoiding the need to renumber
   significant parts of an enterprise."  That is, by 'hiding' the subnet
   topology and making independent of any connectivity provider the
   addressing model used within a site, NATs enable renumbering of
   entire networks because the only device that is renumbered when
   global addressing changes is the outside edge of the NAT devices.


   However, NAT is strongly discouraged in IPv6, not least because they
   obscure identity - the basis for permission, authorisation,
   verification and validation - and thus should not be considered as
   being available as a solution.  A significant reason to deploy IPv6
   is to simplify network and application operation by NAT removal, for
   example to provide true end-to-end connectivity, to make simple the
   gateway between site and Internet, to encourage 'considered' policy
   as regards secure access rather than the weak and dangerous defense
   of hiding behind a NAT.  A more detailed discussion of the
   motivations for 'protecting' the network architecture from NATs can
   be found in [28].


6.14  Policy and Configuration adaption


   Section 3.1 of Baker [1] is aptly titled "Find all the places", and
   serves as a gentle reminder to application developers that embedding
   addresses is bad at best.  Where common UNIX tools such as "grep"
   allow administrators to crawl the file systems of servers for places
   where address information is hard-coded, the proliferation of
   technologies such as NetInfo and other directory- or hive-based
   configuration schemes makes the job of finding all the places that
   addresses are hard-coded intractable.




Chown, et al.            Expires April 18, 2005                [Page 24]


Internet-Draft        Renumbering an IPv6 network           October 2004



   Beyond the call to arms for application and services developers made
   by Baker, and specific to the challenges of renumbering, the
   following security and policy-related services that initial research
   has flagged as particularly troublesome:


6.14.1  Packet filters, Firewalls and ACLs


   Throughout the transition from the old address set to the new, all
   packet filters and firewalls will need to adapt to map policy to both
   sets of addresses - perhaps even selectively as the old addresses
   become deprecated.  Whilst technologies such as Router Renumbering
   and Neighbour Discovery automate to a large extent the transition of
   router and node configurations, and dynamic DNS update for the
   re-mapping of resource records to reflect the new addresses [29], no
   such mechanism exists at present for mechanising the adaption of
   security policy.


   Particularly troublesome policies to administer include egress
   filtering, where packet filters discard outbound packets that have
   source addresses that should not exist within the site, and filtering
   inbound site-local addresses in cases where two organisations are
   renumbering as a step toward merging their networks together
   (although the use of site-local addressing is now deprecated).


   Where renumbering is due to a 'clean break' from previous
   connectivity provider, another consideration is for the ingress
   filtering performed by the provider.  For instance, the new provider
   may refuse to receive into their routing topology those packets whose
   source address is under the old prefix, and likewise for the old
   provider and new prefix.  Whilst it is not the business of the IETF
   to mandate business practice, it is likely that the provision of
   out-of-allocation prefix routing as part of a multi-homing service
   contract would be a chargeable service and not one that an enterprise
   trying to make a clean break away would likely be willing to pay just
   for the duration of transition to their new prefix.


   Beyond the immediate up-stream provider, there are other policy-based
   considerations to take into account when renumbering.  Some
   rudimentary authenticated access mechanisms rely on access queries
   coming from a particular IP network, for example, and so those
   application service providers will need to update their access
   control lists.  Likewise all the internal applications (possibly
   meant for 'internal' eyes only) will have to have their access
   controls updated to reflect the change.  The use of symbolic access
   controls (i.e.  DNS domain names) rather than embedded addresses may
   serve to mitigate much of the distributed administrative load here,
   especially during the mid-renumbering states where both sets of
   addresses are still live and valid.




Chown, et al.            Expires April 18, 2005                [Page 25]


Internet-Draft        Renumbering an IPv6 network           October 2004



6.14.2  Monitoring tools


   Network monitoring and supervisory utilities such as RMON probes,
   etc., are often deployed to monitor network status based on IP
   traffic.  During a renumbering episode, the addresses for which the
   probes should monitoring and the addresses of logging services to
   which the probes report (e.g.  in the case of remote SNMP logging)
   need to be tracked.


   "Helpdesk ops" service liveness monitoring software also poses a
   particular problem where liveness is determined, for example, by a
   null transaction (e.g.  for POP3 mail server, authenticating and
   performing a NOOP) made against a named service instance, if the name
   is by IP then two instances of the liveness test will be required:
   one on the old address to cater for those remote parties that are not
   yet aware of the new address, and one test against the new.


7.  Application and service-oriented Issues


   In this section we highlight issues and common approaches to software
   development that 'disrupt' protocol layering to the extent that
   applications become aware of renumbering episodes, even if
   catastrophic and without knowing how to recover without failing.


   NOTE: This section, like section 6 before it, will evolve as
   experience grows researching the various renumbering strategies in
   controlled experiments - particularly in light of Section 8.


7.1  Shims and sockets


   As discussed in Section 6.14, Baker's draft calls for application
   developers to consider the effects of renumbering whilst applications
   are 'live', particularly as regards caching the results of symbol
   resolution.  Where applications maintain open connections to services
   over a sustained period of time (as opposed to the ephemeral nature
   of protocol interactions such as with HTTP), any change in either
   end's addressing may intrude on the application's execution -
   particularly if the change is abrupt or the session longer than the
   expiry and withdrawal time of the old addresses.


   Various options may be available to minimise the risk of application
   disruption in this instance.  A HIP-like 'shim' [30], as is being
   developed as a candidate solution to the general multi-homing
   problem, removes the tight coupling between a connection and a
   service's topological location: as the renumbering event takes place,
   the locator is updated to reflect the new address topology and the
   application blissfully unaware - a form of layer 3.5 mobility.





Chown, et al.            Expires April 18, 2005                [Page 26]


Internet-Draft        Renumbering an IPv6 network           October 2004



   Alternatively, should the old address space be available such that a
   single (or subnet of) Mobile IPv6 Home Agents be deployed in the
   routing path of the to-be-otherwise-interrupted connection, then the
   endpoint being renumbered could utilise layer 3 mobility once the old
   prefix removed from its link, i.e.  register with the Home Agent in
   the old prefix topology - presumably in the provider's network,
   formerly upstream from the site - and rely on Mobile IPv6 route
   optimisation to make good the additional overhead imposed by the
   reverse tunneling to the new prefix.


   Applications that employ SCTP as opposed TCP or UDP for communication
   avoid all of the issues highlighted in this sub-section due to the
   provision of dynamic endpoint reconfiguration in the protocol (see
   Section 4.2).


7.2  Explicitly named IP addresses


   There are many places in the network where IP addresses are embedded
   as opposed to symbolic names, and finding them all to be updated
   during a renumbering episode is not a trivial task.  This section
   details an evolving list of such places as surveyed as common.


   Addresses may be hard-coded in software configuration files or
   services, in software source-code itself (which is particularly
   cumbersome if no source is available, e.g.  a bespoke utility built
   to order), in firmware (for example, an access-controlling hardware
   dongle), or even in hardware, e.g.  fixed by DIP switches.


   A non-exhaustive list of instances of such addresses includes:


   o  Provider based prefix(es)


   o  Names resolved to IP addresses in firewall at startup time


   o  IP addresses in remote firewalls allowing access to remote
      services


   o  IP-based authentication in remote systems allowing access to
      online bibliographic resources


   o  IP address of both tunnel end points for IPv6 in IPv4 tunnel


   o  Hard-coded IP subnet configuration information


   o  IP addresses for static route targets


   o  Blocked SMTP server IP list (spam sources)





Chown, et al.            Expires April 18, 2005                [Page 27]


Internet-Draft        Renumbering an IPv6 network           October 2004



   o  Web .htaccess and remote access controls


   o  Apache .Listen.  directive on given IP address


   o  Configured multicast rendezvous point


   o  TCP wrapper files


   o  Samba configuration files


   o  DNS resolv.conf on Unix


   o  Any network traffic monitoring tool


   o  NIS/ypbind via the hosts file


   o  Some interface configurations


   o  Unix portmap security masks


   o  NIS security masks


   o  PIM-SM Rendezvous Point address


   Some hard-coded IP address information will be held in remote
   locations, e.g.  remote firewalls, DNS glue, etc.  adding to the
   complexity of the search for all instances of the old prefix.  Should
   symbols be used rather than addresses, administrative ownership of
   DNS - with due consideration for the TTL of resource records - and
   other naming services ease this particularly problematic issue of
   data ownership and validity.


7.3  API dilemna


   In light of Section 6.4, there is an open question as to whether we
   need an extension to the sockets API that would allow applications
   resolving addresses to be able to determine the freshness of the
   resolved data.  A straw poll of networking applications demonstrated
   that common programming practise is to 'resolve once, bind many'
   during the lifetime of an application, caching the initial lookup
   result and assuming that it is still valid throughout.  Whilst this
   is a perfectly valid approach for short-lived applications, where the
   chance of renumbering - site or the single node - increases with
   regards the longevity of the application, the likelihood of the
   resolved data being intrusively inaccurate also increases.







Chown, et al.            Expires April 18, 2005                [Page 28]


Internet-Draft        Renumbering an IPv6 network           October 2004



7.4  Server Sockets


   Certain services create a server socket instance on which they intend
   to receive client connections throughout their execution lifetime,
   never re-binding that socket unless explicitly shut-down and
   restarted.  An example would be a webserver, which may in fact bind
   to multiple different IP addresses to serve content for different
   domains where the particular business case is for customers to be
   allocated their 'own' IP address (e.g.  for reverse DNS to reflect
   their branded domain name).  Address space usage inefficiencies
   aside, the class of service that creates a server socket that
   persists on the initially-bound address is problematic during
   renumbering.


   A typical work-around would be to schedule a restart of all such
   services having first identified whether they can operate on both
   address prefixes (to satisfy the middle states of Baker [1]), or at
   least to schedule their migration to the new address configuration in
   light of the DNS name bindings (considering caches and TTL), and the
   nature of existing clients that may still be bound to the old service
   (consider graceful migration).


8.  IETF Call to Arms


   In the above considerations, a number of actions would be most
   helpful in advancing the understanding of the practical implications
   and robustness of IPv6 renumbering.  These include:


   o  Survey of the pervasiveness of address literals and steps to avoid
      their use


   o  Validation of address selection at source and destination during
      various stages of Baker's renumbering procedure


   o  Validation of RA lifetime expiry and confirmation of prefix
      removal and effects on existing sessions


   o  Better understanding of the commonalities and differences between
      renumbering and multi-homing


   o  ...  (to be expanded in future revisions)


   Effort is on-going researching the issues discussed and validating
   and extending [1] and associated activities and the results of that
   work will be reflected in revisions to this memo as well as fedback
   to the appropriate draft authors.






Chown, et al.            Expires April 18, 2005                [Page 29]


Internet-Draft        Renumbering an IPv6 network           October 2004



9.  IANA Considerations


   This document makes no request of IANA.


10.  Security Considerations


   The security considerations as outlined in [1] still hold, with the
   following supporting comments...  (tbd)


11.  Acknowledgements


   The authors gratefully acknowledge the many helpful discussions and
   suggestions of their colleagues from the 6NET consortium,
   particularly Fred Baker, Graca Carvalho, Ralph Droms, Eliot Lear,
   Christian Schild, Andre Stolz&eacute;, Tina Strauf, Bernard Tuy,
   Gunter Van de Velde, and Stig Venaas.


12.  References


12.1  Normative References


   [1]  Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an
        IPv6 Network without a Flag Day",
        draft-ietf-v6ops-renumbering-procedure-01 (work in progress),
        July 2004.


   [2]  Berkowitz, H., Ferguson, P., Leland, W. and P. Nesser,
        "Enterprise Renumbering: Experience and Information
        Solicitation", RFC 1916, February 1996.


   [3]  Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
        Why would I want it and what is it anyway?", RFC 2071, January
        1997.


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


   [5]  Draves, R., "Default Address Selection for Internet Protocol
        version 6 (IPv6)", RFC 3484, February 2003.


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


   [7]  Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
        2000.


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




Chown, et al.            Expires April 18, 2005                [Page 30]


Internet-Draft        Renumbering an IPv6 network           October 2004



12.2  Informative References


   [9]   Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.


   [10]  IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
         Allocations to Sites", RFC 3177, September 2001.


   [11]  Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
         Allocation) Phaseout", RFC 3701, March 2004.


   [12]  Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
         Automatic Tunnel Addressing Protocol (ISATAP)",
         draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.


   [13]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-01 (work in progress), February
         2004.


   [14]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
         "Stream Control Transmission Protocol", RFC 2960, October 2000.


   [15]  Stewart, R., "Stream Control Transmission Protocol (SCTP)
         Dynamic Address  Reconfiguration",
         draft-ietf-tsvwg-addip-sctp-09 (work in progress), June 2004.


   [16]  Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.


   [17]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.


   [18]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.


   [19]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633, December
         2003.


   [20]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
         Addresses", RFC 2526, March 1999.


   [21]  Jeong, J., "IPv6 Host Configuration of DNS Server Information
         Approaches", draft-ietf-dnsop-ipv6-dns-configuration-04 (work
         in progress), September 2004.





Chown, et al.            Expires April 18, 2005                [Page 31]


Internet-Draft        Renumbering an IPv6 network           October 2004



   [22]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.


   [23]  "Architectural Approaches to Multi-Homing for IPv6",
         draft-ietf-multi6-architecture-00 (work in progress), July
         2004.


   [24]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
         progress), September 2004.


   [25]  Hinden, R. and B. Haberman, "Centrally Assigned Unique Local
         IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-00 (work
         in progress), June 2004.


   [26]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
         Multicast Addresses", RFC 3306, August 2002.


   [27]  Venaas, S. and T. Chown, "Lifetime Option for DHCPv6",
         draft-ietf-dhc-lifetime-02 (work in progress), September 2004.


   [28]  Velde, G., "IPv6 Network Architecture Protection",
         draft-vandevelde-v6ops-nap-00 (work in progress), October 2004.


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


   [30]  Moskowitz, R., "Host Identity Protocol Architecture",
         draft-moskowitz-hip-arch-06 (work in progress), June 2004.


   [31]  Chown, T., "IPv6 Campus Transition Scenario Description and
         Analysis", draft-chown-v6ops-campus-transition-00 (work in
         progress), July 2004.


URIs


   [32]  <http://popbsmtp.sourceforge.net/>














Chown, et al.            Expires April 18, 2005                [Page 32]


Internet-Draft        Renumbering an IPv6 network           October 2004



Authors' Addresses


   Tim J. Chown
   University of Southampton, UK
   Electronics and Computer Science
   University of Southampton
   Southampton  SO17 1BJ
   UK


   Phone: +44 23 8059 5415
   Fax:   +44 23 8059 2865
   EMail: tjc@ecs.soton.ac.uk



   Mark K. Thompson
   University of Southampton, UK


   EMail: mkt@ecs.soton.ac.uk



   Alan J. Ford
   University of Southampton, UK


   EMail: af@ecs.soton.ac.uk




























Chown, et al.            Expires April 18, 2005                [Page 33]


Internet-Draft        Renumbering an IPv6 network           October 2004



Intellectual Property Statement


   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.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   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.




Chown, et al.            Expires April 18, 2005                [Page 34]


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