Back to Blog
NetworkingDevOpsInfrastructureCloud ArchitectureCIDRBackend

Demystifying Subnetting, CIDR Notation, and IP Addressing: An Engineering Guide

Written by Dev Toolkit Editorial
•
July 2, 2026
•11 MIN READ

Master IPv4 and IPv6 addressing, CIDR bitmask calculations, subnet allocation, and cloud network architecture. Learn how to design VPCs, Docker networks, and Kubernetes pod CIDRs.

Whether you are configuring cloud infrastructure in Amazon Web Services (AWS) or Google Cloud Platform (GCP), setting up Docker container bridges, defining Kubernetes Pod CIDR ranges, or auditing firewall rule sets, IP addressing and subnetting form the foundation of network communication.

Despite being a fundamental concept in software engineering, subnet calculations and Classless Inter-Domain Routing (CIDR) notation are often treated as opaque magic. Developers frequently rely on online calculators without fully understanding how bitmasks determine network boundaries, broadcast addresses, and host capacities.

In this guide, we will break down the mathematical principles of IPv4 bitmasking, CIDR prefix manipulation, subnet splitting, private IP allocations (RFC 1918), and modern cloud/container network topology.

1. Anatomy of an IPv4 Address: Binary & Decimal Representation

An IPv4 address is a 32-bit numerical identifier assigned to a network interface. To make these 32 bits readable by humans, they are formatted as dotted-decimal notation: four 8-bit integers (octets) separated by periods.

Each octet represents an 8-bit unsigned integer ranging from 0 to 255 ((2^8 - 1)):

$$\text{IPv4 Address} = \text{Octet}_1 . \text{Octet}_2 . \text{Octet}_3 . \text{Octet}_4$$

Converting Dotted-Decimal to Binary

Consider the standard private IP address 192.168.1.100. Converting each octet into its 8-bit binary representation reveals the underlying 32-bit sequence:

  • 192 = 11000000
  • 168 = 10101000
  • 1 = 00000001
  • 100 = 01100100

In binary, 192.168.1.100 is represented as:

$$\mathtt{11000000.10101000.00000001.01100100}$$

Every network packet routed across the internet or a local area network (LAN) relies on routers evaluating these raw binary sequences. An IP address by itself, however, is incomplete—a router cannot determine where the network prefix ends and where the specific host portion begins without a subnet mask.

2. Subnet Masks & CIDR Notation

A modern CIDR subnet mask consists of a 32-bit sequence of contiguous 1s followed by contiguous 0s (distinguishing it from historical non-contiguous masks). The 1s designate the network prefix (the network portion), while the 0s designate the host portion (the specific device address on that network).

Traditional Subnet Mask vs. CIDR Slash Notation

Historically, IP addresses were split into rigid classes (Class A, B, and C). Introduced in 1993 via RFC 1519 and currently specified by RFC 4632, Classless Inter-Domain Routing (CIDR) replaced classful routing to eliminate address waste and enable route aggregation (supernetting), significantly reducing the growth and size of global Internet routing tables.

Under CIDR, a network prefix is specified by appending a slash (/) followed by the prefix length (b) (the number of contiguous 1 bits in the subnet mask).

IPv4 CIDR Decomposition

Common CIDR Prefixes and Corresponding Subnet Masks

CIDR Prefix Subnet Mask Binary Mask (Octet 4 / Bit Boundary) Total IP Addresses Usable Host Capacity
/32 255.255.255.255 11111111 1 1 (Single Host Route)
/31 255.255.255.254 11111110 2 2 (Point-to-Point Links, RFC 3021)
/30 255.255.255.252 11111100 4 2 (Traditional Point-to-Point)
/28 255.255.255.240 11110000 16 14
/27 255.255.255.224 11100000 32 30
/26 255.255.255.192 11000000 64 62
/24 255.255.255.0 00000000 256 254
/20 255.255.240.0 00000000 (Octet 3 boundary) 4,096 4,094
/16 255.255.0.0 00000000 (Octet 2 boundary) 65,536 65,534

3. Mathematical Principles of Subnet Calculations

When given an IP address and a CIDR prefix (e.g., 10.0.4.150/22), four primary parameters must be calculated:

  1. Subnet Mask
  2. Network Address (all host bits = 0)
  3. Broadcast Address (all host bits = 1)
  4. Usable Host Range & Host Capacity

Calculating Host Capacity

Given a CIDR prefix length (b), the number of host bits (h) remaining in the 32-bit IPv4 address is:

$$h = 32 - b$$

The total number of IP addresses contained within the subnet is:

$$N_{\text{total}} = 2^{32 - b}$$

In traditional IPv4 LANs, two addresses within any subnet are reserved for protocol mechanics:

  • Network Address: All host bits set to 0 (identifies the network portion itself).
  • Broadcast Address: All host bits set to 1 (targets all hosts on the subnet). Note: AWS VPC networking does not support IPv4 broadcast traffic.

