Source: https://guthlabs.ai/docs/instruments/mtu-packet-fragmentation-calculator/mechanism/

instrument mechanism / verified-clean

# MTU / Packet Fragmentation Calculator mechanism

The inspectable method record for MTU / Packet Fragmentation Calculator, kept separate from implementation and qualification.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Model scope

The existing honest label correctly identifies the model as idealized and mentions path MTU discovery and firewalls, but it should also explicitly disclose the missing IPv4 8-byte alignment rule, IPv6 Fragment extension header, IPv6 router behavior, DF handling, input-unit requirements, and zero/invalid-input behavior. Verdict is NEEDS_REVIEW because units, per-fragment size semantics, zero-payload behavior, and protocol-specific header treatment are not fully specified.

- The formula payload_per_fragment = MTU - header_size is only an idealized arithmetic model, not the standard IPv4/IPv6 fragmentation calculation.

- IPv4 non-final fragment payloads must be multiples of 8 bytes; the formula does not enforce this alignment.

- IPv6 fragmentation requires an 8-byte Fragment extension header on fragmented packets, and IPv6 routers do not fragment packets; the formula does not model either fact.

- The protocol input is not actually used to select protocol-specific rules, and header_overhead is ambiguous regarding IPv4 options, IPv6 extension headers, and whether the fragmentation header is included.

- per-fragment size is undefined: the specification does not state whether this means each fragment's total size, payload size, or only a maximum size. It also does not define the final fragment size.

- The formula does not state whether payload is transport/application payload or the bytes after the supplied header overhead. Total overhead is only correctly computed as fragment_count multiplied by per-fragment header overhead under the idealized model.

## Units and conventions

- All payload, MTU, header_size, fragment sizes, and overhead values are integer bytes; decimal KB, KiB, bits, and bytes must not be mixed.

- MTU is treated as the maximum total IP packet size, including the supplied header_size.

- payload is treated as bytes carried above the supplied header_size.

- header_size is assumed to be present on every fragment, with no IPv4 options or IPv6 extension headers unless explicitly included in that value.

- The test vectors use the declared idealized formula, not standards-compliant wire-level IPv4/IPv6 fragmentation behavior.

- For these vectors, per-fragment size means total fragment size, and total overhead means fragment_count multiplied by header_size.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "inputs": {
    "payload": 4000,
    "MTU": 1500,
    "protocol": "IPv4",
    "header_size": 20
  },
  "expected_outputs": {
    "will_fragment": true,
    "payload_per_fragment": 1480,
    "fragment_count": 3,
    "fragment_payload_sizes": [
      1480,
      1480,
      1040
    ],
    "fragment_sizes": [
      1500,
      1500,
      1060
    ],
    "total_overhead_bytes": 60
  },
  "working": "payload_per_fragment = 1500 - 20 = 1480 bytes. fragment_count = ceil(4000 / 1480) = ceil(2.702702...) = 3. First two fragment payloads are 1480 bytes: 1480 + 1480 = 2960. Last payload = 4000 - 2960 = 1040 bytes. Total fragment sizes = 1480 + 20 = 1500, 1480 + 20 = 1500, and 1040 + 20 = 1060 bytes. Total overhead = 3 x 20 = 60 bytes."
}
````

## Failure boundary

**BREAK_CLAIMED** · SELF_FLAGGED

The formula permits MTU equal to header overhead, producing a zero payload capacity and an undefined fragment-count division. The calculator must reject MTU <= header_size. The specification also leaves KB-versus-KiB interpretation ambiguous.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/mtu-packet-fragmentation-calculator/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/mtu-packet-fragmentation-calculator/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/mtu-packet-fragmentation-calculator/qualification/>)

## Sources and evidence

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

- `VERIFIED_LEDGER.json`

- `evidence-tranche5/tranche5-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`