IPv6 Operations Working Group
Internet Draft                                             Jim Bound
Document: draft-ietf-v6ops-ent-analysis-00.txt       Yanick Pouffary
Obsoletes: None                                                   HP
Expires: March 2005                                        Tim Chown
                                           University of Southampton
                                                         David Green
                                                         Jordi Palet
                                                       Steve Klynsma

                  IPv6 Enterprise Network Analysis


Status of this Memo
   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been
   disclosed, and any of which I become aware will be disclosed, in
   accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


 This document analyzes the transition to IPv6 in enterprise
 networks.  These networks are characterized as a network that has
 multiple internal links, one or more router connections, to one or
 more Providers, and is managed by a network operations entity.  The
 analysis will focus on a base set of transition units and
 requirements expanded from a previous Enterprise Scenarios
 document, and will depict a set of components and transition
 methods required for the enterprise to transition to IPv6 within
 each scenario and then common to all scenarios.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 1]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

Table of Contents:

1  Introduction.................................................3
2  Terminology..................................................5
3  Enterprise Matrix Analysis for Transition....................6
4  Wide-Scale Dual-Stack Deployment.............................8
4.1  Phased Dual-Stack Deployment...............................8
4.2  Analysis of Required Tools for Dual-Stack Deployment.......9
4.3  IPv6-Capable Existing Routing Infrastructure Available.....9
4.4  No IPv6-Capable Existing Routing Infrastructure............9
4.4.1  Tunnel IPv6 over the IPv4 infrastructure.................9
4.4.2  Deploy a parallel IPv6 infrastructure...................10
4.5  Remote IPv6 access to the enterprise......................10
4.6  Other considerations......................................10
5  Sparse Dual-Stack Deployment................................11
5.1  Internal versus External Tunnel-End-Point.................11
5.2  Manual versus Autoconfigured..............................12
6  IPv6 Dominant Network Deployment............................13
7  General issues and applicability for all Scenarios..........14
7.1 Phased Plan for IPv6 Deployment............................14
7.2  Network Infrastructure Requirements.......................14
7.3 Phase 1: Initial connectivity steps........................14
7.3.1 Obtaining external connectivity..........................14
7.3.2 Obtaining global IPv6 address space......................15
7.4 Phase 2: Deploying generic basic service components........15
7.4.1 IPv6 DNS.................................................15
7.4.2  IPv6 Routing............................................15
7.4.3  Configuration of Hosts..................................16
7.4.4  Developing an IPv6 addressing plan......................16
7.4.5  Security................................................16
7.4.6  IPv4-IPv6 interworking..................................17
7.5  Phase 3: Widespread Dual-Stack deployment on-site.........17
7.5.1  Deploying IPv6 across the enterprise....................17
7.5.2  Supporting remote access................................17
8  Applicable Transition Mechanisms............................19
9  Security Considerations.....................................21
10  References.................................................21
10.1  Normative References.....................................21
10.2  Non-Normative References.................................22
Document Acknowledgments.......................................22
Author's Address...............................................23
Appendix A - Campus Deployment Scenario with VLANs.............24
Appendix B - Crisis Management Network Scenarios...............25
Intellectual Property and Copyright Statements.................30

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 2]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

1  Introduction

 This document analyzes the transition to IPv6 in enterprise
 networks.  These networks are characterized as a network that has
 multiple internal links, one or more router connections, to one or
 more Providers, and is managed by a network operations entity.  The
 analysis will focus on a base set of transition units and
 requirements expanded from a previous Enterprise Scenarios
 document, and will depict a set of components and transition
 methods required for the enterprise to transition to IPv6 within
 each scenario and then common to all scenarios.

 The audience for this document is the enterprise network team
 considering deployment of IPv6.  The document will be useful for
 enterprise teams that will have to determine the IPv6 transition
 strategy for their enterprise.  It is expected those teams include
 members from management, network operations, and engineering. The
 scenarios presented provide an example set of cases the enterprise
 can use to build an IPv6 network scenario.

 The enterprise analysis will begin by describing a matrix tool to
 be used to portray the different IPv4 and IPv6 possibilities for
 deployment. The first column (Application/Host 1 OS) represents the
 IP-capability offered by the node that originates IP packets.  The
 second to last column (Application/Host 2 OS) represents the IP-
 capability offered by the node that terminates the IP packet.  In
 between are three columns that represent the IP-capability of
 typical networks traversed by the packet, including an originating
 host network (Host 1 Network),Service Provider Network and
 Destination Host Network (Host 2 Network). Each row (1 through 13)
 is one possible scenario and the final column shows the recommended
 transition mechanism to use for that particular scenario.

 The objective of this document is to take the [BSCN] scenarios and
 then integrate those with a basic unit transition set in the course
 of this analysis to provide a set of options for an enterprise,
 where one size does not fit all.

 Will expand on this part of the introduction in next draft.

 The following specific topics are currently out of scope for this

  - Multihoming
  - Application transition/porting (see [APPS]).
  - IPv6 VPN, firewall or intrusion detection deployment
  - IPv6 network management and QoS deployment
  - Detailed IT Department requirements
  - Deployment of novel IPv6 services, e.g. MIPv6
  - +others??

 Thus, we are focusing in this document on Layer 3 deployment, in
 the same way as the other IPv6 deployment scenario texts have done
 [UMAN,ISPA, 3GPA].  This document covers deployment of IPv6 "on the
 wire", including address management and DNS services.

 We are also assuming that the enterprise deployment is one being

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 3]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 undertaken by the network administration team, i.e. this document
 is not discussing the case of an individual user gaining IPv6
 connectivity (to some external IPv6 provider) from within an
 enterprise network.

 In Section 2 we introduce the terminology used in this document.
 In Section 3 we introduce and define an enterprise matrix and
 define the layer 3 connectivity requirements. In Section 4 we
 discuss wide scale dual-stack use within an enterprise. In section
 5 we discuss sparse dual-stack deployment within an enterprise.  In
 section 6 we discuss IPv6 dominant network deployment within the
 enterprise.  In section 8 we analyze the applicable transition
 mechanisms to support the matrix defined in Section 1 referencing
 the discussions in Sections 4, 5, 6, and 7.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 4]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

