draft-ietf-v6ops-ent-analysis-03.txt   draft-ietf-v6ops-ent-analysis-04.txt 
IPv6 Operations Working Group IPv6 Operations Working Group
Internet Draft Jim Bound Internet Draft Jim Bound
Document: draft-ietf-v6ops-ent-analysis-03.txt Yanick Pouffary Document: draft-ietf-v6ops-ent-analysis-04.txt Yanick Pouffary
Obsoletes: ietf-v6ops-ent-analysis-02.txt Hewlett-Packard Obsoletes: ietf-v6ops-ent-analysis-03.txt Hewlett-Packard
Expires: January 2006 Steve Klynsma Expires: January 2006 Steve Klynsma
MITRE MITRE
Tim Chown Tim Chown
University of Southhampton University of Southampton
Dave Green Dave Green
SRI SRI
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-03.txt> <draft-ietf-v6ops-ent-analysis-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 51 skipping to change at line 52
This document analyzes the transition to IPv6 in enterprise This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has networks. These networks are characterized as a network that has
multiple internal links, one or more router connections, to one or multiple internal links, one or more router connections, to one or
more Providers, and is managed by a network operations entity. The more Providers, and is managed by a network operations entity. The
analysis will focus on a base set of transition notational networks analysis will focus on a base set of transition notational networks
and requirements expanded from a previous Enterprise Scenarios and requirements expanded from a previous Enterprise Scenarios
document. Discussion is provided on a focused set of transition document. Discussion is provided on a focused set of transition
analysis required for the enterprise to transition to IPv6, analysis required for the enterprise to transition to IPv6,
assuming a Dual-IP layer (IPv4 and IPv6) network and node assuming a Dual-IP layer (IPv4 and IPv6) network and node
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 1]
environment, within the enterprise. Then a set of transition environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network. mechanisms are recommended for each notational network.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 1]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 2]
Table of Contents: Table of Contents:
1. Introduction................................................3 1. Introduction................................................4
2. Terminology.................................................5 2. Terminology.................................................6
3. Enterprise Matrix Analysis for Transition...................6 3. Enterprise Matrix Analysis for Transition...................7
4. Wide-Scale Dual-Stack Deployment Analysis..................10 4. Wide-Scale Dual-Stack Deployment Analysis..................11
4.1 Staged Dual-Stack Deployment...............................10 4.1 Staged Dual-Stack Deployment...............................11
4.2 Routing Capability Analysis for Dual-IP Deployment.........11 4.2 Routing Capability Analysis for Dual-IP Deployment.........12
4.2.1 IPv6 Routing Capability..................................11 4.2.1 IPv6 Routing Capability..................................12
4.2.2 IPv6 Routing Non-Capability..............................11 4.2.2 IPv6 Routing Non-Capability..............................12
4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............11 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............13
4.4.2.2 Deploy a parallel IPv6 infrastructure..................12 4.2.2.2 Deploy a parallel IPv6 infrastructure..................13
4.3 Remote IPv6 access to the enterprise.......................12 4.3 Remote IPv6 access to the enterprise.......................14
4.4 Other considerations.......................................12 4.4 Other considerations.......................................14
5. Sparse Dual-Stack Deployment Analysis......................13 5. Sparse Dual-Stack Deployment Analysis......................15
5.1 Internal versus External Tunnel End Point..................13 5.1 Internal versus External Tunnel End Point..................15
5.2 Manual versus Autoconfigured...............................14 5.2 Manual versus Autoconfigured...............................16
6. IPv6 Dominant Network Deployment Analysis..................15 6. IPv6 Dominant Network Deployment Analysis..................17
7. General Issues from Analysis...............................16 7. General Issues from Analysis...............................18
7.1 Staged Plan for IPv6 Deployment............................16 7.1 Staged Plan for IPv6 Deployment............................18
7.2 Network Infrastructure Requirements........................16 7.2 Network Infrastructure Requirements........................18
7.3 Stage 1: Initial connectivity steps........................16 7.3 Stage 1: Initial connectivity steps........................18
7.3.1 Obtaining external connectivity..........................16 7.3.1 Obtaining external connectivity..........................18
7.3.2 Obtaining global IPv6 address space......................16 7.3.2 Obtaining global IPv6 address space......................18
7.4 Stage 2: Deploying generic basic service components........17 7.4 Stage 2: Deploying generic basic service components........19
7.4.1 IPv6 DNS.................................................17 7.4.1 IPv6 DNS.................................................19
7.4.2 IPv6 Routing.............................................17 7.4.2 IPv6 Routing.............................................19
7.4.3 Configuration of Hosts...................................17 7.4.3 Configuration of Hosts...................................19
7.4.4 Developing an IPv6 addressing plan.......................18 7.4.4 Developing an IPv6 addressing plan.......................20
7.4.5 Security.................................................18 7.4.5 Security.................................................21
7.5 Stage 3: Widespread Dual-Stack deployment on-site..........19 7.5 Stage 3: Widespread Dual-Stack deployment on-site..........22
8. Applicable Transition Mechanisms...........................21 8. Applicable Transition Mechanisms...........................23
8.1 Recognizing Incompatible Network touchpoints...............21 8.1 Recognizing Incompatible Network touchpoints...............23
8.2 Recognizing Application incompatibilities..................22 8.2 Recognizing Application incompatibilities..................24
8.3 Using Multiple Mechanisms to Support IPv6 Transition.......22 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......25
8.4 Analysis of Selected Transition Mechanisms.................22 9. Security Considerations....................................26
9. Security Considerations....................................24 10. IANA Considerations........................................26
10. IANA Considerations........................................24 11. References.................................................26
11. References.................................................24 11.1 Normative References......................................26
11.1 Normative References......................................24 11.2 Non-Normative References..................................28
11.2 Non-Normative References..................................24 Change Log.....................................................28
Change Log.....................................................26 Document Acknowledgments.......................................29
Document Acknowledgments.......................................27 Author's Addresses.............................................30
Author's Addresses.............................................28 Copyright (C) The Internet Society (2006)......................31
Copyright (C) The Internet Society (2005)......................29 Disclaimer.....................................................31
Disclaimer.....................................................29 IPR Disclosure Acknowledgement.................................31
IPR Disclosure Acknowledgement.................................29 Disclaimer of validity.........................................31
Disclaimer of validity.........................................29 Acknowledgment.................................................32
Acknowledgment.................................................30 Appendix A - Crisis Management Network Scenarios...............33
Appendix A - Crisis Management Network Scenarios...............31
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 2]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 3]
1. Introduction 1. Introduction
This document analyzes the transition to IPv6 in enterprise This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has networks. These networks are characterized as a network that has
multiple internal links, one or more router connections, to one or multiple internal links, one or more router connections, to one or
more Providers, and is managed by a network operations entity. The more Providers, and is managed by a network operations entity. The
analysis will focus on a base set of transition notational networks analysis will focus on a base set of transition notational networks
and requirements expanded from a previous Enterprise Scenarios and requirements expanded from a previous Enterprise Scenarios
document. Discussion is provided on a focused set of transition document. Discussion is provided on a focused set of transition
skipping to change at line 145 skipping to change at line 147
wide Dual-IP layer deployment strategy across the enterprise, to wide Dual-IP layer deployment strategy across the enterprise, to
provide the reader a view of how that can be planned and what are provide the reader a view of how that can be planned and what are
the options available. The document will then discuss the the options available. The document will then discuss the
deployment of sparse IPv6 nodes within the enterprise and what deployment of sparse IPv6 nodes within the enterprise and what
requirements need to be considered and implemented, when the requirements need to be considered and implemented, when the
enterprise will remain with IPv4-only routing infrastructure for enterprise will remain with IPv4-only routing infrastructure for
some time. The next discussion focuses on the use of IPv6 when it some time. The next discussion focuses on the use of IPv6 when it
is determined to be dominant across or within parts of the is determined to be dominant across or within parts of the
enterprise network. enterprise network.
The document then begins to discuss the the general issues and The document then begins to discuss the general issues and
applicability from the previous analysis. The document concludes applicability from the previous analysis. The document concludes
providing a set of current transistion mechanism recommendations providing a set of current transition mechanism recommendations for
for the notational network scenarios to support an enterprise the notational network scenarios to support an enterprise planning
planning to deploy IPv6. to deploy IPv6.
This document, as stated in the introduction, focuses only on the This document, as stated in the introduction, focuses only on the
deployment cases where a Dual-IP layer is supported across the deployment cases where a Dual-IP layer is supported across the
network and on the nodes in the enterprise. Additional deployment network and on the nodes in the enterprise. Additional deployment
transition analysis will be required from the effects of IPv6-only transition analysis will be required from the effects of IPv6-only
node or Provider deployments, and beyond the scope of this node or Provider deployments, and beyond the scope of this
document. In addition this document does not attempt to define or document. In addition this document does not attempt to define or
discuss any use with network address translation [NATPT, NATDE] or discuss any use with network address translation [NATPT, NATDE] or
the use of Provider Independent address space. the use of Provider Independent address space.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 4]
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
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 3]^L
- 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 Transtion 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 We are focusing in this document on IP Layer 3 deployment, in the
same way as the other IPv6 deployment analysis works have done same way as the other IPv6 deployment analysis works have done
[UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the [UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the
wire", including address management and DNS services. wire", including address management and DNS services.
We are also assuming that the enterprise deployment is one 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 is not discussing 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 sectioin 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 are
recommended that can support the deployment of IPv6 with an recommended that can support the deployment of IPv6 with an
enterprise. enterprise.
This document then provides Appendix A for readers depicting a This document then provides Appendix A for readers depicting a
Crisis Management enterprise network to demonstrate an enterprise Crisis Management enterprise network to demonstrate an enterprise
network example that requires all the properties as analyzed in network example that requires all the properties as analyzed in
Sections 3, 4, 5, 6, and 7. Sections 3, 4, 5, 6, and 7.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 4]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 5]
2. Terminology 2. Terminology
Enterprise Network - A network that has multiple internal links, Enterprise Network - A network that has multiple internal links,
one or more router connections, to one or one or more router connections, to one or
more Providers and is actively managed by a more Providers and is actively managed by a
network operations entity. network 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
skipping to change at line 240 skipping to change at line 241
IPv4 and IPv6. IPv4 and IPv6.
IP-capability - The ability to support IPv6 only, IPv4 only, IP-capability - The ability to support IPv6 only, IPv4 only,
or Dual IP Layer or Dual IP Layer
IPv6-dominant - A network or link that uses only IPv6 routing. IPv6-dominant - A network or link that uses only IPv6 routing.
Transition - The network strategy the enterprise uses to Transition - The network strategy the enterprise uses to
Implementation transition to IPv6. Implementation transition to IPv6.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 5]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 6]
3. Enterprise Matrix Analysis for Transition 3. Enterprise Matrix Analysis for Transition
In order to identify the best suited transition mechanisms for an
enterprise, it is recommended that the enterprise have an in-depth
up-to-date understanding of its current IT environment. This
understanding will help choose the best suited transition
mechanisms. It is important to note that one size does not fit all.
While selecting a mechanism it is suggested to select mechanisms
which reduce the impact on the existing environment. When selecting
a transition mechanism one must consider the functionality
required, its scalability characteristic, and the security
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 layer 3 we have provided a matrix which describes various at layer 3 we have provided a matrix which describes various
scenarios which might be encountered during an IPv6 transition. scenarios which might be encountered during an IPv6 transition.
The notional enterprise network is comprised of hosts attached to The notional enterprise network is comprised of hosts attached to
an enterprise-owned intranet(s) at two different global locations an enterprise-owned intranet(s) at two different global locations
separated by the Internet. The enterprise owns, operates and separated by the Internet. The enterprise owns, operates and
maintains its own intranetworks, but relies on an external provider maintains its own intranetworks, but relies on an external provider
organization that offers Internet Service. Both local and organization that offers Internet Service. Both local and
destination intranetworks are operated by different organizations destination intranetworks are operated by different organizations
within the same enterprise and consequently could have different within the same enterprise and consequently could have different
skipping to change at line 280 skipping to change at line 292
IPv6-only ISPs will require separate analysis, that is beyond the IPv6-only ISPs will require separate analysis, that is beyond the
scope of this document. scope of this document.
Table 1 scenarios below is a matrix of ten possible Transition Table 1 scenarios below is a matrix of ten possible Transition
Implementations that, being encountered in an enterprise, may Implementations that, being encountered in an enterprise, may
require analysis and the selection of an IPv6 transition mechanism require analysis and the selection of an IPv6 transition mechanism
for that notional network. Each possible implementation is for that notional network. Each possible implementation is
represented by the rows of the matrix. The matrix describes a set represented by the rows of the matrix. The matrix describes a set
of notional networks as follows: of notional networks as follows:
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 7]
- The first column represents the protocol used by the - The first column represents the protocol used by the
application and below, the IP-capability of the node application and below, the IP-capability of the node
originating the IP packets. originating the IP 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 network wherein the node originated the packet. host 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 provider network. service 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 received. are received.
(Host 2 Network) (Host 2 Network)
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 6]^L
- The fifth column represents the protocol used by the - The fifth column represents the protocol used by the
application and, below, the IP-capability of the application and, below, the IP-capability of the
destination node receiving the originating IP packets. destination node receiving 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 a Dual-IP layer host trying to establish a communications on a Dual-IP layer host trying to establish a communications
exchange with a destination IPv6 application. To complete the exchange with a destination IPv6 application. To complete the
information exchange the packets must first traverse the host's information exchange the packets must first traverse the host's
originating IPv4 network (intranet), then the service provider's, originating IPv4 network (intranet), then the service provider's,
and destination hosts Dual-IP network. and destination hosts 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 represent the vast majority of transitional situations
likely to be encountered in today's enterprise. Therefore, we will likely to be encountered in today's enterprise. Therefore, we will
use these ten to address the analysis for enterprise deployment. use these ten to address the analysis for enterprise deployment.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 7]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 8]
Table 1 - Enteprise 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| ---- |
| Dual IP | | IPv4 | | Dual IP | | Dual IP | | IPv4 | | Dual IP |
====================================================== ======================================================
skipping to change at line 369 skipping to change at line 381
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)
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 9]
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 which wishes to
use IPv6 applications, but has yet to transition its internal use IPv6 applications, but has yet to transition its internal
networks and it's Service Provider also lags, offering only a v4 networks and its Service Provider also lags, offering only a v4
IP-service. Conversely, Scenario C represents an enterprise which IP-service. Conversely, Scenario C represents an enterprise which
has completed transition to IPv6 in its core networks (as has its has completed transition to IPv6 in its core networks (as has its
Service Provider), but continues to require a legacy IPv4-based Service Provider), but continues to require a legacy IPv4-based
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 8]^L
application. application.
Scenario D represents the unusual situation where the enterprise Scenario D represents the unusual situation where the enterprise
has transitioned its core intranetworks to IPv6, but (like scenario has transitioned its core intranetworks to IPv6, but (like scenario
B) it's ISP provider has yet to transition. In addition, this B) 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 heterogenous network applications which 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 v4- and v6-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 heterogenous network segments between the it maintains a variety of heterogeneous network segments between
communicating applications. Scenarios E and J represent distinctly the communicating applications. Scenarios E and J represent
different extremes on either end of the spectrum. In scenario E, distinctly different extremes on either end of the spectrum. In
the enterprise has largely transitioned to IPv6 in both its scenario E, the enterprise has largely transitioned to IPv6 in both
applications and networks. However, scenario E shows that a few its applications and networks. However, scenario E shows that a few
legacy IPv4-based applications may still be found in the legacy IPv4-based applications may still be found in the
enterprise. On the other hand, scenario J shows an Enterprise that enterprise. On the other hand, scenario J shows an Enterprise that
has begun its transition in a very disjointed manner and, in which has begun its transition in a very disjointed manner and, in which
IPv6-based applications and network segments are relatively rare. IPv6-based applications and network segments are relatively rare.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 9]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 10]
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 [BSCN]. The scenario, assumptions and requirements are driven of [BSCN]. The scenario, assumptions and requirements are driven
from the [BSCN] text. This analysis further corresponds to from the [BSCN] text. This analysis further corresponds to
Scenario A in Section 3 above (although Scenario A shows a Scenario A in Section 3 above (although Scenario A shows a
transitional situation wherein the enterprise has one network transitional situation wherein the enterprise has one network
segment still lagging on transition to dual-IP). segment still lagging on 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, such that communications can run over either protocol. IP, 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
skipping to change at line 451 skipping to change at line 463
be enabled on specific links at various stages of deployment. There be enabled on specific links at various stages of deployment. There
may be a requirement that some links remain IPv4 only, or some that may 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 the layer 3 analysis of this selected is orthogonal to the layer 3 analysis of this document.
document.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 11]
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 deployment. Such a testbed not only allows the IPv6 wider deployment. Such a testbed not only allows the IPv6
capability of specific platforms and applications to be evaluated capability of specific platforms and applications to be evaluated
and verified, but also permits the steps in Sections 7.3 and 7.4 of and verified, but also permits the steps in Sections 7.3 and 7.4 of
this document to be undertaken without (potential) adverse impact this document to be undertaken without (potential) adverse impact
on the production elements of the enterprise. on the production elements of the enterprise.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 10]^L
Section 7.5 describes the stages for the widespread deployment in Section 7.5 describes the stages for the widespread deployment in
the enterprise, which could be undertaken after the basic building the enterprise, which could be undertaken after the basic building
blocks for IPv6 deployment are in place. blocks 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-capable routing infrastructure to be implemented. The path IPv6-capable routing infrastructure to be implemented. The path
taken will depend on whether the enterprise has existing Layer 2/3 taken 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
skipping to change at line 493 skipping to change at line 504
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 been verified. has 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 below may be required.
4.2.2 IPv6 Routing Non-Capability 4.2.2 IPv6 Routing Non-Capability
If the enterperise 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 existing IPv4 subnets. into existing IPv4 subnets.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 12]
It may thus be the case that a nodes IPv4 and IPv6 default routes It may thus be the case that a nodes IPv4 and IPv6 default routes
to reach other links (subnets) are through different routing to 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 which
are IPv6-capable, while others,and perhaps the enterprise backbone are 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 described in [BCNF] would be established between the Dual-IP as described in [BCNF] would be established between the Dual-IP
capable routers on the enterprise, thus "bypassing" existing non capable routers on the enterprise, thus "bypassing" existing non
IPv6-capable routers and platforms. IPv6-capable routers and platforms.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 11]^L
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 addressing is obtained, planned and used from the outset. IPv6 addressing is obtained, planned and used from the outset.
4.4.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 parallel infrastructure would be IPv6-dominant. a 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 the advantage that the existing IPv4 routing platforms are not has 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
skipping to change at line 546 skipping to change at line 557
based on the subnet/link the packet is destined for; thus multiple based on the subnet/link the packet is destined for; thus multiple
IPv6 links can be collapsed for delivery on a single (or small IPv6 links can be collapsed for delivery on a single (or small
number of) physical IPv6 router interfaces in the early stages of number of) physical IPv6 router interfaces 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 enterprise services to be deployed, including IPv6 addressing, IPv6 enterprise services to be deployed, including IPv6 addressing,
thus making the enterprise ready for that unifying step at a later thus making the enterprise ready for that unifying step at a later
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 13]
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 not support any native IPv6 service or IPv6 transition aids, does not support any native IPv6 service or IPv6 transition aids,
the enterprise may consider deploying it's own remote IPv6 access the enterprise may consider deploying it's own remote IPv6 access
support, as described in Section 7.5.2 below. support.
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]
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 12]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 14]
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 the Scenario 2 as described in Section 3.1 of
[BSCN]. This scenario assumes the requirements defined within the [BSCN]. This scenario assumes the requirements defined within the
[BSCN] text. [BSCN] text.
IPv6 deployment within the enterprise network, with an existing IPv6 deployment within the enterprise network, with an existing
IPv4 infrastructure, could be motivated by mission critical or IPv4 infrastructure, could be motivated by mission critical or
business applications or services that require IPv6. In this case business applications or services that require IPv6. In this case
skipping to change at line 612 skipping to change at line 625
because all IPv6 traffic must be forwarded by the Enterprise's IPv4 because all IPv6 traffic must be forwarded by the Enterprise's IPv4
infrastructure to the Tunnel End-Point offered by the Provider. infrastructure to the Tunnel End-Point offered by the Provider.
Nevertheless, this may be acceptable paticularly if the IPv6 Nevertheless, this may be acceptable paticularly 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
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 15]
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.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 13]^L
5.2 Manual versus Autoconfigured 5.2 Manual versus Autoconfigured
If the number of nodes to be using IPv6 is reduced, another option If the number of nodes to be using IPv6 is low, the first option is
is to use statically configured tunnels. However automatically to use statically configured tunnels. However, automatically
configured tunnels are generally preferred. configured tunnels may be preferable, especially if the number is
higher.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 14]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 16]
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 captured in Scenario C of Table 1. is 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 deployment strategy. What this means essentially is that network deployment strategy. What this means essentially is that
the network or specific sites within the enterprise network will the network or specific sites within the enterprise network will
transition to IPv6 using only IPv6 routing to transfer both IPv4 transition to IPv6 using only IPv6 routing to transfer both IPv4
and IPv6 packets over the network, even though the network may be and IPv6 packets over the network, even though the network may be
Dual-IP capable. IPv4 routing would not be turned on within an Dual-IP capable. IPv4 routing would not be turned on within an
IPv6-dominant network, except if required at to support edge IPv4 IPv6-dominant network, 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. When IPv6-capable nodes in the IPv6-dominant network need to IPv6. 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 [6TUN]. An edge implementation to tunnel IPv4 packets in IPv6 [6TUN]. 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 From Table 1 scenarios E and F 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 the entire network could be IPv6-dominant, but the Host OS 2 E the entire network could be IPv6-dominant, but the Host OS 2
system is running an IPv4 application. In scenario F the Host OS 1 system is running an IPv4 application. In scenario F the Host OS 1
system network could be IPv6-dominant, but the rest of the networks system network could be IPv6-dominant, but the rest of the networks
are all IPv4. are all 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 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 aquire 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 networks slows and may even IPv4 services in an IPv6-dominant network slows and may even impede
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 and operational objectives and guided by the Enterprise's business and operational objectives and guided by the Enterprise's
transition plan. transition plan.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 15]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 17]
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 sections 4-6 in 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
skipping to change at line 717 skipping to change at line 731
upstream link. It would be expected that the enterprise would use upstream link. It would be expected that the enterprise would use
either native IPv6 upstream connectivity or, in its absence, a either native IPv6 upstream connectivity or, in its absence, a
manually configured tunnel [BCNF] to the upstream provider. manually configured 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.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 18]
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].
The procedure for enterprise renumbering between providers is The procedure for enterprise renumbering between providers is
described in [RENUM]. described in [RENUM].
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 16]^L
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, but
these aspects should be addressed in Stage 2. these aspects should be addressed in Stage 2.
7.4.1 IPv6 DNS 7.4.1 IPv6 DNS
skipping to change at line 761 skipping to change at line 774
For internal routing, an appropriate interior routing protocol may For internal routing, an appropriate interior routing protocol may
be deployed. IPv6 routing protocols that can be used are as be deployed. IPv6 routing protocols that can be used are as
follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng
[RIPng]. [RIPng].
7.4.3 Configuration of Hosts 7.4.3 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
IPv4 address and other configuration information delegation and IPv4 address and other configuration information delegation and
management, including manual configuration, NIS [NIS] or DHCP management, including manual configuration, NIS [NIS] or DHCP
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 19]
[DHCPv4]. [DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration In an IPv6 enterprise, Stateless Address Autoconfiguration
[ADDRCONF] may be used to configure a host with a global IPv6 [ADDRCONF] may be used to configure a host with a global IPv6
address, a default router, and an on-link prefix information. address, a default router, and an on-link prefix information.
For secure autoconfiguration, the IPsec [IPSEC] or SEND method For secure autoconfiguration, the IPsec [IPSEC] or SEND method
[SEND] can be used. [SEND] can be used.
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, a DHCPv6 Relay Agent function will be required. offlink, a DHCPv6 Relay Agent function will be required.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 17]^L
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.4 Developing an IPv6 addressing plan 7.4.4 Developing an IPv6 addressing plan
A site will need to formulate an IPv6 addressing plan, utilising A site will need to formulate an IPv6 addressing plan, utilizing
the globally aggregatable public IPv6 prefix allocated to it by its the 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 renumbering due to restructuring). future renumbering due to restructuring).
skipping to change at line 810 skipping to change at line 824
nodes), because IPv4 address conservation is required. This creates nodes), because IPv4 address conservation is required. This creates
problems when the number of nodes on a subnet grows, larger IPv4 problems when the number of nodes on a subnet grows, larger IPv4
prefixes are then required, and potentially time-consuming and prefixes are then required, and potentially time-consuming and
disruptive renumbering events will follow. disruptive 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
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 20]
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 utilise 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 a /48) is likely to include such room for growth. be a /48) is likely to include such room for growth.
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 for IPv4-capable nodes. For example, a border firewall does for IPv4-capable nodes. For example, a border firewall
should be capable of filtering and controlling IPv6 traffic by should be capable of filtering and controlling IPv6 traffic by
enforcing the same policy as it already does for IPv4. enforcing the 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 of IPv6 specific functionality that will be deployed in the light of IPv6 specific functionality that will be deployed in the
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 18]^L
site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND), site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND),
IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use IPv6 Privacy Extensions, end-to-end IPsec, and, not least, the use
of globally aggregatable public address space where for IPv4 of globally aggregatable public address space where for IPv4
private addressing and NAT may have been used. 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 found in [NAP]. This describes how the perceived security with be found in [NAP]. This describes how the perceived security with
IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6 IPv4 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.
skipping to change at line 860 skipping to change at line 874
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 tunnelled 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.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 21]
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 IPv6 transport. an IPv6 transport.
In the Dual-IP deployment case, this means enabling IPv6 on In the Dual-IP deployment case, this means enabling IPv6 on
skipping to change at line 888 skipping to change at line 904
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 all applications. Putting support for IPv6 in all site by 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 and services IPv6 enabled, the IPv6 capable applications and services IPv6 enabled, the IPv6 capable
infrastructure can be leveraged. For most networks, Dual-IP will infrastructure can be leveraged. For most networks, Dual-IP will
be at the very least a medium-term transition towards an IPv6 be at the very least a medium-term transition towards an IPv6-
dominant future. However, the introduction of IPv6 support, with dominant future. However, the introduction of IPv6 support, with
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 19]^L
the potential benefits of globally aggregatable public address the potential benefits of globally aggregatable public address
usage (with [NAP]), and other new IPv6 capabilities, can bring more usage (with [NAP]), and other new IPv6 capabilities, can bring more
immediate benefits for the site. immediate benefits for the site.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 20]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 22]
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 support the enterprise matrix notional networks (rows) in to support the enterprise matrix notional networks (rows) in
Section 3, and within the context of the analysis discussed in Section 3, and within the context of the analysis discussed in
Sections 4, 5, and 6. Sections 4, 5, and 6.
Table 1 provides a number of common scenarios that an enterprise Table 1 provides a number of common scenarios that an enterprise
skipping to change at line 938 skipping to change at line 952
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 4.2.2.1, tunneling can be used to "bypass" the incompatible Section 4.2.2.1, tunneling can be used to "bypass" the incompatible
network segments. One tunneling option, Manual Configured Tunnels network segments. One tunneling option, Manual Configured Tunnels
[BCNF] could be used by the enterprise, but as the name implies, [BCNF] could be used by the enterprise, but as the name implies,
this mechanism provides no automated tunnnel configuration. this mechanism provides no automated tunnel configuration.
6to4 [6to4] can be used to support enterprises that do not have an 6to4 [6to4] can be used to support enterprises that do not have an
assigned IPv6 prefix address. assigned IPv6 prefix address.
Identifying the responsible device to perform the tunneling is Identifying the responsible device to perform the tunneling is
driven by the position of the incompatible touchpoint. If a local driven by the position of the incompatible touchpoint. If a local
network is incompatible than host tunneling is appropriate. If the network is incompatible then host tunneling is appropriate. If the
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 23]
backbone (provider) network is incompatible then gateway-to-gateway backbone (provider) network is incompatible then gateway-to-gateway
tunneling might be a better choice. By working to ensure tunnel tunneling might be a better choice. By working to ensure tunnel
endpoints are always configured at dual-IP devices, end-to-end endpoints are always configured at dual-IP devices, end-to-end
communication or services (IPv4 or IPv6) can be preserved. communication or services (IPv4 or IPv6) can be preserved.
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
lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end requires some form of tunneling. Where configured tunnels are not
service. ISATAP [ISTP] can be used to provide end node IPv6 sufficient a more automatic solution may be appropriate. Available
solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 21]^L end service. ISATAP [ISTP] can be used to provide end node IPv6
connectivity from nodes on an isolated IPv4 network, through the connectivity from nodes on an isolated IPv4 network, through the
use of automatic tunneling of IPv6 in IPv4. use of automatic 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 an enterprise using manual configured tunnels, 6to4, or DSTM. for an enterprise using manual configured tunnels, 6to4, or DSTM.
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
should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or will need to determine a network transition strategy to tunnel IPv4
in the case of early deployment of IPv6-dominant networks DSTM can within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise
be used too. Intranet. Or in the case of early deployment of IPv6-dominant
networks the architect will need to address this from the beginning
of the required transition planning. The deployment methodology
for an architect to design IPv6-dominant networks is under study
currently, two work in progress reference points that can be used
for analysis are use of Tunnel Brokers [TBRK] or Dual-IP Layer
Transition Mechanism [DSTM].
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. During the transition period, particularly for incompatibilities. During the transition period, particularly for
large enterprises, it is to be expected that applications hosted at large enterprises, it is to be expected that applications hosted at
one location may lead (or lag) the IPv6-compability of its peer (or one location may lead (or lag) the IPv6-compability of its peer (or
server) at some other location. server) at some other location.
This leads us to the third theme represented by Scenario E and G, This leads us to the third theme represented by Scenario E and G,
i.e. incompatible applications communicating across a homogenous i.e. incompatible applications communicating across a homogenous
network. Translation is an obvious solution, but not recommended network. Translation is an obvious solution, but not recommended
except for legacy devices at the network edge which cannot or never except for legacy devices at the network edge which cannot or never
will be upgraded to IPv6. A more scaleable solution would be to will be upgraded to IPv6. A more scaleable solution would be to
use an Application Layer Gateways (ALG) between the incompatible use an Application Layer Gateways (ALG) between the incompatible
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 24]
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 IPv6, the architect will be faced with both incompatible hosts to IPv6, the architect will be faced with both incompatible hosts
and simulataneously (at different parts of the enterprise) and simultaneously (at different parts of the enterprise)
incompatible networks. These highly complex situations represent incompatible networks. These highly complex situations represent
the fourth common theme in Table 1 and are specifically depicted by the fourth common theme in Table 1 and are specifically depicted by
Scenarios F, H, I and J. Maintaining IP interoperability in these Scenarios F, H, I and J. Maintaining IP interoperability in these
situations requires additional planning and may require multiple or situations requires additional planning and may require multiple or
even nested use of diverse transition mechanisms. For example, an even nested use of diverse transition mechanisms. For example, an
ALG co-located with the application server may be required to ALG co-located with the application server may be required to
service both IPv4 and IPv6 data streams that are simulataneously service both IPv4 and IPv6 data streams that are simultaneously
tunneled through incompatible network segment(s). tunneled through incompatible network segment(s).
8.4 Analysis of Selected Transition Mechanisms draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 25]
The following transition mechanism have at least two independent
implementations and are deployed in enterprises today. The authors
are only comfortable analyzing the transition mechanisms below, in
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 22]^L
addition to our analysis in Sections 8.1, 8.2, and 8.3.
Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to
develop a test network in the enterprise, but will not scale well
for a complete implementation of an IPv6 network. Manual Configured
Tunnels for IPv6 is an IETF Proposed Standard.
6to4 [6t4] is a useful tunneling mechanism for deployment if the
enterprise has not obtained a native IPv6 prefix from their
provider. 6to4 is an IETF Proposed Standard.
NAT-PT [NATPT] can be useful when there is no other means to access
an IPv4 node behind a NAT network that only has a private address.
But, it is recommended that the enterprise also look at the ability
to provide access to that IPv4 node using a Proxy or Application
Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF
Proposed Standard.
Teredo [TRDO] can be useful for an enterprise when an enterprise
node only has an IPv4 address and use of NAT-PT, Proxy, or an
Application Layer Gateway is not optimal. Teredo is on track to be
an IETF Proposed Standard.
ISATAP [ISTP] is a useful tunneling mechanism when the enterprise
has deployed IPv6, and there are particpating nodes for the IPv6
deployment that exist on IPv4 networks. ISATAP is being submitted as
an IETF Experimental RFC.
DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.
Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the
Enterprise wants to automate the setup of tunnels in the enterprise,
and a tunnel broker can be used to support 6to4, ISATAP, and DSTM
mechanisms. Tunnel Broker set-up protocol is being submitted as an
IETF Experimental RFC.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 23]^L
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 are discussed above in section 7.4.5, where external environment are discussed above in section 7.4.5, where external
references to overview documents [V6SEC] [NAP] are also included. references to overview documents [V6SEC] [NAP] are also included.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. References 11. References
11.1 Normative References 11.1 Normative References
There are no normative references in this document to depict [CONF] Thomson, S., Narten, T., "IPv6 Stateless
correct protocol operation. This document is an analysis technical Autoconfiguration" RFC 2462 December 1998.
effort not a operative or protocol specification.
11.2 Non-Normative References [DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al.
"Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" RFC 3315 July 2003.
[DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational [DHCPL] Droms, R., "Stateless Dynamic Host Configuration
Considerations and Issues with IPv6 DNS", Work in Protocol (DHCP) Service for IPv6"
Progress. RFC 3756 April 2004.
[CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration" [6TO4] Carpenter, B., Moore, K., "Connection of IPv6
RFC 2462 December 1998. Domains via IPv4 Clouds" RFC 3056 February 2001.
[DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic [BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network
Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July Scenarios" RFC 4057 June 2005.
2003.
[DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP
(DHCP) Service for IPv6" RFC 3756 April 2004. through NATs" RFC 4380.
[APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E., [ISTP] Templin, F., et al "Intra-Site Automatic Tunnel
"Application Aspects of IPv6 Transition" RFC 3038 March 2005. Addressing Protocol (ISATAP)". RFC 4214 October 2005.
[BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios" [6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in
Work in Pogress. IPv6" RFC 2473 December 1998.
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via [TBRK] Durand, A., et al "IPv6 Tunnel Broker"
IPv4 Clouds" RFC 3056 February 2001. RFC 3053 January 2001.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 26]
NATs" Work in Progress. [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites" RFC 3177 September 2001.
[BCNF] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address
for IPv6 Hosts and Routers" Work in Progress from RFC 2893. `Translation - Protocol Translation (NAT-PT)"
RFC 2766 February 2000
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 24]^L [UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition
[DSTM] Bound, J., (Ed) et al. "Dual Stack Transition Mechanim" Mechanisms for Unmanaged Networks".
Work in Progress. RFC 3904 September 2004.
[DSTM+] DSTM Industry Design Team web site www.dstm.info [ISPA] Lind, M., et al "Scenarios and Analysis for
Introducing IPv6 into ISP Networks".
RFC 4029 March 2005.
[ISTP] Templin, F., et al "Intra-Site Automatic Tunnel [3GPA] Wiljakka, J., "Analysis on IPv6 Transition in
Addressing Protocol (ISATAP)". Work in Progress. 3GPP Networks" RFC 4215 October 2005.
[6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in [OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6"
IPv6" RFC 2473 December 1998. RFC2740 December 1999.
[TBRK] Durand, A., et al "IPv6 Tunnel Broker" [BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol
RFC 3053 January 2001. Extensions for BGP-4", RFC2283 June 2000.
[TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker with the [ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing
Tunnel Setup Protocol". Work in Progress. Protocol", RFC1142 February 1990.
[SEC1] Savola, P. and Patel, C. "Security Considerations for 6to4" [RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC3964 December 2004. 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
[SEC1] Savola, P. and Patel, C. "Security Considerations
for 6to4" RFC 3964 December 2004.
[ULA] Hinden, B., Haberman, B., "Unique Local IPv6 [ULA] Hinden, B., Haberman, B., "Unique Local IPv6
Addresses". Work in Progress. Addresses". RFC 4193 October 2005.
[RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 27]
an IPv6 Network without a Flag Day". Work in Progress.
[ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address 11.2 Non-Normative References
Allocations to Sites" RFC 3177 September 2001.
[NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation - [DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational
Protocol Translation (NAT-PT)" RFC 2766 February 2000 Considerations and Issues with IPv6 DNS", Work in
Progress.
[NATDE] Aoun, C., Davies, E., "Reasons to move NAT-PT to Experimental" [DSTM] Bound, J., (Ed) et al. "Dual Stack Transition
Work in Progress. Mechanim" Work in Progress.
[UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms [TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker with
for Unmanaged Networks". RFC 3904 September 2004. the Tunnel Setup Protocol". Work in Progress.
[ISPA] Lind, M., et al "Scenarios and Analysis for Introducing IPv6 [NATDE] Aoun, C., Davies, E., "Reasons to move NAT-PT to
into ISP Networks". RFC 4029 March 2005. Experimental" Work in Progress.
[3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks" [V6SEC] Davies, E. et al "IPv6 Transition/Co-existence
Work in Progress. Security Considerations". Work in Progress.
[V6SEC] Davies, E. et al "IPv6 Transition/Co-existence Security [NAP] Van de Velde, G. et al "IPv6 Network Architecture
Considerations". Work in Progress. Protection". Work in Progress.
[NAP] Van de Velde, G. et al "IPv6 Network Architecture Protection", Change Log
Work in Progress. July 2005 - February 2006
ID 03 to 04
[OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6" - Edits to document (minor).
RFC2740 December 1999.
BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol Extensions for - Removed any reference to DSTM as IETF supported mechanism.
BGP-4", RFC2283 June 2000.
[ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing Protocol", - Remove 8.4 Transition Mechanisms Recommendations.
RFC1142 February 1990.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 25]^L - Updated references move to RFC.
[RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC2080 January 1997
Change Log - Added Normative references.
June 2005 - to July 2005 June 2005 - to July 2005
ID 02 to 03 ID 02 to 03
- Fixed more IETF id-nits. - Fixed more IETF id-nits.
- Added Section 8.4 Transition Mechanism Summary - Added Section 8.4 Transition Mechanism Summary
analysis. analysis.
March 2005 to June 2005 March 2005 to June 2005
ID 01 to 02 ID 01 to 02
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 28]
- Fixed IETF id-nits. - Fixed IETF id-nits.
- Updated Section 3 Table 1 and added discussion of intent and - Updated Section 3 Table 1 and added discussion of intent and
scenario analysis per WG input. scenario analysis per WG input.
- Completed sections 6, 7, and 8. - Completed sections 6, 7, and 8.
- Completed required Security Section. - Completed required Security Section.
- Fixed normative vs. non-normative references. - Fixed normative vs. non-normative references.
skipping to change at line 1199 skipping to change at line 1193
IP layer networks and nodes. IP layer networks and nodes.
- Removed Table of Content Campus VLAN appendix place holder. - Removed Table of Content Campus VLAN appendix place holder.
November 2004 to March 2005 November 2004 to March 2005
ID 00 to 01 ID 00 to 01
- Changed introduction, Section 1-3 to reflect authors and IETF WG - Changed introduction, Section 1-3 to reflect authors and IETF WG
discussions to attempt consensus on these initial sections. discussions to attempt consensus on these initial sections.
- Added explanation of why Appendix A is in the document to - Added explanation of why Appendix A is in the document to introduction.
introduction.
- Expanded what topics are out of scope for this document. - Expanded what topics are out of scope for this document.
- Updated terminology section. - Updated terminology section.
- Updated section 3 matrix and description to simplify and focus - Updated section 3 matrix and description to simplify and focus
on dual IP layer. on dual IP layer.
- Edited base text of Sections 4-7 but all three require extensive - Edited base text of Sections 4-7 but all three require extensive
additional test for descriptions. additional test for descriptions.
- Edited section 8 and removed table and will reference table in - Edited section 8 and removed table and will reference table in
section 3. This section still needs to be written. section 3. This section still needs to be written.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 26]^L
Document Acknowledgments Document Acknowledgments
The Author's would like to acknowledge contributions from the The Author's would like to acknowledge contributions from the
following: IETF v6ops Working Group members, Pekka Savola, and following: IETF v6ops Working Group members, Pekka Savola, and
Jordi Palet. Jordi Palet.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 27]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 29]
Author's Addresses Author's Addresses
Jim Bound Jim Bound
HP HP
110 Spitbrook Road 110 Spitbrook Road
Nashua, NH 03062 Nashua, NH 03062
USA USA
Phone: 603.465.3130 Phone: 603.465.3130
Email: jim.bound@hp.com Email: jim.bound@hp.com
skipping to change at line 1266 skipping to change at line 1257
Email: david.green@sri.com Email: david.green@sri.com
Steve Klynsma Steve Klynsma
The MITRE Corporation The MITRE Corporation
7515 Colshire Drive 7515 Colshire Drive
McLean, VA 22102-5708 McLean, VA 22102-5708
USA USA
703-883-6469 703-883-6469
Email: sklynsma@mitre.org Email: sklynsma@mitre.org
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 28]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 30]
Copyright (C) The Internet Society (2005) Copyright (C) The Internet Society (2006)
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
skipping to change at line 1312 skipping to change at line 1303
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 31]
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 29]^L
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 30]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 32]
Appendix A - Crisis Management Network Scenarios Appendix A - Crisis Management Network Scenarios
Introduction: 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 service. Then, the scenarios for introducing IPv6 are analyzed IPv4 service. Then, the scenarios for introducing IPv6 are analyzed
and the relevance of already defined transition mechanisms are and the relevance of already defined transition mechanisms are
skipping to change at line 1383 skipping to change at line 1373
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 to interoperate with other institutions that are using IPv6 ability to interoperate with other institutions that are using IPv6
services. The IPv6 deployment is limited to the minimum required to services. The IPv6 deployment is limited to the minimum required to
operate this set of applications. operate 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.
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 33]
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 and network infrastructure. Enterprise with an existing IPv4 hosts and network infrastructure. Enterprise with an existing IPv4
network wants to deploy IPv6 in conjunction with their IPv4 network network wants to deploy IPv6 in conjunction with their IPv4 network
in order to take advantage of emerging IPv6 network-centric in order to take advantage of emerging IPv6 network-centric
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 31]^L
capabilities and to be interoperable with other agencies, capabilities and to be interoperable with other agencies,
international partners, and commercial enterprises that are international partners, and 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 capability in IPv6. equivalent 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
skipping to change at line 1429 skipping to change at line 1418
to be interoperable with it's own legacy networks, commercial to be interoperable with it's own legacy networks, commercial
networks, and the legacy networks of similar organizations that networks, and the legacy networks of similar organizations that
will remain IPv4 dominant during a long transition period. Reserve will remain IPv4 dominant during a long transition period. Reserve
units, contractors, other agencies, and international partners may units, contractors, other agencies, and international partners may
need IPv4 service across this enterprise's IPv6 dominant backbone. need IPv4 service across this enterprise's 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
increase
net-centricity through aggressive IPv6 transition. Interoperation net-centricity through aggressive IPv6 transition. Interoperation
and coexistence with legacy IPv4 networks and applications is and coexistence with legacy IPv4 networks and applications is
required. Legacy IPv4 nodes/applications/networks will need to be required. Legacy IPv4 nodes/applications/networks will need to be
able to operate across the IPv6 backbone and need to be able to able to operate across the IPv6 backbone and need to be able to
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 34]
interoperate with the IPv6-dominant network's nodes/applications. interoperate with the IPv6-dominant network's nodes/applications.
Description of a Generic Crisis Management Network Description of a Generic Crisis Management Network
A generic network topology for a crisis management reflects the A generic network topology for a crisis management reflects the
various ways a crisis management network can connect customers various ways a crisis management network can connect customers
through their network infrastructure. Because the institution's through their network infrastructure. Because the institution's
existing wired and fixed site wireless infrastructure can be existing wired and fixed site wireless infrastructure can be
destroyed or unavailable in a crisis, the crisis management network destroyed or unavailable in a crisis, the crisis management network
must be able to deploy it's own mobile wireless network or connect must be able to deploy it's own mobile wireless network or connect
through external wired and wireless networks provided by ISPs or through external wired and wireless networks provided by ISPs or
partner organizations. This infrastructure lets us divide the partner organizations. This infrastructure lets us divide the
basic areas for IPv4/IPv6 interoperability into three main areas: basic areas for IPv4/IPv6 interoperability into three main areas:
the customer applications, the local network, and the network the customer applications, the local network, and the network
backbone. backbone.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 32]^L
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 / : --------------------- Network Backbone
Backbone -------------- /------|-------------|--------------------------------
--------------
/------|-------------|--------------------------------
---------- / ---------- ---------- ---------- / ---------- ----------
| Home |/ | Wireless | External |............. | Home |/ | Wireless | External |.............
| Base | | Mobile | |Untrusted |+--------- : | Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | : | Network | | Network | |Network | | :
---------- ---------- ---------- | : ---------- ---------- ---------- | :
| : : | : Local | : : | : Local Network
Network
-----:------------:--------------------------------------------------- -----:------------:---------------------------------------------------
| : : | : Customer | : : | : Customer Apps
Apps
+--------+ +--------+ +--------+ | : +--------+ +--------+ +--------+ | :
| | | | | | | : | | | | | | | :
|Customer| |Customer| |Customer|+----------- :.... |Customer| |Customer| |Customer|+----------- :....
| | | | | |.............. | | | | | |..............
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1: Crisis Management Network Topology. Figure 1: Crisis Management Network Topology.
Stages of IPv6 Deployment: Stages of IPv6 Deployment:
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 35]
The stages are derived from the generic description of scenarios The stages are derived from the generic description of scenarios
for crisis management networks in Section 2. Combinations of for crisis management networks in Section 2. Combinations of
different building blocks that constitute an crisis network different building blocks that constitute an crisis network
environment lead to a number of scenarios from which the network environment lead to a number of scenarios from which the network
engineers can choose. The scenarios most relevant to this document engineers can choose. The scenarios most relevant to this document
are those that maximize the network's ability to offer IPv6 to its are those that maximize the network's ability to offer IPv6 to its
customers in the most efficient and feasible way. The assumption in customers in the most efficient and feasible way. The assumption in
the first three stages the goal is to offer both IPv4 and IPv6 to the first three stages the goal is to offer both IPv4 and IPv6 to
the customer, and that in the distant future all IPv4 services will the customer, and that in the distant future all IPv4 services will
be eventually switched to IPv6. This document will cover be eventually switched to IPv6. This document will cover
skipping to change at line 1512 skipping to change at line 1497
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 current IPv4 network to provide IPv6 services via a dual-stack a 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 indicted 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
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 33]^L
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 v6 tunneling or translation mechanisms to the existing in v6 tunneling or translation mechanisms to the existing
configuration from stage 2. When designing a new network, if a new configuration from stage 2. When designing a new network, if a new
IPv6-only service is required, it can be implemented at a lower IPv6-only service is required, it can be implemented at a lower
cost jumping directly to stage 3/4 if there are only limited/no cost jumping directly to stage 3/4 if there are only limited/no
legacy concerns. legacy concerns.
Tunnels Dominant dual Full dual Stack Tunnels Dominant dual Full dual Stack
IPv4-only --> or limited --> stacking with --> everywhere, mostly --> IPv4-only --> or limited --> stacking with --> everywhere, mostly --> V6
V6 dual stacks transition v6 apps, some Only
dual stacks transition v6 apps, some
Only
Limited v6 mechanisms in v6 only nets with Limited v6 mechanisms in v6 only nets with
Applications backbone transition mechanisms Applications backbone transition mechanisms
pushed to legacy v4 pushed to legacy v4 nets
nets
Figure 2: Transition Path. Figure 2: Transition Path.
Stage 1 Scenario: Limited Launch Stage 1 Scenario: Limited Launch
The first stage begins with an IPv4-only network and IPv4 The first stage begins with an IPv4-only network and IPv4
customers. This is the most common case today and the natural customers. This is the most common case today and the natural
starting point for the introduction of IPv6. During this stage the starting point for the introduction of IPv6. During this stage the
enterprise begins to connect individual IPv6 applications run on enterprise begins to connect individual IPv6 applications run on
dual stacked hosts through host based tunneling using Tunnel dual stacked hosts through host based tunneling using Tunnel
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 36]
Broker, ISATAP, Teredo. Some early adopter networks are created for Broker, ISATAP, Teredo. Some early adopter networks are created for
pilot studies and networked together through configured tunnels and pilot studies and networked together through configured tunnels and
6to4. 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
skipping to change at line 1574 skipping to change at line 1556
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 IPv6 ready. is IPv6 ready.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 34]^L
Specialty legacy applications and wireless/satellite networks may Specialty legacy applications and wireless/satellite networks may
be especially slow to transition to IPv6 capability due to upgrade be 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 on legacy IPv4-only networks. The tunnels may provide relying on legacy IPv4-only networks. The tunnels may provide
host-based tunneling for individual customers or site-to-site host-based tunneling for individual customers or site-to-site
tunnels to connect small IPv6 domains through IPv4 only networks. tunnels to connect small IPv6 domains through IPv4 only networks.
If any new applications are IPv6-only rather than dual-stacked, and If any new applications are IPv6-only rather than dual-stacked, and
need to interact with IPv4-only legacy applications, translators need to interact with IPv4-only legacy applications, translators
will be used as a transition mechanism of last resort during this will be used as a transition mechanism of last resort during this
stage. stage.
Stage 3 Scenario: IPv6 Dominance Stage 3 Scenario: IPv6 Dominance
draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 37]
Stage 3 occurs when the majority of network services are being Stage 3 occurs when the majority of network services are being
provided by IPv6 so that most network traffic is dominantly IPv6 provided by IPv6 so that most network traffic is dominantly IPv6
and the net-centric benefits of IPv6 end-to-end communications, and the net-centric benefits of IPv6 end-to-end communications,
IPSEC based security, QOS, mobility, and autoconfiguration are IPSEC based security, QOS, mobility, and autoconfiguration are
realized. During this stage, some networks and applications will realized. During this stage, some networks and applications will
become native IPv6-only and will have to rely on transition become native IPv6-only and will have to rely on transition
mechanism for backwards compatibility with IPv4. The switch to mechanism for backwards compatibility with IPv4. The switch to
native IPv6 may be pursued to lower the operations and maintenance native IPv6 may be pursued to lower the operations and maintenance
cost of network operations and lower the performance overhead cost of network operations and lower the performance overhead
associated with running two stacks on networked systems. During associated with running two stacks on networked systems. During
skipping to change at line 1633 skipping to change at line 1615
end-user security such as host-based firewalls and virus checkers end-user security such as host-based firewalls and virus checkers
for IPv6 attacks. Police, homeland defense, and military crisis for IPv6 attacks. Police, homeland defense, and military crisis
management networks require especially high levels of security and management networks require especially high levels of security and
should begin creation and implementation of their specialized should begin creation and implementation of their specialized
security architectures as soon as they begin planning for IPv6 security architectures as soon as they begin planning for IPv6
transition. New IPv6 features such as MIPv6, stateless address transition. New IPv6 features such as MIPv6, stateless address
auto-assignment, and ubiquitous end-user IPSEC will likely not be auto-assignment, and ubiquitous end-user IPSEC will likely not be
compatible with current information-assurance tools that are simply compatible with current information-assurance tools that are simply
ported from IPv4 to a minimal IPv6 capability. A complete new ported from IPv4 to a minimal IPv6 capability. A complete new
security policy, architecture, and tools will most likely be security policy, architecture, and tools will most likely be
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 35]^L
required to realize the true net-centric benefits of IPv6 in crisis required to realize the true net-centric benefits of IPv6 in crisis
networks requiring high security. networks requiring high security.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 36]^L draft-ietf-v6ops-ent-analysis-04.txt Expires Aug 2006 [Page 38]
 End of changes. 128 change blocks. 
274 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/