Ixia’s Michael Haugh discusses how SDN can enable the transition to IPv6.
I recently spoke at the Global IPv6 Summit and Next Generation Internet Summit in Beijing, China, hosted by the Beijing Internet Institute (BII) and the IPv6 Forum. My topic was that of using SDN to enable a transition to IPv6. Why? The adoption of IPv6 is happening faster in China than anywhere else in the world – driven by the lack of available public and private IPv4 addresses.
The motivation to use Software Defined Networking (SDN) technologies is high since it offers a common and open API to program the network, enabling new services and applications. SDN has the ability to accelerate application deployment and decrease the time-to-revenue for service providers.
Taking a deep dive into using OpenFlow® to enable IPv6, I looked at OpenFlow® version 1.0 and the more recent version implemented by vendors, version 1.3. OpenFlow® v1.0 is still attractive for some basic applications since it is fairly simple with support for a single logical table and support for a 12-tuple header match including input port, MAC, VLAN, IPv4, protocol source, and destination ports. One clear gap is that it does not define match/action for IPv6 header fields.
Looking at traditional mechanisms used to transition to IPv6 you have: tunneling, translation, and dual-stack as the most common choices. OpenFlow® v1.0, on the other hand, would provide three options:
- Use port based match/action. Assuming you know what ports IPv6 hosts or what devices are connected to you could match on that ingress port and then use an action to set the output port. In an overlay network this could be a tunnel interface. In an underlay network, you would need to provision the path across the network using specific ingress and egress ports across the network. While this is possible, it is not very attractive since you would need dedicated ports across the network. Another option is to modify the packet on the output port adding a VLAN tag, and then use the VLAN tag to get it across the network again modifying it at the egress to strip the VLAN header. Again this is a decent option, but the limitation of 4096 VLAN IDs presents scaling limitations. Both of these options would be considered tunneling solutions.
- Use OpenFlow® at Layer 2 and remain agnostic of Layer 3 (be it IPv4 or IPv6). In this case you can use MAC learning or provisioning of Layer 2 paths based on MAC or VLAN headers. You could also use the mechanisms described in the first option for an overlay (often using GRE or STT tunneling). This method is fairly common in the data center, but provides scalability challenges since you still have the VLAN tag limitation of 4096 and you have limitations of the MAC address tables the network devices are able to maintain.
- The final option is to run OpenFlow® in a hybrid mode, which means the device supports traditional routing or switching in addition to OpenFlow. In this case, you may be able to run native IPv6 while also running OpenFlow. This is similar to dual-stack where IPv4 and IPv6 are both run. While this may be a viable method, you lose the benefit of using SDN for IPv6 and create more operational challenges since the network is running multiple protocols and needs to maintain multiple tables.
Moving on to OpenFlow® v1.3 there are many changes in the specification with some of the biggest changes including the definition of using multiple tables and the ability to pipeline the packet from table to table. It also extends the match fields from 12 in v1.0 to 40 in v1.3 including the addition of MPLS, Provider Backbone Bridging (PBB), and IPv6. While these additions greatly expand the potential of OpenFlow® they also create challenges since many of the features are defined as optional and implementations of multi-table support vary greatly from vendor to vendor.
Using OpenFlow® v1.3 to enable the transition to IPv6 enables many options in addition to all of the options described for v1.0. However, since there is native support in the protocol for match/action on the IPv6 header the two main methods to consider are these:
- Dynamically learn the Layer 3 IPv6 hosts. This can be facilitated by supporting the IPv6 Neighbor Discovery Protocol (NDP) or supporting DHCPv6. In this case, there needs to be application support on the controller that pushes down a flow-table entry to each of the edge devices enabling the forwarding of these packets up to the controller or application to process. Consistent with IPv4, the control plane packets are handled by the controller or application. Once the controller or application has discovered the network topology and knows what hosts are trying to talk to each other the path through the network can be dynamically provisioned, or in some cases the operator prefers to pre-provision the paths through the network. In this underlay model, each of the devices would need to support the optional IPv6 features of OpenFlow® and support the required combinations of match/action on the IPv6 header. This also includes the ability to support masking of address fields. Often this is required to reduce the table entries on the hardware.
- Similar to option one, option two could support dynamic learning or pre-provisioning the required connectivity. The main difference in option two is to leverage the tunnel interface support and implement an overlay solution using match/action of IPv6 at the edge, but use a tunnel over an existing network. Tunneling is a common method used in the data center and with an OpenFlow® enabled vSwitch you can build IPv6 connectivity VM to VM. Another attractive option of tunneling is that you would not need to support OpenFlow® on every node of the network, which may take a while to deploy. An overlay enables faster deployment by just enabling OpenFlow® at the edges.
When we consider these mechanisms it is important to evaluate three key attributes:
- Conformance to standards based OpenFlow® – It is critical, especially in a multi-vendor network, that the implementation leverage standards-based support. Conformance testing is considered a fundamental verification step.
- Functional testing – ensuring that each device including all the network layer devices as well as the controller or application will support the desired functions and perform at the required level of service. As mentioned, many features in OpenFlow® v1.3 are optional, so verification is required. Some features may be supported using different forwarding paths. For example if the devices forward MAC and IPv4 traffic in hardware, but forward IPv6 in software, there will be a significant packet forwarding performance penalty and the result may not meet the desired service level
- Benchmark testing – Operators perform capacity planning and need to know the total capacity of the device. For OpenFlow® this includes: forwarding performance, flow-table capacity, redundancy and resiliency, and integrated control-plane or data-plane testing. Benchmarking of either of the network layer devices as well as the controller or application is critical to success.
After I presented on this topic it was exciting to see that just after me was a presenter from China Mobile who is now testing OpenFlow® for the transition to IPv6. I expect this to move from the lab to the network much faster than most people think. Enabling the transition to IPv6 may be one of the “killer apps” of SDN technologies.
- Michael Haugh, Product Marketing Director, Ixia
