Planning Vnet IP address spaces

Every Vnet must have at least one IP address space assignment. A Vnet space assignment can either be single-stack (IPv4 address space only) or dual-stack (IPv4 and IPv6 address spaces). At the time of writing, an IPv6-only Vnet is not supported! You might be able to create an IPv6-only Vnet in the portal, but you will not be able to attach a virtual network interface card (NIC) to it. Attempting it will result in the error message shown in Figure 1.5:

Figure 1.5 – Your Vnet must have at least one IPv4 address space to use IPv6

Note

Azure does not yet support an IPv6-only Vnet and subnet, but you can implement dual-stack Vnets and subnets that support both IPv4 and IPv6.

Azure VNet is not limited to one IP address space assignment. We can add more IP address spaces as needed, which is great for scalability! For example, we may want to add an additional IPv4 address space to support an unexpected workload expansion.

Limitation

Regardless of how many addresses are contained in the IP address spaces assigned to a Vnet, the total number of private IP addresses assigned to workloads cannot exceed 65,536.

The IP address spaces assigned to a Vnet do not have to be contiguous. Figure 1.6 shows an example of this with a Vnet that is configured to have two IPv4 address spaces that are not contiguous – 10.1.0.0/16 and 192.168.1.0/24 and an additional IPv6 address space for a dual-stack implementation – fd00:db8:deca::/48.

Figure 1.6 – A Vnet with multiple address spaces

So, which IP address spaces should we use for our Vnets in Azure? Even though it is not required, it is highly recommended to use address ranges within the private, non-internet routable address spaces! For IPv4, this will be one of the IP ranges defined in RFC 1918 and for IPv6, this will be the Internet Engineering Task Force (IETF) defined Unique Local Addresses, which use the fc00::/7 address range.

RFC 1918 private IPv4 address ranges

Private IP address ranges defined in RFC 1918 are IP ranges that have been set aside by the IETF for private network use. They include the following:

•10.0.0.0/8 (10.0.0.0 – 10.255.255.255)

•172.16.0.0/12 (172.16.0.0 – 172.31.255.255)

•192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

Using any of the RFC 1918 private IP address ranges will require some form of address translation for internet routing and connectivity (we will cover this scenario later in this book).

Shared IPv4 address spaces reserved in RFC 6598 can also be used as they are treated as private IP address spaces in Azure. This range includes the following:

• 100.64/10 (100.64.0.0 – 100.127.255.255)

Other IP address spaces may work but they are not recommended as they could have undesirable routing side effects with instability! The following address ranges are not allowed to be used as Vnet IP address spaces:

• 224.0.0.0/4 (Multicast)
• 255.255.255.255/32 (Broadcast)
• 127.0.0.0/8 (Loopback)
• 169.254.0.0/16 (Link-local)
• 168.63.129.16/32 (Internal DNS)

Whatever IP address ranges you decide to use for your Vnets, it is highly recommended to plan for non-overlapping IP address spaces across Azure regions and on-premises locations in advance. You can achieve this by defining an organization-wide IP address scheme that ensures that each network has its own unique private IP address space if it is an Azure network or an on-premises network.

Best practice

Define an organization-wide IP address scheme that ensures that each organization network has its own unique private IP address space.

One of the reasons why this is important is that it can impact your ability to connect networks together later or leave you in a situation where you need to implement sub-optimal network address translations that add to the complexity.

For example, you cannot connect two Vnets together via Vnet peering if they have the same address space! Figure 1.7 shows the error message that you will get if you attempt this:

Figure 1.7 – Vnets with overlapping address spaces cannot be peered

If you don’t know what Vnet peering is, don’t worry, we will cover it later in this book when we look at hybrid connectivity. You could use a VPN gateway to connect two networks with the same IP address spaces but this requires implementing address translation, which can make troubleshooting traffic flow very complex!