Convert IP range to CIDR: why it takes multiple blocks
When you need to express an arbitrary IP range as CIDR blocks, the intuitive assumption is that one prefix will cover it. In practice, a single contiguous range almost never aligns perfectly with a single CIDR boundary. Understanding why, and how to decompose a range into the minimal set of valid CIDR blocks, is a core skill for network planning, route aggregation, and firewall rule configuration.
Why CIDR blocks have boundaries
CIDR notation divides an address space by powers of two. A /24 block contains 256 addresses; a /25 contains 128; a /26 contains 64. Each valid CIDR block must start at an address whose binary representation aligns with its prefix length. For example, 192.168.0.0/24 is valid because 192.168.0.0 in binary ends with 8 zero bits (matching the /24). But 192.168.0.50/24 is not a valid CIDR block--the host bits are non-zero.
This mathematical constraint means that arbitrary ranges like 10.0.5.0 to 10.0.10.255 do not map to a single CIDR prefix. The start address may not align, the end address may not align, or both. The solution is to decompose the range into a set of standard CIDR blocks that together cover the entire span without overlap or gaps.
The decomposition algorithm
The standard approach is a greedy algorithm: starting from the lowest address in the range, find the largest CIDR block that fits within the remaining range, add it to your list, and repeat until the entire range is covered.
Example: convert 192.168.1.0 to 192.168.1.127 Start: 192.168.1.0 End: 192.168.1.127 (128 addresses) Largest block starting at 192.168.1.0 that fits: 192.168.1.0/25 (covers 192.168.1.0 to 192.168.1.127) Result: 1 block (192.168.1.0/25) --- Example: convert 192.168.0.0 to 192.168.1.255 Start: 192.168.0.0 End: 192.168.1.255 (512 addresses) Largest block starting at 192.168.0.0: 192.168.0.0/23 (512 addresses) Covers exactly the range. Result: 1 block (192.168.0.0/23) --- Example: convert 10.0.0.50 to 10.0.0.100 Start: 10.0.0.50 End: 10.0.0.100 (51 addresses) Largest block at 10.0.0.50: 10.0.0.64/26 (64 addresses, but starts at .64) Instead: 10.0.0.50/31 covers .50-.51 Then: 10.0.0.52/30 covers .52-.55 Then: 10.0.0.56/29 covers .56-.63 Then: 10.0.0.64/26 covers .64-.127 (but we stop at .100) Then: 10.0.0.64/27 covers .64-.95 Then: 10.0.0.96/29 covers .96-.103 (but we stop at .100) Then: 10.0.0.96/30 covers .96-.99 Then: 10.0.0.100/32 covers .100 Result: 8 blocks (highly fragmented)
The number of blocks required depends entirely on the alignment of the start and end addresses within the binary structure of the address space. Ranges that begin and end on power-of-two boundaries decompose cleanly. Ranges that start or end mid-block require many small fragments.
Real-world impact
- →Firewall ACLs: a single range rule may require 5-10 individual CIDR permit statements, increasing rule count and maintenance burden.
- →BGP route aggregation: an ISP allocating addresses to a customer may need to advertise multiple prefixes instead of one summary route.
- →IP address management (IPAM) tools: must track and optimize block allocation to minimize fragmentation.
- →Terraform and infrastructure-as-code: network definitions can become verbose if ranges are not pre-calculated into efficient CIDR sets.
Practical example: ISP allocation
An ISP customer requests a /22 (1024 addresses). The ISP's available pool is 203.0.113.0 to 203.0.113.255 (256 addresses) plus 203.0.114.0 to 203.0.114.255 (another 256 addresses). The customer's range spans both blocks. The ISP must allocate 203.0.113.0/24 and 203.0.114.0/24 separately--two /24 blocks instead of one /22. The customer's BGP session must advertise both prefixes, and any downstream firewall rules must reference both blocks.
This is why network engineers plan address allocation carefully, aligning boundaries to future growth and minimizing the need for range-to-CIDR decomposition in production.