[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

RFC 2675 §3 lists four errors a receiver must detect: Payload Length 0 with a Hop-by-Hop header and no Jumbo Payload option; a non-zero Payload Length with the option; a Jumbo Payload Length below 65,536; the option with a Fragment header. IPv6.read now raises ProtocolError for each, as IPv4.read rejects a bad version, so behind a link layer the frame stops at IPv6 and rebuilds byte for byte. jumbogram_error() in schema/internet/ipv6.py defines all four. A capture cut before the Jumbo Payload option is rejected too (the first error), as the RFC has it. A capture cut after the option but short of its Jumbo Payload Length is still read as a jumbogram.

This changes the default engine only. The dpkt, scapy, pyshark and pypcapfile adapters are untouched; they are best effort and need not match.

IPv6.make with payload_length unset now writes 0 when the payload's leading Hop-by-Hop header carries a Jumbo Payload option, so a genuine Jumbo Payload Length builds a jumbogram, and make->parse round-trips byte for byte. Input the caller made invalid still raises on construction: a Jumbo Payload Length ≤ 65,535, an explicit non-zero payload_length, or a Fragment header. HOPOPT alone and in IPv4 is unchanged.

examples/generators/options.py built HOPOPT's Jumbo Payload frame in options-ipv6.pcap with Jumbo Payload Length 0 behind a non-zero Payload Length, now rejected, so the frame stopped at IPv6. It is now a genuine jumbogram: Payload Length 0, Jumbo Payload Length 65,536, filled out by a UDP datagram with a valid checksum, in a capture whose snaplen (262,144) lets libpcap readers take the 65,590-octet frame whole. The scapy engine reads only its first 65,535 octets (scapy's MTU, in PcapReader.recv); third-party engines are best effort.

Tests: a new class in test_ipv6_jumbogram_unit.py, tests/toolkit/test_pcap_jumbogram_rfc2675_1687_unit.py (default-engine extraction inputs) and tests/protocols/test_option_generator_jumbogram_1687_unit.py (the generator's jumbogram); all fail on origin/main. test_option_coverage_runtime.py checks the capture's jumbogram is read whole. Adapter tests drop the rows that compared an adapter with the default engine on a now-invalid jumbogram (#1708 cleans those files up). Only the related suites were run, on 3.14.8 and 3.11.15, not the whole suite.

Closes #1687

[JarryShaw]

Verdict: GOOD TO GO at 191460715. A Sonnet cross-review covered two rounds.

• RFC 2675: the four §3 receiver errors are rejected by the default engine. Behind Ethernet the frame stops at a raw IPv6 layer and rebuilds byte for byte. Genuine jumbograms, including Jumbo Payload Length 65,536, parse unchanged, and an ICMPv6 quote of a rejected header still parses.
• Your two rulings: with payload_length unset, a Jumbo option makes IPv6.make write 0; explicitly invalid input still raises; a capture cut before the option is rejected.
• Scope: pcapkit/toolkit/ is byte-identical to main, and no test asserts a third-party engine against the default.
• Tests: 220 round-trip tests and 9,943 subtests pass on 3.14 and 3.11. The new tests fail on main (46).
• Left for refactor(toolkit): revert the cross-engine agreement tests and the adapter code that only mirrors the default engine #1708: four adapter-test rows now compare two empty results, and refactor(toolkit): revert the cross-engine agreement tests and the adapter code that only mirrors the default engine #1708 deletes them.

[JarryShaw]

CI is red on 191460715, and the cause is a real test failure. The Integration legs (3.11–3.15) and the PyPCAP/PyPCAPFile parity leg fail one subtest:

• tests/protocols/test_option_coverage_runtime.py, capture options-ipv6.pcap, frame 12: expected a Ethernet:IPv6 envelope, got Ethernet:Internet_Protocol_version_6.
• examples/generators/options.py:1593 puts the Jumbo Payload option in an IPv6 envelope with a non-zero Payload Length. That is RFC 2675's second error, so this PR now rejects the frame. The narrow runs in both rounds missed this runtime-tier test.

Round 3 fixes the generator or the test, keeping coverage of the Jumbo option, and re-runs every test that reads these captures. The verdict resets on the new head.

[github-actions]

Coverage: 89.47% (unit tier, Python 3.15, f927e8df7, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18860	954	2368	868	91.06%
pcapkit/corekit	2372	67	762	35	96.49%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	3035	151	1076	34	94.28%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17181	226	4590	190	98.07%
pcapkit/toolkit	1437	281	592	6	77.97%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4417	2342	1010	157	43.38%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

Verdict: GOOD TO GO at a4cf408ff. A Sonnet cross-review checked round 3, which fixes the red Integration and parity legs.

• The fix: examples/generators/options.py now emits the HOPOPT Jumbo Payload frame of options-ipv6.pcap as a genuine jumbogram: Payload Length 0, Jumbo Payload Length 65,536 carried in full, and a UDP datagram whose RFC 1071 checksum the reviewer recomputed independently.
• Snaplen: the capture's snaplen is 262,144, so readers don't cut the 65,590-octet frame. The other four option captures are byte-identical.
• The failing test: test_option_coverage_runtime.py fails at 191460715 and passes here on 3.14 and 3.11. Every test reading the option captures passes: 27 tests, 31,961 subtests.
• Known limit: the scapy engine delivers only the first 65,535 octets of that frame; that is filed separately.

[JarryShaw]

CI is red on a4cf408ff, from a real failure. On the unit legs (3.11–3.15), the new tests/protocols/test_option_generator_jumbogram_1687_unit.py fails 4 tests with ModuleNotFoundError: No module named 'scapy'. _jumbogram_datagram (examples/generators/options.py:1933) imports scapy.utils.checksum, and the unit tier installs no scapy. The local runs had scapy, so they missed it. Round 4 computes the RFC 1071 checksum without scapy, so the test keeps running on the unit tier. The verdict resets on the new head.

[JarryShaw]

Verdict: GOOD TO GO at f927e8df7. A Sonnet cross-review checked round 4.

• The fix: _jumbogram_datagram now computes the UDP checksum with a pure-Python RFC 1071 sum over the IPv6 pseudo-header (RFC 8200 §8.1). It equals scapy.utils.checksum on 46 datagram sizes, and the receiver sum comes to 0xFFFF.
• Captures unchanged: options-ipv6.pcap is byte-identical to round 3's.
• The failing tests: they failed on a4cf408ff in a venv without scapy and pass here.
• New test: test_the_datagram_needs_no_scapy blocks every scapy module, so the unit test cannot regress even where scapy is installed.