Unsupported

RFC 7166 - Supporting Authentication Trailer for OSPFv3

Every requirement this repository extracted from RFC 7166, the tests bound to it, and what a reader has verified about them. This summary is enrolled and gated by ./le rfc check.

Overview

Positive

what Ze has

Tested both ways0.0%0 of 17 gated MUSTs

a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids

One polarity plus reason0.0%0 of 17 gated MUSTs

the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it

One polarity, unexcused0.0%0 of 17 gated MUSTs

one direction is tested, the other is neither tested nor excused, and nothing states which

Partial proof; remaining gap0.0%0 of 17 gated MUSTs

scoped tests exist; the remaining obligation is unmet or unproven, with zero whole-requirement credit

Proven by a recorded break0.0%0 of 0 tagged units

a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed

Neutral

measures that are neither good news nor bad

Gated MUSTs17of 33 this summary declares

MUST-level requirements the gate HOLDS. A population, not a result: the shares beside it are what says how Ze stands

Out of scope0of 17 gated MUSTs

an obligation that does not bind Ze. A {not-applicable} annotation says it never bound; a {feature-declined} annotation says its condition is an optional feature Ze does not offer, and quotes the RFC sentence that makes it optional. Scope, not coverage: it stays in the denominator every share on this page is taken over

Not applicable0.0%0 of 17 gated MUSTs

a {not-applicable} annotation says the obligation does not bind Ze, so no test is owed for it. It stays in the denominator every share here is taken over

Met below Ze0.0%0 of 17 gated MUSTs

a {lower-layer} annotation says a layer under Ze performs the behavior, on state Ze installs into that layer, and names the producer that installs it. The obligation binds Ze and is met; Ze proves none of it, because its own boundary carries no value the behavior reads

Optional feature declined0.0%0 of 17 gated MUSTs

a {feature-declined} annotation says the obligation is conditional on a feature the RFC makes optional and Ze does not offer, and it quotes the sentence that makes it optional. The condition is false, so nothing is owed and nothing is missing. It stays in the denominator every share here is taken over

Negative

what Ze owes

No test at all100.0%17 of 17 gated MUSTs

no test carries the requirement id, whether or not a gap states why

The 8 shares marked as a part above are the whole of the 17 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

How to read the colors

A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.

Card	Tone here	Why that color
Gated MUSTs	neutral	no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total
Out of scope	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Tested both ways	ok	green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got
One polarity plus reason	ok	green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it
One polarity, unexcused	ok	green at zero, RED above it: half a proof with no reason for the other half
Partial proof; remaining gap	ok	green at zero, RED above it: a tested clause cannot prove the whole requirement
No test at all	bad	green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated
Not applicable	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Met below Ze	neutral	no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself
Optional feature declined	neutral	no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit
Proven by a recorded break	ok	green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above
Audit verdicts	warn	RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current

At a glance

Field	Value
Public status	Unsupported
Enrolment	Enrolled
Requirements	33
Gated MUST-level	17
Not applicable, so out of scope	0
Declared gaps	17
Declared gaps a test demonstrates	0
Gated with no test	0
Nightly-only evidence	0
Test tags	0
Tagged units	0
Recorded audit verdicts	0
Discrimination records	0
Summary	`rfc/short/rfc7166.md`
Requirement shard	`rfc/requirements/rfc7166.md`
RFC text	`rfc/full/rfc7166.txt`

Enrolment

Enrolled: Supporting Authentication Trailer for OSPFv3 (RFC 7166): all 17 MUST/MUST NOT are gap -- the OSPFv3 Authentication Trailer is unimplemented (no AT-bit in v3 Options, no SA-ID/64-bit-sequence/HMAC trailer, no IPv6-source-bound digest, no receive-side verification). OSPFv3 ships only transmit checksum-omission hooks; cryptographic auth is the separate OSPFv2 path (RFC 2328/5709/7474). rfc-status row Unsupported; each gap cites its absence producer

