draft-ietf-v6ops-ent-analysis-00.txt   draft-ietf-v6ops-ent-analysis-01.txt 
IPv6 Operations Working Group IPv6 Operations Working Group
Internet Draft Jim Bound Internet Draft Jim Bound (Editor)
Document: draft-ietf-v6ops-ent-analysis-00.txt Yanick Pouffary Document: draft-ietf-v6ops-ent-analysis-01.txt HP
Obsoletes: None HP Obsoletes: ietf-v6ops-ent-analysis-00.txt
Expires: March 2005 Tim Chown Expires: June 2005
University of Southampton
David Green
SRI
Jordi Palet
Consulintel
Steve Klynsma
Mitre
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-00.txt> <draft-ietf-v6ops-ent-analysis-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668. accordance with RFC 3668.
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-
skipping to change at page 1, line 43 skipping to change at page 1, line 36
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/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 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 units and analysis will focus on a base set of transition notational networks
requirements expanded from a previous Enterprise Scenarios and requirements expanded from a previous Enterprise Scenarios
document, and will depict a set of components and transition document. Discussion is provided on a focused set of transition
methods required for the enterprise to transition to IPv6 within analysis required for the enterprise to transition to IPv6,
each scenario and then common to all scenarios. assuming a dual IP layer (IPv4 and IPv6) network and node
environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network.
Table of Contents: 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.............................8 4 Wide-Scale Dual-Stack Deployment Analysis....................9
4.1 Phased Dual-Stack Deployment...............................8 4.1 Staged Dual-Stack Deployment...............................9
4.2 Analysis of Required Tools for Dual-Stack Deployment.......9 4.2 Analysis of Required Tools for Dual-Stack Deployment......10
4.3 IPv6-Capable Existing Routing Infrastructure Available.....9 4.3 IPv6 Capability in the Routing Infrastructure.............10
4.4 No IPv6-Capable Existing Routing Infrastructure............9 4.4 IPv6 Capability not in the Routing Infrastructure.........10
4.4.1 Tunnel IPv6 over the IPv4 infrastructure.................9 4.4.1 Tunnel IPv6 over the IPv4 infrastructure................10
4.4.2 Deploy a parallel IPv6 infrastructure...................10 4.4.2 Deploy a parallel IPv6 infrastructure...................11
4.5 Remote IPv6 access to the enterprise......................10 4.5 Remote IPv6 access to the enterprise......................11
4.6 Other considerations......................................10 4.6 Other considerations......................................11
5 Sparse Dual-Stack Deployment................................11 5 Sparse Dual-Stack Deployment Analysis.......................12
5.1 Internal versus External Tunnel-End-Point.................11 5.1 Internal versus External Tunnel End Point.................12
5.2 Manual versus Autoconfigured..............................12 5.2 Manual versus Autoconfigured..............................13
6 IPv6 Dominant Network Deployment............................13 6 IPv6 Dominant Network Deployment Analysis...................14
7 General issues and applicability for all Scenarios..........14 7 General Issues and Applicability from Analysis..............15
7.1 Phased Plan for IPv6 Deployment............................14 7.1 Staged Plan for IPv6 Deployment............................15
7.2 Network Infrastructure Requirements.......................14 7.2 Network Infrastructure Requirements.......................15
7.3 Phase 1: Initial connectivity steps........................14 7.3 Stage 1: Initial connectivity steps........................15
7.3.1 Obtaining external connectivity..........................14 7.3.1 Obtaining external connectivity..........................15
7.3.2 Obtaining global IPv6 address space......................15 7.3.2 Obtaining global IPv6 address space......................16
7.4 Phase 2: Deploying generic basic service components........15 7.4 Stage 2: Deploying generic basic service components........16
7.4.1 IPv6 DNS.................................................15 7.4.1 IPv6 DNS.................................................16
7.4.2 IPv6 Routing............................................15 7.4.2 IPv6 Routing............................................16
7.4.3 Configuration of Hosts..................................16 7.4.3 Configuration of Hosts..................................17
7.4.4 Developing an IPv6 addressing plan......................16 7.4.4 Developing an IPv6 addressing plan......................17
7.4.5 Security................................................16 7.4.5 Security................................................17
7.4.6 IPv4-IPv6 interworking..................................17 7.5 Stage 3: Widespread Dual-Stack deployment on-site.........18
7.5 Phase 3: Widespread Dual-Stack deployment on-site.........17 7.5.1 Deploying IPv6 across the enterprise....................18
7.5.1 Deploying IPv6 across the enterprise....................17
7.5.2 Supporting remote access................................17
8 Applicable Transition Mechanisms............................19 8 Applicable Transition Mechanisms............................19
9 Security Considerations.....................................21 9 Security Considerations.....................................20
10 References.................................................21 10 References.................................................20
10.1 Normative References.....................................21 10.1 Normative References.....................................20
10.2 Non-Normative References.................................22 10.2 Non-Normative References.................................21
Changes from -00 t -01.........................................21
Document Acknowledgments.......................................22 Document Acknowledgments.......................................22
Author's Address...............................................23 Author Addresses...............................................23
Appendix A - Campus Deployment Scenario with VLANs.............24 Appendix A - Campus Deployment Scenario with VLANs.............23
Appendix B - Crisis Management Network Scenarios...............25 Appendix B - Crisis Management Network Scenarios...............24
Intellectual Property and Copyright Statements.................30 Intellectual Property and Copyright Statements.................29
1 Introduction 1 Introduction
NOTE to v6ops WG: This draft is mainly to get consensus on section
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 units and analysis will focus on a base set of transition notational networks
requirements expanded from a previous Enterprise Scenarios and requirements expanded from a previous Enterprise Scenarios
document, and will depict a set of components and transition document. Discussion is provided on a focused set of transition
methods required for the enterprise to transition to IPv6 within analysis required for the enterprise to transition to IPv6,
each scenario and then common to all scenarios. assuming a dual IP layer (IPv4 and IPv6) network and node
environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network.
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
scenarios presented provide an example set of cases the enterprise analysis and notational networks presented provide an example set
can use to build an IPv6 network scenario. of cases the enterprise can use to build an IPv6 transition
strategy.
The enterprise analysis will begin by describing a matrix tool to The enterprise analysis will begin by describing a matrix as a tool
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 first column (Application/Host 1 OS) represents the deployment. The document will then provide analysis to support a
IP-capability offered by the node that originates IP packets. The wide dual IP layer deployment strategy across the enterprise, to
second to last column (Application/Host 2 OS) represents the IP- provide the reader a view of how that can be planned and what is
capability offered by the node that terminates the IP packet. In options are available. The document will then discuss the
between are three columns that represent the IP-capability of deployment of sparse IPv6 nodes within the enterprise and what
typical networks traversed by the packet, including an originating requirements need to be considered and implemented, when the
host network (Host 1 Network),Service Provider Network and enterprise will remain with IPv4-only routing infrastructure for
Destination Host Network (Host 2 Network). Each row (1 through 13) some time. The next discussion focuses on the use of IPv6 when it
is one possible scenario and the final column shows the recommended is determined to be dominant across or within parts of the
transition mechanism to use for that particular scenario. enterprise network.
The objective of this document is to take the [BSCN] scenarios and The document then begins to discuss the the general issues and
then integrate those with a basic unit transition set in the course applicability from the previous analysis. The document concludes
of this analysis to provide a set of options for an enterprise, providing a set of recommendations for each notational network
where one size does not fit all. within the matrix based on the previous analysis, issues and
applicability discussion, adding additional analysis useful for an
enterprise planning to deploy IPv6.
Will expand on this part of the introduction in next draft. This document, as stated in the introduction, focuses only on the
deployment cases where a dual IP layer is supported across the
network and on the nodes in the enterprise. Additional deployment
transition analysis will be required from the effects of IPv6-only
node or Provider deployments, and beyond the scope of this
document. In addition this document does not attempt to define or
discuss any use with network address translation or 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. MIPv6 - Deployment of novel IPv6 services, e.g. Mobile IPv6
- +others?? - Requirements or Transtion at the Providers network
- Transport protocol selection for applications with IPv6
- Application layer and configuration issues.
- IPv6 only future deployment scenarios.
Thus, we are focusing in this document on Layer 3 deployment, in We are focusing in this document on Layer 3 deployment, in the same
the same way as the other IPv6 deployment scenario texts have done 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. enterprise network. Much of the analysis is applicable to wireless
networks, but there are additional considerations for wireless
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 Section 3 we introduce and define an enterprise matrix and In Section 3 we introduce and define a tools matrix and define the
define the layer 3 connectivity requirements. In Section 4 we layer 3 connectivity requirements. In Section 4 we discuss wide
discuss wide scale dual-stack use within an enterprise. In section scale dual IP layer use within an enterprise. In section 5 we
5 we discuss sparse dual-stack deployment within an enterprise. In discuss sparse dual IP layer deployment within an enterprise. In
section 6 we discuss IPv6 dominant network deployment within the section 6 we discuss IPv6 dominant network deployment within the
enterprise. In section 8 we analyze the applicable transition enterprise. In sectioin 7 we discuss general issues and
mechanisms to support the matrix defined in Section 1 referencing applicability. In section 8 a set of deployment analysis is
the discussions in Sections 4, 5, 6, and 7. provided and recommendations.
This document then provides Appendix A for readers depicting a
Crisis Management enterprise network to demonstrate an enterprise
network example that requires all the properties as analyzed in
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.
IPv6 Capable - A node or network capable of supporting both IPv6-capable - A node or network capable of supporting both
IPv6 and IPv4. IPv6 and IPv4.
IPv4 only - A node or network capable of supporting only IPv4-only - A node or network capable of supporting only
IPv4. IPv4.
IPv6 only - A node or network capable of supporting only IPv6-only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only IPv6. This does not imply an IPv6 only
stack, in this document. stack, in this document.
IPv6 Dominant - A network or link that uses only IPv6 routing. Dual-IP - References a network or node that supports both
Network IPv4 and IPv6.
IP-capability - The ability to support IPv6 only, IPv4 only,
or Dual IP Layer
IPv6-dominant - A network or link that uses only IPv6 routing.
Transition - The network strategy the enterprise uses to
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 layer 3 enterprise analysis context for discussion we
provide for this document the use of a matrix with most common provide for this document the use of a matrix with a common set of
transition scenarios to exist for the enterprise. enterprise notational networks resulting from a selected Transition
Implementation chosen for the enterprise. The notional networks
are comprised of hosts attached to an enterprise-owned intranet(s)
at two different global locations separated by the Internet. The
enterprise owns, operates and maintains its own intranetworks, but
relies on an external provider organization that offers Internet
Service. Both local and destination intranetworks are operated by
different organizations within the same enterprise and consequently
could use different IP-capability, than other intranetworks, at
certain times in the transition period.
Table 1 below is a matrix of thirteen possible transition scenarios Addressing every possible combination of network IP-capability in
that may be encountered in the enterprise. The first column this notional enterprise network is impractical, therefore trivial
(Application/Host 1 OS) represents the IP-capability offered by the (i.e. pure IPv4, pure IPv6, ubiquitous dual-IP and straight forward
node that originates IP packets. The second to last column tunneling or translation at local or destination hosts) are not
(Application/Host 2 OS) represents the IP-capability offered by the considered. In addition, the authors could not conceive of any
node that terminates the IP packet. In between are three columns scenarios involving IPv6-only ISPs or IPv6-only nodes in the near-
that represent the IP-capability of typical networks traversed by term and consequently have not addressed scenarios with IPv6-only
the packet, including an originating host network (Host 1 ISPs or IPv6-only nodes. We assume all nodes that use IPv6
Network),Service Provider Network and Destination Host Network applications are Dual IP. The matrix does not assume or suggest
(Host 2 Network). that network address translation is used. The authors recommend
that network address translation not be used in these notational
cases.
As an example, Scenario 1 is an IPv6 application trying to Future enterprise transitions that will support IPv6-only nodes and
establish a communications exchange with a destination v4 only IPv6-only ISPs will be a separate analysis required, that is beyond
application. Since proper porting of the application to the host the scope of this document.
is a prerequisite, the IP-capability of the operating system at
both originating and destination host is not specifically addressed Table 1 below is a matrix of nine possible Transition
herein. To complete the information exchange the packets must Implementations that may be selected in an enterprise, which
first traverse the host's originating IPv4 network, then the require analysis and the selection of an IPv6 transition mechanism
service provider's dual-IP network and finally, the destination for that notational network, which are the rows of the matrix. The
host's network. matrix describes a set of notational networks as follows:
- The first column represents the protocol used by the
application and below the IP-capability of the node
originating the IP packets.
(Application/Host 1 OS).
- The second column represents the IP-capability of the
network where the node originated the packet.
(Host 1 Network)
- The third column represents the IP-capability of the
service provider network.
(Service Provider)
- The fourth column represents the IP-capability of the
destination network where the originating IP packets
are received.
(Host 2 Network)
- The fifth column represents the protocol used by the
application and below the IP-capability of the
destination node receiving the originating IP packets.
(Application/Host 2 OS).
As an example, notational network 1 is an IPv6 application residing
on a dual IP layer host trying to establish a communications
exchange with a destination IPv6 application. To complete the
information exchange the packets must first traverse the host's
originating IPv4 network (intranet), then the service provider's,
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 scenarios (such as pure IPv4, pure IPv6, and straight-
forward tunneling or translation) are not addressed. Instead we Trivial notational networks (such as pure IPv4, pure IPv6, and
will use these thirteen to address the analysis for enterprise straight-forward tunneling or translation) are not addressed.
deployment. 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 IPv6|Dual IP| |Dual IP|IPv6 IPv6| | IPv6 | | | | IPv6 |
1 |---- or ----| or |Dual IP | or |---- or ----| 1 | ---- | IPv4 |Dual IP |Dual IP| ---- |
|IPv6 Dual|v6 Only| |v6 only|IPv6 Dual| | Dual IP | | | | Dual IP |
====================================================== ======================================================
|IPv4 IPv4| | | |IPv4 IPv4| | IPv6 | | | | IPv6 |
2 |---- or ----|Dual IP|Dual IP |Dual IP|---- or ----| 2 | ---- | IPv4 |Dual IP | IPv4 | ---- |
|IPv4 Dual| | | |IPv4 Dual| | Dual IP | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv6 | | IPv6 | | | | IPv6 |
3 | ---- | IPv4 |Dual IP |Dual IP| ---- | 4 | ---- |Dual IP|Dual IP | IPv4 | ---- |
| Dual | | | | IPv6 | | Dual IP | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | |IPv4 IPv4| | IPv6 | | | | IPv6 |
4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----| 4 | ---- |Dual IP| IPv4 |Dual IP| ---- |
| Dual | | | |IPv4 Dual| | Dual IP | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv6 | | IPv6 | | | | IPv6 |
5 | ---- | IPv4 | IPv4 |Dual IP| ---- | 5 | ---- | IPv4 | IPv4 |Dual IP| ---- |
| Dual | | | | IPv6 | | Dual IP | | | | Dual IP |
======================================================
|IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|
6 |---- or ----| or | IPv4 | or |---- or ----|
|IPv6 Dual|v6 only| |v6 only|IPv6 Dual|
======================================================
| IPv6 |Dual IP| IPv4, | | IPv4 |
7 | ---- | or | IPv6 or| IPv4 | ---- |
| IPv6 |v6 only|Dual IP | | IPv4 |
======================================================
| IPv6 |Dual IP| None - | | IPv4 |
8 | ---- | or | Local | IPv4 | ---- |
| IPv6 |v6 only| Connect| | IPv4 |
====================================================== ======================================================
| IPv4 | | | | IPv4 | | IPv4 | | | | IPv4 |
9 | ---- | IPv4 |v6 only | IPv4 | ---- | 6 | ---- | IPv6 |Dual IP |Dual IP| ---- |
| IPv4 | | | | IPv4 | | Dual IP | | | | IPv4 |
======================================================
| Dual | | | | IPv4 |
10| ---- |Dual IP| v6 Only| IPv4 | ---- |
| Dual | | | | IPv4 |
====================================================== ======================================================
| Dual | | | | IPv4 | | IPv4 | | | | IPv4 |
11| ---- |v6 only| v6 only| IPv4 | ---- | 7 | ---- | IPv6 | IPv4 | IPv6 | ---- |
| Dual | | | | IPv4 | | Dual IP | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv6 | | IPv4 | | | | IPv4 |
12| ---- |Dual IP|v6 only |Dual IP| ---- | 8 | ---- | IPv4 |Dual IP | IPv6 | ---- |
| Dual | | | | Dual | | IPv4 | | | | Dual IP |
====================================================== ======================================================
| IPv6 | | | | IPv6 | | IPv4 | | | | IPv4 |
13| ---- |v6 only|v6 only |v6 only| ---- | 9 | ---- | IPv4 | IPv4 | IPv6 | ---- |
| IPv6 | | | | IPv6 | | IPv4 | | | | Dual IP |
====================================================== ======================================================
4 Wide-Scale Dual-Stack Deployment 4 Wide-Scale Dual-Stack Deployment Analysis
In this section we are covering Scenario 1 as described in Section In this section we are covering Scenario 1 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.
A common scenario for IPv6 deployment is the enterprise network A common scenario for IPv6 deployment is the enterprise network
that wishes to introduce IPv6 by enabling IPv6 on the wire in a that wishes to introduce IPv6 by enabling IPv6 on the wire in a
structured fashion with the existing IPv4 infrastructure. In such structured fashion with the existing IPv4 infrastructure. In such a
a scenario, a number of the existing IPv4 routers (and thus scenario, a number of the existing IPv4 routers (and thus subnets)
subnets) will be made dual-stack, such that communications can run will be made dual-stack, such that communications can run over
over either protocol. either protocol.
Nodes within the dual-stack links may themselves be IPv4-only, Nodes within the dual-stack links may themselves be IPv4-only and
IPv6-only or dual-stack. The driver for deploying IPv6 may not be IPv6-capable. The driver for deploying IPv6 may not be for
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 with IPv6 capability, such that dual- existing IPv4 infrastructure to support IPv6-capable nodes, such
stack nodes, or later IPv6-only nodes, can be deployed. that Dual-IP nodes exist, but IPv6 is not used, but exist when IPv6
is implemented.
We analyze the scenario against existing transition mechanisms for We analyze the scenario against existing transition mechanisms for
their applicability, suggesting a phased approach for IPv6 their applicability, suggesting a staged approach for IPv6
deployment in the enterprise. deployment in the enterprise.
4.1 Phased Dual-Stack Deployment 4.1 Staged Dual-Stack Deployment
The site administrator should formulate a phased plan for the The site administrator should formulate a staged plan for the
introduction of dual-stack IPv6 network. We suggest that the introduction of dual-stack IPv6 network. We suggest that the
generic plan of Section 7 of this document provides a good basis generic plan of Section 7 of this document provides a good basis
for such a plan. for such a plan.
The generic plan has a number of stages/phases that are independent The generic plan has a number of stages that are independent of
of whether dual-stack or IPv6-dominant deployment is undertaken. 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 specific stages of deployment. It
may be a specific requirement that some links remain IPv4 only, or may be a specific requirement that some links remain IPv4 only, or
specifically should not have IPv6 connectivity. It may also be a specifically should not have IPv6 connectivity. It may also be a
requirement that aggregatable global IPv6 addresses, assigned by requirement that aggregatable global IPv6 addresses, assigned by
the enterprise's upstream provider from the address space allocated the enterprise's upstream provider from the address space allocated
to them by the Regional Internet Registries (RIRs), are used for to them by the Regional Internet Registries (RIRs), are used for
assignment. assignment.
In this document we do not advocate or discuss the deployment of In this document we do not discuss the deployment of Unique Local
Unique Local IPv6 Unicast Addresses [ULA]. We do strongly suggest IPv6 Unicast Addresses [ULA]. The address type and scope selected
that IPv6 NAT is not deployed, as doing so negates the key is orthogonal to the the layer 3 analysis in this document.
advantages of moving to the new Internet Protocol version.
A typical deployment would involve the establishment of a single A typical deployment would involve the establishment of a single
"testbed" IPv6 capable subnet at the enterprise site, prior to "testbed" Dual-IP subnet at the enterprise site, prior to wider
wider deployment. Such a testbed not only allows the IPv6 deployment. Such a testbed not only allows the IPv6 capability of
capability of specific platforms and applications to be evaluated specific platforms and applications to be evaluated and verified,
and verified, it also allows the steps in Sections 7.3 and 7.4 of it also permits the steps in Sections 7.3 and 7.4 of this document
this document to be undertaken without (potential) adverse impact to be undertaken without (potential) adverse impact on the
on the production elements of the enterprise. 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 would be undertaken after the basic building
blocks for deployment are in place. blocks for IPv6 deployment are in place.
4.2 Analysis of Required Tools for Dual-Stack Deployment 4.2 Analysis of Required Tools for Dual-Stack Deployment
The critical part of the dual-stack deployment is the IPv6 routing The critical part of Dual-IP deployment is the IPv6 routing
infrastructure. The path taken will depend on whether the infrastructure implemented. The path taken will depend on whether
enterprise has existing Layer 2/3 switch/router equipment that has the enterprise has existing Layer 2/3 switch/router equipment that
an IPv6 (routing) capability, or that can be upgraded to have such has an IPv6 (routing) capability, or that can be upgraded to have
capability. 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-stack deployment is widespread use in the enterprise. goal of Dual-IP deployment is widespread use in the enterprise.
4.3 IPv6-Capable Existing Routing Infrastructure Available 4.3 IPv6 Capability in the Routing Infrastructure
Where IPv6 routing capability exists in existing 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-stack deployment, when the capability, performance, enterprise Dual-IP deployment, when the capability, performance, and
and robustness of the dual-stack operational deployment is verified. 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 at 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 No IPv6-Capable Existing Routing Infrastructure 4.4 IPv6 Capability not in the Routing Infrastructure
In this case the enterprise administrator faces two basic choices, In this case the enterprise administrator faces two basic choices,
either to tunnel IPv6 over some or all of the existing IPv4 either to tunnel IPv6 over some or all of the existing IPv4
infrastructure, or to deploy a parallel IPv6 routing infrastructure infrastructure, or to deploy a parallel IPv6 routing infrastructure
providing IPv6 connectivity into existing IPv4 subnets. providing IPv6 connectivity into existing IPv4 subnets.
It may thus be the case that a nodes IPv4 and IPv6 default routes It may thus be the case that a nodes IPv4 and IPv6 default routes to
off-link are through different routing platforms. reach other links (subnets) are through different routing platforms.
4.4.1 Tunnel IPv6 over the IPv4 infrastructure 4.4.1 Tunnel IPv6 over the IPv4 infrastructure
The tunneling, as described in [BCNF] would be established between The tunneling, as described in [BCNF] would be established between
dual-stack capable routers on the enterprise, thus "bypassing" Dual-IP capable routers on the enterprise, thus "bypassing" existing
existing non IPv6-capable routers and platforms. For example, some non IPv6-capable routers and platforms. For example, some IPv6
IPv6 edge routers in the enterprise may be IPv6 capable, while edge routers in the enterprise may be IPv6-capable, while others,
others, and perhaps the enterprise backbone itself, are not. and perhaps the enterprise backbone itself, are not IPv6-capable.
In the widespread dual-stack scenario, a more structured, manageable In the widespread dual-stack 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-subnet 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 Deploy a parallel IPv6 infrastructure
In this case, the administrator may deploy a new, separate IPv6- In this case, 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 only. a parallel infrastructure would be IPv6-dominant.
Such an approach means acquiring additional hardware, but it has the Such an approach can mean acquiring additional hardware, but it has
advantage that the existing IPv4 routing platforms are not disturbed the advantage that the existing IPv4 routing platforms are not
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 the existing IPv4 enterprise subnets, either
dedicated physical infrastructure can be deployed or, if it is dedicated physical infrastructure can be deployed or, if it is
available, IEEE 802.1q VLANs could be used, as described in [VLAN]. available, IEEE 802.1q VLANs could be used, as described in [VLAN].
The latter has the significant advantage of not requiring any The latter has the significant advantage of not requiring any
additional physical cabling/wiring; it offers all the advantages of additional physical cabling/wiring; it offers all the advantages of
VLANs for the new dual-stack environment. VLANs for the new dual-stack environment.
Many router platforms can tag multiple VLAN IDs on a single physical Many router platforms can tag multiple VLAN IDs on a single physical
interface based on the subnet/link the packet is destined for; thus interface based on the subnet/link the packet is destined for; thus
multiple IPv6 links can be collapsed for delivery on a single (or multiple IPv6 links can be collapsed for delivery on a single (or
small number of) physical IPv6 router interfaces in the early stages small number of) physical IPv6 router interfaces in the early stages
of deployment. of deployment.
The parallel infrastructure would only ever be seen as an interim The parallel infrastructure would only ever be seen as an interim
step towards a full dual-stack deployment on a unified step towards a full Dual-IP deployment on a unified infrastructure.
infrastructure. The parallel infrastructure however allows all The parallel infrastructure however allows all other aspects of the
other aspects of the IPv6 enterprise services to be deployed, IPv6 enterprise services to be deployed, including IPv6 addressing,
including IPv6 addressing, ready for that unifying step at a later ready for that unifying step at a later date.
date.
4.5 Remote IPv6 access to the enterprise 4.5 Remote IPv6 access to the enterprise
Where the enterprise's users are off-site, and using an ISP that Where 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.
4.6 Other considerations 4.6 Other considerations
There are some identified issues with turning IPv6 on by default, There are some identified issues 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].
<more to go here> 5 Sparse Dual-Stack Deployment Analysis
5 Sparse Dual-Stack Deployment
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 with 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 a dual-stack. The routing applications need to be upgraded to be IPv6-capable. The routing
infrastructure will not be upgraded to support IPv6, nor does the infrastructure will not be upgraded to support IPv6, nor does the
enterprise wish to deploy a parallel IPv6 routing infrastructure at enterprise wish to deploy a parallel IPv6 routing infrastructure at
this point, since this is an option in section 4. this point, since this is an option in section 4.
The lack of existing IPv6-enabled routing infrastructure implies There is a need for end-to-end communication with IPv6, but the
the usage of IPv4 and IPv6 in the nodes. There is a need for end- infrastructure only supports IPv4 routing. Thus, the only viable
to-end communication with IPv6, but the infrastructure only method for end-to-end communication with IPv6 is to tunnel the
supports IPv4 transport. Thus the only viable method for end-to-end traffic over the existing IPv4 infrastructure, within this analysis
communication with IPv6 is to tunnel the traffic over the existing documents boundaries defined.
IPv4 infrastructure.
The network team needs to decide which is the most efficient among The network team needs to decide which are the most efficient the
the available transition tunneling mechanisms to deploy, so they available transition tunneling mechanisms to deploy, so they can be
can be used without disrupting the existing IPv4 infrastructure. used without disrupting the existing IPv4 infrastructure. Several
conditions require analysis, as introduced in the following sub
sections.
Several decisions need to be taken into consideration, as 5.1 Internal versus External Tunnel End Point
introduced in the following subsections.
5.1 Internal versus External Tunnel-End-Point Assuming the upstream provider has deployed some IPv6 services,
either native IPv6 in its backbone or in the access network, or a
combination of both. Also, or alternatively, could have deployed
one or more several transition mechanisms based upon tunnels for
subscribers.
The upstream provider could have already deployed some IPv6 for example in the case where the access network doesn't support
service, either native IPv6 in its backbone or in the access IPv6, the enterprise could decide to use those available transition
network, or a combination of both. Also, or alternatively, could services from the Provider. However, this will usually mean that
have deployed one or several transition mechanisms based upon individual nodes in the network will have their own IPv6-in-IPv4
tunnels, for example in the case where the access network doesn't tunnel. Then, the IPv6 intranetworks communication may not be as
support IPv6. In this case, the enterprise could decide to use efficient, because it will require all the traffic to be forwarded
those available transition services from the ISP. However, this by the IPv4 infrastructure to the Tunnel-End-Point located at the
will usually mean that the each of the different nodes in the Provider. This may be acceptable if the IPv6 applications do not
network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6 require intranetworks communication at all. For example in the case
intranet communication will not be efficient, as it will require where the application server is located outside of the enterprise
all the traffic to be forwarded by the IPv4 infrastructure to the network, or on other intranetworks of the same enterprise.
Tunnel-End-Point located at the ISP. This could be acceptable if
the IPv6 applications do not require intranet communication at all,
for example in the case the application server that is located
outside of the enterprise network, or in other networks of the same
enterprise.
The enterprise could also decide to deploy its own transition box The enterprise could also decide to deploy its own transition
and possibly collocate it adjacent to the border router that mechanism node, and possibly collocate it adjacent to the border
connects to the upstream provider. In this case, the intranet router that connects to the upstream Provider. In this case,
communication is also possible. intranetnetworks communication using this tunnel end point is also
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, an option is to
use statically configured tunnels. use statically configured tunnels.
However, in general automatic configured tunnels will be preferred. However, in general automatic configured tunnels will be preferred.
Section 5 doesn't yet discuss pros and cons of connecting sparse Section 5 doesn't yet discuss pros and cons of connecting sparse
nodes, nor management/security issues. We need to add that in -01. nodes, nor management/security issues. We need to add that in -02.
6 IPv6 Dominant Network Deployment 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.
IPv6 deployment in some enterprise networks will use a dominant IPv6 deployment in some enterprise networks will use an IPv6-
IPv6 network deployment strategy. What this means essentially is dominant network deployment strategy. What this means essentially
that the network or specific sites within the enterprise network is that the network or specific sites within the enterprise network
will transition to IPv6 using only IPv6 routing to transfer both will transition to IPv6 using only IPv6 routing to transfer both
IPv4 and IPv6 packets over the network. IPv4 and IPv6 packets over the network, even though the network is
Dual-IP capable.
IPv6 communications between IPv6 nodes will use IPv6 to IPv6 communications between IPv6 nodes will use IPv6 to
communicate. When IPv6 dual-stack nodes in the dominant IPv6 communicate. When IPv6-capable nodes in the IPv6-dominant network
network need to communicate with IPv4 nodes, in the dominant IPv6 need to communicate with IPv4 nodes, on the IPv6-dominant network,
network, the IPv6 nodes will use their IPv4 implementation of the the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4
dual-stack to tunnel IPv4 packets in IPv6 [6TUN], and an edge packets in IPv6 [6TUN]. An edge router within the IPv6-dominant
router within the dominant IPv6 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-stack nodes to communicate with legacy IPv4 nodes communicate with legacy IPv4 nodes within an IPv6-dominant network.
within a dominant IPv6 network.
Use of IPv4 within the dominant network and past the edge of the
dominant network to be added.
Add subsection on analysis of end-2-end security and not using NAT
to communicate with IPv4 legacy nodes.
This section to be completed. This section needs more work.
7 General issues and applicability for all Scenarios 7 General Issues and Applicability from Analysis
In this section we describe generic enterprise IPv6 deployment In this section we describe generic enterprise IPv6 deployment
issues, applicable to each of the scenarios described above. issues, applicable to the analysis sections 4-6 in this document.
7.1 Phased Plan for IPv6 Deployment This section needs more work.
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.
<add more here> This section needs more work.
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.
<add more here> This section needs more work.
7.3 Phase 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 (to minimize connectivity RTT) IPv6 provider
skipping to change at page 15, line 15 skipping to change at page 16, line 16
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].
There is currently no Provider Independent (PI) address space The procedure for enterprise renumbering between providers is
available. The procedure for enterprise renumbering between described in [RENUM].
providers is described in [RENUM].
Unique Local Addressing [ULAs] should not be used for enterprise This section needs more work.
networks.
7.4 Phase 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 on those aspects that we believe are in scope for this comment on those aspects that we believe are in scope for this
analysis document. Thus we have not included network management, analysis 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 Phase 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 (of the AAAA format, see RFC????) 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 is standardized and capability exists in BGP4+ (RFC????), IS- IPv6 routing protocols that can be used are as follows: BGP4+
IS (RFC????), OSPFv3 (RFC????) and RIPng (RFC????). [BGPv6], IS-IS [ISISv6], OSPFv3 [RFC????) and RIPng [RIPv6].
Availability of such routing implementations will naturally vary This section needs more work.
between vendors. Such commentary is outside the scope of this
document.
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 or DHCP. management, including manual configuration, NIS [NIS] or DHCP
[DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration In an IPv6 enterprise, Stateless Address Autoconfiguration
(RFC2462) 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, an on-link prefix information. address, a default router, and an on-link prefix information.
For secure autoconfiguration, the SEND protocol is defined (now at For secure autoconfiguration, the IPsec [IPSEC] or SEND method
RFC????). [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 Stateless information (e.g. DNS, NTP servers) will likely need a Stateful
DHCPv6 service available. DHCPv6 [DHCPv6] service available.
For nodes configuring via DHCPv6, where DHCPv6 servers are offlink, For nodes configuring via DHCPv6, where DHCPv6 servers are offlink,
a DHCPv6 Relay Agent function will be required. a DHCPv6 Relay Agent function will be required.
Hosts may also generate or request IPv6 Privacy Addresses Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
(RFC3041); there is support for DHCPv6 to assign privacy addresses there is support for DHCPv6 to assign privacy addresses to nodes in
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 > <to be completed >
7.4.5 Security 7.4.5 Security
<to be completed - see Pekka's various drafts on 6to4 and others?, <to be completed - see Pekka's various drafts on 6to4 and others?,
and emphasize use of best practice> and emphasize use of best practice>
7.4.6 IPv4-IPv6 interworking 7.5 Stage 3: Widespread Dual-Stack deployment on-site
In the case of an IPv6 only node in an IPv6-dominant or dual-stack
enterprise, wishing to communicate with external IPv4-only systems,
some interworking (translation) method is required. The
translation could be applied at Layer 3 (e.g. [NAT-PT]), Layer 4
(e.g. [SOCKS]) or Layer 7 (a dual-stack application layer gateway -
ALG).
Use of [NAT-PT] is discouraged [cite the I-D on this?]. A
recommended solution is the use of ALGs. Many applications
naturally have an ALG behavior, and can be used to offer access for
"legacy" IPv4 services such as SMTP (dual-stack email server, see
[cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache),
and are already operated by many enterprise sites. By dual-stacking
the servers, an IPv6 only node can reach an external IPv4-only web
site (for example) via the proxy without any additional (Layer 3 or
4) translation being required.
7.5 Phase 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. IPv6 transport.
7.5.1 Deploying IPv6 across the enterprise 7.5.1 Deploying IPv6 across the enterprise
In the dual-stack case, this means enabling IPv6 on existing IPv4 In the Dual-IP deployment case, this means enabling IPv6 on
subnets. It is most likely that the administrator will deploy IPv6 existing IPv4 subnets. It is most likely that the administrator
links to be congruent with existing IPv4 subnets (because IPv4 will deploy IPv6 links to be congruent with existing IPv4 subnets
subnets tend to be created for geographic, policy or administrative (because IPv4 subnets tend to be created for geographic, policy or
reasons that would be IP-independent). administrative reasons that would be IP-independent).
7.5.2 Supporting remote access
Where an enterprise's users may be working off-site, and their
transient ISP has no IPv6 support (natively or through transition
aids) the enterprise should consider deploying its own transition
(remote access) aid.
Such an aid may be either a tunnel broker [TBRK], ideally one that
supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If
a 6to4 relay is offered, the site should be aware of security
issues with operating 6to4 relays [cite ref?].
There is ongoing work on auto-transition and assisted tunneling
tools that may also be applicable as remote access aids [cite
refs?].
8 Applicable Transition Mechanisms 8 Applicable Transition Mechanisms
This section will provide guidance for the use of specific This section will provide guidance for the use of specific
transition mechanisms below that can be used by the enterprise to transition mechanisms below that can be used by the enterprise to
support the enterprise matrix scenarios (rows) in Section 3, and support the enterprise matrix notational networks (rows) in Section
within the context of the three scenarios discussed in this 3, and within the context of the analysis discussed in Sections 4,
document in Section 4, 5, and 6. Table xx below shows the 5, and 6.
transition mechanisms recommended by the authors in each of the
respective scenarios. In some cases the enterprise network team
will have a choice and the decision will be based upon criteria
that is not within the scope of this document. One size will not
fit all for the enterprise for transition in most cases and the
transition mechanisms are tools to be used by the enterprise as
required to fulfill their strategy and business reasons for
transitioning to IPv6. The mechanisms depicted below the authors
selected based on their knowledge of these mechanisms have gained
acceptance in the market and have multiple implementations in
current network pilots or in those network pilot plans within
industry.
Basic Configured Tunnels:
6to4:
Tunnel Broker:
Teredo:
DSTM:
ISATAP:
NAT-PT:
====================================================================== Section to be written.
|Application |Host 1 |Service |Host 2 |Application | Recommended
|----------- |Network|Provider|Network|---------- | Transition
| Host 1 OS | | | | Host 2 OS | Mechanism
=====================================+================================
|IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Dual IP Networks
1 |---- or ----| or |Dual IP | or |---- or ----|and Hosts for
|IPv6 Dual|v6 Only| |v6 only|IPv6 Dual|IPv6
======================================================================
|IPv4 IPv4| | | |IPv4 IPv4|Dual IP Networks
2 |---- or ----|Dual IP|Dual IP |Dual IP|---- or ----|and Hosts for
|IPv4 Dual| | | |IPv4 Dual|IPv4
======================================================================
| IPv6 | | | | IPv6 |IPv6 Host Tunnel
3 | ---- | IPv4 |Dual IP |Dual IP| ---- |(Brokered atISP)
| Dual | | | | IPv6 |
======================================================================
| IPv6 | | | |IPv4 IPv4|Translation on
4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6
| Dual | | | |IPv4 Dual|domain
======================================================================
| IPv6 | | | | IPv6 |IPv6 Host Tunnel
5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at
| Dual | | | | IPv6 |Net2)
======================================================================
|IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site
6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel|
|IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?)
======================================================================
| IPv6 |Dual IP| IPv4, | | IPv4 |Translation on
7 | ---- | or | IPv6 or| IPv4 | ---- |local IPv6
| IPv6 |v6 only|Dual IP | | IPv4 |domain
======================================================================
| IPv6 |Dual IP| None - | | IPv4 |Translation for
8 | ---- | or | Local | IPv4 | ---- |local nets
| IPv6 |v6 only| Connect| | IPv4 |
======================================================================
| IPv4 | | | | IPv4 |4in6 Config
9 | ---- | IPv4 |v6 only | IPv4 | ---- |Tunnel
| IPv4 | | | | IPv4 |
======================================================================
| Dual | | | | IPv4 |DSTM for
10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6
| Dual | | | | IPv4 |
======================================================================
| Dual | | | | IPv4 |DSTM for
11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6
| Dual | | | | IPv4 |
======================================================================
| IPv6 | | | | IPv6 |Dual IP plus
12| ---- |Dual IP|v6 only |Dual IP| ---- | v6 only
| Dual | | | | Dual |
======================================================================
| IPv6 | | | | IPv6 |
13| ---- |v6 only|v6 only |v6 only| ---- |v6 only
| IPv6 | | | | IPv6 |
======================================================================
9 Security Considerations 9 Security Considerations
WRITING: Lets do this after we get above writing done. WRITING: Lets do this after we get above writing done.
10 References 10 References
10.1 Normative References 10.1 Normative References
Most of these need to be moved to non-normative reference section
and additional references need to be added.
[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.
skipping to change at page 22, line 28 skipping to change at page 21, line 31
for Unmanaged Networks". Work in Progress. for Unmanaged Networks". Work in Progress.
[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". Work in Progress.
[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 10.2 Non-Normative References
None at this time. To be completed in next draft version.
Changes from -00 t -01
- Changed abstract and context of document to only deal with dual
IP layer
networks and nodes.
- Changed introduction, Section 1-3 to reflect authors and IETF WG
discussions
to attempt consensus on these initial sections.
- Added explanation of why Appendix A is in the document to
introduction.
- Expanded what topics are out of scope for this document.
- Updated terminology section
- Updated section 3 matrix and description to simplify and focus on
dual IP layer
- Edited base text of Sections 4-7 but all three require extensive
additional test
for descriptions.
- Edited section 8 and removed table and will reference table in
section 3. This
section still needs to be written.
Document Acknowledgments Document Acknowledgments
The Authors would like to acknowledge contributions from the The Authors would like to acknowledge contributions from the
following: IETF v6ops Working Group members Pekka Savola. following: IETF v6ops Working Group members Pekka Savola.
Author's Address Author 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.305.3051
Email: jim.bound@hp.com Email: jim.bound@hp.com
Yanick Pouffary Yanick Pouffary
skipping to change at page 24, line 5 skipping to change at page 23, line 54
Email: jordi.palet@consulintel.es 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
Appendix A - Campus Deployment Scenario with VLANs Appendix A - Campus Deployment Scenario with VLANs
To be completed in next drafts. To be completed in next drafts.
Appendix B - Crisis Management Network Scenarios Appendix B - 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
skipping to change at page 26, line 45 skipping to change at page 25, line 45
during a long transition period. Reserve units, contractors, other during a long transition period. Reserve units, contractors, other
agencies, agencies,
and international partners may need IPv4 service across this and international partners may need IPv4 service across this
enterprise's enterprise's
IPv6 dominant backbone. IPv6 dominant backbone.
Assumptions: Required IPv6 network infrastructure is available, or Assumptions: Required IPv6 network infrastructure is available, or
available available
over some defined timeline, supporting the aggressive transition plan. over some defined timeline, supporting the aggressive transition plan.
Requirements: Requirements:Reduce operation and maintenance requirements and
increase
Reduce operation and maintenance requirements and increase net-centricity through aggressive IPv6 transition. Interoperation and
net-centricity through aggressive IPv6 transition. coexistence with legacy IPv4 networks and applications is required.
Legacy
Interoperation and coexistence with legacy IPv4 networks and IPv4 nodes/applications/networks will need to be able to operate across
applications is the
required. IPv6 backbone and need to be able to interoperate with the
IPv6-dominant
Legacy IPv4 nodes/applications/networks will need to be able to operate
across the
IPv6 backbone and need to be able to interoperate with the IPv6-dominant
network's nodes/applications. 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 various
ways ways
a crisis management network can connect customers through their network a crisis management network can connect customers through their network
infrastructure. Because the institution's existing wired and fixed site infrastructure. Because the institution's existing wired and fixed site
wireless wireless
infrastructure can be destroyed or unavailable in a crisis, the crisis infrastructure can be destroyed or unavailable in a crisis, the crisis
 End of changes. 

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