Therefore, in traditional IPv4 networks, the usable host capacity (H_{\text{usable}}) is calculated as:

$$H_{\text{usable}} = 2^{32 - b} - 2$$

Important exceptions include /31 subnets (RFC 3021), where both IP addresses are usable on point-to-point links without network/broadcast address overhead, and /32 host routes.

Cloud VPC Exception: In AWS VPCs, AWS reserves 5 IP addresses per subnet: the network address (base address), the VPC router (base address + 1), the Amazon-provided DNS server (base address + 2), one address reserved for future provider use (base address + 3), and the final address in the subnet. Because AWS VPCs do not support IPv4 broadcast traffic, the final address is reserved by the platform rather than functioning as a broadcast address, reducing usable capacity to (2^{32 - b} - 5).

Step-by-Step Subnet Calculation Example: 10.0.4.150/22

Let’s solve 10.0.4.150/22 mathematically:

Step 1: Determine Network and Host Bits

  • Prefix length (b = 22).
  • Host bits (h = 32 - 22 = 10) bits.
  • Total IP addresses = (2^{10} = 1024).
  • Usable host addresses (traditional LAN) = (1024 - 2 = 1022).

Step 2: Determine Subnet Mask

22 network bits translates to 8 bits in octet 1, 8 bits in octet 2, and 6 bits in octet 3:

  • Octet 1: 11111111 = 255
  • Octet 2: 11111111 = 255
  • Octet 3: 11111100 = 252 (Sum: (128 + 64 + 32 + 16 + 8 + 4 = 252))
  • Octet 4: 00000000 = 0

Subnet Mask: 255.255.252.0

Step 3: Calculate Network Address via Bitwise AND

Bitwise AND the IP address with the Subnet Mask:

  • IP Octet 3: 4 = 00000100
  • Mask Octet 3: 252 = 11111100
  • 00000100 AND 11111100 = 00000100 (Decimal 4)

Network Address: 10.0.4.0

Step 4: Calculate Broadcast Address via Bitwise OR with Inverted Mask (Wildcard Mask)

Invert the subnet mask (Bitwise NOT) to produce the wildcard mask: 0.0.3.255. Bitwise OR the wildcard mask with the Network Address:

  • Octet 3: 4 OR 3 = 00000100 OR 00000011 = 00000111 (Decimal 7)
  • Octet 4: 0 OR 255 = 255

Broadcast Address: 10.0.7.255

Summary for 10.0.4.150/22:

  • Network Prefix: 10.0.4.0/22
  • Subnet Mask: 255.255.252.0
  • First Usable Host: 10.0.4.1
  • Last Usable Host: 10.0.7.254
  • Broadcast Address: 10.0.7.255
  • Total Usable Hosts: 1022 (LAN) / 1019 (AWS VPC)

4. Private Address Space (RFC 1918) vs. Public Routing

Not all IPv4 addresses are routable over the public internet. To prevent the premature exhaustion of the IPv4 address space, RFC 1918 allocated three specific address blocks for private local area networks (LANs) and enterprise environments:

CIDR Prefix Address Range Subnet Mask Total IP Count Primary Use Case
/8 Private Block 10.0.0.0 – 10.255.255.255 255.0.0.0 16,777,216 Large Cloud VPCs, Enterprise Data Centers
/12 Private Block 172.16.0.0 – 172.31.255.255 255.240.0.0 1,048,576 Container network bridges, VPNs
/16 Private Block 192.168.0.0 – 192.168.255.255 255.255.0.0 65,536 Home networks, small office routers

Carrier-Grade NAT & Loopback Addresses

In addition to RFC 1918, other notable reserved ranges include:

  • 127.0.0.0/8: Loopback addresses (e.g., 127.0.0.1 / localhost).
  • 100.64.0.0/10: Carrier-Grade NAT (CGNAT) (RFC 6598) primarily used by ISPs to share public IPv4 addresses, and also utilized by overlay networking systems such as Tailscale.
  • 169.254.0.0/16: Link-Local addresses (RFC 3927). In cloud environments, providers commonly assign instance metadata endpoints within this link-local range (such as 169.254.169.254).

5. Practical Application: Cloud VPCs and Container Networking

In modern cloud-native software development, engineers design network topology when setting up Virtual Private Clouds (VPCs), Kubernetes clusters, and container engines.

VPC Network Subdivision and Routing Architecture

Designing a Production VPC Subnet Layout

