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.\u00a0 Paul Saab of Facebook gave a presentation at\u00a0NANOG64<\/a>\u00a0titled \u201cThe benefits of deploying IPv6 only<\/a>\u201c and on\u00a0slide 17 he showed a graph<\/a>\u00a0of daily IPv4 traffic compared to IPv6 traffic (see graph below).\u00a0 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 \u00a0work.\u00a0 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.\u00a0 Because IPv6 can perform better than IPv4 in some cases (see\u00a0Part 1<\/a>,\u00a0Part 2<\/a>), organizations will want to provide their end-users IPv6 Internet access sooner rather than later in their deployment schedule.<\/p>\n 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.\u00a0 Initially this starts by enabling IPv6 on the inside of their firewalls and then proceeding to IPv6-enable the core network.\u00a0 Eventually, the enterprise will have to implement IPv6 across the WAN and to the wired and wireless remote office access networks.\u00a0 This is what the IETF\u00a0RFC 7381<\/a>\u00a0refers to as the \u201cInternal Phase\u201d.\u00a0 The following picture shows an organization that has received Provider Independent (PI)\u00a0global unicast IPv6 addresses<\/a>\u00a0and advertises this \/36 prefix using\u00a0BGP<\/a>\u00a0to multiple upstream ISPs.\u00a0 The enterprise uses this global IPv6 addresses (2AAA:BBBB:C000::\/36) for all its DMZs and internal systems.\u00a0 Eventually, enterprises will IPv6-enable their end-users at their offices. That would mean deploying IPv6 across the corporate MPLS WAN.\u00a0 The same IPv6 prefix is used for corporate headquarters sites and branch offices.<\/p>\n 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.\u00a0 Enterprises that have maintained\u00a0MPLS WANs<\/a>\u00a0for decades have found them to be expensive, inflexible, limited in their ability to provide management visibility, and suffering from vendor lock-in.\u00a0 Enterprises have been exploring how they can use\u00a0Direct Internet Access<\/a>\u00a0(DIA) to augment their bandwidth and reduce installation times for new offices.\u00a0 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.\u00a0 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.\u00a0 These advanced software features and tunnel overlays added to hybrid-WAN features have led to the coining of the term\u00a0Software-Defined WAN<\/a>.\u00a0 There are\u00a0many reasons<\/a>\u00a0why an enterprise would want to use an SD-WAN system like this.\u00a0 You can read Gartner\u2019s \u201cMarket Guide for Software-Defined WAN<\/a>\u201d to get an overview of the benefits of an SD-WAN and the major vendors offering SD-WAN connectivity devices and services.<\/p>\n When an organization deploys SD-WAN, more often than not, Direct Internet Access (DIA) is involved.\u00a0 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).\u00a0 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.\u00a0 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.\u00a0 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.\u00a0 In the hybrid model, the IPv4 traffic from the branch, could use the branch router\u2019s routing tables to either forward the traffic across the WAN to the headquarters or through a NAT to the broadband ISP.\u00a0 However, the IPv6 traffic from the branch can only traverse the WAN to the headquarters to reach the Internet.<\/p>\n Now that we can visualize how SD-WAN might change an enterprise\u2019s IPv6 addressing plan, we should consider the possibilities and consider alternatives.\u00a0 Enterprises will not want to change the addressing at the branch office and we know that user\u2019s devices will have both IPv4 and IPv6 addresses as well as a desire for dual-protocol Internet connectivity.\u00a0 In the diagram below, the scenario where the branch only has Direct Internet Access (DIA) changes things slightly.\u00a0 With IPv4, the branch continues to use NAT when traffic goes to the Internet.\u00a0 There may well be a secure tunnel overlay across the Internet to join the branch to the headquarters location.\u00a0 With IPv4, the branch can continue to use internal addresses that follow the internal private IPv4 address plan.\u00a0 The IPv6 address space allocated by their RIR that is used at the corporate headquarters will be their global IPv6 address block.<\/p>\n <\/p>\n When these broadband Internet connections are used for the branch office, there isn\u2019t any\u00a0EBGP<\/a>\u00a0used to advertise the IPv6 address that the enterprise site may be using.\u00a0 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 \u201cbelongs\u201d to the ISP.\u00a0 The problem here is that this creates a vendor lock-in situation when the branch uses PA IPv6 address space from the ISP.\u00a0 Since there isn\u2019t 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\u2019s IPv6 address space.\u00a0 And most if not all organizations would want to\u00a0avoid IPv6 re-addressing<\/a>.\u00a0 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.\u00a0 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.<\/p>\n One solution might be to use IPv6 Unique Local Addresses (ULA) (RFC 4193<\/a>) and perform NPTv6 (RFC 6296<\/a>) to avoid vendor lock-in.\u00a0 However, as Tom Coffeen has taught us, there are multiple ways to ruin our future networks using IPv6 ULA (see\u00a0Part 1<\/a>,\u00a0Part 2<\/a>).\u00a0\u00a0Ed Horley has also compared the use of ULA<\/a>\u00a0and\u00a0NPTv6<\/a>\u00a0with IPv6 Global Unicast Addresses (GUA).\u00a0 Even though, historically, perimeter security products offered limited availability of NPTv6 features, more firewalls are starting to include NPTv6 as a standard feature.<\/p>\n Furthermore, an enterprise may have two different ISPs at the branch office to add redundancy.\u00a0 In this situation, the branch will have multiple \/48s of PA IPv6 addresses.\u00a0 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.\u00a0 IPv6 nodes can have multiple IPv6 addresses, but they will use the IPv6 address associated with the default route to source packets (RFC 6724<\/a>).\u00a0 During a fail-over event, the nodes simply change to using the default gateway of the available ISP connection.<\/p>\n 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 \u201csite\u201d then ask the broadband ISP to re-advertise that site\u2019s \/48 into the Internet routing tables.\u00a0 If an enterprise has purchased a business-class service and not a residential-class of service, the ISP may be willing to do this.\u00a0 However,\u00a0you want to avoid completely disaggregating<\/a>\u00a0your IPv6 \/36 of PI address space into \/48s for all of your branches.<\/p>\n As we have said before \u201cIf you are making a new product or service, it should be dual-protocol from the start<\/a>.\u201d\u00a0 Unfortunately, we do see new products launched in 2016 with IPv4-only connectivity.\u00a0 While, we prefer products have \u201cfunctional parity<\/a>\u201d between their IPv4 and IPv6 capabilities, we may not always get what we want from a vendor.\u00a0 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.\u00a0 Soon, when the enterprise attempts to deploy IPv6 to the end-users at their branch offices, they will be unable to do so.\u00a0 Following is some information about SD-WAN vendors and their support of IPv6.<\/p>\n 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. \u00a0Remember, 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.<\/p>\n As your enterprise embarks on its IPv6 deployment, you will obtain your IPv6 addresses from your RIR and start to create a\u00a0corporate-wide IPv6 addressing plan<\/a>.\u00a0 As an enterprise, you will want to use Provider-Independent (PI) global IPv6 addresses to prevent vendor lock-in.\u00a0 As your enterprise also moves forward with a hybrid-WAN deployment model, you should consider how this might change your IPv6 addressing plan.\u00a0 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.\u00a0 Depending on the nature of your organizations, you may prefer one of these scenarios.<\/p>\n<\/i><\/span><\/p>\n
<\/i><\/span><\/p>\n
Software-Defined WAN<\/h2>\n
<\/i><\/span><\/p>\n
SD-WAN and IPv6 Addressing<\/h2>\n
<\/i><\/span><\/p>\n
IPv6 Support in SD-WAN<\/h2>\n
\n
Conclusions<\/h2>\n