Network Working Group                                            B. Liu
Internet Draft                                                 S. Jiang
Intended status: Informational             Huawei Technologies Co., Ltd
Expires: October 28, 2013                                  B. Carpenter
                                                 University of Auckland
                                                              S. Venaas
                                                          Cisco Systems
                                                              W. George
                                                      Time Warner Cable
                                                         April 26, 2013

                    IPv6 Site Renumbering Gap Analysis

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is

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

   This Internet-Draft will expire on October 28, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Liu, et al.           Expires October 28 2013                [Page 1]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013


   This document briefly introduces the existing mechanisms that could
   be utilized for IPv6 site renumbering and tries to cover most of the
   explicit issues and requirements of IPv6 renumbering. Through the gap
   analysis, the document provides a basis for future works that
   identify and develop solutions or to stimulate such development as
   appropriate. The gap analysis is organized by the main steps of a
   renumbering process.

Table of Contents

   1. Introduction ................................................. 4
   2. Overall Requirements for Renumbering ......................... 4
   3. Existing Components for IPv6 Renumbering ..................... 5
      3.1. Relevant Protocols and Mechanisms ....................... 5
      3.2. Management Tools ........................................ 6
      3.3. Procedures/Policies ..................................... 7
   4. Managing Prefixes ............................................ 7
      4.1. Prefix Delegation ....................................... 7
      4.2. Prefix Assignment ....................................... 7
   5. Address Configuration ........................................ 8
      5.1. Host Address Configuration .............................. 8
      5.2. Router Address Configuration ........................... 10
   6. Updating Address-relevant Entries ........................... 10
      6.1. DNS Records Update ..................................... 11
      6.2. In-host Server Address Update .......................... 11
      6.3. Parameterized IP-specific Configuration ................ 12
   7. Renumbering Event Management ................................ 13
      7.1. Renumbering Notification ............................... 13
      7.2. Synchronization Management ............................. 14
      7.3. Renumbering Monitoring ................................. 14
   8. Miscellaneous ............................................... 14
      8.1. Multicast .............................................. 14
      8.2. Mobility ............................................... 16
   9. Gap Summary ................................................. 16
      9.1. Managing Prefixes ...................................... 16
      9.2. Address configuration .................................. 16
      9.3. Address relevant entries update ........................ 17
      9.4. Renumbering event management ........................... 18
      9.5. Miscellaneous .......................................... 18
   10. Gaps considered unsolvable ................................. 18

Liu, et al.           Expires October 28, 2013                [Page 2]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

      10.1. Address Configuration ................................. 18
      10.2. Address-relevant Entries Update ....................... 19
      10.3. Miscellaneous ......................................... 20
   11. Security Considerations .................................... 20
   12. IANA Considerations......................................... 20
   13. Acknowledgments ............................................ 20
   14. References ................................................. 21
      14.1. Normative References .................................. 21
      14.2. Informative References ................................ 21

Liu, et al.           Expires October 28, 2013                [Page 3]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

1. Introduction

   As introduced in [RFC5887], renumbering, especially for medium to
   large sites and networks, is currently viewed as an expensive,
   painful, and error-prone process, avoided by network managers as much
   as possible. If IPv6 site renumbering continues to be considered
   difficult, network managers will turn to Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   renumbering. However, widespread use of PI may create very serious
   BGP4 scaling problems [RFC4984]. It is thus desirable to develop
   tools and practices that may make renumbering a simpler process to
   reduce demand for IPv6 PI space.

   This document performs a gap analysis to provide a basis for future
   work to identify and develop solutions or to stimulate such
   development as appropriate. The gap analysis is organized according
   to the main steps of a renumbering process, which include prefix
   management, node address (re)configuration, and updating address-
   relevant entries in various devices such as firewalls, routers and
   servers, etc. Renumbering event management is presented independently
   from the steps of a renumbering process, in order to identify some
   operational and administrative gaps in renumbering.

   This document starts from existing work in [RFC5887],
   [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]. This document
   does further analysis and identifies the valuable and solvable issues,
   digs out of some undiscovered gaps, and gives some solution

   Renumbering nodes with static addresses has a particular set of
   problems, thus discussion of that space has been covered in a related
   document [RFC6866].

