draft-ietf-v6ops-ent-analysis-07.txt   rfc4852.txt 
IPv6 Operations WG Jim Bound Network Working Group J. Bound
Internet-Draft Yanick Pouffary Request for Comments: 4852 Y. Pouffary
Expires June 8, 2007 Hewlett-Packard Category: Informational Hewlett-Packard
Steve Klynsma S. Klynsma
MITRE MITRE
Tim Chown T. Chown
University of Southampton University of Southampton
Dave Green D. Green
Command Information Command Information
December 8, 2007
IPv6 Enterprise Network Analysis - IP Layer 3 Focus IPv6 Enterprise Network Analysis - IP Layer 3 Focus
<draft-ietf-v6ops-ent-analysis-07.txt> Status of This Memo
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document analyzes the transition to IPv6 in enterprise
networks focusing on IP Layer 3. These networks are characterized
as a network that has multiple internal links, one or more router
connections, to one or more Providers, and is managed by a network
operations entity. The analysis will focus on a base set of
transition notational networks and requirements expanded from a
previous Enterprise Scenarios document. Discussion is provided on a
focused set of transition analysis required for the enterprise to
transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6)
network and node environment, within the enterprise. Then a set of
transition mechanisms are recommended for each notational network.
Table of Contents: This document analyzes the transition to IPv6 in enterprise networks
focusing on IP Layer 3. These networks are characterized as having
multiple internal links and one or more router connections to one or
more Providers, and as being managed by a network operations entity.
The analysis focuses on a base set of transition notational networks
and requirements expanded from a previous document on enterprise
scenarios. Discussion is provided on a focused set of transition
analysis required for the enterprise to transition to IPv6, assuming
a Dual-IP layer (IPv4 and IPv6) network and node environment within
the enterprise. Then, a set of transition mechanisms are recommended
for each notational network.
1. Introduction................................................4 Table of Contents
2. Terminology.................................................7
3. Enterprise Matrix Analysis for Transition...................8 1. Introduction ....................................................3
4. Wide-Scale Dual-Stack Deployment Analysis..................12 2. Terminology .....................................................5
4.1 Staged Dual-Stack Deployment...............................12 3. Enterprise Matrix Analysis for Transition .......................5
4.2 Routing Capability Analysis for Dual-IP Deployment.........13 4. Wide-Scale Dual-Stack Deployment Analysis ......................10
4.2.1 IPv6 Routing Capability..................................13 4.1. Staged Dual-Stack Deployment ..............................10
4.2.2 IPv6 Routing Non-Capability..............................14 4.2. Routing Capability Analysis for Dual-IP Deployment ........11
4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............14 4.2.1. IPv6 Routing Capability ............................11
4.2.2.2 Deploy a parallel IPv6 infrastructure..................14 4.2.2. IPv6 Routing Non-Capability ........................11
4.3 Remote IPv6 access to the enterprise.......................15 4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure ..12
4.4 Other considerations.......................................15 4.2.2.2. Deploy a Parallel IPv6 Infrastructure .....12
5. Sparse Dual-Stack Deployment Analysis......................16 4.3. Remote IPv6 Access to the Enterprise ......................12
5.1 Internal versus External Tunnel End Point..................16 4.4. Other Considerations ......................................13
5.2 Manual versus Autoconfigured...............................17 5. Sparse Dual-Stack Deployment Analysis ..........................13
6. IPv6 Dominant Network Deployment Analysis..................18 5.1. Internal versus External Tunnel Endpoint ..................13
7. General Issues from Analysis...............................20 5.2. Manual versus Autoconfigured ..............................14
7.1 Staged Plan for IPv6 Deployment............................20 6. IPv6-Dominant Network Deployment Analysis ......................14
7.2 Network Infrastructure Requirements........................20 7. General Issues from Analysis ...................................15
7.3 Stage 1: Initial connectivity steps........................20 7.1. Staged Plan for IPv6 Deployment ...........................15
7.3.1 Obtaining external connectivity..........................20 7.2. Network Infrastructure Requirements .......................15
7.3.2 Obtaining global IPv6 address space......................21 7.3. Stage 1: Initial Connectivity Steps .......................15
7.4 Stage 2: Deploying generic basic service components........21 7.3.1. Obtaining External Connectivity ....................16
7.4.1 Developing an IPv6 addressing plan.......................21 7.3.2. Obtaining Global IPv6 Address Space ................16
7.4.2 IPv6 DNS.................................................22 7.4. Stage 2: Deploying Generic Basic Service Components .......16
7.4.3 IPv6 Routing.............................................22 7.4.1. Developing an IPv6 Addressing Plan .................16
7.4.4 Configuration of Hosts...................................23 7.4.2. IPv6 DNS ...........................................17
7.4.5 Security.................................................23 7.4.3. IPv6 Routing .......................................17
7.5 Stage 3: Widespread Dual-Stack deployment on-site..........24 7.4.4. Configuration of Hosts .............................18
8. Applicable Transition Mechanisms...........................26 7.4.5. Security ...........................................18
8.1 Recognizing Incompatible Network touchpoints...............26 7.5. Stage 3: Widespread Dual-Stack Deployment On-Site .........19
8.2 Recognizing Application incompatibilities..................27 8. Applicable Transition Mechanisms ...............................20
8.3 Using Multiple Mechanisms to Support IPv6 Transition.......28 8.1. Recognizing Incompatible Network Touchpoints ..............20
9. Security Considerations....................................29 8.2. Recognizing Application Incompatibilities .................21
10. IANA Considerations........................................29 8.3. Using Multiple Mechanisms to Support IPv6 Transition ......22
11. References.................................................29 9. Security Considerations ........................................22
11.1 Normative References......................................29 10. References ....................................................22
11.2 Non-Normative References..................................31 10.1. Normative References .....................................22
Change Log.....................................................32 10.2. Informative References ...................................24
Acknowledgments................................................34 11. Acknowledgments ...............................................25
Author's Addresses.............................................35 Appendix A. Crisis Management Network Scenarios ...................26
Intellectual Property and Copyright Statements.................36 A.1. Introduction ..............................................26
Appendix A - Crisis Management Network Scenarios...............37 A.2. Scenarios for IPv6 Deployment in Crisis Management
Networks ..................................................26
A.3. Description of a Generic Crisis Management Network ........28
A.4. Stages of IPv6 Deployment .................................29
1. Introduction 1. Introduction
This document analyzes the transition to IPv6 in enterprise This document analyzes the transition to IPv6 in enterprise networks
networks focusing on IP Layer 3. These networks are characterized focusing on IP Layer 3. These networks are characterized as having
as a network that has multiple internal links, one or more router multiple internal links, and one or more router connections to one or
connections, to one or more Providers, and is managed by a network more Providers, and as being managed by a network operations entity.
operations entity. The analysis will focus on a base set of The analysis focuses on a base set of transition notational networks
transition notational networks and requirements expanded from a and requirements expanded from a previous document on enterprise
previous Enterprise Scenarios document. Discussion is provided on a scenarios. Discussion is provided on a focused set of transition
focused set of transition analysis required for the enterprise to analysis required for the enterprise to transition to IPv6, assuming
transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) a Dual-IP layer (IPv4 and IPv6) network and node environment within
network and node environment, within the enterprise. Then a set of the enterprise. Then, a set of transition mechanisms are recommended
transition mechanisms are recommended for each notational network. for each notational network.
The audience for this document is the enterprise network team The audience for this document is the enterprise network team
considering deployment of IPv6. The document will be useful for considering deployment of IPv6. The document will be useful for
enterprise teams that will have to determine the IPv6 transition enterprise teams that have to determine the IPv6 transition strategy
strategy for their enterprise. It is expected those teams include for their enterprise. It is expected that those teams include
members from management, network operations, and engineering. The members from management, network operations, and engineering. The
analysis and notational networks presented provide an example set analysis and notational networks presented provide an example set of
of cases the enterprise can use to build an IPv6 transition cases the enterprise can use to build an IPv6 transition strategy.
strategy.
The enterprise analysis will begin by describing a matrix as a tool The enterprise analysis begins by describing a matrix as a tool to be
to be used to portray the different IPv4 and IPv6 possibilities for used to portray the different IPv4 and IPv6 possibilities for
deployment. The document will then provide analysis to support a deployment. The document will then provide analysis to support
wide Dual-IP layer deployment strategy across the enterprise, to enterprise-wide Dual-IP layer deployment strategy, to provide the
provide the reader a view of how that can be planned and what are reader with a view of how that can be planned and what options are
the options available. The document will then discuss the available. The document then discusses the deployment of sparse IPv6
deployment of sparse IPv6 nodes within the enterprise and what nodes within the enterprise and the requirements that need to be
requirements need to be considered and implemented, when the considered and implemented when the enterprise remains with an IPv4-
enterprise will remain with IPv4-only routing infrastructure for only routing infrastructure for some time. The next discussion
some time. The next discussion focuses on the use of IPv6 when it focuses on the use of IPv6 when it is determined to be dominant
is determined to be dominant across or within parts of the across or within parts of the enterprise network.
enterprise network.
The document then begins to discuss the general issues and The document then discusses the general issues and applicability from
applicability from the previous analysis. The document concludes the previous analysis. The document concludes by providing a set of
providing a set of current transition mechanism recommendations for current transition mechanism recommendations for the notational
the notational network scenarios to support an enterprise planning network scenarios to support an enterprise that is planning to deploy
to deploy IPv6. IPv6.
This document, as stated in the introduction, focuses only on the As stated, this document focuses only on the deployment cases where a
deployment cases where a Dual-IP Layer 3 is supported across the Dual-IP Layer 3 is supported across the network and on the nodes in
network and on the nodes in the enterprise. Additional deployment the enterprise. Additional deployment transition analysis will be
transition analysis will be required from the effects of IPv6-only required from the effects of an IPv6-only node or Provider
node or Provider deployments, and beyond the scope of this deployments, and is beyond the scope of this document. In addition,
document. In addition this document does not attempt to define or this document does not attempt to define or discuss any use with
discuss any use with network address translation [NATPT] or the use network address translation [NATPT] or Provider Independent address
of Provider Independent address space. space.
The following specific topics are currently out of scope for this The following specific topics are currently out of scope for this
document: document:
- Multihoming - Multihoming
- Application transition/porting (see [APPS]). - Application transition/porting (see [APPS]).
- IPv6 VPN, firewall or intrusion detection deployment - IPv6 VPN, firewall, or intrusion detection deployment.
- IPv6 network management and QoS deployment - IPv6 network management and QoS deployment.
- Detailed IT Department requirements - Detailed IT Department requirements.
- Deployment of novel IPv6 services, e.g. Mobile IPv6 - Deployment of novel IPv6 services, e.g., Mobile IPv6.
- Requirements or Transition at the Providers network - Requirements or Transition at the Providers' network.
- Transport protocol selection for applications with IPv6 - Transport protocol selection for applications with IPv6.
- Application layer and configuration issues. - Application layer and configuration issues.
- IPv6 only future deployment scenarios. - IPv6 only future deployment scenarios.
We are focusing in this document on IP Layer 3 deployment, in the This document focuses on IP Layer 3 deployment in the same way as the
same way as the other IPv6 deployment analysis works have done other IPv6 deployment analysis works have done [UMAN] [ISPA] [3GPA].
[UMAN] [ISPA] [3GPA]. This document covers deployment of IPv6 "on This document covers deployment of IPv6 "on the wire", including
the wire", including address management and DNS services. address management and DNS services.
We are also assuming that the enterprise deployment is being We are also assuming that the enterprise deployment is being
undertaken by the network administration team, i.e. this document undertaken by the network administration team, i.e., this document
is not discussing the case of an individual user gaining IPv6 does not discuss the case of an individual user gaining IPv6
connectivity (to some external IPv6 provider) from within an connectivity (to some external IPv6 provider) from within an
enterprise network. Much of the analysis is applicable to wireless enterprise network. Much of the analysis is applicable to wireless
networks, but there are additional considerations for wireless networks, but there are additional considerations for wireless
networks not contained within this document. networks not contained within this document.
In Section 2 we introduce the terminology used in this document. In In Section 2, we introduce the terminology used in this document. In
Section 3 we introduce and define a tools matrix and define the IP Section 3, we introduce and define a tools matrix and define the IP
layer 3 connectivity requirements. In Section 4 we discuss wide Layer 3 connectivity requirements. In Section 4, we discuss wide
scale Dual-IP layer use within an enterprise. In section 5 we scale Dual-IP layer use within an enterprise. In Section 5, we
discuss sparse Dual-IP layer deployment within an enterprise. In discuss sparse Dual-IP layer deployment within an enterprise. In
section 6 we discuss IPv6-dominant network deployment within the Section 6, we discuss IPv6-dominant network deployment within the
enterprise. In section 7 we discuss general issues and enterprise. In Section 7, we discuss general issues and
applicability. In section 8 a set of transition mechanisms are applicability. In Section 8, a set of transition mechanisms that can
recommended that can support the deployment of IPv6 with an support the deployment of IPv6 with an enterprise are recommended.
enterprise.
This document then provides Appendix A for readers depicting a This document then provides Appendix A for readers depicting a Crisis
Crisis Management enterprise network to demonstrate an enterprise Management enterprise network to demonstrate an enterprise network
network example that requires all the properties as analyzed in example that requires all the properties as analyzed in Sections 3,
Sections 3, 4, 5, 6, and 7. In addition we recommend readers of 4, 5, 6, and 7. In addition, we recommend that readers of this
this document also read another use case document to support an document also read another use-case document to support an IPv6
IPv6 Transition for a Campus Network [CAMP]. Transition for a Campus Network [CAMP].
Readers should also be aware a parallel effort for an enterprise to Readers should also be aware that a parallel effort for an enterprise
transition to IPv6 is training, but out of scope for this document. to transition to IPv6 is training, but out of scope for this
document.
2. Terminology 2. Terminology
Enterprise Network - A network that has multiple internal links, Enterprise Network - A network that has multiple internal links, and
one or more router connections, to one or one or more router connections to one or more
more Providers and is actively managed by a Providers, and is actively managed by a network
network operations entity. operations entity.
Provider - An entity that provides services and Provider - An entity that provides services and
connectivity to the Internet or connectivity to the Internet or other private
other private external networks for the external networks for the enterprise network.
enterprise network.
IPv6-capable - A node or network capable of supporting both IPv6-capable - A node or network capable of supporting both
IPv6 and IPv4. IPv6 and IPv4.
IPv4-only - A node or network capable of supporting only IPv4-only - A node or network capable of supporting only
IPv4. IPv4.
IPv6-only - A node or network capable of supporting only IPv6-only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only IPv6. This does not imply an IPv6 only stack in
stack, in this document. this document.
Dual-IP - References a network or node that supports Dual-IP - A network or node that supports both IPv4 and
both IPv4 and IPv6. IPv6.
IP-capability - The ability to support IPv6 only, IPv4 only, IP-capability - The ability to support IPv6 only, IPv4 only, or
or Dual IP Layer Dual-IP Layer
IPv6-dominant - A network running IPv6 routing and control plane IPv6-dominant - A network running IPv6 routing and control plane
services that provides transport for both IPv4 and services that provides transport for both IPv4
IPv6 protocol services and IPv6 protocol services
Transition - The network strategy the enterprise uses to Transition - The network strategy the enterprise uses to
Implementation transition to IPv6. Implementation transition to IPv6.
3. Enterprise Matrix Analysis for Transition 3. Enterprise Matrix Analysis for Transition
In order to identify the best suited transition mechanisms for an In order to identify the best-suited transition mechanisms for an
enterprise, it is recommended that the enterprise have an in-depth enterprise, it is recommended that the enterprise have an in-depth
up-to-date understanding of its current IT environment. This up-to-date understanding of its current IT environment. This
understanding will help choose the best suited transition understanding will help choose the best-suited transition mechanisms.
mechanisms. It is important to note that one size does not fit all. It is important to note that one size does not fit all. Selection of
While selecting a mechanism it is suggested to select mechanisms mechanisms that reduce the impact on the existing environment is
which reduce the impact on the existing environment. When selecting suggested. When selecting a transition mechanism, one must consider
a transition mechanism one must consider the functionality the functionality required, its scalability characteristic, and the
required, its scalability characteristic, and the security security implications of each mechanism.
implications of each mechanism.
To provide context for an analysis of the transitioning enterprise To provide context for an analysis of the transitioning enterprise at
at layer 3 we have provided a matrix which describes various Layer 3, we have provided a matrix that describes various scenarios
scenarios which might be encountered during an IPv6 transition. which might be encountered during an IPv6 transition. The notional
The notional enterprise network is comprised of hosts attached to enterprise network is comprised of hosts attached to an enterprise-
an enterprise-owned intranet(s) at two different global locations owned intranet(s) at two different global locations separated by the
separated by the Internet. The enterprise owns, operates and Internet. The enterprise owns, operates, and maintains its own
maintains its own intranetworks, but relies on an external provider intranetworks, but relies on an external provider organization that
organization that offers Internet Service. Both local and offers Internet Service. Both local and destination intranetworks
destination intranetworks are operated by different organizations are operated by different organizations within the same enterprise
within the same enterprise and consequently could have different and consequently could have different IP-capability than other
IP-capability, than other intranetworks, at certain times in the intranetworks at certain times in the transition period.
transition period.
Addressing every possible combination of network IP-capability in Addressing every possible combination of network IP-capability in
this notional enterprise network is impractical, therefore trivial this notional enterprise network is impractical; therefore, trivial
(i.e. pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not notional networks (i.e., pure IPv4, pure IPv6, and ubiquitous Dual-
considered. In addition, the authors could not conceive of any IP) are not considered. In addition, the authors could not conceive
scenarios involving IPv6-only ISPs or IPv6-only nodes in the near of any scenarios involving IPv6-only ISPs or IPv6-only nodes in the
term and consequently have not addressed scenarios with IPv6-only near term and consequently have not addressed scenarios with IPv6-
ISPs or IPv6-only nodes. We assume all nodes that host IPv6 only ISPs or IPv6-only nodes. We assume all nodes that host IPv6
applications are Dual IP. The matrix does not assume or suggest applications are Dual-IP. The matrix does not assume or suggest that
that network address translation is used. The authors recommend network address translation is used. The authors recommend that
that network address translation not be used in these notional network address translation not be used in these notional cases.
cases.
Future enterprise transitions that support IPv6-only nodes and Future enterprise transitions that support IPv6-only nodes and IPv6-
IPv6-only ISPs will require separate analysis, that is beyond the only ISPs will require separate analysis, which is beyond the scope
scope of this document. of this document.
Table 1 scenarios below is a matrix of ten possible Transition Table 1 below is a matrix of ten possible Transition Implementations
Implementations that, being encountered in an enterprise, may that, being encountered in an enterprise, may require analysis and
require analysis and the selection of an IPv6 transition mechanism the selection of an IPv6 transition mechanism for that notional
for that notional network. Each possible implementation is network. Each possible implementation is represented by the rows of
represented by the rows of the matrix. The matrix describes a set the matrix. The matrix describes a set of notional networks as
of notional networks as follows: follows:
- The first column represents the protocol used by the - The first column represents the protocol used by the application
application and below, the IP-capability of the node and, below, the IP-capability of the node originating the IP
originating the IP packets. packets.
(Application/Host 1 OS). (Application/Host 1 OS)
- The second column represents the IP-capability of the - The second column represents the IP-capability of the host
host network wherein the node originated the packet. network wherein the node originated the packet.
(Host 1 Network) (Host 1 Network)
- The third column represents the IP-capability of the - The third column represents the IP-capability of the service
service provider network. provider network.
(Service Provider) (Service Provider)
- The fourth column represents the IP-capability of the - The fourth column represents the IP-capability of the
destination network wherein the originating IP packets destination network wherein the originating IP packets are
are received. received.
(Host 2 Network) (Host 2 Network)
- The fifth column represents the protocol used by the - The fifth column represents the protocol used by the application
application and, below, the IP-capability of the and, below, the IP-capability of the destination node receiving
destination node receiving the originating IP packets. the originating IP packets.
(Application/Host 2 OS). (Application/Host 2 OS)
As an example, notional network 1 is an IPv6 application residing As an example, notional network 1 is an IPv6 application residing on
on a Dual-IP layer host trying to establish a communications a Dual-IP layer host trying to establish a communications exchange
exchange with a destination IPv6 application. To complete the with a destination IPv6 application. To complete the information
information exchange the packets must first traverse the host's exchange, the packets must first traverse the host's originating IPv4
originating IPv4 network (intranet), then the service provider's, network (intranet), then the service provider's and destination
and destination hosts Dual-IP network. host's Dual-IP network.
Obviously Table 1 does not describe every possible scenario. Obviously, Table 1 does not describe every possible scenario.
Trivial notional networks (such as pure IPv4, pure IPv6, and Trivial notional networks (such as pure IPv4, pure IPv6, and
ubiquitous Dual-IP) are not addressed. However, the authors feel ubiquitous Dual-IP) are not addressed. However, the authors feel
these ten represent the vast majority of transitional situations these ten scenarios represent the vast majority of transitional
likely to be encountered in today's enterprise. Therefore, we will situations likely to be encountered in today's enterprise.
use these ten to address the analysis for enterprise deployment. Therefore, we will use these ten to address the analysis for
enterprise deployment.
Table 1 - Enterprise Scenario Deployment Matrix Table 1 - Enterprise Scenario Deployment Matrix
====================================================== ======================================================
|Application |Host 1 |Service |Host 2 |Application | |Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- | |----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS | | Host 1 OS | | | | Host 2 OS |
=====================================+================ =====================================+================
| IPv6 | |Dual IP | | IPv6 | | IPv6 | |Dual IP | | IPv6 |
A | ---- | IPv4 | or |Dual IP| ---- | A | ---- | IPv4 | or |Dual IP| ---- |
skipping to change at page 11, line 4 skipping to change at page 9, line 4
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ======================================================
| IPv4 | | | | IPv6 | | IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- | I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv4 | | IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- | J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ======================================================
The reader should note that scenarios A-C in Table 1 are variations The reader should note that Scenarios A-C in Table 1 are variations
of compatible hosts communicating across largely (but not entirely) of compatible hosts communicating across largely (but not entirely)
homogenous networks. In each of the first three scenarios, the homogenous networks. In each of the first three scenarios, the
packet must traverse at least one incompatible network component. packet must traverse at least one incompatible network component.
For example, scenario B represents an enterprise which wishes to For example, Scenario B represents an enterprise that wishes to use
use IPv6 applications, but has yet to transition its internal IPv6 applications, but has yet to transition its internal networks;
networks and its Service Provider also lags, offering only a v4 its Service Provider also lags, offering only a v4 IP-service.
IP-service. Conversely, Scenario C represents an enterprise which Conversely, Scenario C represents an enterprise that has completed
has completed transition to IPv6 in its core networks (as has its transition to IPv6 in its core networks (as has its Service
Service Provider), but continues to require a legacy IPv4-based Provider), but continues to require a legacy IPv4-based application.
application.
Scenario D represents the unusual situation where the enterprise Scenario D represents the unusual situation where the enterprise has
has transitioned its core intranetworks to IPv6, but (like scenario transitioned its core intranetworks to IPv6, but (like Scenario B)
B) it's ISP provider has yet to transition. In addition, this it's ISP provider has yet to transition. In addition, this
Enterprise continues to retain critical legacy IPv4-based enterprise continues to retain critical legacy IPv4-based
applications which must communicate over this heterogeneous network applications that must communicate over this heterogeneous network
environment. environment.
Scenarios E-J represent transitional situations wherein the Scenarios E-J represent transitional situations wherein the
Enterprise has both IPv4 and IPv6 based instantiations of the same enterprise has both IPv4 and IPv6 based instantiations of the same
application that must continue to interoperate. In addition, these application that must continue to interoperate. In addition, these
scenarios show that the Enterprise has not completed transition to scenarios show that the enterprise has not completed transition to
IPv6 in all its organic and/or Service Provider networks. Instead, IPv6 in all its organic and/or Service Provider networks. Instead,
it maintains a variety of heterogeneous network segments between it maintains a variety of heterogeneous network segments between the
the communicating applications. Scenarios E and J represent communicating applications. Scenarios E and J represent distinctly
distinctly different extremes on either end of the spectrum. In different extremes on either end of the spectrum. In Scenario E, the
scenario E, the enterprise has largely transitioned to IPv6 in both enterprise has largely transitioned to IPv6 in both its applications
its applications and networks. However, scenario E shows that a few and networks. However, Scenario E shows that a few legacy IPv4-based
legacy IPv4-based applications may still be found in the applications may still be found in the enterprise. On the other
enterprise. On the other hand, scenario J shows an Enterprise that hand, Scenario J shows an enterprise that has begun its transition in
has begun its transition in a very disjointed manner and, in which a very disjointed manner and, in which IPv6-based applications and
IPv6-based applications and network segments are relatively rare. network segments are relatively rare.
4. Wide-Scale Dual-Stack Deployment Analysis 4. Wide-Scale Dual-Stack Deployment Analysis
In this section we address Scenario 1 as described in Section 3.1 In this section, we address Scenario 1 as described in Section 3.1 of
of [BSCN]. The scenario, assumptions and requirements are driven [BSCN]. The scenario, assumptions, and requirements are driven from
from the [BSCN] text. This analysis further corresponds to the [BSCN] text. This analysis further corresponds to Scenario A in
Scenario A in Section 3 above (although Scenario A shows a Section 3 above (although Scenario A shows a transitional situation
transitional situation wherein the enterprise has one network wherein the enterprise has one network segment still lagging on
segment still lagging on transition to Dual-IP). transition to Dual-IP).
Within these IPv6 deployment scenarios the enterprise network Within these IPv6 deployment scenarios the enterprise network
administrator would introduce IPv6 by enabling IPv6 on the wire administrator would introduce IPv6 by enabling IPv6 on the wire
(i.e. within the network infrastructure) in a structured fashion (i.e., within the network infrastructure) in a structured fashion
with the existing IPv4 infrastructure. In such scenarios, a number with the existing IPv4 infrastructure. In such scenarios, a number
of the existing IPv4 routers (and thus subnets) will be made dual- of the existing IPv4 routers (and thus subnets) will be made Dual-IP,
IP, such that communications can run over either protocol. such that communications can run over either protocol.
Nodes on the dual-IP links may themselves be IPv4-only or IPv6- Nodes on the Dual-IP links may themselves be IPv4-only or IPv6-
capable. The driver for deploying IPv6 on the wire may not be for capable. The driver for deploying IPv6 on the wire may not be for
immediate wide-scale usage of IPv6, but rather to prepare an immediate wide-scale usage of IPv6, but rather to prepare an existing
existing IPv4 infrastructure to support IPv6-capable nodes. Thus, IPv4 infrastructure to support IPv6-capable nodes. Thus, while IPv6
while IPv6 is not used, dual-IP nodes exist, and the enterprise can is not used, Dual-IP nodes exist, and the enterprise can be
be transitioned to IPv6 on demand. transitioned to IPv6 on demand.
Analyzing this scenario against existing transition mechanisms for Analyzing this scenario against existing transition mechanisms for
their applicability, suggests a staged approach for IPv6 deployment their applicability suggests a staged approach for IPv6 deployment in
in the enterprise. the enterprise.
4.1 Staged Dual-Stack Deployment 4.1. Staged Dual-Stack Deployment
Under these scenarios (as well as most others), the site Under these scenarios (as well as most others), the site
administrator should formulate a staged plan for the introduction administrator should formulate a staged plan for the introduction of
of a dual-IP IPv6 network. We suggest that the generic plan of a Dual-IP IPv6 network. We suggest that Section 7 of this document
Section 7 of this document provides a good basis for such a plan. provides a good basis for such a plan.
In an enterprise network, the administrator will generally seek to In an enterprise network, the administrator will generally seek to
deploy IPv6 in a structured, controlled manner, such that IPv6 can deploy IPv6 in a structured, controlled manner, such that IPv6 can be
be enabled on specific links at various stages of deployment. There enabled on specific links at various stages of deployment. There may
may be a requirement that some links remain IPv4 only, or some that be a requirement that some links remain IPv4 only, or some that
specifically should not have IPv6 connectivity (e.g. Scenario A of specifically should not have IPv6 connectivity (e.g., Scenario A of
Table 1). There may also be a requirement that aggregatable global Table 1). There may also be a requirement that aggregatable global
IPv6 addresses, assigned by the enterprise's upstream provider from IPv6 addresses, assigned by the enterprise's upstream provider from
the address space allocated to them by the Regional Internet the address space allocated to them by the Regional Internet
Registries (RIRs), be assigned. Registries (RIRs), be assigned.
In this document we do not discuss the deployment of Unique Local In this document, we do not discuss the deployment of Unique Local
IPv6 Unicast Addresses [ULA] because the address type and scope IPv6 Unicast Addresses [ULA] because the address type and scope
selected is orthogonal to the layer 3 analysis of this document. selected is orthogonal to the Layer 3 analysis of this document.
A typical deployment would initially involve the establishment of a A typical deployment would initially involve the establishment of a
single "testbed" Dual-IP subnet at the enterprise site prior to single "testbed" Dual-IP subnet at the enterprise site prior to wider
wider deployment. Such a testbed not only allows the IPv6 deployment. Such a testbed not only allows the IPv6 capability of
capability of specific platforms and applications to be evaluated specific platforms and applications to be evaluated and verified, but
and verified, but also permits the steps in Sections 7.3 and 7.4 of also permits the steps in Sections 7.3 and 7.4 of this document to be
this document to be undertaken without (potential) adverse impact undertaken without (potential) adverse impact on the production
on the production elements of the enterprise. elements of the enterprise.
Section 7.5 describes the stages for the widespread deployment in Section 7.5 describes the stages for the widespread deployment in the
the enterprise, which could be undertaken after the basic building enterprise, which could be undertaken after the basic building blocks
blocks for IPv6 deployment are in place. for IPv6 deployment are in place.
4.2 Routing Capability Analysis for Dual-IP Deployment 4.2. Routing Capability Analysis for Dual-IP Deployment
A critical part of Dual-IP deployment is the selection of the A critical part of Dual-IP deployment is the selection of the IPv6-
IPv6-capable routing infrastructure to be implemented. The path capable routing infrastructure to be implemented. The path taken
taken will depend on whether the enterprise has existing Layer 2/3 will depend on whether the enterprise has existing Layer 2/3
switch/router equipment that has an IPv6 (routing) capability, or switch/router equipment that has an IPv6 (routing) capability, or
that can be upgraded to have such capability. that can be upgraded to have such capability.
In Section 4, we are not considering sparse IPv6 deployment; the In Section 4, we are not considering sparse IPv6 deployment; the goal
goal of Dual-IP deployment is widespread use in the enterprise. of Dual-IP deployment is widespread use in the enterprise.
4.2.1 IPv6 Routing Capability 4.2.1. IPv6 Routing Capability
Where IPv6 routing capability exists within the infrastructure, the Where IPv6 routing capability exists within the infrastructure, the
network administrator can enable IPv6 on the same physical hardware network administrator can enable IPv6 on the same physical hardware
as the existing IPv4 service. This is the end goal of any as the existing IPv4 service. Enabling both is the end-goal of any
enterprise to support Dual-IP deployment, when the capability, enterprise to support Dual-IP deployment, when the capability,
performance, and robustness of the Dual-IP operational deployment performance, and robustness of the Dual-IP operational deployment has
has been verified. been verified.
Ideally, the IPv6 capability will span the entire enterprise, Ideally, the IPv6 capability will span the entire enterprise,
allowing deployment on any link or subnet. If not, techniques from allowing deployment on any link or subnet. If not, techniques from
Section 4.4 below may be required. Section 4.4 may be required.
4.2.2 IPv6 Routing Non-Capability 4.2.2. IPv6 Routing Non-Capability
If the enterprise cannot provide IPv6 routing initially there are If the enterprise cannot provide IPv6 routing initially, there are
alternative methods for transition. In this case the enterprise alternative methods for transition. In this case, the enterprise
administrator faces two basic choices, either to tunnel IPv6 over administrator faces two basic choices, either to tunnel IPv6 over
some or all of the existing IPv4 infrastructure, or to deploy a some or all of the existing IPv4 infrastructure, or to deploy a
parallel IPv6 routing infrastructure providing IPv6 connectivity parallel IPv6 routing infrastructure providing IPv6 connectivity into
into existing IPv4 subnets. existing IPv4 subnets.
It may thus be the case that a nodes IPv4 and IPv6 default routes It may thus be the case that a node's IPv4 and IPv6 default routes to
to reach other links (subnets) are through different routing reach other links (subnets) are through different routing platforms.
platforms.
4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure 4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure
Consider the situation where there exists IPv6 edge routers which Consider the situation where there exists IPv6 edge routers that are
are IPv6-capable, while others,and perhaps the enterprise backbone IPv6-capable, while others, and perhaps the enterprise backbone
itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, as
as described in [BCNF] would be established between the Dual-IP described in [BCNF], would be established between the Dual-IP capable
capable routers on the enterprise, thus "bypassing" existing non routers on the enterprise, thus "bypassing" existing non IPv6-capable
IPv6-capable routers and platforms. routers and platforms.
In the widespread dual-IP scenario, a more structured, manageable In the widespread Dual-IP scenario, a more structured, manageable
method is required, where the administrator has control of the method is required, where the administrator has control of the
deployment per-link and (ideally) long-term, aggregatable global deployment per-link and (ideally) long-term, aggregatable global IPv6
IPv6 addressing is obtained, planned and used from the outset. addressing is obtained, planned, and used from the outset.
4.2.2.2 Deploy a parallel IPv6 infrastructure 4.2.2.2. Deploy a Parallel IPv6 Infrastructure
Alternatively,the administrator may deploy a new, separate IPv6- Alternatively,the administrator may deploy a new, separate IPv6-
capable router (or set of routers). It is quite possible that such capable router (or set of routers). It is quite possible that such a
a parallel infrastructure would be IPv6-dominant. parallel infrastructure would be IPv6-dominant.
Such an approach would likely require additional hardware, but it Such an approach would likely require additional hardware, but it has
has the advantage that the existing IPv4 routing platforms are not the advantage that the existing IPv4 routing platforms are not
disturbed by the introduction of IPv6. disturbed by the introduction of IPv6.
To distribute IPv6 to existing IPv4 enterprise subnets, either To distribute IPv6 to existing IPv4 enterprise subnets, either
dedicated physical infrastructure can be employed or, if available, dedicated physical infrastructure can be employed or, if available,
IEEE 802.1q VLANs could be used, as described in [VLAN]. The IEEE 802.1q VLANs could be used, as described in [VLAN]. The latter
latter has the significant advantage of not requiring any has the significant advantage of not requiring any additional
additional physical cabling/wiring and also offers all the physical cabling/wiring and also offers all the advantages of VLANs
advantages of VLANs for the new dual-IP environment. Many router for the new Dual-IP environment. Many router platforms can tag
platforms can tag multiple VLAN IDs on a single physical interface multiple VLAN IDs on a single physical interface based on the
based on the subnet/link the packet is destined for; thus multiple subnet/link the packet is destined for; thus, multiple IPv6 links can
IPv6 links can be collapsed for delivery on a single (or small be collapsed for delivery on a single (or small number of) physical
number of) physical IPv6 router interfaces in the early stages of IPv6 router interface(s) in the early stages of deployment.
deployment.
The parallel infrastructure should only be seen as an interim step The parallel infrastructure should only be seen as an interim step
towards full Dual-IP deployment on a unified infrastructure. The towards full Dual-IP deployment on a unified infrastructure. The
parallel infrastructure however allows all other aspects of the parallel infrastructure however allows all other aspects of the IPv6
IPv6 enterprise services to be deployed, including IPv6 addressing, enterprise services to be deployed, including IPv6 addressing, thus
thus making the enterprise ready for that unifying step at a later making the enterprise ready for that unifying step at a later date.
date.
4.3 Remote IPv6 access to the enterprise 4.3. Remote IPv6 Access to the Enterprise
When the enterprise's users are off-site, and using an ISP that When the enterprise's users are off-site, and using an ISP that does
does not support any native IPv6 service or IPv6 transition aids, not support any native IPv6 service or IPv6 transition aids, the
the enterprise may consider deploying it's own remote IPv6 access enterprise may consider deploying it's own remote IPv6 access
support. Such remote support might for example be offered by support. Such remote support might for example be offered by
deployment of an IPv6 Tunnel Broker [TBRK]. deployment of an IPv6 Tunnel Broker [TBRK].
4.4 Other considerations 4.4. Other Considerations
There are some issues associated with turning IPv6 on by default, There are some issues associated with turning IPv6 on by default,
including application connection delays, poor connectivity, and including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF] worked around or mitigated by following the advice in [V6DEF].
5. Sparse Dual-Stack Deployment Analysis 5. Sparse Dual-Stack Deployment Analysis
This section covers the Scenario 2 as described in Section 3.1 of This section covers Scenario 2 as described in Section 3.1 of [BSCN].
[BSCN]. This scenario assumes the requirements defined within the This scenario assumes the requirements defined within the [BSCN]
[BSCN] text. text.
IPv6 deployment within the enterprise network, with an existing IPv6 deployment within the enterprise network, with an existing IPv4
IPv4 infrastructure, could be motivated by mission critical or infrastructure, could be motivated by mission-critical or business
business applications or services that require IPv6. In this case applications or services that require IPv6. In this case, the
the prerequisite is that only the nodes using those IPv6 prerequisite is that only the nodes using those IPv6 applications
applications need to be upgraded to be IPv6-capable. The routing need to be upgraded to be IPv6-capable. The routing infrastructure
infrastructure will not be upgraded to support IPv6, nor does the will not be upgraded to support IPv6, nor does the enterprise wish to
enterprise wish to deploy a parallel IPv6 routing infrastructure at deploy a parallel IPv6 routing infrastructure at this point, since
this point, since this is an option in section 4. this is an option in Section 4.
There is a need for end-to-end communication with IPv6, but the There is a need for end-to-end communication with IPv6, but the
infrastructure only supports IPv4 routing. Thus, the only viable infrastructure only supports IPv4 routing. Thus, the only viable
method for end-to-end communication with IPv6 is to tunnel the method for end-to-end communication with IPv6 is to tunnel the
traffic over the existing IPv4 infrastructure, within this analysis traffic over the existing IPv4 infrastructure as defined in this
documents boundaries defined. analysis document.
The network team needs to decide which are the most efficient the The network team needs to decide which of the available transition
available transition tunneling mechanisms to deploy, so they can be tunneling mechanisms are the most efficient to deploy, so they can be
used without disrupting the existing IPv4 infrastructure. Several used without disrupting the existing IPv4 infrastructure. Several
conditions require analysis, as introduced in the following sub conditions require analysis, as introduced in the following sub-
sections. sections.
5.1 Internal versus External Tunnel End Point 5.1. Internal versus External Tunnel Endpoint
Let's assume the upstream provider has deployed some IPv6 services, Let's assume the upstream provider has deployed some IPv6 services,
either native IPv6 in its backbone or in the access network, or either native IPv6 in its backbone or in the access network, or some
some combination of both (Scenario B of Table 1). In this case, the combination of both (Scenario B of Table 1). In this case, the
provider will likely also deploy one or more transition mechanisms provider will likely also deploy one or more transition mechanisms to
to support their IPv6 subscribers. Obviously, the enterprise could support their IPv6 subscribers. Obviously, the enterprise could
decide to take advantage of those transition services offered from decide to take advantage of those transition services offered from
the Provider. However, this will usually mean that individual nodes the Provider. However, this will usually mean that individual nodes
in the network will require their own IPv6-in-IPv4 tunnel. The end in the network require their own IPv6-in-IPv4 tunnel. The end result
result is somewhat inefficient IPv6 intranetworks communication, is somewhat inefficient IPv6 intranetworks communication, because all
because all IPv6 traffic must be forwarded by the Enterprise's IPv4 IPv6 traffic must be forwarded by the enterprise's IPv4
infrastructure to the Tunnel End-Point offered by the Provider. infrastructure to the Tunnel Endpoint offered by the Provider.
Nevertheless, this may be acceptable paticularly if the IPv6 Nevertheless, this may be acceptable, particularly if the IPv6
applications do not require intranetworks communication at all. For applications do not require intranetworks communication at all -- for
example when an application's server is located outside of the example, when an application's server is located outside of the
enterprise network, or on other intranetworks of the same enterprise network, or on other intranetworks of the same enterprise.
enterprise.
Alternatively, the enterprise could decide to deploy its own Alternatively, the enterprise could decide to deploy its own
transition mechanism node, possibly collocating it adjacent to the transition mechanism node, possibly collocating it adjacent to the
border router that connects to the upstream Provider. In this case, border router that connects to the upstream Provider. In this case,
intranetnetworks communication using this tunnel end point is also intranetnetworks communication using this tunnel end point is also
possible. possible.
5.2 Manual versus Autoconfigured 5.2. Manual versus Autoconfigured
If the number of nodes to be using IPv6 is low, the first option is If the number of nodes to be using IPv6 is low, the first option is
to use statically configured tunnels. However, automatically to use statically configured tunnels. However, automatically
configured tunnels may be preferable, especially if the number is configured tunnels may be preferable, especially if the number is
higher. higher.
6. IPv6 Dominant Network Deployment Analysis 6. IPv6-Dominant Network Deployment Analysis
In this section we are covering Scenario 3 as described in Section In this section we are covering Scenario 3 as described in Section
3.1 of [BSCN]. The scenario, assumptions and requirements are 3.1 of [BSCN]. The scenario, assumptions, and requirements are
driven from the [BSCN] text. Within this document, this situation driven from the [BSCN] text. Within this document, this situation is
is captured in Scenario C of Table 1. captured in Scenario C of Table 1.
Some enterprise networks may wish to employ an IPv6-dominant Some enterprise networks may wish to employ an IPv6-dominant network
network deployment strategy. What this means essentially is that deployment strategy. What this means essentially is that the network
the network or specific sites within the enterprise network will or specific sites within the enterprise network will transition to
transition to IPv6 using only IPv6 routing to transfer both IPv4 IPv6 using only IPv6 routing to transfer both IPv4 and IPv6 packets
and IPv6 packets over the network, even though the network may be over the network, even though the network may be Dual-IP capable.
Dual-IP capable. IPv4 routing would not be turned on within an IPv4 routing would not be turned on within an IPv6-dominant network,
IPv6-dominant network, except if required to support edge IPv4 except if required to support edge IPv4 networks.
networks.
Under this scenario, communications between IPv6 nodes will use Under this scenario, communications between IPv6 nodes will use IPv6.
IPv6. When IPv6-capable nodes in the IPv6-dominant network need to When IPv6-capable nodes in the IPv6-dominant network need to
communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP
implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge
router within the IPv6-dominant network will decapsulate the IPv4 router within the IPv6-dominant network will decapsulate the IPv4
packet and route to the path of the IPv4 node on the network. This packet and route to the path of the IPv4 node on the network. This
permits Dual-IP layer nodes to communicate with legacy IPv4 nodes permits Dual-IP layer nodes to communicate with legacy IPv4 nodes
within an IPv6-dominant network. within an IPv6-dominant network.
From Table 1 scenarios E and F depict additional cases where an Scenarios E and F from Table 1 depict additional cases where an
IPv6- dominant deployment strategy could be in place. In scenario IPv6-dominant deployment strategy could be in place. In Scenario E,
E the entire network could be IPv6-dominant, but the Host OS 2 the entire network could be IPv6-dominant, but the Host OS 2 system
system is running an IPv4 application. In scenario F the Host OS 1 is running an IPv4 application. In Scenario F, the Host OS 1 system
system network could be IPv6-dominant, but the rest of the networks network could be IPv6-dominant, but the rest of the networks are all
are all IPv4. IPv4.
In each case, communicating with an IPv4 end host or over an IPv4 In each case, communicating with an IPv4 end host or over an IPv4
network requires a transition point exist within the network to network requires that a transition point exist within the network to
support that operation. Furthermore, the node in the IPv6-dominant support that operation. Furthermore, the node in the IPv6-dominant
network must acquire an IPv4 address (to interoperate with the IPv4 network must acquire an IPv4 address (to interoperate with the IPv4
end host), and locate a tunnel endpoint on their network which end host), and locate a tunnel endpoint on their network which
permits the IPv4 packet to be tunneled to the next hop IPv6 router permits the IPv4 packet to be tunneled to the next-hop IPv6 router
and eventually to a destination Dual IP router. and eventually to a destination Dual-IP router.
While retaining interoperability with IPv4 is a noble goal for While retaining interoperability with IPv4 is a noble goal for
Enterprise architects, it is an unfortunate fact that maintaining enterprise architects, it is an unfortunate fact that maintaining
IPv4 services in an IPv6-dominant network slows and may even impede IPv4 services in an IPv6-dominant network slows and may even impede
your ability to reap the maximum benefits of IPv6. your ability to reap the maximum benefits of IPv6.
The decision whether or not to use an IPv6-dominant network The decision whether or not to use an IPv6-dominant network
deployment strategy is completely driven by the Enterprise's deployment strategy is completely driven by the enterprise's business
business and operational objectives and guided by the Enterprise's and operational objectives and guided by the enterprise's transition
transition plan. plan.
7. General Issues from Analysis 7. General Issues from Analysis
In this section we describe generic enterprise IPv6 deployment In this section, we describe generic enterprise IPv6 deployment
issues, applicable to the analysis sections 4-6 in this document. issues, applicable to the analysis in Sections 4-6 of this document.
7.1. Staged Plan for IPv6 Deployment
7.1 Staged Plan for IPv6 Deployment
The enterprise network administrator will need to follow a staged The enterprise network administrator will need to follow a staged
plan for IPv6 deployment. What this means is that a strategic plan for IPv6 deployment. What this means is that a strategic
identification of the enterprise network must be performed for all identification of the enterprise network must be performed for all
points and components of the transition. points and components of the transition.
7.2 Network Infrastructure Requirements 7.2. Network Infrastructure Requirements
The considerations for the enterprise components are detailed in The considerations for the enterprise components are detailed in
Section 3.2 of [BSCN]. We do not go into detail of all aspects of Section 3.2 of [BSCN]. We do not go into detail on all aspects of
such components in this document. In this document we focus on such components in this document. In this document, we focus on
Layer 3 issues. Layer 3 issues.
7.3 Stage 1: Initial connectivity steps 7.3. Stage 1: Initial Connectivity Steps
The first steps for IPv6 deployment do not involve technical The first steps for IPv6 deployment do not involve technical aspects
aspects per se; the enterprise needs to select an external IPv6 per se; the enterprise needs to select an external IPv6 provider and
provider, and obtain globally routable IPv6 address space from that obtain globally routable IPv6 address space from that provider.
provider.
7.3.1 Obtaining external connectivity 7.3.1. Obtaining External Connectivity
The enterprise service provider would typically be a The enterprise service provider would typically be a topographically
topographically close IPv6 provider that is able to provide an IPv6 close IPv6 provider that is able to provide an IPv6 upstream link.
upstream link. It would be expected that the enterprise would use It would be expected that the enterprise would use either native IPv6
either native IPv6 upstream connectivity or, in its absence, a upstream connectivity or, in its absence, a manually configured
manually configured tunnel [BCNF] to the upstream provider. tunnel [BCNF] to the upstream provider.
7.3.2 Obtaining global IPv6 address space 7.3.2. Obtaining Global IPv6 Address Space
The enterprise will obtain global IPv6 address space from its The enterprise will obtain global IPv6 address space from its
selected upstream provider, as provider assigned (PA) address selected upstream provider, as provider-assigned (PA) address space.
space.
The enterprise should receive at least a /48 allocation from its The enterprise should receive at least a /48 allocation from its
provider, as described in [ALLOC]. provider, as described in [ALLOC].
Should an enterprise change their provider, a procedure for Should an enterprise change their provider, a procedure for
enterprise renumbering between providers is described in [RENUM]. enterprise renumbering between providers is described in [RENUM].
7.4 Stage 2: Deploying generic basic service components 7.4. Stage 2: Deploying Generic Basic Service Components
Most of these are discussed in Section 4 of [BSCN]. Here we comment Most of these are discussed in Section 4 of [BSCN]. Here we comment
on those aspects that we believe are in scope for this analysis on those aspects that we believe are in scope for this analysis
document. Thus we have not included network management, document. Thus, we have not included network management,
multihoming, multicast or application transition analysis here, but multihoming, multicast, or application transition analysis here;
these aspects should be addressed in Stage 2. however, these aspects should be addressed in Stage 2.
7.4.1 Developing an IPv6 addressing plan 7.4.1. Developing an IPv6 Addressing Plan
A site will need to formulate an IPv6 addressing plan, utilizing A site will need to formulate an IPv6 addressing plan, utilizing the
the globally aggregatable public IPv6 prefix allocated to it by its globally aggregatable public IPv6 prefix allocated to it by its
upstream connectivity provider. upstream connectivity provider.
In a Dual-IP deployment, the site will need to decide whether it In a Dual-IP deployment, the site will need to decide whether it
wishes to deploy IPv6 links to be congruent with existing IPv4 wishes to deploy IPv6 links to be congruent with existing IPv4
subnets. In this case, nodes will fall into the same links or subnets. In this case, nodes will fall into the same links or
subnets for both protocols. Such a scheme could be followed, with subnets for both protocols. Such a scheme could be followed, with
IPv6 prefix allocations being made such that room for topological IPv6 prefix allocations being made such that room for topological
growth is provisioned (reducing the potential requirement for growth is provisioned (reducing the potential requirement for future
future renumbering due to restructuring). renumbering due to restructuring).
A beneficial property of IPv6 is that an administrator will not A beneficial property of IPv6 is that an administrator will not need
need to invest as much effort in address conservation. With IPv4, to invest as much effort in address conservation. With IPv4, a site
a site will likely allocate IPv4 subnets to be as small as possible will likely allocate IPv4 subnets to be as small as possible for the
for the number of hosts currently in the subnet (e.g. a /26 for 50 number of hosts currently in the subnet (e.g., a /26 for 50 nodes)
nodes), because IPv4 address conservation is required. This creates because IPv4 address conservation is required. This creates problems
problems when the number of nodes on a subnet grows, larger IPv4 when the number of nodes on a subnet grows, larger IPv4 prefixes are
prefixes are then required, and potentially time-consuming and then required, and potentially time-consuming and disruptive
disruptive renumbering events will follow. renumbering events will follow.
With IPv6, a link can in effect have any number of nodes, allowing With IPv6, a link can in effect have any number of nodes, allowing
link growth without the need to adjust prefix allocations with the link growth without the need to adjust prefix allocations with the
associated renumbering requirement. The size of the initial site associated renumbering requirement. The size of the initial site
allocation (currently recommended to be a /48) also is likely to allocation (currently recommended to be a /48) also is likely to
allow room for site growth without a need to return to the allow room for site growth without a need to return to the
connectivity provider to obtain more, potentially non-sequential, connectivity provider to obtain more, potentially non-sequential,
address space (as is the case for IPv4 today, with the associated address space (as is the case for IPv4 today, with the associated
paperwork and probable delays). paperwork and probable delays).
At the time of writing, best practice in IPv6 site address planning At the time of writing, best practice in IPv6 site address planning
is restricted due to limited wide-scale deployments. Administrators is restricted due to limited wide-scale deployments. Administrators
should allocate /64 size prefixes for subnets, and do so in a way should allocate /64 size prefixes for subnets, and do so in a way
that has scope for growth within a site. The site should utilize a that has scope for growth within a site. The site should utilize a
plan that reserves space for topological growth in the site, given plan that reserves space for topological growth in the site, given
that its initial IPv6 prefix allocation (currently recommended to that its initial IPv6 prefix allocation (currently recommended to be
be a /48) is likely to include such room for growth. Also see IPv6 a /48) is likely to include such room for growth. Also see "IPv6
unicast address assignments document in process [UNAD]. Unicast Address Assignment" [UNAD].
7.4.2 IPv6 DNS 7.4.2. IPv6 DNS
The enterprise site should deploy a DNS service that is capable of The enterprise site should deploy a DNS service that is capable of
both serving IPv6 DNS records using the AAAA format [DNSV6R] and of both serving IPv6 DNS records using the AAAA format [DNSV6R] and
communicating over IPv6 transport. communicating over IPv6 transport.
Specific IPv6 DNS issues are reported in [DNSOP6]. Specific IPv6 DNS issues are reported in [DNSOP6].
7.4.3 IPv6 Routing 7.4.3. IPv6 Routing
The enterprise network will need to support methods for internal The enterprise network will need to support methods for internal and
and external routing. external routing.
For a single-homed single-site network, a static route to a single For a single-homed single-site network, a static route to a single
upstream provider may be sufficient, although the site may choose upstream provider may be sufficient, although the site may choose to
to use an exterior routing protocol, especially where it has use an exterior routing protocol, especially where it has multiple
multiple upstream providers. upstream providers.
For internal routing, an appropriate interior routing protocol may For internal routing, an appropriate interior routing protocol may be
be deployed. IPv6 routing protocols that can be used are as deployed. IPv6 routing protocols that can be used are as follows:
follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF], and RIPng [RIPng].
[RIPng].
7.4.4 Configuration of Hosts 7.4.4. Configuration of Hosts
An enterprise network will have a number of tools available for An enterprise network will have a number of tools available for the
IPv4 address and other configuration information delegation and delegation and management of IPv4 addresses and other configuration
management, including manual configuration, NIS [NIS] or DHCP information. These include manual configuration, NIS [NIS], and DHCP
[DHCPv4]. [DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] may
may be used to configure a host with a global IPv6 address, a be used to configure a host with a global IPv6 address, a default
default router, and an on-link prefix information. router, and on-link prefix information.
Where support for secure autoconfiguration is required, SEND [SEND] Where support for secure autoconfiguration is required, SEND [SEND]
can be used. Readers should see the applicability statements to can be used. Readers should see the applicability statements to
IPsec [IPSEC] within the SEND document. IPsec [IPSEC] within the SEND document.
A stateless configured node wishing to gain other configuration A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateful information (e.g., DNS, NTP servers) will likely need a Stateful
DHCPv6 [DHCPv6] service available. DHCPv6 [DHCPv6] service available.
For nodes configuring using DHCPv6, where DHCPv6 servers are For nodes configuring using DHCPv6, where DHCPv6 servers are offlink,
offlink, a DHCPv6 Relay Agent function will be required. Where a DHCPv6 Relay Agent function will be required. Where DHCPv4 and
DHCPv4 and DHCPv6 service are deployed together, dual-stack DHCPv6 service are deployed together, dual-stack considerations need
considerations need to be made, as discussed within current work on to be made, as discussed within current work on DHCP dual-stack
DHCP dual stack issues [DHDS]. issues [DHDS].
Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
there is support for DHCPv6 to assign privacy addresses to nodes in there is support for DHCPv6 to assign privacy addresses to nodes in
managed environments. managed environments.
7.4.5 Security 7.4.5. Security
When deploying IPv6 within a Dual-IP network, a site will need to When deploying IPv6 within a Dual-IP network, a site will need to
implement its site security policy for IPv6-capable nodes as it implement its site security policy for IPv6-capable nodes as it does
does for IPv4-capable nodes. For example, a border firewall for IPv4-capable nodes. For example, a border firewall should be
should be capable of filtering and controlling IPv6 traffic by capable of filtering and controlling IPv6 traffic by enforcing the
enforcing the same policy as it already does for IPv4. same policy as it already does for IPv4.
However, a site will also need to review its security policy in However, a site will also need to review its security policy in light
light of IPv6 specific functionality that will be deployed in the of IPv6-specific functionality that will be deployed in the site,
site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND), e.g., Mobile IPv6, stateless autoconfiguration (and SEND), IPv6
IPv6 Privacy Extensions, end-to-end IPsec, and, not least, the use Privacy Extensions, and end-to-end IPsec. In addition, a site will
of globally aggregatable public address space where for IPv4 need to review the use of globally aggregatable public address space
private addressing and NAT may have been used. where, for IPv4, private addressing and NAT may have been used.
An overview of how Network Architecture Protection (NAP) using IPv6 An overview of how Network Architecture Protection (NAP) using IPv6
can provide the same or more benefits without the need for NAT can can provide the same or more benefits without the need for NAT can be
be found in [NAP]. This describes how the perceived security with found in [NAP]. This describes how the perceived security with IPv4
IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6 NAT can be achieved and surpassed with IPv6, i.e., how IPv6
technology can be used to provide the market-perceived benefits of technology can be used to provide the market-perceived benefits of
IPv4 NAT. IPv4 NAT.
Where deployed, intrusion detection systems will need to be Where deployed, intrusion detection systems will need to be enhanced
enhanced to both check IPv6 transport for known application layer to check IPv6 transport both for known application layer attack
attack patterns and also to check for new potential IPv6 threats, patterns and for new potential IPv6 threats, e.g., excessive hop-by-
e.g. excessive hop-by-hop headers, or errant IPv6 header options. hop headers or errant IPv6 header options.
The deployment of specific transition mechanisms may also introduce The deployment of specific transition mechanisms may also introduce
threats, e.g. carrying IPv6 data tunnelled in IPv4. The site threats, e.g., carrying IPv6 data tunneled in IPv4. The site
security policy should embrace the transition mechanisms that are security policy should embrace the transition mechanisms that are
deployed. deployed.
An overview of IPv6 security issues can be found in [V6SEC]. This An overview of IPv6 security issues can be found in [V6SEC]. This
includes discussion of issues specific to the IPv6 protocol, to includes discussion of issues specific to the IPv6 protocol, to
transition mechanisms, and to IPv6 deployment itself. transition mechanisms, and to IPv6 deployment itself.
In addition an enterprise should review all current Host Based In addition, an enterprise should review all current host-based
security requirements for their networks and verify support for security requirements for their networks and verify support for IPv6.
IPv6.
7.5 Stage 3: Widespread Dual-Stack deployment on-site 7.5. Stage 3: Widespread Dual-Stack Deployment On-Site
With the basic building blocks of external connectivity, interior With the basic building blocks of external connectivity, interior
IPv6 routing, an IPv6 DNS service and address allocation management IPv6 routing, an IPv6 DNS service, and address allocation management
in place, the IPv6 capability can be rolled out to the wider in place, the IPv6 capability can be rolled out to the wider
enterprise. This involves putting IPv6 on the wire in the desired enterprise. This involves putting IPv6 on the wire in the desired
links, and enabling applications and other services to begin using links, and enabling applications and other services to begin using an
an IPv6 transport. IPv6 transport.
In the Dual-IP deployment case, this means enabling IPv6 on In the Dual-IP deployment case, this means enabling IPv6 on existing
existing IPv4 subnets. As described in Section 7.4.4 above, it is IPv4 subnets. As described in Section 7.4.4, above, it is likely
likely that IPv6 links will be congruent with IPv4 subnets, because that IPv6 links will be congruent with IPv4 subnets because IPv4
IPv4 subnets tend to be created for geographic, policy or subnets tend to be created for geographic, policy, or administrative
administrative reasons that would be IP version-independent. reasons that would be IP version-independent.
While the use of IPv6 by some applications can be administratively While the use of IPv6 by some applications can be administratively
controlled (e.g. in the case of open source software by compiling controlled (e.g., in the case of open source software by compiling
the application without IPv6 support enabled), the use of IPv6 the application without IPv6 support enabled), the use of IPv6
transport, and preference over IPv4 transport, will vary per transport, and preference over IPv4 transport, will vary per
application based on the developer/author's implementation. application based on the developer/author's implementation.
A Dual-IP deployment will often be made by sites wishing to support A Dual-IP deployment will often be made by sites wishing to support
use of IPv6 within a site, even if IPv6 transport is not preferred use of IPv6 within a site, even if IPv6 transport is not preferred by
by all applications. Putting support for IPv6 in all site all applications. Putting support for IPv6 in all site
infrastructure (DNS, email transport, etc) allows IPv6 usage to be infrastructure (DNS, email transport, etc.) allows IPv6 usage to be
phased in over time. As nodes become IPv6 capable, and phased in over time. As nodes become IPv6 capable, and applications
applications and services IPv6 enabled, the IPv6 capable and services IPv6 enabled, the IPv6 capable infrastructure can be
infrastructure can be leveraged. For most networks, Dual-IP will leveraged. For most networks, Dual-IP will be at the very least a
be at the very least a medium-term transition towards an IPv6- medium-term transition towards an IPv6-dominant future. However, the
dominant future. However, the introduction of IPv6 support, with introduction of IPv6 support, with the potential benefits of globally
the potential benefits of globally aggregatable public address aggregatable public address usage (with [NAP]) and other new IPv6
usage (with [NAP]), and other new IPv6 capabilities, can bring more capabilities, can bring more immediate benefits for the site.
immediate benefits for the site.
8. Applicable Transition Mechanisms 8. Applicable Transition Mechanisms
This section will provide general guidance for the use of specific This section will provide general guidance for the use of specific
transition mechanisms which in turn can be used by the enterprise transition mechanisms which in turn can be used by the enterprise to
to support the enterprise matrix notional networks (rows) in support the enterprise matrix notional networks (rows) in Section 3,
Section 3, and within the context of the analysis discussed in and within the context of the analysis discussed in Sections 4, 5,
Sections 4, 5, and 6. and 6.
Table 1 provides a number of common scenarios that an enterprise Table 1 provides a number of common scenarios that an enterprise
architect might encounter as they consider how and where they architect might encounter as they consider how and where they should
should consider deploying transition mechanisms to support the consider deploying transition mechanisms to support the network
network transition to IPv6. Selecting the most appropriate transition to IPv6. Selecting the most appropriate mechanism for
mechanism for each scenario is more of an art than a science and each scenario is more of an art than a science and consequently
consequently making recommendations against each of the ten making recommendations against each of the ten scenarios would be
scenarios would be simply fodder for sharpshooters touting their simply fodder for sharpshooters touting their favored product.
favored product. However we can provide some high-level guidance However we can provide some high-level guidance that should benefit
that should benefit the architect's decision making process. the architect's decision-making process.
8.1 Recognizing Incompatible Network touchpoints 8.1. Recognizing Incompatible Network Touchpoints
Mapping your specific situation into one of the ten scenarios of Mapping your specific situation into one of the ten scenarios of
Table 1 is far less important than recognizing the critical Table 1 is far less important than recognizing the critical
touchpoints within the enterprise networks where incompatible touchpoints within the enterprise networks where incompatible
networks interface. Unless a transition mechanism is being offered networks interface. Unless a transition mechanism is being offered
by the enterprise as a service, it is at these touchpoints that a by the enterprise as a service, it is at these touchpoints that a
mechanism must be considered. mechanism must be considered.
A quick review of Table 1 reveals that the ten scenarios can be A quick review of Table 1 reveals that the ten scenarios can be
boiled down to variations of four major themes. The simplest, but boiled down to variations of four major themes. The simplest, but
also most favored (due to its flexibility), is wide spread Dual IP also most favored (due to its flexibility), is widespread Dual-IP
with compatible hosts at either end. This situation is illustrated with compatible hosts at either end. This situation is illustrated
in Scenario A and transition mechanism considerations have already in Scenario A, and transition mechanism considerations have already
been described in some detail in Section 4. been described in some detail in Section 4.
In the second common theme (depicted in Scenarios B-D of Table 1), In the second common theme (depicted in Scenarios B-D of Table 1),
the enterprise is comprised of compatible hosts, with one or more the enterprise is comprised of compatible hosts, with one or more
incompatible network touchpoints in between. As described in incompatible network touchpoints in between. As described in Section
Section 4.2.2.1, tunneling can be used to "bypass" the incompatible 4.2.2.1, tunneling can be used to "bypass" the incompatible network
network segments. One tunneling option, Manual Configured Tunnels segments. One tunneling option, manually configured tunnels [BCNF]
[BCNF] could be used by the enterprise, but as the name implies, could be used by the enterprise, but as the name implies, this
this mechanism provides no automated tunnel configuration. mechanism provides no automated tunnel configuration.
6TO4 [6TO4] can be used to support enterprises that do not have an "Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can be used to
assigned IPv6 prefix address. support enterprises that do not have an assigned IPv6 prefix address.
Identifying the responsible device to perform the tunneling is Identifying the responsible device to perform the tunneling is driven
driven by the position of the incompatible touchpoint. If a local by the position of the incompatible touchpoint. If a local network
network is incompatible then host tunneling is appropriate. If the is incompatible, then host tunneling is appropriate. If the backbone
backbone (provider) network is incompatible then gateway-to-gateway (provider) network is incompatible, then gateway-to-gateway tunneling
tunneling might be a better choice. By working to ensure tunnel might be a better choice. By working to ensure tunnel endpoints are
endpoints are always configured at dual-IP devices, end-to-end always configured at Dual-IP devices, end-to-end communication or
communication or services (IPv4 or IPv6) can be preserved. services (IPv4 or IPv6) can be preserved.
Readers should review the current work regarding tunnels within the Readers should review the current work regarding tunnels within the
IETF Softwire working group and problem statement [SOFTW]. IETF Softwire working group and problem statement [SOFTW].
Having IPv6 applications on a Dual-IP host on a v4-only network Having IPv6 applications on a Dual-IP host on a v4-only network
requires some form of tunneling. Where configured tunnels are not requires some form of tunneling. Where configured tunnels are not
sufficient a more automatic solution may be appropriate. Available sufficient, a more automatic solution may be appropriate. Available
solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 solutions include the Intra-Site Automatic Tunnel Addressing Protocol
end service. ISATAP [ISTP] can be used to provide end node IPv6 (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service.
connectivity from nodes on an isolated IPv4 network, through the ISATAP [ISTP] can be used to provide end-node IPv6 connectivity from
use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be nodes on an isolated IPv4 network, through the use of automatic
used when the enterprise network is behind a NAT. tunneling of IPv6 in IPv4. Teredo [TRDO] can be used when the
enterprise network is behind a NAT.
Enterprise architects should consider providing a Tunnel Broker Enterprise architects should consider providing a Tunnel Broker
[TBRK] [TSPB] as a cost effective service to local users or [TBRK] [TSPB] as a cost-effective service to local users or
applications. Tunnel Brokers can be used to provide tunnel setup applications. Tunnel Brokers can be used to provide tunnel setup for
for an enterprise using manual configured tunnels and 6TO4 [6TO4]. an enterprise using manually configured tunnels and 6TO4 [6TO4].
Tunnel Brokers can automate the use of tunnels across an enterprise Tunnel Brokers can automate the use of tunnels across an enterprise
deploying IPv6. deploying IPv6.
Later in the transition process, after the enterprise has Later in the transition process, after the enterprise has
transitioned to a predominately IPv6 infrastructure, the architect transitioned to a predominately IPv6 infrastructure, the architect
will need to determine a network transition strategy to tunnel IPv4 will need to determine a network transition strategy to tunnel IPv4
within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise
Intranet. Or in the case of early deployment of IPv6-dominant Intranet. Or in the case of early deployment of IPv6-dominant
networks the architect will need to address this from the beginning networks, the architect will need to address this from the beginning
of the required transition planning. of the required transition planning.
8.2 Recognizing Application incompatibilities 8.2. Recognizing Application Incompatibilities
Having recognized incompatible network touchpoints, it is also Having recognized incompatible network touchpoints, it is also
incumbent on the architect to identify application incumbent on the architect to identify application incompatibilities.
incompatibilities. During the transition period, particularly for During the transition period, particularly for large enterprises, it
large enterprises, it is to be expected that applications hosted at is to be expected that an application hosted at one location may lead
one location may lead (or lag) the IPv6-compability of its peer (or (or lag) the IPv6-compatibility of its peer (or server) at some other
server) at some other location. location.
This leads us to the third theme represented by Scenario E and G, This leads us to the third theme (represented by Scenarios E and G):
i.e. incompatible applications communicating across a homogenous incompatible applications communicating across a homogenous network.
network. Translation is an obvious solution, but not recommended Translation is an obvious solution, but not recommended except for
except for legacy devices at the network edge which cannot or never legacy devices that are at the network edge and cannot or never will
will be upgraded to IPv6. A more scaleable solution would be to be upgraded to IPv6. A more scalable solution would be to use an
use an Application Layer Gateways (ALG) between the incompatible Application Layer Gateway (ALG) between the incompatible hosts.
hosts.
8.3 Using Multiple Mechanisms to Support IPv6 Transition 8.3. Using Multiple Mechanisms to Support IPv6 Transition
Inevitably, during the course of transitioning a large enterprise Inevitably, during the course of transitioning a large enterprise to
to IPv6, the architect will be faced with both incompatible hosts IPv6, the architect will be faced with both incompatible hosts and
and simultaneously (at different parts of the enterprise) simultaneously (at different parts of the enterprise) incompatible
incompatible networks. These highly complex situations represent networks. These highly complex situations represent the fourth
the fourth common theme in Table 1 and are specifically depicted by common theme in Table 1 (specifically depicted by Scenarios F, H, I,
Scenarios F, H, I and J. Maintaining IP interoperability in these and J). Maintaining IP interoperability in these situations requires
situations requires additional planning and may require multiple or additional planning and may require multiple or even nested use of
even nested use of diverse transition mechanisms. For example, an diverse transition mechanisms. For example, an ALG collocated with
ALG co-located with the application server may be required to the application server may be required to service both IPv4 and IPv6
service both IPv4 and IPv6 data streams that are simultaneously data streams that are simultaneously tunneled through incompatible
tunneled through incompatible network segment(s). network segment(s).
9. Security Considerations 9. Security Considerations
Security considerations for IPv6 deployment in a Dual-IP Security considerations for IPv6 deployment in a Dual-IP environment
environment are discussed above in section 7.4.5, where external are discussed above in Section 7.4.5, where external references to
references to overview documents [V6SEC] [NAP] are also included. overview documents [V6SEC] [NAP] are also included.
10. IANA Considerations
This document has no actions for IANA.
11. References
11.1 Normative References
[CONF] Thomson, S., Narten, T., "IPv6 Stateless
Autoconfiguration" RFC 2462 December 1998.
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T.,
et al. "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)" RFC 3315 July 2003.
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6
Domains via IPv4 Clouds" RFC 3056 February 2001.
[BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network
Scenarios" RFC 4057 June 2005.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP
through NATs" RFC 4380.
[ISTP] Templin, F., et al "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)".
RFC 4214 October 2005.
[V6TUN] Conta, A., Deering, S., "Generic Packet Tunneling
in IPv6" RFC 2473 December 1998.
[TBRK] Durand, A., et al "IPv6 Tunnel Broker"
RFC 3053 January 2001.
[ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6
Address Allocations to Sites"
RFC 3177 September 2001.
[NATPT] Tsirtsis, G., Srisuresh, P., "Network Address
`Translation - Protocol Translation (NAT-PT)"
RFC 2766 February 2000
[UMAN] Huitema, C.,. et al "Evaluation of IPv6
Transition Mechanisms for Unmanaged Networks".
RFC 3904 September 2004.
[ISPA] Lind, M., et al "Scenarios and Analysis for
Introducing IPv6 into ISP Networks".
RFC 4029 March 2005.
[3GPA] Wiljakka, J., "Analysis on IPv6 Transition in
3GPP Networks" RFC 4215 October 2005.
[OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for
IPv6" RFC2740 December 1999.
[BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol
Extensions for BGP-4", RFC2858 June 2000.
[ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain
Routing Protocol", RFC1142 February 1990.
[RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC2080 January 1997
[APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P.,
Castro, E., "Application Aspects of IPv6
Transition" RFC 4038 March 2005.
[RENUM] Baker, F., Lear, E., Droms, R., "Procedures for
Renumbering an IPv6 Network without a Flag Day".
RFC 4192 September 2005.
[BCNF] Nordmark, E., Gilligan, R., "Basic Transition
Mechanisms for IPv6 Hosts and Routers"
RFC 4213 October 2005
[ULA] Hinden, B., Haberman, B., "Unique Local IPv6
Addresses". RFC 4193 October 2005.
[DNSOP6] Durand, A., Ihren, J. and P. Savola,
"Operational Considerations and Issues with
IPv6 DNS". RFC 4472 April 2006.
[DNSV6R] Thomson, S., Huitema, C., et al "DNS
Extensions to Support IP Version 6".
RFC 3596 October 2003.
[NIS] Kalusivalingam. V, "Network Information
Service (NIS) Configuration Options for D
HCPv6. RFC 3898 October 2004.
[DHCPv4] Droms, R., "Dynamic Host Configuration
Protocol" RFC 2131 March 1997.
[IPSEC] Eastlake. D., "Cryptographic Algorithm
Implementation Requirements for Encapsulating
Security Payload (ESP) and Authentication
Header (AH)". RFC 4305 December 2005.
[SEND] Arkko, J. et al. "Secure Neighbor Discovery
(SEND)". RFC 3971 March 2005.
[PRIVv6] Narten, T., Draves, R., "Privacy Extensions 10. References
for Stateless Address Autoconfiguration in
IPv6. RFC 3041 January 2001.
11.2 Non-Normative References 10.1. Normative References
[TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
with the Tunnel Setup Protocol". Autoconfiguration", RFC 2462, December 1998.
Work in Progress.
[V6SEC] Davies, E. et al "IPv6 Transition/Co-existence [DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Security Considerations". Work in Progress. and M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[NAP] Van de Velde, G. et al "IPv6 Network [6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
Architecture Protection". Work in Progress. IPv4 Clouds", RFC 3056, February 2001.
[CAMP] Chown, T., "IPv6 Campus Transition Scenario [BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC
Description and Analysis". Work in Progress. 4057, June 2005.
[DHDS] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Issues", Work in Progress. Network Address Translations (NATs)", RFC 4380, February
2006.
[UNAD] Van de Velde, G., Popoviciu, C., Chown, T., [ISTP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"IPv6 Unicast Address Assignment". "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)",
Work in Progress. RFC 4214, October 2005.
[VLAN] Chown, T. "Use of VLANs for IPv4-IPv6 [V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Coexistence in Enterprise Networks". Specification", RFC 2473, December 1998.
Work in Progress.
[V6DEF] Roy, S., Durand, A., Paugh, J., "IPv6 Neighbor [TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Discovery On-Link Assumption Considered Tunnel Broker", RFC 3053, January 2001.
Harmful". Work in Progress.
[SOFTW] Dawkins, S. (Ed) "Softwire Problem Statement" [ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Work in Progress Allocations to Sites", RFC 3177, September 2001.
Change Log [NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)", RFC 2766, February 2000.
ID 06-07 [UMAN] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
- Add IP Layer 3 Focus to the title "Evaluation of IPv6 Transition Mechanisms for Unmanaged
- Remove IPsec use SEND for Autoconfiguration Networks", RFC 3904, September 2004.
- Remove all mentions of DSTM
- Add Softwire Tunnel Reference
- Add Host Based Security check to security section
ID 05 - 06 [ISPA] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
- Fix ID Nits for IESG "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", RFC 4029, March 2005.
ID 04 to 05 [3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third
- Edits: Intro, Sections 4 and 7, References Generation Partnership Project (3GPP) Networks", RFC 4215,
- Update definition IPv6-Dominant October 2005.
- Add Campus Deployment Reference
- Fix ID-Nits
July 2005 - February 2006 [OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
ID 03 to 04 2740, December 1999.
- Edits to document (minor). [BGP4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
- Removed any reference to DSTM as IETF supported mechanism. [ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
- Remove 8.4 Transition Mechanisms Recommendations. [RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
- Updated references move to RFC. [APPS] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", RFC 4038,
March 2005.
- Added Normative references. [RENUM] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
ID 02 to 03 [BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
- Fixed more IETF id-nits. [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
- Added Section 8.4 Transition Mechanism Summary [DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational
analysis. Considerations and Issues with IPv6 DNS", RFC 4472, April
2006.
ID 01 to 02 [DNSV6R] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003.
- Fixed IETF id-nits. [NIS] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
- Updated Section 3 Table 1 and added discussion of intent and [DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
scenario analysis per WG input. March 1997.
- Completed sections 6, 7, and 8. [IPSEC] Eastlake 3rd, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
- Completed required Security Section. [SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- Fixed normative vs. non-normative references. [PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
- Changed abstract and context of document to only deal with dual 10.2. Informative References
IP layer networks and nodes.
- Removed Table of Content Campus VLAN appendix place holder. [TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP", Work in Progress, August 2005.
ID 00 to 01 [V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6
Transition/Co-existence Security Considerations", Work in
Progress, October 2006.
- Changed introduction, Section 1-3 to reflect authors and IETF WG [NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E.
discussions to attempt consensus on these initial sections. Klein, "Local Network Protection for IPv6", Work in
Progress, January 2007.
- Added explanation of why Appendix A is in the document to [CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and
introduction. Analysis", Work in Progress, March 2007.
- Expanded what topics are out of scope for this document. [DHDS] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
Issues", RFC 4477, May 2006.
- Updated terminology section. [UNAD] Van de Velde, G., Popoviciu, C., and T. Chown, "IPv6 Unicast
Address Assignment", Work in Progress, March 2007.
- Updated section 3 matrix and description to simplify and focus [VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
on dual IP layer. Enterprise Networks", RFC 4554, June 2006.
- Edited base text of Sections 4-7 but all three require extensive [V6DEF] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery
additional test for descriptions. On-Link Assumption Considered Harmful", Work in Progress,
January 2006.
- Edited section 8 and removed table and will reference table in [SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in
section 3. This section still needs to be written. Progress, March 2007.
Acknowledgments 11. Acknowledgments
The Author's would like to acknowledge contributions from the The authors would like to acknowledge contributions from the
following: IETF v6ops Working Group members, Fred Baker, Pekka following: IETF v6ops Working Group members, Fred Baker, Pekka
Savola, and Jordi Palet Savola, and Jordi Palet
Author's Addresses Appendix A. Crisis Management Network Scenarios
Jim Bound
HP
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: 603.465.3130
Email: jim.bound@hp.com
Yanick Pouffary
HP Competency Center
950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX
FRANCE
Phone: + 33492956285
Email: Yanick.pouffary@hp.com
Tim Chown
School of Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
David Green
Command Information
13655 Dulles Technology Drive
Suite 500
Herndon, VA 20171
USA
Phone: 703.561.5937
Email: green@commandinformation.com
Steve Klynsma
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102-5708
USA
703-883-6469
Email: sklynsma@mitre.org
Intellectual Property and Copyright Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix A - Crisis Management Network Scenarios
Introduction: A.1. Introduction
This appendix first describes different scenarios for the This appendix first describes different scenarios for the
introduction of IPv6 into a crisis management network for emergency introduction of IPv6 into a crisis management network for emergency
services, defense, or security forces that are currently running services, defense, or security forces that are currently running IPv4
IPv4 service. Then, the scenarios for introducing IPv6 are analyzed service. Then, the scenarios for introducing IPv6 are analyzed, and
and the relevance of already defined transition mechanisms are the relevance of already defined transition mechanisms are evaluated.
evaluated. Known challenges are also identified. Known challenges are also identified.
When a crisis management enterprise deploys IPv6, its goal is to When a crisis management enterprise deploys IPv6, its goal is to
provide IPv6 connectivity on it's institutional fixed networks and provide IPv6 connectivity on its institutional fixed networks and on
on the mobile wireless services that are deployed to a crisis area. the mobile wireless services that are deployed to a crisis area. The
The new IPv6 service must be added to an already existing IPv4 new IPv6 service must be added to an already existing IPv4 service,
service, the introduction of IPv6 must not interrupt this IPv4 the introduction of IPv6 must not interrupt this IPv4 service, and
service, and the IPv6 services must be interoperable with existing the IPv6 services must be interoperable with existing IPv4 services.
IPv4 services.
Crisis management enterprises accessing IPv4 service across mobile Crisis management enterprises accessing IPv4 service across mobile
ground networks, airborne networks, and satellites will find ground networks, airborne networks, and satellites will find
different ways to add IPv6 to this service based on their network different ways to add IPv6 to this service based on their network
architecture, funding, and institutional goals. This document architecture, funding, and institutional goals. This document
discusses a small set of scenarios representing the architectures discusses a small set of scenarios representing the architectures for
for IPv6 expected to be dominant in crisis management networks IPv6 expected to be dominant in crisis management networks during the
during the next decade. It evaluates the relevance of the existing next decade. This document evaluates the relevance of the existing
transition mechanisms in the context of these deployment scenarios, transition mechanisms in the context of these deployment scenarios,
and points out the lack of essential functionality in these methods and points out the lack of essential functionality within these
to the ISP's operation of an IPv6 service. methods for a provider to support IPv6 services for these scenarios.
The document is focused on services that include both IPv6 and IPv4 The document focuses on services that include both IPv6 and IPv4 and
and does cover issues surrounding accessing IPv4 services across does cover issues surrounding accessing IPv4 services across IPv6-
IPv6-only networks. It is outside the scope of this document to only networks. It is outside the scope of this document to describe
describe detailed implementation plans for IPv6 in defense networks detailed implementation plans for IPv6 in defense networks.
Scenarios for IPv6 Deployment in Crisis Management Networks: A.2. Scenarios for IPv6 Deployment in Crisis Management Networks
Scenario 1: Limited IPv6 Deployment Network..................... Scenario 1: Limited IPv6 Deployment Network
Sparse IPv6 dual-stack deployment in an existing IPv4 network Sparse IPv6 dual-stack deployment in an existing IPv4 network
infrastructure. Enterprise with an existing IPv4 network wants to infrastructure. Enterprise with an existing IPv4 network wants to
deploy a set of particular IPv6 "applications" and have some deploy a set of particular IPv6 "applications" and have some ability
ability to interoperate with other institutions that are using IPv6 to interoperate with other institutions that are using IPv6 services.
services. The IPv6 deployment is limited to the minimum required to The IPv6 deployment is limited to the minimum required to operate
operate this set of applications. this set of applications.
Assumptions: IPv6 software/hardware components for the application Assumptions: IPv6 software/hardware components for the application
are available, and platforms for the application are IPv6 capable. are available, and platforms for the application are IPv6 capable.
Requirements: Do not disrupt IPv4 infrastructure. Requirements: Do not disrupt IPv4 infrastructure.
Scenario 2: Dual Stack Network Scenario 2: Dual-Stack Network
Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts
hosts and network infrastructure. Enterprise with an existing IPv4 and network infrastructure. Enterprise with an existing IPv4 network
network wants to deploy IPv6 in conjunction with their IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network in order
in order to take advantage of emerging IPv6 network-centric to take advantage of emerging IPv6 network-centric capabilities and
capabilities and to be interoperable with other agencies, to be interoperable with other agencies, international partners, and
international partners, and commercial enterprises that are commercial enterprises that are deploying an IPv6 architecture.
deploying an IPv6 architecture.
Assumptions: The IPv4 network infrastructure used has an Assumptions: The IPv4 network infrastructure used has an equivalent
equivalent capability in IPv6. capability in IPv6.
Requirements: Do not disrupt existing IPv4 network infrastructure Requirements: Do not disrupt existing IPv4 network infrastructure
with IPv6. IPv6 should be equivalent or "better" than the network with IPv6. IPv6 should be equivalent or "better" than the network
infrastructure in IPv4. It may not be feasible to deploy IPv6 on infrastructure in IPv4. It may not be feasible to deploy IPv6 on all
all parts of the network immediately. Dual stacked defense parts of the network immediately. Dual-stacked defense enterprise
enterprise network must be interoperable with both IPv4 and IPv6 network must be interoperable with both IPv4 and IPv6 networks and
networks and applications. applications.
Scenario 3: IPv6 Dominant Network Scenario 3: IPv6-Dominant Network
Enterprise has some limited IPv4-capable/only nodes/applications Enterprise has some limited IPv4-capable/only nodes/applications
needing to communicate over the IPv6 infrastructure. Crisis needing to communicate over the IPv6 infrastructure. Crisis
management enterprise re-structuring an existing network, decides management enterprise re-structuring an existing network, decides to
to pursue aggressive IPv6 transition as an enabler for network- pursue aggressive IPv6 transition as an enabler for network-centric
centric services and wants to run some native IPv6-only networks to services and wants to run some native IPv6-only networks to eliminate
eliminate cost/complexity of supporting a dual stack. Some legacy cost/complexity of supporting a dual stack. Some legacy IPv4 capable
IPv4 capable nodes/applications within the enterprise will have nodes/applications within the enterprise will have slow technical
slow technical refresh/replacement path and will need to refresh/replacement paths and will need to communicate over the IPv6
communicate over the IPv6 dominant infrastructure for years until dominant infrastructure for years until they are replaced. The
they are replaced. The IPv6 dominant enterprise network will need IPv6-dominant enterprise network will need to be interoperable with
to be interoperable with it's own legacy networks, commercial its own legacy networks, commercial networks, and the legacy networks
networks, and the legacy networks of similar organizations that of similar organizations that will remain IPv4-dominant during a long
will remain IPv4 dominant during a long transition period. Reserve transition period. Reserve units, contractors, other agencies, and
units, contractors, other agencies, and international partners may international partners may need IPv4 service across this enterprise's
need IPv4 service across this enterprise's IPv6 dominant backbone. IPv6-dominant backbone.
Assumptions: Required IPv6 network infrastructure is available, or Assumptions: Required IPv6 network infrastructure is available, or
available over some defined timeline, supporting the aggressive available over some defined timeline, supporting the aggressive
transition plan. transition plan.
Requirements: Reduce operation and maintenance requirements and Requirements: Reduce operation and maintenance requirements and
increase net-centricity through aggressive IPv6 transition. increase net-centricity through aggressive IPv6 transition.
Interoperation and coexistence with legacy IPv4 networks and Interoperation and coexistence with legacy IPv4 networks and
applications is required. Legacy IPv4 nodes/applications/networks applications is required. Legacy IPv4 nodes/applications/networks
will need to be able to operate across the IPv6 backbone and need will need to be able to operate across the IPv6 backbone and need to
to be able to interoperate with the IPv6-dominant network's be able to interoperate with the IPv6-dominant network's
nodes/applications. nodes/applications.
Description of a Generic Crisis Management Network A.3. Description of a Generic Crisis Management Network
A generic network topology for a crisis management reflects the A generic network topology for crisis management reflects the various
various ways a crisis management network can connect customers ways a crisis management network can connect customers through their
through their network infrastructure. Because the institution's network infrastructure. Because the institution's existing wired and
existing wired and fixed site wireless infrastructure can be fixed-site wireless infrastructure can be destroyed or unavailable in
destroyed or unavailable in a crisis, the crisis management network a crisis, the crisis management network must be able to deploy its
must be able to deploy it's own mobile wireless network or connect own mobile wireless network or connect through external wired and
through external wired and wireless networks provided by ISPs or wireless networks provided by ISPs or partner organizations. This
partner organizations. This infrastructure lets us divide the infrastructure lets us divide the basic areas for IPv4/IPv6
basic areas for IPv4/IPv6 interoperability into three main areas: interoperability into three main areas: the customer applications,
the customer applications, the local network, and the network the local network, and the network backbone.
backbone.
The basic components in a crisis management network are depicted in The basic components in a crisis management network are depicted in
Figure 1. Figure 1.
------------ ---------- ---- Wired Connection ------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection | Network and| | | .... Wireless Connection
| Service |--| Backbone | | Service |--| Backbone |
| Operation | | | | Operation | | |
------------ ---------- ------------ ----------
/ | --------------------- / | ---------------------
/ : _|Connection to | / : _|Connection to |
/ : |Commercial Internet | / : |Commercial Internet |
/ : --------------------- / : ---------------------
Network Backbone Network Backbone
-------------- /------|-------------|-------------------- -------------- /------|-------------|--------------------
---------- / ---------- ---------- ---------- / ---------- ----------
| Home |/ | Wireless | External |............. | Home |/ | Wireless | |External |.............
| Base | | Mobile | |Untrusted |+--------- : | Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | : | Network | | Network | |Network | | :
---------- ---------- ---------- | : ---------- ---------- ---------- | :
| : : | : | : : | :
Local Network Local Network
-----:------------:----------------------------------- -----:------------:-----------------------------------
Custome Applications Customer Applications
| : : | : | : : | :
+--------+ +--------+ +--------+ | : +--------+ +--------+ +--------+ | :
| | | | | | | : | | | | | | | :
|Customer| |Customer| |Customer|+----------- : |Customer| |Customer| |Customer|+----------- :
| | | | | |.............. | | | | | |..............
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1: Crisis Management Network Topology. Figure 1: Crisis Management Network Topology.
Stages of IPv6 Deployment: A.4. Stages of IPv6 Deployment
The stages are derived from the generic description of scenarios The stages are derived from the generic description of scenarios for
for crisis management networks in Section 2. Combinations of crisis management networks in Section 2. Combinations of different
different building blocks that constitute an crisis network building blocks that constitute a crisis network environment lead to
environment lead to a number of scenarios from which the network a number of scenarios from which the network engineers can choose.
engineers can choose. The scenarios most relevant to this document The scenarios most relevant to this document are those that maximize
are those that maximize the network's ability to offer IPv6 to its the network's ability to offer IPv6 to its customers in the most
customers in the most efficient and feasible way. The assumption in efficient and feasible way. In the first three stages, the goal is
the first three stages the goal is to offer both IPv4 and IPv6 to to offer both IPv4 and IPv6 to the customer, and it is assumed that
the customer, and that in the distant future all IPv4 services will in the distant future, all IPv4 services will be eventually switched
be eventually switched to IPv6. This document will cover to IPv6. This document will cover engineering the first four stages.
engineering the first four stages.
The four most probable stages are: The four most probable stages are:
o Stage 1 Limited Launch o Stage 1 Limited Launch
o Stage 2 Dual Stack Dominance o Stage 2 Dual-Stack Dominance
o Stage 3 IPv6 Dominance o Stage 3 IPv6 Dominance
o Stage 4 IPv6 Transition Complete o Stage 4 IPv6 Transition Complete
Generally, a crisis management network is able to entirely upgrade Generally, a crisis management network is able to entirely upgrade a
a current IPv4 network to provide IPv6 services via a dual-stack current IPv4 network to provide IPv6 services via a dual-stack
network in Stage 2 and then slowly progress to stages 3 and 4 as network in Stage 2 and then slowly progress to Stages 3 and 4 as
indicted in Figure 2. During stage 2, When most applications are indicated in Figure 2. During Stage 2, when most applications are
IPv6 dominant, operational and maintenance costs can be reduced on IPv6 dominant, operational and maintenance costs can be reduced on
some networks by moving to stage 3 and running backbone networks some networks by moving to Stage 3 and running backbone networks
entirely on IPv6 while adding IPv4 backwards compatibility via v4 entirely on IPv6, while adding IPv4 backwards compatibility via v4 in
in v6 tunneling or translation mechanisms to the existing v6 tunneling or translation mechanisms to the existing configuration
configuration from stage 2. When designing a new network, if a new from Stage 2. When designing a new network, if a new IPv6-only
IPv6-only service is required, it can be implemented at a lower service is required, it can be implemented at a lower cost by jumping
cost jumping directly to stage 3/4 if there are only limited/no directly to Stage 3/4 if there are only limited or no legacy
legacy concerns. concerns.
Stage 1 Scenario: Limited Launch Stage 1: Limited Launch
The first stage begins with an IPv4-only network and IPv4
customers. This is the most common case today and the natural The first stage begins with an IPv4-only network and IPv4 customers.
starting point for the introduction of IPv6. During this stage the This is the most common case today and the natural starting point for
enterprise begins to connect individual IPv6 applications run on the introduction of IPv6. During this stage, the enterprise begins
dual stacked hosts through host based tunneling using Tunnel to connect individual IPv6 applications run on dual-stacked hosts
Broker, ISATAP, Teredo. Some early adopter networks are created for through host-based tunneling using Tunnel Broker, ISATAP, or Teredo.
pilot studies and networked together through configured tunnels and Some early adopter networks are created for pilot studies and
6to4. networked together through configured tunnels and 6to4.
The immediate first step consists of obtaining a prefix allocation The immediate first step consists of obtaining a prefix allocation
typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC,
ARIN, LACNIC, RIPE) according to allocation procedures. ARIN, LACNIC, RIPE) according to allocation procedures.
The crisis management enterprise will also need to establish IPv6 The crisis management enterprise will also need to establish IPv6
connectivity between its home base networks and mobile wireless connectivity between its home base networks and mobile wireless
networks over it's backbone and negotiate IPv6 service with its networks over its backbone. It will need to negotiate IPv6 service
service providers and with peer organizations; it is of utmost with its service providers and with peer organizations; it is of
importance to require IPv6 capability or an upgrade plan when utmost importance to require IPv6 capability or an upgrade plan when
negotiating purchases of network applications and infrastructure. negotiating purchases of network applications and infrastructure. In
In the short term, network connections, especially legacy wireless the short term, network connections, especially legacy wireless
networks, that cannot provide IPv6 services can provide IPv6 networks that cannot provide IPv6 services, can provide IPv6 services
services through the use of tunnels. However, the longer-term goal through the use of tunnels. However, the longer-term goal must be
must be requiring and obtaining IPv6 native connectivity from the requiring and obtaining IPv6 native connectivity from the transit
transit networks, because otherwise the quality of IPv6 networks. Otherwise, the quality of IPv6 connectivity will likely be
connectivity will likely be poor and the transition to stage 2 will poor and the transition to Stage 2 will be delayed.
be delayed.
Stage 2 Scenario: Dual Stack Dominance Stage 2: Dual-Stack Dominance
Stage 2 occurs when most applications, local networks, and network Stage 2 occurs when most applications, local networks, and network
backbones become dual-stacked so that native IPv6 connections are backbones become dual-stacked so that native IPv6 connections are
enabled. At this point there is a mix of IPv4 and IPv6 applications enabled. At this point there is a mix of IPv4 and IPv6 applications
and services in use across the enterprise. The enterprise may be and services in use across the enterprise. The enterprise may be
made IPv6-capable through either software upgrades, hardware made IPv6-capable through either software upgrades, hardware
upgrades, or a combination of both. Generally IPv6 is added during upgrades, or a combination of both. Generally IPv6 is added during
normal technical refresh as the enterprise buys new equipment that normal technical refresh as the enterprise buys new equipment that is
is IPv6 ready. IPv6 ready.
Specialty legacy applications and wireless/satellite networks may Specialty legacy applications and wireless/satellite networks may be
be especially slow to transition to IPv6 capability due to upgrade especially slow to transition to IPv6 capability due to upgrade
costs so plans must be made for backwards compatibility for these costs, so plans must be made for backwards compatibility for these
systems. Since some new IPv6 services cannot be provided through systems. Since some new IPv6 services cannot be provided through
IPv4, and some legacy network connections may not yet be upgraded, IPv4, and some legacy network connections may not yet be upgraded,
tunneling mechanisms have to be provided on the backbone to provide tunneling mechanisms have to be provided on the backbone to provide
IPv6 connectivity through to customer IPv6 applications still IPv6 connectivity through to customer IPv6 applications still relying
relying on legacy IPv4-only networks. The tunnels may provide on legacy IPv4-only networks. The tunnels may provide host-based
host-based tunneling for individual customers or site-to-site tunneling for individual customers or site-to-site tunnels to connect
tunnels to connect small IPv6 domains through IPv4 only networks. small IPv6 domains through IPv4-only networks. If any new
If any new applications are IPv6-only rather than dual-stacked, and applications are IPv6-only rather than dual-stacked, and need to
need to interact with IPv4-only legacy applications, translators interact with IPv4-only legacy applications, translators will be used
will be used as a transition mechanism of last resort during this as a transition mechanism of last resort during this stage.
stage.
Stage 3 Scenario: IPv6 Dominance Stage 3: IPv6 Dominance
Applications are deployed specifically to use IPv6 as benefit, thus Applications are deployed specifically to use IPv6 as benefit; thus,
network backbone and nodes use IPv6 and not IPv4, except where IPv4 network backbone and nodes use IPv6 and not IPv4, except where IPv4
is legacy. is legacy.
Authors' Addresses
Jim Bound
HP
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: 603.465.3130
EMail: jim.bound@hp.com
Yanick Pouffary
HP Competency Center
950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX
FRANCE
Phone: + 33492956285
EMail: Yanick.pouffary@hp.com
Tim Chown
School of Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
David Green
Command Information
13655 Dulles Technology Drive
Suite 500
Herndon, VA 20171
USA
Phone: 703.561.5937
EMail: green@commandinformation.com
Steve Klynsma
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102-5708
USA
Phone: 703-883-6469
EMail: sklynsma@mitre.org
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 241 change blocks. 
981 lines changed or deleted 767 lines changed or added

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