What the public ledger says

Status: Unsupported

What the ledger says is covered

None: the OSPFv3 Authentication Trailer wire format is not implemented. OSPFv3 carries only the transmit-side checksum-omission hooks (internal/plugins/ospf/v3/packet/checksum.go, header.go)
an interface authentication key-chain drives the separate OSPFv2 cryptographic path (RFC 2328/5709/7474) through internal/plugins/ospf/packet/auth_verify.go, not an OSPFv3 trailer.

What the ledger says remains

The OSPFv3 Authentication Trailer is absent: no AT-bit in the OSPFv3 Options, no 16-byte trailer (Auth Type / Auth Data Len / SA ID / 64-bit sequence / HMAC), no Security Association, no IPv6-source-bound digest, and no receive-side trailer verification or per-packet-type replay for OSPFv3. All 17 MUST-level requirements are annotated {gap} in rfc/short/rfc7166.md.

Coverage

Bucket	Count	What it counts
Positive and negative tests	0	one part of the gated population
Annotated (including scoped evidence)	17	one part of the gated population
One polarity only	0	one part of the gated population
No test and no annotation	0	one part of the gated population
Partial proof; remaining gap (subset of annotated; zero whole-requirement credit)	0	an overlay: each of these is also counted by the part it falls in
Evidence that runs nightly only	0	an overlay: each of these is also counted by the part it falls in
Derived from other rows	0	outside the gated population: each asserts nothing and derives its state from the rows it names, which the parts above already count
Gated MUST-level requirements	17	every gated MUST falls in exactly one bucket above

Annotated (including scoped evidence) (17): RFC7166-2.1-1, RFC7166-3-3, RFC7166-3-6, RFC7166-4.1-2, RFC7166-4.1-3, RFC7166-4.1-4, RFC7166-4.1-5, RFC7166-4.1.1-1, RFC7166-4.2-3, RFC7166-4.2-4, RFC7166-4.3-1, RFC7166-4.3-4, RFC7166-4.4-1, RFC7166-4.6-1, RFC7166-4.6-3, RFC7166-4.6-5, RFC7166-4.6-6

Requirements

Requirement	Level	Section	Tests
`RFC7166-2.1-1`	OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all the packets on this link will include an Authentication Trailer. (§2.1)
	MUST	2.1 - AT-Bit	positive`no test`no positive test negative`no test`no negative test {gap}: no AT-bit exists in the OSPFv3 Options bitset -- internal/plugins/ospf/v3/types/options.go:14-23 defines only V6/E/N/R/AF, and the Hello/DD encoders internal/plugins/ospf/v3/packet/hello.go:88 and dbdesc.go:73 never set one, so no Authentication Trailer is emitted
`RFC7166-3-3`	When a new key replaces an old key, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. (§3)
	MUST	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test {gap}: ze has no OSPFv3 Security Association carrying the RFC 7166 KeyStartAccept/KeyStartGenerate/KeyStopGenerate/KeyStopAccept lifetimes -- the only key model is the OSPFv2 send-lifetime pair in internal/plugins/ospf/auth_keystore.go:29-32, and validateKeyRollover internal/plugins/ospf/config.go:1007 orders OSPFv2 send-lifetimes only
`RFC7166-3-6`	In the event that the last key associated with an interface expires, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated. (§3)
	MUST NOT	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test {gap}: no OSPFv3 Authentication Trailer is ever produced -- internal/plugins/ospf/auth_wiring.go:28 signPacket appends the OSPFv2 trailer via internal/plugins/ospf/packet/auth_verify.go:157, so there is no OSPFv3 authenticated-transmit path whose key expiry this could govern; the never-revert selection in auth_keystore.go:281-286 is OSPFv2-only
