draft-ietf-v6ops-ent-analysis-05.txt   draft-ietf-v6ops-ent-analysis-06.txt 
IPv6 Operations Working Group IPv6 Operations Working Group
Internet Draft Jim Bound Internet Draft Jim Bound
Document: draft-ietf-v6ops-ent-analysis-05.txt Yanick Pouffary Document: draft-ietf-v6ops-ent-analysis-06.txt Yanick Pouffary
Obsoletes: ietf-v6ops-ent-analysis-04.txt Hewlett-Packard Obsoletes: ietf-v6ops-ent-analysis-05.txt Hewlett-Packard
Expires: November 2006 Steve Klynsma Expires: December 2006 Steve Klynsma
MITRE MITRE
Tim Chown Tim Chown
University of Southampton University of Southampton
Dave Green Dave Green
SRI Command Information
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-05.txt> <draft-ietf-v6ops-ent-analysis-06.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 52 skipping to change at page 2, line 7
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-05.txt Expires Nov 2006 [Page 1]^L
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-05.txt Expires Nov 2006 [Page 2]^L
Table of Contents: Table of Contents:
1. Introduction................................................4 1. Introduction................................................4
2. Terminology.................................................6 2. Terminology.................................................7
3. Enterprise Matrix Analysis for Transition...................7 3. Enterprise Matrix Analysis for Transition...................8
4. Wide-Scale Dual-Stack Deployment Analysis..................11 4. Wide-Scale Dual-Stack Deployment Analysis..................12
4.1 Staged Dual-Stack Deployment...............................11 4.1 Staged Dual-Stack Deployment...............................12
4.2 Routing Capability Analysis for Dual-IP Deployment.........12 4.2 Routing Capability Analysis for Dual-IP Deployment.........13
4.2.1 IPv6 Routing Capability..................................12 4.2.1 IPv6 Routing Capability..................................13
4.2.2 IPv6 Routing Non-Capability..............................12 4.2.2 IPv6 Routing Non-Capability..............................14
4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............13 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............14
4.2.2.2 Deploy a parallel IPv6 infrastructure..................13 4.2.2.2 Deploy a parallel IPv6 infrastructure..................14
4.3 Remote IPv6 access to the enterprise.......................14 4.3 Remote IPv6 access to the enterprise.......................15
4.4 Other considerations.......................................14 4.4 Other considerations.......................................15
5. Sparse Dual-Stack Deployment Analysis......................15 5. Sparse Dual-Stack Deployment Analysis......................16
5.1 Internal versus External Tunnel End Point..................15 5.1 Internal versus External Tunnel End Point..................16
5.2 Manual versus Autoconfigured...............................16 5.2 Manual versus Autoconfigured...............................17
6. IPv6 Dominant Network Deployment Analysis..................17 6. IPv6 Dominant Network Deployment Analysis..................18
7. General Issues from Analysis...............................18 7. General Issues from Analysis...............................20
7.1 Staged Plan for IPv6 Deployment............................18 7.1 Staged Plan for IPv6 Deployment............................20
7.2 Network Infrastructure Requirements........................18 7.2 Network Infrastructure Requirements........................20
7.3 Stage 1: Initial connectivity steps........................18 7.3 Stage 1: Initial connectivity steps........................20
7.3.1 Obtaining external connectivity..........................18 7.3.1 Obtaining external connectivity..........................20
7.3.2 Obtaining global IPv6 address space......................18 7.3.2 Obtaining global IPv6 address space......................21
7.4 Stage 2: Deploying generic basic service components........19 7.4 Stage 2: Deploying generic basic service components........21
7.4.1 Developing an IPv6 addressing plan.......................19 7.4.1 Developing an IPv6 addressing plan.......................21
7.4.2 IPv6 DNS.................................................20 7.4.2 IPv6 DNS.................................................22
7.4.3 IPv6 Routing.............................................20 7.4.3 IPv6 Routing.............................................22
7.4.4 Configuration of Hosts...................................20 7.4.4 Configuration of Hosts...................................23
7.4.5 Security.................................................21 7.4.5 Security.................................................23
7.5 Stage 3: Widespread Dual-Stack deployment on-site..........22 7.5 Stage 3: Widespread Dual-Stack deployment on-site..........24
8. Applicable Transition Mechanisms...........................23 8. Applicable Transition Mechanisms...........................26
8.1 Recognizing Incompatible Network touchpoints...............23 8.1 Recognizing Incompatible Network touchpoints...............26
8.2 Recognizing Application incompatibilities..................24 8.2 Recognizing Application incompatibilities..................27
8.3 Using Multiple Mechanisms to Support IPv6 Transition.......25 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......28
9. Security Considerations....................................26 9. Security Considerations....................................29
10. IANA Considerations........................................26 10. IANA Considerations........................................29
11. References.................................................26 11. References.................................................29
11.1 Normative References......................................26 11.1 Normative References......................................29
11.2 Non-Normative References..................................28 11.2 Non-Normative References..................................31
Change Log.....................................................28 Change Log.....................................................32
Document Acknowledgments.......................................30 Document Acknowledgments.......................................34
Author's Addresses.............................................31 Author's Addresses.............................................35
Copyright (C) The Internet Society (2006)......................32 Copyright (C) The Internet Society (2006)......................36
Disclaimer.....................................................32 IPR Disclosure Acknowledgement.................................36
IPR Disclosure Acknowledgement.................................32 Disclaimer of validity.........................................36
Disclaimer of validity.........................................32 Acknowledgment.................................................37
Acknowledgment.................................................33 Appendix A - Crisis Management Network Scenarios...............38
Appendix A - Crisis Management Network Scenarios...............34
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 3]^L
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 159 skipping to change at page 5, line 5
providing a set of current transition mechanism recommendations for providing a set of current transition mechanism recommendations for
the notational network scenarios to support an enterprise planning the notational network scenarios to support an enterprise 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] or the use
the use of Provider Independent address space. of Provider Independent address space.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 4]^L
The following specific topics are currently out of scope for this The following specific topics are currently out of scope for this
document: document:
- Multihoming - Multihoming
- Application transition/porting (see [APPS]). - Application transition/porting (see [APPS]).
- IPv6 VPN, firewall or intrusion detection deployment - IPv6 VPN, firewall or intrusion detection deployment
- IPv6 network management and QoS deployment - IPv6 network management and QoS deployment
- Detailed IT Department requirements - Detailed IT Department requirements
- Deployment of novel IPv6 services, e.g. Mobile IPv6 - Deployment of novel IPv6 services, e.g. Mobile IPv6
- Requirements or Transition at the Providers network - Requirements or Transition at the Providers network
- Transport protocol selection for applications with IPv6 - Transport protocol selection for applications with IPv6
- Application layer and configuration issues. - Application layer and configuration issues.
- IPv6 only future deployment scenarios. - IPv6 only future deployment scenarios.
We are focusing in this document on IP Layer 3 deployment, in the 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
wire", including address management and DNS services. the wire", including address management and DNS services.
We are also assuming that the enterprise deployment is being We are also assuming that the enterprise deployment is being
undertaken by the network administration team, i.e. this document undertaken by the network administration team, i.e. this document
is not discussing the case of an individual user gaining IPv6 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
skipping to change at line 211 skipping to change at page 7, line 5
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. In addition we recommend readers of Sections 3, 4, 5, 6, and 7. In addition we recommend readers of
this document also read another use case document to support an this document also read another use case document to support an
IPv6 Transition for a Campus Network [CAMP]. IPv6 Transition for a Campus Network [CAMP].
Readers should also be aware a parallel effort for an enterprise to Readers should also be aware a parallel effort for an enterprise to
transition to IPv6 is training, but out of scope for this document. transition to IPv6 is training, but out of scope for this document.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 5]^L
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
other private external networks for the other private external networks for the
skipping to change at line 235 skipping to change at page 7, line 27
IPv6-capable - A node or network capable of supporting both IPv6-capable - A node or network capable of supporting both
IPv6 and IPv4. IPv6 and IPv4.
IPv4-only - A node or network capable of supporting only IPv4-only - A node or network capable of supporting only
IPv4. IPv4.
IPv6-only - A node or network capable of supporting only IPv6-only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only IPv6. This does not imply an IPv6 only
stack, in this document. stack, in this document.
Dual-IP - References a network or node that supports both Dual-IP - References a network or node that supports
IPv4 and IPv6. both 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 running IPv6 routing and control plane IPv6-dominant - A network running IPv6 routing and control plane
services that provides transport for both IPv4 services that provides transport for both IPv4 and
and IPv6 protocol services. IPv6 protocol services
Transition - The network strategy the enterprise uses to Transition - The network strategy the enterprise uses to
Implementation transition to IPv6. Implementation transition to IPv6.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 6]^L
3. Enterprise Matrix Analysis for Transition 3. Enterprise Matrix Analysis for Transition
In order to identify the best suited transition mechanisms for an In order to identify the best suited transition mechanisms for an
enterprise, it is recommended that the enterprise have an in-depth enterprise, it is recommended that the enterprise have an in-depth
up-to-date understanding of its current IT environment. This up-to-date understanding of its current IT environment. This
understanding will help choose the best suited transition understanding will help choose the best suited transition
mechanisms. It is important to note that one size does not fit all. mechanisms. It is important to note that one size does not fit all.
While selecting a mechanism it is suggested to select mechanisms While selecting a mechanism it is suggested to select mechanisms
which reduce the impact on the existing environment. When selecting which reduce the impact on the existing environment. When selecting
a transition mechanism one must consider the functionality a transition mechanism one must consider the functionality
skipping to change at line 280 skipping to change at page 8, line 35
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
IP-capability, than other intranetworks, at certain times in the IP-capability, than other intranetworks, at certain times in the
transition period. transition period.
Addressing every possible combination of network IP-capability in Addressing every possible combination of network IP-capability in
this notional enterprise network is impractical, therefore trivial this notional enterprise network is impractical, therefore trivial
(i.e. pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not (i.e. pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not
considered. In addition, the authors could not conceive of any considered. In addition, the authors could not conceive of any
scenarios involving IPv6-only ISPs or IPv6-only nodes in the near- scenarios involving IPv6-only ISPs or IPv6-only nodes in the near
term and consequently have not addressed scenarios with IPv6-only term and consequently have not addressed scenarios with IPv6-only
ISPs or IPv6-only nodes. We assume all nodes that host IPv6 ISPs or IPv6-only nodes. We assume all nodes that host IPv6
applications are Dual IP. The matrix does not assume or suggest applications are Dual IP. The matrix does not assume or suggest
that network address translation is used. The authors recommend that network address translation is used. The authors recommend
that network address translation not be used in these notional that network address translation not be used in these notional
cases. cases.
Future enterprise transitions that support IPv6-only nodes and Future enterprise transitions that support IPv6-only nodes and
IPv6-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-05.txt Expires Nov 2006 [Page 7]^L
- 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
skipping to change at line 337 skipping to change at page 10, line 5
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-05.txt Expires Nov 2006 [Page 8]^L
Table 1 - Enterprise Scenario Deployment Matrix Table 1 - Enterprise Scenario Deployment Matrix
====================================================== ======================================================
|Application |Host 1 |Service |Host 2 |Application | |Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- | |----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS | | Host 1 OS | | | | Host 2 OS |
=====================================+================ =====================================+================
| IPv6 | |Dual IP | | IPv6 | | IPv6 | |Dual IP | | IPv6 |
A | ---- | IPv4 | or |Dual IP| ---- | A | ---- | IPv4 | or |Dual IP| ---- |
| Dual IP | | IPv4 | | Dual IP | | Dual IP | | IPv4 | | Dual IP |
skipping to change at line 385 skipping to change at page 11, line 4
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ======================================================
| IPv4 | | | | IPv6 | | IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- | I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv4 | | IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- | J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ======================================================
The reader should note that scenarios A-C in Table 1 are variations The reader should note that scenarios A-C in Table 1 are variations
of compatible hosts communicating across largely (but not entirely) of compatible hosts communicating across largely (but not entirely)
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 9]^L
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 its 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
application. application.
skipping to change at line 422 skipping to change at page 12, line 5
it maintains a variety of heterogeneous network segments between it maintains a variety of heterogeneous network segments between
the communicating applications. Scenarios E and J represent the communicating applications. Scenarios E and J represent
distinctly different extremes on either end of the spectrum. In distinctly different extremes on either end of the spectrum. In
scenario E, the enterprise has largely transitioned to IPv6 in both scenario E, the enterprise has largely transitioned to IPv6 in both
its 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-05.txt Expires Nov 2006 [Page 10]^L
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
skipping to change at line 472 skipping to change at page 13, line 7
specifically should not have IPv6 connectivity (e.g. Scenario A of specifically should not have IPv6 connectivity (e.g. Scenario A of
Table 1). There may also be a requirement that aggregatable global Table 1). There may also be a requirement that aggregatable global
IPv6 addresses, assigned by the enterprise's upstream provider from IPv6 addresses, assigned by the enterprise's upstream provider from
the address space allocated to them by the Regional Internet the address space allocated to them by the Regional Internet
Registries (RIRs), be assigned. Registries (RIRs), be assigned.
In this document we do not discuss the deployment of Unique Local In this document we do not discuss the deployment of Unique Local
IPv6 Unicast Addresses [ULA] because the address type and scope IPv6 Unicast Addresses [ULA] because the address type and scope
selected is orthogonal to the layer 3 analysis of this document. selected is orthogonal to the layer 3 analysis of this document.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 11]^L
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.
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
skipping to change at line 518 skipping to change at page 14, line 14
4.2.2 IPv6 Routing Non-Capability 4.2.2 IPv6 Routing Non-Capability
If the enterprise cannot provide IPv6 routing initially there are If the enterprise cannot provide IPv6 routing initially there are
alternative methods for transition. In this case the enterprise alternative methods for transition. In this case the enterprise
administrator faces two basic choices, either to tunnel IPv6 over administrator faces two basic choices, either to tunnel IPv6 over
some or all of the existing IPv4 infrastructure, or to deploy a some or all of the existing IPv4 infrastructure, or to deploy a
parallel IPv6 routing infrastructure providing IPv6 connectivity parallel IPv6 routing infrastructure providing IPv6 connectivity
into existing IPv4 subnets. into existing IPv4 subnets.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 12]^L
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
skipping to change at line 564 skipping to change at page 15, line 16
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-05.txt Expires Nov 2006 [Page 13]^L
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. Such remote support might for example be offered by support. Such remote support might for example be offered by
deployment of an IPv6 Tunnel Broker [TBRK]. deployment of an IPv6 Tunnel Broker [TBRK].
4.4 Other considerations 4.4 Other considerations
There are some issues associated with turning IPv6 on by default, There are some issues associated with turning IPv6 on by default,
including application connection delays, poor connectivity, and including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF] worked around or mitigated by following the advice in [V6DEF]
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 14]^L
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
the prerequisite is that only the nodes using those IPv6 the prerequisite is that only the nodes using those IPv6
skipping to change at line 633 skipping to change at page 17, line 7
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-05.txt Expires Nov 2006 [Page 15]^L
border router that connects to the upstream Provider. In this case, border router that connects to the upstream Provider. In this case,
intranetnetworks communication using this tunnel end point is also intranetnetworks communication using this tunnel end point is also
possible. possible.
5.2 Manual versus Autoconfigured 5.2 Manual versus Autoconfigured
If the number of nodes to be using IPv6 is low, the first option is If the number of nodes to be using IPv6 is low, the first option is
to use statically configured tunnels. However, automatically to use statically configured tunnels. However, automatically
configured tunnels may be preferable, especially if the number is configured tunnels may be preferable, especially if the number is
higher. higher.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 16]^L
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 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 [V6TUN]. An edge
router within the IPv6-dominant network will decapsulate the IPv4 router within the IPv6-dominant network will decapsulate the IPv4
packet and route to the path of the IPv4 node on the network. This packet and route to the path of the IPv4 node on the network. This
permits Dual-IP layer nodes to communicate with legacy IPv4 nodes permits Dual-IP layer nodes to communicate with legacy IPv4 nodes
within an IPv6-dominant network. within an IPv6-dominant network.
From Table 1 scenarios E and F depict additional cases where an 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
skipping to change at line 698 skipping to change at page 20, line 5
While retaining interoperability with IPv4 is a noble goal for While retaining interoperability with IPv4 is a noble goal for
Enterprise architects, it is an unfortunate fact that maintaining Enterprise architects, it is an unfortunate fact that maintaining
IPv4 services in an IPv6-dominant network slows and may even impede IPv4 services in an IPv6-dominant network slows and may even impede
your ability to reap the maximum benefits of IPv6. your ability to reap the maximum benefits of IPv6.
The decision whether or not to use an IPv6-dominant network The decision whether or not to use an IPv6-dominant network
deployment strategy is completely driven by the Enterprise's deployment strategy is completely driven by the Enterprise's
business 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-05.txt Expires Nov 2006 [Page 17]^L
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
points and components of the transition. points and components of the transition.
skipping to change at line 739 skipping to change at page 21, line 11
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-05.txt Expires Nov 2006 [Page 18]^L
The enterprise should receive at least a /48 allocation from its The enterprise should receive at least a /48 allocation from its
provider, as described in [ALLOC]. provider, as described in [ALLOC].
Should an enterprise change their provider, a procedure for Should an enterprise change their provider, a procedure for
enterprise renumbering between providers is described in [RENUM]. enterprise renumbering between providers is described in [RENUM].
7.4 Stage 2: Deploying generic basic service components 7.4 Stage 2: Deploying generic basic service components
Most of these are discussed in Section 4 of [BSCN]. Here we comment Most of these are discussed in Section 4 of [BSCN]. Here we comment
on those aspects that we believe are in scope for this analysis on those aspects that we believe are in scope for this analysis
skipping to change at line 786 skipping to change at page 22, line 14
With IPv6, a link can in effect have any number of nodes, allowing With IPv6, a link can in effect have any number of nodes, allowing
link growth without the need to adjust prefix allocations with the link growth without the need to adjust prefix allocations with the
associated renumbering requirement. The size of the initial site associated renumbering requirement. The size of the initial site
allocation (currently recommended to be a /48) also is likely to allocation (currently recommended to be a /48) also is likely to
allow room for site growth without a need to return to the allow room for site growth without a need to return to the
connectivity provider to obtain more, potentially non-sequential, connectivity provider to obtain more, potentially non-sequential,
address space (as is the case for IPv4 today, with the associated address space (as is the case for IPv4 today, with the associated
paperwork and probable delays). paperwork and probable delays).
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 19]^L
At the time of writing, best practice in IPv6 site address planning At the time of writing, best practice in IPv6 site address planning
is restricted due to limited wide-scale deployments. Administrators is restricted due to limited wide-scale deployments. Administrators
should allocate /64 size prefixes for subnets, and do so in a way should allocate /64 size prefixes for subnets, and do so in a way
that has scope for growth within a site. The site should utilize a that has scope for growth within a site. The site should utilize a
plan that reserves space for topological growth in the site, given plan that reserves space for topological growth in the site, given
that its initial IPv6 prefix allocation (currently recommended to that its initial IPv6 prefix allocation (currently recommended to
be a /48) is likely to include such room for growth. Also see IPv6 be a /48) is likely to include such room for growth. Also see IPv6
unicast address assignments document in process [UNAD]. unicast address assignments document in process [UNAD].
7.4.2 IPv6 DNS 7.4.2 IPv6 DNS
The enterprise site should deploy a DNS service that is capable of The enterprise site should deploy a DNS service that is capable of
both serving IPv6 DNS records using the AAAA format [DNSV6REC] and both serving IPv6 DNS records using the AAAA format [DNSV6R] and of
of communicating over IPv6 transport. communicating over IPv6 transport.
Specific IPv6 DNS issues are reported in [DNSV6]. Specific IPv6 DNS issues are reported in [DNSOP6].
7.4.3 IPv6 Routing 7.4.3 IPv6 Routing
The enterprise network will need to support methods for internal The enterprise network will need to support methods for internal
and external routing. and external routing.
For a single-homed single-site network, a static route to a single For a single-homed single-site network, a static route to a single
upstream provider may be sufficient, although the site may choose upstream provider may be sufficient, although the site may choose
to use an exterior routing protocol, especially where it has to use an exterior routing protocol, especially where it has
multiple upstream providers. multiple upstream providers.
skipping to change at line 826 skipping to change at page 23, line 12
follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng
[RIPng]. [RIPng].
7.4.4 Configuration of Hosts 7.4.4 Configuration of Hosts
An enterprise network will have a number of tools available for An enterprise network will have a number of tools available for
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
[DHCPv4]. [DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF]
[ADDRCONF] may be used to configure a host with a global IPv6 may be used to configure a host with a global IPv6 address, a
address, a default router, and an on-link prefix information. 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
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 20]^L
[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. Where offlink, a DHCPv6 Relay Agent function will be required. Where
DHCPv4 and DHCPv6 service are deployed together, dual-stack DHCPv4 and DHCPv6 service are deployed together, dual-stack
considerations need to be made, as discussed within current work on considerations need to be made, as discussed within current work on
skipping to change at line 881 skipping to change at page 24, line 19
Where deployed, intrusion detection systems will need to be Where deployed, intrusion detection systems will need to be
enhanced to both check IPv6 transport for known application layer enhanced to both check IPv6 transport for known application layer
attack patterns and also to check for new potential IPv6 threats, attack patterns and also to check for new potential IPv6 threats,
e.g. excessive hop-by-hop headers, or errant IPv6 header options. e.g. excessive hop-by-hop headers, or errant IPv6 header options.
The deployment of specific transition mechanisms may also introduce The deployment of specific transition mechanisms may also introduce
threats, e.g. carrying IPv6 data tunnelled in IPv4. The site threats, e.g. carrying IPv6 data 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.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 21]^L
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.
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
skipping to change at line 920 skipping to change at page 26, line 5
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
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-05.txt Expires Nov 2006 [Page 22]^L
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
architect might encounter as they consider how and where they architect might encounter as they consider how and where they
skipping to change at line 964 skipping to change at page 26, line 47
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 tunnel 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 then host tunneling is appropriate. If the network is incompatible then host tunneling is appropriate. If the
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 23]^L
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
requires some form of tunneling. Where configured tunnels are not requires some form of tunneling. Where configured tunnels are not
sufficient a more automatic solution may be appropriate. Available sufficient a more automatic solution may be appropriate. Available
solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6
end service. ISATAP [ISTP] can be used to provide end node IPv6 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. Teredo [TRDO] can be use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be
used when the enterprise network is behind a NAT. 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 [6TO4], or
Tunnel Brokers can automate the use of tunnels across an enterprise DSTM [DSTM]. Tunnel Brokers can automate the use of tunnels across
deploying IPv6. an enterprise deploying IPv6.
Later in the transition process, after the enterprise has Later in the transition process, after the enterprise has
transitioned to a predominately IPv6 infrastructure, the architect transitioned to a predominately IPv6 infrastructure, the architect
will need to determine a network transition strategy to tunnel IPv4 will need to determine a network transition strategy to tunnel IPv4
within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise
Intranet. Or in the case of early deployment of IPv6-dominant Intranet. Or in the case of early deployment of IPv6-dominant
networks the architect will need to address this from the beginning networks the architect will need to address this from the beginning
of the required transition planning. The deployment methodology of the required transition planning. The deployment methodology
for an architect to design IPv6-dominant networks is under study for an architect to design IPv6-dominant networks is under study
currently, two work in progress reference points that can be used currently, two work in progress reference points that can be used
skipping to change at line 1020 skipping to change at page 28, line 11
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-05.txt Expires Nov 2006 [Page 24]^L
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 simultaneously (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 simultaneously service both IPv4 and IPv6 data streams that are simultaneously
tunneled through incompatible network segment(s). tunneled through incompatible network segment(s).
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 25]^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
[CONF] Thomson, S., Narten, T., "IPv6 Stateless [CONF] Thomson, S., Narten, T., "IPv6 Stateless
Autoconfiguration" RFC 2462 December 1998. Autoconfiguration" RFC 2462 December 1998.
[DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T.,
"Dynamic Host Configuration Protocol for IPv6 et al. "Dynamic Host Configuration Protocol
(DHCPv6)" RFC 3315 July 2003. for IPv6 (DHCPv6)" RFC 3315 July 2003.
[DHCPL] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6"
RFC 3756 April 2004.
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6 [6TO4] Carpenter, B., Moore, K., "Connection of IPv6
Domains via IPv4 Clouds" RFC 3056 February 2001. Domains via IPv4 Clouds" RFC 3056 February 2001.
[BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network [BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network
Scenarios" RFC 4057 June 2005. Scenarios" RFC 4057 June 2005.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP
through NATs" RFC 4380. through NATs" RFC 4380.
[ISTP] Templin, F., et al "Intra-Site Automatic Tunnel [ISTP] Templin, F., et al "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)". RFC 4214 October 2005. Addressing Protocol (ISATAP)".
RFC 4214 October 2005.
[6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in [V6TUN] Conta, A., Deering, S., "Generic Packet Tunneling
IPv6" RFC 2473 December 1998. in IPv6" RFC 2473 December 1998.
[TBRK] Durand, A., et al "IPv6 Tunnel Broker" [TBRK] Durand, A., et al "IPv6 Tunnel Broker"
RFC 3053 January 2001. RFC 3053 January 2001.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 26]^L [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6
[ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Address Allocations to Sites"
Allocations to Sites" RFC 3177 September 2001. RFC 3177 September 2001.
[NATPT] Tsirtsis, G., Srisuresh, P., "Network Address [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address
`Translation - Protocol Translation (NAT-PT)" `Translation - Protocol Translation (NAT-PT)"
RFC 2766 February 2000 RFC 2766 February 2000
[UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition [UMAN] Huitema, C.,. et al "Evaluation of IPv6
Mechanisms for Unmanaged Networks". Transition Mechanisms for Unmanaged Networks".
RFC 3904 September 2004. RFC 3904 September 2004.
[ISPA] Lind, M., et al "Scenarios and Analysis for [ISPA] Lind, M., et al "Scenarios and Analysis for
Introducing IPv6 into ISP Networks". Introducing IPv6 into ISP Networks".
RFC 4029 March 2005. RFC 4029 March 2005.
[3GPA] Wiljakka, J., "Analysis on IPv6 Transition in [3GPA] Wiljakka, J., "Analysis on IPv6 Transition in
3GPP Networks" RFC 4215 October 2005. 3GPP Networks" RFC 4215 October 2005.
[OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6" [OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for
RFC2740 December 1999. IPv6" RFC2740 December 1999.
[BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol [BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol
Extensions for BGP-4", RFC2858 June 2000. Extensions for BGP-4", RFC2858 June 2000.
[ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing [ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain
Protocol", RFC1142 February 1990. Routing Protocol", RFC1142 February 1990.
[RIPng] Malkin, G., Minnear, R. "RIPng for IPv6" [RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC2080 January 1997 RFC2080 January 1997
[APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P.,
Castro, E., "Application Aspects of IPv6 Transition" Castro, E., "Application Aspects of IPv6
RFC 4038 March 2005. Transition" RFC 4038 March 2005.
[RENUM] Baker, F., Lear, E., Droms, R., "Procedures for [RENUM] Baker, F., Lear, E., Droms, R., "Procedures for
Renumbering an IPv6 Network without a Flag Day". Renumbering an IPv6 Network without a Flag Day".
RFC 4192 September 2005. RFC 4192 September 2005.
[BCNF] Nordmark, E., Gilligan, R., "Basic Transition [BCNF] Nordmark, E., Gilligan, R., "Basic Transition
Mechanisms for IPv6 Hosts and Routers" Mechanisms for IPv6 Hosts and Routers"
RFC 4213 October 2005 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". RFC 4193 October 2005. Addresses". RFC 4193 October 2005.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 27]^L [DNSOP6] Durand, A., Ihren, J. and P. Savola,
"Operational Considerations and Issues with
IPv6 DNS". RFC 4472 April 2006.
11.2 Non-Normative References [DNSV6R] Thomson, S., Huitema, C., et al "DNS
Extensions to Support IP Version 6".
RFC 3596 October 2003.
[DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational [NIS] Kalusivalingam. V, "Network Information
Considerations and Issues with IPv6 DNS", Work in Service (NIS) Configuration Options for D
Progress. HCPv6. RFC 3898 October 2004.
[DHCPv4] Droms, R., "Dynamic Host Configuration
Protocol" RFC 2131 March 1997.
[IPSEC] Eastlake. D., "Cryptographic Algorithm
Implementation Requirements for Encapsulating
Security Payload (ESP) and Authentication
Header (AH)". RFC 4305 December 2005.
[SEND] Arkko, J. et al. "Secure Neighbor Discovery
(SEND)". RFC 3971 March 2005.
[PRIVv6] Narten, T., Draves, R., "Privacy Extensions
for Stateless Address Autoconfiguration in
IPv6. RFC 3041 January 2001.
11.2 Non-Normative References
[DSTM] Bound, J., (Ed) et al. "Dual Stack Transition [DSTM] Bound, J., (Ed) et al. "Dual Stack Transition
Mechanim" Work in Progress. Mechanim" Work in Progress.
[TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker with [TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker
the Tunnel Setup Protocol". Work in Progress. with the Tunnel Setup Protocol".
Work in Progress.
[NATDE] Aoun, C., Davies, E., "Reasons to move NAT-PT to
Experimental" Work in Progress.
[V6SEC] Davies, E. et al "IPv6 Transition/Co-existence [V6SEC] Davies, E. et al "IPv6 Transition/Co-existence
Security Considerations". Work in Progress. Security Considerations". Work in Progress.
[NAP] Van de Velde, G. et al "IPv6 Network Architecture [NAP] Van de Velde, G. et al "IPv6 Network
Protection". Work in Progress. Architecture Protection". Work in Progress.
[CAMP] Chown, T., "IPv6 Campus Transition Scenario [CAMP] Chown, T., "IPv6 Campus Transition Scenario
Description and Analysis". Work in Progress. Description and Analysis". Work in Progress.
[DHDS] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack Issues", [DHDS] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack
Issues", Work in Progress.
[UNAD] Van de Velde, G., Popoviciu, C., Chown, T.,
"IPv6 Unicast Address Assignment".
Work in Progress. Work in Progress.
[UNAD] Van de Velde, G., Popoviciu, C., Chown, T., "IPv6 [VLAN] Chown, T. "Use of VLANs for IPv4-IPv6
Unicast Address Assignment Considerations". Coexistence in Enterprise Networks".
Work in Progress. Work in Progress.
[V6DEF] Roy, S., Durand, A., Paugh, J., "IPv6 Neighbor
Discovery On-Link Assumption Considered
Harmful". Work in Progress.
Change Log Change Log
ID 05 - 06
- Fix ID Nits for IESG
ID 04 to 05 ID 04 to 05
- Edits: Intro, Sections 4 and 7, References - Edits: Intro, Sections 4 and 7, References
- Update definition IPv6-Dominant - Update definition IPv6-Dominant
- Add Campus Deployment Reference - Add Campus Deployment Reference
- Fix ID-Nits - Fix ID-Nits
July 2005 - February 2006 July 2005 - February 2006
ID 03 to 04 ID 03 to 04
- Edits to document (minor). - Edits to document (minor).
- Removed any reference to DSTM as IETF supported mechanism. - Removed any reference to DSTM as IETF supported mechanism.
- Remove 8.4 Transition Mechanisms Recommendations. - Remove 8.4 Transition Mechanisms Recommendations.
- Updated references move to RFC. - Updated references move to RFC.
- Added Normative references.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 28]^L - Added Normative references.
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.
ID 01 to 02 ID 01 to 02
- 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.
- Changed abstract and context of document to only deal with dual - Changed abstract and context of document to only deal with dual
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.
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-05.txt Expires Nov 2006 [Page 29]^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, Fred Baker, Pekka following: IETF v6ops Working Group members, Fred Baker, Pekka
Savola, and Jordi Palet. Savola, and Jordi Palet
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 30]^L
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 1249 skipping to change at page 35, line 31
Email: Yanick.pouffary@hp.com Email: Yanick.pouffary@hp.com
Tim Chown Tim Chown
School of Electronics and Computer Science School of Electronics and Computer Science
University of Southampton University of Southampton
Southampton SO17 1BJ Southampton SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
David Green David Green
SRI International Command Information
333 Ravenswood Ave 13655 Dulles Technology Drive
Menlo Park, CA 94025-3493 Suite 500
Herndon, VA 20171
USA USA
Phone: 732 532-6715 Phone: 703.561.5937
Email: david.green@sri.com Email: green@commandinformation.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-05.txt Expires Nov 2006 [Page 31]^L
Copyright (C) The Internet Society (2006) 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
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
IPR Disclosure Acknowledgement IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Disclaimer of validity Disclaimer of validity
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-05.txt Expires Nov 2006 [Page 32]^L
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
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-05.txt Expires Nov 2006 [Page 33]^L
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
evaluated. Known challenges are also identified. evaluated. Known challenges are also identified.
skipping to change at line 1368 skipping to change at page 38, line 42
and points out the lack of essential functionality in these methods and points out the lack of essential functionality in these methods
to the ISP's operation of an IPv6 service. to the ISP's operation of an IPv6 service.
The document is focused on services that include both IPv6 and IPv4 The document is focused on services that include both IPv6 and IPv4
and does cover issues surrounding accessing IPv4 services across and does cover issues surrounding accessing IPv4 services across
IPv6-only networks. It is outside the scope of this document to IPv6-only networks. It is outside the scope of this document to
describe detailed implementation plans for IPv6 in defense networks describe detailed implementation plans for IPv6 in defense networks
Scenarios for IPv6 Deployment in Crisis Management Networks: Scenarios for IPv6 Deployment in Crisis Management Networks:
Scenario 1: Limited IPv6 Deployment Network. Scenario 1: Limited IPv6 Deployment Network.....................
Sparse IPv6 dual-stack deployment in an existing IPv4 network Sparse IPv6 dual-stack deployment in an existing IPv4 network
infrastructure. Enterprise with an existing IPv4 network wants to infrastructure. Enterprise with an existing IPv4 network wants to
deploy a set of particular IPv6 "applications" and have some deploy a set of particular IPv6 "applications" and have some
ability 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-05.txt Expires Nov 2006 [Page 34]^L
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
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
skipping to change at line 1430 skipping to change at page 40, line 10
Assumptions: Required IPv6 network infrastructure is available, or Assumptions: Required IPv6 network infrastructure is available, or
available over some defined timeline, supporting the aggressive available over some defined timeline, supporting the aggressive
transition plan. transition plan.
Requirements:Reduce operation and maintenance requirements and Requirements:Reduce operation and maintenance requirements and
increase net-centricity through aggressive IPv6 transition. increase net-centricity through aggressive IPv6 transition.
Interoperation and coexistence with legacy IPv4 networks and Interoperation and coexistence with legacy IPv4 networks and
applications is required. Legacy IPv4 nodes/applications/networks applications is required. Legacy IPv4 nodes/applications/networks
will need to be able to operate across the IPv6 backbone and need will need to be able to operate across the IPv6 backbone and need
to be able to to be able to interoperate with the IPv6-dominant network's
nodes/applications.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 35]^L
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 basic areas for IPv4/IPv6 interoperability into three main areas:
areas: the customer applications, the local network, and the the customer applications, the local network, and the network
network backbone. backbone.
The basic components in a crisis management network are depicted in The basic components in a crisis management network are depicted in
Figure 1. Figure 1.
------------ ---------- ---- Wired Connection ------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection | Network and| | | .... Wireless Connection
| Service |--| Backbone | | Service |--| Backbone |
| Operation | | | | Operation | | |
------------ ---------- ------------ ----------
/ | --------------------- / | ---------------------
skipping to change at line 1483 skipping to change at page 41, line 15
+--------+ +--------+ +--------+ | : +--------+ +--------+ +--------+ | :
| | | | | | | : | | | | | | | :
|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-05.txt Expires Nov 2006 [Page 36]^L
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 1516 skipping to change at page 41, line 47
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
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 Full dual Stack
v4-only-> or limited-> dual stacking-> everywhere-> v6
dual stacks transition v6 apps, some only
Limited v6 mechanisms in v6 only nets with
Applications backbone transition mechanisms
pushed to legacy v4 nets
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-05.txt Expires Nov 2006 [Page 37]^L
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
networks over it's backbone and negotiate IPv6 service with its networks over it's backbone and negotiate IPv6 service with its
service providers and with peer organizations; it is of utmost service providers and with peer organizations; it is of utmost
importance to require IPv6 capability or an upgrade plan when importance to require IPv6 capability or an upgrade plan when
negotiating purchases of network applications and infrastructure. negotiating purchases of network applications and infrastructure.
In the short term, network connections, especially legacy wireless In the short term, network connections, especially legacy wireless
networks, that cannot provide IPv6 services can provide IPv6 networks, that cannot provide IPv6 services can provide IPv6
services through the use of tunnels. However, the longer-term goal services through the use of tunnels. However, the longer-term goal
skipping to change at line 1584 skipping to change at page 43, line 12
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
Applications are deployed specifically to use IPv6 as benefit, Applications are deployed specifically to use IPv6 as benefit, thus
thus network backbone and nodes use IPv6 and not IPv4, except network backbone and nodes use IPv6 and not IPv4, except where IPv4
where IPv4 is legacy. is legacy.
draft-ietf-v6ops-ent-analysis-05.txt Expires Nov 2006 [Page 38]^L
 End of changes. 100 change blocks. 
206 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/