IPv6 Operations Working Group Internet Draft Jim Bound (Editor) Document:
draft-ietf-v6ops-ent-scenarios-01.txtdraft-ietf-v6ops-ent-scenarios-02.txt Hewlett Packard Obsoletes: draft-ietf-v6ops-ent-scenarios-00.txtdraft-ietf-v6ops-ent-scenarios-01.txt Expires: JulyNovember 2004 IPv6 Enterprise Network Scenarios <draft-ietf-v6ops-ent-scenarios-01.txt><draft-ietf-v6ops-ent-scenarios-02.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission by the Internet Protocol IPv6 Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the firstname.lastname@example.org mailing list. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the scenarios for IPv6 deployment within enterprise networks. It will focus upon an enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of enterprise solutions in a later document. Table of Contents: 1. Introduction................................................3 2. Terminology.................................................5 3. Base Scenarios..............................................6 3.1 Base Scenarios Defined.....................................6 3.2 Scenarios Network Infrastructure Components................7 3.3 Specific Scenario Examples.................................8 4. Support for Legacy IPv4 Nodes and Applications.............10 4.1 IPv4 Tunnels to Encapsulate IPv6..........................10 4.2 IPv6 Tunnels to Encapsulate IPv4..........................10 4.3 IPv6 only communicating with IPv4.........................11 5. Network Infrastructure Component Requirements..............11 5.1 DNS.......................................................11 5.2 Routing...................................................11 5.3 Autoconfiguration.........................................12 5.4 Security..................................................12 5.5 Applications..............................................12 5.6 Network Management........................................12 5.7 Address Planning..........................................12 5.8 Multicast..................................................13 5.9 Multihoming................................................13 6. Security Considerations....................................13 7. References.................................................13 7.1 Normative References......................................14 7.2 Non-Normative References..................................14 Document Acknowledgments.......................................14 Authors-Design Team Contact Information........................15 Intellectual Property Statement................................16 Full Copyright Statement.......................................17 Acknowledgement................................................17 1. Introduction This document describes the scenarios for IPv6 deployment within enterprise networks. It will focus upon an enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of enterprise solutions in a later document. 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. To frame the discussion, the document will describe a set of scenarios and network infrastructure for each scenario. It is impossible to define every possible enterprise scenario that will apply to IPv6 adoption and transition. Each enterprise will select the transition that best supports their business requirements. Any attempt to define a default or one-size- fits-all transition scenario, will simply not work. This document does not try to depict the drivers for adoption of IPv6 by an enterprise. While it is difficult to quantify all the scenarios for an enterprise network team to plan for IPv6, it is possible to depict a set of abstract scenarios that will assist with planning. The document presents three base scenarios as a general use case to be used as a model as input for the enterprise to define specific scenarios. The first scenario assumes the enterprise decides to deploy IPv6 in conjunction with IPv4. The second scenario assumes the enterprise decides to deploy IPv6 because of a specific set of applications the enterprise wants to use over an IPv6 network. The third scenario assumes an enterprise is building a new network or re-structuring an existing network and decides to deploy IPv6 as the predominant protocol within the enterprise coexisting with IPv4. The document then defines a set of network infrastructure components that must be analyzed. The document then provides three specific scenario examples using the network infrastructure components to depict the requirements. These are common enterprise deployment cases to depict the challenges for the enterprise to transition a network to IPv6. The document then discusses the issues of supporting legacy functions on the network, while the transition is in process, and the network infrastructure components required to be analyzed by the enterprise. The interoperation with legacy functions within the enterprise will be required for all transition except possibly by a new network that will be IPv6 from inception. The network infrastructure components will depict functions in their networks that require consideration for IPv6 deployment and transition. Using the scenarios, network infrastructure components, and examples in the document an enterprise can define its specific scenario requirements. Understanding the legacy functions and network infrastructure components required, the enterprise can determine the network operations required to deploy IPv6. The tools and mechanisms to support IPv6 deployment operations will require enterprise analysis. The analysis to determine the tools and mechanisms to support the scenarios will be presented in subsequent document(s). 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 IPv4. IPv6 only - A node or network capable of supporting only IPv6. This does not imply an IPv6 only stack, in this document. 3. Base Scenarios Three base scenarios are defined to capture the essential abstraction set for the enterprise. Each scenario has assumptions and requirements. This is not an exhaustive set of scenarios, but a base set of general cases. Below we use the term network infrastructure to mean the software, network operations and configuration, and the methods used to operate a network in an enterprise. 3.1 Base Scenarios Defined Scenario 1: Enterprise with an existing IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network. Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6. Requirements: Do not disrupt existing IPv4 network infrastructure assumptions with IPv6. IPv6 should be equivalent or "better" than the network infrastructure in IPv4, however, it is understood that IPv6 is not required to solve current network infrastructure problems, not solved by IPv4. It may also not be feasible to deploy IPv6 on all parts of the network immediately. Scenario 2: Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" (application is voluntarily loosely defined here, e.g. peer to peer). The IPv6 deployment is limited 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: Don'tDo not disrupt IPv4 networkinfrastructure. Scenario 3: Enterprise deploying a new network or re-structuring an existing network, decides IPv6 is the basis for most network communication, to coexist with IPv4. Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the enterprise plan. Requirements: Interoperation and Coexistence with IPv4 network network infrastructure and applications are required for communications. 3.2 Scenarios Network Infrastructure Components This section defines the network infrastructure that exist for the above enterprise scenarios. This is not an exhaustive list, but a base list that can be expanded by the enterprise for specific deployment scenarios. The network infrastructure components are presented as functions that the enterprise must analyze as part of defining their specific scenario. The analysis of these functions will identify actions that are required to deploy IPv6. Network Infrastructure Component 1 Enterprise Provider Requirements - Is external connectivity required? - One site vs. multiple sites? - Leased lines or VPN? - How many global IPv4 addresses are available to the enterprise? - What is the IPv6 address ownershipassignment plan available from the provider? - Will clients be Multihomed? - Does the provider offer any IPv6 services? - What site external IPv6 routing protocols are required? - Is there an external data-center? Network Infrastructure Component 2 Enterprise Application Requirements - List of applications in use? - Which applications must be moved to support IPv6 first? - Can the application be upgraded to IPv6? - Will the application have to support both IPv4 and IPv6? - Do the enterprise platforms support both IPv4 and IPv6? - Do the applications have issues with NAT v4-v4 and NAT v4-v6? - Do the applications need stableglobally routable IP addresses? - Do the applications care about dependency between IPv4 and IPv6 addresses? Network Infrastructure Component 3 Enterprise IT Department Requirements - Who "owns"/"operates" the network: in house, or outsourced? - Is a Tele-commuter work force supported? - Is inter-site communications required? - Is network mobility used or required for IPv6? - What are the requirements of the IPv6 address plan? - What will be the internal IPv6 address assignment procedure? - What site internal IPv6 routing protocols are required? - What will be the IPv6 Network Management policy/procedure? - What will be the IPv6 QOS policy/procedure? - What will be the IPv6 Security policy/procedure? - What is the IPv6 training plan to educate the enterprise? - What network operations software will be impacted by IPv6? - DNS - Management (SNMP & ad-hoc tools) - Enterprise Network Servers Applications - Mail Servers - High Availability Software for Nodes - Directory Services - Are all these software functions upgradeable to IPv6? - If not upgradeable, then what are the workarounds? - Do any of the software functions store, display, or allow input of IP addresses? - Other services (e.g. NTP, etc.........) - What network hardware will be impacted by IPv6 - Routers/switches - Printers/Faxes - Firewalls - Intrusion Detection - Load balancers - VPN Points of Entry/Exit - Security Servers and Services - Network Interconnect for Platforms - Intelligent Network Interface Cards - Network Storage Devices - Are all these hardware functions upgradeable to IPv6? - If not, what are the workarounds? - Do any of the hardware functions store, display, or allow input of IP addresses? - Are the nodes moving within the enterprise network? - Are the nodes moving outside and inside the enterprise network? Network Infrastructure Component 4 Enterprise Network Management System - Performance Management Required? - Network Management Applications Required? - Configuration Management Required? - Policy Management and Enforcement Required? - Security Management Required? - Management of Transition Tools and Mechanisms? - What new considerations does IPv6 create for Network Management? Network Infrastructure Component 5 Enterprise Network Interoperation and Coexistence - What platforms are required to be IPv6 capable? - What network ingress and egress points to the site are required to be IPv6 capable? - What transition mechanisms are needed to support IPv6 network operations? - What policy/procedures are required to support the transition to IPv6? - What policy/procedures are required to support interoperation with legacy nodes and applications? 3.3 Specific Scenario Examples This section presents a set of base scenario examples and is not an exhaustive list of examples. These examples were selected to provide further clarity for base scenarios within an enterprise of a less abstract nature. Example Network A: A distributed network across a number of geographically separated campuses. - External network operation. - External connectivity required. - Multiple sites connected by leased lines. - Provider independent IPv4 addresses. - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider Used Applications run by the enterprise: - Internal Web/Mail. - File servers. - Java applications. - Collaborative development tools. - Enterprise Resource Applications. - Multimedia Applications. - Financial Enterprise Applications. - Data Warehousing Applications. Internal network operation: - In house operation of the network. - DHCP (v4) is used for all desktops, servers use static address configuration. - The DHCP server to update naming records for dynamic desktops uses dynamic DNS. - A web based tool is used to enter name to address mappings for statically addressed servers. - Network management is done using SNMP. - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Peer-2-Peer Application and Security supported. - IPv4 Private address space is used within the enterprise. Example Network B: A bank running a large network supporting online transaction processing (OLTP) across a distributed multi-sited network, with access to a central database on an external network from the OLTP network: - External connectivity not required. - Multiple sites connected by VPN. - Multiple sites connected by Native IP protocol. - Private address space used with NAT. - Connections to private exchanges. Applications in the enterprise: - ATM transaction application. - ATM management application. - Financial Software and Database. - Part of the workforce is mobile and requires access to the enterprise from outside networks. Internal Network Operation: - Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Identifying and managing each nodes IP address. Example Network C: A Security Defense Network Operation: - External network required at secure specific points. - Network is its own Internet. - Network must be able to absorb ad-hoc creation of sub-Networks. - Entire parts of the Network are completely mobile. - All nodes on the network can be mobile (including routers) - Network True High-Availability is mandatory. - Network must be able to be managed from ad-hoc location. - All nodes must be able to be configured from stateless mode. Applications run by the Enterprise: - Multimedia streaming of audio, video, and data for all nodes. - Data computation and analysis on stored and created data. - Transfer of data coordinate points to sensor devices. - Data and Intelligence gathering applications from all nodes. Internal Network Operations: - All packets must be secured end-2-end with encryption. - Intrusion Detection exists on all network entry points. - Network must be able to bolt on to the Internet to share bandwidth as required from Providers. - VPNs can be used but NAT can never be used. - Nodes must be able to access IPv4 legacy applications over IPv6 network. 4. Support for Legacy IPv4 Nodes and Applications The enterprise network will have to support the coexistence of IPv6 and IPv4, to support legacy IPv4 applications and nodes. This means that some set of nodes will have to be IPv6 capable. The enterprise user has the following choices for that coexistence to consider today. 4.1 IPv4 Tunnels to Encapsulate IPv6 IPv6 capable nodes want to communicate using IPv6, but an IPv4 Internal router is between them. These nodes could also be Mobile nodes on a visited network. 4.2 IPv6 Tunnels to Encapsulate IPv4 An IPv6 capable node, on an IPv6 link within an IPv6 routing domain, wants to communicate with a legacy IPv4 application. 4.3 IPv6 only communicating with IPv4 An IPv6 capable node wants to communicate with an IPv4 service, but the node is operating as IPv6 only. In order to continue support for communications with IPv4 services an IPv6 to IPv4 translator or IPv6 proxy is required. Introduction of such software may prevent usage of end-to-end security trust models and applications carrying embedded IP addressing information. Bi-directional establishment of connections might be difficult to achieve. 5. Network Infrastructure Component Requirements The enterprise will need to determine what network infrastructure components require enhancements or to be added for deployment of IPv6. This infrastructure will need to be analyzed and understood as a critical resource to manage. 5.1 DNS DNS will now have to support both IPv4 and IPv6 DNS records and the enterprise will need to determine how the DNS is to be managed and accessed, and secured. The range of DNS operational issues are out of scope for this work. Users need to consider all current DNS IPv4 operations and determine if those operations are supported for IPv6. However, DNS resolution and transport solutions for both IP protocols are influenced by the chosen IPv6 deployment scenario. Users need to consider all current DNS IPv4 operations and determine if those operations are supported for IPv6. 5.2 Routing Interior and Exterior routing will be required to support both IPv4 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 over the enterprise network. The enterprise will need to define the IPv6 routing topology, any ingress and egress points to provider networks, and transition mechanisms they wish to use for IPv6 adoption. The enterprise will also need to determine what IPv6 transition mechanisms are supported by their upstream providers. The choice of interior routing protocols have an impact on how the routing tables will be handled: some such as OSPF will have the ships-in-the-night,ships-in-the-night paradigm, others such as ISIS are integrated. This has an impact on the topology and the management of the network. IPv6 capable routers should be monitored to ensure the router has sufficient storage for both IPv6 and IPv4 route tables. Existing network design principles to limit the number of routes in the network, such as prefix aggregation, become more critical with the addition of IPv6 to an existing IPv4 network. 5.3 Autoconfiguration IPv6 introduces the concept of stateless autoconfiguration in addition to stateful autoconfiguration. The enterprise will have to determine the best method of autoconfiguration, for their network. The enterprise will need to determine if they are to use stateless or stateful autoconfiguration, and how autoconfiguration is to operate for DNS updates. The enterprise will need to determine how prefix delegation is done from their upstream provider and how those prefixes are cascaded down to the enterprise IPv6 network. The policy for DNS or choice of autoconfiguration is out of scope for this document. 5.4 Security Current existing mechanisms used for IPv4 to provide security need to be supported for IPv6 within the enterprise. IPv6 should create no new security concerns for IPv4. The entire security infrastructure currently used in the enterprise needs to be analyzed against IPv6 deployment effect and determine what is supported in IPv6. Users should review other security IPv6 network infrastructure work in the IETF and within the industry on going at this time. Users will have to work with their platform and software providers to determine what IPv6 security network infrastructure components are supported. The security filters and firewall requirments for IPv6 need to be determined by the enterprise. The policy choice of users for security is out of scope for this document. 5.5 Applications Existing applications will need to be ported or proxyed to support both IPv4 and IPv6. 5.6 Network Management The addition of IPv6 network infrastructure components will need to be managed by the enterprise network operations center. Users will need to work with their network management platform providers to determine what for IPv6 is supported during their planning for IPv6 adoption, and what tools are available in the market to monitor the network. 5.7 Address Planning The address space within the enterprise will need to be defined and coordinated with the routing topology of the enterprise network. It is also important to identify the pool of IPv4 address space available to the enterprise to assist with IPv6 transition methods. 5.8 Multicast Enterprises utilising IPv4 Multicast services will need to consider how these services may be presented in an IPv6-enabled environment. First, the Multicast routing protocols will need to be considered; those such as PIM-SM may operate similarly under either protocol, but in IPv6 nodes will need to support the Multicast Listener Discovery protocol. Nodes wishing to utilise Source Specific Multicast (SSM) will need to support Multicast Listener Discovery protocol v2 (MLDv2). In addition, applications written for PIM-SM may need to be modified to use SSM. For inter-domain multicast, IPv6 has no equivalent of Multicast Source Discovery Protocol (MSDP); alternative methods are being designed within the IETF, e.g. by embedding the Rendezvous Point address in the multicast group address. For inter-domain use, sites may choose to migrate IPv4 multicast applications to SSM, for which no reverse path discovery method is required. 5.9 Multihoming At this time, current IPv6 allocation policies are mandating the allocation of IPv6 address space from the upstream provider. If an enterprise is multihomed, the enterprise will have to determine how they wish to support multihoming. This also is an area of study within the IETF and work in progress. 6. Security Considerations This document lists scenarios for the deployment of IPv6 in enterprise networks, and there are no security considerations associated with making such a list. There will security considerations for the deployment of IPv6 in each of these scenarios, but they will be addressed in the document that includes the analysis of each scenario. 7. References 7.1 Normative References None at this time. 7.2 Non-Normative References None at this time. Document Acknowledgments The Authors would like to acknowledge contributions from the following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, Alain Durand, and Bob Hinden. Authors-Design Team Contact Information Send email to email@example.com to contact the design team and send comments on the draft to firstname.lastname@example.org. Yanick Pouffary (Chair of Design Team) HP Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE Phone: + 33492956285 Email: Yanick.email@example.com Jim Bound (Editor) Hewlett Packard 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.884.0062 Email: firstname.lastname@example.org Marc Blanchet HexagoViagenie inc. 2875 boul. Laurier, bur. 300 Ste-Foy, Quebec, Canada, G1V 2M2 EMail: Marc.Blanchet@hexago.comMarc.Blanchet@viagenie.qc.ca Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 400 Bellevue, Wa. 98004 Email: email@example.com Paul Gilbert Cisco Systems 1 Penn Plaza, 5th floor, NY, NY 10119 USA Phone: 212.714.4334 Email: firstname.lastname@example.org Margaret Wasserman Nokia 5 Wayside Road Burlington, MA 01803 US Phone: +1 781 993 4900 EMail: email@example.com URI: http://www.nokia.com/ Jason Goldschmidt Sun Microsystems M/S UMPK17-103 17 Network Circle Menlo Park, CA 94025 USA Phone: (650)-786-3502 Fax: (650)-786-8250 Email:firstname.lastname@example.org Aldrin Isaac Bloomberg L.P. 499 Park Avenue New York, NY 10022 USA Phone: 212.940.1812 Email: email@example.com Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom Email: firstname.lastname@example.org Jordi Palet Martinez Consulintel San Jose Artesano, 1 Madrid, SPAIN Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 Email: email@example.com Fred Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: 650.625.2331 Email: firstname.lastname@example.org Roy Brabson IBM PO BOX 12195 3039 Cornwallis Road Research Triangle Park, NC 27709 USA Phone: +1 919 254 7332 Email: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.