RFC 4852
IPv6 Enterprise Network Analysis - IP Layer 3 Focus
Part 1 of 7 💖 more parts coming, bestie!
Title Block 🎀
- Series and number: This is RFC 4852, from the Network Working Group.
- Title: IPv6 Enterprise Network Analysis - IP Layer 3 Focus
- Authors: J. Bound and Y. Pouffary (both Hewlett-Packard), S. Klynsma (MITRE), T. Chown (University of Southampton), and D. Green (Command Information).
- Category: Informational
- Date: April 2007
- Obsoletes / Updates: The header doesn't list any RFCs this one obsoletes or updates.
Status of This Memo 📋
This memo gives information to the Internet community. It is not an Internet standard of any kind, and the distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007).
Abstract ✨
This doc is all about moving enterprise networks over to IPv6, with the focus on IP Layer 3. These networks have multiple internal links, one or more router connections to one or more Providers, and a network operations entity keeping everything running. The analysis uses a base set of transition notational networks and requirements that grew out of an earlier doc on enterprise scenarios. It then looks at the transition analysis an enterprise needs in order to move to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment inside the enterprise. Last, it recommends a set of transition mechanisms for each notational network. 🦋
Table of Contents 🗂️
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
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure ..12
4.2.2.2. 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 .................................291. Introduction 🌸
This doc is about moving enterprise networks to IPv6, focusing on IP Layer 3. These networks have multiple internal links, one or more router connections to one or more Providers, and a network operations entity managing them. The analysis is built on a base set of transition notational networks and requirements that expand on an earlier doc about enterprise scenarios. It digs into the focused set of transition analysis an enterprise needs to get to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment inside the enterprise. Then it recommends a set of transition mechanisms for each notational network. 💅
The audience is the enterprise network team that's thinking about deploying IPv6. It'll help teams that need to figure out their IPv6 transition strategy. Those teams are expected to include people from management, network operations, and engineering. The notational networks and analysis give an example set of cases the enterprise can use to build its own IPv6 transition strategy. 🧚
The enterprise analysis starts with a matrix, which is a tool for showing the different IPv4 and IPv6 deployment possibilities. Next, the doc backs up an enterprise-wide Dual-IP layer deployment strategy, so you can see how it can be planned and what your options are. After that, it covers sparse IPv6 nodes inside the enterprise, plus the requirements you need to think about and implement if the enterprise stays on an IPv4-only routing infrastructure for a while. The next part focuses on using IPv6 when it's the dominant protocol across all or part of the enterprise network. 👑
Then the doc talks about the general issues and applicability from all that earlier analysis. It wraps up with a set of current transition mechanism recommendations for the notational network scenarios, to support an enterprise that's planning an IPv6 deployment. 🦋
Real talk, though: this doc only covers deployments where Dual-IP Layer 3 is supported across the network and on the enterprise's nodes. Deployment analysis for IPv6-only nodes or IPv6-only Provider deployments is beyond its scope and needs to be done separately. It also doesn't try to define or discuss any use of network address translation [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 doc focuses on IP Layer 3 deployment, the same way other IPv6 deployment analysis works have done [UMAN] [ISPA] [3GPA]. It covers deploying IPv6 "on the wire", including address management and DNS services. 🌈
We're also assuming the network administration team is doing the enterprise deployment. In other words, this doc doesn't cover an individual user getting IPv6 connectivity (from some external IPv6 provider) from inside an enterprise network. A lot of the analysis applies to wireless networks too, but wireless networks have extra considerations that aren't covered here. 📡
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 doc also gives you Appendix A, which shows a Crisis Management enterprise network. It's an example that has all the properties analyzed in Sections 3, 4, 5, 6, and 7. Plus, we recommend reading another use-case doc about an IPv6 transition for a Campus Network [CAMP]. 🎓
Also, know that training for an enterprise transitioning to IPv6 is a parallel effort. It's out of scope for this doc, though. 📚
2. Terminology 💖
Enterprise Network: a network with multiple internal links and one or more router connections to one or more Providers, which 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 that can support both IPv6 and IPv4.IPv4-only: a node or network that can support only IPv4.IPv6-only: a node or network that can support only IPv6. This does not imply an IPv6 only stack in this document.Dual-IP: a network or node that supports both IPv4 and IPv6.IP-capability: the ability to support IPv6 only, IPv4 only, or Dual-IP Layer.IPv6-dominant: a network running IPv6 routing and control plane services that provides transport for both IPv4 and IPv6 protocol services.Transition Implementation: the network strategy the enterprise uses to transition to IPv6.
Heads up, bestie: these definitions are the vocab the rest of the doc relies on, so keep them handy! 🧠
Section 3 is up next, and it's where the tools matrix shows up. Stay tuned 👀🫶
3. Enterprise Matrix Analysis for Transition ✨
okay so before you pick a transition mechanism, bestie, your enterprise needs an in-depth, up-to-date understanding of its current IT environment 🧐 that's the foundation for everything. And ngl, one size does NOT fit all 🙅♀️ it's suggested that you pick mechanisms that mess with your existing setup as little as possible 💅 when you're choosing one, think about the functionality you need, how well it scales, and the security implications of each option 🔐 very important, no skipping this part 😭
to make this all concrete, we built a matrix of the different scenarios you might run into during an IPv6 transition at Layer 3 🦋 picture a notional enterprise with hosts hanging off enterprise-owned intranets in two different global locations, with the Internet in between 🌍 the enterprise owns, runs, and maintains its own intranetworks, but it leans on an outside provider for Internet Service 🛜 and the local and destination intranetworks are run by different orgs inside the same enterprise, so they could have different IP-capabilities at any given moment during the transition 🌸
now, covering every possible combo of network IP-capability would be totally impractical 💀 so we skipped the trivial notional networks (pure IPv4, pure IPv6, and ubiquitous Dual-IP) 🙈 we also couldn't think of any IPv6-only ISPs or IPv6-only nodes coming up in the near term, so those scenarios aren't covered either 🤷♀️ we assume that every node hosting IPv6 applications is Dual-IP 🫶 and the matrix doesn't assume or suggest that network address translation is used. the authors do recommend that NAT not be used in these notional cases 🚫
IPv6-only ISPs and IPv6-only nodes are going to need their own separate analysis someday, and that's beyond the scope of this doc 🧚
okay, the main event 🎀 Table 1 below lays out ten possible Transition Implementations that you could meet in an enterprise and that might need analysis and an IPv6 transition mechanism picked for that notional network 💖 each implementation is one row of the matrix, and the columns work like this:
- The first column is the protocol the application uses and, underneath it, the IP-capability of the node that originates the IP packets.
(Application/Host 1 OS)- The second column is the IP-capability of the host network where the originating node sent the packet from.
(Host 1 Network) - The third column is the IP-capability of the service provider network.
(Service Provider) - The fourth column is the IP-capability of the destination network where the originating IP packets get received.
(Host 2 Network) - The fifth column is the protocol the application uses and, underneath it, the IP-capability of the destination node receiving the originating IP packets.
(Application/Host 2 OS)
- The second column is the IP-capability of the host network where the originating node sent the packet from.
for example, notional network 1 is an IPv6 application on a Dual-IP host trying to start a communications exchange with a destination IPv6 application 👀 so the packets have to first cross the host's originating IPv4 network (intranet), then the service provider's and destination host's Dual-IP network 🧵
obviously Table 1 doesn't cover every possible scenario 🙃 the trivial notional networks (like pure IPv4, pure IPv6, and ubiquitous Dual-IP) aren't addressed. BUT the authors feel these ten scenarios represent the vast majority of transitional situations you're likely to run into in today's enterprise 💯 so those ten are what we'll use for the enterprise deployment analysis ✨
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 |
======================================================heads up, the reader should know that Scenarios A-C are all versions of compatible hosts talking across mostly (but not entirely) homogeneous networks 🌷 in each of those first three, the packet has to cross at least one incompatible network component 🚧 like, Scenario B is an enterprise that wants to use IPv6 apps but hasn't transitioned its internal networks yet, and its Service Provider is also lagging and only offering a v4 IP-service 😩 flip it, and Scenario C is an enterprise that's finished moving its core networks to IPv6 (and so has its Service Provider), but it still needs a legacy IPv4-based app 🕰️
Scenario D is the unusual one 🦄 the enterprise has moved its core intranetworks to IPv6, but (like Scenario B) its ISP hasn't transitioned yet 🙃 on top of that, the enterprise is still holding onto critical legacy IPv4-based apps that have to talk across this mixed network environment 🫠
Scenarios E-J are the transitional situations where the enterprise has both IPv4 and IPv6 instances of the same application that still need to interoperate 🔄 these also show the enterprise hasn't finished moving to IPv6 in all its organic and/or Service Provider networks, so it has a bunch of heterogeneous network segments between the communicating apps 🧩 Scenarios E and J are basically the two extremes on either end of the spectrum 🌈 in Scenario E, the enterprise has mostly moved to IPv6 for both apps and networks, but a few legacy IPv4-based apps might still be hanging around 👑 Scenario J is the opposite: a very disjointed transition where IPv6-based apps and network segments are pretty rare 💀
4. Wide-Scale Dual-Stack Deployment Analysis 🌸
okay this section is where we get into Scenario 1 as described in Section 3.1 of [BSCN] 📖 the scenario, assumptions, and requirements all come straight from the [BSCN] text 🫶 this analysis lines up with Scenario A from Section 3 above (although Scenario A has a transitional situation where the enterprise still has one network segment lagging on the transition to Dual-IP 🐢)
in these IPv6 deployment scenarios, the enterprise network administrator brings IPv6 in by turning it on on the wire (i.e., inside the network infrastructure) in a structured way, alongside the existing IPv4 infrastructure 🛠️ so a bunch of the existing IPv4 routers (and therefore subnets) get made Dual-IP, which means communications can run over either protocol ✨
nodes on the Dual-IP links might be IPv4-only or IPv6-capable 🧸 the reason for deploying IPv6 on the wire might not be immediate wide-scale IPv6 usage, but rather getting the existing IPv4 infrastructure ready to support IPv6-capable nodes 🌱 so even though IPv6 isn't being used yet, Dual-IP nodes exist, and the enterprise can switch over to IPv6 whenever it's needed 💜
analyzing this scenario against existing transition mechanisms for their applicability points toward a staged approach for IPv6 deployment in the enterprise 🪜🔥
4.1. Staged Dual-Stack Deployment ✨
Okay bestie, in these scenarios (and honestly most others too), the site administrator should make a staged plan for bringing in a Dual-IP IPv6 network. Section 7 of this document is a good basis for that plan 📋
In an enterprise network, the admin will usually want to roll out IPv6 in a structured, controlled way, so IPv6 can be switched on for specific links at different stages. Some links might need to stay IPv4 only, and some specifically should not have IPv6 connectivity (e.g., Scenario A of Table 1). There may also be a requirement that aggregatable global IPv6 addresses be assigned, coming from the upstream provider's allocation from the Regional Internet Registries (RIRs) 🌍
We're not going to get into Unique Local IPv6 Unicast Addresses [ULA] here, because the address type and scope you pick is totally orthogonal to the Layer 3 analysis in this document 🙅♀️
A typical deployment starts with one "testbed" Dual-IP subnet at the enterprise site before anything goes wider. This testbed is so good because it lets you evaluate and verify the IPv6 capability of specific platforms and applications, and it lets you do the steps in Sections 7.3 and 7.4 without any (potential) adverse impact on production elements of the enterprise 🧪
Section 7.5 covers the stages for widespread deployment across the enterprise, which can happen once the basic building blocks for IPv6 deployment are in place 🚀
4.2. Routing Capability Analysis for Dual-IP Deployment 🛣️
Choosing the IPv6-capable routing infrastructure is a critical part of Dual-IP deployment, and the path you take depends on whether the enterprise already has Layer 2/3 switch/router equipment with IPv6 (routing) capability, or equipment that can be upgraded to have it 💅
Heads up: in Section 4, we're not considering sparse IPv6 deployment. The goal of Dual-IP deployment is widespread use across the enterprise 💖
4.2.1. IPv6 Routing Capability 🦋
When IPv6 routing capability already exists in the infrastructure, the network administrator can turn on IPv6 on the same physical hardware as the existing IPv4 service. Enabling both is the end goal for any enterprise doing Dual-IP deployment, once the capability, performance, and robustness of the Dual-IP operational deployment have been verified 👑
Ideally, IPv6 capability spans the whole enterprise, so you can deploy on any link or subnet. If it doesn't, techniques from Section 4.4 may be required 🫶
4.2.2. IPv6 Routing Non-Capability 🙈
If the enterprise can't provide IPv6 routing right away, there are alternative transition methods. The enterprise administrator basically has two choices: tunnel IPv6 over some or all of the existing IPv4 infrastructure, or deploy a parallel IPv6 routing infrastructure that provides IPv6 connectivity into existing IPv4 subnets 🌸
It may end up being the case that a node's IPv4 and IPv6 default routes, used to reach other links (subnets), go through different routing platforms 🧩
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure 🚇
Picture this: some edge routers are IPv6-capable, but others, and maybe the enterprise backbone itself, are not (Scenario B of Table 1). Tunneling, as described in [BCNF], would be set up between the Dual-IP capable routers on the enterprise, so it "bypasses" the existing non-IPv6-capable routers and platforms 🫣
In the widespread Dual-IP scenario, you need a more structured, manageable method, where the administrator controls the deployment per link and, ideally, long-term aggregatable global IPv6 addressing is obtained, planned, and used from the very beginning 📋✨
4.2.2.2. Deploy a Parallel IPv6 Infrastructure 🏗️
Alternatively, the administrator can deploy a brand new, separate IPv6-capable router (or set of routers). It's totally possible that a parallel infrastructure like this would end up being IPv6-dominant 💜
This approach would likely need additional hardware, but the upside is that the existing IPv4 routing platforms aren't disturbed by the introduction of IPv6 🙌
To get IPv6 out to existing IPv4 enterprise subnets, you can either employ dedicated physical infrastructure or, if it's available, use IEEE 802.1q VLANs, as described in [VLAN]. The VLAN route is a big win because it doesn't need any extra physical cabling or wiring, and it also gives you all the VLAN advantages for the new Dual-IP environment 🎀 Lots of router platforms can tag multiple VLAN IDs on a single physical interface based on the subnet/link the packet is destined for. So 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 on the way to full Dual-IP deployment on a unified infrastructure. That said, it still lets all the other aspects of IPv6 enterprise services get deployed, including IPv6 addressing, which makes the enterprise ready for that unifying step later on 🔥
4.3. Remote IPv6 Access to the Enterprise 🏠
When the enterprise's users are off-site and using an ISP that doesn't support any native IPv6 service or IPv6 transition aids, the enterprise may consider deploying its own remote IPv6 access support 🌈 For example, that remote support could be offered by deploying an IPv6 Tunnel Broker [TBRK].
4.4. Other Considerations 🤔
There are some issues that come with turning IPv6 on by default, including application connection delays, poor connectivity, and network insecurity, as discussed in [V6DEF]. The good news is that these issues can be worked around or mitigated by following the advice in [V6DEF] 💅
5. Sparse Dual-Stack Deployment Analysis 🌷
This section covers Scenario 2 as described in Section 3.1 of [BSCN]. It assumes the requirements defined within the [BSCN] text 💖
IPv6 deployment within the enterprise network, on top of an existing IPv4 infrastructure, could be motivated by mission-critical or business applications or services that require IPv6. In this case, the only prerequisite is that the nodes using those IPv6 applications need to be upgraded to be IPv6-capable. The routing infrastructure won't be upgraded to support IPv6, and the enterprise doesn't want to deploy a parallel IPv6 routing infrastructure at this point, since that's an option in Section 4 🙅♀️
There's a need for end-to-end communication with IPv6, but the infrastructure only supports IPv4 routing. So 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 need analysis, as introduced in the following sub-sections 🧐
5.1. Internal versus External Tunnel Endpoint 🔀
Let's say the upstream provider has deployed some IPv6 services, either native IPv6 in its backbone or in the access network, or a combination of both (Scenario B of Table 1). In this case, the provider will likely also deploy one or more transition mechanisms to support its IPv6 subscribers 🫶 The enterprise could totally decide to take advantage of those transition services offered by the Provider. But this usually means that individual nodes in the network each need their own IPv6-in-IPv4 tunnel 😬 The end result is somewhat inefficient IPv6 intranetworks communication, because all IPv6 traffic must be forwarded by the enterprise's IPv4 infrastructure to the Tunnel Endpoint offered by the Provider. Still, this may be acceptable, especially if the IPv6 applications don't need intranetworks communication at all. For example, that's the case when an application's server is located outside the enterprise network, or on other intranetworks of the same enterprise 🌍
Alternatively, the enterprise could decide to deploy its own transition mechanism node, possibly collocated next to the border router that connects to the upstream Provider. In this case, intranetnetworks communication using this tunnel endpoint is also possible 🙌
5.2. Manual versus Autoconfigured 🛠️
If the number of nodes using IPv6 is low, the first option is to use statically configured tunnels. However, automatically configured tunnels may be preferable, especially if the number is higher 💜
6. IPv6-Dominant Network Deployment Analysis 👑
In this section we're covering Scenario 3 as described in Section 3.1 of [BSCN]. The scenario, assumptions, and requirements all come from the [BSCN] text. Within this document, this situation is captured in Scenario C of Table 1 🦋
Some enterprise networks may want to employ an IPv6-dominant network deployment strategy. Essentially, that means the network, or specific sites within the enterprise network, will transition to IPv6 using only IPv6 routing to transfer both IPv4 and IPv6 packets across 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 it's required to support edge IPv4 networks 🌸
In this setup, communication between IPv6 nodes uses IPv6. When IPv6-capable nodes in the IPv6-dominant network need to talk to IPv4 nodes, those IPv6 nodes use their Dual-IP implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge router within the IPv6-dominant network decapsulates the IPv4 packet and routes it along the path to the IPv4 node on the network. This lets Dual-IP layer nodes communicate with legacy IPv4 nodes inside 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's network could be IPv6-dominant, but the rest of the networks are all IPv4 🧁
In each case, talking to an IPv4 end host or over an IPv4 network requires a transition point to exist within the network to support that operation. Also, 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 its network that lets the IPv4 packet be tunneled to the next-hop IPv6 router, and eventually to a destination Dual-IP router 🚦
While keeping interoperability with IPv4 is a noble goal for enterprise architects, it's an unfortunate fact that maintaining IPv4 services in an IPv6-dominant network slows things down and may even impede your ability to reap the maximum benefits of IPv6 😭
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 💅
7. General Issues from Analysis 📚
In this section, we describe generic enterprise IPv6 deployment issues that apply to the analysis in Sections 4-6 of this document 🌈
7.1. Staged Plan for IPv6 Deployment 🗺️
okay bestie, so the enterprise network administrator needs to follow a staged plan for IPv6 deployment 💅 what that literally means is a strategic identification of the enterprise network has to be done for all the points and components of the transition ✨
7.2. Network Infrastructure Requirements 🎀
the enterprise components are covered in Section 3.2 of [BSCN] 📚 we don't go into detail on every aspect of those components in this doc, because we're focusing on Layer 3 issues here 🧚
7.3. Stage 1: Initial Connectivity Steps 🌈
the first steps for IPv6 deployment don't really involve technical stuff per se 🫶 the enterprise needs to pick an external IPv6 provider and get globally routable IPv6 address space from that provider.
7.3.1. Obtaining External Connectivity
the enterprise service provider would typically be a topographically close IPv6 provider that can give an IPv6 upstream link 🌸 it's expected that the enterprise uses native IPv6 upstream connectivity or, if that's not available, a manually configured tunnel [BCNF] to the upstream provider.
7.3.2. Obtaining Global IPv6 Address Space
the enterprise gets global IPv6 address space from its selected upstream provider, as provider-assigned (PA) address space 💜
the enterprise should receive at least a /48 allocation from its provider, as described in [ALLOC] ✨
should an enterprise change providers, a procedure for enterprise renumbering between providers is described in [RENUM] 🦋
7.4. Stage 2: Deploying Generic Basic Service Components 🧁
most of these are discussed in Section 4 of [BSCN] 📖 here we comment on the bits we think are in scope for this analysis doc. so we have not included network management, multihoming, multicast, or application transition analysis here 🙈 however, these aspects should be addressed in Stage 2 💅
7.4.1. Developing an IPv6 Addressing Plan
a site needs to formulate an IPv6 addressing plan, using the globally aggregatable public IPv6 prefix allocated to it by its upstream connectivity provider 🍓
in a Dual-IP deployment, the site will need to decide whether it wants IPv6 links to be congruent with existing IPv4 subnets 🤔 if it does, nodes fall into the same links or subnets for both protocols. this scheme could be followed, with IPv6 prefix allocations made so that room for topological growth is provisioned (reducing the potential requirement for future renumbering due to restructuring) 🌷
a beneficial property of IPv6 is that an administrator won't need to invest as much effort in address conservation 💖 with IPv4, a site will likely allocate subnets to be as small as possible for the number of hosts currently in the subnet (e.g., a /26 for 50 nodes) because IPv4 address conservation is required 😩 this creates problems when the number of nodes on a subnet grows, since larger IPv4 prefixes are then required, and potentially time-consuming and disruptive renumbering events follow 💀
with IPv6, a link can in effect have any number of nodes 🙌 that allows link growth without needing to adjust prefix allocations and the renumbering requirement that comes with it. the initial site allocation (currently recommended to be a /48) also is likely to allow room for site growth, without a need to go back to the connectivity provider for 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] 📎
7.4.2. IPv6 DNS
the enterprise site should deploy a DNS service that is capable of both serving IPv6 DNS records using the AAAA format [DNSV6R] and communicating over IPv6 transport 🌐
specific IPv6 DNS issues are reported in [DNSOP6] 🔍
7.4.3. IPv6 Routing
the enterprise network will need to support methods for internal and external routing 🛣️
for a single-homed single-site network, a static route to a single upstream provider may be sufficient 🎈 although the site may choose to use an exterior routing protocol, especially where it has multiple upstream providers 🦄
for internal routing, an appropriate interior routing protocol may be deployed 🧭 the IPv6 routing protocols that can be used are as follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF], and RIPng [RIPng] 👑
7.4.4. Configuration of Hosts
an enterprise network has a bunch of tools available for delegating and managing IPv4 addresses and other configuration information 🧰 these include manual configuration, NIS [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 that wants 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 🫣
7.4.5. Security
when deploying IPv6 within a Dual-IP network, a site will need to implement its site security policy for IPv6-capable nodes, the same way it does for IPv4-capable nodes 🛡️ for example, a border firewall should be capable of filtering and controlling IPv6 traffic by enforcing the same policy it already does for IPv4 🔥
okay this part is a whole vibe: a site also needs to review its security policy in light of IPv6-specific functionality that will be deployed in the site, e.g., Mobile IPv6, stateless autoconfiguration (and SEND), IPv6 Privacy Extensions, and end-to-end IPsec 😭 plus, a site will need to review the use of globally aggregatable public address space where, for IPv4, private addressing and NAT may have been used 👀
an overview of how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT can be found in [NAP] 💅 it 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 ✅
7.5. Stage 3: Widespread Dual-Stack Deployment On-Site 🎉
with the basic building blocks of external connectivity, interior IPv6 routing, an IPv6 DNS service, and address allocation management in place, the IPv6 capability can be rolled out to the wider enterprise 🚀 this involves putting IPv6 on the wire in the desired links, and enabling applications and other services to begin using an IPv6 transport 💫
in the Dual-IP deployment case, this means enabling IPv6 on existing IPv4 subnets 🧃 as described in 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 💖
8. Applicable Transition Mechanisms ✨
this section will provide general guidance for the use of specific transition mechanisms, which in turn can be used by the enterprise to support the enterprise matrix notional networks (rows) in 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, so 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 🫶
8.1. Recognizing Incompatible Network Touchpoints
Okay bestie, figuring out which of the ten scenarios in Table 1 you're in is honestly way less important than spotting the critical touchpoints where incompatible networks meet inside the enterprise 🫶. Unless the enterprise is offering a transition mechanism as a service, a mechanism needs to be considered right at those touchpoints ✨.
Quick Table 1 review and ngl, the ten scenarios boil down to four major themes 💅. The simplest one (and the most loved, because it's so flexible) is widespread Dual-IP with compatible hosts at either end 💖. That's Scenario A, and we already covered the transition mechanism stuff in some detail in Section 4 🌸.
Theme two (Scenarios B-D of Table 1) is when the enterprise is full of compatible hosts but there's one or more incompatible network touchpoints in between 🦋. As Section 4.2.2.1 explains, tunneling can be used to "bypass" those incompatible network segments 🚇. One option is manually configured tunnels [BCNF], which the enterprise could use, but as the name implies, it gives you zero automated tunnel configuration 🙈.
"Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can support enterprises that don't have an assigned IPv6 prefix address 🌈.
Figuring out which device does the tunneling depends on where the incompatible touchpoint sits 👑. If a local network is the incompatible one, host tunneling is appropriate. If the backbone (provider) network is incompatible, gateway-to-gateway tunneling might be a better choice ✨. By making sure tunnel endpoints are always configured at Dual-IP devices, end-to-end communication or services (IPv4 or IPv6) can be preserved 💜.
Also go check out the current tunnel work in the IETF Softwire working group and its problem statement [SOFTW] 📚.
Having IPv6 applications on a Dual-IP host sitting on a v4-only network requires some form of tunneling 😭. If configured tunnels aren't sufficient, a more automatic solution may be appropriate. The options include the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service 🧚. ISATAP [ISTP] can give end-node IPv6 connectivity from nodes on an isolated IPv4 network, through automatic tunneling of IPv6 in IPv4 🌸. Teredo [TRDO] can be used when the enterprise network is behind a NAT 🎀.
Enterprise architects should consider offering a Tunnel Broker [TBRK] [TSPB] as a cost-effective service to local users or applications 💅. Tunnel Brokers can provide tunnel setup for an enterprise using manually configured tunnels and 6TO4 [6TO4], and they can automate the use of tunnels across an enterprise deploying IPv6 🫶.
Later in the transition process, after the enterprise has moved to a predominantly IPv6 infrastructure, the architect will need a network transition strategy for tunneling IPv4 within IPv6 [V6TUN] across IPv6-dominant links or the enterprise Intranet 🦋. Or, if IPv6-dominant networks are deployed early, the architect will need to deal with this from the very beginning of the required transition planning 🔥.
8.2. Recognizing Application Incompatibilities
Once the incompatible network touchpoints are recognized, the architect is also responsible for spotting application incompatibilities 🕵️. During the transition period, especially for large enterprises, it's totally expected that an application hosted at one location may lead (or lag) the IPv6-compatibility of its peer (or server) at some other location 💀.
This brings us to theme three (represented by Scenarios E and G): incompatible applications communicating across a homogenous network 🧩. Translation is the obvious answer, but it's not recommended except for legacy devices at the network edge that can't be upgraded to IPv6 (or never will be) 🙈. A more scalable solution is an Application Layer Gateway (ALG) between the incompatible hosts 🌟.
8.3. Using Multiple Mechanisms to Support IPv6 Transition
Inevitably, while transitioning a large enterprise to IPv6, the architect will be faced with incompatible hosts and, at different parts of the enterprise at the same time, incompatible networks 🌀. These highly complex situations are theme four in Table 1 (specifically Scenarios F, H, I, and J). Keeping IP interoperability working here requires additional planning and may require multiple or even nested use of diverse transition mechanisms 🧠. For example, an ALG collocated with the application server may be required to service both IPv4 and IPv6 data streams that are simultaneously tunneled through incompatible network segment(s) 💫.
9. Security Considerations ✨
Security considerations for IPv6 deployment in a Dual-IP environment are discussed above in Section 7.4.5, where external references to overview documents [V6SEC] [NAP] are also included 🔐. This part is seriously important, bestie, so go read it before you deploy anything 😭.
10. References
10.1. Normative References
- [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.
10.2. Informative References
- [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.
11. Acknowledgments
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet 🫶💖
Appendix A. Crisis Management Network Scenarios ✨
A.1. Introduction ✨
okay so this appendix is gonna walk through the different ways a crisis management network for emergency services, defense, or security forces can bring in IPv6 while it's already running IPv4 service 💅. then we look at the scenarios, check how well the existing transition mechanisms actually fit, and call out the known challenges 🔥.
when a crisis management enterprise deploys IPv6, the goal is to give IPv6 connectivity on its institutional fixed networks AND on the mobile wireless services that get deployed to a crisis area 🌍. the new IPv6 service has to be added on top of an IPv4 service that already exists, the IPv6 rollout must not interrupt that IPv4 service (no drama!! 🙅♀️), and the two have to be interoperable 🫶.
enterprises reaching IPv4 across mobile ground networks, airborne networks, and satellites will find different ways to add IPv6, depending on their network architecture, funding, and institutional goals 🦋. this doc covers a small set of scenarios that represent the IPv6 architectures expected to dominate crisis management networks over the next decade 🔮. it checks how relevant the existing transition mechanisms are in these deployment scenarios, and it points out the lack of essential functionality in those methods for a provider trying to support IPv6 services in them 😭.
the doc focuses on services that include both IPv6 and IPv4. it does not cover accessing IPv4 services across IPv6-only networks 🌸. detailed implementation plans for IPv6 in defense networks are also out of scope 🎀.
A.2. Scenarios for IPv6 Deployment in Crisis Management Networks ✨
Scenario 1: Limited IPv6 Deployment Network 🧚
sparse IPv6 dual-stack deployment in an existing IPv4 network infrastructure. the enterprise already has IPv4 and wants to deploy a particular set of IPv6 "applications", with some ability to interoperate with other institutions that are using IPv6 services. the IPv6 deployment is limited to the minimum required to run that set of applications.
Assumptions: IPv6 software and hardware components for the application are available, and the platforms for the application are IPv6 capable.
Requirements: do not disrupt the IPv4 infrastructure.
Scenario 2: Dual-Stack Network 💜
wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure. the enterprise with an existing IPv4 network wants to deploy IPv6 alongside it, so it can take advantage of emerging IPv6 network-centric capabilities and be interoperable with other agencies, international partners, and commercial enterprises that are deploying an IPv6 architecture 👑.
Assumptions: the IPv4 network infrastructure in use has an equivalent capability in IPv6.
Requirements: do not disrupt the 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. the dual-stacked defense enterprise network must be interoperable with both IPv4 and IPv6 networks and applications.
Scenario 3: IPv6-Dominant Network 🌈
the enterprise has some limited IPv4-capable/only nodes and applications that need to communicate over the IPv6 infrastructure. this crisis management enterprise is restructuring an existing network, has decided to pursue an aggressive IPv6 transition as an enabler for network-centric services, and wants to run some native IPv6-only networks to get rid of the cost and complexity of supporting a dual stack ⭐. some legacy IPv4 capable nodes and applications inside the enterprise will have slow technical refresh or replacement paths, so they will need to communicate over the IPv6 dominant infrastructure for years until they're 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 stay 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: the required IPv6 network infrastructure is available, or will be available over some defined timeline, to support the aggressive transition plan.
Requirements: reduce operation and maintenance requirements and increase net-centricity through an aggressive IPv6 transition. interoperation and coexistence with legacy IPv4 networks and applications is required. legacy IPv4 nodes, applications, and networks will need to be able to operate across the IPv6 backbone, and they will need to be able to interoperate with the IPv6-dominant network's nodes and applications 💖.
A.3. Description of a Generic Crisis Management Network ✨
okay so a generic network topology for crisis management shows all the different ways a crisis management network can connect its customers through its network infrastructure 🗺️. the institution's existing wired and fixed-site wireless infrastructure can be destroyed or unavailable in a crisis, so the crisis management network must be able to deploy its own mobile wireless network or connect through external wired and wireless networks run by ISPs or partner organizations 🚨. this infrastructure lets us split the basic areas for IPv4/IPv6 interoperability into three main areas: the customer applications, the local network, and the network backbone 🎀.
the basic components in a crisis management network are shown in 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.A.4. Stages of IPv6 Deployment
okay so these stages are built off the generic crisis network scenarios from Section 2 🧚 Mixing different building blocks gives network engineers a whole menu of scenarios to pick from. The ones we care about most are the ones that let the network offer IPv6 to 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's assumed that in the distant future all IPv4 services will eventually switch over to IPv6 🦋 This document covers engineering the first four stages ✨
The four most probable stages are:
- Stage 1: Limited Launch
- Stage 2: Dual-Stack Dominance
- Stage 3: IPv6 Dominance
- Stage 4: IPv6 Transition Complete
Generally, a crisis management network can fully upgrade a current IPv4 network to offer IPv6 services through a dual-stack network in Stage 2, then slowly level up to Stages 3 and 4, as shown in Figure 2 🌈 During Stage 2, when most applications are IPv6 dominant, operational and maintenance costs can go down on some networks by moving to Stage 3 and running backbone networks entirely on IPv6. You add IPv4 backwards compatibility with v4-in-v6 tunneling or translation mechanisms on top of the Stage 2 setup 🎀 When designing a brand-new network, if you need a new IPv6-only service, you can build it for less by jumping straight to Stage 3/4, as long as there are only limited or no legacy concerns 💜
Stage 1: Limited Launch
Stage 1 starts with an IPv4-only network and IPv4 customers. This is the most common situation today, and it's the natural starting point for bringing in IPv6 🌸 During this stage, the enterprise starts connecting individual IPv6 applications running on dual-stacked hosts through host-based tunneling using Tunnel Broker, ISATAP, or Teredo. Some early adopter networks get set up for pilot studies, and they're networked together through configured tunnels and 6to4 🧚
The very first step is getting a prefix allocation (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC, ARIN, LACNIC, RIPE), following the allocation procedures 📝
The crisis management enterprise also needs to set up IPv6 connectivity between its home base networks and its mobile wireless networks over its backbone 🛰️ It needs 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 can't provide IPv6 services, can get IPv6 through tunnels. The longer-term goal, though, is requiring and obtaining IPv6 native connectivity from the transit networks 💅 Otherwise, the quality of IPv6 connectivity will likely be poor, and the move to Stage 2 gets delayed 😭
Stage 2: Dual-Stack Dominance
Stage 2 happens when most applications, local networks, and network backbones become dual-stacked, so native IPv6 connections are enabled ✨ At this point, there's a mix of IPv4 and IPv6 applications and services in use across the enterprise 🌈 The enterprise can become IPv6-capable through software upgrades, hardware upgrades, or a combo of both. Generally, IPv6 gets 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 get IPv6 capability because of upgrade costs, so plans must be made for backwards compatibility for these systems 🙈 Since some new IPv6 services can't be provided through IPv4, and some legacy network connections may not be upgraded yet, tunneling mechanisms have to be provided on the backbone. That way, IPv6 connectivity reaches customer IPv6 applications that still rely on legacy IPv4-only networks 🦋 The tunnels can provide host-based tunneling for individual customers, or site-to-site tunnels that connect small IPv6 domains through IPv4-only networks. If any new applications are IPv6-only rather than dual-stacked, and they 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 get deployed specifically to use IPv6 for its benefits, so the network backbone and nodes use IPv6 and not IPv4, except where IPv4 is still legacy 💖
Authors' Addresses ✨
Here's who wrote this 🎀 Each address block is kept exactly as published:
Jim Bound
HP
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: 603.465.3130
EMail: jim.bound@hp.comYanick Pouffary
HP Competency Center
950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX
FRANCE
Phone: + 33492956285
EMail: Yanick.pouffary@hp.comTim Chown
School of Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.ukDavid Green
Command Information
13655 Dulles Technology Drive
Suite 500
Herndon, VA 20171
USA
Phone: 703.561.5937
EMail: green@commandinformation.comSteve Klynsma
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102-5708
USA
Phone: 703-883-6469
EMail: sklynsma@mitre.orgFull Copyright Statement 🔥
The IETF Trust holds the copyright for 2007 💅 This document is subject to the rights, licenses and restrictions in BCP 78. Except as set out there, the authors keep 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 doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope 🧚 It also doesn't say whether any license under those rights might or might not be available, and it hasn't made any independent effort to find such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📝
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 💜
The IETF invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🦋
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society 🙌 ✨
📦 where this page comes from
- ietf: rfc4852 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms