TL&DR: MIA

Six years ago, when I was talking about overlay virtual networks at Interop, I loved to joke that we must be living on a weird planet where Microsoft has the best overlay virtual networking implementation… at least as far as IPv6 goes.

Even then, their data plane implementation which was fully dual-stack-aware on both tenant- and underlay level was way ahead of what System Center could do. If I remember correctly (and I’m positive @ehorley will be quick to correct me), you could configure either IPv4 or IPv6 but not dual-stack tenant networks.

Fast-forward six years. After completing the AWS Networking webinar, I started preparing the materials for my Microsoft Azure Networking workshop, expecting at least a parity with AWS as far as IPv6 goes. As my Twitter followers might have noticed I was bitterly disappointed. The only IPv6 functionality available in Azure is:

• Private IPv6 addresses on VM NICs;
• Public IPv6 addresses on outside interfaces of load balancers;
• Load balancing of incoming IPv6 traffic.

Virtual machines can’t even communicate over IPv6, and needless to say there are no subnets, user-defined routes, network security groups… The state of IPv6 in Azure is best summarized by this “key benefit” from their documentation:

Meet government regulations requiring that new applications be accessible to IPv6-only clients

To rephrase: we have IPv6 so you can have a tick in the box.

Compare that to AWS that has full feature parity between IPv4 and IPv6 in:

• Virtual networks;
• Security groups;
• Routing;
• Internet access;
• Load balancers.

As far as I’d love to see a public infrastructure cloud market with many strong players, it seems we have a replica of networking hardware market, this time called AWS and seven dwarfs.

Want to know more about networking in Microsoft Azure? The slide deck is ready and available to ipSpace.net subscribers. I’ll run a workshop using this material in Zurich (Switzerland) on June 12th, and a webinar sometime in autumn 2019.