draft-ietf-v6ops-entnet-scenarios-00.txt   draft-ietf-v6ops-entnet-scenarios-01.txt 
V6ops Working Group Enterprise Network Scenarios Design Team This document has been replaced by draft-pouffary-v6ops-ent-v6net-03.txt
For more information or a copy of the document, contact the author directly.
INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt
OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt
Yanick Pouffary (Chair)
Jim Bound (Editor)
Enterprise Networks Scenarios Design Team
See Acknowledgements Section
February 2003
IPv6 Enterprise Networks Scenarios
<draft-ietf-v6ops-entnet-scenarios-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-
Drafts.
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
IPv6 will be deployed in Enterprise networks. This scenario has
requirements for the adoption of IPv6. This document will focus upon
and define: a set of technology scenarios that shall exist for the
enterprise network, the set of transition variables, transition
methods, and tools required by different scenarios. The document
using these definitions will define the points of transition for an
Enterprise network.
Table of Contents:
1. Introduction.................................................4
2. Requirements.................................................5
3. Terminology..................................................6
4. Enterprise Network Assumptions...............................7
5. Enterprise Network Scenarios Overview........................9
6. Enterprise Points of Transition Methods.....................11
6.1 M1: IPv4 Tunnels to Encapsulate IPv6....................11
6.2 M2: IPv6 Tunnels to Encapsulate IPv4....................11
6.3 M3: IPv6 NAT to Communicate with IPv4...................11
6.4 M4: IPv6 Native LANs....................................12
6.5 M5: IPv6 Native Routing Domains.........................12
6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4...........12
7. Enterprise Network Infrastructure Points of Transition......13
7.1 DNS.....................................................13
7.2 Routing.................................................13
7.3 Autoconfiguration.......................................13
7.4 Security................................................13
7.5 Applications and APIs...................................14
7.6 IPv6 Address Scoping....................................14
7.7 Network Management......................................14
7.8 Address Planning........................................14
8. Enterprise Tools Requirements...............................15
8.1 Routing Configuration...................................15
8.2 DNS Configuration.......................................15
8.3 IPv6 Address Allocation and Configuration...............15
8.4 IPv4 Address Allocation and Configuration...............15
8.5 VPN/Tunnel Configuration................................15
8.6 Mobile Node IPv4/IPv6 Interoperation Configuration......15
9. Enterprise Network Scenarios in Depth.......................16
10. Enteprise Network Scenarios Matrix Graph...................16
11. Applicability Statement....................................16
12. Security Section...........................................16
Acknowledgments................................................16
References.....................................................16
Design Team' Addresses.........................................17
1. Introduction
IPv6 will be deployed in Enterprise networks. This scenario has
requirements for the adoption of IPv6. This document will focus upon
and define: a set of technology scenarios that shall exist for the
enterprise network, the set of transition variables, transition
methods, and tools required by different scenarios. The document
using these definitions will define the points of transition for an
Enterprise network.
The audience for this document is the enterprise network team
considering deployment of IPv6. It is needed to clearly state the
problem space so there is a common understanding of the need for
transition tools in general. Specifically it is intended to show that
the enterprise brings an important set of cases that the transition
tools have to address. It will attempt to describe common
environments and the issues that are important to a transition.
To frame the discussion, it will focus on administrative policy
rather than size, and break that down by services available within
the enterprise. The business value and high level motivation for each
technical approach will be touched on in terms of cost/benefit
aspects. This value is expected to affect the order of deployment an
enterprise will take, so the document will try to order approaches
according to value.
While it is difficult to quantify all the potential motivations for
enterprise network teams to move to IPv6, there are some cases where
an abstract description is possible.
The primary case is the detrimental affect on the basic business
processes caused by a lack of available IPv4 addresses. This may be
through IPv4-NAT breaking applications or security technologies, or
the simple inability to achieve a viable business model with current
allocation policies. With a simpler end-to-end approach to
accomplishing the business goal, IPv6 provides strong motivations to
move.
Another related motivator is avoiding the significant and frequently
hidden burden on IT of continually balancing the available IPv4
address pool against the number of devices attached to a particular
network of subnets. This is generally a problem with fast growing
satellite offices, but also occurs as business priorities cause rapid
reorganization. Using the autoconfiguration capabilities of IPv6, the
effort aligns with the need for new independently routed segments,
rather than the shifting number of devices that may be attached to
any given network segment.
A slightly different motivator is the case of the enterprise that
develops products for other enterprises, where the consuming
enterprise has an insufficient pool of IPv4 addresses. While on the
surface this is another shortage motivator, the real business
motivator is for the supplier to avoid having to build and
continually update their product to work despite the presence of
IPv4-NAT. The NAT-traversal problem requires both substantial
resources to develop the work-around, as well as provide the
additional infrastructure components. Each of these raise the cost to
develop the product, therefore make it less competitive than a
comparable IPv6 based product.
Another case to consider are new enterprise networks that want to
begin their operations with IPv6 from day one.
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
3. Terminology
Enterprise Network - An Enterprise Network is a network
that has multiple links, a router
conection to a Provider, and is actively
managed by a network operations entity.
Provider - A Provider is an entity that provides
services and connectivity to the Internet
or other private external networks for
the Enterprise Network.
Edge - The Edge is the ingress and egress points
connecting to the Internet, Extranet, or
to another private external network.
Administrative Domain - An Administrative Domain are the
ingress and egress points connecting
nodes across the Enterprise
Network, behind the Edges.
Extranet - An Extranet is any Enterprise Network
owned network components at the Edge, but
not part of the Administrative Domain.
Border Router - An Enterprise Network Border Router is a
a router that is configured at the Edges.
Internal Router - An Enterprise Network Internal Router is
a router that is not configured at an
Edge, but within the Administrative Domain.
Mobile - An Enterprise Network condition when a
node changes its network location, or
is not attached to the Administrative
Domain.
Mobile Node - An Enterprise Network Mobile Node is any
node that is Mobile within or not
within the enterprise, or as remote
telecommuting node.
Points of Transtion - An Enterprise Network Point of Transition
is a general abstraction to note functions
that must be defined for the transition to
IPv6.
Internet Network Provider - A Provider for connectivity and services
to the public Internet.
Private Network Provider - A Provider for connectivity and services
to a private Internet.
Dual Stack IPv4/IPv6 Node - A node that supports IPv4 and IPv6.
IPv4 ONLY Node - A node that only supports IPv4.
IPv6 ONLY Node - A node that only supports IPv6
4. Enterprise Network Assumptions
In this section assumptions about the enterprise network for this
document are provided.
Each network will need to select the method to best suit their
business requirements. Any attempt to define a default or one-
size-fits-all set of variables and methods for all scenarios would
result in failure.
Every node that can be addressed by another node must be in a
registered name service, managing this name service is a
significant scaling challenge for the Enterprise.
Applications that support multiple users on multiple nodes
(multi-Party) require globally consistent addresses for peer-to-
peer communications.
Bi-directional communication between two nodes across Service
Provider networks is often used as a crude level of authenticity,
having the IP addresses in the IP header be the same as from where
the nodes data packet came from provides a rudimentary component
of security.
Enterprise Networks will vary in size and network complexity from
a small office to a large manufacturing operation with multiple
sites, across a wide geography
Points of Transition will need to be defined for the following:
- Routers
- Non Router Nodes
- Network Topology
- Network Applications
- Network Management and Tools
- Network Security
- Network Mobility
- Network VPNs
- Network Telecommuter Work Force
- Network Inter Site Communications
This document will identify those Points of Transition and discuss
them within a set of scenarios. This document will not provide
solutions. A set of suggested solutions will be provided in a follow
on document to this work.
Enterprise Networks will vary how they approach the transition to
IPv6 depending on a set of transition variables (V1..VN):
V1: IPv4 NAT and Firewall uses IPv4 private addresses.
V2: IPv4 Firewall uses IPv4 global routable addresses.
V3: Applications must be able to communicate between remote
Administrative Domains.
V4: The methods and security used to access the Administrative
Domain for Telecommuters and Mobile Nodes.
V5: IPv6 software upgrades are not available for existing
routers and nodes.
V6: Source code for applications have been lost or cannot be
upgraded to IPv6.
V7: New business function being defined and can exist without
extensive access to legacy IPv4 networks and nodes.
V8: Mission critical applications must be able to interoperate
with legacy IPv4 nodes.
V9: Legacy IPv4 nodes can be upgraded to support dual stack
IPv4 and IPv6.
V10: Legacy IPv4 nodes cannot be upgraded to support dual stack
IPv4 and IPv6.
V11: What sections of the network for an existing network or
new network will move towards IPv6 deployment first, second, ....,
last, and at what rate.
V12: What are the network security requirements for the Enterprise
Network.
V13: Provider does not support IPv6.
The transition variables are the parameters to the first function to
determine the functions for a scenario. Once the transition variables
are understood then the next step is to select transition methods as
follows (M1..MN):
M1: IPv4 Tunnels to Encapsulate IPv6
M2: IPv6 Tunnels to Encapsulate IPv4
M3: IPv6 NAT to Communicate with IPv4
M4: IPv6 Native LANs
M5: IPv6 Native Routing Domains
M6: Dual Stack Nodes supporting IPv6 and IPv4
M7: IPv6 Tunnels to Encapsulate IPv6
This document will define a list of sets for transition variables,
methods, and tool requirements, which will provide a three
dimensional system for analysis that can be used to extrapolate a set
of solutions. Where the X axis is the transition variables (V#), the
Y axis the transition method (M#), and the Z axis the tools
requirement set (section 8) to support X and Y conditions.
This point on the graph will be an transtion strategy. After the
document describes the scenarios in depth (section 9) the graph will
be depicted in a matrix for readers of this document (section 10)
5. Enterprise Network Scenarios Overview
It would be impossible for any one document to describe all the
potential scenarios as networks deploy IPv6. Attempting to break the
problem space down and cover the high level perspectives, this
document will separate the scenarios by administrative scope and
policy. Within each, the various ISP service offerings produce 15
cases to describe. Finally, we find there are 27 cases when the
additional characteristic of host and application-first versus
network-first approaches are considered.
The 15 above is 5 cases x 3 offerings. The 27 comes from the doubling
by discussing network vs. application first, minus the 3 offerings
from set D because it has to be done all at once. Another way to
describe the table is scenarios x offerings x order = (4 x 3 x 2) +
(1 x 3 x 1).
Without looking for a one-size-fits-all, to simplify the document we
will assume a single motivating application. The multi-party peer-to-
peer conferencing application they are deploying to improve
productivity requires unambiguous addresses. The IPv6 enabled
application needs to communicate with each party as a peer, while
other applications on those systems still need access to IPv4 based
services.
Critical issues for each:
Addressing : Dynamic vs. control w/administrative burden
DNS : Dynamic vs. control w/administrative burden
Public visibility of the name space.
AAA : Internal & external
Mobility of road warrior and telecommuters
Applications: What applications are needed
PMTUD : Support for discovery vs. traditional ICMP aversion
Mobility : Requirements for nodes
Management : Network and tools management
Trust system between host & network management teams:
Dual-stack vs. IPv6-only
IPv6-only is a restricted capability subset
Routing
Architectural concept of tunneling over foo vs. native service
Scenario set A:
Single geographic region, single administration & policy
ISP offering - IPv4-only IPv4 & IPv6 IPv6-only
Deployment order - Hosts & Apps first Network first
Scenario set B:
Multiple geographic regions, single administration & policy
ISP offering - IPv4-only IPv4 & IPv6 IPv6-only
Deployment order - Hosts & Apps first Network first
Scenario set C:
Multiple geographic regions, multiple administrations & policy
ISP offering - IPv4-only IPv4 & IPv6 IPv6-only
Deployment order - Hosts & Apps first Network first
Scenario set D:
New enterprise, looking to avoid a transition
ISP offering - IPv4-only IPv4 & IPv6 IPv6-only
Deployment order - All at once by definition
Scenario set E:
Enterprise Services for remote users
ISP offering - IPv4-only IPv4 & IPv6 IPv6-only
Deployment order - Hosts & Apps first Network first
Scenario #1
An enterprise has an existing IPv4 network and is adding IPv6 between
geographic sites. Set A and B.
Scenario #2
An enterprise deploys wireless services where groups of access points
end up on different subnets. Set A and B.
Scenario #3
A multi-site enterprise has deployed IPv4-NAT with overlapping
private address ranges between the sites. Set A and B.
Scenario #4
A global enterprise interacts with a public and private Internet as a
cohesive unit, but is composed of several administratively distinct
business units. Set C.
Scenario #5
Two large enterprises using IPv4-NAT merge with the consequence that
large segments of private network address space overlap. Set C.
Scenario #6
A new Enterprise providing location based services for over a wide
geography enables mobile devices for their Account Teams to access
network data and services. Set D.
Scenario #6 (subset of all scenarios)
Enterprise employees telecommute to work from home, or during
business travel. Set E.
6. Enterprise Points of Transition Methods
The Enterprise network will have varying points of transition that
will require different points of interoperability with IPv6 and IPv4.
These points of transition are the fulcrum of the template to define
what is required for Enterprise networks within the focus of this
document.
6.1 M1: IPv4 Tunnels to Encapsulate IPv6
This Point of Transition exists for the following conditions:
1. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
but an IPv4 Internal Router is between them. These nodes could also
be Mobile nodes too and in a remote location.
2. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
but they are in a remote Administrative Domain and geography, and
packets must be sent to a Provider. These nodes could also be Mobile
nodes and in a remote location.
3. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
and both are on remote IPv4 network.
4. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
and both are on remote IPv6 network.
It is important to realize in this scenario the transit providers
could be IPv4-ONLY.
6.2 M2: IPv6 Tunnels to Encapsulate IPv4
This Point of Transition exists for the following conditions:
1. A Dual Stacked IPv4/IPv6 node wants to communicate to a legacy IPv4
service and is on a Native IPv6 link and Routing Domain. Enterpise
policy is that IPv6 should be used to encapsulate IPv4.
2. A Dual Stacked IPv4/IPv6 node wants to communicate to a legcy IPv4
service and is on a Native IPv6 link and Routing Domain. Enterprise
policy is IPv4 should be used for this communications.
3. Same conditions above but for Mobile node.
6.3 M3: IPv6 NAT to Communicate with IPv4
This Point of Transition exists for the following conditions:
1. A Dual Stacked IPv4/IPv6 node wants to communicate with a legacy IPv4
ONLY service or node. Enterprise policy is that IPv6 NAT should be
used for this communications.
2. An IPv6 ONLY node wants to communicate with a legacy IPv4 ONLY node
or service. Same policy as above.
3. Same conditions above but for Mobile IPv6 ONLY node.
Using NAT for this point of transition will preclude end-2-end
security, applications, and remove some benefits from the IPv6
protocol.
1. The Design Team highly recommends that network not adopt the policy
in reference "1" above.
2. IPv6 ONLY nodes should not be deployed in a network until they will
not require access to any legacy IPv4. This means that applications
and infrastructure has been ported or moved to IPv6. Until that
time nodes for transition should be Dual Stacked IPv4/IPv6 nodes.
This means networks that want to use IPv6 ONLY nodes will be required
to move applications and infrastructure to IPv6 first.
6.4 M4: IPv6 Native LANs
This Point of Transtion exists when the policy wants to support the
deployment of Native IPv6 LANs. This condition will be driven by the
transition variables V1-V14 stated in Section 4.
6.5 M5: IPv6 Native Routing Domains
This Point of Transition exists when the policy is to deploy IPv6
Native Routing Domains. This condition will be driven by the
variables V1-14 stated in Section 4.
6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4
This Point of Transition is a method to deploy IPv6 and a method for
transition. A network that deploys Dual Stacked IPv4/IPv6 nodes as
they adopt IPv6 are more assured that IPv6 and IPv4 interoperation
will be possible between the two nodes or services. It also means
for many legacy IPv4 nodes that they can be upgraded to support IPv4
and IPv6, but not turn on IPv6 until the IPv6 operational network has
been verified to be interoperable and secure. It also means that
both IPv4 and IPv6 can be supported by the nodes that transition to
IPv6 and then will be able to communicate with IPv4 nodes using an
IPv4 network infrastructure.
7. Enterprise Network Infrastructure Points of Transition
The Enterprise will be required to determine what network
infrastructure will be affected by transtion to IPv6. This
infrastructure must be analyzed and understood as a critical resource
to manage.
Each topic below in this section will be discussed and the issues
facing transition for these network infrastructure parts will be
discussed.
7.1 DNS
This will be discussed in a future draft.
7.2 Routing
This will be discussed in a future draft.
7.3 Autoconfiguration
IPv6 introduces the concept of autoconfiguration [RFC2462].
Autoconfiguration removes the need for DHCP to dynamically assign
addresses to nodes. Though DHCPv6 can be used to administrate
addresses that are assigned to nodes.
When preforming stateless autoconfiguration, an EUI-64 is generated
by the IPv6 node, on a per-interface basis, to form the entire 128
bit IPV6 address. The EUI-64 is derived from the MAC address of the
interface that being autoconfigured. This mechanism proves a large
amount of flexibility when joining new nodes to an IPv6 network.
Since the address is tied to the MAC address of a given interface,
swapping said interface device would change the address of the node.
This presents a problem for nodes, such as servers and routers, that
require a stable IP address.
It is suggested that nodes which require such stability, in their IP
address, make use of either stateful autoconfiguration or fixed
interface-id autoconfiguration. The later involves using a fixed 64
bit token, instead of the EUI-64. Determining the value of this
token should be considered when establishing an address plan."
7.4 Security
This will be discussed in a future draft.
7.5 Applications and APIs
This will be discussed in a future draft.
7.6 IPv6 Address Scoping
This will be discussed in a future draft.
7.7 Network Management
This will be discussed in a future draft.
7.8 Address Planning
This will be discussed in a future draft.
8. Enterprise Tools Requirements
This section will identify the tools requirements for an EN
transitioning to IPv6 so the configuration issues for the EN are
documented for the document.
8.1 Routing Configuration
This will be discussed in a future draft.
8.2 DNS Configuration
This will be discussed in a future draft.
8.3 IPv6 Address Allocation and Configuration
This will be discussed in a future draft.
8.4 IPv4 Address Allocation and Configuration
This will be discussed in a future draft.
8.5 VPN/Tunnel Configuration
This will be discussed in a future draft.
8.6 Mobile Node IPv4/IPv6 Interoperation Configuration
This will be discussed in a future draft.
9. Enterprise Network Scenarios in Depth
This section will discuss the Scenarios in depth and identify the
transition methods options and tools requirements from previous
sections.
This will be done in a future draft.
10. Enteprise Network Scenarios Matrix Graph
This section will provide a set of matrices from the scenarios,
transition variables, methods, and tools to define and determine
common points of transition across the Scenarios.
This will be done in future draft.
11. Applicability Statement
This will be done in a future draft as we get more working group discussion.
12. Security Section
The first iteration of this section will be done in a future draft.
Acknowledgments
Enterprise Network Scenarios Design Team:
Yanick Pouffary (Chair) - Hewlett Packard
Jim Bound (Editor) - Hewlett Packard
Yurie Rich - Native6 Group
Marc Blanchet - Hexago
Tony Hain - Cisco
Paul Gilbert - Cisco
Scott Hahn - Intel
Margaret Wasserman - Windriver
Jason Goldschmidt - Sun Microsystems
Mathew Lehman - Microsoft
Aldrin Isaac - Bloomberg
The Design Team would also like to acknowledge the input from the
following: IETF V6OPS Working Group, Tim Chown, Alain Durand, and Bob Hinden.
References
These will be provided as the drafts mature and we reference related
work in the IETF and in the Industry.
Design Team' Addresses
Send email to ent-v6net@viagenie.qc.ca to contact the design team and send comments on the draft to v6ops@ops.ietf.org. Draft Author(s):
Authors contact info will be provided in a future draft. J. Bound: bound@zk3.dec.com
Y. Pouffary: Yanick.Pouffary@digital.com
 End of changes. 

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