2  Terminology

 Enterprise Network - A network that has multiple internal links,
                      one or more router connections, to one or
                      more Providers and is actively managed by a
                      network operations entity.

 Provider           - An entity that provides services and
                      connectivity to the Internet or
                      other private external networks for the
                      enterprise network.

 IPv6 Capable       - A node or network capable of supporting both
                      IPv6 and IPv4.

 IPv4 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
                      stack, in this document.

 IPv6 Dominant      - A network or link that uses only IPv6 routing.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 5]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

3  Enterprise Matrix Analysis for Transition

 To provide layer 3 enterprise analysis context for discussion we
 provide for this document the use of a matrix with most common
 transition scenarios to exist for the enterprise.

 Table 1 below is a matrix of thirteen possible transition scenarios
 that may be encountered in the enterprise.  The first column
 (Application/Host 1 OS) represents the IP-capability offered by the
 node that originates IP packets.  The second to last column
 (Application/Host 2 OS) represents the IP-capability offered by the
 node that terminates the IP packet.  In between are three columns
 that represent the IP-capability of typical networks traversed by
 the packet, including an originating host network (Host 1
 Network),Service Provider Network and Destination Host Network
 (Host 2 Network).

 As an example, Scenario 1 is an IPv6 application trying to
 establish a communications exchange with a destination v4 only
 application.  Since proper porting of the application to the host
 is a prerequisite, the IP-capability of the operating system at
 both originating and destination host is not specifically addressed
 herein.  To complete the information exchange the packets must
 first traverse the host's originating IPv4 network, then the
 service provider's dual-IP network and finally, the destination
 host's network.

 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
 will use these thirteen to address the analysis for enterprise

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 6]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

   |Application |Host 1 |Service |Host 2 |Application |
   |----------- |Network|Provider|Network|----------  |
   | Host 1 OS  |       |        |       | Host 2 OS  |
   |IPv6    IPv6|Dual IP|        |Dual IP|IPv6    IPv6|
 1 |---- or ----|  or   |Dual IP |  or   |---- or ----|
   |IPv6    Dual|v6 Only|        |v6 only|IPv6    Dual|
   |IPv4    IPv4|       |        |       |IPv4    IPv4|
 2 |---- or ----|Dual IP|Dual IP |Dual IP|---- or ----|
   |IPv4    Dual|       |        |       |IPv4    Dual|
   |    IPv6    |       |        |       |    IPv6    |
 3 |    ----    | IPv4  |Dual IP |Dual IP|    ----    |
   |    Dual    |       |        |       |    IPv6    |
   |    IPv6    |       |        |       |IPv4    IPv4|
 4 |    ----    | IPv4  |Dual IP |Dual IP|---- or ----|
   |    Dual    |       |        |       |IPv4    Dual|
   |    IPv6    |       |        |       |    IPv6    |
 5 |    ----    | IPv4  |  IPv4  |Dual IP|    ----    |
   |    Dual    |       |        |       |    IPv6    |
   |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    |
 9 |    ----    | IPv4  |v6 only | IPv4  |    ----    |
   |    IPv4    |       |        |       |    IPv4    |
   |    Dual    |       |        |       |    IPv4    |
 10|    ----    |Dual IP| v6 Only| IPv4  |    ----    |
   |    Dual    |       |        |       |    IPv4    |
   |    Dual    |       |        |       |    IPv4    |
 11|    ----    |v6 only| v6 only| IPv4  |    ----    |
   |    Dual    |       |        |       |    IPv4    |
   |    IPv6    |       |        |       |    IPv6    |
 12|    ----    |Dual IP|v6 only |Dual IP|    ----    |
   |    Dual    |       |        |       |    Dual    |
   |    IPv6    |       |        |       |    IPv6    |
 13|    ----    |v6 only|v6 only |v6 only|    ----    |
   |    IPv6    |       |        |       |    IPv6    |

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 7]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

