fix(esp): short-circuit read() when parsed as an IPv6 extension header (#895)

[JarryShaw]

Closes #895.

The maintainer's ruling: "i say the short-circuit must be done in ESP cause it's part of the IPv6 extension headers."

#924 discharged this issue's substantive half — _extf became load-bearing, so payload, protochain and protocol consult it. This is the other half: the if extension: return guard its seven siblings all have before calling _decode_next_layer. When the header is one link of an IPv6 chain, IPv6._decode_next_layer walks the rest of the chain itself, so decoding it again from inside the header produces a result nobody reads.

ESP needed the guard in two places, not one. The decrypted path returns at read's tail; every undecrypted path — no security association, wrong key, malformed trailer — returns through _make_opaque instead. Guarding only read's tail would leave the common case unfixed, since a capture taken without keys is the expected case rather than the rare one. _make_opaque has no extension parameter, so it consults self._extf, which __post_init__ sets before handing off to read.

Measured, patching Internet — which is what actually defines _decode_next_layer; patching ProtocolBase intercepts nothing and silently reads zero:

extension=True  -> _decode_next_layer called 0x
extension=False -> _decode_next_layer called 1x

Reverting both guards fails the new tests with 1 != 0 and with the family sweep naming esp.py:1194.

One note on the tests themselves: the family sweep pairs each return self._decode_next_layer( with the two lines above it. A first draft merely looked for if extension: anywhere in the file and passed on unfixed ESP, because ESP.protocol already consults self._extf for an unrelated reason — true and useless. The committed version distinguishes a guarded return from an unguarded one.

Verified: 5 new tests pass; test_esp_unit, test_ah_unit, test_ipv6_ext_unit and test_isort_clean green at 65 tests.

• fix
• changelog — N/A -- changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

[JarryShaw]

Closed unmerged per the ruling on #895 — "okay, that makes sense now." ESP is an IPv6 extension header per IANA, but RFC 4303 puts its Next Header inside the encrypted trailer, so the chain walk cannot continue past it and the short-circuit loses every parsed inner layer rather than deferring the work. Measured: info.ipv4 absent and protochain raising UnsupportedCall on RFC 3602 case 7. The exclusion is already documented at pcapkit/protocols/internet/ipv6.py:90-100.