Repository navigation
fix(protocols): a non-first IPv6 fragment's data is dissected as an upper-layer header #1545
Description
On main b6b95bc8e, the default engine dissects the data of a non-first IPv6 fragment as if it began with the header named in the Fragment header's Next Header field.
examples/captures/ipv6.pcap, frames 13–16 (Fragment offsets 0, 1448, 2896, 4344), all read Ethernet:IPv6:IPv6-Frag:UDP:Raw:
| Frame | Offset | UDP read |
|---|---|---|
| 13 | 0 | 51234 → 5001, len 4778 (real) |
| 14 | 1448 | 39645 → 58998, len 24206 (payload bytes) |
| 15 | 2896 | 62624 → 12089, len 12864 |
| 16 | 4344 | 10352 → 14281, len 20758 |
Frag(offset > 0) + TCP does the same (Frag:TCP:Raw), so TCP flow tracing and reassembly can ingest garbage segments.
RFC 8200 §4.5: subsequent fragments carry the Per-Fragment headers, the Fragment header, then "the fragment itself", a slice of the Fragmentable Part. No header begins there. The Next Header field names the first header of the Fragmentable Part, which is only in the first fragment.
Expected: after a Fragment header with offset > 0, the remainder is opaque payload (Raw), not a parsed upper layer. This changes the sample digests for frames 14–16, deliberately.
The #1540 worker and its reviewer found this; I re-derived it on a git archive of main.
Activity
JarryShaw commentedon Oct 10, 2026
Blocked until #1540 merges, since both change the fragment walk in
pcapkit/protocols/internet/ipv6.py.JarryShaw commentedon Oct 10, 2026
Unblocked: #1540 has merged (
f4243bcbb). A worker is on the fix inpcapkit/protocols/internet/ipv6.py.fix(protocols): a later IPv6 fragment's data is raw, not an upper-lay…
fix(protocols): a later IPv4 fragment's data is raw, not an upper-lay…