`RFC7166-4.1-2`	This field is reserved. It SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets. (§4.1)
	MUST	4.1 - Authentication Trailer fields	positive`no test`no positive test negative`no test`no negative test {gap}: no OSPFv3 trailer decoder exists -- the only receive-side auth verify internal/plugins/ospf/auth_wiring.go:56 verifyPacket delegates to internal/plugins/ospf/auth_keystore.go:330 which decodes an OSPFv2 common header, so an OSPFv3 trailer Reserved field is never parsed
`RFC7166-4.1-3`	The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. (§4.1)
	MUST	4.1 - Authentication Trailer fields	positive`no test`no positive test negative`no test`no negative test {gap}: the 64-bit ESN counter in internal/plugins/ospf/auth_keystore.go:304-314 feeds the OSPFv2 packet.Sign trailer, not an OSPFv3 trailer; no OSPFv3 Cryptographic Sequence Number field is ever written
`RFC7166-4.1-4`	Upon reception, the sequence number MUST be greater than the sequence number in the last accepted OSPFv3 packet of the same OSPFv3 packet type from the sending OSPFv3 neighbor. (§4.1)
	MUST	4.1 - Authentication Trailer fields	positive`no test`no positive test negative`no test`no negative test {gap}: the per-packet-type strictly-greater replay check internal/plugins/ospf/auth_keystore.go:352-361 runs only inside the OSPFv2 verify path; there is no OSPFv3 trailer receive path to which it applies
`RFC7166-4.1-5`	OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). (§4.1)
	MUST	4.1 - Authentication Trailer fields	positive`no test`no positive test negative`no test`no negative test {gap}: the persisted boot-count mechanism internal/plugins/ospf/auth_keystore.go:115 loadOSPFBootCount seeds the OSPFv2 ESN sequence only; no OSPFv3 trailer sequence is emitted for it to protect
`RFC7166-4.1.1-1`	If by some chance the OSPFv3 router is deployed long enough that there is a possibility that the 64-bit sequence number may wrap, all keys, independent of their key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. (§4.1.1)
	MUST	4.1.1 - Sequence Number Wrap	positive`no test`no positive test negative`no test`no negative test {gap}: no OSPFv3 trailer or its 64-bit sequence exists to wrap -- internal/plugins/ospf/auth_keystore.go:311-314 only bumps bootCount on the OSPFv2 ESN low-word wrap and performs no key reset
`RFC7166-4.2-3`	o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. (§4.2)
	MUST	4.2 - Checksum handling	positive`no test`no positive test negative`no test`no negative test {gap}: the receive path never detects an OSPFv3 Authentication Trailer, so it cannot conditionally omit header-checksum verification; only the transmit-side checksum-omission hook exists at internal/plugins/ospf/v3/packet/checksum.go:165-167 and internal/plugins/ospf/v3/packet/header.go:277-280
`RFC7166-4.2-4`	o For received OSPFv3 packets including an LLS data block and OSPFv3 Authentication Trailer, LLS data block checksum verification MUST be omitted. (§4.2)
	MUST	4.2 - Checksum handling	positive`no test`no positive test negative`no test`no negative test {gap}: the OSPFv3 codec implements no LLS data block -- there is no LLS type under internal/plugins/ospf/v3/packet/ -- and no trailer receive path, so there is no LLS checksum to conditionally omit
`RFC7166-4.3-1`	implementations of this specification MUST include support for at least HMAC-SHA-256 (§4.3)
	MUST	4.3 - Cryptographic Authentication algorithms	positive`no test`no positive test negative`no test`no negative test {gap}: the HMAC-SHA-256 primitive exists only for the OSPFv2 trailer at internal/plugins/ospf/packet/auth_verify.go:69 and :120; no OSPFv3 Authentication Trailer wires any algorithm
`RFC7166-4.3-4`	Implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm. (§4.3)
	MUST	4.3 - Cryptographic Authentication algorithms	positive`no test`no positive test negative`no test`no negative test {gap}: no OSPFv3 trailer means no OSPFv3 default algorithm; the OSPFv2 keychain algorithm is operator-selected per key at internal/plugins/ospf/auth_keystore.go:239-252 with no HMAC-SHA-256 default
