draft-ietf-6renum-enterprise-04.txt   draft-ietf-6renum-enterprise-05.txt 
Network Working Group S. Jiang Network Working Group S. Jiang
Internet Draft B. Liu Internet Draft B. Liu
Intended status: Informational Huawei Technologies Co., Ltd Intended status: Informational Huawei Technologies Co., Ltd
Expires: May 27, 2013 B. Carpenter Expires: June 23, 2013 B. Carpenter
University of Auckland University of Auckland
November 28, 2012 December 21, 2012
IPv6 Enterprise Network Renumbering Scenarios and Guidelines IPv6 Enterprise Network Renumbering Scenarios,
draft-ietf-6renum-enterprise-04.txt Considerations and Methods
draft-ietf-6renum-enterprise-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/. at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2013. This Internet-Draft will expire on June 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document analyzes events that cause renumbering and describes This document analyzes events that cause renumbering and describes
the best renumbering practice. Best practices are described in three the current renumbering methods. These are described in three
categories: those applicable during network design, those applicable categories: those applicable during network design, those applicable
during preparation for renumbering, and those applicable during the during preparation for renumbering, and those applicable during the
renumbering operation. renumbering operation.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. Enterprise Network Illustration for Renumbering .............. 3 2. Enterprise Network Illustration for Renumbering .............. 3
3. Enterprise Network Renumbering Scenario Categories ........... 4 3. Enterprise Network Renumbering Scenario Categories ........... 5
3.1. Renumbering Caused by External Network Factors........... 4 3.1. Renumbering Caused by External Network Factors .......... 5
3.2. Renumbering caused by Internal Network Factors........... 5 3.2. Renumbering caused by Internal Network Factors .......... 6
4. Network Renumbering Considerations and Best Current Practices. 5 4. Network Renumbering Considerations and Current Methods ....... 6
4.1. Considerations and Best Current Practices during Network 4.1. Considerations and Current Methods during Network Design. 6
Design ....................................................... 6 4.2. Considerations and Current Methods for the Preparation of
4.2. Considerations and Best Current Practices for the Preparation Renumbering ................................................. 10
of Renumbering .............................................. 10 4.3. Considerations and Current Methods during Renumbering
4.3. Considerations and Best Current Practices during Renumbering
Operation ................................................... 11 Operation ................................................... 11
5. Security Considerations ..................................... 13 5. Security Considerations ..................................... 13
6. IANA Considerations ......................................... 13 6. IANA Considerations ......................................... 14
7. Acknowledgements ............................................ 13 7. Acknowledgements ............................................ 14
8. References .................................................. 13 8. References .................................................. 14
8.1. Normative References ................................... 13 8.1. Normative References ................................... 14
8.2. Informative References ................................. 15 8.2. Informative References ................................. 15
Author's Addresses ............................................. 17 Author's Addresses ............................................. 17
1. Introduction 1. Introduction
Site renumbering is difficult. Network managers frequently attempt to Site renumbering is difficult. Network managers frequently attempt to
avoid renumbering by numbering their network resources from Provider avoid future renumbering by numbering their network resources from
Independent (PI) address space. However, widespread use of PI might Provider Independent (PI) address space. However, widespread use of
create serious BGP4 scaling problems and according to Regional PI would aggravate BGP4 scaling problems [RFC4116] and, depending on
Internet Registry (RIR) policies, PI space is not always available Regional Internet Registry (RIR) policies, PI space is not always
for enterprises Therefore, it is desirable to develop mechanisms that available for enterprises of all sizes. Therefore, it is desirable to
simplify IPv6 renumbering. develop mechanisms that simplify IPv6 renumbering for enterprises.
This document undertakes scenario descriptions, including This document is an analysis of IPv6 site renumbering for enterprise
documentation of current capabilities and existing BCPs, for networks. It undertakes scenario descriptions, including
enterprise networks. It takes [RFC5887] and other relevant documents documentation of current capabilities and existing practices. The
as the primary input. reader is assumed to be familiar with [RFC4192] and [RFC5887].
Proposals for new technology and methods are out of scope.
Since the IPv4 and IPv6 are logically separated from the perspective Since IPv4 and IPv6 are logically separate from the perspective of
of renumbering, regardless of overlapping of the IPv4/IPv6 networks renumbering, regardless of overlapping of the IPv4/IPv6 networks or
or devices, this document focuses on IPv6 only, by leaving IPv4 out devices, this document focuses on IPv6 only, leaving IPv4 out of
of scope. Dual-stack network or IPv4/IPv6 transition scenarios are scope. Dual-stack network or IPv4/IPv6 transition scenarios are out
out of scope, too. of scope, too.
This document focuses on enterprise network renumbering, however, This document focuses on enterprise network renumbering; however,
most of the analysis is also applicable to ISP network renumbering. most of the analysis is also applicable to ISP network renumbering.
Renumbering in home networks is out of scope, but it can also benefit Renumbering in home networks is out of scope, but it can also benefit
from the analysis in this document. from the analysis in this document.
The concept of enterprise network and a typical network illustration The concept of an enterprise network and a typical network
are introduced first. Then, best renumbering practices are introduced illustration are introduced first. Then, current renumbering methods
according to the following categories: those applicable during are introduced according to the following categories: those
network design, those applicable during preparation for renumbering, applicable during network design, those applicable during preparation
and those applicable during the renumbering operation. for renumbering, and those applicable during the renumbering
operation.
2. Enterprise Network Illustration for Renumbering 2. Enterprise Network Illustration for Renumbering
An Enterprise Network as defined in [RFC4057] is: a network that has An Enterprise Network as defined in [RFC4057] is a network that has
multiple internal links, one or more router connections to one or multiple internal links, one or more router connections to one or
more Providers, and is actively managed by a network operations more Providers, and is actively managed by a network operations
entity. entity.
Figure 1 provides a sample enterprise network architecture. Those Figure 1 provides a sample enterprise network architecture for a
entities relevant to renumbering are highlighted. simple case. Those entities mainly affected by renumbering are
illustrated:
Address reconfiguration is fulfilled either by Dynamic Host * Gateway: Border router, firewall, web cache, etc.
* Application server (for internal or external users)
* DNS and DHCP servers
* Routers
* Hosts (desktops etc.)
Address reconfiguration is fulfilled either by the Dynamic Host
configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for
IPv6 (ND) protocols. During the renumbering event, the Domain Name IPv6 (ND) protocols. During a renumbering event, the Domain Name
Service (DNS) records need to be synchronized while routing tables, Service (DNS) records need to be synchronized while routing tables,
Access Control Lists (ACLs) and IP filtering tables in various Access Control Lists (ACLs) and IP filtering tables in various
devices also need to be updated, too. devices also need to be updated. It is taken for granted that
applications will work entirely on the basis of DNS names, but any
direct dependencies on IP addresses in application layer entities
must also be updated.
Static address issue is described in a dedicated draft The issue of static addresses is described in a dedicated draft
[I-D.ietf-6renum-static-problem]. [I-D.ietf-6renum-static-problem].
Uplink 1 Uplink 2 Uplink 1 Uplink 2
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+ +---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ | | +-------+ +-------+ |
| Enterprise Network | | Enterprise Network |
| +------+ +------+ +------+ | | +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | | | | APP | |DHCPv6| | DNS | |
| |Server| |Server| +Server+ | | |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ | | +---+--+ +---+--+ +--+---+ |
| | | | | | | | | |
| ---+--+---------+------+---+- | | ---+--+---------+------+---+- |
| | | | | | | |
| +--+---+ +---+--+ | | +--+---+ +---+--+ |
| |Router| |Router| | | |Router| |Router| |
| +--+---+ +---+--+ | | +--+---+ +---+--+ |
| | | | | | | |
| -+---+----+-------+---+--+- | | -+---+----+-------+---+--+- |
| | | | | | | | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ | | +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| | | |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ |
+----------------------------------------+ +----------------------------------------+
Figure 1 Enterprise network illustration Figure 1 Enterprise network illustration
It is assumed that IPv6 enterprise networks are IPv6-only, or dual- It is assumed that IPv6 enterprise networks are IPv6-only, or dual-
stack in which a logical IPv6 plane is independent from IPv4. stack in which a logical IPv6 plane is independent from IPv4. As
IPv4/IPv6 co-existence scenarios are out of scope. mentioned above, IPv4/IPv6 co-existence scenarios are out of scope.
This document focuses on the unicast addresses; site-local, link- This document focuses on routable unicast addresses; link-local,
local, multicast and anycast addresses are out of scope. multicast and anycast addresses are also out of scope.
3. Enterprise Network Renumbering Scenario Categories 3. Enterprise Network Renumbering Scenario Categories
In this section, we divide enterprise network renumbering scenarios In this section, we divide enterprise network renumbering scenarios
into two categories defined by external and internal network factors, into two categories defined by external and internal network factors,
which require renumbering for different reasons. which require renumbering for different reasons.
3.1. Renumbering Caused by External Network Factors 3.1. Renumbering Caused by External Network Factors
The following ISP uplink-related events can cause renumbering: The following ISP uplink-related events can cause renumbering:
o The enterprise network switches to a new ISP. When this occurs, o The enterprise network switches to a new ISP. When this occurs,
the enterprise stop numbering its resources form the prefix the enterprise stop numbering its resources from the prefix
allocated by the old ISP and renumbers its resources from the allocated by the old ISP and renumbers its resources from the
prefix allocated by the new ISP. prefix allocated by the new ISP.
When the enterprise switches ISPs, a "flag day" renumbering event When the enterprise switches ISPs, a "flag day" renumbering event
[RFC4192] may be averted if, during a transitional period, the [RFC4192] may be averted if, during a transitional period, the
enterprise network may number its resources from either prefix. enterprise network may number its resources from either prefix.
One way to facilitate such a transitional period is for the One way to facilitate such a transitional period is for the
enterprise to contract for service from both ISPs during the enterprise to contract for service from both ISPs during the
transition. transition.
skipping to change at page 5, line 36 skipping to change at page 6, line 9
o The enterprise network adds new uplink(s) for multihoming purposes. o The enterprise network adds new uplink(s) for multihoming purposes.
This might not be a typical renumbering case because the original This might not be a typical renumbering case because the original
addresses will not be changed. However, initial numbering may be addresses will not be changed. However, initial numbering may be
considered as a special renumbering event. The enterprise network considered as a special renumbering event. The enterprise network
removes uplink(s) or old prefixes. removes uplink(s) or old prefixes.
3.2. Renumbering caused by Internal Network Factors 3.2. Renumbering caused by Internal Network Factors
o As companies split, merge, grow, relocate or reorganize, the o As companies split, merge, grow, relocate or reorganize, the
enterprise network architectures might need to be re-built. This enterprise network architectures might need to be re-built. This
will trigger the internal renumbering. will trigger partial or total internal renumbering.
o The enterprise network might proactively adopt a new address o The enterprise network might proactively adopt a new address
scheme, for example by switching to a new transition mechanism or scheme, for example by switching to a new transition mechanism or
stage of a transition plan. stage of a transition plan.
o The enterprise network might reorganize its topology or subnets. o The enterprise network might reorganize its topology or subnets.
4. Network Renumbering Considerations and Best Current Practices 4. Network Renumbering Considerations and Current Methods
In order to carry out renumbering in an enterprise network, In order to carry out renumbering in an enterprise network,
systematic planning and administrative preparation are needed. systematic planning and administrative preparation are needed.
Carefully planning and preparation could make the renumbering process Careful planning and preparation could make the renumbering process
smoother. smoother.
This section recommends some solutions or strategies for the This section describes current solutions or strategies for enterprise
enterprise renumbering, chosen among existing mechanisms. There are renumbering, chosen among existing mechanisms. There are known gaps
known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps analyzed by [I-D.ietf-6renum-gap-analysis] and
are filled in the future, the enterprise renumbering can be processed [I-D.ietf-6renum-static-problem]. If these gaps are filled in the
more automatically, with fewer issues. future, enterprise renumbering can be processed more automatically,
with fewer issues.
4.1. Considerations and Best Current Practices during Network Design 4.1. Considerations and Current Methods during Network Design
This section describes the consideration or issues relevant to This section describes the consideration or issues relevant to
renumbering that a network architect should carefully plan when renumbering that a network architect should carefully plan when
building or designing a new network. building or designing a new network.
- Prefix Delegation - Prefix Delegation
In a large or a multi-site enterprise network, the prefix should In a large or a multi-site enterprise network, the prefix should
be carefully managed, particularly during renumbering events. be carefully managed, particularly during renumbering events.
Prefix information needs to be delegated from router to router. Prefix information needs to be delegated from router to router.
The DHCPv6 Prefix Delegation options [RFC3633] and The DHCPv6 Prefix Delegation options [RFC3633] and [RFC6603]
[RFC6603] provide a mechanism for automated delegation of IPv6 provide a mechanism for automated delegation of IPv6 prefixes.
prefixes. Normally, DHCPv6 PD options are used between the Normally, DHCPv6 Prefix Delegation (PD) options are used between
internal enterprise routers, for example, a router receives the internal enterprise routers, for example, a router receives
prefix (es) from its upstream router (might be a border gateway or prefix(es) from its upstream router (a border gateway or edge
edge router .etc) through DHCPv6 PD options and then advertise it router etc.) through DHCPv6 PD options and then advertises it
(them) to the local hosts through RA messages. (them) to the local hosts through Router Advertisement (RA)
messages.
- Usage of FQDN - Usage of FQDN
In general, Fully-Qualified Domain Names (FQDNs) are recommended In general, Fully-Qualified Domain Names (FQDNs) are recommended
to be used to configure network connectivity, such as tunnels, to be used to configure network connectivity, such as tunnels,
servers etc. The capability to use FQDNs as endpoint names has servers etc. The capability to use FQDNs as endpoint names has
been standardized in several RFCs, such as [RFC5996], although been standardized in several RFCs, for example for IPsec
many system/network administrators do not realize that it is there [RFC5996], although many system/network administrators do not
and works well as a way to avoid manual modification during realize that it is there and works well as a way to avoid manual
renumbering. modification during renumbering.
Note that, using FQDN would rely on DNS systems. For a link local Note that using FQDN would rely on DNS systems. For a link local
network that does not have a DNS system, multicast DNS network that does not have a DNS system, multicast DNS
[I-D.cheshire-dnsext-multicastdns] could be utilized. For some [I-D.cheshire-dnsext-multicastdns] could be utilized. For some
specific circumstances, using FQDN might not be proper if adding specific circumstances, using FQDN might not be chosen if adding
DNS service in the node/network would cause un-desired complexity DNS service in the node/network would cause undesired complexity
or issues. or issues.
Service discovery protocols such as Service Location Protocol Service discovery protocols such as Service Location Protocol
[RFC2608], multicast DNS with SRV records and DNS Service [RFC2608], multicast DNS with SRV records and DNS Service
Discovery [I-D.cheshire-dnsext-dns-sd] can engage using FQDN and Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce
reduce the number of places that IP addresses need to be the number of places that IP addresses need to be configured. But
configured. But it should be noted that these protocols are it should be noted that these protocols are normally used link-
normally used link-local only. local only.
Network designers generally have little control over the design of
application software. However, it is important to avoid any
software that has built-in dependency on IP addresses instead of
FQDNs [I-D.ietf-6renum-static-problem].
- Usage of ULA - Usage of ULA
Unique Local Addresses (ULAs) are defined in [RFC4193] as Unique Local Addresses (ULAs) are defined in [RFC4193] as
provider-independent prefixes. And since there is a 40 bits pseudo provider-independent prefixes. Since there is a 40 bits pseudo
random field in the ULA prefix, there is no practical risk of random field in the ULA prefix, there is no practical risk of
collision (please refer to section 3.2.3 in [RFC4193] for more collision (please refer to section 3.2.3 in [RFC4193] for more
detail). For enterprise networks, using ULA along with PA can detail). For enterprise networks, using ULA simultaneously with
provide a logically local routing plane separated from the Provider Aggregated (PA) addresses can provide a logically local
globally routing plane. The benefit is to ensure stable and routing plane separated from the global routing plane. The benefit
specific local communication regardless of the ISP uplink failure. is to ensure stable and specific local communication regardless of
This benefit is especially meaningful for renumbering. It mainly any ISP uplink failure. This benefit is especially meaningful for
includes three use cases as the following. renumbering. It mainly includes three use cases described below.
During the transition period, it is desirable to isolate local During the transition period, it is desirable to isolate local
communication changes in the global routing plane. If we use ULA communication changes in the global routing plane. If we use
for the local communication, this isolation is achieved. ULA for the local communication, this isolation is achieved.
Enterprise administrators might want to avoid the need to renumber Enterprise administrators might want to avoid the need to
their internal-only, private nodes when they have to renumber the renumber their internal-only, private nodes when they have to
PA addresses of the whole network because of changing ISPs, ISPs renumber the PA addresses of the whole network because of
restructuring their address allocation, or any other reasons. In changing ISPs, ISPs restructuring their address allocation, or
these situations, ULA is an effective tool for the internal-only any other reasons. In these situations, ULA is an effective
nodes. tool for the internal-only nodes.
For multicast, ULA can be a way of avoiding renumbering from ULA can be a way of avoiding renumbering from having an impact
having an impact on multicast. In most deployments multicast is on multicast. In most deployments multicast is only used
only used internally (intra-domain), and the addresses used for internally (intra-domain), and the addresses used for
multicast sources and Rendezvous-Points need not be reachable nor multicast sources and Rendezvous-Points need not be reachable
routable externally. Hence one may at least internally make use of nor routable externally. Hence one may at least internally
ULA for multicast specific infrastructure. make use of ULA for multicast specific infrastructure.
- Address Types - Address Types
This document focuses on the dynamically-configured global unicast This document focuses on the dynamically-configured global unicast
addresses in enterprise networks. They are the targets of addresses in enterprise networks. They are the targets of
renumbering events. renumbering events.
Manual-configured addresses are not scalable in medium to large Manually-configured addresses are not scalable in medium to large
sites, hence are out of scope. Manually-configured addresses/hosts sites, hence should be avoided for both network elements and
should be avoided as much as possible. application servers [I-D.ietf-6renum-static-problem].
- Address configuration models - Address configuration models
In IPv6 networks, there are two auto-configuration models for In IPv6 networks, there are two auto-configuration models for
address assignment: Stateless Address Auto-Configuration (SLAAC, address assignment after each host obtains a link-local address:
[RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful Stateless Address Auto-Configuration (SLAAC, [RFC4862]) by
address configuration by Dynamic Host Configuration Protocol for Neighbor Discovery (ND, [RFC4861]) and stateful address
IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also configuration by Dynamic Host Configuration Protocol for IPv6
support host-generated address model by assigning a prefix through (DHCPv6, [RFC3315]). In the latest work, DHCPv6 may also support
the host-generated address model by assigning a prefix through
DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. DHCPv6 messages [I-D.ietf-dhc-host-gen-id].
ND is considered easier to renumber by broadcasting a Router SLAAC is considered to support easy renumbering by broadcasting a
Advertisement message with a new prefix. DHCPv6 can also trigger Router Advertisement message with a new prefix. DHCPv6 can also
the renumbering process by sending unicast RECONFIGURE messages, trigger the renumbering process by sending unicast RECONFIGURE
though it might cause a large number of interactions between hosts messages, though it might cause a large number of interactions
and DHCPv6 server. between hosts and the DHCPv6 server.
This document has no preference between ND and DHCPv6 address This document has no preference between the SLAAC and DHCPv6
configuration models. It is network architects' job to decide address configuration models. It is the network architects' job to
which configuration model is employed. But it should be noticed decide which configuration model is employed. But it should be
that using DHCPv6 and ND together within one network, especially noticed that using DHCPv6 and SLAAC together within one network,
in one subnet, might cause operational issues. For example, some especially in one subnet, might cause operational issues. For
hosts use DHCPv6 as the default configuration model while some use example, some hosts use DHCPv6 as the default configuration model
ND. Then the hosts' address configuration model depends on the while some use ND. Then the hosts' address configuration model
policies of operating systems and cannot be controlled by the depends on the policies of operating systems and cannot be
network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses controlled by the network. Section 5.1 of
more details on this topic. So, in general, this document
recommends using DHCPv6/SLAAC independently in different subnets. [I-D.ietf-6renum-gap-analysis] discusses more details on this
topic. So, in general, this document recommends using DHCPv6 or
SLAAC independently in different subnets.
However, since DHCPv6 is also used to configure many other network However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 co-existence scenarios. parameters, there are ND and DHCPv6 co-existence scenarios.
Combinations of address configuration models might coexist within Combinations of address configuration models might coexist within
a single enterprise network. [I-D.ietf-savi-mix] provides a single enterprise network. [I-D.ietf-savi-mix] provides
recommendations to avoid collisions and to review collision recommendations to avoid collisions and to review collision
handling in such scenarios. handling in such scenarios.
- DNS - DNS
It is recommended that the site have an automatic and systematic
procedure for updating/synchronizing its DNS records, including
both forward and reverse mapping [RFC2874]. A manual on-demand
updating model does not scale, and increases the chance of errors.
Although the A6 DNS record model [RFC2874] was designed for easier Although the A6 DNS record model [RFC2874] was designed for easier
renumbering, it left many unsolved technical issues [RFC3364]. renumbering, it left many unsolved technical issues [RFC3364].
Therefore, it has been moved to historic status [RFC6563] and is Therefore, it has been moved to historic status [RFC6563] and
not recommended. should not be used.
In order to simplify the operational procedure, the network
architect should combine the forward and reverse DNS updates in a
single procedure.
Often, a small site depends on its ISP's DNS system rather than Often, a small site depends on its ISP's DNS system rather than
maintaining its own. When renumbering, this requires maintaining its own. When renumbering, this requires
administrative coordination between the site and its ISP. administrative coordination between the site and its ISP.
The DNS synchronization can be completed through the Secure DNS It is recommended that the site have an automatic and systematic
Dynamic Update [RFC3007]. Dynamic DNS update can be provided by procedure for updating/synchronizing its DNS records, including
the DHCPv6 client or by the server on behalf of individual hosts. both forward and reverse mapping. In order to simplify the
[RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and operational procedure, the network architect should combine the
servers to exchange information about the client's FQDN and about forward and reverse DNS updates in a single procedure. A manual
who has the responsibility for updating the DNS with the on-demand updating model does not scale, and increases the chance
associated AAAA and PTR (Pointer Record) RRs (Resource Records). of errors. Either a database-driven mechanism, or Secure Dynamic
For example, if a client wants the server to update the FQDN- DNS Update [RFC3007], or both, could be used.
address mapping in the DNS server, it can include the Client FQDN
option with proper settings in the SOLICIT with Rapid Commit,
REQUEST, RENEW, and REBIND message originated by the client. When
DHCPv6 server gets this option, it can use the dynamic DNS update
on behalf of the client. In this document, we promote to support
this FQDN option. But since it's a DHCPv6 option, it implies that
only the DHCP-managed networks are suitable for this operation. In
SLAAC mode, sometimes hosts also need to register addresses on a
registration server, which could in fact be a DHCPv6 server (as
described in [I-D.ietf-dhc-addr-registration]); then the server
would update corresponding DNS records.
- Security Dynamic DNS update can be provided by the DHCPv6 client or by the
server on behalf of individual hosts. [RFC4704] defined a DHCPv6
option to be used by DHCPv6 clients and servers to exchange
information about the client's FQDN and about who has the
responsibility for updating the DNS with the associated AAAA and
PTR (Pointer Record) RRs (Resource Records). For example, if a
client wants the server to update the FQDN-address mapping in the
DNS server, it can include the Client FQDN option with proper
settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and
REBIND message originated by the client. When DHCPv6 server gets
this option, it can use Secure Dynamic DNS update on behalf of the
client. This document suggests use of this FQDN option. However,
since it is a DHCPv6 option, only the DHCP-managed hosts can make
use of it. In SLAAC mode, hosts need either to use Secure Dynamic
DNS Update directly, or to register addresses on a registration
server. This could in fact be a DHCPv6 server (as described in
Any automatic renumbering scheme has a potential exposure to [I-D.ietf-dhc-addr-registration]); then the server would update
hijacking. Malicious entity in the network can forge prefixes to corresponding DNS records.
renumber the hosts. So proper network security mechanisms are
needed.
For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible - Security
solution, but it is complex and there's almost no real deployment
so far. Comparing the non-trivial deployment of SEND, RA guard
[RFC6105] is a light-weight alternative, which focuses on rogue
router advertisements proof in a L2 network. However, it also
hasn't been widely deployed since it hasn't been published for
long.
For DHCPv6, there are built-in secure mechanisms (like Secure Any automatic renumbering scheme has a potential exposure to
DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 hijacking. A malicious entity in the network could forge prefixes
messages [RFC3315] could be utilized. But these security to renumber the hosts, so proper network security mechanisms are
mechanisms also haven't been verified by wide real deployment. needed. Further details are in the Security Considerations below.
- Miscellaneous - Miscellaneous
A site or network should also avoid embedding addresses from other A site or network should also avoid embedding addresses from other
sites or networks in its own configuration data. Instead, the sites or networks in its own configuration data. Instead, the
Fully-Qualified Domain Names should be used. Thus, these Fully-Qualified Domain Names should be used. Thus, connections can
connections can survive after renumbering events at other sites. be restored after renumbering events at other sites. This also
This also applies to host-based connectivity. applies to host-based connectivity.
4.2. Considerations and Best Current Practices for the Preparation of 4.2. Considerations and Current Methods for the Preparation of
Renumbering Renumbering
In ND, it is not possible to reduce a prefix's lifetime to below two In ND, it is not possible to reduce a prefix's lifetime to below two
hours. So, renumbering should not be an unplanned sudden event. This hours. So, renumbering should not be an unplanned sudden event. This
issue could only be avoided by early planning and preparation. issue could only be avoided by early planning and preparation.
This section describes several recommendations for the preparation of This section describes several recommendations for the preparation of
enterprise renumbering event. By adopting these recommendations, a enterprise renumbering event. By adopting these recommendations, a
site could be renumbered more easily. However, these recommendations site could be renumbered more easily. However, these recommendations
might increase the daily traffic, server load, or burden of network might increase the daily traffic, server load, or burden of network
operation. Therefore, only those networks that are expected to be operation. Therefore, only those networks that are expected to be
renumbered soon or very frequently should adopt these recommendations, renumbered soon or very frequently should adopt these
with balanced consideration between daily cost and renumbering cost. recommendations, with balanced consideration between daily cost and
renumbering cost.
- Reduce the address preferred time or valid time or both. - Reduce the address preferred time or valid time or both.
Long-lifetime addresses might cause issues for renumbering events. Long-lifetime addresses might cause issues for renumbering events.
Particularly, some offline hosts might reconnect using these Particularly, some offline hosts might reconnect using these
addresses after renumbering events. Shorter preferred lifetimes addresses after renumbering events. Shorter preferred lifetimes
with relatively long valid lifetimes may allow short transition with relatively long valid lifetimes may allow short transition
periods for renumbering events and avoid frequent address renewals. periods for renumbering events and avoid frequent address
renewals.
- Reduce the DNS record TTL on the local DNS server. - Reduce the DNS record TTL on the local DNS server.
The DNS AAAA resource record TTL on the local DNS server should be The DNS AAAA resource record TTL on the local DNS server should be
manipulated to ensure that stale addresses are not cached. manipulated to ensure that stale addresses are not cached.
Recent research [BA2011] [JSBM2002] indicates that it is both Recent research [BA2011] [JSBM2002] indicates that it is both
practical and reasonable for A, AAAA, and PTR records that belong practical and reasonable for A, AAAA, and PTR records that belong
to leaf nodes of the DNS (i.e. not including the DNS root or DNS to leaf nodes of the DNS (i.e. not including the DNS root or DNS
top-level domains) to be configured with very short DNS TTL values, top-level domains) to be configured with very short DNS TTL
not only during renumbering events, but also for longer-term values, not only during renumbering events, but also for longer-
operation. term operation.
- Reduce the DNS configuration lifetime on the hosts. - Reduce the DNS configuration lifetime on the hosts.
Since the DNS server could be renumbered as well, the DNS Since the DNS server could be renumbered as well, the DNS
configuration lifetime on the hosts should also be reduced if configuration lifetime on the hosts should also be reduced if
renumbering events are expected. In ND, The DNS configuration can renumbering events are expected. In ND, the DNS configuration can
be done through reducing the lifetime value in RDNSS option be done through reducing the lifetime value in RDNSS option
[RFC6106]. In DHCPv6, the DNS configuration option specified in [RFC6106]. In DHCPv6, the DNS configuration option specified in
[RFC3646] doesn't provide lifetime attribute, but we can reduce [RFC3646] doesn't provide a lifetime attribute, but we can reduce
the DHCPv6 client lease time to achieve similar effect. the DHCPv6 client lease time to achieve similar effect.
- Identify long-living sessions - Identify long-living sessions
Any applications which maintain very long transport connections Any applications which maintain very long transport connections
(hours or days) should be identified in advance, if possible. Such (hours or days) should be identified in advance, if possible. Such
applications will need special handling during renumbering, so it applications will need special handling during renumbering, so it
is important to know that they exist. is important to know that they exist.
4.3. Considerations and Best Current Practices during Renumbering 4.3. Considerations and Current Methods during Renumbering Operation
Operation
Renumbering events are not instantaneous events. Normally, there is a Renumbering events are not instantaneous events. Normally, there is a
transition period, in which both the old prefix and the new prefix transition period, in which both the old prefix and the new prefix
are used in the site. Better network design and management, better are used in the site. Better network design and management, better
pre-preparation and longer transition period are helpful to reduce pre-preparation and longer transition period are helpful to reduce
the issues during renumbering operation. the issues during renumbering operation.
- Within/without a flag day - Within/without a flag day
As is described in [RFC4192], "a 'flag day' is a procedure in As is described in [RFC4192], "a 'flag day' is a procedure in
skipping to change at page 12, line 42 skipping to change at page 13, line 4
TTLs of DNS records are shorter than the transition period, an TTLs of DNS records are shorter than the transition period, an
administrative operation might not be necessary. administrative operation might not be necessary.
DNS configuration on hosts should be updated if local recursive DNS configuration on hosts should be updated if local recursive
DNS servers are renumbered. During the transition period, both old DNS servers are renumbered. During the transition period, both old
and new DNS server addresses might co-exist on the hosts. If the and new DNS server addresses might co-exist on the hosts. If the
lifetime of DNS configuration is shorter than the transition lifetime of DNS configuration is shorter than the transition
period, name resolving failure may be reduced to minimum. period, name resolving failure may be reduced to minimum.
- Tunnel concentrator renumbering - Tunnel concentrator renumbering
A tunnel concentrator itself might be renumbered. This change A tunnel concentrator itself might be renumbered. This change
should be reconfigured in relevant hosts or routers, unless the should be reconfigured in relevant hosts or routers, unless the
configuration of tunnel concentrator was based on FQDN. configuration of tunnel concentrator was based on FQDN.
For IPSec, [RFC2230] defines the KX (Key eXchange) record, which For IPSec, IKEv2 [RFC5996] defines the ID_FQDN Identification
could be used to help locate the domain-name for an IPsec VPN Type, which could be used to identify an IPsec VPN concentrator
concentrator associated with a site's domain name. For current associated with a site's domain name. For current practice, the
practice, the community needs to change its bad habit of using community needs to change its bad habit of using IPsec in an
IPsec in an address-oriented way, and renumbering is one of the address-oriented way, and renumbering is one of the main reasons
main reasons for that. for that.
- Connectivity session survivability - Connectivity session survivability
During the renumbering operations, connectivity sessions in IP During the renumbering operations, connectivity sessions in IP
layer would break if the old address is deprecated before the layer would break if the old address is deprecated before the
session ends. However, the upper layer sessions can survive by session ends. However, the upper layer sessions can survive by
using session survivability technologies, such as SHIM6 [RFC5533]. using session survivability technologies, such as SHIM6 [RFC5533].
As mentioned above, some long-living applications may need to be As mentioned above, some long-living applications may need to be
handled specially. handled specially.
5. Security Considerations - Verification of success
As noted, a site that is listed by IP address in a black list can The renumbering operation should end with a thorough check that
escape that list by renumbering itself. all network elements and hosts are using only the new prefixes and
that network management and monitoring systems themselves are
still operating correctly. A database clean-up may also be needed.
5. Security Considerations
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Proper network security mechanisms are needed. Although hijacking by an insider attack. For attacks on ND, Secure Neighbor
there are some existing security mechanisms such as SEND, RA guard, Discovery (SEND) [RFC3971] is a possible solution, but it is complex
secure DHCPv6 etc., they haven't been widely deployed and haven't and there is almost no real deployment at the time of writing.
been verified whether they are not bringing too much operational Compared to the non-trivial deployment of SEND, RA Guard [RFC6105] is
complexity and cost. a lightweight alternative, which focuses on preventing rogue router
advertisements in a network. However, it was also not widely deployed
at the time when this memo was published.
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages
[RFC3315] could be utilized. But these security mechanisms also have
not been verified by widespread deployment at the time of writing.
A site that is listed by IP address in a black list can escape that
list by renumbering itself. However, the new prefix might be back on
a black list rather soon, if the root cause for being added to such a
list is not corrected. In practice, the cost of renumbering will be
typically much larger than the cost of getting off the black list.
Dynamic DNS update might bring risk of DoS attack to the DNS server. Dynamic DNS update might bring risk of DoS attack to the DNS server.
So along with the update authentication, session filtering/limitation So along with the update authentication, session filtering/limitation
might also be needed. might also be needed.
The "make-before-break" approach of [RFC4192] requires the routers The "make-before-break" approach of [RFC4192] requires the routers
keep advertising the old prefixes for some time. But if the ISP keep advertising the old prefixes for some time. But if the ISP
changes the prefixes very frequently, the co-existence of old and new changes the prefixes very frequently, the co-existence of old and new
prefixes might cause potential risk to the enterprise routing prefixes might cause potential risk to the enterprise routing system,
system since the old address relevant route path might already since the old address relevant route path might already invalid and
invalid and the routing system just doesn't know it. However, the routing system just doesn't know it. However, normally enterprise
normally enterprise scenarios don't involve the extreme situation. scenarios don't involve the extreme situation.
6. IANA Considerations 6. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
7. Acknowledgements 7. Acknowledgements
This work is illuminated by RFC5887, so thank for RFC 5887 authors, This work is inspired by RFC5887, so thank for RFC 5887 authors,
Randall Atkinson and Hannu Flinck. Useful ideas were also presented Randall Atkinson and Hannu Flinck. Useful ideas were also presented
in by documents from Tim Chown and Fred Baker. The authors also want in by documents from Tim Chown and Fred Baker. The authors also want
to thank Wesley George, Olivier Bonaventure and other 6renum members to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald
for valuable comments. Bonica, other 6renum members, and several reviewers for valuable
comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service
Location Protocol, Version 2", RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
skipping to change at page 14, line 30 skipping to change at page 15, line 12
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3646] R. Droms, "DNS Configuration options for Dynamic Host [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005
[RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios",
RFC 4057, June 2005.
[RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4706, October 2006. RFC 4706, October 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
skipping to change at page 15, line 7 skipping to change at page 15, line 39
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010. September 2010.
[RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli
"IPv6 Router Advertisement Option for DNS Configuration", "IPv6 Router Advertisement Option for DNS Configuration",
RFC 6106, November 2011. RFC 6106, November 2011.
8.2. Informative References 8.2. Informative References
[RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997.
[RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000. 2000.
[RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain,
"Representing Internet Protocol version 6 (IPv6) Addresses
in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)", RFC 3364, August for Internet Protocol version 6 (IPv6)", RFC 3364, August
2002. 2002.
[RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 4057, [RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and V. Gill,
June 2005. "IPv4 Multihoming Practices and Limitations", RFC 4116,
July 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010. Still Needs Work", RFC 5887, May 2010.
skipping to change at page 16, line 29 skipping to change at page 17, line 6
[I-D.ietf-6renum-gap-analysis] [I-D.ietf-6renum-gap-analysis]
Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap
Analysis", working in progress, August 2012. Analysis", working in progress, August 2012.
[I-D.ietf-6renum-static-problem] [I-D.ietf-6renum-static-problem]
Carpenter, B. and S. Jiang., "Problem Statement for Carpenter, B. and S. Jiang., "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses", working in Renumbering IPv6 Hosts with Static Addresses", working in
progress, August 2012. progress, August 2012.
[I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Cheshire, S. and M. Krochmal, "DNS-Based Service
draft-cheshire-dnsext-dns-sd-11 (work in progress), Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
December 2011. progress), December 2011.
[I-D.cheshire-dnsext-multicastdns] [I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS", draft- Cheshire, S. and M. Krochmal, "Multicast DNS", draft-
cheshire-dnsext-multicastdns-15 (work in progress), cheshire-dnsext-multicastdns-15 (work in progress),
December 2011. December 2011.
[BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. [BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc.
14th IEEE Global Internet Symposium (GI2011), Shanghai, 14th IEEE Global Internet Symposium (GI2011), Shanghai,
China. 15 April 2011. China. 15 April 2011.
 End of changes. 70 change blocks. 
225 lines changed or deleted 253 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/