Repository navigation
fix(protocols): two octets of option padding are written as two Pad1 options, not one PadN #1793
Description
Describe the bug
For two octets of padding, the padding builders emit two Pad1 options:
pcapkit/protocols/internet/hopopt.py:1369-1372pcapkit/protocols/internet/ipv6_opts.py:1358-1361pcapkit/protocols/internet/mh.py:7755-7758
_make_pad_options(6) returns [Pad1, Pad1] on each. RFC 8200 §4.2 says PadN "should be used, rather than multiple Pad1 options", and RFC 6275 §6.2.2 says the same for Mobility options. The code already parses a two-octet PadN with length 0.
Expected behavior
Two octets of padding become one PadN with length 0; one octet stays a Pad1. The builders' docstrings, which state the two-Pad1 behaviour, follow.
Additional context
Low severity: a SHOULD, so the output is still valid. Found by the #1103 second pass (internet slice) and confirmed by a Sonnet review. #354 is a different PadN defect.
Activity
JarryShaw commentedon Oct 15, 2026
Blocked until #1798 merges; it edits the docstrings of
hopopt.py,ipv6_opts.pyandmh.py, which this fix also changes.JarryShaw commentedon Oct 15, 2026
Unblocked: #1798 has merged. A worker is on it.