Azure VNets and 172.16.0.0/12

Why is the RFC1918 private network range missing from the System RouteTable?

I've recently been digging into the weeds of doing an Azure VNet Hub and Spoke design for a customer and it's brought about revisiting a topic from a while back.

For some quick context- for any given VNet in Azure there is a System RouteTable that holds basic routing information for that VNets network traffic flows within that VNet as well as inbound and outbound of the VNet. The following table outlines what the default System RouteTable routes consist of (table information source):

So, whats the problem with that?

Well, wheres 172.16.0.0/12 and why hasn't Microsoft included that range in the default VNet System RouteTable? I want answers!

Most organisations use the RFC1918 range of 10.0.0.0/8 or smaller for their address space on their entire network. You'd got an entire /8 block containing up to 16,777,216 possible IP addresses so plenty to go round (though I've even seen that assigned to single VNets, even though a max CIDR range for a VNet is /16). Smaller organisations or home networks commonly use the 192.168.0.0/16 network range with again plenty of room with lots of 16 addresses.

More uncommon is the carrier-grade NAT private network range (RFC6598) that Microsoft lists with the range 100.64.0.0/10.

I have two theories why it's not been included.

  1. Either Microsoft uses this range for internal infrastructure or
  2. No one at likes 172.16.0.0/12 and theres a vendetta against the private range

Either way, I think some Comunicado Oficial should be made to address this serious and urgent matter. Maybe you dear reader could get involved? Check out the GitHub issue on this very matter and request answers!


Microsoft Azure Azure Networking RouteTable VNet

Discussion 💬

Follow or start a discussion for this blog (Azure VNets and 172.16.0.0/12) on Twitter. If you're after something more in depth, or want to ask me an expanded question: raise an issue in my open GitHub AMA repo.