Suppose an application requires a production VPC with a top-level block of 10.0.0.0/16 (65,536 IP addresses). Rather than placing all services in a flat network, the space is divided into logical subnets across multiple Availability Zones (AZs) to enforce network isolation and security perimeters:

  1. Public Web Subnets (10.0.1.0/24, 10.0.2.0/24):

    • Holds Internet-facing Load Balancers (ALB) and Ingress Proxies.
    • Associated with a Route Table pointing 0.0.0.0/0 to an Internet Gateway (IGW).

  2. Private Application Subnets (10.0.10.0/24, 10.0.20.0/24):

    • Holds backend microservices, API servers, and worker nodes.
    • Outbound internet access is routed strictly through a NAT Gateway located in a public subnet.
    • For additional guidelines on securing network boundaries, see our guide on Zero Trust Network Perimeter Architecture.

  3. Isolated Database Subnets (10.0.100.0/24, 10.0.200.0/24):

    • Holds managed databases (AWS RDS, Cloud SQL) and Redis caches.
    • No route to the internet (0.0.0.0/0) exists in the route table. Communication is limited exclusively to private application subnets via security groups.

Container Networking: Docker & Kubernetes Pod CIDRs

When running containerized workloads:

  • Docker Default Bridge: Docker commonly defaults to a 172.17.0.0/16 bridge network, although the bridge subnet is fully configurable and may differ based on daemon configuration.
  • Kubernetes Cluster CIDR: Kubernetes assigns a large CIDR block (e.g., 10.244.0.0/16) to the Container Network Interface (CNI) plugin (such as Calico, Cilium, or Flannel). A per-node allocation (such as a /24 subnet providing 256 IPs) is a common configuration, though the exact prefix size depends on the CNI plugin and cluster setup.

6. IPv6 Addressing Fundamentals

While IPv4 uses 32 bits yielding ~4.3 billion addresses, IPv6 uses 128 bits, providing approximately (3.4 \times 10^{38}) unique addresses (enough to assign billions of IPs to every grain of sand on Earth).

IPv6 Format Rules

An IPv6 address is formatted as eight groups of four hexadecimal digits separated by colons:

$$\mathtt{2001:0db8:85a3:0000:0000:8a2e:0370:7334}$$

To simplify readability, two shortening rules apply:

  1. Leading Zero Suppression: Omit leading zeros within any 16-bit block (0000 becomes 0, 0db8 becomes db8).
  2. Zero Compression (::): Replace a contiguous sequence of zero blocks with a double colon :: (can only be used once per address to avoid ambiguity).

Applying these rules shortens the example address to:

$$\mathtt{2001:db8:85a3::8a2e:370:7334}$$

IPv6 Subnetting Practice

In IPv6, subnetting is structured and streamlined compared to IPv4. Allocation sizes vary by context: enterprise networks commonly receive a /48 prefix, while ISPs and cloud providers may allocate a /56, /60, or /48 block depending on the environment:

  • Global Routing Prefix: Assigned by an ISP, enterprise network, or cloud provider, with allocations ultimately delegated through Regional Internet Registries (RIRs).
  • Subnet ID: Used by the network administrator to construct subnet boundaries (e.g., 16 bits in a /48 allocation for (2^{16} = 65,536) subnets).
  • Interface Identifier (64 bits): Uniquely identifies an interface on the subnet (replacing the IPv4 host portion).

Because IPv6 subnets almost universally use a /64 prefix, engineers rarely need to perform host-capacity calculations or handle non-octet bitmask arithmetic.

7. Troubleshooting & Engineering Best Practices

  1. Avoid Overlapping CIDR Blocks: When peering VPCs or connecting cloud infrastructure to on-premises data centers via VPN/DirectConnect, ensure CIDR blocks never overlap. Peering 10.0.0.0/16 with another 10.0.0.0/16 network will cause routing collisions.
  2. Leave Expansion Space: Do not allocate all available CIDR space on day one. If your cloud VPC uses 10.0.0.0/16, start by allocating small /24 or /22 subnets, leaving unassigned blocks available for future regions, container clusters, or database shards.
  3. Use Least Privilege Firewall Rules: In security groups and Network Access Control Lists (NACLs), avoid opening ingress to 0.0.0.0/0 unless required for public endpoints. Restrict administrative services (e.g., SSH/RDP or database ports) to specific internal CIDR ranges (e.g., 10.0.10.0/24). For further details on production API gateways and routing, refer to our article on Production Grade API Practices.

Summary Decision Matrix

Requirement Recommended CIDR / Strategy Key Consideration
Large Cloud VPC 10.0.0.0/16 Provides 65,536 IPs; easily split into dozens of /24 subnets across Availability Zones.
Standard Subnet /24 (255.255.255.0) Provides 254 usable host IPs; aligns cleanly with the 4th octet for simple management.
Point-to-Point Link /30 or /31 /30 provides 2 usable IPs; RFC 3021 allows /31 (2 IPs) on point-to-point links to save space.
Kubernetes Pod CIDR /16 overall (per-node allocation varies) /24 per node is a common allocation, though exact prefix size depends on the CNI plugin and cluster setup.