2. Overall Requirements for Renumbering

   This section introduces the overall goals we want to achieve in a
   renumbering event. In general, we need to leverage renumbering
   automation to avoid human intervention as much as possible at
   reasonable cost. Some existing mechanisms have already provided
   useful ability.

   The automation can be divided into four aspects as follows.

   o Prefix delegation and delivery should be automatic and accurate in
     aggregation and coordination.

Liu, et al.           Expires October 28, 2013                [Page 4]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   o Address reconfiguration should be automatically achieved through
     standard protocols with minimum human intervention.

   o Address-relevant entry updates should be performed integrally and
     without error.

   o Renumbering event management is needed to provide the functions of
     renumbering notification, synchronization, and monitoring.

   Besides automation, session survivability is another important issue
   during renumbering since application outage is one of the most
   obvious impacts that make renumbering painful and expensive. Session
   survivability is a fundamental issue that cannot be solved within
   renumbering context only. However, IPv6's ability to overlap old and
   new prefixes (make before break) provides an enormous advantage and
   to use the address lifetime mechanisms in IPv6 Stateless Address
   Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6). That is fully described in [RFC4192], which provides a
   smooth transition mechanism from old to new prefixes. In most of the
   cases, since we can set the transition period long enough to cover
   the on-going sessions, we consider this mechanism sufficient for
   avoiding session brokenness issue in IPv6 site renumbering. (Please
   note that if multiple addresses are running simultaneously on hosts,
   the address selection [RFC6724] needs to be carefully handled.)

3. Existing Components for IPv6 Renumbering

   Since renumbering is not a new issue, some protocols and mechanisms
   have already been utilized for renumbering. There were also some
   dedicated protocols and mechanisms developed for renumbering. This
   section briefly reviews these existing protocols and mechanisms to
   provide a basis for the gap analysis.

3.1. Relevant Protocols and Mechanisms

   o RA messages, defined in [RFC4861], are used to deprecate/announce
     old/new prefixes and to advertise the availability of an upstream
     router. In renumbering, it is one of the basic mechanisms for host

   o When renumbering a host, SLAAC [RFC4862] may be used for address
     configuration with the new prefix(es). Hosts receive RA messages
     which contain routable prefix(es) and the address(es) of the
     default router(s), then hosts can generate IPv6 address(es) by

Liu, et al.           Expires October 28, 2013                [Page 5]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
     addresses by starting RENEW actions when the current addresses'
     lease time are expired or they receive the reconfiguration
     messages initiated by the DHCPv6 servers.

   o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated
     delegation of IPv6 prefixes using the DHCPv6.

   o [RFC2894] defined standard ICMPv6 messages for router renumbering.
     This is a dedicated protocol for renumbering, but we are not aware
     of it being used in real network deployment.

3.2. Management Tools

   Some renumbering operations could be automatically processed by
   management tools in order to make the renumbering process more
   efficient and accurate. The tools may be designed specifically for
   renumbering, or common tools could be utilized for some of the
   renumbering operations.

   Following are examples of these tools.

   o IP address management (IPAM) tools. There are both commercial and
     open-source solutions. IPAM tools are used to manage IP address
     plans, and usually integrates the DHCPv6 and DNS services together
     as a whole solution. Many mature commercial tools can support
     management operations, but normally they do not have dedicated
     renumbering functions. However, the integrated DNS/DHCPv6 services
     and address management function can obviously facilitate the
     renumbering process.

   o Some organizations use third-party tools like [cfengine] to push
     configuration to devices. This is sometimes used as a supplement
     to vendor specific solutions.

   o [LEROY] proposed a mechanism of macros to automatically update the
     address-relevant entries/configurations inside the DNS, firewall,
     etc. The macros can be delivered though SOAP protocol from a
     network management server to the managed devices.

   o Asset management tools/systems. These tools may provide the
     ability of managing configuration files in nodes so that it is
     convenient to update the address-relevant configuration in these

Liu, et al.           Expires October 28, 2013                [Page 6]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

3.3. Procedures/Policies

   o [RFC4192] proposed a procedure for renumbering an IPv6 network
     without a flag day. The document includes a set of operational
     suggestions which can be followed step by step by network

   o [RFC6879] analyzes the enterprise renumbering
     events and gives the recommendations among the existing
     renumbering mechanisms. According to the different stages,
     renumbering considerations are described in three categories:
     considerations and recommendations during network design, for
     preparation of enterprise network renumbering, and during
     renumbering operation.