4  Wide-Scale Dual-Stack Deployment

 In this section we are covering Scenario 1 as described in Section
 3.1 of [BSCN]. The scenario, assumptions and requirements are
 driven from the [BSCN] text.

 A common scenario for IPv6 deployment is the enterprise network
 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,
 IPv6-only or dual-stack. The driver for deploying IPv6 may not be
 for immediate wide-scale usage of IPv6, but rather to prepare an
 existing IPv4 infrastructure with IPv6 capability, such that dual-
 stack nodes, or later IPv6-only nodes, can be deployed.

 We analyze the scenario against existing transition mechanisms for
 their applicability, suggesting a phased approach for IPv6
 deployment in the enterprise.

4.1  Phased Dual-Stack Deployment

 The site administrator should formulate a phased plan for the
 introduction of dual-stack IPv6 network.  We suggest that the
 generic plan of Section 7 of this document provides a good basis
 for such a plan.

 The generic plan has a number of stages/phases that are independent
 of whether dual-stack or IPv6-dominant deployment is undertaken.

 In an enterprise network, the administrator will generally seek to
 deploy IPv6 in a structured, controlled manner, such that IPv6 can
 be enabled on specific links at specific stages of deployment.   It
 may be a specific requirement that some links remain IPv4 only, or
 specifically should not have IPv6 connectivity.  It may also be a
 requirement that aggregatable global IPv6 addresses, assigned by
 the enterprise's upstream provider from the address space allocated
 to them by the Regional Internet Registries (RIRs), are used for

 In this document we do not advocate or discuss the deployment of
 Unique Local IPv6 Unicast Addresses [ULA].   We do strongly suggest
 that IPv6 NAT is not deployed, as doing so negates the key
 advantages of moving to the new Internet Protocol version.

 A typical deployment would involve the establishment of a single
 "testbed" IPv6 capable subnet at the enterprise site, prior to
 wider deployment.  Such a testbed not only allows the IPv6
 capability of specific platforms and applications to be evaluated
 and verified, it also allows the steps in Sections 7.3 and 7.4 of
 this document to be undertaken without (potential) adverse impact
 on the production elements of the enterprise.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 8]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 Section 7.5 describes the stages for the widespread deployment in
 the enterprise, which would be undertaken after the basic building
 blocks for deployment are in place.

4.2  Analysis of Required Tools for Dual-Stack Deployment

 The critical part of the dual-stack deployment is the IPv6 routing
 infrastructure.   The path taken will depend on whether the
 enterprise has existing Layer 2/3 switch/router equipment that has
 an IPv6 (routing) capability, or that can be upgraded to have such

 In Section 4, we are not considering sparse IPv6 deployment; the
 goal of dual-stack deployment is widespread use in the enterprise.

4.3  IPv6-Capable Existing Routing Infrastructure Available

Where IPv6 routing capability exists in existing infrastructure, the
network administrator can enable IPv6 on the same physical hardware
as the existing IPv4 service.   This is the end goal of any
enterprise dual-stack deployment, when the capability, performance,
and robustness of the dual-stack operational deployment is verified.

Ideally, the IPv6 capability will span the entire enterprise,
allowing deployment at any link or subnet.  If not, techniques from
Section 4.4 below may be required.

4.4  No IPv6-Capable Existing Routing Infrastructure

In this case the enterprise administrator faces two basic choices,
either to tunnel IPv6 over 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
off-link are through different routing platforms.

4.4.1  Tunnel IPv6 over the IPv4 infrastructure

The tunneling, as described in [BCNF] would be established between
dual-stack capable routers on the enterprise, thus "bypassing"
existing non IPv6-capable routers and platforms.   For example, some
IPv6 edge routers in the enterprise may be IPv6 capable, while
others, and perhaps the enterprise backbone itself, are not.

In the widespread dual-stack scenario, a more structured, manageable
method is required, where the administrator has control of the
deployment per-subnet and (ideally) long-term, aggregatable global
IPv6 addressing is obtained, planned and used from the outset.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005    [Page 9]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

4.4.2  Deploy a parallel IPv6 infrastructure

In this case, the administrator may deploy a new, separate IPv6-
capable router (or set of routers).  It is quite possible that such
a parallel infrastructure would be IPv6 only.

Such an approach means acquiring additional hardware, but it has the
advantage that the existing IPv4 routing platforms are not disturbed
by the introduction of IPv6.

To distribute IPv6 to the existing IPv4 enterprise subnets, either
dedicated physical infrastructure can be deployed or, if it is
available, IEEE 802.1q VLANs could be used, as described in [VLAN].
The latter has the significant advantage of not requiring any
additional physical cabling/wiring; it offers all the advantages of
VLANs for the new dual-stack environment.

