ExtensionHeader is generated from the wrong IANA registry, so it carries a member the authoritative list does not have.
Measured. pcapkit/const/ipv6/extension_header.py has 12 members:
0 HOPOPT, 43 IPv6_Route, 44 IPv6_Frag, 50 ESP, 51 AH, 60 IPv6_Opts,
135 Mobility_Header, 139 HIP, 140 Shim6, 147 BIT_EMU,
253 / 254 Use_for_experimentation_and_testing
IANA's IPv6 Extension Header Types registry has 11 — the same list without 147 BIT_EMU:
curl https://www.iana.org/assignments/ipv6-parameters/extension-header.csv
0, 43, 44, 50, 51, 60, 135, 139, 140, 253, 254
Root cause is the source URL. pcapkit/vendor/ipv6/extension_header.py:57 reads:
LINK = 'https://www.iana.org/assignments/protocol-numbers/protocol-numbers-1.csv'
That is the Protocol Numbers registry, filtered on its IPv6 Extension Header column — a derived signal rather than the registry that defines the set. And the two registries disagree: protocol-numbers-1.csv flags 147,BIT-EMU,Bit-stream Emulation,Y,[RFC9801], while extension-header.csv omits 147 entirely.
Which side is right. RFC 8200 §4 makes the extension-header registry authoritative, and RFC 7045 §4 says the two are meant to be in lockstep — so this is an upstream inconsistency, not a judgement call about IANA's intent. RFC 9801's own text supports the omission: §10.1 describes 147 as indicating the payload is an emulated bit-stream, and §5.1.1's pseudocode treats it as an upper-layer header, removing "the outer IPv6 header with all its extension headers". So Y in RFC 9801's Table 1 looks like an error. I found no erratum or IANA note confirming that, so treat the upstream diagnosis as a reading of two conflicting primary sources.
Scope. Point LINK at extension-header.csv and regenerate, which drops BIT_EMU and takes the count to 11. The parser changes too — that CSV's columns are Protocol Number,Description,Reference, so the IPv6 Extension Header == 'Y' filter goes away rather than being retargeted.
Worth checking while there: whether anything depends on BIT_EMU existing, and whether the same wrong-registry pattern appears in any sibling vendor crawler.
Not blocked. No open PR touches these two files. Found while classifying the extension headers for #924's subclassing convention; that PR does not depend on this and should not wait for it.
ExtensionHeaderis generated from the wrong IANA registry, so it carries a member the authoritative list does not have.Measured.
pcapkit/const/ipv6/extension_header.pyhas 12 members:IANA's IPv6 Extension Header Types registry has 11 — the same list without
147 BIT_EMU:Root cause is the source URL.
pcapkit/vendor/ipv6/extension_header.py:57reads:That is the Protocol Numbers registry, filtered on its
IPv6 Extension Headercolumn — a derived signal rather than the registry that defines the set. And the two registries disagree:protocol-numbers-1.csvflags147,BIT-EMU,Bit-stream Emulation,Y,[RFC9801], whileextension-header.csvomits 147 entirely.Which side is right. RFC 8200 §4 makes the extension-header registry authoritative, and RFC 7045 §4 says the two are meant to be in lockstep — so this is an upstream inconsistency, not a judgement call about IANA's intent. RFC 9801's own text supports the omission: §10.1 describes 147 as indicating the payload is an emulated bit-stream, and §5.1.1's pseudocode treats it as an upper-layer header, removing "the outer IPv6 header with all its extension headers". So
Yin RFC 9801's Table 1 looks like an error. I found no erratum or IANA note confirming that, so treat the upstream diagnosis as a reading of two conflicting primary sources.Scope. Point
LINKatextension-header.csvand regenerate, which dropsBIT_EMUand takes the count to 11. The parser changes too — that CSV's columns areProtocol Number,Description,Reference, so theIPv6 Extension Header == 'Y'filter goes away rather than being retargeted.Worth checking while there: whether anything depends on
BIT_EMUexisting, and whether the same wrong-registry pattern appears in any sibling vendor crawler.Not blocked. No open PR touches these two files. Found while classifying the extension headers for #924's subclassing convention; that PR does not depend on this and should not wait for it.