Network Working Group B. Liu
Internet Draft S. Jiang
Intended status: Informational Huawei Technologies Co., Ltd
Expires: December 11, 2013 B. Carpenter
University of Auckland
S. Venaas
Cisco Systems
W. George
Time Warner Cable
June 9, 2013
IPv6 Site Renumbering Gap Analysis
draft-ietf-6renum-gap-analysis-08.txt
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
at http://datatracker.ietf.org/drafts/current/.
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 December 11, 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
(http://trustee.ietf.org/license-info) 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 December 11 2013 [Page 1]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
Abstract
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. Its main
content is a gap analysis that provides a basis for future works to
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 ....................................... 8
5. Address Configuration ........................................ 8
5.1. Host Address Configuration .............................. 8
5.2. Router Address Configuration ............................ 9
6. Updating Address-relevant Entries ........................... 10
6.1. DNS Records Update ..................................... 10
6.2. In-host Server Address Update .......................... 11
6.3. Address update in scattered configurations ............. 11
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 ................................................. 17
9.1. Managing Prefixes ...................................... 17
9.2. Address configuration .................................. 17
9.3. Address relevant entries update ........................ 17
9.4. Renumbering event management ........................... 18
9.5. Miscellaneous .......................................... 19
10. Gaps considered unsolvable ................................. 19
Liu, et al. Expires December 11, 2013 [Page 2]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
10.1. Address Configuration ................................. 19
10.2. Address-relevant Entries Update ....................... 19
10.3. Miscellaneous ......................................... 20
11. Security Considerations .................................... 20
12. IANA Considerations......................................... 21
13. Acknowledgments ............................................ 21
14. References ................................................. 22
14.1. Normative References .................................. 22
14.2. Informative References ................................ 23
Liu, et al. Expires December 11, 2013 [Page 3]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 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.
Building upon the IPv6 enterprise renumbering scenarios described in
[RFC6879], 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] and [RFC4192].
It does further analysis and identifies the valuable and solvable
issues, digs out of some undiscovered gaps, and gives some solution
suggestions. This document considers make-before-break approach as a
premise for the gap analysis, so readers should be familiar with
[RFC4192].
Renumbering nodes with static addresses has a particular set of
problems, thus discussion of that space has been covered in a related
document [RFC6866].
This document does not cover the un-planned emergency renumbering
cases.
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.
Liu, et al. Expires December 11, 2013 [Page 4]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
The automation can be divided into four aspects as follows. (Detailed
analysis of the four aspects is presented respectively in section 4
to section 7.)
o Prefix delegation and delivery should be automatic and accurate in
aggregation and coordination.
o Address reconfiguration should be automatically achieved through
standard protocols with minimum human intervention.
o Address-relevant entry updates should be performed together 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, with the [RFC4192] make-before-
break approach, and the address lifetime mechanisms in IPv6
Stateless Address Autoconfiguration (SLAAC) and Dynamic Host
Configuration Protocol for IPv6 (DHCPv6), a smooth transition
mechanism from old to new prefixes is applicable. 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
configuration.
Liu, et al. Expires December 11, 2013 [Page 5]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
themselves.
o Hosts that are configured through DHCPv6 [RFC3315] obtain new
addresses through the renewal process or when 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 integrate 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 to push configuration to
devices. This is sometimes used as a supplement to vendor specific
solutions. A representative of such third-party tool is [cfengine].
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.
Liu, et al. Expires December 11, 2013 [Page 6]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
nodes.
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
administrators. It should be noted that the administrators need to
carefully deal with the address selection issue while the old and
new prefixes are both available during the overlapping period in
[RFC4192] procedure. And the address selection policies might need
to be updated after renumbering. So administrator could leverage
the address selection policy distribution mechanism in
[I-D.ietf-6man-addr-select-opt].
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
For big enterprises, the new short prefix(es) usually comes down
through off-line human communication. But for the SOHO style SMEs
(Small & Medium Enterprises), the prefixes might be dynamically
received by DHCPv6 servers or routers inside the enterprise networks.
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
Liu, et al. Expires December 11, 2013 [Page 7]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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 advertise a
prefix on a link to which hosts are connected. Host address
configuration, rather than routers, is the primary concern for prefix
assignment which is described in the following section 5.1.
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 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-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
Liu, et al. Expires December 11, 2013 [Page 8]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
prefixes
[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.
Relevant standards ([RFC4862],[RFC3315]) are ambiguous about what
approach should be taken by a DHCPv6-configured host when it
receives RA messages containing a new prefix. Current behavior
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
unspecified.
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.
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
lengths."
o Restart after renumbering
Liu, et al. Expires December 11, 2013 [Page 9]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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.
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 [RFC4704]. This
server-oriented approach is applicable for large numbers of hosts'
using secure DDNS. (In some commercial solutions, DNS service could
be integrated with DHCP service provided by the same vendor so that
the secure DDNS might be silently enabled as default.) However, there
is still a gap here, since the DHCP servers have to learn the
relevant hosts have changed their addresses and thus trigger the DDNS
Liu, et al. Expires December 11, 2013 [Page 10]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
update. If the hosts were numbered and also renumbered by DHCP, then
it is easy for the DHCP servers to learn the address changes; but if
the hosts were numbered by SLAAC, then there could be trouble.
[I-D.ietf-dhc-addr-registration] proposed a address registration
mechanism which could be used to address the latter issue; however,
it has not been deployed yet.
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.
In principle, the addresses of DHCPv6 servers do not need to be
updated, since they could be dynamically discovered through DHCPv6
relevant multicast messages. But in practice, most relay agents have
the alternative of being configured with DHCPv6 server address rather
than sending to a multicast address. So the DHCP server addresses
update might be an issue in practice.
6.3. Address update in scattered configurations
Besides the DNS records and the in-host server address entries, there
are also many places in which 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.
In renumbering, it is annoying and error-prone to update the IP
addresses in all the above mentioned places. We lack a "one-stop"
mechanism to trigger the updates for all the subsystems on a
host/server, and all the external databases that refer to the IP
address update. We decompose the general "one-stop" gap into the
following two aspects.
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
Liu, et al. Expires December 11, 2013 [Page 11]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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 refers to 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
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
Liu, et al. Expires December 11, 2013 [Page 12]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
manageable.
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 to hosts that a
renumbering event has changed some DNS records in DNS servers
(normally, in an enterprise it/they is/are (a) local recursive DNS
server(s).), and then the hosts might want to refresh the DNS
cache. That mechanism may also need to indicate that such a change
will happen at a specific time in the future.
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 domains which are
connected by border routers, all border routers should be aware of
renumbering in one domain or multiple domains, and update the
internal forwarding tables and the address/prefix based filters
accordingly to correctly handle inbound packets.
o Ingress filtering: ISPs normally enable ingress filter to drop
packets with source addresses from other ISPs at the end site
routers to prevent IP spoofing [RFC2827]. In a multihomed site
with multiple PA prefixes, the ingress router of ISP A should be
notified if the ISP B initiates a renumbering event in order to
properly update its filters to permit the new legitimate prefix
(es). For large enterprises, it might be applicable to indicate
this new legitimate prefix information through human communication,
however, for the millions of small enterprises, an automated
notification mechanism is needed.
Liu, et al. Expires December 11, 2013 [Page 13]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
o In the NMS (network management system), logs collected through
syslog, SNMP notification, IPFIX, etc. usually treat the UDP
message source IP addresses as the host or router IDs. When one
source IP address is changed, the log collectors will consider
that a new device appeared in the network. So a mechanism is
needed for the NMS applications to learn the renumbering event, so
that they could correlate the old and new addresses in the logs.
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].
Ideally, during a renumbering operation, the DNS TTLs should always
be shorter than any other lifetime associated with an address. If the
TTLs were set correctly, then the DNS latency could be well
controlled. However, there might be some exceptional situations in
which the DNS TTLs were already set too long for the time available
to plan and execute a renumbering event. In these situations, there
currently are no mechanisms to deal with the already configured long
DNS TTLs.
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
Since multicast and mobility are special use cases which might not be
included in routine/common renumbering operations, they are
separately discussed as miscellaneous in this section.
8.1. Multicast
In the perspective of interface renumbering operations, renumbering a
multicast address is the same with renumbering a unicast address. So
this section mainly discusses the issues from the perspective of the
impact to the multicast application systems caused by renumbering.
Liu, et al. Expires December 11, 2013 [Page 14]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
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
Liu, et al. Expires December 11, 2013 [Page 15]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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.
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.
In summary, currently the multicast renumbering issues are basically
handled by application-specific methods. There is no standard way to
guarantee multicast service could live across a renumbering event.
8.2. Mobility
As described in [RFC5887], if a mobile node's home address changes
unexpectedly, the node can be informed of the new global routing
prefix used at the home site through the Mobile Prefix Solicitation
and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. But if the
mobile node is unfortunately disconnected at the time of home address
renumbering, it will no longer know a valid subnet anycast address
for its home agent, leaving it to deduce a valid address on the basis
of DNS information.
Liu, et al. Expires December 11, 2013 [Page 16]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
So, 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-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
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
administrators
9.3. Address relevant entries update
o DNS records update
- For key management scalable issue, secure dynamic DNS update is
usually done by DHCP servers on behalf of the hosts, so it might
not be applicable for SLAAC-configured hosts to do secure DDNS.
o In-host server address update
Liu, et al. Expires December 11, 2013 [Page 17]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
- DHCP relays might be configured with DHCP server addresses
rather than sending multicast messages to discover the DHCP
server dynamically, so the DHCP server addresses update might be
an issue in practice.
o Address update in scattered configurations
- 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
- 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
renumbered
- A prior notice about a renumbering event for DNS
- A mechanism for border routers to know internal partial
renumbering
- For multihomed sites, a mechanism to notify the egress router of
ISPA that egress router connecting to ISPB initiates renumbering
is needed.
- A mechanism is needed for the NMS applications to learn the
renumbering event, so that they could correlate the old and new
addresses in the logs.
o Synchronization management
- DNS information propagating latency issue
o Renumbering monitoring
- Mechanisms to monitor the process and feedback of renumbering
might be needed.
Liu, et al. Expires December 11, 2013 [Page 18]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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
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 authority
In an enterprise that hosts servers on behalf of collaborators and
customers, it is often the case that DNS zones outside the
administrative control of the hosting enterprise maintain resource
records concerning addresses for hosted nodes within its address
space. When the hosting enterprise renumbers, it does not have
sufficient authority to change those records.
This is an operational and policy issue. It is out of scope for this
document to consider a technical solution or to propose an additional
protocol or mechanism to standardize the interaction between DNS
systems for authority negotiations.
Liu, et al. Expires December 11, 2013 [Page 19]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
o DNS entries commonly have matching Reverse DNS entries which will
also need to be updated during renumbering. It might not be
possible to combine forward and reverse DNS entries update in one
procedure.
o DNS data structure optimization
[RFC2874] proposed an A6 record type for DNS recording of IPv6
address and prefix. Several extensions to DNS query and processing
were also proposed. A6 was designed to be a replacement for AAAA
record. The changes were designed to facilitate network renumbering
and multihoming. 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.
However, the A6 record has not been widely used, and has been shown
to have various problems and disadvantages (see section 2 in
[RFC6563]). It has been deprecated and moved to historic status by
[RFC6563]. The idea of a structured record to separate prefix and
suffix is still potentially valuable for renumbering, but avoiding
the problems of the A6 record would require a major development
effort.
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
addresses.
We considered the above two points (ID/Locator overloading in
transport layer & address caching in app layer) are fundamental
issues that might not be proper to deal with them just in terms of
renumbering.
11. Security Considerations
o Prefix Validation
Liu, et al. Expires December 11, 2013 [Page 20]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
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.
If there are DHCPv6 authentication keys associated with an IP address
then the keys need to be changed for continually working when the
addresses are renumbered.
Addresses in SEND certificates are going to need to get updated when
renumbering. During the overlap between old and new addresses, both
certificates must remain valid.
o Security Protection for Renumbering Notification
Section 7.1 mentions possible notification mechanisms to signal a
change in the DNS system or in the border routers related to a
renumbering event. Since DNS system and border routers are key
elements in any network, and they might take action according to the
notification, a security authentication for the renumbering
notification is needed.
o Security Protection for Configuration Update
Automated configuration update approaches like [LEROY] would increase
the risk since a bad actor with the right permission could cause
havoc to the networks.
12. IANA Considerations
This draft does not request any IANA actions.
13. Acknowledgments
This work adopts significant amounts of content from [RFC5887] and
particularly the "DNS Authority" topic in section 10.2 is from
Liu, et al. Expires December 11, 2013 [Page 21]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
[draft-chown-v6ops-renumber-thinkabout]. Both of the two documents
are important input for this work, that some
principles/considerations applied in this work are implicitly
inherited from them. 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 Ted Lemon, Lee
Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit
Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke,
Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot
and other members of 6renum WG.
This document was prepared using 2-Word-v2.0.template.dot.
14. References
14.1. Normative References
[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.
Liu, et al. Expires December 11, 2013 [Page 22]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
14.2. Informative References
[RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January
1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2267, January 1998.
[RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894,
August 2000.
[RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", RFC 3965, November
2004.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4704, October 2006.
[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.
Liu, et al. Expires December 11, 2013 [Page 23]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
[RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[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.
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Working in Progress,
April 2013.
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working
in progress, March 2012.
[I-D.ietf-dhc-addr-registration]
Jiang, S., Chen G., and S. Krishnan, "A Generic IPv6
Addresses Registration Solution Using DHCPv6", working in
progress, February 2013.
[I-D.liu-6renum-dhcpv6-slaac-switching]
Liu, B., "DHCPv6/SLAAC Address Configuration Switching for
Host Renumbering", Working in Progress, July 2012.
[I-D.liu-bonica-dhcpv6-slaac-problem]
Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", Working in Progress,
February 2013.
[cfengine]http://cfengine.com/what-is-cfengine
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network
configurations for IPv6 renumbering", International of
Network Management, 2009, <http://
inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>
Liu, et al. Expires December 11, 2013 [Page 24]
Internet-Draft IPv6 Site Renumbering Gap Analysis June 2013
Authors' Addresses
Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: stig@cisco.com
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
USA
Phone: +1 703-561-2540
Email: wesley.george@twcable.com