Many router platforms can tag multiple VLAN IDs on a single physical
interface based on the subnet/link the packet is destined for; thus
multiple IPv6 links can be collapsed for delivery on a single (or
small number of) physical IPv6 router interfaces in the early stages
of deployment.

The parallel infrastructure would only ever be seen as an interim
step towards a full dual-stack deployment on a unified
infrastructure.   The parallel infrastructure however allows all
other aspects of the IPv6 enterprise services to be deployed,
including IPv6 addressing, ready for that unifying step at a later

4.5  Remote IPv6 access to the enterprise

Where the enterprise's users are off-site, and using an ISP that
does not support any native IPv6 service or IPv6 transition aids,
the enterprise may consider deploying it's own remote IPv6 access
support, as described in Section 7.5.2.

4.6  Other considerations

There are some identified issues with turning IPv6 on by default,
including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF].

<more to go here>

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 10]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

5  Sparse Dual-Stack Deployment

 This section covers the Scenario 2 as described in Section 3.1 of
 [BSCN].  This scenario assumes the requirements defined with the
 [BSCN] text.

 IPv6 deployment within the enterprise network, with an existing
 IPv4 infrastructure, could be motivated by mission critical or
 business applications or services that require IPv6. In this case
 the prerequisite is that only the nodes using those IPv6
 applications need to be upgraded to a dual-stack. The routing
 infrastructure will not be upgraded to support IPv6, nor does the
 enterprise wish to deploy a parallel IPv6 routing infrastructure at
 this point, since this is an option in section 4.

 The lack of existing IPv6-enabled routing infrastructure implies
 the usage of IPv4 and IPv6 in the nodes.  There is a need for end-
 to-end communication with IPv6, but the infrastructure only
 supports IPv4 transport. Thus the only viable method for end-to-end
 communication with IPv6 is to tunnel the traffic over the existing
 IPv4 infrastructure.

 The network team needs to decide which is the most efficient among
 the available transition tunneling mechanisms to deploy, so they
 can be used without disrupting the existing IPv4 infrastructure.

 Several decisions need to be taken into consideration, as
 introduced in the following subsections.

5.1  Internal versus External Tunnel-End-Point

 The upstream provider could have already deployed some IPv6
 service, either native IPv6 in its backbone or in the access
 network, or a combination of both. Also, or alternatively, could
 have deployed one or several transition mechanisms based upon
 tunnels, for example in the case where the access network doesn't
 support IPv6. In this case, the enterprise could decide to use
 those available transition services from the ISP. However, this
 will usually mean that the each of the different nodes in the
 network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6
 intranet communication will not be efficient, as it will require
 all the traffic to be forwarded by the IPv4 infrastructure to the
 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

 The enterprise could also decide to deploy its own transition box
 and possibly collocate it adjacent to the border router that
 connects to the upstream provider. In this case, the intranet
 communication is also possible.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 11]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

5.2  Manual versus Autoconfigured

 If the number of nodes to be using IPv6 is reduced, an option is to
 use statically configured tunnels.

 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 -01.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 12]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

6  IPv6 Dominant Network Deployment

 In this section we are covering Scenario 3 as described in Section
 3.1 of [BSCN].  The scenario, assumptions and requirements are
 driven from the [BSCN] text.

 IPv6 deployment in some enterprise networks will use a dominant
 IPv6 network deployment strategy. What this means essentially is
 that the network or specific sites within the enterprise network
 will transition to IPv6 using only IPv6 routing to transfer both
 IPv4 and IPv6 packets over the network.

 IPv6 communications between IPv6 nodes will use IPv6 to
 communicate.  When IPv6 dual-stack nodes in the dominant IPv6
 network need to communicate with IPv4 nodes, in the dominant IPv6
 network, the IPv6 nodes will use their IPv4 implementation of the
 dual-stack to tunnel IPv4 packets in IPv6 [6TUN], and an edge
 router within the dominant IPv6 network will decapsulate the IPv4
 packet and route to the path of the IPv4 node on the network.  This
 permits dual-stack nodes to communicate with legacy IPv4 nodes
 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.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 13]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

7  General issues and applicability for all Scenarios

 In this section we describe generic enterprise IPv6 deployment
 issues, applicable to each of the scenarios described above.

7.1 Phased Plan for IPv6 Deployment

 The enterprise network administrator will need to follow a staged
 plan for IPv6 deployment.

 <add more here>

7.2  Network Infrastructure Requirements

 The considerations for the enterprise components are detailed in
 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
 Layer 3 issues.

 <add more here>

7.3 Phase 1: Initial connectivity steps

 The first steps for IPv6 deployment do not involve technical
 aspects per se; the enterprise needs to select an external IPv6
 provider, and obtain globally routable IPv6 address space from that

7.3.1 Obtaining external connectivity

 The enterprise service provider would typically be a
 topographically close (to minimize connectivity RTT) IPv6 provider
 that is able to provide an IPv6 upstream link.

 It would be expected that the enterprise would use either native
 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]
 for an enterprise deployment.  The enterprise has a requirement for
 long-term, stable IPv6 connectivity.  6to4 and the tunnel broker
 are more appropriate for SOHO or single node environments.  Use of
 6to4 also prevents the enterprise adopting aggregatable global IPv6

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 14]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 addressing from the outset.