`RFC7166-4.4-1`	In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key prior to use. Other protocols using Cryptographic Authentication as specified herein MUST similarly append their respective Cryptographic Protocol IDs to their keys in this step. (§4.4)
	MUST	4.4 - Cryptographic Authentication procedure	positive`no test`no positive test negative`no test`no negative test {gap}: only the OSPFv2 Cryptographic Protocol ID 0x0001 is appended, and only for the OSPFv2 AuType-3 trailer at internal/plugins/ospf/packet/auth_verify.go:38 and :195; there is no OSPFv3 Cryptographic Protocol ID constant or OSPFv3 trailer to apply it to
`RFC7166-4.6-1`	Due to the placement of the AT following the LLS data block and the fact that the LLS data block is included in the Cryptographic Authentication computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS data block to access the AT. (§4.6)
	MUST	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test {gap}: the OSPFv3 codec parses no LLS block, defines no L-bit in internal/plugins/ospf/v3/types/options.go:14-23, and defines no trailer, so it cannot locate an Authentication Trailer past an LLS block
`RFC7166-4.6-3`	If the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 packet MUST be dropped (§4.6)
	MUST	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test {gap}: the seq<=last drop at internal/plugins/ospf/auth_keystore.go:357-359 is reached only via the OSPFv2 verify path; no OSPFv3 trailer receive path exists
`RFC7166-4.6-5`	The calculated data is compared with the received authentication data in the Authentication Trailer. If the two do not match, the packet MUST be discarded (§4.6)
	MUST	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test {gap}: the constant-time digest compare at internal/plugins/ospf/packet/auth_verify.go:242 and :263 verifies the OSPFv2 trailer only; there is no OSPFv3 trailer digest to verify
`RFC7166-4.6-6`	After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for each OSPFv3 packet type received from the neighbor. (§4.6)
	MUST	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test {gap}: the recvSeq high-water store keyed by packet type at internal/plugins/ospf/auth_keystore.go:352-361 records OSPFv2-trailer sequences only; no OSPFv3 trailer sequence is ever received to store
`RFC7166-3-1`	In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate (§3)
	SHOULD	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test
`RFC7166-3-2`	KeyStopGenerate SHOULD be less than KeyStopAccept (§3)
	SHOULD	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test
`RFC7166-3-4`	Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. (§3)
	SHOULD	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test
`RFC7166-3-5`	In the event that the last key associated with an interface expires, the network operator SHOULD be notified (§3)
	SHOULD	3 - OSPFv3 Security Association	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.1-1`	This field is reserved. It SHOULD be set to 0 when sending protocol packets (§4.1)
	SHOULD	4.1 - Authentication Trailer fields	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.2-1`	the OSPFv3 header checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest (§4.2)
	SHOULD	4.2 - Checksum handling	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.2-2`	the OSPFv3 LLS data block checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest (§4.2)
	SHOULD	4.2 - Checksum handling	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.3-2`	SHOULD include support for HMAC-SHA-1 (§4.3)
	SHOULD	4.3 - Cryptographic Authentication algorithms	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.6-2`	It is RECOMMENDED that OSPFv3 routers supporting this specification fully support OSPFv3 Link-Local Signaling (§4.6)
	RECOMMENDED	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.6-4`	If the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. (§4.6)
	SHOULD	4.6 - Packet reception	positive`no test`no positive test negative`no test`no negative test
`RFC7166-5-1`	All OSPFv3 routers participating on a link SHOULD be migrated to OSPFv3 authentication at the same time. (§5)
	SHOULD	5 - Migration	positive`no test`no positive test negative`no test`no negative test