4. Managing Prefixes

   When renumbering an IPv6 enterprise site, the key procedural issue is
   switching the old prefix (es) to the new one(s). A new short prefix
   may be divided into longer ones for subnets. So we need to carefully
   manage the prefixes to ensure they are synchronized and coordinated
   in the whole network.

4.1. Prefix Delegation

   Usually, the new short prefix(es) comes down from the operator(s) and
   is received by DHCPv6 servers or routers inside the enterprise
   networks (or through off-line human communication). The short
   prefix(es) could be automatically delegated through DHCPv6-PD. Then
   the downlink DHCPv6 servers or routers can begin advertising the
   longer prefixes to the subnets.

   The delegation routers might need to renumber themselves with the new
   delegated prefixes. So there should be a mechanism informing the
   router to renumber themselves by delegated prefixes; and there also
   should be a mechanism for the routers to derive addresses
   automatically based on the delegated prefixes.

4.2. Prefix Assignment

   When subnet routers receive the longer prefixes, they can directly
   assign them to the hosts.  Host address configuration, rather than
   routers, is the primary concern for prefix assignment which is
   described in the following section 5.1.

Liu, et al.           Expires October 28, 2013                [Page 7]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

5. Address Configuration

5.1. Host Address Configuration

   o SLAAC/DHCPv6 interaction problems

   Both of the DHCPv6 and Neighbor Discovery (ND) protocols have IP
   address configuration function. They are suitable for different
   scenarios. During renumbering, the SLAAC-configured hosts can
   reconfigure IP addresses by receiving ND Router Advertisement (RA)
   messages containing new prefix information. (It should be noted that,
   the prefix delivery could be achieved through DHCPv6 according to
   [I.D ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can
   reconfigure addresses by initiating RENEW sessions when the current
   addresses' lease times are expired or when they receive
   reconfiguration messages initiated by the DHCPv6 servers.

   Sometimes the two address configuration modes may both be available
   in one network. This would add more or less additional complexity for
   both the hosts and the network management.

   With the flags defined in RA (ManagedFlag indicating the DHCPv6
   service available in the network; OtherConfigFlag indicating other
   configurations such as DNS/routing), the two separated address
   configuration modes are correlated. However, the ND protocol did not
   define the flags as prescriptive but only as advisory. This has led
   to variation in the behavior of hosts when interpreting the flags.
   Different operating systems have followed different approaches. (For
   more details, please refer to [I-D.liu-bonica-dhcpv6-slaac-problem]
   and [I-D.liu-6renum-dhcpv6-slaac-switching].)

   The impact of ambiguous M/O flags includes the following aspects:

     - DHCPv6-only address management might not be applicable

     On some current operating systems, DHCPv6 procedure will not start
     until they receive RA messages with M flag set. This has an
     implication that RA messages are required to cooperate with DHCPv6
     for address provisioning.

     If administrators want to switch the current networks to DHCPv6-
     only (or adopted DHCPv6-only at the beginning), they need to retain
     RA for the times when existing hosts reboot or new hosts come
     online. ND protocol is always necessary for layer-2 discovery, but
     this does not mean it should be necessary for address provisioning.
     It might raise the possibility of operational errors since it

Liu, et al.           Expires October 28, 2013                [Page 8]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

     always requires accurate ND/DHCPv6 cooperation to achieve DHCPv6
     address provisioning in a network.

     - DHCPv6-configured hosts might not be able to be renumbered by RA

     It is unclear whether a DHCPv6 configured host will accept address
     configuration though RA messages, especially when M flag
     transitioning from 1 to 0; this depends on the implementation of
     the operating system. It might not be possible for administrators
     to only use RA messages for renumbering, since renumbering might
     fail on some already DHCPv6-configured hosts. It means
     administrators have to use DHCPv6 reconfiguration for some DHCPv6-
     configured hosts. It is not convenient and DHCPv6 reconfiguration
     is not suitable for bulk usage as analyzed in below.

     - DHCPv6-configured hosts might not be able to learn new RA

     [RFC5887] mentioned that DHCPv6-configured hosts may want to learn
     about the upstream availability of new prefixes or loss of prior
     prefixes dynamically by deducing this from periodic RA messages.
     But there is no standard specifying what approach should be taken
     by a DHCPv6-configured host when it receives RA messages containing
     a new prefix. It depends on the operating system of the host and
     cannot be predicted or controlled by the network.

     - SLAAC-configured hosts might not be able to add DHCPv6 address(es)

     The behavior when the host receives RA messages with M flag set is

     The host may start a DHCPv6 session and receive the DHCPv6 address
     configuration, or it may just ignore the messages. If the network
     side wants the hosts to start DHCPv6 configuration, it is just out
     of control of the network side.

   o DHCPv6 reconfigure bulk usage

   [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear to be
   widely used for bulk renumbering purposes".

   The reconfiguration defined in [RFC3315] needs to establish a session
   between DHCPv6 server and client. This could be considered as a
   stateful approach which needs much resource on the server to maintain
   the renumbering sessions. This is probably one of the reasons that
   DHCPv6 reconfiguration is not suitable for bulk usage.

Liu, et al.           Expires October 28, 2013                [Page 9]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   Another limitation of DHCPv6 reconfiguration is that it only allows
   the messages to be delivered to unicast addresses. So if we want to
   use it for bulk renumbering, stateless DHCPv6 reconfiguration with
   multicast may be needed. However, this may involve protocol

5.2. Router Address Configuration

   o Learning new prefixes

   As described in [RFC5887], "if a site wanted to be multihomed using
   multiple provider-aggregated (PA) routing prefixes with one prefix
   per upstream provider, then the interior routers would need a
   mechanism to learn which upstream providers and prefixes were
   currently reachable (and valid). In this case, their Router
   Advertisement messages could be updated dynamically to only advertise
   currently valid routing prefixes to hosts.  This would be
   significantly more complicated if the various provider prefixes were
   of different lengths or if the site had non-uniform subnet prefix

   o Restart after renumbering

   As [RFC2072] mentioned, some routers cache IP addresses in some
   situations, so routers might need to be restarted as a result of site
   renumbering. While most modern systems support a cache-clear function
   that eliminates the need for restarts, there are always exceptions
   that must be taken into account.

   o Router naming

   [RFC4192] suggests that "To better support renumbering, switches and
   routers should use domain names for configuration wherever
   appropriate, and they should resolve those names using the DNS when
   the lifetime on the name expires." As [RFC5887] described, this
   capability is not new, and currently it is present in most IPSec VPN
   implementations. However, many administrators may need to be alerted
   to the fact that it could be utilized to avoid manual modification
   during renumbering.

6. Updating Address-relevant Entries

   In conjunction with renumbering the nodes, any configuration or data
   store containing previous addresses must be updated as well. Some
   examples include DNS records and filters in various entities such as
   ACLs in firewalls/gateways.

Liu, et al.           Expires October 28, 2013               [Page 10]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

6.1. DNS Records Update

   o Secure Dynamic DNS update

   In real network operations, DNS update is normally achieved by
   maintaining a DNS zone file and loading this file into the site's DNS
   server(s). Synchronization between host renumbering and the updating
   of its A6 or AAAA record is hard. [RFC5887] mentioned that an
   alternative is to use Secure Dynamic DNS Update [RFC3007], in which a
   host informs its own DNS server when it receives a new address.

   Secure Dynamic DNS Update has been widely supported by the major DNS
   implementations, but it hasn't been widely deployed. Normal hosts are
   not suitable to do the update mainly because of the complexity of key
   management issues inherited from secure DNS mechanisms, so current
   practices usually assign the DHCP servers to act as DNS clients to
   request the DNS server updating relevant records. However, it is
   still not easy to use, the operational complexity of Secure Dynamic
   DNS Update is still a gao. (But for some commercial DNS systems, the
   operational issue may be much easier, since it could be integrated
   with services like DHCP provided by the same vendor so that the
   dynamic DNS update could be silently enabled.)

6.2. In-host Server Address Update

   While DNS stores addresses of hosts in servers, hosts are also
   configured with addresses of servers such as DNS server, radius
   server. While renumbering, the hosts must update these addresses if
   the server addresses changed. (Addresses of DHCPv6 servers do not
   need to be updated. They are dynamically discovered using DHCPv6
   relevant multicast addresses.)

   The DNS server addresses for hosts could be configured by DHCPv6. In
   stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
   specify valid time for the DNS configuration. But in stateful DHCPv6,
   current protocols could not indicate hosts the valid time of DNS
   configuration. If the DNS server has been renumbered, and the DHCP
   lease time has not expired yet, then the hosts would still use the
   old DNS server address(es). It might be better that the hosts could
   renew the DHCP DNS configuration before the lease time, especially
   there might be some extreme situations that the lease time need to be
   long. In this case how the DHCP server could learn the proper DNS
   configuration valid time is also an issue.

Liu, et al.           Expires October 28, 2013               [Page 11]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

6.3. Parameterized IP-specific Configuration

   Besides the DNS records and the in-host server address entries, there
   are also many places in which the IP addresses are configured, for
   example, filters such as ACL and routing policies. There are even
   more sophisticated cases where the IP addresses are used for deriving
   values, for example, using the unique portion of the loopback address
   to generate an ISIS net ID.

   Ideally, a layer of abstraction for IP-specific configuration within
   various devices (routers, switches, hosts, servers, etc.) is needed.
   However, this cannot be achieved in one step. One possible
   improvement is to make the IP-specific configuration parameterized.
   Two aspects of parameterized configuration could be considered to
   achieve this.

   o Self-contained Configuration in Individual device

   In an ideal way, the IP addresses can be defined as a value once, and
   then the administrators can use either keywords or variables to call
   the value in other places such as a sort of internal inheritance in
   CLI (command line interface) or other local configurations. This
   makes it easier to manage a renumbering event by reducing the number
   of places where a device's configuration must be updated. However, it
   still means that every device needs to be touched, but only once
   instead of having to inspect the whole configuration to ensure that
   none of the separate places that a given IP address occurs is missed.

   Among the current devices, some routers support defining multiple
   loopback interfaces which can be called in other configurations. For
   example, when defining a tunnel, it can call the defined loopback
   interface to use its address as the local address of the tunnel. This
   can be considered as a kind of parameterized self-contained
   configuration. But this only applies certain use cases; it is
   impossible to use the loopback interfaces to represent external
   devices and it is not always possible to call loopback interfaces in
   many other configurations. Parameterized self-contained configuration
   is still a gap for current devices.

   o Unified Configuration Management among Devices

   This is a more formalized central configuration management system,
   where all changes are made in one place and the system manages how to
   push the changes to the individual devices. This issue contains two
   aspects as the following.

     - Configuration Aggregation

Liu, et al.           Expires October 28, 2013               [Page 12]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

     Configuration based on addresses or prefixes are usually spread in
     various devices. As [RFC5887] described, some address configuration
     data might be widely dispersed and much harder to find, even will
     inevitably be found only after the renumbering event. So there's a
     big gap for configuration aggregation, it is hard to get all the
     relevant configurations through one place.

     - Configuration Update Automation

     As mentioned in section 3.2, [LEROY] proposed a mechanism which can
     automatically update the configurations. The mechanism utilizes
     macros suitable for various devices such as routers, firewalls. to
     update the configurations based on the new prefix. Such automation
     tool is valuable for renumbering because it can reduce manual
     operation which is error-prone and inefficiency.

     Besides the macros, [LEROY] also proposed to use SOAP to deliver
     the macros to the devices. As well as SOAP we may consider whether
     it is possible and suitable to use other standardized protocols
     such as NETCONF [RFC4714].

     But in current real networks, most of the devices use vendor-
     private protocols to update configurations, so it is not
     necessarily valid to assume that there is going to be a formalized
     configuration management system to leverage. Although there are
     some vendor-independent tools as mentioned in section 3.2, a
     standard and comprehensive way of uniformly updating configurations
     in multi-vendor devices is still a big gap currently.

7. Renumbering Event Management

   From the perspective of network management, renumbering is a kind of
   event which may need additional process to make it more easy and

7.1. Renumbering Notification

   If hosts or servers are aware of a renumbering event happening, it
   may benefit the relevant process. Following are several examples of
   such additional process that may ease the renumbering.

   o A notification mechanism may be needed to indicate the hosts that
     a renumbering event of local recursive DNS happens or is going to
     take place.

Liu, et al.           Expires October 28, 2013               [Page 13]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   o As suggested in [RFC4192], if the DNS service can be given prior
     notice about a renumbering event, then people could reduce the
     delay in the transition to new IPv6 addresses, thus improve the
     efficiency of renumbering.

   o Router awareness: in a site with multiple border routers, all
     border routers should be aware of partial renumbering in order to
     correctly handle inbound packets. Internal forwarding tables need
     to be updated.

   o Border filtering: in a multihomed site, an egress router to ISP A
     could normally filter packets with source addresses from other
     ISPs. The egress router connecting to ISP A should be notified if
     the egress router connecting to ISP B initiates a renumbering
     event in order to properly update its filter function.

7.2. Synchronization Management

   o DNS update synchronization

   The DNS changes must be coordinated with the changes of node address
   configuration. DNS has a latency issue of propagating information
   from the server to the resolver. The latency is mainly caused by TTL
   assigned to individual DNS records and the timing of updates from
   primary to secondary servers [RFC4192]. Currently, there are no
   mechanisms to deal with the latency issue.

7.3. Renumbering Monitoring

   While treating renumbering as a network event, mechanisms to monitor
   the renumbering process might be needed to inform the administrators
   whether the renumbering has been successfully done. Considering the
   address configuration operation might be stateless (if ND is used for
   renumbering), it is difficult for monitoring.

8. Miscellaneous

8.1. Multicast

   Renumbering also has an impact on multicast. Renumbering of unicast
   addresses affects multicast even if the multicast addresses are not
   changed. There may also be cases where the multicast addresses need
   to be renumbered.

   o Renumbering of multicast sources

Liu, et al.           Expires October 28, 2013               [Page 14]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   If a host that is a multicast source is renumbered, the application
   on the host may need to be restarted for it to successfully send
   packets with the new source address.

   For ASM (Any-Source Multicast) the impact on a receiver is that a new
   source appears to start sending, and it no longer receives from the
   previous source. Whether this is an issue depends on the application,
   but we believe it is likely to not be a major issue.

   For SSM (Source-Specific Multicast) however, there is one significant
   problem. The receiver needs to learn which source addresses it must
   join. Some applications may provide their own method for learning
   sources, where the source application may somehow signal the receiver.

   Otherwise, the receiver may e.g. need to get new SDP information with
   the new source address. This is similar to how to learn a new group
   address, see the "Renumbering of multicast addresses" topic below.

   o Renumbering of Rendezvous-Point

   If the unicast addresses of routers in a network are renumbered, then
   the RP (Rendezvous-Point) address is also likely to change for at
   least some groups. An RP address is needed by PIM-SM for providing
   ASM, and for Bidir PIM. Changing the RP address is not a major issue,
   except that the multicast service may be impacted while the new RP
   addresses are configured. If dynamic protocols are used for
   distributing group-to-RP mappings, the change can be fairly quick,
   and any impact should be only for a very brief time. However, if
   routers are statically configured, this depends on how long it takes
   to update all the configurations.

   For PIM-SM one typically switches to SPT (Shortest-Path-Tree) when
   the first packet is received by the last-hop routers. Forwarding on
   the SPT should not be impacted by change of IP address. Network
   operator should be careful not deprecate the previous mapping before
   configuring a new one, because implementations may revert to Dense
   Mode if no RP is configured.

   o Renumbering of multicast addresses

   In general multicast addresses can be chosen independently of the
   unicast addresses, and the multicast addresses can remain fixed even
   if the unicast addresses are renumbered. However, for IPv6 there are
   useful ways of deriving multicast addresses from unicast addresses,
   such as unicast-prefix-based IPv6 Multicast Addresses [RFC3306] and
   Embedded-RP IPv6 Multicast Addresses [RFC3956]. In that case the
   multicast addresses used may have to be renumbered.

Liu, et al.           Expires October 28, 2013               [Page 15]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   Renumbering group addresses may be complicated. For multicast, it is
   common to use literal addresses, and not DNS. When multicast
   addresses are changed, source applications need to be reconfigured
   and restarted.

   Multicast receivers need to learn the new group addresses to join.

   Note that for SSM, receivers need to learn which multicast channels
   to join. A channel is a source and group pair. This means that for an
   SSM application, a change of source address is likely to have the
   same effect as a change of group address.

   Some applications may have dynamic methods of learning which groups
   (and possibly sources) to join. If not, the application may have to
   be reconfigured and restarted.

   One common way for receivers to learn the necessary parameters is by
   use of SDP. SDP information may be distributed via various
   application protocols, or it may be from a file. An SDP file may be
   distributed via HTTP, email etc. If a user is using a web browser and
   clicking on a link to launch the application with the necessary data,
   it may be a matter of closing the current application, and re-
   clicking the link.

8.2. Mobility

   As [RFC5887] suggested, for Mobile IP, we need a better mechanism to
   handle change of home agent address while mobile is disconnected.

9. Gap Summary

9.1. Managing Prefixes

   o A mechanism informing the router to renumber themselves by
     delegated prefixes

   o A mechanism for the routers to derive addresses automatically
     based on the delegated prefixes.

9.2. Address configuration

   o Host address configuration

     - DHCPv6-only management might not applicable on some of current

Liu, et al.           Expires October 28, 2013               [Page 16]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

     - DHCPv6-configured hosts might not able to be renumbered by RA on
       some of current implementations

     - DHCPv6-configured hosts might not able to learn new RA prefixes
       on some of current implementations

     - SLAAC-configured hosts might not able to add DHCPv6 address(es)
       on some of current implementations

     - DHCPv6 reconfigure not suitable for bulk usage

   o Router address configuration

     - A mechanism for interior routers in multihomed site to learn
       which upstream providers and prefixes were currently reachable

     - Cache-clear might need restart (rarely in modern routers)

     - Using router domain names is not widely learned/deployed by

9.3. Address relevant entries update

   o DNS records update

     - Secure Dynamic DNS Update has operational complexity and seldom
       used in real networks

   o In-host server address update

     - a mechanism is needed for the hosts to renew the DHCP DNS
       configuration before the lease time when the DNS server is

     - It might be better to extend stateful DHCPv6 to indicate hosts
       the associated DNS server valid time when making DNS

   o Parameterized IP-specific Configuration

     - Devices don't support parameterized configuration,
       administrators need to touch every places where IP addresses
       were configured

     - It is hard to get all the address-relevant configurations spread
       in various devices through one place

Liu, et al.           Expires October 28, 2013               [Page 17]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

     - uniformly update configurations in multi-vendor devices is a big
        gap currently

9.4. Renumbering event management

   o  Renumbering notification

     - A mechanism to indicate hosts local recursive DNS is going to be

     - A prior notice about a renumbering event for DNS

     - A mechanism for border routers to know internal partial

     - For multihomed sites, a mechanism to notify the egress router of
       ISPA that egress router connecting to ISPB initiates renumbering

   o  Synchronization management

     - DNS information propagating latency issue

   o  Renumbering monitoring

     - Mechanisms to monitor the process and feedback of renumbering
       may be needed

9.5. Miscellaneous

   o  Multicast

     - Mechanism for SSM receivers to learn the source addresses when
       multicast sources are renumbered

   o  Mobility

     - A better mechanism to handle change of home agent address while
       mobile is disconnected.

10. Gaps considered unsolvable

   This section lists gaps have been identified by other documents but
   are considered unsolvable.

10.1. Address Configuration

   o RA prefix lifetime limitation

Liu, et al.           Expires October 28, 2013               [Page 18]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   In section 5.5.3 of [RFC4862], it is defined that "If the received
   Valid Lifetime is greater than 2 hours or greater than
   RemainingLifetime, set the valid lifetime of the corresponding
   address to the advertised Valid Lifetime." So when renumbering, if
   the previous RemainingLifetime is longer than two hours, it is
   impossible to reduce a prefix's lifetime less than two hours. This
   limitation is to prevent denial-of-service attack.

10.2. Address-relevant Entries Update

   o DNS entries commonly have matching Reverse DNS entries which will
     also need to be updated during renumbering.

   o DNS data structure optimization

   [RFC2874] proposed an experimental A6 record type for DNS recording
   of IPv6 address and prefix. Several extensions to DNS query and
   processing were also proposed. With the A6 record and the extensions,
   an IPv6 address could be defined by using multiple DNS records. This
   feature would increase the complexity of resolvers but reduce the
   cost of zone file maintenance, so renumbering could be easier than
   with the AAAA record.

   But the A6 record has not been widely used, and it has been moved to
   historic status [RFC6563]. However, the idea of structured record to
   separate prefix and suffix is still valuable for renumbering, but it
   might not be able to develop a more proper new DNS record type in a
   short time.

   o DNS authority

   As described in [I-D.chown-v6ops-renumber-thinkabout], "it is often
   the case in enterprises that host web servers and application servers
   on behalf of collaborators and customers that DNS zones out of the
   administrative control of the host maintain resource records
   concerning addresses for nodes out of their control. When the service
   host renumbers, they do not have sufficient authority to change the
   records. "

   It is an operational and policy issue and this document considers it
   not suitable to be solved through technical approach or bring
   additional protocol/mechanism to standardize the interaction between
   DNS systems for authority negotiations.

Liu, et al.           Expires October 28, 2013               [Page 19]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

10.3. Miscellaneous

   o For transport layer, [RFC5887] said that TCP connections and UDP
     flows are rigidly bound to a given pair of IP addresses.

   o For application layer, in general, we can assert that any
     implementation is at risk from renumbering if it does not check
     whether an address is valid each time it starts session resumption
     (e.g. a laptop wakes from sleep state). It is also more of less
     risky when it opens a new communications session by using cached

11. Security Considerations

   o Prefix Validation

   Prefixes from the ISP may need authentication to prevent prefix
   fraud. Announcing changes of site prefix to other sites (for example,
   those that configure routers or VPNs to point to the site in
   question) also need validation.

   In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or Secure
   Neighbor Discovery (SEND, [RFC3971]) deployment may be needed to
   validate prefixes.

   o Influence on Security Controls

   During renumbering, security controls (e.g. ACLs) protecting
   legitimate resources should not be interrupted. For example, if some
   addresses are in a blacklist, they should not escape from the
   blacklist due to renumbering.

12. IANA Considerations

   This draft does not request any IANA actions.

13. Acknowledgments

   This work adopts significant amounts of content from [RFC5887] and
   [I-D.chown-v6ops-renumber-thinkabout], so thanks go to Randall
   Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some
   useful materials were provided by Oliver Bonaventure and his student
   Damien Leroy.

   Many useful comments and contributions were made by Lee Howard, and
   members of 6renum WG.

Liu, et al.           Expires October 28, 2013               [Page 20]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   This document was prepared using

14. References

14.1. Normative References

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

   [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
             IPv6 Address Aggregation and Renumbering", RFC 2874, July

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

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

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

   [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point
             (RP) Address in an IPv6 Multicast Address.", RFC 3956,
             November 2004.

   [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander
             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP version 6 (IPv6)", RFC
             4861,September 2007.

   [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC 4862, September 2007.

14.2. Informative References

   [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January

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

Liu, et al.           Expires October 28, 2013               [Page 21]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
             (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP)
             Address in an IPv6 Multicast Address", RFC 3965, November

   [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
             Renumbering an IPv6 Network without a Flag Day", RFC 4192,
             September 2005.

   [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
             Time Option for Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", RFC 4242, November 2005.

   [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714,
             December 2006.

   [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
             from the IAB Workshop on Routing and Addressing", RFC 4984,
             September 2007.

   [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
             Still Needs Work", RFC 5887, May 2010.

   [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to
             Historic Status", RFC 6563, May 2012.

   [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
             "Default Address Selection for Internet Protocol Version 6
             (IPv6)", RFC 6724, September 2012.

   [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for
             Renumbering IPv6 Hosts with Static Addresses in Enterprise
             Networks", RFC 6866, February 2013.

   [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
             Network Renumbering Scenarios, Considerations, and Methods",
             RFC 6879, February 2013.

             Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working
             in progress, March 2012.

             Chown, T., "Things to think about when Renumbering an IPv6
             network", Work in Progress, September 2006.

Liu, et al.           Expires October 28, 2013               [Page 22]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

             Liu, B., "DHCPv6/SLAAC Address Configuration Switching for
             Host Renumbering", Working in Progress, July 2012.

             Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration
             Interaction Problem Statement", Working in Progress,
             February 2013.


   [LEROY]   Leroy, D. and O. Bonaventure, "Preparing network
             configurations for IPv6 renumbering", International of
             Network Management, 2009, <http://

Liu, et al.           Expires October 28, 2013               [Page 23]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

Authors' Addresses

   Bing Liu
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing  100095
   P.R. China


   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing  100095
   P.R. China


   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland, 1142
   New Zealand


   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134


Liu, et al.           Expires October 28, 2013               [Page 24]

Internet-Draft   IPv6 Site Renumbering Gap Analysis         April 2013

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171

   Phone: +1 703-561-2540