CIDR / Subnet Calculator mechanism

Model scope

The core network and broadcast formulas are standard for valid IPv4 CIDR inputs, but the advertised feature set is underspecified and the host formula is not universally correct. The blank honest_label is a concern: the UI should disclose the host-count convention, /31 and /32 behavior, accepted mask format, and 32-bit arithmetic constraints.

• hosts=2^(32-prefix)-2 is valid only for conventional subnets with prefixes /0 through /30; it produces 0 for /31 and -1 for /32. The instrument must define RFC 3021 /31 behavior and /32 host behavior explicitly.
• The specification claims first and last usable host but provides no formulas or policy for deriving them. Conventional formulas are first_usable=network+1 and last_usable=broadcast-1, subject to /31 and /32 exceptions.
• The wildcard mask formula is omitted. It should be wildcard=255.255.255.255 XOR subnet_mask, or the 32-bit complement of the mask.
• The network and broadcast formulas are correct when IP and mask are valid 32-bit IPv4 values: network=IP AND mask and broadcast=network OR (NOT mask), with NOT restricted to 32 bits.
• There is no stated validation that a supplied subnet mask is contiguous or that a prefix is in the inclusive range 0 through 32.
• The stated UInt32 implementation note is incomplete: 2^32 cannot be represented in UInt32, so host-count intermediate arithmetic must use UInt64 or a special-case implementation.

Units and conventions

• IPv4 addresses are dotted-decimal octets, each in the inclusive range 0 through 255.
• A CIDR prefix is an integer from 0 through 32; a supplied subnet mask is a contiguous 32-bit mask and is converted to its equivalent prefix.
• Bitwise operations are performed on exactly 32 bits, with no signed-integer sign extension.
• host_count conventionally excludes the network and broadcast addresses for prefixes /0 through /30.
• All addresses and masks are dimensionless bit patterns; host_count is a nonnegative integer.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "ipv4": "192.168.1.10",
    "prefix": 24
  },
  "expected_outputs": {
    "network_address": "192.168.1.0",
    "broadcast_address": "192.168.1.255",
    "first_usable_host": "192.168.1.1",
    "last_usable_host": "192.168.1.254",
    "subnet_mask": "255.255.255.0",
    "wildcard_mask": "0.0.0.255",
    "host_count": 254,
    "binary_breakdown": {
      "ip": "11000000.10101000.00000001.00001010",
      "mask": "11111111.11111111.11111111.00000000",
      "network": "11000000.10101000.00000001.00000000",
      "broadcast": "11000000.10101000.00000001.11111111"
    }
  },
  "working": "prefix=24, so host_bits=32-24=8. host_count=2^8-2=256-2=254. mask=255.255.255.0; wildcard=255.255.255.255-255.255.255.0=0.0.0.255. IP AND mask: 192 AND 255=192, 168 AND 255=168, 1 AND 255=1, 10 AND 0=0, giving network 192.168.1.0. broadcast=network OR wildcard: 192.168.1.0 OR 0.0.0.255=192.168.1.255. first usable=network+1=192.168.1.1; last usable=broadcast-1=192.168.1.254."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The supplied host formula produces an invalid negative host count for /32: 2^(32-32)-2 = -1. The calculator should reject that result or implement an explicit /32 special case. A second convention-sensitive boundary occurs at /31, where the stated traditional formula gives zero usable hosts but RFC3021 point-to-point semantics give two.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche3/tranche3-results.json
• BOUNDARY_HAZARD_CATALOG.json