Repository navigation
fix(protocols): IPv6.read accepts a header whose Version is not 6 #1680
Description
Question, carried over from #1666, which #1675 fixed and closed: should IPv6.read reject a header whose Version is not 6?
Today. IPv6.read copies the Version nibble without checking it (pcapkit/protocols/internet/ipv6.py:206), although Data_IPv6.version is typed Literal[6] (pcapkit/protocols/data/internet/ipv6.py:38). IPv4.read rejects any Version but 4 (pcapkit/protocols/internet/ipv4.py:296), and tshark stops at "Bogus IPv6 version".
Measured with a runtime patch on #1666's survey: rejecting Version ≠ 6 would drop the default engine's inputs on rows 1-8 and 15. TCP and trace inputs would go to 0/0, and row 15 would lose its IPv6 reassembly inputs. The H4 controls would also lose theirs: a first fragment, a later fragment, and H4 carrying IPv4. dpkt and scapy hand all of these over, so agreement would need the same change in every engine.
Options:
- Keep accepting any Version (today's behaviour). The engines agree as they are.
- Reject Version ≠ 6 in
IPv6.read, asIPv4.readdoes, and make dpkt, scapy and pypcapfile stop there too.
Activity
JarryShaw commentedon Oct 13, 2026
If the version is not 6, it should reject. Each concrete protocol class should focus only on itself. Only those abstract protocol classes with dispatcher logic can handle multiple concrete protocols.
JarryShaw commentedon Oct 13, 2026
Recorded:
IPv6.readrejects a Version other than 6, asIPv4.readrejects anything but 4. Each concrete protocol class handles only itself, and only the abstract dispatcher classes route between protocols. Retitled as a fix.Every engine has to stop at the same place, or the change opens new disagreements. On these frames, dpkt, scapy and pypcapfile would hand over inputs while the default engine hands over none. tshark already stops at "Bogus IPv6 version". So this lands as one PR covering
IPv6.readand each engine's adapter.Blocked until the open work on those engine files merges: the PRs for #1667 (pypcapfile), #1676 (scapy) and #1671 (pyshark).
[-]question: should IPv6.read reject a header whose Version is not 6?[/-][+]fix(protocols): IPv6.read accepts a header whose Version is not 6[/+]JarryShaw commentedon Oct 13, 2026
#1682 (pypcapfile) and #1683 (scapy) have merged. This is now blocked only on the PR for #1671 (pyshark), which a worker is writing.
JarryShaw commentedon Oct 14, 2026
Its pyshark blocker, #1686, has merged. Two others now hold it, because this lands as one PR across every engine adapter: #1690 (open) edits the dpkt and pypcapfile adapters,
pcapkit/toolkit/dpkt.pyandpcapkit/toolkit/pypcapfile.py, and the #1626 worker is editingpcapkit/toolkit/pyshark.py. Blocked until #1690 and the PR for #1626 merge.JarryShaw commentedon Oct 14, 2026
#1690 has merged. This is now blocked only on the PR for #1626, whose worker is editing
pcapkit/toolkit/pyshark.py.JarryShaw commentedon Oct 14, 2026
Re-scoped under the best-effort ruling on #1687:
IPv6.readrejects a Version other than 6 in the default engine only, and the adapters stay as they are. That removes the pyshark blocker. It now waits only on the #1687 PR, which editsIPv6.read's jumbogram handling in the same file,pcapkit/protocols/internet/ipv6.py. Blocked until the #1687 PR merges.JarryShaw commentedon Oct 14, 2026
The #1687 PR is #1713. This stays blocked until it merges.
JarryShaw commentedon Oct 14, 2026
#1713 has merged, so this is unblocked. A worker is on it:
IPv6.readrejects a Version other than 6 in the default engine only, as recorded above.