[JarryShaw]

• 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?

• fix — corrects a defect

---

Description of your pull request and other information

IPv6_Ext is the abstract name for the IPv6 extension-header family, so its id() now composes its direct concrete subclasses: HOPOPT, IPv6_Route, IPv6_Frag, ESP, AH, IPv6_Opts, MH, HIP. Selecting 'IPv6_Ext' matches any extension header.

Each member narrows id() to its own class name, as AH/ESP do under IPsec; members' output is unchanged from main. A header parsed by IPv6_Ext itself (Shim6, or a dedicated parser's fallback) matches every member name and 'IPsec'; #2477 will make failed dedicated parses Raw instead.

Tests derive the member set from the class hierarchy, so a new subclass can't drift, and check protochain selection on parsed packets.

Closes #2462

[JarryShaw]

Cross-review (different model, adversarial) came back NEEDS CHANGES, and found a real flaw in #2462's own premise, not just a bug in this PR.

Squarely fixable, no decision needed:

1. HIP subclasses IPv6_Ext and has no id() override, so it inherits the new 7-name family tuple — it now false-matches as AH/ESP/HOPOPT/MH in a protocol chain, and hip == 'HIP' flips from True to False. Needs its own ('HIP',) override.
2. The alias strings are wrong — every existing precedent (C_Tag/S_Tag, HTTPv1/HTTPv2, ARP/InARP) uses the Python class name in id(), even where alias differs (C_Tag.alias is '802.1Q' but C_Tag.id() is ('C_Tag', 'VLAN')). This PR (and my issue IPv6_Ext family is missing the id() sibling-dispatch trick #2462, which got this wrong) used hyphenated alias strings instead, which flips frag == 'IPv6_Frag' from True to False — the opposite of "purely additive".
3. No tests were added (every other family has one pinning its id()), and no docs (.. automethod:: id is missing from all 6 pages, so the new methods won't render).

Needs a decision — IPv6_Ext isn't actually like IP/IPsec/VLAN. Those three family bases are abstract; IPv6_Ext is a documented "concrete fallback parser" (#917) — Shim6 registers straight to it, and any failed HOPOPT/Route/Opts/MH/HIP/AH parse falls back to it too. Giving it a family-wide id() tuple means a Shim6 packet, or any failed-parse fallback, now matches 'AH'/'ESP'/'HOPOPT'/'MH' in the chain — a real false positive, not a narrowing-style tradeoff. The reviewer confirmed nothing in this codebase currently uses 'IPv6_Ext' as a string selector.

My recommendation: drop the family-wide tuple entirely. IPv6_Ext.id() stays ('IPv6_Ext',) (its own name only), and the 6 siblings each narrow to just their own class name — satisfying #2462's actual ask (siblings get their own identity) without the fallback-parser hazard. Labeling needs: decision in case there's a reason to want the family-string selector anyway; proceeding with this safer default meanwhile.

Dispatching a fix now.

[JarryShaw]

Fixed and verified directly (new head afc91037a): IPv6_Ext.id() dropped to ('IPv6_Ext',) only (it's a concrete fallback parser, per the owner's confirmed decision on #2462), HIP.id() added, and the 3 hyphenated alias strings corrected to class names. Added a regression test proving a Shim6-carrying packet no longer false-matches AH/HOPOPT/MH — confirmed it fails against the pre-fix tuple and passes now. Docs updated on all 7 pages. 441 tests passing, pylint/mypy identical to baseline.

[github-actions]

Coverage: 94.44% (unit tier, Python 3.15, 798a87866, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	19609	133	2620	120	98.84%
pcapkit/corekit	2605	74	818	37	96.52%
pcapkit/dumpkit	281	3	100	3	98.43%
pcapkit/foundation	3070	24	1072	26	98.79%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	17614	193	4678	179	98.32%
pcapkit/toolkit	924	36	334	10	95.55%
pcapkit/utilities	502	7	144	5	98.14%
pcapkit/vendor	4449	1854	1020	167	55.11%

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

[JarryShaw]

NEEDS CHANGES. Cross-review on Opus at head afc91037a. The author was also a default-model (Opus) worker, so this is not a different-model review; a Sonnet pass follows the fix round.

The core claim holds: IPv6_Ext is a concrete fallback parser (Internet.__proto__[TransType.Shim6] = IPv6_Ext, and IPv6._import_next_layer substitutes it when a dedicated parser raises), so a family-wide tuple would be wrong. The implementation has a real defect, though:

1. The hard-coded base id() leaks into subclasses. On main, IPv6_Ext has no id() and inherits Protocol.id() → (cls.__name__,); I checked both trees. With ('IPv6_Ext',) hard-coded, any subclass without its own id() reports as the fallback parser. A Shim6(IPv6_Ext) defining everything the refactor(ipv6): rename IPv6_GenericExt to IPv6_Ext and make it the base for all 8 extension headers #917 rule requires gives Shim6.id() == ('IPv6_Ext',), inst == 'Shim6' False, inst['IPv6_Ext'] found. That is the mirror of the false match this PR targets, and nothing catches it. Simplest fix, verified by the reviewer in a scratch copy: delete IPv6_Ext.id() and put its rationale in the class docstring. Also drop the six leaf # type: ignore[override] comments, which then go unused. mypy then matches main exactly.
2. Title, body and commit message describe revision 1. They describe a family tuple, sibling dispatch, and siblings that "used the hyphenated alias". On main none of the seven classes defines id(), and every built-in class's id() output is identical between main and the head, so this pins and documents behaviour rather than fixing a defect.
3. The new test's docstring claims a regression that never existed. Both new tests pass on unmodified main; reword as a guard.
4. Attribution. The direction rests on a reading of IPv6_Ext family is missing the id() sibling-dispatch trick #2462 that isn't safe. Asking there now; the fix round waits on that answer.

[JarryShaw]

Fix worker dispatched for option (a), per the ruling on #2462.

[JarryShaw]

Verified (0fae5ce9d): IPv6_Ext.id() composes its 8 direct concrete subclasses (AH/ESP included, since they subclass IPv6_Ext directly); members narrow to themselves; a test derives the set from the hierarchy. Sonnet review dispatched.

[JarryShaw]

NEEDS CHANGES (Sonnet, 0fae5ce9d). The member set, its spelling and the selectors on real packets are all correct, and AH/ESP/IP/IPsec selection is unchanged.

• Squash: afc91037a's message describes the abandoned design and false "fixes".
• IPv6_Ext(...) == 'IPv6_Ext' was True on main and is now False. Match the IP/IPv4 precedent and pin it with a test.
• The class's "must define" Warning omits id(). A subclass that skips it inherits all 8 names.
• The selector test covers only HOPOPT, Opts and Frag. Add Route, MH, AH, ESP, HIP, 'IPsec' and the fallback case.
• Body fixed: A malformed known IPv6 extension header should parse as Raw, not IPv6_Ext #2477 hasn't landed, so a failed dedicated parse still falls back to IPv6_Ext.

[JarryShaw]

Verified (810902017, one commit): == against the family name is False, as ipv4 == 'IP' already is (measured), and now pinned; the "must define" list includes id(); selector tests cover all 8 members plus the fallback. Sonnet review dispatched.

[JarryShaw]

NEEDS CHANGES (Sonnet, 810902017). Code, tests and lint pass: all 16 mutants caught except one equivalent, and == matches the IP precedent.

• The commit message clause "AH and ESP keep the one IPsec already gives them" is wrong. Each defines its own narrowed id(). Use "AH and ESP already narrow theirs".
• Scope the id() Note to the string form: fallback == IPv6_Ext (the class) is True.

[JarryShaw]

Pushed 798a87866 (held until the 1.5.1 release cleared): addresses the previous review. Sonnet review dispatched.

[JarryShaw]

GOOD TO GO (Sonnet, 798a87866). Both fixes are in, nothing else changed, and the IPv6 tests pass once samples are generated (the earlier failures were missing captures, identical on main).