V6ops Working Group Enterprise Network Scenarios Design Team 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 draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 1]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 2]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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 draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 3]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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 draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 4]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 5]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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 draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 6]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 7]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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) draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 8]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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: draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 9]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 10]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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 draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 11]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 12]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 13]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 14]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 15]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 16]
INTERNET-DRAFT draft-ietf-v6ops-entnet-scenarios-00.txt February 2003 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. Authors contact info will be provided in a future draft. draft-ietf-v6ops-entnet-scenarios-00.txt Expires July 2003 [Page 17]
