IP Range to CIDR

What is Range to CIDR Conversion?

Range to CIDR conversion takes a start IP address and an end IP address and produces the minimal set of CIDR blocks that exactly cover every address in that range — no more, no less. This is the inverse operation of CIDR-to-range expansion: instead of going from 192.168.1.0/24 to a range of 256 addresses, you go from a range back to CIDR notation.

This conversion is essential because most network infrastructure — firewalls, routers, cloud security groups, and access control lists — operates on CIDR blocks, not arbitrary IP ranges. When a vendor provides an IP range (e.g., “our servers use 203.0.113.10 through 203.0.113.50”), you need to express that range as one or more CIDR blocks to configure your infrastructure.

If the range happens to align perfectly with a CIDR boundary (e.g., 192.168.1.0 through 192.168.1.255), the result is a single block. But in practice, arbitrary ranges rarely align cleanly, and the conversion produces multiple blocks of different sizes.

Why Non-Aligned Ranges Need Multiple CIDRs

CIDR blocks follow strict mathematical rules. A /n block must start at an address that is a multiple of 2^(32-n). For example, a /24 block (256 addresses) must start at an address where the last octet is 0 (like 192.168.1.0). A /25 block (128 addresses) must start at 0 or 128.

When a range starts at an address that is not a valid CIDR boundary, no single block can represent it. The algorithm must decompose the range into the largest possible aligned blocks, working from both ends toward the middle.

Consider the range 10.0.0.5 to 10.0.0.19 (15 addresses):

1. Start at 10.0.0.5: The largest aligned block starting at .5 is a /32 (single address). But .5 is odd, so we can only start with 10.0.0.5/32.
2. Next, 10.0.0.6: This address is aligned to a /31 (2 addresses), giving us 10.0.0.6/31 (covers .6 and .7).
3. Next, 10.0.0.8: This is aligned to a /29 (8 addresses), giving us 10.0.0.8/29 (covers .8 through .15).
4. Next, 10.0.0.16: A /30 would cover .16 through .19, giving us 10.0.0.16/30 (covers .16 through .19).

Result: 4 CIDR blocks instead of one. The algorithm always finds the minimum number of blocks, but non-aligned ranges inherently require more entries.

The Algorithm in Brief

The standard approach works as follows:

1. Convert both the start and end addresses to 32-bit integers
2. Find the largest power-of-two block that starts at the current address and does not exceed the end address
3. Record that CIDR block and advance the current address past it
4. Repeat until the entire range is covered

This greedy algorithm is guaranteed to produce the minimal set of CIDR blocks for any given range.

Practical Uses

Range-to-CIDR conversion appears in many real-world scenarios:

• Firewall configuration: When a third-party service publishes an IP range for whitelisting (e.g., “our webhook servers use 198.51.100.32 through 198.51.100.63”), you need CIDR blocks for your firewall rules. In this case, the range conveniently maps to 198.51.100.32/27.
• Cloud security groups: AWS Security Groups, Azure NSGs, and GCP Firewall Rules all require CIDR notation. If a vendor gives you a plain IP range, you must convert it before you can add the rule.
• IP geolocation databases: Regional Internet Registries (RIRs) publish IP allocations as ranges. Tools that consume this data often convert ranges to CIDR for efficient prefix matching using longest-prefix-match algorithms.
• BGP route optimization: Network engineers converting customer IP allocations from ranges to CIDR blocks for BGP advertisement. Fewer, larger blocks reduce the size of the global routing table.
• ACL auditing: When comparing two versions of an access control list, converting ranges to CIDR provides a normalized form that makes diffs meaningful and human-readable.
• Migration planning: When moving workloads between data centers or cloud providers, IP range-to-CIDR conversion helps plan the new address scheme and verify that no addresses overlap with existing allocations.

Understanding this conversion ensures that your network rules are both precise (covering exactly the addresses you intend) and efficient (using the fewest possible CIDR entries).