Internet Edge IPv6 Deployment
Typical enterprise networks connect to the Internet at their perimeter and this is the logical place to start an IPv6 deployment. This is the part of the network topology that touches the Internet through various upstream ISP connections and this is the place to start to bring the IPv6 Internet connectivity into the enterprise. This “Internet Edge” model of IPv6 deployment has been recommended for years by ARIN and the other RIRs as well as the IPv6 community at large. Companies are encouraged to start by IPv6-enabling their public-facing web applications, their e-mail servers, and their authoritative external DNS servers. This has been the guidance that the U.S. Federal Government has given their departments and agencies. The IETF has also documented this recommendation with their Enterprise IPv6 Deployment Guidelines (RFC 7381) as the “External Phase.” Even Cisco provides guidance on Deploying IPv6 in the Internet Edge.
After an enterprise has obtained their IPv6 addressing resources from their RIR and IPv6-enabled their Internet perimeter, the next step would be to bring IPv6 inward to the end-users. Paul Saab of Facebook gave a presentation at NANOG64 titled “The benefits of deploying IPv6 only“ and on slide 17 he showed a graph of daily IPv4 traffic compared to IPv6 traffic (see graph below). The reason that these traffic graphs look different is that end-users likely have IPv6 Internet connectivity on their mobile devices and at their home broadband Internet link, but they use an IPv4-only network during the day at work. Even though most ISPs have IPv6 connectivity ready for enterprises and many content providers are enabling IPv6, corporate enterprises do not have IPv6 deployed to their internal users. Because IPv6 can perform better than IPv4 in some cases (see Part 1, Part 2), organizations will want to provide their end-users IPv6 Internet access sooner rather than later in their deployment schedule.
As an organization starts to bring IPv6 internally from their Internet DMZ, they advance IPv6 one layer-3 hop at a time inward to maintain IPv6 contiguity. Initially this starts by enabling IPv6 on the inside of their firewalls and then proceeding to IPv6-enable the core network. Eventually, the enterprise will have to implement IPv6 across the WAN and to the wired and wireless remote office access networks. This is what the IETF RFC 7381 refers to as the “Internal Phase.” The following picture shows an organization that has received Provider Independent (PI) global unicast IPv6 addresses and advertises this /36 prefix using BGP to multiple upstream ISPs. The enterprise uses this global IPv6 addresses (2AAA:BBBB:C000::/36) for all its DMZs and internal systems. Eventually, enterprises will IPv6-enable their end-users at their offices. That would mean deploying IPv6 across the corporate MPLS WAN. The same IPv6 prefix is used for corporate headquarters sites and branch offices.
Software-Defined WAN
Over the past few years, the networking industry has seen innovation taking place in the WAN and enterprises are exploring the potential cost savings of using a hybrid-WAN architecture. Enterprises that have maintained MPLS WANs for decades have found them to be expensive, inflexible, limited in their ability to provide management visibility, and suffering from vendor lock-in. Enterprises have been exploring how they can use Direct Internet Access (DIA) to augment their bandwidth and reduce installation times for new offices. Over the last decade, the cost of broadband Internet has fallen while the reliability has simultaneously increased to the point where it is suitable for most businesses. If enterprises use broadband Internet connectivity as another WAN connection to their branch offices, then they need solutions to help make the WAN secure, control application traffic flows over the diverse links, and manage and streamline the deployment. These advanced software features and tunnel overlays added to hybrid-WAN features have led to the coining of the term Software-Defined WAN. There are many reasons why an enterprise would want to use an SD-WAN system like this. You can read Gartner’s “Market Guide for Software-Defined WAN” to get an overview of the benefits of an SD-WAN and the major vendors offering SD-WAN connectivity devices and services.
When an organization deploys SD-WAN, more often than not, Direct Internet Access (DIA) is involved. That typically means that the enterprise has purchased a business class of broadband Internet service (maybe for a larger office), or they purchased a residential subscriber class of broadband Internet connectivity (maybe for a small office, home office, or retail store). When a hybrid-WAN is deployed, as seen in the picture below, the branch will be connected both to the traditional corporate WAN and to the Internet. When it comes to addressing the branch, the organization will not want to have to re-address the network and systems in the branch to move to this new architecture. The enterprise will likely continue to use private IPv4 in the branch office, but lack of NAT66 will require the branch to use global IPv6 in the office. In the hybrid model, the IPv4 traffic from the branch could use the branch router’s routing tables to either forward the traffic across the WAN to the headquarters or through a NAT to the broadband ISP. However, the IPv6 traffic from the branch can only traverse the WAN to the headquarters to reach the Internet.
SD-WAN and IPv6 Addressing
Now that we can visualize how SD-WAN might change an enterprise’s IPv6 addressing plan, we should consider the possibilities and consider alternatives. Enterprises will not want to change the addressing at the branch office and we know that user’s devices will have both IPv4 and IPv6 addresses as well as a desire for dual-protocol Internet connectivity. In the diagram below, the scenario where the branch only has Direct Internet Access (DIA) changes things slightly. With IPv4, the branch continues to use NAT when traffic goes to the Internet. There may well be a secure tunnel overlay across the Internet to join the branch to the headquarters location. With IPv4, the branch can continue to use internal addresses that follow the internal private IPv4 address plan. The IPv6 address space allocated by their RIR that is used at the corporate headquarters will be their global IPv6 address block.
When these broadband Internet connections are used for the branch office, there isn’t any EBGP used to advertise the IPv6 address that the enterprise site may be using. Instead, these DIA connections imply that it is a small site and the IPv6 addresses for the site will come from the Provider Assigned (PA) block of IPv6 addresses that “belongs” to the ISP. The problem here is that this creates a vendor lock-in situation when the branch uses PA IPv6 address space from the ISP. Since there isn’t any NAT66 specification (not to mention a general recommendation to avoid it), the branch will not be able to use their corporate global IPv6 address space internally to NAT those IPv6 addresses to the broadband ISP’s IPv6 address space. And most if not all organizations would want to avoid IPv6 re-addressing. As mentioned before, the enterprise could still use the corporate global IPv6 address for the inside of the branch site along with a tunnel that traverses the Internet back to HQ. The branch nodes could reach the IPv6 Internet through the headquarters over the backhauled tunnel overlay, but the IPv6-enabled nodes at the branch would lack direct IPv6 Internet connectivity.
One solution might be to use IPv6 Unique Local Addresses (ULA) (RFC 4193) and perform NPTv6 (RFC 6296) to avoid vendor lock-in. However, as Tom Coffeen of Infoblox has taught us, there are multiple ways to ruin our future networks using IPv6 ULA (see Part 1, Part 2). IPv6 expert Ed Horley has also compared the use of ULA and NPTv6 with IPv6 Global Unicast Addresses (GUA). Even though, historically, perimeter security products offered limited availability of NPTv6 features, more firewalls are starting to include NPTv6 as a standard feature.
Furthermore, an enterprise may have two different ISPs at the branch office to add redundancy. In this situation, the branch will have multiple /48s of PA IPv6 addresses. Enterprises would then be faced with the decision as to whether they want the internal branch office nodes to have two IPv6 addresses; i.e., one from each /48 of PA IPv6 address space. IPv6 nodes can have multiple IPv6 addresses, but they will use the IPv6 address associated with the default route to source packets (RFC 6724). During a fail-over event, the nodes simply change to using the default gateway of the available ISP connection.
One possibility would be to address the branch with the global IPv6 address space the enterprise was allocated and to disaggregate a /48 for that “site” then ask the broadband ISP to re-advertise that site’s /48 into the Internet routing tables. If an enterprise has purchased a business-class service and not a residential-class of service, the ISP may be willing to do this. However, you want to avoid completely disaggregating your IPv6 /36 of PI address space into /48s for all of your branches.
IPv6 Support in SD-WAN
As we have said before “If you are making a new product or service, it should be dual-protocol from the start.” Unfortunately, we do see new products launched in 2016 with IPv4-only connectivity. While, we prefer products have “functional parity” between their IPv4 and IPv6 capabilities, we may not always get what we want from a vendor. Along these lines, there may be a serious problem if an enterprise has already purchased an SD-WAN device and the manufacturer does not support IPv6. Soon, when the enterprise attempts to deploy IPv6 to the end-users at their branch offices, they will be unable to do so. Following is some information about SD-WAN vendors and their support of IPv6.
Cisco offers their Intelligent WAN (IWAN) hybrid-WAN solution. IWAN uses DMVPN for the secure tunnel overlay and DMVPN works over IPv4 or IPv6, and IWAN leverages Performance Routing v3 (PfRv3) for intelligent path control, but unfortunately PfRv3 does not support IPv6.
Citrix Cloudbridge claims that in version 7.3 and in version 7.4 that they support WAN optimization for IPv4 and IPv6.
Riverbed’s SteelConnect does have some IPv6 capabilities. Their documentation indicates that you can configure a SteelConnect Gateway to send an IPv6 RA. The SteelConnect Manager User Guide (version 1.20) also shows several other IPv6 configuration options. Riverbed acquired Ocedo, which offers a SD-WAN system that has cloud management and control. Their product datasheets lists that IPv6 is one of their features and their documentation lists layer(3) functionality with IPv6.
There are many other SD-WAN vendors in the market and asking them what their current and roadmap support plan for IPv6 should be part of your due diligence. Remember, as IPv6 becomes increasingly important, having true feature parity in a SD-WAN solution will become a deciding factor for which vendor solution you select.
Conclusions
As your enterprise embarks on its IPv6 deployment, you will obtain your IPv6 addresses from your RIR and start to create a corporate-wide IPv6 addressing plan. As an enterprise, you will want to use Provider-Independent (PI) global IPv6 addresses to prevent vendor lock-in. As your enterprise also moves forward with a hybrid-WAN deployment model, you should consider how this might change your IPv6 addressing plan. You will want to prevent vendor lock-in from using Provider-Assigned (PA) IPv6 address space for your branches, but as you disconnect branches from the private MPLS WAN you might not have a choice. Depending on the nature of your organizations, you may prefer one of these scenarios.
If your organization is a large enterprise and you use business-class direct Internet for your large branches, then you would prefer to use your RIR-allocated IPv6 addresses for all your sites and have the ISPs route the individual /48s to your sites.
If your organization has Internet-edge devices at the branch sites that have NPTv6 capabilities, then you can use your own RIR-allocated IPv6 addresses for each branch.
In both of the above cases, you could use your own RIR-allocated IPv6 addresses for your VPN tunnel overlay networks and for site-to-site communications as well as Internet communications.
If your organization has very small branches, then using the PA IPv6 addresses from the ISP connecting your branches may be acceptable. Re-addressing a small office when switching providers may not be a significant burden.
Over time, your organization may transition from a private WAN to a hybrid-WAN to a fully Internet-based WAN. Regardless of your design choices based on your requirements and constraints, you should have plenty of IPv6 addresses to change your design as your WAN continues to evolve over the coming decades. Use of global IPv6 addresses will help you overcome the challenges of NAT and allow for improved end-user Internet experience.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/t5/IPv6-Center-of-Excellence/Could-SD-WAN-Change-IPv6-Adoption-in-Enterprises/ba-p/7294
Scott Hogg is the Chief Technical Officer (CTO) for GTRI.
