Network Working Group J. Bound Request for Comments: 4852 Y. Pouffary Category: Informational Hewlett-Packard S. Klynsma MITRE T. Chown University of Southampton D. Green Command Information April 2007 IPv6 Enterprise Network Analysis - IP Layer 3 Focus Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.
1. Introduction ....................................................3 2. Terminology .....................................................5 3. Enterprise Matrix Analysis for Transition .......................5 4. Wide-Scale Dual-Stack Deployment Analysis ......................10 4.1. Staged Dual-Stack Deployment ..............................10 4.2. Routing Capability Analysis for Dual-IP Deployment ........11 4.2.1. IPv6 Routing Capability ............................11 4.2.2. IPv6 Routing Non-Capability ........................11 126.96.36.199. Tunnel IPv6 over the IPv4 infrastructure ..12 188.8.131.52. Deploy a Parallel IPv6 Infrastructure .....12 4.3. Remote IPv6 Access to the Enterprise ......................12 4.4. Other Considerations ......................................13 5. Sparse Dual-Stack Deployment Analysis ..........................13 5.1. Internal versus External Tunnel Endpoint ..................13 5.2. Manual versus Autoconfigured ..............................14 6. IPv6-Dominant Network Deployment Analysis ......................14 7. General Issues from Analysis ...................................15 7.1. Staged Plan for IPv6 Deployment ...........................15 7.2. Network Infrastructure Requirements .......................15 7.3. Stage 1: Initial Connectivity Steps .......................15 7.3.1. Obtaining External Connectivity ....................16 7.3.2. Obtaining Global IPv6 Address Space ................16 7.4. Stage 2: Deploying Generic Basic Service Components .......16 7.4.1. Developing an IPv6 Addressing Plan .................16 7.4.2. IPv6 DNS ...........................................17 7.4.3. IPv6 Routing .......................................17 7.4.4. Configuration of Hosts .............................18 7.4.5. Security ...........................................18 7.5. Stage 3: Widespread Dual-Stack Deployment On-Site .........19 8. Applicable Transition Mechanisms ...............................20 8.1. Recognizing Incompatible Network Touchpoints ..............20 8.2. Recognizing Application Incompatibilities .................21 8.3. Using Multiple Mechanisms to Support IPv6 Transition ......22 9. Security Considerations ........................................22 10. References ....................................................22 10.1. Normative References .....................................22 10.2. Informative References ...................................24 11. Acknowledgments ...............................................25 Appendix A. Crisis Management Network Scenarios ...................26 A.1. Introduction ..............................................26 A.2. Scenarios for IPv6 Deployment in Crisis Management Networks ..................................................26 A.3. Description of a Generic Crisis Management Network ........28 A.4. Stages of IPv6 Deployment .................................29
NATPT] or Provider Independent address space.
The following specific topics are currently out of scope for this document: - 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., Mobile IPv6. - Requirements or Transition at the Providers' network. - Transport protocol selection for applications with IPv6. - Application layer and configuration issues. - IPv6 only future deployment scenarios. This document focuses on IP Layer 3 deployment in the same way as the other IPv6 deployment analysis works 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 being undertaken by the network administration team, i.e., this document does not discuss the case of an individual user gaining IPv6 connectivity (to some external IPv6 provider) from within an enterprise network. Much of the analysis is applicable to wireless networks, but there are additional considerations for wireless networks not contained within this document. In Section 2, we introduce the terminology used in this document. In Section 3, we introduce and define a tools matrix and define the IP Layer 3 connectivity requirements. In Section 4, we discuss wide scale Dual-IP layer use within an enterprise. In Section 5, we discuss sparse Dual-IP layer deployment within an enterprise. In Section 6, we discuss IPv6-dominant network deployment within the enterprise. In Section 7, we discuss general issues and applicability. In Section 8, a set of transition mechanisms that can support the deployment of IPv6 with an enterprise are recommended. This document then provides Appendix A for readers depicting a Crisis Management enterprise network to demonstrate an enterprise network example that requires all the properties as analyzed in Sections 3, 4, 5, 6, and 7. In addition, we recommend that readers of this document also read another use-case document to support an IPv6 Transition for a Campus Network [CAMP]. Readers should also be aware that a parallel effort for an enterprise to transition to IPv6 is training, but out of scope for this document.
which might be encountered during an IPv6 transition. The notional enterprise network is comprised of hosts attached to an enterprise- owned intranet(s) at two different global locations separated by the Internet. The enterprise owns, operates, and maintains its own intranetworks, but relies on an external provider organization that offers Internet Service. Both local and destination intranetworks are operated by different organizations within the same enterprise and consequently could have different IP-capability than other intranetworks at certain times in the transition period. Addressing every possible combination of network IP-capability in this notional enterprise network is impractical; therefore, trivial notional networks (i.e., pure IPv4, pure IPv6, and ubiquitous Dual- IP) are not considered. In addition, the authors could not conceive of any scenarios involving IPv6-only ISPs or IPv6-only nodes in the near term and consequently have not addressed scenarios with IPv6- only ISPs or IPv6-only nodes. We assume all nodes that host IPv6 applications are Dual-IP. The matrix does not assume or suggest that network address translation is used. The authors recommend that network address translation not be used in these notional cases. Future enterprise transitions that support IPv6-only nodes and IPv6- only ISPs will require separate analysis, which is beyond the scope of this document. Table 1 below is a matrix of ten possible Transition Implementations that, being encountered in an enterprise, may require analysis and the selection of an IPv6 transition mechanism for that notional network. Each possible implementation is represented by the rows of the matrix. The matrix describes a set of notional networks as follows: - The first column represents the protocol used by the application and, below, the IP-capability of the node originating the IP packets. (Application/Host 1 OS) - The second column represents the IP-capability of the host network wherein the node originated the packet. (Host 1 Network) - The third column represents the IP-capability of the service provider network. (Service Provider)
- The fourth column represents the IP-capability of the destination network wherein the originating IP packets are received. (Host 2 Network) - The fifth column represents the protocol used by the application and, below, the IP-capability of the destination node receiving the originating IP packets. (Application/Host 2 OS) As an example, notional network 1 is an IPv6 application residing on a Dual-IP layer host trying to establish a communications exchange with a destination IPv6 application. To complete the information exchange, the packets must first traverse the host's originating IPv4 network (intranet), then the service provider's and destination host's Dual-IP network. Obviously, Table 1 does not describe every possible scenario. Trivial notional networks (such as pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not addressed. However, the authors feel these ten scenarios represent the vast majority of transitional situations likely to be encountered in today's enterprise. Therefore, we will use these ten to address the analysis for enterprise deployment.
Table 1 - Enterprise Scenario Deployment Matrix ====================================================== |Application |Host 1 |Service |Host 2 |Application | |----------- |Network|Provider|Network|---------- | | Host 1 OS | | | | Host 2 OS | =====================================+================ | IPv6 | |Dual IP | | IPv6 | A | ---- | IPv4 | or |Dual IP| ---- | | Dual IP | | IPv4 | | Dual IP | ====================================================== | IPv6 | | | | IPv6 | B | ---- | IPv6 | IPv4 | IPv4 | ---- | | Dual IP | | | | Dual IP | ====================================================== | IPv4 | | | | IPv4 | C | ---- | IPv4 |Dual IP | IPv6 | ---- | | Dual IP | | | | Dual IP | ====================================================== | IPv4 |Dual IP| | | IPv4 | D | ---- | or | IPv4 | IPv6 | ---- | | Dual IP | IPv6 | | | Dual IP | ====================================================== | IPv6 |Dual IP| |Dual IP| IPv4 | E | ---- | or |Dual IP | or | ---- | | Dual IP | IPv6 | | IPv6 | Dual IP | ====================================================== | IPv6 | | | | IPv4 | F | ---- | IPv6 | IPv4 | IPv4 | ---- | | Dual IP | | | | Dual IP | ====================================================== | IPv4 | | | | IPv6 | G | ---- | IPv6 | Dual IP| IPv6 | ---- | | Dual IP | | | | Dual IP | ====================================================== | IPv4 | | | | IPv6 | H | ---- | IPv6 |Dual IP | IPv4 | ---- | | IPv4 | | | | Dual IP | ====================================================== | IPv4 | | | | IPv6 | I | ---- | IPv6 | IPv4 | IPv6 | ---- | | IPv4 | | | | Dual IP | ====================================================== | IPv6 | | | | IPv4 | J | ---- | IPv4 | IPv4 | IPv6 | ---- | | Dual IP | | | | Dual IP | ======================================================
The reader should note that Scenarios A-C in Table 1 are variations of compatible hosts communicating across largely (but not entirely) homogenous networks. In each of the first three scenarios, the packet must traverse at least one incompatible network component. For example, Scenario B represents an enterprise that wishes to use IPv6 applications, but has yet to transition its internal networks; its Service Provider also lags, offering only a v4 IP-service. Conversely, Scenario C represents an enterprise that has completed transition to IPv6 in its core networks (as has its Service Provider), but continues to require a legacy IPv4-based application. Scenario D represents the unusual situation where the enterprise has transitioned its core intranetworks to IPv6, but (like Scenario B) it's ISP provider has yet to transition. In addition, this enterprise continues to retain critical legacy IPv4-based applications that must communicate over this heterogeneous network environment. Scenarios E-J represent transitional situations wherein the enterprise has both IPv4 and IPv6 based instantiations of the same application that must continue to interoperate. In addition, these scenarios show that the enterprise has not completed transition to IPv6 in all its organic and/or Service Provider networks. Instead, it maintains a variety of heterogeneous network segments between the communicating applications. Scenarios E and J represent distinctly different extremes on either end of the spectrum. In Scenario E, the enterprise has largely transitioned to IPv6 in both its applications and networks. However, Scenario E shows that a few legacy IPv4-based applications may still be found in the enterprise. On the other hand, Scenario J shows an enterprise that has begun its transition in a very disjointed manner and, in which IPv6-based applications and network segments are relatively rare.
Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. This analysis further corresponds to Scenario A in Section 3 above (although Scenario A shows a transitional situation wherein the enterprise has one network segment still lagging on transition to Dual-IP). Within these IPv6 deployment scenarios the enterprise network administrator would introduce IPv6 by enabling IPv6 on the wire (i.e., within the network infrastructure) in a structured fashion with the existing IPv4 infrastructure. In such scenarios, a number of the existing IPv4 routers (and thus subnets) will be made Dual-IP, such that communications can run over either protocol. Nodes on the Dual-IP links may themselves be IPv4-only or IPv6- capable. The driver for deploying IPv6 on the wire may not be for immediate wide-scale usage of IPv6, but rather to prepare an existing IPv4 infrastructure to support IPv6-capable nodes. Thus, while IPv6 is not used, Dual-IP nodes exist, and the enterprise can be transitioned to IPv6 on demand. Analyzing this scenario against existing transition mechanisms for their applicability suggests a staged approach for IPv6 deployment in the enterprise. Section 7 of this document provides a good basis for such a plan. 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 various stages of deployment. There may be a requirement that some links remain IPv4 only, or some that specifically should not have IPv6 connectivity (e.g., Scenario A of Table 1). There 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), be assigned. In this document, we do not discuss the deployment of Unique Local IPv6 Unicast Addresses [ULA] because the address type and scope selected is orthogonal to the Layer 3 analysis of this document.
A typical deployment would initially involve the establishment of a single "testbed" Dual-IP 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, but also permits 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. Section 7.5 describes the stages for the widespread deployment in the enterprise, which could be undertaken after the basic building blocks for IPv6 deployment are in place. Section 4, we are not considering sparse IPv6 deployment; the goal of Dual-IP deployment is widespread use in the enterprise. Section 4.4 may be required.
BCNF], would be established between the Dual-IP capable routers on the enterprise, thus "bypassing" existing non IPv6-capable routers and platforms. In the widespread Dual-IP scenario, a more structured, manageable method is required, where the administrator has control of the deployment per-link and (ideally) long-term, aggregatable global IPv6 addressing is obtained, planned, and used from the outset. VLAN]. The latter has the significant advantage of not requiring any additional physical cabling/wiring and also offers all the advantages of VLANs for the new Dual-IP 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 interface(s) in the early stages of deployment. The parallel infrastructure should only be seen as an interim step towards full Dual-IP deployment on a unified infrastructure. The parallel infrastructure however allows all other aspects of the IPv6 enterprise services to be deployed, including IPv6 addressing, thus making the enterprise ready for that unifying step at a later date. TBRK].
V6DEF]. The issues can be worked around or mitigated by following the advice in [V6DEF]. Section 3.1 of [BSCN]. This scenario assumes the requirements defined within 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 be IPv6-capable. 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. There is a need for end-to-end communication with IPv6, but the infrastructure only supports IPv4 routing. Thus, the only viable method for end-to-end communication with IPv6 is to tunnel the traffic over the existing IPv4 infrastructure as defined in this analysis document. The network team needs to decide which of the available transition tunneling mechanisms are the most efficient to deploy, so they can be used without disrupting the existing IPv4 infrastructure. Several conditions require analysis, as introduced in the following sub- sections.
applications do not require intranetworks communication at all -- for example, when an application's server is located outside of the enterprise network, or on other intranetworks of the same enterprise. Alternatively, the enterprise could decide to deploy its own transition mechanism node, possibly collocating it adjacent to the border router that connects to the upstream Provider. In this case, intranetnetworks communication using this tunnel endpoint is also possible. Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. Within this document, this situation is captured in Scenario C of Table 1. Some enterprise networks may wish to employ an IPv6-dominant 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, even though the network may be Dual-IP capable. IPv4 routing would not be turned on within an IPv6-dominant network, except if required to support edge IPv4 networks. Under this scenario, communications between IPv6 nodes will use IPv6. When IPv6-capable nodes in the IPv6-dominant network need to communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge router within the IPv6-dominant network will decapsulate the IPv4 packet and route to the path of the IPv4 node on the network. This permits Dual-IP layer nodes to communicate with legacy IPv4 nodes within an IPv6-dominant network. Scenarios E and F from Table 1 depict additional cases where an IPv6-dominant deployment strategy could be in place. In Scenario E, the entire network could be IPv6-dominant, but the Host OS 2 system is running an IPv4 application. In Scenario F, the Host OS 1 system network could be IPv6-dominant, but the rest of the networks are all IPv4.
In each case, communicating with an IPv4 end host or over an IPv4 network requires that a transition point exist within the network to support that operation. Furthermore, the node in the IPv6-dominant network must acquire an IPv4 address (to interoperate with the IPv4 end host), and locate a tunnel endpoint on their network which permits the IPv4 packet to be tunneled to the next-hop IPv6 router and eventually to a destination Dual-IP router. While retaining interoperability with IPv4 is a noble goal for enterprise architects, it is an unfortunate fact that maintaining IPv4 services in an IPv6-dominant network slows and may even impede your ability to reap the maximum benefits of IPv6. The decision whether or not to use an IPv6-dominant network deployment strategy is completely driven by the enterprise's business and operational objectives and guided by the enterprise's transition plan. Sections 4-6 of this document. Section 3.2 of [BSCN]. We do not go into detail on all aspects of such components in this document. In this document, we focus on Layer 3 issues.
BCNF] to the upstream provider. ALLOC]. Should an enterprise change their provider, a procedure for enterprise renumbering between providers is described in [RENUM]. 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; however, these aspects should be addressed in Stage 2.
when the number of nodes on a subnet grows, larger IPv4 prefixes are then required, and potentially time-consuming and disruptive renumbering events will follow. With IPv6, a link can in effect have any number of nodes, allowing link growth without the need to adjust prefix allocations with the associated renumbering requirement. The size of the initial site allocation (currently recommended to be a /48) also is likely to allow room for site growth without a need to return to the connectivity provider to obtain more, potentially non-sequential, address space (as is the case for IPv4 today, with the associated paperwork and probable delays). At the time of writing, best practice in IPv6 site address planning is restricted due to limited wide-scale deployments. Administrators should allocate /64 size prefixes for subnets, and do so in a way that has scope for growth within a site. The site should utilize a plan that reserves space for topological growth in the site, given that its initial IPv6 prefix allocation (currently recommended to be a /48) is likely to include such room for growth. Also see "IPv6 Unicast Address Assignment" [UNAD]. DNSV6R] and communicating over IPv6 transport. Specific IPv6 DNS issues are reported in [DNSOP6]. BGP4], IS-IS [ISIS], OSPFv3 [OSPF], and RIPng [RIPng].
NIS], and DHCP [DHCPv4]. In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] may be used to configure a host with a global IPv6 address, a default router, and on-link prefix information. Where support for secure autoconfiguration is required, SEND [SEND] can be used. Readers should see the applicability statements to IPsec [IPSEC] within the SEND document. A stateless configured node wishing to gain other configuration information (e.g., DNS, NTP servers) will likely need a Stateful DHCPv6 [DHCPv6] service available. For nodes configuring using DHCPv6, where DHCPv6 servers are offlink, a DHCPv6 Relay Agent function will be required. Where DHCPv4 and DHCPv6 service are deployed together, dual-stack considerations need to be made, as discussed within current work on DHCP dual-stack issues [DHDS]. Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; there is support for DHCPv6 to assign privacy addresses to nodes in managed environments. NAP]. This describes how the perceived security with IPv4 NAT can be achieved and surpassed with IPv6, i.e., how IPv6
technology can be used to provide the market-perceived benefits of IPv4 NAT. Where deployed, intrusion detection systems will need to be enhanced to check IPv6 transport both for known application layer attack patterns and for new potential IPv6 threats, e.g., excessive hop-by- hop headers or errant IPv6 header options. The deployment of specific transition mechanisms may also introduce threats, e.g., carrying IPv6 data tunneled in IPv4. The site security policy should embrace the transition mechanisms that are deployed. An overview of IPv6 security issues can be found in [V6SEC]. This includes discussion of issues specific to the IPv6 protocol, to transition mechanisms, and to IPv6 deployment itself. In addition, an enterprise should review all current host-based security requirements for their networks and verify support for IPv6. Section 7.4.4, above, it is likely that IPv6 links will be congruent with IPv4 subnets because IPv4 subnets tend to be created for geographic, policy, or administrative reasons that would be IP version-independent. While the use of IPv6 by some applications can be administratively controlled (e.g., in the case of open source software by compiling the application without IPv6 support enabled), the use of IPv6 transport, and preference over IPv4 transport, will vary per application based on the developer/author's implementation. A Dual-IP deployment will often be made by sites wishing to support use of IPv6 within a site, even if IPv6 transport is not preferred by all applications. Putting support for IPv6 in all site infrastructure (DNS, email transport, etc.) allows IPv6 usage to be phased in over time. As nodes become IPv6 capable, and applications and services IPv6 enabled, the IPv6 capable infrastructure can be leveraged. For most networks, Dual-IP will be at the very least a
medium-term transition towards an IPv6-dominant future. However, the introduction of IPv6 support, with the potential benefits of globally aggregatable public address usage (with [NAP]) and other new IPv6 capabilities, can bring more immediate benefits for the site. Section 3, and within the context of the analysis discussed in Sections 4, 5, and 6. Table 1 provides a number of common scenarios that an enterprise architect might encounter as they consider how and where they should consider deploying transition mechanisms to support the network transition to IPv6. Selecting the most appropriate mechanism for each scenario is more of an art than a science and consequently making recommendations against each of the ten scenarios would be simply fodder for sharpshooters touting their favored product. However we can provide some high-level guidance that should benefit the architect's decision-making process. Section 4. In the second common theme (depicted in Scenarios B-D of Table 1), the enterprise is comprised of compatible hosts, with one or more incompatible network touchpoints in between. As described in Section 184.108.40.206, tunneling can be used to "bypass" the incompatible network segments. One tunneling option, manually configured tunnels [BCNF] could be used by the enterprise, but as the name implies, this mechanism provides no automated tunnel configuration.
"Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can be used to support enterprises that do not have an assigned IPv6 prefix address. Identifying the responsible device to perform the tunneling is driven by the position of the incompatible touchpoint. If a local network is incompatible, then host tunneling is appropriate. If the backbone (provider) network is incompatible, then gateway-to-gateway tunneling might be a better choice. By working to ensure tunnel endpoints are always configured at Dual-IP devices, end-to-end communication or services (IPv4 or IPv6) can be preserved. Readers should review the current work regarding tunnels within the IETF Softwire working group and problem statement [SOFTW]. Having IPv6 applications on a Dual-IP host on a v4-only network requires some form of tunneling. Where configured tunnels are not sufficient, a more automatic solution may be appropriate. Available solutions include the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service. ISATAP [ISTP] can be used to provide end-node IPv6 connectivity from nodes on an isolated IPv4 network, through the use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be used when the enterprise network is behind a NAT. Enterprise architects should consider providing a Tunnel Broker [TBRK] [TSPB] as a cost-effective service to local users or applications. Tunnel Brokers can be used to provide tunnel setup for an enterprise using manually configured tunnels and 6TO4 [6TO4]. Tunnel Brokers can automate the use of tunnels across an enterprise deploying IPv6. Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect will need to determine a network transition strategy to tunnel IPv4 within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise Intranet. Or in the case of early deployment of IPv6-dominant networks, the architect will need to address this from the beginning of the required transition planning.
This leads us to the third theme (represented by Scenarios E and G): incompatible applications communicating across a homogenous network. Translation is an obvious solution, but not recommended except for legacy devices that are at the network edge and cannot or never will be upgraded to IPv6. A more scalable solution would be to use an Application Layer Gateway (ALG) between the incompatible hosts. Section 7.4.5, where external references to overview documents [V6SEC] [NAP] are also included. [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005. [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[ISTP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [UMAN] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. [ISPA] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005. [OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [BGP4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990. [RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [APPS] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RENUM] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006. [DNSV6R] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [NIS] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. [DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [IPSEC] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005. [SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP", Work in Progress, August 2005. [V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2006. [NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", Work in Progress, January 2007. [CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and Analysis", Work in Progress, March 2007.
[DHDS] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006. [UNAD] Van de Velde, G., Popoviciu, C., and T. Chown, "IPv6 Unicast Address Assignment", Work in Progress, March 2007. [VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", RFC 4554, June 2006. [V6DEF] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006. [SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, March 2007.
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 architecture. 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 applications. 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 enterprise will have slow technical refresh/replacement paths and will need to communicate over the IPv6 dominant infrastructure for years until they are replaced. The IPv6-dominant enterprise network will need to be interoperable with its own legacy networks, commercial networks, and the legacy networks of similar organizations that will remain IPv4-dominant during a long transition period. Reserve units, contractors, other agencies, and international partners may need IPv4 service across this enterprise's IPv6-dominant backbone. Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the aggressive transition plan. Requirements: Reduce operation and maintenance requirements and increase net-centricity through aggressive IPv6 transition. Interoperation and coexistence with legacy IPv4 networks and applications is required. 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. Figure 1. ------------ ---------- ---- Wired Connection | Network and| | | .... Wireless Connection | Service |--| Backbone | | Operation | | | ------------ ---------- / | --------------------- / : _|Connection to | / : |Commercial Internet | / : --------------------- Network Backbone -------------- /------|-------------|-------------------- ---------- / ---------- ---------- | Home |/ | Wireless | |External |............. | Base | | Mobile | |Untrusted |+--------- : | Network | | Network | |Network | | : ---------- ---------- ---------- | : | : : | : Local Network -----:------------:----------------------------------- Customer Applications | : : | : +--------+ +--------+ +--------+ | : | | | | | | | : |Customer| |Customer| |Customer|+----------- : | | | | | |.............. +--------+ +--------+ +--------+ Figure 1: Crisis Management Network Topology.
Section 2. Combinations of different building blocks that constitute a 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. In the first three stages, the goal is to offer both IPv4 and IPv6 to the customer, and it is assumed 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 indicated 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 by jumping directly to Stage 3/4 if there are only limited or no legacy concerns. Stage 1: 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, or Teredo. Some early adopter networks are created for pilot studies and networked together through configured tunnels and 6to4. 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 its backbone. It will need to 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. Otherwise, the quality of IPv6 connectivity will likely be poor and the transition to Stage 2 will be delayed. Stage 2: 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 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. Stage 3: IPv6 Dominance Applications are deployed specifically to use IPv6 as benefit; thus, network backbone and nodes use IPv6 and not IPv4, except where IPv4 is legacy.
Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.