RPL's fixed area is 5 octets where RFC 6554 gives 4, so the header it builds is one octet wider than its own Hdr Ext Len declares. Found while cross-reviewing #561, which unmasked it; filed separately because it is a third, independent defect sitting behind the two that PR addresses.
The mismatch
pcapkit/protocols/schema/internet/ipv6_route.py, the RPL schema, declares the fixed area as three whole-octet fields:
cmpr_i: 'int' = UInt8Field() # 1 octet
cmpr_e: 'int' = UInt8Field() # 1 octet
pad: 'PadInfo' = BitField(length=3, namespace={'pad_len': (0, 4), ...}) # 3 octets
That is 5 octets. RFC 6554 section 3 gives 4, and so does the ASCII diagram in IPv6_Route._read_data_type_rpl's own docstring in pcapkit/protocols/internet/ipv6_route.py:
| CmprI | CmprE | Pad | Reserved |
CmprI 4 bits, CmprE 4 bits, Pad 4 bits, Reserved 20 bits — 32 bits, one 4-octet word. cmpr_i and cmpr_e are nibbles, not octets.
So the module documents the correct layout in prose and implements a different one in the schema.
Consequence
The ipv6-route-type/RPL_Source_Route_Header roundtrip case builds a header that packs to 41 octets while its own Hdr Ext Len of 5 declares 48. Measured during #561's cross-review.
Why it is filed now
#561 fixes RPL.post_process, which used to raise on the pack path before anything downstream could be reached. With that gone, the next failure is the % 16 length guard at pcapkit/protocols/internet/ipv6_route.py:612 — itself a known, deliberately unfixed unit-confusion defect of the same shape #487 fixed for Source Route and Type 2. This octet-width defect sits behind that one, so ipv6-route-type/RPL_Source_Route_Header would remain red even if the % 16 guard were corrected today.
That ordering matters for whoever picks up the guard: fixing % 16 alone will not turn the case green, and without this issue to point at, the reason would not be obvious.
Scope note
Correcting the field widths changes what the schema packs and parses, so it is a wire-format change rather than a cosmetic one, and the Hdr Ext Len arithmetic and the % 16 guard should be reconciled in the same pass rather than separately — the guard cannot be validated against a header whose width is still wrong. Nothing here has been checked against a real RPL capture, which is the same caveat recorded against the guard itself.
Coverage
A test asserting the packed fixed area is 4 octets, and that a built header's length agrees with its declared Hdr Ext Len. Proven to fail without the fix, exit code read from a file.
RPL's fixed area is 5 octets where RFC 6554 gives 4, so the header it builds is one octet wider than its ownHdr Ext Lendeclares. Found while cross-reviewing #561, which unmasked it; filed separately because it is a third, independent defect sitting behind the two that PR addresses.The mismatch
pcapkit/protocols/schema/internet/ipv6_route.py, theRPLschema, declares the fixed area as three whole-octet fields:That is 5 octets. RFC 6554 section 3 gives 4, and so does the ASCII diagram in
IPv6_Route._read_data_type_rpl's own docstring inpcapkit/protocols/internet/ipv6_route.py:CmprI4 bits,CmprE4 bits,Pad4 bits,Reserved20 bits — 32 bits, one 4-octet word.cmpr_iandcmpr_eare nibbles, not octets.So the module documents the correct layout in prose and implements a different one in the schema.
Consequence
The
ipv6-route-type/RPL_Source_Route_Headerroundtrip case builds a header that packs to 41 octets while its ownHdr Ext Lenof 5 declares 48. Measured during #561's cross-review.Why it is filed now
#561 fixes
RPL.post_process, which used to raise on the pack path before anything downstream could be reached. With that gone, the next failure is the% 16length guard atpcapkit/protocols/internet/ipv6_route.py:612— itself a known, deliberately unfixed unit-confusion defect of the same shape #487 fixed for Source Route and Type 2. This octet-width defect sits behind that one, soipv6-route-type/RPL_Source_Route_Headerwould remain red even if the% 16guard were corrected today.That ordering matters for whoever picks up the guard: fixing
% 16alone will not turn the case green, and without this issue to point at, the reason would not be obvious.Scope note
Correcting the field widths changes what the schema packs and parses, so it is a wire-format change rather than a cosmetic one, and the
Hdr Ext Lenarithmetic and the% 16guard should be reconciled in the same pass rather than separately — the guard cannot be validated against a header whose width is still wrong. Nothing here has been checked against a real RPL capture, which is the same caveat recorded against the guard itself.Coverage
A test asserting the packed fixed area is 4 octets, and that a built header's length agrees with its declared
Hdr Ext Len. Proven to fail without the fix, exit code read from a file.