7.3.2 Obtaining global IPv6 address space

 The enterprise will obtain global IPv6 address space from its
 selected upstream provider, as provider assigned (PA) address

 The enterprise should receive at least a /48 allocation from its
 provider, as described in [ALLOC].

 There is currently no Provider Independent (PI) address space
 available.  The procedure for enterprise renumbering between
 providers is described in [RENUM].

 Unique Local Addressing [ULAs] should not be used for enterprise

7.4 Phase 2: Deploying generic basic service components

 Most of these are discussed in Section 4 of [BSCN].   Here we
 comment on those aspects that we believe are in scope for this
 analysis document. Thus we have not included network management,
 multihoming, multicast or application transition analysis here, but
 these aspects should be addressed in Phase 2.

7.4.1 IPv6 DNS

 The enterprise site should deploy a DNS service that is capable of
 both serving IPv6 DNS records (of the AAAA format, see RFC????) and
 of communicating over IPv6 transport.

 Specific IPv6 DNS issues are reported in [DNSV6].

7.4.2  IPv6 Routing

 The enterprise network will need to support methods for internal
 and external routing.

 For a single-homed single-site network, a static route to a single
 upstream provider may be sufficient, although the site may choose

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 15]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 to use an exterior routing protocol, especially where it has
 multiple upstream providers.

 For internal routing, an appropriate interior routing protocol may
 be deployed.

 IPv6 is standardized and capability exists in BGP4+ (RFC????), IS-
 IS (RFC????), OSPFv3 (RFC????) and RIPng (RFC????).

 Availability of such routing implementations will naturally vary
 between vendors.  Such commentary is outside the scope of this

7.4.3  Configuration of Hosts

 An enterprise network will have a number of tools available for
 IPv4 address and other configuration information delegation and
 management, including manual configuration, NIS or DHCP.

 In an IPv6 enterprise, Stateless Address Autoconfiguration
 (RFC2462) may be used to configure a host with a global IPv6
 address, a default router, an on-link prefix information.

 For secure autoconfiguration, the SEND protocol is defined (now at

 A stateless configured node wishing to gain other configuration
 information (e.g. DNS, NTP servers) will likely need a Stateless
 DHCPv6 service available.

 For nodes configuring via DHCPv6, where DHCPv6 servers are offlink,
 a DHCPv6 Relay Agent function will be required.

 Hosts may also generate or request IPv6 Privacy Addresses
 (RFC3041);  there is support for DHCPv6 to assign privacy addresses
 to nodes in managed environments.

7.4.4  Developing an IPv6 addressing plan

 <to be completed >

7.4.5  Security

 <to be completed - see Pekka's various drafts on 6to4 and others?,
 and  emphasize use of best practice>

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 16]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

7.4.6  IPv4-IPv6 interworking

 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 -

 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
 IPv6 routing, an IPv6 DNS service and address allocation management
 in place, the IPv6 capability can be rolled out to the wider
 enterprise.  This involves putting IPv6 on the wire in the desired
 links, and enabling applications and other services to begin using
 IPv6 transport.

7.5.1  Deploying IPv6 across the enterprise

 In the dual-stack case, this means enabling IPv6 on existing IPv4
 subnets.  It is most likely that the administrator will deploy IPv6
 links to be congruent with existing IPv4 subnets (because IPv4
 subnets tend to be created for geographic, policy or 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?].

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 17]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 There is ongoing work on auto-transition and assisted tunneling
 tools that may also be applicable as remote access aids [cite

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 18]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

8  Applicable Transition Mechanisms

 This section will provide guidance for the use of specific
 transition mechanisms below that can be used by the enterprise to
 support the enterprise matrix scenarios (rows) in Section 3, and
 within the context of the three scenarios discussed in this
 document in Section 4, 5, and 6.  Table xx below shows the
 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

 Basic Configured Tunnels:


 Tunnel Broker:





draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 19]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

   |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    |

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 20]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

9  Security Considerations

 WRITING: Lets do this after we get above writing done.

10  References

