draft-ietf-v6ops-ent-analysis-01.txt   draft-ietf-v6ops-ent-analysis-02.txt 
IPv6 Operations Working Group IPv6 Operations Working Group
Internet Draft Jim Bound (Editor) Internet Draft Jim Bound
Document: draft-ietf-v6ops-ent-analysis-01.txt HP Document: draft-ietf-v6ops-ent-analysis-02.txt Yanick Pouffary
Obsoletes: ietf-v6ops-ent-analysis-00.txt Obsoletes: ietf-v6ops-ent-analysis-01.txt Hewlett-Packard
Expires: June 2005 Expires: December 2005 Steve Klynsma
MITRE
Tim Chown
University of Southhampton
Dave Green
SRI
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-01.txt> <draft-ietf-v6ops-ent-analysis-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that
patent or other IPR claims of which I am aware have been any applicable patent or other IPR claims of which he or she is
disclosed, and any of which I become aware will be disclosed, in aware have been or will be disclosed, and any of which he or she
accordance with RFC 3668. becomes aware will be disclosed, in accordance with Section 6 of
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
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
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.
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....................9 4. Wide-Scale Dual-Stack Deployment Analysis..................10
4.1 Staged Dual-Stack Deployment...............................9 4.1 Staged Dual-Stack Deployment...............................10
4.2 Analysis of Required Tools for Dual-Stack Deployment......10 4.2 Routing Capability Analysis for Dual-IP Deployment.........11
4.3 IPv6 Capability in the Routing Infrastructure.............10 4.2.1 IPv6 Routing Capability..................................11
4.4 IPv6 Capability not in the Routing Infrastructure.........10 4.2.2 IPv6 Routing Non-Capability..............................11
4.4.1 Tunnel IPv6 over the IPv4 infrastructure................10 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............11
4.4.2 Deploy a parallel IPv6 infrastructure...................11 4.4.2.2 Deploy a parallel IPv6 infrastructure..................12
4.5 Remote IPv6 access to the enterprise......................11 4.3 Remote IPv6 access to the enterprise.......................12
4.6 Other considerations......................................11 4.4 Other considerations.......................................12
5 Sparse Dual-Stack Deployment Analysis.......................12 5. Sparse Dual-Stack Deployment Analysis......................13
5.1 Internal versus External Tunnel End Point.................12 5.1 Internal versus External Tunnel End Point..................13
5.2 Manual versus Autoconfigured..............................13 5.2 Manual versus Autoconfigured...............................14
6 IPv6 Dominant Network Deployment Analysis...................14 6. IPv6 Dominant Network Deployment Analysis..................15
7 General Issues and Applicability from Analysis..............15 7. General Issues from Analysis...............................16
7.1 Staged Plan for IPv6 Deployment............................15 7.1 Staged Plan for IPv6 Deployment............................16
7.2 Network Infrastructure Requirements.......................15 7.2 Network Infrastructure Requirements........................16
7.3 Stage 1: Initial connectivity steps........................15 7.3 Stage 1: Initial connectivity steps........................16
7.3.1 Obtaining external connectivity..........................15 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........16 7.4 Stage 2: Deploying generic basic service components........17
7.4.1 IPv6 DNS.................................................16 7.4.1 IPv6 DNS.................................................17
7.4.2 IPv6 Routing............................................16 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......................17 7.4.4 Developing an IPv6 addressing plan.......................18
7.4.5 Security................................................17 7.4.5 Security.................................................19
7.5 Stage 3: Widespread Dual-Stack deployment on-site.........18 7.5 Stage 3: Widespread Dual-Stack deployment on-site..........19
7.5.1 Deploying IPv6 across the enterprise....................18 8. Applicable Transition Mechanisms...........................21
8 Applicable Transition Mechanisms............................19 8.1 Recognizing Incompatible Network touchpoints...............21
9 Security Considerations.....................................20 8.2 Recognizing Application incompatibilities..................22
10 References.................................................20 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......22
10.1 Normative References.....................................20 9. Security Considerations....................................23
10.2 Non-Normative References.................................21 10. IANA Considerations........................................23
Changes from -00 t -01.........................................21 11. References.................................................23
Document Acknowledgments.......................................22 11.1 Normative References......................................23
Author Addresses...............................................23 11.2 Non-Normative References..................................23
Appendix A - Campus Deployment Scenario with VLANs.............23 Change Log.....................................................25
Appendix B - Crisis Management Network Scenarios...............24 Document Acknowledgments.......................................25
Intellectual Property and Copyright Statements.................29 Author's Addresses.............................................26
Copyright (C) The Internet Society (2005)......................27
1 Introduction Disclaimer.....................................................27
Acknowledgment.................................................27
Appendix A - Crisis Management Network Scenarios...............28
NOTE to v6ops WG: This draft is mainly to get consensus on section 1. Introduction
3, that we have correct analysis topics sections 4-7, and section 8
still has to be written. All sections need more work but this is
to move discussion further. See changes from -00 to -01.
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
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.
The audience for this document is the enterprise network team The audience for this document is the enterprise network team
considering deployment of IPv6. The document will be useful for considering deployment of IPv6. The document will be useful for
enterprise teams that will have to determine the IPv6 transition enterprise teams that will have to determine the IPv6 transition
strategy for their enterprise. It is expected those teams include strategy for their enterprise. It is expected those teams include
members from management, network operations, and engineering. The members from management, network operations, and engineering. The
analysis and notational networks presented provide an example set analysis and notational networks presented provide an example set
of cases the enterprise can use to build an IPv6 transition of cases the enterprise can use to build an IPv6 transition
strategy. strategy.
The enterprise analysis will begin by describing a matrix as a tool The enterprise analysis will begin by describing a matrix as a tool
to be used to portray the different IPv4 and IPv6 possibilities for to be used to portray the different IPv4 and IPv6 possibilities for
deployment. The document will then provide analysis to support a deployment. The document will then provide analysis to support a
wide dual IP layer deployment strategy across the enterprise, to wide Dual-IP layer deployment strategy across the enterprise, to
provide the reader a view of how that can be planned and what is provide the reader a view of how that can be planned and what are
options are available. The document will then discuss the the options available. The document will then discuss the
deployment of sparse IPv6 nodes within the enterprise and what deployment of sparse IPv6 nodes within the enterprise and what
requirements need to be considered and implemented, when the requirements need to be considered and implemented, when the
enterprise will remain with IPv4-only routing infrastructure for enterprise will remain with IPv4-only routing infrastructure for
some time. The next discussion focuses on the use of IPv6 when it some time. The next discussion focuses on the use of IPv6 when it
is determined to be dominant across or within parts of the is determined to be dominant across or within parts of the
enterprise network. enterprise network.
The document then begins to discuss the the general issues and The document then begins to discuss the the general issues and
applicability from the previous analysis. The document concludes applicability from the previous analysis. The document concludes
providing a set of recommendations for each notational network providing a set of current transistion mechanism recommendations
within the matrix based on the previous analysis, issues and for the notational network scenarios to support an enterprise
applicability discussion, adding additional analysis useful for an planning to deploy IPv6.
enterprise planning 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 or the use of discuss any use with network address translation [NATPT, NATDE] or
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
- 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 Layer 3 deployment, in the same We are focusing in this document on IP Layer 3 deployment, in the
way as the other IPv6 deployment analysis works have done same way as the other IPv6 deployment analysis works have done
[UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the [UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the
wire", including address management and DNS services. wire", including address management and DNS services.
We are also assuming that the enterprise deployment is one being We are also assuming that the enterprise deployment is one 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 Section 2 we introduce the terminology used in this document. In
In Section 3 we introduce and define a tools matrix and define the Section 3 we introduce and define a tools matrix and define the IP
layer 3 connectivity requirements. In Section 4 we discuss wide layer 3 connectivity requirements. In Section 4 we discuss wide
scale dual IP layer use within an enterprise. In section 5 we scale Dual-IP layer use within an enterprise. In section 5 we
discuss sparse dual IP layer deployment within an enterprise. In discuss sparse Dual-IP layer deployment within an enterprise. In
section 6 we discuss IPv6 dominant network deployment within the section 6 we discuss IPv6 dominant network deployment within the
enterprise. In sectioin 7 we discuss general issues and enterprise. In sectioin 7 we discuss general issues and
applicability. In section 8 a set of deployment analysis is applicability. In section 8 a set of transition mechanisms are
provided and recommendations. recommended that can support the deployment of IPv6 with an
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.
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
enterprise network. enterprise network.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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.
3 Enterprise Matrix Analysis for Transition 3. Enterprise Matrix Analysis for Transition
To provide layer 3 enterprise analysis context for discussion we To provide context for an analysis of the transitioning enterprise
provide for this document the use of a matrix with a common set of at layer 3 we have provided a matrix which describes various
enterprise notational networks resulting from a selected Transition scenarios which might be encountered during an IPv6 transition.
Implementation chosen for the enterprise. The notional networks The notional enterprise network is comprised of hosts attached to
are comprised of hosts attached to an enterprise-owned intranet(s) an enterprise-owned intranet(s) at two different global locations
at two different global locations separated by the Internet. The separated by the Internet. The enterprise owns, operates and
enterprise owns, operates and maintains its own intranetworks, but maintains its own intranetworks, but relies on an external provider
relies on an external provider organization that offers Internet organization that offers Internet Service. Both local and
Service. Both local and destination intranetworks are operated by destination intranetworks are operated by different organizations
different organizations within the same enterprise and consequently within the same enterprise and consequently could have different
could use different IP-capability, than other intranetworks, at IP-capability, than other intranetworks, at certain times in the
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, ubiquitous dual-IP and straight forward (i.e. pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not
tunneling or translation at local or destination hosts) 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 use 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 notational that network address translation not be used in these notional
cases. cases.
Future enterprise transitions that will support IPv6-only nodes and Future enterprise transitions that support IPv6-only nodes and
IPv6-only ISPs will be a separate analysis required, that is beyond IPv6-only ISPs will require separate analysis, that is beyond the
the scope of this document. scope of this document.
Table 1 below is a matrix of nine possible Transition Table 1 scenarios below is a matrix of ten possible Transition
Implementations that may be selected in an enterprise, which 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 notational network, which are the rows of the matrix. The for that notional network. Each possible implementation is
matrix describes a set of notational networks as follows: represented by the rows of the matrix. The matrix describes a set
of notional networks as follows:
- 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
network where the node originated the packet. host network wherein the node originated the packet.
(Host 1 Network) (Host 1 Network)
- The third column represents the IP-capability of the - The third column represents the IP-capability of the
service provider network. service provider network.
(Service Provider) (Service Provider)
- The fourth column represents the IP-capability of the - The fourth column represents the IP-capability of the
destination network where the originating IP packets destination network wherein the originating IP packets
are received. are received.
(Host 2 Network) (Host 2 Network)
- The fifth column represents the protocol used by the - The fifth column represents the protocol used by the
application 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, notational 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
ubiquitous Dual-IP) are not addressed. However, the authors feel
these ten represent the vast majority of transitional situations
likely to be encountered in today's enterprise. Therefore, we will
use these ten to address the analysis for enterprise deployment.
Trivial notational networks (such as pure IPv4, pure IPv6, and Table 1 - Enteprise Scenario Deployment Matrix
straight-forward tunneling or translation) are not addressed.
Additionally there are other possible permutations, which are not
addressed. However, the authors feel these nine represent
notational networks, which are likely to be encountered in today's
enterprise. Therefore, we will use these nine to address the
analysis for enterprise deployment.
====================================================== ===================================================== |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 | | | | IPv6 | A | ---- | IPv4 | or |Dual IP| ---- |
1 | ---- | IPv4 |Dual IP |Dual IP| ---- | | Dual IP | | IPv4 | | Dual IP |
| Dual IP | | | | Dual IP | ===================================================== | IPv6 | | | | IPv6 |
====================================================== B | ---- | IPv6 | IPv4 | IPv4 | ---- |
| IPv6 | | | | IPv6 |
2 | ---- | IPv4 |Dual IP | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
4 | ---- |Dual IP|Dual IP | IPv4 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ===================================================== | IPv4 | | | | IPv4 |
| IPv6 | | | | IPv6 | C | ---- | IPv4 |Dual IP | IPv6 | ---- |
4 | ---- |Dual IP| IPv4 |Dual IP| ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ===================================================== | IPv4 |Dual IP| | | IPv4 |
| IPv6 | | | | IPv6 | D | ---- | or | IPv4 | IPv6 | ---- |
5 | ---- | IPv4 | IPv4 |Dual IP| ---- | | Dual IP | IPv6 | | | Dual IP |
===================================================== | IPv6 |Dual IP| |Dual IP| IPv4 |
E | ---- | or |Dual IP | or | ---- |
| Dual IP | IPv6 | | IPv6 | Dual IP |
===================================================== | IPv6 | | | | IPv4 |
F | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ===================================================== | IPv4 | | | | IPv6 |
| IPv4 | | | | IPv4 | G | ---- | IPv6 | Dual IP| IPv6 | ---- |
6 | ---- | IPv6 |Dual IP |Dual IP| ---- |
| Dual IP | | | | IPv4 |
======================================================
| IPv4 | | | | IPv4 |
7 | ---- | IPv6 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP | | Dual IP | | | | Dual IP |
====================================================== ===================================================== | IPv4 | | | | IPv6 |
| IPv4 | | | | IPv4 | H | ---- | IPv6 |Dual IP | IPv4 | ---- |
8 | ---- | IPv4 |Dual IP | IPv6 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ===================================================== | IPv4 | | | | IPv6 |
| IPv4 | | | | IPv4 | I | ---- | IPv6 | IPv4 | IPv6 | ---- |
9 | ---- | IPv4 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP | | IPv4 | | | | Dual IP |
====================================================== ===================================================== | IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP |
==================================================== The reader should note that scenarios A-C in Table 1 are variations
of compatible hosts communicating across largely (but not entirely)
homogenous networks. In each of the first three scenarios, the
packet must traverse at least one incompatible network component.
For example, scenario B represents an enterprise which wishes to
use IPv6 applications, but has yet to transition its internal
networks and it's Service Provider also lags, offering only a v4
IP-service. Conversely, Scenario C represents an enterprise which
has completed transition to IPv6 in its core networks (as has its
Service Provider), but continues to require a legacy IPv4-based
application.
4 Wide-Scale Dual-Stack Deployment Analysis Scenario D represents the unusual situation where the enterprise
has transitioned its core intranetworks to IPv6, but (like scenario
B) it's ISP provider has yet to transition. In addition, this
Enterprise continues to retain critical legacy IPv4-based
applications which must communicate over this heterogenous network
environment.
In this section we are covering Scenario 1 as described in Section Scenarios E-J represent transitional situations wherein the
3.1 of [BSCN]. The scenario, assumptions and requirements are Enterprise has both v4- and v6-based instantiations of the same
driven from the [BSCN] text. application that must continue to interoperate. In addition, these
scenarios show that the Enterprise has not completed transition to
IPv6 in all its organic and/or Service Provider networks. Instead,
it maintains a variety of heterogenous network segments between the
communicating applications. Scenarios E and J represent distinctly
different extremes on either end of the spectrum. In scenario E,
the enterprise has largely transitioned to IPv6 in both its
applications and networks. However, scenario E shows that a few
legacy IPv4-based applications may still be found in the
enterprise. On the other hand, scenario J shows an Enterprise that
has begun its transition in a very disjointed manner and, in which
IPv6-based applications and network segments are relatively rare.
A common scenario for IPv6 deployment is the enterprise network 4. Wide-Scale Dual-Stack Deployment Analysis
that wishes to introduce IPv6 by enabling IPv6 on the wire in a
structured fashion with the existing IPv4 infrastructure. In such a
scenario, a number of the existing IPv4 routers (and thus subnets)
will be made dual-stack, such that communications can run over
either protocol.
Nodes within the dual-stack links may themselves be IPv4-only and In this section we address Scenario 1 as described in Section 3.1
IPv6-capable. The driver for deploying IPv6 may not be for of [BSCN]. The scenario, assumptions and requirements are driven
from the [BSCN] text. This analysis further corresponds to
Scenario A in Section 3 above (although Scenario A shows a
transitional situation wherein the enterprise has one network
segment still lagging on transition to dual-IP).
Within these IPv6 deployment scenarios the enterprise network
administrator would introduce IPv6 by enabling IPv6 on the wire
(i.e. within the network infrastructure) in a structured fashion
with the existing IPv4 infrastructure. In such scenarios, a number
of the existing IPv4 routers (and thus subnets) will be made dual-
IP, such that communications can run over either protocol.
Nodes on the dual-IP links may themselves be IPv4-only or IPv6-
capable. The driver for deploying IPv6 on the wire may not be for
immediate wide-scale usage of IPv6, but rather to prepare an immediate wide-scale usage of IPv6, but rather to prepare an
existing IPv4 infrastructure to support IPv6-capable nodes, such existing IPv4 infrastructure to support IPv6-capable nodes. Thus,
that Dual-IP nodes exist, but IPv6 is not used, but exist when IPv6 while IPv6 is not used, dual-IP nodes exist, and the enterprise can
is implemented. be transitioned to IPv6 on demand.
We analyze the scenario against existing transition mechanisms for Analyzing this scenario against existing transition mechanisms for
their applicability, suggesting a staged approach for IPv6 their applicability, suggests a staged approach for IPv6 deployment
deployment in the enterprise. in the enterprise.
4.1 Staged Dual-Stack Deployment 4.1 Staged Dual-Stack Deployment
The site administrator should formulate a staged plan for the Under these scenarios (as well as most others), the site
introduction of dual-stack IPv6 network. We suggest that the administrator should formulate a staged plan for the introduction
generic plan of Section 7 of this document provides a good basis of a dual-IP IPv6 network. We suggest that the generic plan of
for such a plan. Section 7 of this document provides a good basis for such a plan.
The generic plan has a number of stages that are independent of
whether Dual-IP IPv4, or IPv6-dominant networks are selected as a
IP-cabability Transition Implmentation for deployment.
In an enterprise network, the administrator will generally seek to In an enterprise network, the administrator will generally seek to
deploy IPv6 in a structured, controlled manner, such that IPv6 can deploy IPv6 in a structured, controlled manner, such that IPv6 can
be enabled on specific links at specific stages of deployment. It be enabled on specific links at various stages of deployment. There
may be a specific requirement that some links remain IPv4 only, or may be a requirement that some links remain IPv4 only, or some that
specifically should not have IPv6 connectivity. It may also be a specifically should not have IPv6 connectivity (e.g. Scenario A of
requirement that aggregatable global IPv6 addresses, assigned by Table 1). There may also be a requirement that aggregatable global
the enterprise's upstream provider from the address space allocated IPv6 addresses, assigned by the enterprise's upstream provider from
to them by the Regional Internet Registries (RIRs), are used for the address space allocated to them by the Regional Internet
assignment. 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]. The address type and scope selected IPv6 Unicast Addresses [ULA] because the address type and scope
is orthogonal to the the layer 3 analysis in this document. selected is orthogonal to the the layer 3 analysis of this
document.
A typical deployment would involve the establishment of a single A typical deployment would initially involve the establishment of a
"testbed" Dual-IP subnet at the enterprise site, prior to wider single "testbed" Dual-IP subnet at the enterprise site prior to
deployment. Such a testbed not only allows the IPv6 capability of wider deployment. Such a testbed not only allows the IPv6
specific platforms and applications to be evaluated and verified, capability of specific platforms and applications to be evaluated
it also permits the steps in Sections 7.3 and 7.4 of this document and verified, but also permits the steps in Sections 7.3 and 7.4 of
to be undertaken without (potential) adverse impact on the this document to be undertaken without (potential) adverse impact
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 would 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 Analysis of Required Tools for Dual-Stack Deployment 4.2 Routing Capability Analysis for Dual-IP Deployment
The critical part of Dual-IP deployment is the IPv6 routing A critical part of Dual-IP deployment is the selection of the
infrastructure implemented. The path taken will depend on whether IPv6-capable routing infrastructure to be implemented. The path
the enterprise has existing Layer 2/3 switch/router equipment that taken will depend on whether the enterprise has existing Layer 2/3
has an IPv6 (routing) capability, or that can be upgraded to have switch/router equipment that has an IPv6 (routing) capability, or
such capability. that can be upgraded to have such capability.
In Section 4, we are not considering sparse IPv6 deployment; the In Section 4, we are not considering sparse IPv6 deployment; the
goal of Dual-IP deployment is widespread use in the enterprise. goal of Dual-IP deployment is widespread use in the enterprise.
4.3 IPv6 Capability in the Routing Infrastructure 4.2.1 IPv6 Routing Capability
Where IPv6 routing capability exists within the infrastructure, the Where IPv6 routing capability exists within the infrastructure, the
network administrator can enable IPv6 on the same physical hardware network administrator can enable IPv6 on the same physical hardware
as the existing IPv4 service. This is the end goal of any as the existing IPv4 service. This is the end goal of any
enterprise Dual-IP deployment, when the capability, performance, and enterprise to support Dual-IP deployment, when the capability,
robustness of the Dual-IP operational deployment has been verified. performance, and robustness of the Dual-IP operational deployment
has been verified.
Ideally, the IPv6 capability will span the entire enterprise, Ideally, the IPv6 capability will span the entire enterprise,
allowing deployment on any link or subnet. If not, techniques from allowing deployment on any link or subnet. If not, techniques from
Section 4.4 below may be required. Section 4.4 below may be required.
4.4 IPv6 Capability not in the Routing Infrastructure 4.2.2 IPv6 Routing Non-Capability
In this case the enterprise administrator faces two basic choices, If the enterperise cannot provide IPv6 routing initially there are
either to tunnel IPv6 over some or all of the existing IPv4 alternative methods for transition. In this case the enterprise
infrastructure, or to deploy a parallel IPv6 routing infrastructure administrator faces two basic choices, either to tunnel IPv6 over
providing IPv6 connectivity into existing IPv4 subnets. some or all of the existing IPv4 infrastructure, or to deploy a
parallel IPv6 routing infrastructure providing IPv6 connectivity
into existing IPv4 subnets.
It may thus be the case that a nodes IPv4 and IPv6 default routes to It may thus be the case that a nodes IPv4 and IPv6 default routes
reach other links (subnets) are through different routing platforms. to reach other links (subnets) are through different routing
platforms.
4.4.1 Tunnel IPv6 over the IPv4 infrastructure 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure
The tunneling, as described in [BCNF] would be established between Consider the situation where there exists IPv6 edge routers which
Dual-IP capable routers on the enterprise, thus "bypassing" existing are IPv6-capable, while others,and perhaps the enterprise backbone
non IPv6-capable routers and platforms. For example, some IPv6 itself, are not IPv6-capable (Scenario B of Table 1). Tunneling,
edge routers in the enterprise may be IPv6-capable, while others, as described in [BCNF] would be established between the Dual-IP
and perhaps the enterprise backbone itself, are not IPv6-capable. capable routers on the enterprise, thus "bypassing" existing non
IPv6-capable routers and platforms.
In the widespread dual-stack 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 Deploy a parallel IPv6 infrastructure 4.4.2.2 Deploy a parallel IPv6 infrastructure
In this case, the administrator may deploy a new, separate IPv6- Alternatively,the administrator may deploy a new, separate IPv6-
capable router (or set of routers). It is quite possible that such capable router (or set of routers). It is quite possible that such
a parallel infrastructure would be IPv6-dominant. a parallel infrastructure would be IPv6-dominant.
Such an approach can mean acquiring additional hardware, but it has Such an approach would likely require additional hardware, but it
the advantage that the existing IPv4 routing platforms are not has the advantage that the existing IPv4 routing platforms are not
disturbed by the introduction of IPv6. disturbed by the introduction of IPv6.
To distribute IPv6 to the existing IPv4 enterprise subnets, either To distribute IPv6 to existing IPv4 enterprise subnets, either
dedicated physical infrastructure can be deployed or, if it is dedicated physical infrastructure can be employed or, if available,
available, IEEE 802.1q VLANs could be used, as described in [VLAN]. IEEE 802.1q VLANs could be used, as described in [VLAN]. The
The latter has the significant advantage of not requiring any latter has the significant advantage of not requiring any
additional physical cabling/wiring; it offers all the advantages of additional physical cabling/wiring and also offers all the
VLANs for the new dual-stack environment. advantages of VLANs for the new dual-IP environment. Many router
platforms can tag multiple VLAN IDs on a single physical interface
Many router platforms can tag multiple VLAN IDs on a single physical based on the subnet/link the packet is destined for; thus multiple
interface based on the subnet/link the packet is destined for; thus IPv6 links can be collapsed for delivery on a single (or small
multiple IPv6 links can be collapsed for delivery on a single (or number of) physical IPv6 router interfaces in the early stages of
small number of) physical IPv6 router interfaces in the early stages deployment.
of deployment.
The parallel infrastructure would only ever be seen as an interim The parallel infrastructure should only be seen as an interim step
step towards a full Dual-IP deployment on a unified infrastructure. towards full Dual-IP deployment on a unified infrastructure. The
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,
ready for that unifying step at a later date. thus making the enterprise ready for that unifying step at a later
date.
4.5 Remote IPv6 access to the enterprise 4.3 Remote IPv6 access to the enterprise
Where the enterprise's users are off-site, and using an ISP that When the enterprise's users are off-site, and using an ISP that
does not support any native IPv6 service or IPv6 transition aids, does not support any native IPv6 service or IPv6 transition aids,
the enterprise may consider deploying it's own remote IPv6 access the enterprise may consider deploying it's own remote IPv6 access
support, as described in Section 7.5.2. support, as described in Section 7.5.2 below.
4.6 Other considerations 4.4 Other considerations
There are some identified issues with turning IPv6 on by default, There are some issues associated with turning IPv6 on by default,
including application connection delays, poor connectivity, and including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF]. worked around or mitigated by following the advice in [V6DEF]
5 Sparse Dual-Stack Deployment Analysis 5. Sparse Dual-Stack Deployment Analysis
This section covers the Scenario 2 as described in Section 3.1 of This section covers 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
applications need to be upgraded to be IPv6-capable. The routing applications need to be upgraded to be IPv6-capable. The routing
skipping to change at page 12, line 34 skipping to change at page 13, line 34
documents boundaries defined. documents boundaries defined.
The network team needs to decide which are the most efficient the The network team needs to decide which are the most efficient the
available transition tunneling mechanisms to deploy, so they can be available transition tunneling mechanisms to deploy, so they can be
used without disrupting the existing IPv4 infrastructure. Several used without disrupting the existing IPv4 infrastructure. Several
conditions require analysis, as introduced in the following sub conditions require analysis, as introduced in the following sub
sections. sections.
5.1 Internal versus External Tunnel End Point 5.1 Internal versus External Tunnel End Point
Assuming the upstream provider has deployed some IPv6 services, Let's assume the upstream provider has deployed some IPv6 services,
either native IPv6 in its backbone or in the access network, or a either native IPv6 in its backbone or in the access network, or
combination of both. Also, or alternatively, could have deployed some combination of both (Scenario B of Table 1). In this case, the
one or more several transition mechanisms based upon tunnels for provider will likely also deploy one or more transition mechanisms
subscribers. to support their IPv6 subscribers. Obviously, the enterprise could
decide to take advantage of those transition services offered from
for example in the case where the access network doesn't support the Provider. However, this will usually mean that individual nodes
IPv6, the enterprise could decide to use those available transition in the network will require their own IPv6-in-IPv4 tunnel. The end
services from the Provider. However, this will usually mean that result is somewhat inefficient IPv6 intranetworks communication,
individual nodes in the network will have their own IPv6-in-IPv4 because all IPv6 traffic must be forwarded by the Enterprise's IPv4
tunnel. Then, the IPv6 intranetworks communication may not be as infrastructure to the Tunnel End-Point offered by the Provider.
efficient, because it will require all the traffic to be forwarded Nevertheless, this may be acceptable paticularly if the IPv6
by the IPv4 infrastructure to the Tunnel-End-Point located at the applications do not require intranetworks communication at all. For
Provider. This may be acceptable if the IPv6 applications do not example when an application's server is located outside of the
require intranetworks communication at all. For example in the case enterprise network, or on other intranetworks of the same
where the application server is located outside of the enterprise enterprise.
network, or on other intranetworks of the same enterprise.
The enterprise could also decide to deploy its own transition Alternatively, the enterprise could decide to deploy its own
mechanism node, and possibly collocate it adjacent to the border transition mechanism node, possibly collocating it adjacent to the
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 reduced, an option is to If the number of nodes to be using IPv6 is reduced, another option
use statically configured tunnels. is to use statically configured tunnels. However automatically
configured tunnels are generally preferred.
However, in general automatic configured tunnels will be preferred.
Section 5 doesn't yet discuss pros and cons of connecting sparse
nodes, nor management/security issues. We need to add that in -02.
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. driven from the [BSCN] text. Within this document, this situation
is captured in Scenario C of Table 1.
IPv6 deployment in some enterprise networks will use an IPv6- Some enterprise networks may wish to employ an IPv6-dominant
dominant network deployment strategy. What this means essentially network deployment strategy. What this means essentially is that
is that the network or specific sites within the enterprise network the network or specific sites within the enterprise network will
will transition to IPv6 using only IPv6 routing to transfer both transition to IPv6 using only IPv6 routing to transfer both IPv4
IPv4 and IPv6 packets over the network, even though the network is and IPv6 packets over the network, even though the network may be
Dual-IP capable. Dual-IP capable. IPv4 routing would not be turned on within an
IPv6-dominant network, except if required at to support edge IPv4
networks.
IPv6 communications between IPv6 nodes will use IPv6 to Under this scenario, communications between IPv6 nodes will use
communicate. When IPv6-capable nodes in the IPv6-dominant network IPv6. When IPv6-capable nodes in the IPv6-dominant network need to
need to communicate with IPv4 nodes, on the IPv6-dominant network, communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP
the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4 implementation to tunnel IPv4 packets in IPv6 [6TUN]. An edge
packets in IPv6 [6TUN]. An edge router within the IPv6-dominant router within the IPv6-dominant network will decapsulate the IPv4
network will decapsulate the IPv4 packet and route to the path of packet and route to the path of the IPv4 node on the network. This
the IPv4 node on the network. This permits Dual-IP layer nodes to permits Dual-IP layer nodes to communicate with legacy IPv4 nodes
communicate with legacy IPv4 nodes within an IPv6-dominant network. within an IPv6-dominant network.
This section needs more work. From Table 1 scenarios E and F depict additional cases where an
IPv6- dominant deployment strategy could be in place. In scenario
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 network could be IPv6-dominant, but the rest of the networks
are all IPv4.
7 General Issues and Applicability from Analysis In each case, communicating with an IPv4 end host or over an IPv4
network requires a transition point exist within the network to
support that operation. Furthermore, the node in the IPv6 dominant
network must aquire an IPv4 address (to interoperate with the IPv4
end host), and locate a tunnel endpoint on their network which
permits the IPv4 packet to be tunneled to the next hop IPv6 router
and eventually to a destination Dual IP router.
While retaining interoperability with IPv4 is a noble goal for
Enterprise architects, it is an unfortunate fact that maintaining
IPv4 services in an IPv6 dominant networks slows and may even
impede your ability to reap the maximum benefits of IPv6.
The decision whether or not to use an IPv6-dominant network
deployment strategy is completely driven by the Enterprise's
business and operational objectives and guided by the Enterprise's
transition plan.
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.
This section needs more work.
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. plan for IPv6 deployment. What this means is that a strategic
identification of the enterprise network must be performed for all
This section needs more work. points and components of the transition.
7.2 Network Infrastructure Requirements 7.2 Network Infrastructure Requirements
The considerations for the enterprise components are detailed in The considerations for the enterprise components are detailed in
Section 3.2 of [BSCN]. We do not go into detail of all aspects of Section 3.2 of [BSCN]. We do not go into detail of all aspects of
such components in this document. In this document we focus on such components in this document. In this document we focus on
Layer 3 issues. Layer 3 issues.
This section needs more work.
7.3 Stage 1: Initial connectivity steps 7.3 Stage 1: Initial connectivity steps
The first steps for IPv6 deployment do not involve technical The first steps for IPv6 deployment do not involve technical
aspects per se; the enterprise needs to select an external IPv6 aspects per se; the enterprise needs to select an external IPv6
provider, and obtain globally routable IPv6 address space from that provider, and obtain globally routable IPv6 address space from that
provider. provider.
7.3.1 Obtaining external connectivity 7.3.1 Obtaining external connectivity
The enterprise service provider would typically be a The enterprise service provider would typically be a
topographically close (to minimize connectivity RTT) IPv6 provider topographically close IPv6 provider that is able to provide an IPv6
that is able to provide an IPv6 upstream link. upstream link. It would be expected that the enterprise would use
either native IPv6 upstream connectivity or, in its absence, a
It would be expected that the enterprise would use either native manually configured tunnel [BCNF] to the upstream provider.
IPv6 upstream connectivity or, in its absence, a manually
configured tunnel [BCNF] to the upstream provider.
It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] It is not recommended to use 6to4 [6TO4] for an enterprise
for an enterprise deployment. The enterprise has a requirement for deployment. The enterprise has a requirement for long-term, stable
long-term, stable IPv6 connectivity. 6to4 and the tunnel broker IPv6 connectivity. 6to4 is more appropriate for small business,
are more appropriate for SOHO or single node environments. Use of home use, or single node environments. Use of 6to4 also prevents
6to4 also prevents the enterprise adopting aggregatable global IPv6 the enterprise adopting aggregatable global IPv6 addressing from
addressing from the outset. 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].
This section needs more work.
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 Most of these are discussed in Section 4 of [BSCN]. Here we comment
comment on those aspects that we believe are in scope for this on those aspects that we believe are in scope for this analysis
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
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 [DNSV6REC] and
of communicating over IPv6 transport. of communicating over IPv6 transport.
Specific IPv6 DNS issues are reported in [DNSV6]. Specific IPv6 DNS issues are reported in [DNSV6].
This section needs more work.
7.4.2 IPv6 Routing 7.4.2 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.
For internal routing, an appropriate interior routing protocol may For internal routing, an appropriate interior routing protocol may
be deployed. be deployed. IPv6 routing protocols that can be used are as
follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng
IPv6 routing protocols that can be used are as follows: BGP4+ [RIPng].
[BGPv6], IS-IS [ISISv6], OSPFv3 [RFC????) and RIPng [RIPv6].
This section needs more work.
7.4.3 Configuration of Hosts 7.4.3 Configuration of Hosts
An enterprise network will have a number of tools available for An enterprise network will have a number of tools available for
IPv4 address and other configuration information delegation and IPv4 address and other configuration information delegation and
management, including manual configuration, NIS [NIS] or DHCP management, including manual configuration, NIS [NIS] or DHCP
[DHCPv4]. [DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration In an IPv6 enterprise, Stateless Address Autoconfiguration
[ADDRCONF] may be used to configure a host with a global IPv6 [ADDRCONF] may be used to configure a host with a global IPv6
address, a default router, and an on-link prefix information. address, a default router, and an on-link prefix information.
For secure autoconfiguration, the IPsec [IPSEC] or SEND method For secure autoconfiguration, the IPsec [IPSEC] or SEND method
[SEND] can be used. [SEND] can be used.
A stateless configured node wishing to gain other configuration A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateful information (e.g. DNS, NTP servers) will likely need a Stateful
DHCPv6 [DHCPv6] service available. DHCPv6 [DHCPv6] service available.
For nodes configuring via DHCPv6, where DHCPv6 servers are offlink, For nodes configuring using DHCPv6, where DHCPv6 servers are
a DHCPv6 Relay Agent function will be required. offlink, a DHCPv6 Relay Agent function will be required.
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.
This section needs more work continuity.
7.4.4 Developing an IPv6 addressing plan 7.4.4 Developing an IPv6 addressing plan
<to be completed > A site will need to formulate an IPv6 addressing plan, utilising
the globally aggregatable public IPv6 prefix allocated to it by its
upstream connectivity provider.
In a Dual-IP deployment, the site will need to decide whether it
wishes to deploy IPv6 links to be congruent with existing IPv4
subnets. In this case, nodes will fall into the same links or
subnets for both protocols. Such a scheme could be followed, with
IPv6 prefix allocations being made such that room for topological
growth is provisioned (reducing the potential requirement for
future renumbering due to restructuring).
A beneficial property of IPv6 is that an administrator will not
need to invest as much effort in address conservation. With IPv4,
a site will likely allocate IPv4 subnets to be as small as possible
for the number of hosts currently in the subnet (e.g. a /26 for 50
nodes), because IPv4 address conservation is required. This creates
problems when the number of nodes on a subnet grows, larger IPv4
prefixes are then required, and potentially time-consuming and
disruptive renumbering events will follow.
With IPv6, a link can in effect have any number of nodes, allowing
link growth without the need to adjust prefix allocations with the
associated renumbering requirement. The size of the initial site
allocation (currently recommended to be a /48) also is likely to
allow room for site growth without a need to return to the
connectivity provider to obtain more, potentially non-sequential,
address space (as is the case for IPv4 today, with the associated
paperwork and probable delays).
At the time of writing, best practice in IPv6 site address planning
is restricted due to limited wide-scale deployments. Administrators
should allocate /64 size prefixes for subnets, and do so in a way
that has scope for growth within a site. The site should utilise a
plan that reserves space for topological growth in the site, given
that its initial IPv6 prefix allocation (currently recommended to
be a /48) is likely to include such room for growth.
7.4.5 Security 7.4.5 Security
<to be completed - see Pekka's various drafts on 6to4 and others?, When deploying IPv6 within a Dual-IP network, a site will need to
and emphasize use of best practice> implement its site security policy for IPv6-capable nodes as it
does for IPv4-capable nodes. For example, a border firewall
should be capable of filtering and controlling IPv6 traffic by
enforcing the same policy as it already does for IPv4.
However, a site will also need to review its security policy in
light of IPv6 specific functionality that will be deployed in the
site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND),
IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use
of globally aggregatable public address space where for IPv4
private addressing and NAT may have been used.
An overview of how Network Architecture Protection (NAP) using IPv6
can provide the same or more benefits without the need for NAT can
be found in [NAP]. This describes how the perceived security with
IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6
technology can be used to provide the market-perceived benefits of
IPv4 NAT.
Where deployed, intrusion detection systems will need to be
enhanced to both check IPv6 transport for known application layer
attack patterns and also to check for new potential IPv6 threats,
e.g. excessive hop-by-hop headers, or errant IPv6 header options.
The deployment of specific transition mechanisms may also introduce
threats, e.g. carrying IPv6 data tunnelled in IPv4. The site
security policy should embrace the transition mechanisms that are
deployed.
An overview of IPv6 security issues can be found in [V6SEC]. This
includes discussion of issues specific to the IPv6 protocol, to
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
links, and enabling applications and other services to begin using links, and enabling applications and other services to begin using
IPv6 transport. an IPv6 transport.
7.5.1 Deploying IPv6 across the enterprise
In the Dual-IP deployment case, this means enabling IPv6 on In the Dual-IP deployment case, this means enabling IPv6 on
existing IPv4 subnets. It is most likely that the administrator existing IPv4 subnets. As described in Section 7.4.4 above, it is
will deploy IPv6 links to be congruent with existing IPv4 subnets likely that IPv6 links will be congruent with IPv4 subnets, because
(because IPv4 subnets tend to be created for geographic, policy or IPv4 subnets tend to be created for geographic, policy or
administrative reasons that would be IP-independent). administrative reasons that would be IP version-independent.
8 Applicable Transition Mechanisms While the use of IPv6 by some applications can be administratively
controlled (e.g. in the case of open source software by compiling
the application without IPv6 support enabled), the use of IPv6
transport, and preference over IPv4 transport, will vary per
application based on the developer/author's implementation.
This section will provide guidance for the use of specific A Dual-IP deployment will often be made by sites wishing to support
transition mechanisms below that can be used by the enterprise to use of IPv6 within a site, even if IPv6 transport is not preferred
support the enterprise matrix notational networks (rows) in Section by all applications. Putting support for IPv6 in all site
3, and within the context of the analysis discussed in Sections 4, infrastructure (DNS, email transport, etc) allows IPv6 usage to be
5, and 6. phased in over time. As nodes become IPv6 capable, and
applications and services IPv6 enabled, the IPv6 capable
infrastructure can be leveraged. For most networks, Dual-IP will
be at the very least a medium-term transition towards an IPv6
dominant future. However, the introduction of IPv6 support, with
the potential benefits of globally aggregatable public address
usage (with [NAP]), and other new IPv6 capabilities, can bring more
immediate benefits for the site.
Section to be written. 8. Applicable Transition Mechanisms
9 Security Considerations This section will provide general guidance for the use of specific
transition mechanisms which in turn can be used by the enterprise
to support the enterprise matrix notional networks (rows) in
Section 3, and within the context of the analysis discussed in
Sections 4, 5, and 6.
WRITING: Lets do this after we get above writing done. Table 1 provides a number of common scenarios that an enterprise
architect might encounter as they consider how and where they
should consider deploying transition mechanisms to support the
network transition to IPv6. Selecting the most appropriate
mechanism for each scenario is more of an art than a science and
consequently making recommendations against each of the ten
scenarios would be simply fodder for sharpshooters touting their
favored product. However we can provide some high-level guidance
that should benefit the architect's decision making process.
10 References 8.1 Recognizing Incompatible Network touchpoints
10.1 Normative References Mapping your specific situation into one of the ten scenarios of
Table 1 is far less important than recognizing the critical
touchpoints within the enterprise networks where incompatible
networks interface. Unless a transition mechanism is being offered
by the enterprise as a service, it is at these touchpoints that a
mechanism must be considered.
Most of these need to be moved to non-normative reference section A quick review of Table 1 reveals that the ten scenarios can be
and additional references need to be added. boiled down to variations of four major themes. The simplest, but
also most favored (due to its flexibility), is wide spread Dual IP
with compatible hosts at either end. This situation is illustrated
in Scenario A and transition mechanism considerations have already
been described in some detail in Section 4.
In the second common theme (depicted in Scenarios B-D of Table 1),
the enterprise is comprised of compatible hosts, with one or more
incompatible network touchpoints in between. As described in
Section 4.2.2.1, tunneling can be used to "bypass" the incompatible
network segments. One tunneling option, Manual Configured Tunnels
[BCNF] could be used by the enterprise, but as the name implies,
this mechanism provides no automated tunnnel configuration.
6to4 [6to4] can be used to support enterprises that do not have an
assigned IPv6 prefix address.
Identifying the responsible device to perform the tunneling is
driven by the position of the incompatible touchpoint. If a local
network is incompatible than host tunneling is appropriate. If the
backbone (provider) network is incompatible then gateway-to-gateway
tunneling might be a better choice. By working to ensure tunnel
endpoints are always configured at dual-IP devices, end-to-end
communication or services (IPv4 or IPv6) can be preserved.
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.
ISATAP [ISTP] can be used to provide end node IPv6 connectivity
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
[TBRK] 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.
Later in the transition process, after the enterprise has
transitioned to a predominately IPv6 infrastructure, the architect
should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
in the case of early deployment of IPv6-dominant networks DSTM can
be used too.
8.2 Recognizing Application incompatibilities
Having recognized incompatible network touchpoints, it is also
incumbent on the architect to identify application
incompatibilities. During the transition period, particularly for
large enterprises, it is to be expected that applications hosted at
one location may lead (or lag) the IPv6-compability of its peer (or
server) at some other location.
This leads us to the third theme represented by Scenario E and G,
i.e. incompatible applications communicating across a homogenous
network. Translation is an obvious solution, but not recommended
except for legacy devices at the network edge which cannot or never
will be upgraded to IPv6. A more scaleable solution would be to
use an Application Layer Gateways (ALG) between the incompatible
hosts.
8.3 Using Multiple Mechanisms to Support IPv6 Transition
Inevitably, during the course of transitioning a large enterprise
to IPv6, the architect will be faced with both incompatible hosts
and simulataneously (at different parts of the enterprise)
incompatible networks. These highly complex situations represent
the fourth common theme in Table 1 and are specifically depicted by
Scenarios F, H, I and J. Maintaining IP interoperability in these
situations requires additional planning and may require multiple or
even nested use of diverse transition mechanisms. For example, an
ALG co-located with the application server may be required to
service both IPv4 and IPv6 data streams that are simulataneously
tunneled through incompatible network segment(s).
9. Security Considerations
Security considerations for IPv6 deployment in a Dual-IP
environment are discussed above in section 7.4.5, where external
references to overview documents [V6SEC] [NAP] are also included.
10. IANA Considerations
This document has no actions for IANA.
11. References
11.1 Normative References
There are no normative references in this document to depict
correct protocol operation. This document is an analysis technical
effort not a operative or protocol specification.
11.2 Non-Normative References
[DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational [DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in Considerations and Issues with IPv6 DNS", Work in
Progress. Progress.
[CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration" [CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration"
RFC 2462 December 1998. RFC 2462 December 1998.
[DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic [DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July
2003. 2003.
[DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol [DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6" RFC 3756 April 2004. (DHCP) Service for IPv6" RFC 3756 April 2004.
[APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E., [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E.,
"Application Aspects of IPv6 Transition" Work in Progress. "Application Aspects of IPv6 Transition" RFC 3038 March 2005.
[BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios" [BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios"
Work in Pogress. Work in Pogress.
[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.
[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
[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.
[SEC1] Savola, P., Patel, C., "Security Considerations for [SEC1] Savola, P. and Patel, C. "Security Considerations for 6to4"
6to4. Work in Progress. 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
Allocations to Sites" RFC 3177 September 2001. Allocations to Sites" RFC 3177 September 2001.
[NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation - [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)" RFC 2766 February 2000 Protocol Translation (NAT-PT)" RFC 2766 February 2000
[NATDE] Aoun, C., Davies, E., "Reasons to move NAT-PT to Experimental"
Work in Progress.
[UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms [UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms
for Unmanaged Networks". Work in Progress. for Unmanaged Networks". RFC 3904 September 2004.
[ISPA] Lind, M., et al "Scenarios and Analysis for Introducing IPv6 [ISPA] Lind, M., et al "Scenarios and Analysis for Introducing IPv6
into ISP Networks". Work in Progress. into ISP Networks". RFC 4029 March 2005.
[3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks" [3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks"
Work in Progress. Work in Progress.
10.2 Non-Normative References [V6SEC] Davies, E. et al "IPv6 Transition/Co-existence Security
Considerations". Work in Progress.
To be completed in next draft version. [NAP] Van de Velde, G. et al "IPv6 Network Architecture Protection",
Work in Progress.
Changes from -00 t -01 [OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for IPv6"
RFC2740 December 1999.
BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol Extensions for
BGP-4", RFC2283 June 2000.
[ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain Routing Protocol",
RFC1142 February 1990.
[RIPng] Malkin, G., Minnear, R. "RIPng for IPv6"
RFC2080 January 1997
Change Log
March 2005 to June 2005
ID 01 to 02
- Fixed IETF id-nits.
- Updated Section 3 Table 1 and added discussion of intent and
scenario analysis per WG input.
- Completed sections 6, 7, and 8.
- Completed required Security Section.
- 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 IP layer networks and nodes.
networks and nodes.
- Removed Table of Content Campus VLAN appendix place holder.
November 2004 to March 2005
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 discussions to attempt consensus on these initial sections.
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 on - Updated section 3 matrix and description to simplify and focus
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 additional test for descriptions.
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 3. This section still needs to be written.
section still needs to be written.
Document Acknowledgments Document Acknowledgments
The Authors 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. following: IETF v6ops Working Group members, Pekka Savola, and
Jordi Palet.
Author 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.305.3051 Phone: 603.465.3130
Email: jim.bound@hp.com Email: jim.bound@hp.com
Yanick Pouffary Yanick Pouffary
HP Competency Center HP Competency Center
950, Route des Colles, BP027, 950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX 06901 Sophia Antipolis CEDEX
FRANCE FRANCE
Phone: + 33492956285 Phone: + 33492956285
Email: Yanick.pouffary@hp.com Email: Yanick.pouffary@hp.com
skipping to change at page 23, line 38 skipping to change at page 26, line 38
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
David Green David Green
SRI International SRI International
333 Ravenswood Ave 333 Ravenswood Ave
Menlo Park, CA 94025-3493 Menlo Park, CA 94025-3493
USA USA
Phone: 732 532-6715 Phone: 732 532-6715
Email: david.green@sri.com Email: david.green@sri.com
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Madrid, SPAIN
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
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
fi Copyright (C) The Internet Society (2005)
Appendix A - Campus Deployment Scenario with VLANs This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
To be completed in next drafts. 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."
Appendix B - Crisis Management Network Scenarios 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
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 introduction of IPv6 into a crisis management network for emergency
emergency services, defense, or security forces that are currently services, defense, or security forces that are currently running
running IPv4 service. Then, the scenarios for introducing IPv6 are IPv4 service. Then, the scenarios for introducing IPv6 are analyzed
analyzed and the relevance of already defined transition mechanisms and the relevance of already defined transition mechanisms are
are evaluated. Known challenges are also identified. evaluated. Known challenges are also identified.
When a crisis management enterprise deploys IPv6, its goal is to When a crisis management enterprise deploys IPv6, its goal is to
provide IPv6 provide IPv6 connectivity on it's institutional fixed networks and
connectivity on it's institutional fixed networks and on the mobile on the mobile wireless services that are deployed to a crisis area.
wireless The new IPv6 service must be added to an already existing IPv4
services that are deployed to a crisis area. The new IPv6 service must service, the introduction of IPv6 must not interrupt this IPv4
be added to an already existing IPv4 service, the introduction of service, and the IPv6 services must be interoperable with existing
IPv6 must not interrupt this IPv4 service, and the IPv6 services must IPv4 services.
be interoperable with existing IPv4 services.
Crisis management enterprises accessing IPv4 service across mobile Crisis management enterprises accessing IPv4 service across mobile
ground ground networks, airborne networks, and satellites will find
networks, airborne networks, and satellites will find different ways to different ways to add IPv6 to this service based on their network
add architecture, funding, and institutional goals. This document
IPv6 to this service based on their network architecture, funding, discusses a small set of scenarios representing the architectures
and institutional goals. This document discusses a small set of for IPv6 expected to be dominant in crisis management networks
scenarios representing the architectures for IPv6 expected to be during the next decade. It evaluates the relevance of the existing
dominant transition mechanisms in the context of these deployment scenarios,
in crisis management networks during the next decade. It evaluates the and points out the lack of essential functionality in these methods
relevance of the existing transition mechanisms in the context of to the ISP's operation of an IPv6 service.
these deployment scenarios, and points out the lack of essential
functionality in these methods 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 IPv6-only networks. It is outside the scope of this document to
networks. It is outside the scope of this document to describe detailed describe detailed implementation plans for IPv6 in defense networks
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. infrastructure. Enterprise with an existing IPv4 network wants to
Enterprise with an existing IPv4 network wants to deploy a set of deploy a set of particular IPv6 "applications" and have some
particular ability to interoperate with other institutions that are using IPv6
IPv6 "applications" and have some ability to interoperate with other services. The IPv6 deployment is limited to the minimum required to
institutions that are using IPv6 services. The IPv6 deployment is operate this set of applications.
limited
to the minimum required to operate this set of applications.
Assumptions: IPv6 software/hardware components for the application are Assumptions: IPv6 software/hardware components for the application
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 hosts Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable
and network infrastructure. Enterprise with an existing hosts and network infrastructure. Enterprise with an existing IPv4
IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network
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, international capabilities and to be interoperable with other agencies,
partners, and commercial enterprises that are deploying an IPv6 international partners, and commercial enterprises that are
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 all infrastructure in IPv4. It may not be feasible to deploy IPv6 on
parts of all parts of the network immediately. Dual stacked defense
the network immediately. Dual stacked defense enterprise network enterprise network must be interoperable with both IPv4 and IPv6
must be interoperable with both IPv4 and IPv6 networks and networks and applications.
applications.
Scenario 3: ..............................IPv6 Dominant Network Scenario 3: ..............................IPv6 Dominant Network
Enterprise has some limited IPv4-capable/only nodes/applications Enterprise has some limited IPv4-capable/only nodes/applications
needing to needing to communicate over the IPv6 infrastructure. Crisis
communicate over the IPv6 infrastructure. Crisis management enterprise management enterprise re-structuring an existing network, decides
re-structuring an existing network, decides to pursue aggressive IPv6 to pursue aggressive IPv6 transition as an enabler for network-
transition as an enabler for network-centric services and wants to run centric services and wants to run some native IPv6-only networks to
some native IPv6-only networks to eliminate cost/complexity of eliminate cost/complexity of supporting a dual stack. Some legacy
supporting a IPv4 capable nodes/applications within the enterprise will have
dual stack. Some legacy IPv4 capable nodes/applications within the slow technical refresh/replacement path and will need to
enterprise communicate over the IPv6 dominant infrastructure for years until
will have slow technical refresh/replacement path and will need to they are replaced. The IPv6 dominant enterprise network will need
communicate to be interoperable with it's own legacy networks, commercial
over the IPv6 dominant infrastructure for years networks, and the legacy networks of similar organizations that
until they are replaced. The IPv6 dominant enterprise network will need will remain IPv4 dominant during a long transition period. Reserve
to be units, contractors, other agencies, and international partners may
interoperable with it's own legacy networks, commercial networks, and need IPv4 service across this enterprise's IPv6 dominant backbone.
the
legacy networks of similar organizations that will remain IPv4 dominant
during a long transition period. Reserve units, contractors, other
agencies,
and international partners may need IPv4 service across this
enterprise's
IPv6 dominant backbone.
Assumptions: Required IPv6 network infrastructure is available, or Assumptions: Required IPv6 network infrastructure is available, or
available available over some defined timeline, supporting the aggressive
over some defined timeline, supporting the aggressive transition plan. transition plan.
Requirements:Reduce operation and maintenance requirements and Requirements:Reduce operation and maintenance requirements and
increase increase
net-centricity through aggressive IPv6 transition. Interoperation and net-centricity through aggressive IPv6 transition. Interoperation
coexistence with legacy IPv4 networks and applications is required. and coexistence with legacy IPv4 networks and applications is
Legacy required. Legacy IPv4 nodes/applications/networks will need to be
IPv4 nodes/applications/networks will need to be able to operate across able to operate across the IPv6 backbone and need to be able to
the interoperate with the IPv6-dominant network's nodes/applications.
IPv6 backbone and need to be able to 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 various A generic network topology for a crisis management reflects the
ways various ways a crisis management network can connect customers
a crisis management network can connect customers through their network through their network infrastructure. Because the institution's
infrastructure. Because the institution's existing wired and fixed site existing wired and fixed site wireless infrastructure can be
wireless destroyed or unavailable in a crisis, the crisis management network
infrastructure can be destroyed or unavailable in a crisis, the crisis must be able to deploy it's own mobile wireless network or connect
management network must be able to deploy it's own mobile wireless through external wired and wireless networks provided by ISPs or
network partner organizations. This infrastructure lets us divide the
or connect through external wired and wireless networks provided by basic areas for IPv4/IPv6 interoperability into three main areas:
ISPs or the customer applications, the local network, and the network
partner organizations. This infrastructure lets us divide the basic backbone.
areas
for IPv4/IPv6 interoperability into three main areas:
the customer applications, the local network, and the network 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 page 29, line 4 skipping to change at line 1480
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
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.
Intellectual Property and Copyright Statements
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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