draft-ietf-6renum-enterprise-06.txt   rfc6879.txt 
Network Working Group S. Jiang
Internet Draft B. Liu Internet Engineering Task Force (IETF) S. Jiang
Intended status: Informational Huawei Technologies Co., Ltd Request for Comments: 6879 B. Liu
Expires: July 18, 2013 B. Carpenter Category: Informational Huawei Technologies Co., Ltd.
University of Auckland ISSN: 2070-1721 B. Carpenter
January 15, 2013 University of Auckland
February 2013
IPv6 Enterprise Network Renumbering Scenarios, IPv6 Enterprise Network Renumbering Scenarios,
Considerations and Methods Considerations, and Methods
draft-ietf-6renum-enterprise-06.txt
Status of this Memo Abstract
This Internet-Draft is submitted in full conformance with the This document analyzes events that cause renumbering and describes
provisions of BCP 78 and BCP 79. the current renumbering methods. These are described in three
categories: those applicable during network design, those applicable
during preparation for renumbering, and those applicable during the
renumbering operation.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This document is not an Internet Standards Track specification; it is
months and may be updated, replaced, or obsoleted by other documents published for informational purposes.
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 July 18, 2013. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6879.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document analyzes events that cause renumbering and describes
the current renumbering methods. These are described in three
categories: those applicable during network design, those applicable
during preparation for renumbering, and those applicable during the
renumbering operation.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ....................................................2
2. Enterprise Network Illustration for Renumbering .............. 3 2. Enterprise Network Illustration for Renumbering .................3
3. Enterprise Network Renumbering Scenario Categories ........... 5 3. Enterprise Network Renumbering Scenario Categories ..............5
3.1. Renumbering Caused by External Network Factors .......... 5 3.1. Renumbering Caused by External Network Factors .............5
3.2. Renumbering caused by Internal Network Factors .......... 6 3.2. Renumbering Caused by Internal Network Factors .............5
4. Network Renumbering Considerations and Current Methods ....... 6 4. Network Renumbering Considerations and Current Methods ..........6
4.1. Considerations and Current Methods during Network Design. 6 4.1. Considerations and Current Methods during Network Design ...6
4.2. Considerations and Current Methods for the Preparation of 4.2. Considerations and Current Methods for the
Renumbering ................................................. 10 Preparation of Renumbering ................................10
4.3. Considerations and Current Methods during Renumbering 4.3. Considerations and Current Methods during
Operation ................................................... 12 Renumbering Operation .....................................11
5. Security Considerations ..................................... 14 5. Security Considerations ........................................13
6. IANA Considerations ......................................... 14 6. Acknowledgements ...............................................14
7. Acknowledgements ............................................ 14 7. References .....................................................14
8. References .................................................. 15 7.1. Normative References ......................................14
8.1. Normative References .................................. 15 7.2. Informative References ....................................15
8.2. Informative References ................................. 16
Author's Addresses ............................................. 18
1. Introduction 1. Introduction
Site renumbering is difficult. Network managers frequently attempt Site renumbering is difficult. Network managers frequently attempt
to avoid future renumbering by numbering their network resources to avoid future renumbering by numbering their network resources from
from Provider Independent (PI) address space. However, widespread Provider-Independent (PI) address space. However, widespread use of
use of PI would aggravate BGP4 scaling problems [RFC4116] and, PI address space would aggravate BGP4 scaling problems [RFC4116] and,
depending on Regional Internet Registry (RIR) policies, PI space is depending on Regional Internet Registry (RIR) policies, PI space is
not always available for enterprises of all sizes. Therefore, it is not always available for enterprises of all sizes. Therefore, it is
desirable to develop mechanisms that simplify IPv6 renumbering for desirable to develop mechanisms that simplify IPv6 renumbering for
enterprises. enterprises.
This document is an analysis of IPv6 site renumbering for enterprise This document is an analysis of IPv6 site renumbering for enterprise
networks. It undertakes scenario descriptions, including networks. It undertakes scenario descriptions, including
documentation of current capabilities and existing practices. The documentation of current capabilities and existing practices. The
reader is assumed to be familiar with [RFC4192] and [RFC5887]. reader is assumed to be familiar with [RFC4192] and [RFC5887].
Proposals for new technology and methods are out of scope. Proposals for new technology and methods are out of scope.
Since IPv4 and IPv6 are logically separate from the perspective of Since IPv4 and IPv6 are logically separate from the perspective of
renumbering, regardless of overlapping of the IPv4/IPv6 networks or renumbering, regardless of overlapping of the IPv4/IPv6 networks or
devices, this document focuses on IPv6 only, leaving IPv4 out of devices, this document focuses on IPv6 only, leaving IPv4 out of
scope. Dual-stack network or IPv4/IPv6 transition scenarios are out scope. Dual-stack networks or IPv4/IPv6 transition scenarios are out
of scope, too. of scope as well.
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 Renumbering in home networks is out of scope, but it can also benefit
benefit from the analysis in this document. from the analysis in this document.
The concept of an enterprise network and a typical network The concept of an enterprise network and a typical network
illustration are introduced first. Then, current renumbering methods illustration are introduced first. Then, current renumbering methods
are introduced according to the following categories: those are introduced according to the following categories: those
applicable during network design, those applicable during applicable during network design, those applicable during preparation
preparation for renumbering, and those applicable during the for renumbering, and those applicable during the renumbering
renumbering operation. 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, has 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 for a Figure 1 provides a sample enterprise network architecture for a
simple case. Those entities mainly affected by renumbering are simple case. Those entities mainly affected by renumbering are
illustrated: illustrated:
* Gateway: Border router, firewall, web cache, etc. * Gateway (Border router, firewall, web cache, etc.)
* Application server (for internal or external users) * Application server (for internal or external users)
* DNS and DHCP servers * DNS and DHCP servers
* Routers * Routers
* Hosts (desktops etc.) * Hosts (desktops, etc.)
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| |
| +---+--+ +---+--+ +--+---+ | | +---+--+ +---+--+ +--+---+ |
skipping to change at page 4, line 38 skipping to change at page 4, line 27
| +--+---+ +---+--+ | | +--+---+ +---+--+ |
| |Router| |Router| | | |Router| |Router| |
| +--+---+ +---+--+ | | +--+---+ +---+--+ |
| | | | | | | |
| -+---+----+-------+---+--+- | | -+---+----+-------+---+--+- |
| | | | | | | | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ | | +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| | | |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ |
+----------------------------------------+ +----------------------------------------+
Figure 1 Enterprise network illustration
Figure 1. Enterprise Network Illustration
Address reconfiguration is fulfilled either by the Dynamic Host Address reconfiguration is fulfilled either by the Dynamic Host
configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for Configuration Protocol for IPv6 (DHCPv6) or by Neighbor Discovery
IPv6 (ND) protocols. During a renumbering event, the Domain Name (ND) for IPv6 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. It is taken for granted that devices also need to be updated. It is taken for granted that
applications will work entirely on the basis of DNS names, but any applications will work entirely on the basis of DNS names, but any
direct dependencies on IP addresses in application layer entities direct dependencies on IP addresses in application-layer entities
must also be updated. must also be updated.
The issue of static addresses is described in a dedicated draft The issue of static addresses is described in a dedicated document
[I-D.ietf-6renum-static-problem]. [RFC6866].
The emerging cloud-based enterprise network architecture might be The emerging cloud-based enterprise network architecture might be
different with Figure 1. But it is out of the scope of this document different than Figure 1. However, it is out of the scope of this
since the it is far from mature and has not been widely deployed yet. document since it is far from mature and has not been widely deployed
yet.
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. As stack in which a logical IPv6 plane is independent from IPv4. As
mentioned above, IPv4/IPv6 co-existence scenarios are out of scope. mentioned above, IPv4/IPv6 coexistence scenarios are out of scope.
This document focuses on routable unicast addresses; link-local, This document focuses on routable unicast addresses; link-local,
multicast and anycast addresses are also 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 from the prefix the enterprise stops 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 service from both ISPs during the
transition. transition.
o The renumbering event can be initiated by receiving new prefixes o The renumbering event can be initiated by receiving new prefixes
from the same uplink. This might happen if the enterprise network from the same uplink. This might happen if the enterprise network
is switched to a different location within the network topology is switched to a different location within the network topology of
of the same ISP due to various considerations, such as commercial, the same ISP due to various considerations, such as commercial,
performance or services reasons, etc. Alternatively, the ISP performance or services reasons, etc. Alternatively, the ISP
itself might be renumbered due to topology changes or migration itself might be renumbered due to topology changes or migration to
to a different or additional prefix. These ISP renumbering events a different or additional prefix. These ISP renumbering events
would initiate enterprise network renumbering events, of course. would initiate enterprise network renumbering events, of course.
o The enterprise network adds new uplink(s) for multihoming o The enterprise network adds a new uplink(s) for multihoming
purposes. This might not be a typical renumbering case because purposes. This might not be a typical renumbering case because
the original addresses will not be changed. However, initial the original addresses will not be changed. However, initial
numbering may be considered as a special renumbering event. The numbering may be considered as a special renumbering event. The
enterprise network removes uplink(s) or old prefixes. enterprise network 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 rebuilt. This
will trigger partial or total 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 Current Methods 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.
Careful planning and preparation could make the renumbering process Careful planning and preparation could make the renumbering process
smoother. smoother.
This section describes current solutions or strategies for This section describes current considerations and methods for
enterprise renumbering, chosen among existing mechanisms. There are enterprise renumbering, chosen among existing mechanisms. There are
known gaps analyzed by [I-D.ietf-6renum-gap-analysis] and known gaps analyzed by [GAP-ANALYSIS] and [RFC6866]. If these gaps
[I-D.ietf-6renum-static-problem]. If these gaps are filled in the are filled in the future, enterprise renumbering could be processed
future, enterprise renumbering can be processed more automatically, more automatically, with fewer issues.
with fewer issues.
4.1. Considerations and Current Methods 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 considerations 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 (PD)
In a large or a multi-site enterprise network, the prefix should In a large or a multisite enterprise network, the prefix should be
be carefully managed, particularly during renumbering events. carefully managed, particularly for renumbering events. Prefix
Prefix information needs to be delegated from router to router. information needs to be delegated from router to router. The DHCPv6
The DHCPv6 Prefix Delegation options [RFC3633] and [RFC6603] PD options ([RFC3633] and [RFC6603]) provide a mechanism for
provide a mechanism for automated delegation of IPv6 prefixes. automated delegation of IPv6 prefixes. Normally, DHCPv6 PD options
Normally, DHCPv6 Prefix Delegation (PD) options are used between are used between the internal enterprise routers; for example, a
the internal enterprise routers, for example, a router receives router receives a prefix(es) from its upstream router (a border
prefix(es) from its upstream router (a border gateway or edge gateway or edge router, etc.) through DHCPv6 PD options and then
router etc.) through DHCPv6 PD options and then advertises it advertises it (them) to the local hosts through Router Advertisement
(them) to the local hosts through Router Advertisement (RA) (RA) messages.
messages.
- Usage of FQDN - Usage of Fully Qualified Domain Names (FQDNs)
In general, Fully-Qualified Domain Names (FQDNs) are recommended
to be used to configure network connectivity, such as tunnels,
servers etc. The capability to use FQDNs as endpoint names has
been standardized in several RFCs, for example for IPsec
[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.
Note that using FQDN would rely on DNS systems. For a link local In general, FQDNs are recommended to be used to configure network
network that does not have a DNS system, multicast DNS connectivity, such as tunnels, servers, etc. The capability to use
[I-D.cheshire-dnsext-multicastdns] could be utilized. For some FQDNs as endpoint names has been standardized in several RFCs (e.g.,
specific circumstances, using FQDN might not be chosen if adding for IPsec [RFC5996]) although many system/network administrators do
DNS service in the node/network would cause undesired complexity not realize that it is there and it works well as a way to avoid
or issues. manual modification during renumbering.
Service discovery protocols such as Service Location Protocol Note that using FQDNs would rely on DNS systems. For a link-local
[RFC2608], multicast DNS with SRV records and DNS Service network that does not have a DNS system, multicast DNS [RFC6762]
Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce could be utilized. For some specific circumstances, using FQDNs
the number of places that IP addresses need to be configured. But might not be chosen if adding DNS service in the node/network would
it should be noted that these protocols are normally used link- cause undesired complexity or issues.
local only.
Network designers generally have little control over the design of Service discovery protocols such as the Service Location Protocol
application software. However, it is important to avoid any [RFC2608], multicast DNS with Service Records (SRVs), and DNS Service
software that has built-in dependency on IP addresses instead of Discovery [RFC6763] use names and can reduce the number of places
FQDNs [I-D.ietf-6renum-static-problem]. that IP addresses need to be configured. However, it should be noted
that these protocols are normally used link-local only.
- Usage of Parameterized Address Configuration Network designers generally have little control over the design of
application software. However, it is important to avoid any software
that has a built-in dependency on IP addresses instead of FQDNs
[RFC6866].
Besides DNS records, IP addresses might also be configured in many - Usage of Parameterized Address Configuration
other places such as ACLs, various IP filters, various kinds of
text-based configuration files, etc.
In some cases, one IP address can be defined as a value once, and Besides DNS records, IP addresses might also be configured in many
then the administrators can use either keywords or variables to other places such as ACLs, various IP filters, various kinds of text-
call the value in other places such as a sort of internal based configuration files, etc.
inheritance in CLI (command line interface) or other local
configurations. Among the real current devices, some routers
support defining multiple loopback interfaces which can be called
in other configurations. For example, when defining a tunnel, it
can call the defined loopback interface to use its address as the
local address of the tunnel.
This kind of parameterized address configuration is recommended, In some cases, one IP address can be defined as a value once, and
since it makes managing a renumbering event easier by reducing the then the administrators can use either keywords or variables to call
number of places where a device's configuration must be updated. the value in other places such as a sort of internal inheritance CLI
(command line interface) or other local configuration. Among the
real current devices, some routers support defining multiple loopback
interfaces that can be called in other configurations. For example,
when defining a tunnel, it can call the defined loopback interface to
use its address as the local address of the tunnel.
- Usage of ULA This kind of parameterized address configuration is recommended,
since it makes managing a renumbering event easier by reducing the
number of places where a device's configuration must be updated.
Unique Local Addresses (ULAs) are defined in [RFC4193] as - Usage of Unique Local Addresses (ULAs)
provider-independent prefixes. Since there is a 40 bits pseudo
random field in the ULA prefix, there is no practical risk of
collision (please refer to section 3.2.3 in [RFC4193] for more
detail). For enterprise networks, using ULA simultaneously with
Provider Aggregated (PA) addresses can provide a logically local
routing plane separated from the global routing plane. The benefit
is to ensure stable and specific local communication regardless of
any ISP uplink failure. This benefit is especially meaningful for
renumbering. It mainly includes three use cases described below.
During the transition period, it is desirable to isolate local ULAs are defined in [RFC4193] as PI prefixes. Since there is a
communication changes in the global routing plane. If we use 40-bit pseudorandom field in the ULA prefix, there is no practical
ULA for the local communication, this isolation is achieved. risk of collision (please refer to Section 3.2.3 in [RFC4193] for
more detail). For enterprise networks, using ULA simultaneously with
PA addresses can provide a local routing plane logically separated
from the global routing plane. The benefit is to ensure stable and
specific local communication regardless of any ISP uplink failure.
This benefit is especially meaningful for renumbering. It mainly
includes three use cases described below.
Enterprise administrators might want to avoid the need to o During the transition period, it is desirable to isolate local
renumber their internal-only, private nodes when they have to communication changes in the global routing plane. If we use ULA
renumber the PA addresses of the whole network because of for the local communication, this isolation is achieved.
changing ISPs, ISPs restructuring their address allocation, or
any other reasons. In these situations, ULA is an effective
tool for the internal-only nodes.
ULA can be a way of avoiding renumbering from having an impact o Enterprise administrators might want to avoid the need to renumber
on multicast. In most deployments multicast is only used their internal-only, private nodes when they have to renumber the
internally (intra-domain), and the addresses used for PA addresses of the whole network because of changing ISPs, ISPs
multicast sources and Rendezvous-Points need not be reachable restructuring their address allocation, or any other reasons. In
nor routable externally. Hence one may at least internally these situations, a ULA is an effective tool for the internal-only
make use of ULA for multicast specific infrastructure. nodes.
- Address Types o ULAs can be a way of avoiding renumbering from having an impact on
multicast. In most deployments, multicast is only used internally
(intra-domain), and the addresses used for multicast sources and
Rendezvous Points need not be reachable nor routable externally.
Hence, one may, at least internally, make use of ULAs for
multicast-specific infrastructure.
This document focuses on the dynamically-configured global unicast - Address Types
addresses in enterprise networks. They are the targets of
renumbering events.
Manually-configured addresses are not scalable in medium to large This document focuses on the dynamically configured global unicast
sites, hence should be avoided for both network elements and addresses in enterprise networks. They are the targets of
application servers [I-D.ietf-6renum-static-problem]. renumbering events.
- Address configuration models Manually configured addresses are not scalable in medium to large
sites; hence, they should be avoided for both network elements and
application servers [RFC6866].
In IPv6 networks, there are two auto-configuration models for - Address configuration models
address assignment after each host obtains a link-local address:
Stateless Address Auto-Configuration (SLAAC, [RFC4862]) by
Neighbor Discovery (ND, [RFC4861]) and stateful address
configuration by Dynamic Host Configuration Protocol for IPv6
(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].
SLAAC is considered to support easy renumbering by broadcasting a In IPv6 networks, there are two autoconfiguration models for address
Router Advertisement message with a new prefix. DHCPv6 can also assignment after each host obtains a link-local address: Stateless
trigger the renumbering process by sending unicast RECONFIGURE Address Autoconfiguration (SLAAC) [RFC4862] by ND [RFC4861] and
messages, though it might cause a large number of interactions stateful address configuration by DHCPv6 [RFC3315]. In the latest
between hosts and the DHCPv6 server. work, DHCPv6 may also support the host-generated address model by
assigning a prefix through DHCPv6 messages [PREFIX-DHCPV6].
This document has no preference between the SLAAC and DHCPv6 SLAAC is considered to support easy renumbering by broadcasting an RA
address configuration models. It is the network architects' job to message with a new prefix. DHCPv6 can also trigger the renumbering
decide which configuration model is employed. But it should be process by sending unicast RECONFIGURE messages, though it might
noticed that using DHCPv6 and SLAAC together within one network, cause a large number of interactions between hosts and the DHCPv6
especially in one subnet, might cause operational issues. For server.
example, some hosts use DHCPv6 as the default configuration model
while some use ND. Then the hosts' address configuration model
depends on the policies of operating systems and cannot be
controlled by the network. Section 5.1 of
[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 This document has no preference between the SLAAC and DHCPv6 address
parameters, there are ND and DHCPv6 co-existence scenarios. configuration models. It is the network architect's job to decide
Combinations of address configuration models might coexist within which configuration model is employed. However, it should be noticed
a single enterprise network. [I-D.ietf-savi-mix] provides that using DHCPv6 and SLAAC together within one network, especially
recommendations to avoid collisions and to review collision in one subnet, might cause operational issues. For example, some
handling in such scenarios. hosts use DHCPv6 as the default configuration model while some use
ND. Then, the host's address configuration model depends on the
policies of operating systems and cannot be controlled by the
network. Section 5.1 of [GAP-ANALYSIS] discusses more details on
this topic. So, in general, this document recommends using DHCPv6 or
SLAAC independently in different subnets.
- DNS However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 coexistence scenarios.
Combinations of address configuration models might coexist within a
single enterprise network. [SAVI] provides recommendations to avoid
collisions and to review collision handling in such scenarios.
Although the A6 DNS record model [RFC2874] was designed for easier - DNS
renumbering, it left many unsolved technical issues [RFC3364].
Therefore, it has been moved to historic status [RFC6563] and
should not be used.
Often, a small site depends on its ISP's DNS system rather than Although the A6 DNS record model [RFC2874] was designed for easier
maintaining its own. When renumbering, this requires renumbering, it left many unsolved technical issues [RFC3364].
administrative coordination between the site and its ISP. Therefore, it has been moved to Historic status [RFC6563] and should
not be used.
It is recommended that the site have an automatic and systematic Often, a small site depends on its ISP's DNS system rather than
procedure for updating/synchronizing its DNS records, including maintaining its own. When renumbering, this requires administrative
both forward and reverse mapping. In order to simplify the coordination between the site and its ISP.
operational procedure, the network architect should combine the
forward and reverse DNS updates in a single procedure. A manual
on-demand updating model does not scale, and increases the chance
of errors. Either a database-driven mechanism, or Secure Dynamic
DNS Update [RFC3007], or both, could be used.
Dynamic DNS update can be provided by the DHCPv6 client or by the It is recommended that the site have an automatic and systematic
server on behalf of individual hosts. [RFC4704] defined a DHCPv6 procedure for updating/synchronizing its DNS records, including both
option to be used by DHCPv6 clients and servers to exchange forward and reverse mapping. In order to simplify the operational
information about the client's FQDN and about who has the procedure, the network architect should combine the forward and
responsibility for updating the DNS with the associated AAAA and reverse DNS updates in a single procedure. A manual on-demand
PTR (Pointer Record) RRs (Resource Records). For example, if a updating model does not scale and increases the chance of errors.
client wants the server to update the FQDN-address mapping in the Either a database-driven mechanism, a secure dynamic DNS update
DNS server, it can include the Client FQDN option with proper [RFC3007], or both could be used.
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
[I-D.ietf-dhc-addr-registration]); then the server would update
corresponding DNS records.
- Security A dynamic DNS update can be provided by the DHCPv6 client or by the
server on behalf of individual hosts. [RFC4704] defines 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 the DHCPv6 server gets this option,
it can use a 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 a secure dynamic DNS update
directly, or to register addresses on a registration server. This
could in fact be a DHCPv6 server (as described in [ADDR-REG]); then
the server would update corresponding DNS records.
Any automatic renumbering scheme has a potential exposure to - Security
hijacking. A malicious entity in the network could forge prefixes
to renumber the hosts, so proper network security mechanisms are
needed. Further details are in the Security Considerations below.
- Miscellaneous Any automatic renumbering scheme has a potential exposure to
hijacking. A malicious entity in the network could forge prefixes to
renumber the hosts, so proper network security mechanisms are needed.
Further details are in the Security Considerations section below.
A site or network should also avoid embedding addresses from other - Miscellaneous
sites or networks in its own configuration data. Instead, the
Fully-Qualified Domain Names should be used. Thus, connections can
be restored after renumbering events at other sites. This also
applies to host-based connectivity.
4.2. Considerations and Current Methods for the Preparation of A site or network should also avoid embedding addresses from other
Renumbering sites or networks in its own configuration data. Instead, the FQDNs
should be used. Thus, connections can be restored after renumbering
events at other sites. This also applies to host-based connectivity.
4.2. Considerations and Current Methods for the Preparation of
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.
issue could only be avoided by early planning and preparation. This issue could only be avoided by early planning and preparation.
This section describes several recommendations for the preparation This section describes several recommendations for the preparation of
of enterprise renumbering event. By adopting these recommendations, an enterprise renumbering event. By adopting these recommendations,
a site could be renumbered more easily. However, these a site could be renumbered more easily. However, these
recommendations might increase the daily traffic, server load, or recommendations might increase the daily traffic, server load, or
burden of network operation. Therefore, only those networks that are burden of network operation. Therefore, only those networks that are
expected to be renumbered soon or very frequently should adopt these expected to be renumbered soon, or very frequently, should adopt
recommendations, with balanced consideration between daily cost and these recommendations, with balanced consideration between daily cost
renumbering 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 periods for renumbering events and avoid frequent address renewals.
renewals.
- Reduce the DNS record TTL on the local DNS server. - Reduce the DNS record Time to Live (TTL) on the local DNS server
The DNS AAAA resource record TTL on the local DNS server should be The DNS AAAA RR TTL on the local DNS server should be manipulated to
manipulated to ensure that stale addresses are not cached. 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 PTRs that belong to leaf
to leaf nodes of the DNS (i.e. not including the DNS root or DNS nodes of the DNS (i.e., not including the DNS root or DNS top-level
top-level domains) to be configured with very short DNS TTL domains) to be configured with very short DNS TTL values, not only
values, not only during renumbering events, but also for longer- during renumbering events but also for longer-term 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 of 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
be done through reducing the lifetime value in RDNSS option done through reducing the lifetime value in the Recursive DNS Server
[RFC6106]. In DHCPv6, the DNS configuration option specified in (RDNSS) option [RFC6106]. In DHCPv6, the DNS configuration option
[RFC3646] doesn't provide a lifetime attribute, but we can reduce specified in [RFC3646] doesn't provide a lifetime attribute, but we
the DHCPv6 client lease time to achieve similar effect. can reduce the DHCPv6 client lease time to achieve a similar effect.
- Identify long-living sessions - Identify long-living sessions
Any applications which maintain very long transport connections Any applications that maintain very long transport connections (hours
(hours or days) should be identified in advance, if possible. Such 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
is important to know that they exist. important to know that they exist.
4.3. Considerations and Current Methods during Renumbering Operation 4.3. Considerations and Current Methods during Renumbering Operation
Renumbering events are not instantaneous events. Normally, there is 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
are used in the site. Better network design and management, better used in the site. Better network design and management, better
pre-preparation and longer transition period are helpful to reduce preparation, and a longer transition period are helpful to reduce the
the issues during renumbering operation. issues during a 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 which
which the network, or a part of it, is changed during a planned the network, or a part of it, is changed during a planned outage, or
outage, or suddenly, causing an outage while the network suddenly, causing an outage while the network recovers".
recovers."
If renumbering event is processed within a flag day, the network If a renumbering event is processed within a flag day, the network
service/connectivity will be unavailable for a period until the service/connectivity will be unavailable for a period until the
renumbering event is completed. It is efficient and provides renumbering event is completed. It is efficient and provides
convenience for network operation and management. But network convenience for network operation and management. However, a network
outage is usually unacceptable for end users and enterprises. A outage is usually unacceptable for end users and enterprises. A
renumbering procedure without a flag day provides smooth address renumbering procedure without a flag day provides smooth address
switching, but much more operational complexity and difficulty is switching, but much more operational complexity and difficulty is
introduced. introduced.
- Transition period - Transition period
If renumbering transition period is longer than all address If a renumbering transition period is longer than all address
lifetimes, after which the address leases expire, each host will lifetimes, after which the address leases expire, each host will
automatically pick up its new IP address. In this case, it would automatically pick up its new IP address. In this case, it would be
be the DHCPv6 server or Router Advertisement itself that the DHCPv6 server or RA itself that automatically accomplishes client
automatically accomplishes client renumbering. renumbering.
Address deprecation should be associated with the deprecation of Address deprecation should be associated with the deprecation of
associated DNS records. The DNS records should be deprecated as associated DNS records. The DNS records should be deprecated as
early as possible, before the addresses themselves. early as possible, before the addresses themselves.
- Network initiative enforced renumbering - Network initiative enforced renumbering
If the network has to enforce renumbering before address leases If the network has to enforce renumbering before address leases
expire, the network should initiate DHCPv6 RECONFIGURE messages. expire, the network should initiate DHCPv6 RECONFIGURE messages. For
For some operating systems such as Windows 7, if the hosts receive some operating systems such as Windows 7, if the hosts receive RA
RA messages with ManagedFlag=0, they'll release the DHCPv6 messages with ManagedFlag=0, they will release the DHCPv6 addresses
addresses and do SLAAC according to the prefix information in the and utilize SLAAC according to the prefix information in the RA
RA messages, so this could be another enforcement method for some messages, so this could be another enforcement method for some
specific scenarios. specific scenarios.
- Impact to branch/main sites - Impact on main and branch sites
Renumbering in main/branch site might cause impact on branch/main
site communication. The routes, ingress filtering of site's
gateways, and DNS might need to be updated. This needs careful
planning and organizing.
- DNS record update and DNS configuration on hosts Renumbering in the main site might cause impact on branch site
communications, and vice versa. The routes, ingress filtering of the
site's gateways, and DNS might need to be updated. This needs
careful planning and organizing.
DNS records on the local DNS server should be updated if hosts are - DNS record update and DNS configuration on hosts
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
TTLs of DNS records are shorter than the transition period, an
administrative operation might not be necessary.
DNS configuration on hosts should be updated if local recursive DNS records on the local DNS server should be updated if hosts are
DNS servers are renumbered. During the transition period, both old renumbered. If the site depends on an ISP's DNS system, it should
and new DNS server addresses might co-exist on the hosts. If the report the new hosts' DNS records to its ISP. During the transition
lifetime of DNS configuration is shorter than the transition period, both old and new DNS records are valid. If the TTLs of DNS
period, name resolving failure may be reduced to minimum. records are shorter than the transition period, an administrative
operation might not be necessary.
- Tunnel concentrator renumbering DNS configuration on hosts should be updated if local recursive DNS
servers are renumbered. During the transition period, both old and
new DNS server addresses might coexist on the hosts. If the lifetime
of DNS configuration is shorter than the transition period, name
resolving failure may be reduced to a minimum.
A tunnel concentrator itself might be renumbered. This change - Tunnel concentrator renumbering
should be reconfigured in relevant hosts or routers, unless the
configuration of tunnel concentrator was based on FQDN.
For IPSec, IKEv2 [RFC5996] defines the ID_FQDN Identification A tunnel concentrator itself might be renumbered. This change should
Type, which could be used to identify an IPsec VPN concentrator be reconfigured in relevant hosts or routers, unless the
associated with a site's domain name. For current practice, the configuration of the tunnel concentrator was based on FQDN.
community needs to change its bad habit of using IPsec in an
address-oriented way, and renumbering is one of the main reasons
for that.
- Connectivity session survivability For IPsec, Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996]
defines the ID_FQDN Identification type, which could be used to
identify an IPsec VPN concentrator associated with a site's domain
name. For current practice, the community needs to change its bad
habit of using IPsec in an address-oriented way, and renumbering is
one of the main reasons for that.
During the renumbering operations, connectivity sessions in IP - Connectivity session survivability
layer would break if the old address is deprecated before the
session ends. However, the upper layer sessions can survive by
using session survivability technologies, such as SHIM6 [RFC5533].
As mentioned above, some long-living applications may need to be
handled specially.
- Verification of success During the renumbering operations, connectivity sessions in the IP
The renumbering operation should end with a thorough check that layer would break if the old address is deprecated before the session
all network elements and hosts are using only the new prefixes and ends. However, the upper-layer sessions can survive by using session
that network management and monitoring systems themselves are survivability technologies, such as Stanza Headers and Internet
still operating correctly. A database clean-up may also be needed. Metadata 6 (SHIM6) [RFC5533]. As mentioned above, some long-living
applications may need to be handled specially.
5. Security Considerations - Verification of success
The renumbering operation should end with a thorough check that 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 by an insider attack. For attacks on ND, Secure Neighbor hijacking by an insider attack. For attacks on ND, SEcure Neighbor
Discovery (SEND) [RFC3971] is a possible solution, but it is complex Discovery (SEND) [RFC3971] is a possible solution, but it is complex
and there is almost no real deployment at the time of writing. and there is almost no real deployment at the time of writing.
Compared to the non-trivial deployment of SEND, RA Guard [RFC6105] Compared to the nontrivial deployment of SEND, RA-Guard [RFC6105] is
is a lightweight alternative, which focuses on preventing rogue a lightweight alternative that focuses on preventing rogue router
router advertisements in a network. However, it was also not widely advertisements in a network. However, it is also not widely deployed
deployed at the time when this memo was published. at the time when this memo was published.
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages [SECURE-DHCPV6]), and authentication of DHCPv6 messages [RFC3315]
[RFC3315] could be utilized. But these security mechanisms also have could be utilized. However, these security mechanisms also have not
not been verified by widespread deployment at the time of writing. 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.
So along with the update authentication, session
filtering/limitation might also be needed.
The "make-before-break" approach of [RFC4192] requires the routers A site that is listed by IP address in a blacklist can escape that
keep advertising the old prefixes for some time. But if the ISP list by renumbering itself. However, the new prefix might be back on
changes the prefixes very frequently, the co-existence of old and a blacklist rather soon if the root cause for being added to such a
new prefixes might cause potential risk to the enterprise routing list is not corrected. In practice, the cost of renumbering will
system, since the old address relevant route path might already typically be much larger than the cost of getting off the blacklist.
invalid and the routing system just doesn't know it. However,
normally enterprise scenarios don't involve the extreme situation.
6. IANA Considerations A Dynamic DNS update might bring risk of a Denial-of-Service (DoS)
attack to the DNS server. So, along with the update authentication,
session filtering/limitation might also be needed.
This draft does not request any IANA action. The "make-before-break" approach of [RFC4192] requires the routers to
keep advertising the old prefixes for some time. However, if the ISP
changes the prefixes very frequently, the coexistence of old and new
prefixes might cause potential risk to the enterprise routing system,
since the old address relevant route path might already be invalid
and the routing system just doesn't know it. However, normally,
enterprise scenarios don't involve this extreme situation.
7. Acknowledgements 6. Acknowledgements
This work is inspired by RFC5887, so thank for RFC 5887 authors, This work is inspired by RFC 5887; thank you to the authors (Randall
Randall Atkinson and Hannu Flinck. Useful ideas were also presented Atkinson and Hannu Flinck). Useful ideas were also presented in
in by documents from Tim Chown and Fred Baker. The authors also want documents by Tim Chown and Fred Baker. The authors also want to
to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald Bonica,
Bonica, other 6renum members, and several reviewers for valuable other 6renum members, and several reviewers for their valuable
comments. comments.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June "Service Location Protocol, Version 2", RFC 2608, June
1999. 1999.
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
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] Droms, R., Ed., "DNS Configuration options for Dynamic
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host 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", [RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC
RFC 4057, June 2005. 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] Volz, B., "The Dynamic Host Configuration Protocol for
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
RFC 4706, October 2006. Option", RFC 4704, 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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration", "IPv6 Router Advertisement Options for DNS
RFC 6106, November 2011. Configuration", RFC 6106, November 2010.
8.2. Informative References 7.2. Informative References
[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.
[RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
for Internet Protocol version 6 (IPv6)", RFC 3364, August Support for Internet Protocol version 6 (IPv6)", RFC
2002. 3364, August 2002.
[RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and V. Gill, [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
"IPv4 Multihoming Practices and Limitations", RFC 4116, Gill, "IPv4 Multihoming Practices and Limitations", RFC
July 2005. 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
September 2005. 4192, September 2005.
[RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "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.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to
Historic Status", RFC 6563, May 2012. Historic Status", RFC 6563, March 2012.
[RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Exclude Option for DHCPv6-based Prefix Delegation", RFC Troan, "Prefix Exclude Option for DHCPv6-based Prefix
6603, May 2012. Delegation", RFC 6603, May 2012.
[I-D.ietf-dhc-secure-dhcpv6] [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", February 2013.
working in progress, March 2012.
[I-D.ietf-dhc-host-gen-id] [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in Discovery", RFC 6763, February 2013.
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
August, 2012.
[I-D.ietf-savi-mix] [RFC6866] Carpenter, B., and S. Jiang, "Problem Statement for
Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI Renumbering IPv6 Hosts with Static Addresses in
for Mixed Address Assignment Methods Scenario", working in Enterprise Networks", RFC 6866, February 2013.
progress, April 2012.
[I-D.ietf-dhc-addr-registration] [ADDR-REG]
Jiang, S., Chen, G., "A Generic IPv6 Addresses Jiang, S., Chen, G., and S. Krishnan "A Generic IPv6
Registration Solution Using DHCPv6", working in progress, Addresses Registration Solution Using DHCPv6", Work in
May 2012. Progress, February 2013.
[I-D.ietf-6renum-gap-analysis] [BA2011] S. Bhatti, and R. Atkinson, "Reducing DNS Caching", Proc.
Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 14th IEEE Global Internet Symposium (GI2011), Shanghai,
Analysis", working in progress, August 2012. China, April 15 2011.
[I-D.ietf-6renum-static-problem] [GAP-ANALYSIS]
Carpenter, B. and S. Jiang., "Problem Statement for Liu, B., Jiang, S., Carpenter, B. Venaas, S., and W.
Renumbering IPv6 Hosts with Static Addresses", working in George, "IPv6 Site Renumbering Gap Analysis", Work in
progress, August 2012. Progress, December 2012.
[I-D.cheshire-dnsext-dns-sd] [JSBM2002] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS
Cheshire, S. and M. Krochmal, "DNS-Based Service Performance and the Effectiveness of Caching", IEEE/ACM
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in Transactions on Networking, 10(5):589-603, 2002.
progress), December 2011.
[I-D.cheshire-dnsext-multicastdns] [PREFIX-DHCPV6]
Cheshire, S. and M. Krochmal, "Multicast DNS", draft- Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment
cheshire-dnsext-multicastdns-15 (work in progress), in DHCPv6", Work in Progress, February 2013.
December 2011.
[BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. [SAVI] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI
14th IEEE Global Internet Symposium (GI2011), Shanghai, for Mixed Address Assignment Methods Scenario", Work in
China. 15 April 2011. Progress, November 2012.
[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS [SECURE-DHCPV6]
Performance and the Effectiveness of Caching", IEEE/ACM Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", Work
Transactions on Networking, 10(5):589-603, 2002. in Progress, March 2012.
Author's Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd.
Q14, Huawei Campus Q14, Huawei Campus
No.156 Beiqing Rd. No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China P.R. China
EMail: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd.
Q14, Huawei Campus Q14, Huawei Campus
No.156 Beiqing Rd. No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China P.R. China
EMail: leo.liubing@huawei.com EMail: leo.liubing@huawei.com
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
 End of changes. 159 change blocks. 
535 lines changed or deleted 510 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/