THE PRACTICAL GUIDE · NORMANDIN SYSTEMS
Get more from IPv4-6/IPRange/CIDR in IPRange/CIDR/IPMask
IPv4-6/IPRange/CIDR in IPRange/CIDR/IPMask: Given a CIDR/IP Range/Wildcard IP/IP Mask, tell if a given IPv4-6/Range/CIDR/Wildcard IP/IP Mask is in subnet range. Containment checks help validate whether an individual address or an entire range falls within an allowed parent block. IP calculations describe address space; they do not tell you whether a host is online or whether a firewall permits traffic. Prefix lengths divide an address into network and host portions, and a one-bit prefix change can substantially change the number of included addresses. Confirm whether you are working with IPv4 or IPv6 and use the same family throughout a calculation. For network planning, record both the human-readable notation and the exact boundaries. This helps catch accidental overlap, oversized allowlists, and assumptions about which addresses are usable.
Guide updated October 13, 2026
How to use this tool
- Begin with a representative input. For a practical test, use: Address 192.0.2.42 tested against 192.0.2.0/24. Replace demonstration values only after you understand the output.
- Enter the address, range, or prefix in the syntax requested by the tool, using the correct IPv4 or IPv6 address family.
- Inspect the network boundaries and the size of the resulting address space, especially when a calculation broadens or subdivides a range.
- Compare the result with neighboring subnets and your intended allocation before applying it to a router, firewall, or configuration file.
SEE IT IN PRACTICE
A worked example
Address 192.0.2.42 tested against 192.0.2.0/24
The address is inside the specified subnet
Use explicit start and end boundaries when investigating why two overlapping ranges are not fully contained.
Alignment determines how ranges become prefixes
CIDR blocks have power-of-two sizes and aligned starting boundaries. A range of the right size can still require multiple blocks if its start is not aligned. For example, a small interval inside a /24 does not automatically become one equally small prefix. Compare the resulting first and last addresses, not just the number of blocks shown.
Containment, overlap, and subtraction answer different questions
Containment asks whether all of one input lies inside another. Overlap asks whether they share any addresses. Subtraction removes an excluded set and can split one range into several remnants. These distinctions matter in firewall and allocation work: a partly overlapping range is not fully authorized by a containing policy. Keep original inputs with the calculation and check boundary addresses explicitly.
When this tool is useful
- Check an allowlist entry
- Validate subnet nesting
- Review address-range scope
Tips for a better result
- For a range input, confirm that the whole range is contained rather than assuming that overlap is sufficient.
- An address being mathematically inside a subnet does not prove that the address is assigned, reachable, or authorized for access.
- Keep prefix lengths visible in documentation; an address without its prefix is insufficient to describe a subnet allocation.
Frequently asked questions
What is the difference between an exact CIDR decomposition and a covering subnet?
An exact decomposition uses as many aligned blocks as necessary to represent only the requested addresses. A single covering subnet may be larger and include addresses outside the original range.
Why does the prefix length matter?
The prefix length controls how many bits identify the network. Increasing the prefix length makes the block smaller; decreasing it makes the block larger and can include addresses beyond your intended scope.
Can I paste the result directly into a firewall?
First verify the destination’s accepted syntax and the policy’s intended scope. A mathematically correct range can still grant too much access, overlap another rule, or behave differently because of rule ordering.
What happens to the information I enter?
The utility processes your input in this browser. Some tools retain field values in browser storage or the URL; avoid entering secrets in shareable fields. Page and asset requests still go to the hosting provider. Read the privacy and offline-use notes for details.