10.1  Normative References

 [DNSV6]  Durand, A., Ihren, J. and P. Savola, "Operational
          Considerations and Issues with IPv6 DNS", Work in

 [CONF]   Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration"
          RFC 2462 December 1998.

 [DHCPF]  Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic
          Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July

 [DHCPL]  Droms, R., "Stateless Dynamic Host Configuration Protocol
          (DHCP) Service for IPv6" RFC 3756 April 2004.

 [APPS]  Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E.,
         "Application Aspects of IPv6 Transition" Work in Progress.

 [BSCN]  Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios"
         Work in Pogress.

 [6TO4]  Carpenter, B., Moore, K., "Connection of IPv6 Domains via
         IPv4 Clouds" RFC 3056 February 2001.

 [TRDO]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
         NATs" Work in Progress.

 [BCNF]  Nordmark, E., Gilligan, R., "Basic Transition Mechanisms
         for IPv6 Hosts and Routers" Work in Progress from RFC 2893.

 [DSTM]  Bound, J., (Ed) et al. "Dual Stack Transition Mechanim"
         Work in Progress.

 [ISTP]  Templin, F., et al "Intra-Site Automatic Tunnel
         Addressing Protocol (ISATAP)". Work in Progress.

 [6TUN]  Conta, A., Deering, S., "Generic Packet Tunneling in
         IPv6" RFC 2473 December 1998.

 [TBRK]  Durand, A., et al "IPv6 Tunnel Broker"
         RFC 3053 January 2001.

 [SEC1]  Savola, P., Patel, C., "Security Considerations for
         6to4.  Work in Progress.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 21]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 [ULA]   Hinden, B., Haberman, B., "Unique Local IPv6
         Addresses". Work in Progress.

 [RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering
         an IPv6 Network without a Flag Day". Work in Progress.

 [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
         Allocations to Sites" RFC 3177 September 2001.

 [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation -
         Protocol Translation (NAT-PT)" RFC 2766 February 2000

 [UMAN]  Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms
         for Unmanaged Networks".  Work in Progress.

 [ISPA]  Lind, M., et al "Scenarios and Analysis for Introducing IPv6
         into ISP Networks".  Work in Progress.

 [3GPA]  Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks"
         Work in Progress.

10.2  Non-Normative References

 None at this time.

Document Acknowledgments

 The Authors would like to acknowledge contributions from the
 following: IETF v6ops Working Group members Pekka Savola.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 22]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

Author's Address

 Jim Bound
 110 Spitbrook Road
 Nashua, NH 03062
 Phone: 603.305.3051
 Email: jim.bound@hp.com

 Yanick Pouffary
 HP Competency Center
 950, Route des Colles, BP027,
 06901 Sophia Antipolis CEDEX
 Phone: + 33492956285
 Email: Yanick.pouffary@hp.com

 Tim Chown
 School of Electronics and Computer Science
 University of Southampton
 Southampton SO17 1BJ
 United Kingdom
 Email: tjc@ecs.soton.ac.uk

 David Green
 SRI International
 333 Ravenswood Ave
 Menlo Park, CA 94025-3493
 Phone: 732 532-6715
 Email: david.green@sri.com

 Jordi Palet Martinez
 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
 The MITRE Corporation
 7515 Colshire Drive
 McLean, VA 22102-5708
 Email: sklynsma@mitre.org

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 23]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

Appendix A - Campus Deployment Scenario with VLANs

To be completed in next drafts.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 24]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

Appendix B - Crisis Management Network Scenarios


 This appendix first describes different scenarios for the
 introduction of IPv6 into a crisis management network for
 emergency services, defense, or security forces that are currently
 running IPv4 service. Then, the scenarios for introducing IPv6 are
 analyzed and the relevance of already defined transition mechanisms
 are evaluated. Known challenges are also identified.

 When a crisis management enterprise deploys IPv6, its goal is to
provide IPv6
 connectivity on it's institutional fixed networks and on the mobile
 services that are deployed to a crisis area. The new IPv6 service must
 be added to an already existing IPv4 service, the introduction of
 IPv6 must not interrupt this IPv4 service, and the IPv6 services must
 be interoperable with existing IPv4 services.

 Crisis management enterprises accessing IPv4 service across mobile
 networks, airborne networks, and satellites will find different ways to
 IPv6 to this service based on their network architecture, funding,
 and institutional goals. This document discusses a small set of
 scenarios representing the architectures for IPv6 expected to be
 in crisis management networks during the next decade. It evaluates the
 relevance of the existing transition mechanisms in the context of
 these deployment scenarios, and points out the lack of essential
 functionality in these methods to the ISP's operation of an IPv6

 The document is focused on services that include both IPv6 and IPv4
 and does cover issues surrounding accessing IPv4 services across
 networks. It is outside the scope of this document to describe detailed
 implementation plans for IPv6 in defense networks

 Scenarios for IPv6 Deployment in Crisis Management Networks:

 Scenario 1:  Limited IPv6 Deployment Network.....................

 Sparse IPv6 dual-stack deployment in an existing IPv4 network
 Enterprise with an existing IPv4 network wants to deploy a set of
 IPv6 "applications" and have some ability to interoperate with other
 institutions that are using IPv6 services. The IPv6 deployment is
 to the minimum required to operate this set of applications.

 Assumptions:  IPv6 software/hardware components for the application are
 available, and platforms for the application are IPv6 capable.

 Requirements: Do not disrupt IPv4 infrastructure.

 Scenario 2:    Dual Stack Network

 Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts
 and network infrastructure. Enterprise with an existing
 IPv4 network wants to deploy IPv6 in conjunction with their IPv4
 network in order to take advantage of emerging IPv6 network-centric
 capabilities and to be interoperable with other agencies, international
 partners, and commercial enterprises that are deploying an IPv6

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 25]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 Assumptions:  The IPv4 network infrastructure used has an
 equivalent capability in IPv6.

 Requirements: Do not disrupt existing IPv4 network infrastructure
 with IPv6. IPv6 should be equivalent or "better" than the network
 infrastructure in IPv4. It may not be feasible to deploy IPv6 on all