`RFC7166-6-1`	Deployments SHOULD use sufficiently long and random values for the Authentication Key so that guessing and other cryptographic attacks on the key are not feasible in their environments. (§6)
	SHOULD	6 - Security Considerations	positive`no test`no positive test negative`no test`no negative test
`RFC7166-6-2`	it is RECOMMENDED that Authentication Keys incorporate at least 128 pseudorandom bits to minimize the risk of such attacks (§6)
	RECOMMENDED	6 - Security Considerations	positive`no test`no positive test negative`no test`no negative test
`RFC7166-6-3`	management systems SHOULD support hexadecimal input of Authentication Keys (§6)
	SHOULD	6 - Security Considerations	positive`no test`no positive test negative`no test`no negative test
`RFC7166-4.3-3`	MAY also include support for HMAC-SHA-384 and HMAC-SHA-512 (§4.3)
	MAY	4.3 - Cryptographic Authentication algorithms	positive`no test`no positive test negative`no test`no negative test
`RFC7166-5-2`	an OSPFv3 router implementing this specification MAY implement a transition mode where it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets (§5)
	MAY	5 - Migration	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC7166-2.1-1` OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all the packets on this link will include an Authentication Trailer. (§2.1)	{gap}, no test	no AT-bit exists in the OSPFv3 Options bitset -- internal/plugins/ospf/v3/types/options.go:14-23 defines only V6/E/N/R/AF, and the Hello/DD encoders internal/plugins/ospf/v3/packet/hello.go:88 and dbdesc.go:73 never set one, so no Authentication Trailer is emitted
`RFC7166-3-3` When a new key replaces an old key, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. (§3)	{gap}, no test	ze has no OSPFv3 Security Association carrying the RFC 7166 KeyStartAccept/KeyStartGenerate/KeyStopGenerate/KeyStopAccept lifetimes -- the only key model is the OSPFv2 send-lifetime pair in internal/plugins/ospf/auth_keystore.go:29-32, and validateKeyRollover internal/plugins/ospf/config.go:1007 orders OSPFv2 send-lifetimes only
`RFC7166-3-6` In the event that the last key associated with an interface expires, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated. (§3)	{gap}, no test	no OSPFv3 Authentication Trailer is ever produced -- internal/plugins/ospf/auth_wiring.go:28 signPacket appends the OSPFv2 trailer via internal/plugins/ospf/packet/auth_verify.go:157, so there is no OSPFv3 authenticated-transmit path whose key expiry this could govern; the never-revert selection in auth_keystore.go:281-286 is OSPFv2-only
`RFC7166-4.1-2` This field is reserved. It SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets. (§4.1)	{gap}, no test	no OSPFv3 trailer decoder exists -- the only receive-side auth verify internal/plugins/ospf/auth_wiring.go:56 verifyPacket delegates to internal/plugins/ospf/auth_keystore.go:330 which decodes an OSPFv2 common header, so an OSPFv3 trailer Reserved field is never parsed
`RFC7166-4.1-3` The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. (§4.1)	{gap}, no test	the 64-bit ESN counter in internal/plugins/ospf/auth_keystore.go:304-314 feeds the OSPFv2 packet.Sign trailer, not an OSPFv3 trailer; no OSPFv3 Cryptographic Sequence Number field is ever written
`RFC7166-4.1-4` Upon reception, the sequence number MUST be greater than the sequence number in the last accepted OSPFv3 packet of the same OSPFv3 packet type from the sending OSPFv3 neighbor. (§4.1)	{gap}, no test	the per-packet-type strictly-greater replay check internal/plugins/ospf/auth_keystore.go:352-361 runs only inside the OSPFv2 verify path; there is no OSPFv3 trailer receive path to which it applies
`RFC7166-4.1-5` OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). (§4.1)	{gap}, no test	the persisted boot-count mechanism internal/plugins/ospf/auth_keystore.go:115 loadOSPFBootCount seeds the OSPFv2 ESN sequence only; no OSPFv3 trailer sequence is emitted for it to protect
`RFC7166-4.1.1-1` If by some chance the OSPFv3 router is deployed long enough that there is a possibility that the 64-bit sequence number may wrap, all keys, independent of their key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. (§4.1.1)	{gap}, no test	no OSPFv3 trailer or its 64-bit sequence exists to wrap -- internal/plugins/ospf/auth_keystore.go:311-314 only bumps bootCount on the OSPFv2 ESN low-word wrap and performs no key reset
`RFC7166-4.2-3` o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. (§4.2)	{gap}, no test	the receive path never detects an OSPFv3 Authentication Trailer, so it cannot conditionally omit header-checksum verification; only the transmit-side checksum-omission hook exists at internal/plugins/ospf/v3/packet/checksum.go:165-167 and internal/plugins/ospf/v3/packet/header.go:277-280
`RFC7166-4.2-4` o For received OSPFv3 packets including an LLS data block and OSPFv3 Authentication Trailer, LLS data block checksum verification MUST be omitted. (§4.2)	{gap}, no test	the OSPFv3 codec implements no LLS data block -- there is no LLS type under internal/plugins/ospf/v3/packet/ -- and no trailer receive path, so there is no LLS checksum to conditionally omit
`RFC7166-4.3-1` implementations of this specification MUST include support for at least HMAC-SHA-256 (§4.3)	{gap}, no test	the HMAC-SHA-256 primitive exists only for the OSPFv2 trailer at internal/plugins/ospf/packet/auth_verify.go:69 and :120; no OSPFv3 Authentication Trailer wires any algorithm
`RFC7166-4.3-4` Implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm. (§4.3)	{gap}, no test	no OSPFv3 trailer means no OSPFv3 default algorithm; the OSPFv2 keychain algorithm is operator-selected per key at internal/plugins/ospf/auth_keystore.go:239-252 with no HMAC-SHA-256 default
`RFC7166-4.4-1` In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key prior to use. Other protocols using Cryptographic Authentication as specified herein MUST similarly append their respective Cryptographic Protocol IDs to their keys in this step. (§4.4)	{gap}, no test	only the OSPFv2 Cryptographic Protocol ID 0x0001 is appended, and only for the OSPFv2 AuType-3 trailer at internal/plugins/ospf/packet/auth_verify.go:38 and :195; there is no OSPFv3 Cryptographic Protocol ID constant or OSPFv3 trailer to apply it to
`RFC7166-4.6-1` Due to the placement of the AT following the LLS data block and the fact that the LLS data block is included in the Cryptographic Authentication computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS data block to access the AT. (§4.6)	{gap}, no test	the OSPFv3 codec parses no LLS block, defines no L-bit in internal/plugins/ospf/v3/types/options.go:14-23, and defines no trailer, so it cannot locate an Authentication Trailer past an LLS block
`RFC7166-4.6-3` If the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 packet MUST be dropped (§4.6)	{gap}, no test	the seq<=last drop at internal/plugins/ospf/auth_keystore.go:357-359 is reached only via the OSPFv2 verify path; no OSPFv3 trailer receive path exists
`RFC7166-4.6-5` The calculated data is compared with the received authentication data in the Authentication Trailer. If the two do not match, the packet MUST be discarded (§4.6)	{gap}, no test	the constant-time digest compare at internal/plugins/ospf/packet/auth_verify.go:242 and :263 verifies the OSPFv2 trailer only; there is no OSPFv3 trailer digest to verify
`RFC7166-4.6-6` After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for each OSPFv3 packet type received from the neighbor. (§4.6)	{gap}, no test	the recvSeq high-water store keyed by packet type at internal/plugins/ospf/auth_keystore.go:352-361 records OSPFv2-trailer sequences only; no OSPFv3 trailer sequence is ever received to store

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

`RFC7166-2.1-1`

OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all the packets on this link will include an Authentication Trailer. (§2.1)