draft-ietf-v6ops-ent-analysis-02.txt   draft-ietf-v6ops-ent-analysis-03.txt 
IPv6 Operations Working Group IPv6 Operations Working Group
Internet Draft Jim Bound Internet Draft Jim Bound
Document: draft-ietf-v6ops-ent-analysis-02.txt Yanick Pouffary Document: draft-ietf-v6ops-ent-analysis-03.txt Yanick Pouffary
Obsoletes: ietf-v6ops-ent-analysis-01.txt Hewlett-Packard Obsoletes: ietf-v6ops-ent-analysis-02.txt Hewlett-Packard
Expires: December 2005 Steve Klynsma Expires: January 2006 Steve Klynsma
MITRE MITRE
Tim Chown Tim Chown
University of Southhampton University of Southhampton
Dave Green Dave Green
SRI SRI
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-02.txt> <draft-ietf-v6ops-ent-analysis-03.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 page 2, line 5 skipping to change at line 54
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
environment, within the enterprise. Then a set of transition environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network. mechanisms are recommended for each notational network.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 1]^L
Table of Contents: Table of Contents:
1. Introduction................................................3 1. Introduction................................................3
2. Terminology.................................................5 2. Terminology.................................................5
3. Enterprise Matrix Analysis for Transition...................6 3. Enterprise Matrix Analysis for Transition...................6
4. Wide-Scale Dual-Stack Deployment Analysis..................10 4. Wide-Scale Dual-Stack Deployment Analysis..................10
4.1 Staged Dual-Stack Deployment...............................10 4.1 Staged Dual-Stack Deployment...............................10
4.2 Routing Capability Analysis for Dual-IP Deployment.........11 4.2 Routing Capability Analysis for Dual-IP Deployment.........11
4.2.1 IPv6 Routing Capability..................................11 4.2.1 IPv6 Routing Capability..................................11
4.2.2 IPv6 Routing Non-Capability..............................11 4.2.2 IPv6 Routing Non-Capability..............................11
skipping to change at page 2, line 34 skipping to change at line 85
7.1 Staged Plan for IPv6 Deployment............................16 7.1 Staged Plan for IPv6 Deployment............................16
7.2 Network Infrastructure Requirements........................16 7.2 Network Infrastructure Requirements........................16
7.3 Stage 1: Initial connectivity steps........................16 7.3 Stage 1: Initial connectivity steps........................16
7.3.1 Obtaining external connectivity..........................16 7.3.1 Obtaining external connectivity..........................16
7.3.2 Obtaining global IPv6 address space......................16 7.3.2 Obtaining global IPv6 address space......................16
7.4 Stage 2: Deploying generic basic service components........17 7.4 Stage 2: Deploying generic basic service components........17
7.4.1 IPv6 DNS.................................................17 7.4.1 IPv6 DNS.................................................17
7.4.2 IPv6 Routing.............................................17 7.4.2 IPv6 Routing.............................................17
7.4.3 Configuration of Hosts...................................17 7.4.3 Configuration of Hosts...................................17
7.4.4 Developing an IPv6 addressing plan.......................18 7.4.4 Developing an IPv6 addressing plan.......................18
7.4.5 Security.................................................19 7.4.5 Security.................................................18
7.5 Stage 3: Widespread Dual-Stack deployment on-site..........19 7.5 Stage 3: Widespread Dual-Stack deployment on-site..........19
8. Applicable Transition Mechanisms...........................21 8. Applicable Transition Mechanisms...........................21
8.1 Recognizing Incompatible Network touchpoints...............21 8.1 Recognizing Incompatible Network touchpoints...............21
8.2 Recognizing Application incompatibilities..................22 8.2 Recognizing Application incompatibilities..................22
8.3 Using Multiple Mechanisms to Support IPv6 Transition.......22 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......22
9. Security Considerations....................................23 8.4 Analysis of Selected Transition Mechanisms.................22
10. IANA Considerations........................................23 9. Security Considerations....................................24
11. References.................................................23 10. IANA Considerations........................................24
11.1 Normative References......................................23 11. References.................................................24
11.2 Non-Normative References..................................23 11.1 Normative References......................................24
Change Log.....................................................25 11.2 Non-Normative References..................................24
Document Acknowledgments.......................................25 Change Log.....................................................26
Author's Addresses.............................................26 Document Acknowledgments.......................................27
Copyright (C) The Internet Society (2005)......................27 Author's Addresses.............................................28
Disclaimer.....................................................27 Copyright (C) The Internet Society (2005)......................29
Acknowledgment.................................................27 Disclaimer.....................................................29
Appendix A - Crisis Management Network Scenarios...............28 IPR Disclosure Acknowledgement.................................29
Disclaimer of validity.........................................29
Acknowledgment.................................................30
Appendix A - Crisis Management Network Scenarios...............31
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 2]^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 page 4, line 4 skipping to change at line 167
discuss any use with network address translation [NATPT, NATDE] or discuss any use with network address translation [NATPT, NATDE] or
the use of Provider Independent address space. the use of Provider Independent address space.
The following specific topics are currently out of scope for this The following specific topics are currently out of scope for this
document: document:
- Multihoming - Multihoming
- Application transition/porting (see [APPS]). - Application transition/porting (see [APPS]).
- IPv6 VPN, firewall or intrusion detection deployment - IPv6 VPN, firewall or intrusion detection deployment
- IPv6 network management and QoS deployment - IPv6 network management and QoS deployment
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 3]^L
- Detailed IT Department requirements - Detailed IT Department requirements
- Deployment of novel IPv6 services, e.g. Mobile IPv6 - Deployment of novel IPv6 services, e.g. Mobile IPv6
- Requirements or Transtion at the Providers network - Requirements or Transtion at the Providers network
- Transport protocol selection for applications with IPv6 - Transport protocol selection for applications with IPv6
- Application layer and configuration issues. - Application layer and configuration issues.
- IPv6 only future deployment scenarios. - IPv6 only future deployment scenarios.
We are focusing in this document on IP Layer 3 deployment, in the We are focusing in this document on IP Layer 3 deployment, in the
same way as the other IPv6 deployment analysis works have done same way as the other IPv6 deployment analysis works have done
[UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the [UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the
skipping to change at page 5, line 5 skipping to change at line 205
enterprise. In sectioin 7 we discuss general issues and enterprise. In sectioin 7 we discuss general issues and
applicability. In section 8 a set of transition mechanisms are applicability. In section 8 a set of transition mechanisms are
recommended that can support the deployment of IPv6 with an recommended that can support the deployment of IPv6 with an
enterprise. enterprise.
This document then provides Appendix A for readers depicting a This document then provides Appendix A for readers depicting a
Crisis Management enterprise network to demonstrate an enterprise Crisis Management enterprise network to demonstrate an enterprise
network example that requires all the properties as analyzed in network example that requires all the properties as analyzed in
Sections 3, 4, 5, 6, and 7. Sections 3, 4, 5, 6, and 7.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 4]^L
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 page 6, line 5 skipping to change at line 240
IPv4 and IPv6. IPv4 and IPv6.
IP-capability - The ability to support IPv6 only, IPv4 only, IP-capability - The ability to support IPv6 only, IPv4 only,
or Dual IP Layer or Dual IP Layer
IPv6-dominant - A network or link that uses only IPv6 routing. IPv6-dominant - A network or link that uses only IPv6 routing.
Transition - The network strategy the enterprise uses to Transition - The network strategy the enterprise uses to
Implementation transition to IPv6. Implementation transition to IPv6.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 5]^L
3. Enterprise Matrix Analysis for Transition 3. Enterprise Matrix Analysis for Transition
To provide context for an analysis of the transitioning enterprise To provide context for an analysis of the transitioning enterprise
at layer 3 we have provided a matrix which describes various at layer 3 we have provided a matrix which describes various
scenarios which might be encountered during an IPv6 transition. scenarios which might be encountered during an IPv6 transition.
The notional enterprise network is comprised of hosts attached to The notional enterprise network is comprised of hosts attached to
an enterprise-owned intranet(s) at two different global locations an enterprise-owned intranet(s) at two different global locations
separated by the Internet. The enterprise owns, operates and separated by the Internet. The enterprise owns, operates and
maintains its own intranetworks, but relies on an external provider maintains its own intranetworks, but relies on an external provider
organization that offers Internet Service. Both local and organization that offers Internet Service. Both local and
skipping to change at page 7, line 4 skipping to change at line 297
(Host 1 Network) (Host 1 Network)
- The third column represents the IP-capability of the - The third column represents the IP-capability of the
service provider network. service provider network.
(Service Provider) (Service Provider)
- The fourth column represents the IP-capability of the - The fourth column represents the IP-capability of the
destination network wherein the originating IP packets destination network wherein the originating IP packets
are received. are received.
(Host 2 Network) (Host 2 Network)
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 6]^L
- The fifth column represents the protocol used by the - The fifth column represents the protocol used by the
application and, below, the IP-capability of the application and, below, the IP-capability of the
destination node receiving the originating IP packets. destination node receiving the originating IP packets.
(Application/Host 2 OS). (Application/Host 2 OS).
As an example, notional network 1 is an IPv6 application residing As an example, notional network 1 is an IPv6 application residing
on a Dual-IP layer host trying to establish a communications on a Dual-IP layer host trying to establish a communications
exchange with a destination IPv6 application. To complete the exchange with a destination IPv6 application. To complete the
information exchange the packets must first traverse the host's information exchange the packets must first traverse the host's
originating IPv4 network (intranet), then the service provider's, originating IPv4 network (intranet), then the service provider's,
and destination hosts Dual-IP network. and destination hosts Dual-IP network.
Obviously Table 1 does not describe every possible scenario. Obviously Table 1 does not describe every possible scenario.
Trivial notional networks (such as pure IPv4, pure IPv6, and Trivial notional networks (such as pure IPv4, pure IPv6, and
ubiquitous Dual-IP) are not addressed. However, the authors feel ubiquitous Dual-IP) are not addressed. However, the authors feel
these ten represent the vast majority of transitional situations these ten represent the vast majority of transitional situations
likely to be encountered in today's enterprise. Therefore, we will likely to be encountered in today's enterprise. Therefore, we will
use these ten to address the analysis for enterprise deployment. use these ten to address the analysis for enterprise deployment.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 7]^L
Table 1 - Enteprise Scenario Deployment Matrix Table 1 - Enteprise 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 |
===================================================== | IPv6 | | | | IPv6 | ======================================================
| IPv6 | | | | IPv6 |
B | ---- | IPv6 | IPv4 | IPv4 | ---- | B | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
===================================================== | IPv4 | | | | IPv4 | ======================================================
| IPv4 | | | | IPv4 |
C | ---- | IPv4 |Dual IP | IPv6 | ---- | C | ---- | IPv4 |Dual IP | IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
===================================================== | IPv4 |Dual IP| | | IPv4 | ======================================================
| IPv4 |Dual IP| | | IPv4 |
D | ---- | or | IPv4 | IPv6 | ---- | D | ---- | or | IPv4 | IPv6 | ---- |
| Dual IP | IPv6 | | | Dual IP | | Dual IP | IPv6 | | | Dual IP |
===================================================== | IPv6 |Dual IP| |Dual IP| IPv4 | ======================================================
| IPv6 |Dual IP| |Dual IP| IPv4 |
E | ---- | or |Dual IP | or | ---- | E | ---- | or |Dual IP | or | ---- |
| Dual IP | IPv6 | | IPv6 | Dual IP | | Dual IP | IPv6 | | IPv6 | Dual IP |
===================================================== | IPv6 | | | | IPv4 | ======================================================
| IPv6 | | | | IPv4 |
F | ---- | IPv6 | IPv4 | IPv4 | ---- | F | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
===================================================== | IPv4 | | | | IPv6 | ======================================================
| IPv4 | | | | IPv6 |
G | ---- | IPv6 | Dual IP| IPv6 | ---- | G | ---- | IPv6 | Dual IP| IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
===================================================== | IPv4 | | | | IPv6 | ======================================================
| IPv4 | | | | IPv6 |
H | ---- | IPv6 |Dual IP | IPv4 | ---- | H | ---- | IPv6 |Dual IP | IPv4 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
===================================================== | IPv4 | | | | IPv6 | ======================================================
| IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- | I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
===================================================== | IPv6 | | | | IPv4 | ======================================================
| IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- | J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
==================================================== The reader should note that scenarios A-C in Table 1 are variations ======================================================
The reader should note that scenarios A-C in Table 1 are variations
of compatible hosts communicating across largely (but not entirely) of compatible hosts communicating across largely (but not entirely)
homogenous networks. In each of the first three scenarios, the homogenous networks. In each of the first three scenarios, the
packet must traverse at least one incompatible network component. packet must traverse at least one incompatible network component.
For example, scenario B represents an enterprise which wishes to For example, scenario B represents an enterprise which wishes to
use IPv6 applications, but has yet to transition its internal use IPv6 applications, but has yet to transition its internal
networks and it's Service Provider also lags, offering only a v4 networks and it's Service Provider also lags, offering only a v4
IP-service. Conversely, Scenario C represents an enterprise which IP-service. Conversely, Scenario C represents an enterprise which
has completed transition to IPv6 in its core networks (as has its has completed transition to IPv6 in its core networks (as has its
Service Provider), but continues to require a legacy IPv4-based Service Provider), but continues to require a legacy IPv4-based
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 8]^L
application. application.
Scenario D represents the unusual situation where the enterprise Scenario D represents the unusual situation where the enterprise
has transitioned its core intranetworks to IPv6, but (like scenario has transitioned its core intranetworks to IPv6, but (like scenario
B) it's ISP provider has yet to transition. In addition, this B) it's ISP provider has yet to transition. In addition, this
Enterprise continues to retain critical legacy IPv4-based Enterprise continues to retain critical legacy IPv4-based
applications which must communicate over this heterogenous network applications which must communicate over this heterogenous network
environment. environment.
Scenarios E-J represent transitional situations wherein the Scenarios E-J represent transitional situations wherein the
skipping to change at page 10, line 5 skipping to change at line 403
it maintains a variety of heterogenous network segments between the it maintains a variety of heterogenous network segments between the
communicating applications. Scenarios E and J represent distinctly communicating applications. Scenarios E and J represent distinctly
different extremes on either end of the spectrum. In scenario E, different extremes on either end of the spectrum. In scenario E,
the enterprise has largely transitioned to IPv6 in both its the enterprise has largely transitioned to IPv6 in both its
applications and networks. However, scenario E shows that a few applications and networks. However, scenario E shows that a few
legacy IPv4-based applications may still be found in the legacy IPv4-based applications may still be found in the
enterprise. On the other hand, scenario J shows an Enterprise that enterprise. On the other hand, scenario J shows an Enterprise that
has begun its transition in a very disjointed manner and, in which has begun its transition in a very disjointed manner and, in which
IPv6-based applications and network segments are relatively rare. IPv6-based applications and network segments are relatively rare.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 9]^L
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 page 11, line 5 skipping to change at line 462
document. document.
A typical deployment would initially involve the establishment of a A typical deployment would initially involve the establishment of a
single "testbed" Dual-IP subnet at the enterprise site prior to single "testbed" Dual-IP subnet at the enterprise site prior to
wider deployment. Such a testbed not only allows the IPv6 wider deployment. Such a testbed not only allows the IPv6
capability of specific platforms and applications to be evaluated capability of specific platforms and applications to be evaluated
and verified, but also permits the steps in Sections 7.3 and 7.4 of and verified, but also permits the steps in Sections 7.3 and 7.4 of
this document to be undertaken without (potential) adverse impact this document to be undertaken without (potential) adverse impact
on the production elements of the enterprise. on the production elements of the enterprise.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 10]^L
Section 7.5 describes the stages for the widespread deployment in Section 7.5 describes the stages for the widespread deployment in
the enterprise, which could be undertaken after the basic building the enterprise, which could be undertaken after the basic building
blocks for IPv6 deployment are in place. blocks for IPv6 deployment are in place.
4.2 Routing Capability Analysis for Dual-IP Deployment 4.2 Routing Capability Analysis for Dual-IP Deployment
A critical part of Dual-IP deployment is the selection of the A critical part of Dual-IP deployment is the selection of the
IPv6-capable routing infrastructure to be implemented. The path IPv6-capable routing infrastructure to be implemented. The path
taken will depend on whether the enterprise has existing Layer 2/3 taken will depend on whether the enterprise has existing Layer 2/3
switch/router equipment that has an IPv6 (routing) capability, or switch/router equipment that has an IPv6 (routing) capability, or
skipping to change at page 12, line 5 skipping to change at line 513
4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure
Consider the situation where there exists IPv6 edge routers which Consider the situation where there exists IPv6 edge routers which
are IPv6-capable, while others,and perhaps the enterprise backbone are IPv6-capable, while others,and perhaps the enterprise backbone
itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, itself, are not IPv6-capable (Scenario B of Table 1). Tunneling,
as described in [BCNF] would be established between the Dual-IP as described in [BCNF] would be established between the Dual-IP
capable routers on the enterprise, thus "bypassing" existing non capable routers on the enterprise, thus "bypassing" existing non
IPv6-capable routers and platforms. IPv6-capable routers and platforms.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 11]^L
In the widespread dual-IP scenario, a more structured, manageable In the widespread dual-IP scenario, a more structured, manageable
method is required, where the administrator has control of the method is required, where the administrator has control of the
deployment per-link and (ideally) long-term, aggregatable global deployment per-link and (ideally) long-term, aggregatable global
IPv6 addressing is obtained, planned and used from the outset. IPv6 addressing is obtained, planned and used from the outset.
4.4.2.2 Deploy a parallel IPv6 infrastructure 4.4.2.2 Deploy a parallel IPv6 infrastructure
Alternatively,the administrator may deploy a new, separate IPv6- Alternatively,the administrator may deploy a new, separate IPv6-
capable router (or set of routers). It is quite possible that such capable router (or set of routers). It is quite possible that such
a parallel infrastructure would be IPv6-dominant. a parallel infrastructure would be IPv6-dominant.
skipping to change at page 13, line 5 skipping to change at line 562
the enterprise may consider deploying it's own remote IPv6 access the enterprise may consider deploying it's own remote IPv6 access
support, as described in Section 7.5.2 below. support, as described in Section 7.5.2 below.
4.4 Other considerations 4.4 Other considerations
There are some issues associated with turning IPv6 on by default, There are some issues associated with turning IPv6 on by default,
including application connection delays, poor connectivity, and including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF] worked around or mitigated by following the advice in [V6DEF]
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 12]^L
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 page 14, line 5 skipping to change at line 616
example when an application's server is located outside of the example when an application's server is located outside of the
enterprise network, or on other intranetworks of the same enterprise network, or on other intranetworks of the same
enterprise. enterprise.
Alternatively, the enterprise could decide to deploy its own Alternatively, the enterprise could decide to deploy its own
transition mechanism node, possibly collocating it adjacent to the transition mechanism node, possibly collocating it adjacent to the
border router that connects to the upstream Provider. In this case, border router that connects to the upstream Provider. In this case,
intranetnetworks communication using this tunnel end point is also intranetnetworks communication using this tunnel end point is also
possible. possible.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 13]^L
5.2 Manual versus Autoconfigured 5.2 Manual versus Autoconfigured
If the number of nodes to be using IPv6 is reduced, another option If the number of nodes to be using IPv6 is reduced, another option
is to use statically configured tunnels. However automatically is to use statically configured tunnels. However automatically
configured tunnels are generally preferred. configured tunnels are generally preferred.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 14]^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
skipping to change at page 16, line 5 skipping to change at line 676
While retaining interoperability with IPv4 is a noble goal for While retaining interoperability with IPv4 is a noble goal for
Enterprise architects, it is an unfortunate fact that maintaining Enterprise architects, it is an unfortunate fact that maintaining
IPv4 services in an IPv6 dominant networks slows and may even IPv4 services in an IPv6 dominant networks slows and may even
impede your ability to reap the maximum benefits of IPv6. impede your ability to reap the maximum benefits of IPv6.
The decision whether or not to use an IPv6-dominant network The decision whether or not to use an IPv6-dominant network
deployment strategy is completely driven by the Enterprise's deployment strategy is completely driven by the Enterprise's
business and operational objectives and guided by the Enterprise's business and operational objectives and guided by the Enterprise's
transition plan. transition plan.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 15]^L
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 page 16, line 38 skipping to change at line 711
provider. provider.
7.3.1 Obtaining external connectivity 7.3.1 Obtaining external connectivity
The enterprise service provider would typically be a The enterprise service provider would typically be a
topographically close IPv6 provider that is able to provide an IPv6 topographically close IPv6 provider that is able to provide an IPv6
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.
It is not recommended to use 6to4 [6TO4] for an enterprise
deployment. The enterprise has a requirement for long-term, stable
IPv6 connectivity. 6to4 is more appropriate for small business,
home use, or single node environments. Use of 6to4 also prevents
the enterprise adopting aggregatable global IPv6 addressing from
the outset.
7.3.2 Obtaining global IPv6 address space 7.3.2 Obtaining global IPv6 address space
The enterprise will obtain global IPv6 address space from its The enterprise will obtain global IPv6 address space from its
selected upstream provider, as provider assigned (PA) address selected upstream provider, as provider assigned (PA) address
space. space.
The enterprise should receive at least a /48 allocation from its The enterprise should receive at least a /48 allocation from its
provider, as described in [ALLOC]. provider, as described in [ALLOC].
The procedure for enterprise renumbering between providers is The procedure for enterprise renumbering between providers is
described in [RENUM]. described in [RENUM].
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 16]^L
7.4 Stage 2: Deploying generic basic service components 7.4 Stage 2: Deploying generic basic service components
Most of these are discussed in Section 4 of [BSCN]. Here we comment Most of these are discussed in Section 4 of [BSCN]. Here we comment
on those aspects that we believe are in scope for this analysis on those aspects that we believe are in scope for this analysis
document. Thus we have not included network management, document. Thus we have not included network management,
multihoming, multicast or application transition analysis here, but multihoming, multicast or application transition analysis here, but
these aspects should be addressed in Stage 2. these aspects should be addressed in Stage 2.
7.4.1 IPv6 DNS 7.4.1 IPv6 DNS
skipping to change at page 18, line 12 skipping to change at line 777
For secure autoconfiguration, the IPsec [IPSEC] or SEND method For secure autoconfiguration, the IPsec [IPSEC] or SEND method
[SEND] can be used. [SEND] can be used.
A stateless configured node wishing to gain other configuration A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateful information (e.g. DNS, NTP servers) will likely need a Stateful
DHCPv6 [DHCPv6] service available. DHCPv6 [DHCPv6] service available.
For nodes configuring using DHCPv6, where DHCPv6 servers are For nodes configuring using DHCPv6, where DHCPv6 servers are
offlink, a DHCPv6 Relay Agent function will be required. offlink, a DHCPv6 Relay Agent function will be required.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 17]^L
Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
there is support for DHCPv6 to assign privacy addresses to nodes in there is support for DHCPv6 to assign privacy addresses to nodes in
managed environments. managed environments.
7.4.4 Developing an IPv6 addressing plan 7.4.4 Developing an IPv6 addressing plan
A site will need to formulate an IPv6 addressing plan, utilising A site will need to formulate an IPv6 addressing plan, utilising
the globally aggregatable public IPv6 prefix allocated to it by its the globally aggregatable public IPv6 prefix allocated to it by its
upstream connectivity provider. upstream connectivity provider.
skipping to change at page 19, line 15 skipping to change at line 832
7.4.5 Security 7.4.5 Security
When deploying IPv6 within a Dual-IP network, a site will need to When deploying IPv6 within a Dual-IP network, a site will need to
implement its site security policy for IPv6-capable nodes as it implement its site security policy for IPv6-capable nodes as it
does for IPv4-capable nodes. For example, a border firewall does for IPv4-capable nodes. For example, a border firewall
should be capable of filtering and controlling IPv6 traffic by should be capable of filtering and controlling IPv6 traffic by
enforcing the same policy as it already does for IPv4. enforcing the same policy as it already does for IPv4.
However, a site will also need to review its security policy in However, a site will also need to review its security policy in
light of IPv6 specific functionality that will be deployed in the light of IPv6 specific functionality that will be deployed in the
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 18]^L
site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND), site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND),
IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use
of globally aggregatable public address space where for IPv4 of globally aggregatable public address space where for IPv4
private addressing and NAT may have been used. private addressing and NAT may have been used.
An overview of how Network Architecture Protection (NAP) using IPv6 An overview of how Network Architecture Protection (NAP) using IPv6
can provide the same or more benefits without the need for NAT can can provide the same or more benefits without the need for NAT can
be found in [NAP]. This describes how the perceived security with be found in [NAP]. This describes how the perceived security with
IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6 IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6
technology can be used to provide the market-perceived benefits of technology can be used to provide the market-perceived benefits of
skipping to change at page 20, line 14 skipping to change at line 890
A Dual-IP deployment will often be made by sites wishing to support A Dual-IP deployment will often be made by sites wishing to support
use of IPv6 within a site, even if IPv6 transport is not preferred use of IPv6 within a site, even if IPv6 transport is not preferred
by all applications. Putting support for IPv6 in all site by all applications. Putting support for IPv6 in all site
infrastructure (DNS, email transport, etc) allows IPv6 usage to be infrastructure (DNS, email transport, etc) allows IPv6 usage to be
phased in over time. As nodes become IPv6 capable, and phased in over time. As nodes become IPv6 capable, and
applications and services IPv6 enabled, the IPv6 capable applications and services IPv6 enabled, the IPv6 capable
infrastructure can be leveraged. For most networks, Dual-IP will infrastructure can be leveraged. For most networks, Dual-IP will
be at the very least a medium-term transition towards an IPv6 be at the very least a medium-term transition towards an IPv6
dominant future. However, the introduction of IPv6 support, with dominant future. However, the introduction of IPv6 support, with
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 19]^L
the potential benefits of globally aggregatable public address the potential benefits of globally aggregatable public address
usage (with [NAP]), and other new IPv6 capabilities, can bring more usage (with [NAP]), and other new IPv6 capabilities, can bring more
immediate benefits for the site. immediate benefits for the site.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 20]^L
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 page 21, line 59 skipping to change at line 952
Identifying the responsible device to perform the tunneling is Identifying the responsible device to perform the tunneling is
driven by the position of the incompatible touchpoint. If a local driven by the position of the incompatible touchpoint. If a local
network is incompatible than host tunneling is appropriate. If the network is incompatible than host tunneling is appropriate. If the
backbone (provider) network is incompatible then gateway-to-gateway backbone (provider) network is incompatible then gateway-to-gateway
tunneling might be a better choice. By working to ensure tunnel tunneling might be a better choice. By working to ensure tunnel
endpoints are always configured at dual-IP devices, end-to-end endpoints are always configured at dual-IP devices, end-to-end
communication or services (IPv4 or IPv6) can be preserved. communication or services (IPv4 or IPv6) can be preserved.
Having IPv6 applications on a Dual-IP host on a v4-only network Having IPv6 applications on a Dual-IP host on a v4-only network
lets you use ISATAP [ISTP] or Teredo to tunnel to a v6 end service. lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end
ISATAP [ISTP] can be used to provide end node IPv6 connectivity service. ISATAP [ISTP] can be used to provide end node IPv6
from nodes on an isolated IPv4 network, through the use of
automatic tunneling of IPv6 in IPv4.
Enterprise architects should consider providing a tunnel broker draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 21]^L
[TBRK] as a cost effective service to local users or applications. connectivity from nodes on an isolated IPv4 network, through the
Tunnel Brokers can be used to provide tunnel setup for an use of automatic tunneling of IPv6 in IPv4.
enterprise using manual configured tunnels, 6to4, or DSTM. Tunnel
Brokers can automate the use of tunnels across an enterprise Enterprise architects should consider providing a Tunnel Broker
[TBRK, TSPB] as a cost effective service to local users or
applications. Tunnel Brokers can be used to provide tunnel setup
for an enterprise using manual configured tunnels, 6to4, or DSTM.
Tunnel Brokers can automate the use of tunnels across an enterprise
deploying IPv6. deploying IPv6.
Later in the transition process, after the enterprise has Later in the transition process, after the enterprise has
transitioned to a predominately IPv6 infrastructure, the architect transitioned to a predominately IPv6 infrastructure, the architect
should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
in the case of early deployment of IPv6-dominant networks DSTM can in the case of early deployment of IPv6-dominant networks DSTM can
be used too. be used too.
8.2 Recognizing Application incompatibilities 8.2 Recognizing Application incompatibilities
skipping to change at page 23, line 5 skipping to change at line 1003
and simulataneously (at different parts of the enterprise) and simulataneously (at different parts of the enterprise)
incompatible networks. These highly complex situations represent incompatible networks. These highly complex situations represent
the fourth common theme in Table 1 and are specifically depicted by the fourth common theme in Table 1 and are specifically depicted by
Scenarios F, H, I and J. Maintaining IP interoperability in these Scenarios F, H, I and J. Maintaining IP interoperability in these
situations requires additional planning and may require multiple or situations requires additional planning and may require multiple or
even nested use of diverse transition mechanisms. For example, an even nested use of diverse transition mechanisms. For example, an
ALG co-located with the application server may be required to ALG co-located with the application server may be required to
service both IPv4 and IPv6 data streams that are simulataneously service both IPv4 and IPv6 data streams that are simulataneously
tunneled through incompatible network segment(s). tunneled through incompatible network segment(s).
8.4 Analysis of Selected Transition Mechanisms
The following transition mechanism have at least two independent
implementations and are deployed in enterprises today. The authors
are only comfortable analyzing the transition mechanisms below, in
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 22]^L
addition to our analysis in Sections 8.1, 8.2, and 8.3.
Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to
develop a test network in the enterprise, but will not scale well
for a complete implementation of an IPv6 network. Manual Configured
Tunnels for IPv6 is an IETF Proposed Standard.
6to4 [6t4] is a useful tunneling mechanism for deployment if the
enterprise has not obtained a native IPv6 prefix from their
provider. 6to4 is an IETF Proposed Standard.
NAT-PT [NATPT] can be useful when there is no other means to access
an IPv4 node behind a NAT network that only has a private address.
But, it is recommended that the enterprise also look at the ability
to provide access to that IPv4 node using a Proxy or Application
Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF
Proposed Standard.
Teredo [TRDO] can be useful for an enterprise when an enterprise
node only has an IPv4 address and use of NAT-PT, Proxy, or an
Application Layer Gateway is not optimal. Teredo is on track to be
an IETF Proposed Standard.
ISATAP [ISTP] is a useful tunneling mechanism when the enterprise
has deployed IPv6, and there are particpating nodes for the IPv6
deployment that exist on IPv4 networks. ISATAP is being submitted as
an IETF Experimental RFC.
DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.
Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the
Enterprise wants to automate the setup of tunnels in the enterprise,
and a tunnel broker can be used to support 6to4, ISATAP, and DSTM
mechanisms. Tunnel Broker set-up protocol is being submitted as an
IETF Experimental RFC.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 23]^L
9. Security Considerations 9. Security Considerations
Security considerations for IPv6 deployment in a Dual-IP Security considerations for IPv6 deployment in a Dual-IP
environment are discussed above in section 7.4.5, where external environment are discussed above in section 7.4.5, where external
references to overview documents [V6SEC] [NAP] are also included. references to overview documents [V6SEC] [NAP] are also included.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 24, line 5 skipping to change at line 1100
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via
IPv4 Clouds" RFC 3056 February 2001. IPv4 Clouds" RFC 3056 February 2001.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs" Work in Progress. NATs" Work in Progress.
[BCNF] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms [BCNF] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms
for IPv6 Hosts and Routers" Work in Progress from RFC 2893. for IPv6 Hosts and Routers" Work in Progress from RFC 2893.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 24]^L
[DSTM] Bound, J., (Ed) et al. "Dual Stack Transition Mechanim" [DSTM] Bound, J., (Ed) et al. "Dual Stack Transition Mechanim"
Work in Progress. Work in Progress.
[DSTM+] DSTM Industry Design Team web site www.dstm.info [DSTM+] DSTM Industry Design Team web site www.dstm.info
[ISTP] Templin, F., et al "Intra-Site Automatic Tunnel [ISTP] Templin, F., et al "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)". Work in Progress. Addressing Protocol (ISATAP)". Work in Progress.
[6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in [6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in
IPv6" RFC 2473 December 1998. 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.
[TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker with the
Tunnel Setup Protocol". Work in Progress.
[SEC1] Savola, P. and Patel, C. "Security Considerations for 6to4" [SEC1] Savola, P. and Patel, C. "Security Considerations for 6to4"
RFC3964 December 2004. RFC3964 December 2004.
[ULA] Hinden, B., Haberman, B., "Unique Local IPv6 [ULA] Hinden, B., Haberman, B., "Unique Local IPv6
Addresses". Work in Progress. Addresses". Work in Progress.
[RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering [RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering
an IPv6 Network without a Flag Day". Work in Progress. an IPv6 Network without a Flag Day". Work in Progress.
[ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
skipping to change at page 24, line 61 skipping to change at line 1160
[OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6" [OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6"
RFC2740 December 1999. RFC2740 December 1999.
BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol Extensions for BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol Extensions for
BGP-4", RFC2283 June 2000. BGP-4", RFC2283 June 2000.
[ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing Protocol", [ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing Protocol",
RFC1142 February 1990. RFC1142 February 1990.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 25]^L
[RIPng] Malkin, G., Minnear, R. "RIPng for IPv6" [RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC2080 January 1997 RFC2080 January 1997
Change Log Change Log
June 2005 - to July 2005
ID 02 to 03
- Fixed more IETF id-nits.
- Added Section 8.4 Transition Mechanism Summary
analysis.
March 2005 to June 2005 March 2005 to June 2005
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.
skipping to change at page 25, line 48 skipping to change at line 1215
- Updated section 3 matrix and description to simplify and focus - Updated section 3 matrix and description to simplify and focus
on dual IP layer. on dual IP layer.
- Edited base text of Sections 4-7 but all three require extensive - Edited base text of Sections 4-7 but all three require extensive
additional test for descriptions. additional test for descriptions.
- Edited section 8 and removed table and will reference table in - Edited section 8 and removed table and will reference table in
section 3. This section still needs to be written. section 3. This section still needs to be written.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 26]^L
Document Acknowledgments Document Acknowledgments
The Author's would like to acknowledge contributions from the The Author's would like to acknowledge contributions from the
following: IETF v6ops Working Group members, Pekka Savola, and following: IETF v6ops Working Group members, Pekka Savola, and
Jordi Palet. Jordi Palet.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 27]^L
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 page 27, line 5 skipping to change at line 1266
Email: david.green@sri.com Email: david.green@sri.com
Steve Klynsma Steve Klynsma
The MITRE Corporation The MITRE Corporation
7515 Colshire Drive 7515 Colshire Drive
McLean, VA 22102-5708 McLean, VA 22102-5708
USA USA
703-883-6469 703-883-6469
Email: sklynsma@mitre.org Email: sklynsma@mitre.org
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 28]^L
Copyright (C) The Internet Society (2005) Copyright (C) The Internet Society (2005)
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,
skipping to change at page 27, line 31 skipping to change at line 1294
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. PARTICULAR PURPOSE.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Disclaimer of validity
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 29]^L
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 30]^L
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 page 29, line 4 skipping to change at line 1391
are available, and platforms for the application are IPv6 capable. are available, and platforms for the application are IPv6 capable.
Requirements: Do not disrupt IPv4 infrastructure. Requirements: Do not disrupt IPv4 infrastructure.
Scenario 2: Dual Stack Network Scenario 2: Dual Stack Network
Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable
hosts and network infrastructure. Enterprise with an existing IPv4 hosts and network infrastructure. Enterprise with an existing IPv4
network wants to deploy IPv6 in conjunction with their IPv4 network network wants to deploy IPv6 in conjunction with their IPv4 network
in order to take advantage of emerging IPv6 network-centric in order to take advantage of emerging IPv6 network-centric
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 31]^L
capabilities and to be interoperable with other agencies, capabilities and to be interoperable with other agencies,
international partners, and commercial enterprises that are international partners, and commercial enterprises that are
deploying an IPv6 architecture. deploying an IPv6 architecture.
Assumptions: The IPv4 network infrastructure used has an Assumptions: The IPv4 network infrastructure used has an
equivalent capability in IPv6. equivalent capability in IPv6.
Requirements: Do not disrupt existing IPv4 network infrastructure Requirements: Do not disrupt existing IPv4 network infrastructure
with IPv6. IPv6 should be equivalent or "better" than the network with IPv6. IPv6 should be equivalent or "better" than the network
infrastructure in IPv4. It may not be feasible to deploy IPv6 on infrastructure in IPv4. It may not be feasible to deploy IPv6 on
skipping to change at page 30, line 5 skipping to change at line 1451
through their network infrastructure. Because the institution's through their network infrastructure. Because the institution's
existing wired and fixed site wireless infrastructure can be existing wired and fixed site wireless infrastructure can be
destroyed or unavailable in a crisis, the crisis management network destroyed or unavailable in a crisis, the crisis management network
must be able to deploy it's own mobile wireless network or connect must be able to deploy it's own mobile wireless network or connect
through external wired and wireless networks provided by ISPs or through external wired and wireless networks provided by ISPs or
partner organizations. This infrastructure lets us divide the partner organizations. This infrastructure lets us divide the
basic areas for IPv4/IPv6 interoperability into three main areas: basic areas for IPv4/IPv6 interoperability into three main areas:
the customer applications, the local network, and the network the customer applications, the local network, and the network
backbone. backbone.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 32]^L
The basic components in a crisis management network are depicted in The basic components in a crisis management network are depicted in
Figure 1. Figure 1.
------------ ---------- ---- Wired Connection ------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection | Network and| | | .... Wireless Connection
| Service |--| Backbone | | Service |--| Backbone |
| Operation | | | | Operation | | |
------------ ---------- ------------ ----------
/ | --------------------- / | ---------------------
/ : _|Connection to | / : _|Connection to |
skipping to change at page 31, line 4 skipping to change at line 1512
o Stage 1 Limited Launch o Stage 1 Limited Launch
o Stage 2 Dual Stack Dominance o Stage 2 Dual Stack Dominance
o Stage 3 IPv6 Dominance o Stage 3 IPv6 Dominance
o Stage 4 IPv6 Transition Complete o Stage 4 IPv6 Transition Complete
Generally, a crisis management network is able to entirely upgrade Generally, a crisis management network is able to entirely upgrade
a current IPv4 network to provide IPv6 services via a dual-stack a current IPv4 network to provide IPv6 services via a dual-stack
network in Stage 2 and then slowly progress to stages 3 and 4 as network in Stage 2 and then slowly progress to stages 3 and 4 as
indicted in Figure 2. During stage 2, When most applications are indicted in Figure 2. During stage 2, When most applications are
IPv6 dominant, operational and maintenance costs can be reduced on IPv6 dominant, operational and maintenance costs can be reduced on
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 33]^L
some networks by moving to stage 3 and running backbone networks some networks by moving to stage 3 and running backbone networks
entirely on IPv6 while adding IPv4 backwards compatibility via v4 entirely on IPv6 while adding IPv4 backwards compatibility via v4
in v6 tunneling or translation mechanisms to the existing in v6 tunneling or translation mechanisms to the existing
configuration from stage 2. When designing a new network, if a new configuration from stage 2. When designing a new network, if a new
IPv6-only service is required, it can be implemented at a lower IPv6-only service is required, it can be implemented at a lower
cost jumping directly to stage 3/4 if there are only limited/no cost jumping directly to stage 3/4 if there are only limited/no
legacy concerns. legacy concerns.
Tunnels Dominant dual Full dual Stack Tunnels Dominant dual Full dual Stack
IPv4-only --> or limited --> stacking with --> everywhere, mostly --> IPv4-only --> or limited --> stacking with --> everywhere, mostly -->
skipping to change at page 32, line 5 skipping to change at line 1574
Stage 2 occurs when most applications, local networks, and network Stage 2 occurs when most applications, local networks, and network
backbones become dual-stacked so that native IPv6 connections are backbones become dual-stacked so that native IPv6 connections are
enabled. At this point there is a mix of IPv4 and IPv6 applications enabled. At this point there is a mix of IPv4 and IPv6 applications
and services in use across the enterprise. The enterprise may be and services in use across the enterprise. The enterprise may be
made IPv6-capable through either software upgrades, hardware made IPv6-capable through either software upgrades, hardware
upgrades, or a combination of both. Generally IPv6 is added during upgrades, or a combination of both. Generally IPv6 is added during
normal technical refresh as the enterprise buys new equipment that normal technical refresh as the enterprise buys new equipment that
is IPv6 ready. is IPv6 ready.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 34]^L
Specialty legacy applications and wireless/satellite networks may Specialty legacy applications and wireless/satellite networks may
be especially slow to transition to IPv6 capability due to upgrade be especially slow to transition to IPv6 capability due to upgrade
costs so plans must be made for backwards compatibility for these costs so plans must be made for backwards compatibility for these
systems. Since some new IPv6 services cannot be provided through systems. Since some new IPv6 services cannot be provided through
IPv4, and some legacy network connections may not yet be upgraded, IPv4, and some legacy network connections may not yet be upgraded,
tunneling mechanisms have to be provided on the backbone to provide tunneling mechanisms have to be provided on the backbone to provide
IPv6 connectivity through to customer IPv6 applications still IPv6 connectivity through to customer IPv6 applications still
relying on legacy IPv4-only networks. The tunnels may provide relying on legacy IPv4-only networks. The tunnels may provide
host-based tunneling for individual customers or site-to-site host-based tunneling for individual customers or site-to-site
tunnels to connect small IPv6 domains through IPv4 only networks. tunnels to connect small IPv6 domains through IPv4 only networks.
skipping to change at page 33, line 4 skipping to change at line 1633
end-user security such as host-based firewalls and virus checkers end-user security such as host-based firewalls and virus checkers
for IPv6 attacks. Police, homeland defense, and military crisis for IPv6 attacks. Police, homeland defense, and military crisis
management networks require especially high levels of security and management networks require especially high levels of security and
should begin creation and implementation of their specialized should begin creation and implementation of their specialized
security architectures as soon as they begin planning for IPv6 security architectures as soon as they begin planning for IPv6
transition. New IPv6 features such as MIPv6, stateless address transition. New IPv6 features such as MIPv6, stateless address
auto-assignment, and ubiquitous end-user IPSEC will likely not be auto-assignment, and ubiquitous end-user IPSEC will likely not be
compatible with current information-assurance tools that are simply compatible with current information-assurance tools that are simply
ported from IPv4 to a minimal IPv6 capability. A complete new ported from IPv4 to a minimal IPv6 capability. A complete new
security policy, architecture, and tools will most likely be security policy, architecture, and tools will most likely be
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 35]^L
required to realize the true net-centric benefits of IPv6 in crisis required to realize the true net-centric benefits of IPv6 in crisis
networks requiring high security. networks requiring high security.
draft-ietf-v6ops-ent-analysis-02.txt Expires Jan 2006 [Page 36]^L
 End of changes. 

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