Subnet Splitter / VLSM Planner mechanism

Model scope

The host-sizing arithmetic is standard under the stated IPv4 usable-host assumptions, but the spec is incomplete and ambiguous about address-family scope, zero-host and /31-/32 behavior, allocation ordering, and capacity/alignment validation. The empty honest_label is also a labeling concern: the instrument should explicitly state that it is an IPv4 VLSM planner using conventional network/broadcast reservations and that it does not support arbitrary subnet semantics without additional policy.

• needed_bits=ceil(log2(hosts+2)) is correct only for conventional IPv4 subnets where two addresses are reserved for the network and broadcast; it does not cover RFC 3021 /31 point-to-point links, /32 host routes, or zero-host allocations.
• The specification does not define the allocation-order rule. Correct VLSM planning normally sorts requirements from largest to smallest before allocating aligned blocks; merely allocating in the supplied order can create avoidable gaps or failure.
• The specification omits the block-alignment, address-capacity, and exhaustion checks required to ensure every allocated subnet fits inside the base network.
• The formula does not define behavior for non-integer or negative host counts, IPv6, or host counts that exceed the address capacity of the base network.

Units and conventions

• Inputs are IPv4 CIDR networks and required host counts are integer counts of usable IPv4 host addresses.
• The +2 reserves one network address and one broadcast address per subnet.
• Subnet sizes are powers of two addresses; block size is 2^needed_bits and prefix length is 32-needed_bits.
• Allocation examples assume requirements are processed largest-first, with each block placed at the next valid CIDR boundary.
• Ranges include network and broadcast addresses; usable ranges exclude those two reserved addresses.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "base_network": "192.168.10.0/24",
    "required_hosts": [
      100,
      50,
      10
    ]
  },
  "expected_outputs": {
    "allocations": [
      {
        "required_hosts": 100,
        "cidr": "192.168.10.0/25",
        "mask": "255.255.255.128",
        "address_range": "192.168.10.0-192.168.10.127",
        "usable_range": "192.168.10.1-192.168.10.126"
      },
      {
        "required_hosts": 50,
        "cidr": "192.168.10.128/26",
        "mask": "255.255.255.192",
        "address_range": "192.168.10.128-192.168.10.191",
        "usable_range": "192.168.10.129-192.168.10.190"
      },
      {
        "required_hosts": 10,
        "cidr": "192.168.10.192/28",
        "mask": "255.255.255.240",
        "address_range": "192.168.10.192-192.168.10.207",
        "usable_range": "192.168.10.193-192.168.10.206"
      }
    ]
  },
  "working": "100+2=102; ceil(log2(102))=7; block=2^7=128 addresses; prefix=32-7=/25. 50+2=52; ceil(log2(52))=6; block=2^6=64; prefix=/26. 10+2=12; ceil(log2(12))=4; block=2^4=16; prefix=/28. Starting at .0, the /25 consumes .0-.127; the next aligned /26 starts at .128 and consumes .128-.191; the next aligned /28 starts at .192 and consumes .192-.207."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The specification gives no stated validation behavior for negative host counts, so an input of -2 reaches log2(0), an undefined result. It also leaves host-count and /31 network conventions ambiguous.

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-tranche4/tranche4-results.json
• BOUNDARY_HAZARD_CATALOG.json