Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument / verified-clean

Subnet Splitter / VLSM Planner

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: VERIFIED_CLEANLifecycle: verified-clean

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area
Computing & Information
Tranche
tranche-4
Evidence ID
t4-004
Ledger rows
1

No ledger note is attached.

Review findings

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.

Formula and scope findings

  • 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.

Unit assumptions

  • 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.

Boundary hardening

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.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "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."
}

Related workflows

Sources and evidence

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

  • VERIFIED_LEDGER.json · VERIFIED_CLEAN
  • evidence-tranche4/tranche4-results.json
  • BOUNDARY_HAZARD_CATALOG.json