parts of
 the network immediately. Dual stacked defense enterprise network
 must be interoperable with both IPv4 and IPv6 networks and

 Scenario 3:   ..............................IPv6 Dominant Network

 Enterprise has some limited IPv4-capable/only nodes/applications
needing to
 communicate over the IPv6 infrastructure. Crisis management enterprise
 re-structuring an existing network, decides to pursue aggressive IPv6
 transition as an enabler for network-centric services and wants to run
 some native IPv6-only networks to eliminate cost/complexity of
supporting a
 dual stack. Some legacy IPv4 capable nodes/applications within the
 will have slow technical refresh/replacement path and will need to
 over the IPv6 dominant infrastructure for years
 until they are replaced. The IPv6 dominant enterprise network will need
to be
 interoperable with it's own legacy networks, commercial networks, and
 legacy networks of similar organizations that will remain IPv4 dominant
 during a long transition period. Reserve units, contractors, other
 and international partners may need IPv4 service across this
 IPv6 dominant backbone.

 Assumptions:  Required IPv6 network infrastructure is available, or
 over some defined timeline, supporting the aggressive transition plan.


Reduce operation and maintenance requirements and increase
net-centricity through aggressive IPv6 transition.

Interoperation and coexistence with legacy IPv4 networks and
applications is

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.

 Description of a Generic Crisis Management Network

 A generic network topology for a crisis management reflects the various
 a crisis management network can connect customers through their network
 infrastructure. Because the institution's existing wired and fixed site
 infrastructure can be destroyed or unavailable in a crisis, the crisis
 management network must be able to deploy it's own mobile wireless
 or connect through external wired and wireless networks provided by
ISPs or
 partner organizations.  This infrastructure lets us divide the basic
 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
