[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

Closes #1585. The code change is in pcapkit/foundation/reassembly/ip.py and ipv6.py; the docs under docs/source/pcapkit/foundation/reassembly/ip/ and the Datagram.conflict comment are brought in line.

• Length bound. IP._is_complete now bounds a datagram at 65,535 octets with its header, as the new IP._header_overhead counts it. IPv4's Total Length counts the whole header. IPv6's Payload Length counts every header except the fixed 40 octets, so ipv6.py overrides the hook. The issue's case 3c (20 + 65,523) now reads PARTIAL with every octet still reported. IPv6 with no extension header still completes at 65,535 octets of data.
• Total Length 0 declares no length (fix(reassembly): IPv4 reassembly leaves a TSO datagram (total_length 0) incomplete #1555). If such a datagram is too long with its header, the buffer grows past 65,535 octets, and that lifts the bound. The 1555 and 1565 TSO pins are unchanged.
• _detect_conflicts docstring. It now says that octets in an unmarked partial block are deliberately not compared (fix(reassembly): IPv6 reassembly zero-fills a snaplen-cut non-final fragment and reports it COMPLETE #1567). A new test pins this. The Datagram.conflict comment and the conflict notes in ipv4.rst and ipv6.rst had the same stale claim, and now say the same.
• Docs. ip/index.rst lists the bound, with the Total Length 0 exemption, as a third departure from RFC 791.
• Changed pin. One fix(reassembly): IPv4 reassembly raises IndexError for a fragment reaching octet 65,528 #1565 test asserted that an IPv4 final fragment at offset 65,528 completes. That is the defect, because 20 + 65,529 > 65,535, so the test now runs on IPv6 only.

The default, dpkt and scapy engines agree on crafted IPv4/IPv6 captures. Sample-capture reassembly is byte-identical to main: 7,998 rows across those engines, in both modes.

[JarryShaw]

Verdict: GOOD TO GO at 3fa86c900. This was a Sonnet cross-review; the author ran on Opus.

• Boundaries, measured one octet either side, in memory and through crafted pcaps on the default, dpkt and scapy engines:
  • IPv4 completes at ≤65,515 data octets with IHL 20 and ≤65,475 with IHL 60.
  • IPv6 completes at ≤65,535, and at ≤65,527 with 8 octets of extension headers.
  • I re-checked IPv4 IHL 20 myself: 65,515 is COMPLETE and 65,516 is PARTIAL.
  • This matches net/ipv4/ip_fragment.c and net/ipv6/reassembly.c.
• Total Length 0: the fix(reassembly): IPv4 reassembly leaves a TSO datagram (total_length 0) incomplete #1555 and fix(reassembly): IPv4 reassembly raises IndexError for a fragment reaching octet 65,528 #1565 TSO pins pass. Only a TL=0 fragment grows the buffer, and no non-TSO datagram completes over the bound.
• fix(reassembly): IPv4 reassembly raises IndexError for a fragment reaching octet 65,528 #1565 test moved to IPv6: the move is forced. A final fragment at offset 65,528 has TDL ≥ 65,528, which is over IPv4's 65,515.
• Fail-before: 14 subtests fail on main.
• No regression: all 17 reassembly test files pass, run one at a time. Sample-capture reassembly is identical to main (8,274 rows, compared with cmp), and round trips are unchanged.

Non-blocking corner: a first fragment with options (IHL 60, real Total Length) followed by a TL=0 final fragment at IHL 20, with TDL 65,500, reads PARTIAL; on main it reads COMPLETE. The growth rule uses the arriving fragment's IHL, while the bound uses the first fragment's. TSO does not produce that mix, but it makes the "only the buffer bounds it" wording in ip/index.rst slightly too strong.

[github-actions]

Coverage: 89.70% (unit tier, Python 3.14, 3fa86c900, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	956	2366	870	91.04%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2863	154	1006	42	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	16996	227	4540	192	98.04%
pcapkit/toolkit	770	96	266	6	86.68%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4409	2342	1006	157	43.25%

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