Network Working Group S. Jiang
Internet Draft B. Liu
Intended status: Best Current Practice Huawei Technologies Co., Ltd
Expires: January 03, 2012 B. Carpenter
University of Auckland
July 01, 2011
IPv6 Enterprise Network Renumbering Scenarios and Guidelines
draft-jiang-6renum-enterprise-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 03, 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 analyzes the enterprise renumbering events and gives
the recommendations among the existing renumbering mechanisms.
According to the different stages of renumbering events,
Jiang & Liu Expires January 03, 2012 [Page 1]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
considerations and best current recommendations are described in
three categories: during network design, for preparation of
renumbering, and during renumbering operation. A gap inventory is
listed at the end of this document.
Table of Contents
1. Introduction ................................................. 3
2. Enterprise Network Illustration for Renumbering .............. 3
3. Enterprise Network Renumbering Scenario Categories ........... 4
3.1. Renumbering caused by External Network Factors........... 4
3.2. Renumbering caused by Internal Network Factors........... 5
4. Network Renumbering Considerations and Best Current
Recommendations ................................................. 5
4.1. Considerations and Recommendations during Network Design. 6
4.2. Considerations and Recommendations for the Preparation of
Renumbering .................................................. 8
4.3. Considerations and Recommendations during Renumbering
Operation .................................................... 9
5. Gap Inventory ............................................... 11
6. Security Considerations ..................................... 12
7. IANA Considerations ......................................... 12
8. Acknowledgements ............................................ 12
9. Change Log [RFC Editor please remove] ....................... 12
10. References ................................................. 13
10.1. Normative References .................................. 13
10.2. Informative References ................................ 14
Author's Addresses ............................................. 15
Jiang, et al. Expires January 03, 2012 [Page 2]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
1. Introduction
IPv6 site renumbering is considered difficult. Network managers would
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 undertakes scenario descriptions, including
documentation of current capability inventories and existing BCPs,
for enterprise networks. It takes the analysis conclusions from
[RFC5887] and other relevant documents as the primary input.
This document focuses on IPv6 only, by leaving IPv4 out of scope.
Dual-stack network or IPv4/IPv6 transition scenarios are out of scope,
too.
According to the different stages of renumbering events,
considerations and best current recommendations are described in
three categories: during network design, for preparation of
renumbering, and during renumbering operation. A gap inventory is
listed at the end of this document.
2. Enterprise Network Illustration for Renumbering
The enterprise network architecture is illustrated as the figure
below. From the renumbering perspective of view, these entities
relevant to renumbering are highlighted.
Address reconfiguration is fulfilled either by DHCPv6 or ND
protocols. Static address assignment is not considered in this
version. During the renumbering event, the DNS records need to be
synchronized while routing tables, ACLs and IP filtering tables in
various gateways also need to be updated, too.
Jiang, et al. Expires January 03, 2012 [Page 3]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | | DHCP | | DNS | |
| |Server| |Server| +Server+ |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1 Enterprise network illustration
It is assumed that IPv6 enterprise networks are IPv6-only, or dual-
stack in which a logical IPv6 plane is independent from IPv4. The
complicated IPv4/IPv6 co-existing scenarios are out of scope.
This document focuses on the unicast addresses; site-local, link-
local, multicast and anycast addresses are out of scope.
3. Enterprise Network Renumbering Scenario Categories
In this section, we category enterprise network renumbering scenarios
mainly according to different reasons. Some of renumbering reasons
described in [RFC2071] has out of date, or not suitable in IPv6, or
not suitable for enterprise networks.
3.1. Renumbering caused by External Network Factors
The most influential external network factor is the uplink ISP.
Jiang, et al. Expires January 03, 2012 [Page 4]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
o The enterprise network switches to a new ISP. Of course, the
prefixes received from different ISPs are different. This is the
most common scenario.
Whether there is an overlap time between the old and new ISPs
would also influence the possibility whether the enterprise can
fulfill renumbering without a flag day [RFC4192].
o The renumbering event may be initiated by receiving new prefixes
from the same uplink. The typical scenario is that the DHCP server
in ISP delegates a new prefix to the enterprise network. Or the
enterprise network may be switched to a different location within
the network topology of the same ISP due to various
considerations, such as commercial, performance or services
reasons, etc. The ISP itself may also be renumbered due to
topology change or migration to a different or additional prefix.
These ISP renumbering events would initiate enterprise network
renumbering events, of course.
o The enterprise network adds new uplink(s) for multihoming
purpose. This may not a typical renumbering because the original
addresses will not be changed. However, initial numbering may be
considered as a special renumbering event. If the administrators
only want part of the network to have multiple prefixes, the
renumbering process should be carefully managed.
3.2. Renumbering caused by Internal Network Factors
o As companies split, merge, grow, or reorganize, the enterprise
network architectures may need to be re-built. This will trigger
the internal renumbering.
4. Network Renumbering Considerations and Best Current Recommendations
In order to carry out renumbering in an enterprise network,
systematic planning and administrative preparation are needed.
Carefully planning and preparation could make the renumbering process
smoother.
This section tries to give the recommended solutions or strategies
for the enterprise renumbering among the existing mechanisms. There
are a few gaps analyzed by [I-D.liu-6renum-gap-analysis]. If they are
filled in the future, the enterprise renumbering may be processed
more automatically, with fewer issues.
Jiang, et al. Expires January 03, 2012 [Page 5]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
4.1. Considerations and Recommendations during Network Design
This section describes the renumbering relevant considerations or
issues that a network architect should carefully plan when he builds
or designs a new network.
- Prefix Delegation
In a large or a multi-site enterprise network, the prefix should
be carefully managed, particularly during renumbering events.
Prefix information needs to be delegated from router to router.
The DHCPv6 Prefix Delegation options [RFC3633] provide a mechanism
for automated delegation of IPv6 prefixes. DHCPv6 PD options may
also be used between the enterprise routers and their upstream
ISPs.
- Usage of FQDN
It is recommended that Fully-Qualified Domain Names (FQDNs) should
be used to configure network connectivity, such as tunnels. The
capability to use FQDNs as endpoint names has been standardized in
several RFCs, such as [RFC5996], although many system/network
administrators do not realize that it is there and works well as a
way to avoid manual modification during renumbering.
Service Location Protocol [RFC2608] and multicast DNS with SRV
records for service discovery can reduce the number of places that
IP addresses need to be configured.
- Address Types
This document focuses on the dynamic-configured global unicast
addresses in enterprise networks. They are the targets of
renumbering events.
Manual-configured addresses are not scalable in medium to large
sites, hence be out of scope. However, some hosts such as servers
may need static addresses. Manual-configured addresses/hosts
should be avoided as much as possible.
[Open Question to WG] What we can do regarding to manual
configured hosts and static addresses, which do need to be
changed?
Unique Local Address (ULA, [RFC4193]) may be used on local routers
or servers, which only intends for local communications, usually
Jiang, et al. Expires January 03, 2012 [Page 6]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
inside of enterprise networks. Normally, they do NOT need to be
changed during the renumbering event.
[Open Question to WG] Is anyone actually using ULAs?
- Address configuration models
In IPv6 networks, there are two auto-configuration models for
address assignment: the Stateless Address Auto-Configuration
(SLAAC) by Neighbor Discovery (ND, [RFC4861, RFC4862]) and the
stateful address configuration by Dynamic Host Configuration
Protocol for IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6
can also support host-generate address model by assigning prefix
through DHCPv6 messages [I-D.ietf-dhc-host-gen-id].
ND is considered easier to renumber by broadcasting a Router
Advertisement message with a new prefix. DHCPv6 can also trigger
the renumbering process by sending unicast RECONFIGURE messages
though it may cause a large number of interactions between hosts
and DHCPv6 server.
In principle, a network should choose only one address
configuration model and employs either ND or DHCPv6. This document
has no preference between ND and DHCPv6 address configuration
models.
However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 co-existing scenarios. The
current protocols do not effectively prevent that both SLAAC and
DHCPv6 address assignment are used in the same network (see M bit
analysis in section 5.1.1 [RFC5887]). It is network architects'
job to make sure only one configuration model is employed. Even in
a large network that contains several subnet works, it is
recommended not to mix the two address configuration models though
isolately using them in different subnet works may reduce the risk
partly.
- DNS
It is recommended that the site have an automatic and systematic
procedure for updating/synchronising its DNS records, including
both forward and reverse mapping [RFC2874]. Manually on-demand
updating model is considered as a harmful problem creator in
renumbering event.
A6 DNS record model is recommended over AAAA record model for
renumbering purpose [RFC2874, RFC3364].
Jiang, et al. Expires January 03, 2012 [Page 7]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
In order to simplify the operation procedure, the network
architect should combine the forward and reverse DNS updates in a
single procedure.
If a small site depends on its ISP's DNS system rather than
maintains its own one. When renumbering, it requires
administrative coordination between the site and its ISP.
Alternatively, the DNS synchronizing may be completed through the
Secure Dynamic DNS Update.
- Security
Any automatic renumbering scheme has a potential exposure to
hijacking at the moment that a new address is announced. Proper
network security mechanisms should be employed. Secure Neighbor
Discovery (SEND, [RFC3971]), which does not widely deployed, is
recommended to replace ND. Alternatively, certain lightweight
renumbering specific security mechanism may be developed in the
future. DHCPv6 build-in secure mechanisms, like Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages
[RFC3315] are recommended.
- Miscellaneous
A site or network should also avoid to embed addresses from other
sites or networks in its own configuration data. Instead, the
Fully-Qualified Domain Names should be used. Thusness, these
connectivities can survive after renumbering events. This also
applies to host-based connectivities.
4.2. Considerations and Recommendations for the Preparation of
Renumbering
It is not possible to reduce a prefix's lifetime to below two hours.
So, renumbering should not be an unplanned sudden event. This issue
could only be avoided by early planning and preparation.
This session describes several recommendations for the preparation of
enterprise renumbering event. By adopting these recommendations, a
site could be renumbered easier. However, these recommendations are
not cost free. They might increase the daily burden of network
operation. Therefore, only these networks that are expected to be
renumbered soon or very frequently should adopt these recommendations
with the balance consideration between daily cost and renumbering
cost.
- Reduce the address preferred time or valid time or both.
Jiang, et al. Expires January 03, 2012 [Page 8]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
Long-lifetime addresses may cause issues for renumbering events.
Particularly, some offline hosts may reconnect back using these
addresses after renumbering events. Shorter preferred lifetime
with relevant long valid lifetime may get short transition period
for renumbering event and avoid address renew too frequent.
- Reduce the DNS record TTL.
The DNS record TTL on the local DNS server should be manipulated
to ensure that stale addresses are not cached.
- Reduce the DNS configuration lifetime on the hosts.
Since the DNS server could be renumbered as well, the DNS
configuration lifetime on the hosts should also be reduced if
renumbering events are expected. The DNS configuration can be done
through either ND [RFC6106] or DHCPv6 [RFC3646]. However, DHCPv6
DNS option does not include associated lifetime. It should be
updated.
4.3. Considerations and Recommendations during Renumbering Operation
Renumbering events are not instantaneous events. Normally, there is a
transition period, in which both the old prefix and the new prefix
are used in the site. Better network design and management, better
pre-preparation and longer transition period are helpful to reduce
the issues during renumbering operation.
- Within/without a flag day
As is described in [RFC4192], "a 'flag day' is a procedure in
which the network, or a part of it, is changed during a planned
outage, or suddenly, causing an outage while the network
recovers."
If renumbering event is processed within a flag day, the network
service/connectivity will be outage for a period till the
renumbering event is completed. It is efficient and provides
convenient for network operation and management. But network
outage is usually unacceptable for end users and the enterprises.
Renumbering procedure without a flag day provides smooth addresses
switching, but much more operational complexity and difficulty is
introduced.
- Transition period
Jiang, et al. Expires January 03, 2012 [Page 9]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
If renumbering transition period is longer than all addresses
lifetime, after which the addresses lease expire, each host will
automatically pick up its new IP address. In this case, it would
be the DHCP server or Router Advertisement itself that
automatically accomplishes client renumbering.
- Network initiative enforced renumbering
If the network has to enforce renumbering before addresses lease
expire, the network should initiate enforcement messages, either
in Router Advertisement messages or DHCPv6 RECONFIGURE messages.
- Impact to branch/main sites
Renumbering in main/branch site may cause impact on branch/main
site communication. The routes, ingress filtering of site's
gateways, and DNS may need to be updated. This needs carefully
planning and organizing.
- DNS record update and DNS configuration on hosts
DNS records should be updated if hosts are renumbered. If the site
depends on ISP's DNS system, it should report the new host's DNS
records to its ISP. During the transition period, both old and new
DNS records are valid. If the TTL of DNS records is shorter than
the transition period, administrative operation may not be
necessary.
DNS configuration on hosts should be updated if local recursive
DNS servers are renumbered. During the transition period, both old
and new DNS addresses may co-exist on the hosts. If the lifetime
of DNS configuration is shorter than the transition period, name
resolving failure may not be reduced to minimum. 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.
- 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.
- 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
Jiang, et al. Expires January 03, 2012 [Page 10]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
connecting to ISP B initiates a renumbering event in order to
properly act filter function.
- Tunnel concentrator renumbering
Tunnel concentrator itself might be renumbered. This change should
be reconfigured to relevant hosts or router, unless the
configuration of tunnel concentrator was based on FQDN.
5. Gap Inventory
This section lists a few issues that still remain unsolvable. Some of
them may be inherently unsolvable.
- Manual or script-driven procedures will break the completely
automatic host renumbering.
- Some environments like embedded systems might not use DHCP or
SLAAC and even configuration scripts might not be an option.
This creates special problems that no general-purpose solution
is likely to address.
- TCP and UDP flows can't survive at renumbering event at either
end.
- Some address configuration data might be widely dispersed and
much harder to find, even will inevitably be found only after
the renumbering event.
- The embedding of IPv6 unicast addresses into multicast
addresses and the embedded-RP (Rendezvous Point) [RFC3956] will
cause issues when renumbering.
- Changing the unicast source address of a multicast sender might
also be an issue for receivers.
- When a renumbering event takes place, entries in the state
table of tunnel concentrator that happen to contain the
affected addresses will become invalid and will eventually time
out. However, this can be considered as harmless though it
takes sources on these devices for a while.
- A site that is listed in a black list can escape that list by
renumbering itself. The site itself of course will not
initiatively to report its renumbering and the black list may
not be able to monitor or discover the renumbering event.
Jiang, et al. Expires January 03, 2012 [Page 11]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
- Multihomed site, using SLAAC for one address prefix and DHCPv6
for another, would clearly create a risk of inconsistent host
behaviour and operational confusion.
- The impact of portion renumbering may need to be analyzed
further.
Some of these issues can be considered as harmless or have minimum
impacts.
6. Security Considerations
A site that is listed in a black list can escape that list by
renumbering itself.
Any automatic renumbering scheme has a potential exposure to
hijacking at the moment that a new address is announced. Proper
network security mechanisms should be employed. SEND is recommended
to replace ND. Alternatively, certain lightweight renumbering
specific security mechanism may be developed in the future. DHCPv6
build-in secure mechanisms, like Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages
[RFC3315] are recommended.
The security updates will need to be made in two stages (immediately
before and immediately after the event).
[Editor note: this section needs further work.]
7. IANA Considerations
This draft does not request any IANA action.
8. Acknowledgements
This work is illumined by RFC5887, so thank for RFC 5887 authors,
Randall Atkinson and Hannu Flinck. Useful ideas were also illumined
by documents from Tim Chown and Fred Baker. The authors also want to
thank Wesley George, Olivier Bonaventure and other 6renum members for
valuable comments.
9. Change Log [RFC Editor please remove]
draft-jiang-6renum-enterprise-00, original version, 2011-07-01
Jiang, et al. Expires January 03, 2012 [Page 12]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
10. References
10.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[RFC3315] Droms, R., 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.
[RFC3646] R. Droms, "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3956] Savola, P., 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
[RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 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.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010.
[RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 6106, November 2011.
Jiang, et al. Expires January 03, 2012 [Page 13]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
10.2. Informative References
[RFC2071] Ferguson, P., and H. Berkowitz., "Network Renumbering
Overview: Why would I want it and what is it anyway?", RFC
2071, January 1997.
[RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)", RFC 3364, August
2002.
[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 S. Shen, "Secure DHCPv6 Using CGAs", working
in progress.
[I-D.ietf-dhc-host-gen-id]
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
April, 2011.
[I-D.liu-6renum-gap-analysis]
Liu, B., and S. Jiang, "IPv6 Site Renumbering Gap Analysis",
working in progress.
Jiang, et al. Expires January 03, 2012 [Page 14]
Internet-Draft draft-jiang-6renum-enterprise-00.txt July 2011
Author's Addresses
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
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
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Jiang, et al. Expires January 03, 2012 [Page 15]