Figure 1.

      ------------    ----------       ---- Wired Connection
     | Network and|  |          |      .... Wireless Connection
     |  Service   |--| Backbone |
     | Operation  |  |          |
      ------------    ----------

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 26]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

                       /  |          ---------------------
                      /   :        _|Connection to        |
                     /    :          |Commercial Internet  |
                    /     :           ---------------------  Network
      ----------  /  ----------     ----------
     | Home     |/  | Wireless |   External  |.............
     | Base     |   | Mobile   |    |Untrusted |+---------  :
     | Network  |   | Network  |    |Network   |          | :
      ----------     ----------      ----------           | :
          | :            :                                | :  Local

          | :            :                                | :  Customer
       +--------+    +--------+      +--------+           | :
       |        |    |        |      |        |           | :
       |Customer|    |Customer|      |Customer|+----------- :....
       |        |    |        |      |        |..............
       +--------+    +--------+      +--------+

 Figure 1: Crisis Management Network Topology.

 Stages of IPv6 Deployment:

 The stages are derived from the generic description of scenarios
 for crisis management networks in Section 2. Combinations of
 different building blocks that constitute an crisis network
 environment lead to a number of scenarios from which the network
 engineers can choose. The scenarios most relevant to this document
 are those that maximize the network's ability to offer IPv6 to its
 customers in the most efficient and feasible way. The assumption in
 the first three stages the goal is to offer both IPv4 and IPv6 to
 the customer, and that in the distant future all IPv4 services will
 be eventually switched to IPv6. This document will cover
 engineering the first four stages.

    The four most probable stages are:

          o Stage 1      Limited Launch
          o Stage 2      Dual Stack Dominance
          o Stage 3      IPv6 Dominance
          o Stage 4      IPv6 Transition Complete

 Generally, a crisis management network is able to entirely upgrade
 a current IPv4 network to provide IPv6 services via a dual-stack
 network in Stage 2 and then slowly progress to stages 3 and 4 as
 indicted in Figure 2. During stage 2, When most applications are
 IPv6 dominant, operational and maintenance costs can be reduced on
 some networks by moving to stage 3 and running backbone networks
 entirely on IPv6 while adding IPv4 backwards compatibility via v4
 in v6 tunneling or translation mechanisms to the existing
 configuration from stage 2. When designing a new network, if a new
 IPv6-only service is required, it can be implemented at a lower
 cost jumping directly to stage 3/4 if there are only limited/no
 legacy concerns.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 27]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

                Tunnels        Dominant dual     Full dual Stack
  IPv4-only --> or limited --> stacking with --> everywhere, mostly -->
                dual stacks    transition        v6 apps, some
                Limited v6     mechanisms in     v6 only nets with
                Applications   backbone          transition mechanisms
                                                 pushed to legacy v4

 Figure 2: Transition Path.

 Stage 1 Scenario: Limited Launch

 The first stage begins with an IPv4-only network and IPv4
 customers. This is the most common case today and the natural
 starting point for the introduction of IPv6.  During this stage the
 enterprise begins to connect individual IPv6 applications run on
 dual stacked hosts through host based tunneling using Tunnel
 Broker, ISATAP, Teredo. Some early adopter networks are created for
 pilot studies and networked together through configured tunnels and

 The immediate first step consists of obtaining a prefix allocation
 typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC,
 ARIN, LACNIC, RIPE, ...) according to allocation procedures.

 The crisis management enterprise will also need to establish IPv6
 connectivity between its home base networks and mobile wireless
 networks over it's backbone and negotiate IPv6 service with  its
 service providers and with peer organizations; it is of utmost
 importance to require IPv6 capability or an upgrade plan when
 negotiating purchases of network applications and infrastructure.
 In the short term, network connections, especially legacy wireless
 networks, that cannot provide IPv6 services can provide IPv6
 services through the use of tunnels. However, the longer-term goal
 must be requiring and obtaining IPv6 native connectivity from the
 transit networks, because otherwise the quality of IPv6
 connectivity will likely be poor and the transition to stage 2 will
 be delayed.

 Stage 2 Scenario: Dual Stack Dominance

 Stage 2 occurs when most applications, local networks, and network
 backbones become dual-stacked so that native IPv6 connections are
 enabled. At this point there is a mix of IPv4 and IPv6 applications
 and services in use across the enterprise. The enterprise may be
 made IPv6-capable through either software upgrades, hardware
 upgrades, or a combination of both. Generally IPv6 is added during
 normal technical refresh as the enterprise buys new equipment that
 is IPv6 ready.

 Specialty legacy applications and wireless/satellite networks may
 be especially slow to transition to IPv6 capability due to upgrade
 costs so plans must be made for backwards compatibility for these
 systems. Since some new IPv6 services cannot be provided through
 IPv4, and some legacy network connections may not yet be upgraded,
 tunneling mechanisms have to be provided on the backbone to provide
 IPv6 connectivity through to customer IPv6 applications still
 relying on legacy IPv4-only networks. The tunnels may provide
 host-based tunneling for individual customers or site-to-site

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 28]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

 tunnels to connect small IPv6 domains through IPv4 only networks.
 If any new applications are IPv6-only rather than dual-stacked, and
 need to interact with IPv4-only legacy applications, translators
 will be used as a transition mechanism of last resort during this

 Stage 3 Scenario: IPv6 Dominance

 Stage 3 occurs when the majority of network services are being
 provided by IPv6 so that most network traffic is dominantly IPv6
 and the net-centric benefits of IPv6 end-to-end communications,
 IPSEC based security, QOS, mobility, and autoconfiguration are
 realized. During this stage, some networks and applications will
 become native IPv6-only and will have to rely on transition
 mechanism for backwards compatibility with IPv4.  The switch to
 native IPv6 may be pursued to lower the operations and maintenance
 cost of network operations and lower the performance overhead
 associated with running two stacks on networked systems. During
 this stage, IPv4 in IPv6 tunnels are used to provide IPv4 services
 to the remaining customers needing these services across IPv6 only
 backbones. At this stage requirements for IPv4 compatibility can be
 pushed out of the network backbone and to IPv4 end-user networks.
 DSTM, with or without tunnel brokers, can be used to provide host-
 based tunnels for IPv4 service on local networks that only support
 IPv6. Remaining IPv4 dominant networks requiring IPv4 service
 across IPv6-only backbones will have to connect through site-to-
 site tunnels. Since many new applications are IPv6-only rather than
 dual-stacked, legacy IPv4 applications may require translators for

 Stage 4 Scenario: IPv6 Only In the future, if IPv6 becomes the only
 service required, IPv4 service can be dropped. This transition may
 be hastened by the desire to save operational and maintenance costs
 by dropping IPv4 services and only supporting one IP family.

 Security Concerns

 Adding security to IPv6 services requires developing new customer
 applications for IPSEC, new firewalls, guards, VPN/encrypters, and
 end-user security such as host-based firewalls and virus checkers
 for IPv6 attacks. Police, homeland defense, and military crisis
 management networks require especially high levels of security and
 should begin creation and implementation of their specialized
 security architectures as soon as they begin planning for IPv6
 transition. New IPv6 features such as MIPv6, stateless address
 auto-assignment, and ubiquitous end-user IPSEC will likely not be
 compatible with current information-assurance tools that are simply
 ported from IPv4 to a minimal IPv6 capability. A complete new
 security policy, architecture, and tools will most likely be
 required to realize the true net-centric benefits of IPv6 in crisis
 networks requiring high security.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 29]

Internet Draft    IPv6 Enterprise Network Analysis    September 2004

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

Disclaimer of Validity

 This document and the information contained herein are provided on

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


 Funding for the RFC Editor function is currently provided by the
 Internet Society.

draft-ietf-v6ops-ent-analysis-00.txt  Expires March 2005   [Page 30]