fix(protocols)!: pad two octets with one PadN, not two Pad1 (#1793)

[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. Narrow runs only, listed below.

• 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

---

Summary

For two octets of padding, the HOPOPT, IPv6-Opts and MH padding builders emitted two Pad1 options. RFC 8200 §4.2, and RFC 6275 §6.2.2 for Mobility options, say a PadN should be used rather than multiple Pad1 options.

• Fix: in each _make_pad_options (hopopt.py, ipv6_opts.py, mh.py; they share no helper), only one octet gives a Pad1. Two octets become a PadN of length 0 (01 00), and three or more are unchanged. The builders' docstrings cite the RFCs.
• Breaking: a freshly built header with exactly two octets of padding has different bytes. Parsing is unaffected, and a parsed packet that carried two Pad1 options still rebuilds byte for byte.
• Tests: tests/protocols/internet/test_padn_two_octets_1793_unit.py fails on main for all three protocols. Existing fresh-build byte pins move to 01 00; parsed-frame pins are unchanged.
• Runs: tests/protocols/internet, the option and capture round-trip suites, and tests/project pass.

Closes #1793

[JarryShaw]

Verdict: GOOD TO GO at 109638aa4. A Sonnet cross-review (author: Opus) checked 6fe698f6d; this head only adds ! to the subject, and the tree is identical. It checked the RFC text, and a grep found exactly three padding builders. The new tests fail on main. A property probe over 94 built headers found no adjacent Pad1 options on the fix, all round-tripping byte for byte. Old two-Pad1 captures still rebuild exactly, and EXPECTED_FAILURES is untouched (empty).

[github-actions]

Coverage: 89.60% (unit tier, Python 3.15, 109638aa4, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18862	954	2368	868	91.06%
pcapkit/corekit	2462	69	780	35	96.55%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2915	164	1016	34	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17197	224	4580	189	98.09%
pcapkit/toolkit	872	177	298	8	77.18%
pcapkit/utilities	512	2	158	4	99.10%
pcapkit/vendor	4417	2342	1010	157	43.38%

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