Network Working Group B. Liu
Internet Draft S. Jiang
Intended status: Informational Huawei Technologies Co., Ltd
Expires: January 4, 2012 July 4, 2011
IPv6 Site Renumbering Gap Analysis
draft-liu-6renum-gap-analysis-00.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 January 04, 2012.
Copyright Notice
Copyright (c) 2011 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.
Abstract
This document briefly introduces the existing mechanisms could be
utilized by IPv6 site renumbering and envisions the effort could be
done under the 6renum working group. This document tries to cover the
most explicit issues and requirements of IPv6 renumbering. Through
the gap analysis, the document provides a basis for future work to
Liu & Jiang Expires January 4, 2012 [Page 1]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
identify and develop solutions or to stimulate such development as
appropriate. The gap analysis is presented following a renumbering
event procedure clue.
Table of Contents
1. Introduction ................................................. 3
2. Overall Requirements for Renumbering ......................... 3
3. Existing Components for IPv6 Renumbering ..................... 4
3.1. Relevant Protocols and Mechanisms ....................... 4
3.2. Management Tools ........................................ 4
3.3. Procedures/Policies .................................... 5
4. Managing Prefixes ............................................ 5
4.1. Prefix delegation ....................................... 5
4.2. Prefix assignment ....................................... 6
5. Address Configuration ........................................ 6
5.1. Host Address Configuration .............................. 6
5.2. Router Address Configuration ............................ 7
5.3. Static Address Configuration ............................ 8
6. Address Relevant Entries Update .............................. 8
6.1. DNS Records Update ...................................... 8
6.2. Filters ................................................. 9
7. Renumbering Event Management ................................. 9
8. Miscellaneous ............................................... 10
8.1. Multicast .............................................. 10
8.2. Mobility ............................................... 10
9. Gap Summary ................................................. 10
9.1. Managing Prefixes ...................................... 10
9.2. Address configuration .................................. 10
9.3. Address relevant entries update ........................ 11
9.4. Renumbering event management ........................... 11
10. Security Considerations .................................... 11
11. IANA Considerations......................................... 11
12. References ................................................. 12
12.1. Normative References ................................. 12
12.2. Informative References ................................ 12
13. Acknowledgments ............................................ 13
Liu & Jiang Expires January 4, 2012 [Page 2]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
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. 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. Gap analysis draws on existing work in
(at least) [RFC5887] and [RFC4192]. The [I-D.jiang-6renum-enterprise]
contributions are incorporated into the more detailed gap analysis.
In this document, we discuss the overall requirements for
renumbering. The gap analysis is organized by the main steps of
renumbering process, which include the prefix management, the node
address (re)configuration, and address relevant entries update in
various gateways, routers and servers, etc. Besides the steps, a sub-
clause of renumbering event management is presented independently,
which targets to help the operational/administrative process.
2. Overall Requirements for Renumbering
This section envisions the effort potentially be achieved in the
future.
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 intervene.
o Address relevant entries update should be processed integrally and
error-prevented. [open question]Is it necessary to develop
automatic entries update mechanisms? If necessary, do we need
standard protocols/interface for it?
o [open question]Is it necessary/possible to develop a "One-Click"
fully automatic renumbering technology? What scenarios have the
potential possibility?
Liu & Jiang Expires January 4, 2012 [Page 3]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
o [open question]Is session survivability within our scope?
3. Existing Components for IPv6 Renumbering
Existing technical components for IPv6 renumbering are categorized
into three types described as the following.
3.1. Relevant Protocols and Mechanisms
Basically, renumbering is archived by utilizing existing protocols
rather than dedicated renumbering protocols.
o RA messages defined in [RFC4861], are used to deprecate/announce
old/new prefixes in renumbering.
o When a host is renumbered, it may use SLAAC [RFC4862] for address
configuration with the new prefix.
o Hosts configured through DHCPv6 [RFC3315] can reconfigure
addresses by initialing RENEW sessions when the current addresses'
lease time is expired or receiving the reconfiguration messages
initialed by the DHCPv6 servers.
o DHCP-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 has not been
widely used.
3.2. Management Tools
Some operations of renumbering could be automatically processed by
management tools to make the renumbering process more efficient and
accurate. The tools may be designed dedicated for renumbering or just
common tools could be utilized for some operations in renumbering.
Following are samples of the tools.
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 by a network
management server.
Liu & Jiang Expires January 4, 2012 [Page 4]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
o Asset management tools/systems. Some of this kind of 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.
o Other tools haven't been documented or aware of. (need further
contribution)
3.3. Procedures/Policies
o [RFC4192] proposed a procedure for renumbering a IPv6 network
without a flag day. The document includes a set of operational
suggestions which can be followed step by step by network
administrators.
o [I-D.jiang-6renum-enterprise] 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 during network design, considerations for
preparation of enterprise network renumbering, and considerations
during renumbering operation. Recommended solutions or strategies
are also described.
4. Managing Prefixes
When renumbering an enterprise site, a short prefix may be divided
into longer prefixes for subnets. So we need to carefully manage the
prefixes for prefix delivery, delegation, aggregation,
synchronization, coordination, etc.
4.1. Prefix delegation
Usually, the short prefix comes down from the operator and received
by DHCP server or router inside the enterprise network. The short
prefix could be automatically delegated through DHCP-PD. Then the
DHCP server or router can begin advertising the longer prefixes to
the subnets.
Besides DHCP-PD, HPD (Hierarchical Prefix Delegation for IPv6), which
uses bespoke ICMPv6 messages for prefix delegation, could also be
used for prefix delegation.
Liu & Jiang Expires January 4, 2012 [Page 5]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
4.2. Prefix assignment
When subnet routers receive the longer prefixes, they can directly
assign them to the hosts. Then the issues fall into the host address
configuration, which is described in the following section 5.1.
5. Address Configuration
5.1. Host Address Configuration
Both of the DHCPv6 and ND protocols have IP address configuration
function. They are suitable for different scenarios respectively.
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 DHCP according to the new
IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6-
configured hosts can reconfigure addresses by initialing RENEW
sessions when the current addresses' lease time is expired or
receiving the reconfiguration messages initialed by the DHCPv6
servers.
o Gaps of SLAAC and DHCP address configuration co-existence
While an IPv6 site is being renumbered, both DHCPv6 and ND may be
used to reconfigure the host addresses. This may cause potential
address configuration conflicts during renumbering procedure. The
issue mainly includes two situations:
- A DHCPv6-configured host receives RA messages containing new
prefix(es)
There are no standards specifying what approach should be taken
by a DHCPv6-configured host when it receives RA messages
containing new prefix. It depends on the operation system of the
host and cannot be predicted or controlled by the network. If
the host accepts the new prefix in RA, it may violet the DHCPv6-
managed policies. But if it ignores the RA messages and there
are no DHCPv6 reconfiguration messages received either, the
renumbering would fail. What is worse, the host may even receive
both the RA messages and DHCP-v6 reconfiguration messages and
finds the prefixes in the two protocols are different. This
means serious network configuration error occurring.
[open question]It is hard for the host to identify the RA
messages containing new prefix(es) representing adding an uplink
Liu & Jiang Expires January 4, 2012 [Page 6]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
or conflict caused by network configuration mistake. This may be
a gap in protocol.
- A SLAAC-configured finds DHCPv6 is in use
[RFC5887] and [I-D.jiang-6renum-enterprise] mentioned RA message
of ND protocol contains a "Managed Configuration" flag to
indicate DHCPv6 is in use. But it is unspecified what behavior
should be taken when the host receives RA messages with "M" set
to 1. The gap of standard will cause ambiguous host behavior
because it depends on the operation system of the host.
The host may start a DHCPv6 session and receives the DHCPv6
address configuration. It is also possible that the host finds
the DHCPv6 assigned prefix is different from the prefix in the
RA messages, which means there is a serious network
configuration error.
Another possibility is that the host may receive no response
from any DHCPv6 servers, which means the DHCPv6 service is not
available and the "Managed Configuration" flag was mis-
configured.
o Gaps of dynamic upsteam learning
- DHCP-configured host may want to learn about the upstream
availability of new prefixes or loss of prior prefixes
dynamically by deducing from periodic RA messages. This falls
into the host behavior issue, which may be determined by the
operating system of the host.
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 & Jiang Expires January 4, 2012 [Page 7]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
"Some routers cache IP addresses in some situations. So routers
might need to be restarted as a result of site renumbering"
[RFC2072].
After investigation, it seems (need further confirmation) this
caused by individual implementation and only happen on the old
type of routers. Therefore, it is not an issue anymore.
5.3. Static Address Configuration
Further gap analysis about static address issue could consider the
following suggestions (proposed by George Wesley in the mail list).
o Documenting how to limit the places where static addresses must be
used (vs FQDN or autoconf).
o Identifying gaps and proposing solutions in other areas to reduce
the number of places that static addresses are required.
o Documenting any gaps in [RFC4192] to make renumbering easier for a
statically-numbered set of hosts and potentially identifying a
problem statement for improving renumbering for static.
[open question]Besides the open questions above, the ULA utilization
issue may also need consideration.
6. Address Relevant Entries Update
When nodes in a site have been renumbered, then all the entries in
the site which contain the nodes' address must be updated. The
entries mainly include DNS records and filters in various entities
such as ACLs in firewalls/gateways.
6.1. DNS Records Update
o DNS update synchronization
For DNS records update, most sites will achieve it 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 A 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. But Secure Dynamic DNS
Update hasn't been widely deployed.
[open question]To popularize the [RFC3007] or to develop a
lightweight dedicated protocol for this need to be considered.
Liu & Jiang Expires January 4, 2012 [Page 8]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
DNS entries commonly have matching Reverse DNS entries which will
also need to be updated during renumbering.
[open question]So synchronizing the procedures of forward and reverse
DNS or even combining forward and reverse DNS updates in a single
procedure also need to be considered.
o DNS data structure optimization
[RFC2874] proposed a new A6 record type for DNS recording IPv6
address/prefix. And several extensions on query and processing were
also proposed. With the A6 record and the extensions, the DNS entries
update for renumbering could be easier than the original DNS
specification. But the [RFC2874] has not been widely used.
[open question]Is the DNS data structure optimization as [RFC2874]
necessary for easing renumbering? If necessary, the optimization in
[RFC2874] enough?
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."
[open question]Whether it is only an operational issue or we need
additional protocol/mechanism to standardize the interaction between
operator and enterprise inside DNS system needs to be considered.
6.2. Filters
There might be filters based on addresses/prefixes 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 filter/configuration management for renumbering.
7. Renumbering Event Management
From the perspective of network management, renumbering is a kind of
event which may need additional process to make the process more easy
and manageable. Following are several examples of such additional
process may ease the renumbering. Further contributions are expected.
Liu & Jiang Expires January 4, 2012 [Page 9]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
o DHCPv6 should be extended to indicate hosts the associated DNS
lifetimes when making DNS configuration.
o New interaction may need to be defined to achieve the cooperation
among branch sites/sub-networks to be renumbered together with
multiple prefixes.
o A notification mechanism may be needed to indicate the hosts that
a renumbering event of local recursive DNS happen or is going to
take place recursive.
8. Miscellaneous
8.1. Multicast
o The embedding of IPv6 unicast addresses into multicast addresses
and the embedded-RP (Rendezvous Point) will cause issues when
renumbering.
o Changing the unicast source address of a multicast sender might
also be an issue for receivers.
8.2. Mobility
o [RFC5887] suggested that, for Mobile IP, define a better mechanism
to handle change of home agent address while mobile is
disconnected.
9. Gap Summary
9.1. Managing Prefixes
None. (Would be added if gaps could be found.)
9.2. Address configuration
o Host address configuration
SLAAC and DHCP address configuration conflict
M/O debate
Host uplink learning
o Router address configuration
Router uplink learning
Liu & Jiang Expires January 4, 2012 [Page 10]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
Address cache caused restart
o Static address configuration
Further work is needed.
9.3. Address relevant entries update
o DNS records update
Host address configuration and DNS update synchronization
DNS forward and reverse update combination
o DNS data structure optimization
o DNS authority
o Filters
Filter and address configuration data management
9.4. Renumbering event management
o Additional management process to ease renumbering
10. 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 SeND
([RFC3971], Secure Neighbor Discovery) deployment may need to
validate prefixes.
o Influence to Security Controls
During renumbering, security controls (e.g. ACLs) blocking access to
legitimate resources should not be interrupted.
11. IANA Considerations
None.
Liu & Jiang Expires January 4, 2012 [Page 11]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
12. References
12.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
2000.
[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.
[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.
12.2. Informative References
[RFC2072] H. Berkowitz, "Router Renumbering Guide" RFC2072
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working
in progress.
Liu & Jiang Expires January 4, 2012 [Page 12]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
[I-D.chown-v6ops-renumber-thinkabout]
Chown, T., "Things to think about when Renumbering an IPv6
network", Work in Progress, September 2006.
[I-D.jiang-6renum-enterprise]
Jiang, S., and Liu B., " IPv6 Enterprise Network
Renumbering Scenarios and Guidelines ", Working in
Progress, July 2011.
[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>
13. Acknowledgments
This work adopts significant amounts of content from [RFC5887] and
[I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter,
Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford,
and Stig Venaas. Some useful materials were provided by Oliver
Bonaventure and his student Damien Leroy, thanks for them, too.
Useful comments and contributions were made by George Wesley, and
others.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Bing Liu
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China
Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China
Email: jiangsheng@huawei.com
Liu & Jiang Expires January 4, 2012 [Page 13]
Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011
Liu & Jiang Expires January 4, 2012 [Page 14]