MTU / Packet Fragmentation Calculator mechanism

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

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