Experimental

RFC 5838 - Support of Address Families in OSPFv3

Every requirement this repository extracted from RFC 5838, 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 ways31.2%5 of 16 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 reason6.2%1 of 16 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 16 gated MUSTs

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

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

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

Proven by a recorded break82.4%14 of 17 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 MUSTs16of 27 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 scope2of 16 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 applicable12.5%2 of 16 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 16 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 16 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 all50.0%8 of 16 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 16 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	Experimental
Enrolment	Enrolled
Requirements	27
Gated MUST-level	16
Not applicable, so out of scope	2
Declared gaps	8
Declared gaps a test demonstrates	0
Gated with no test	0
Nightly-only evidence	0
Test tags	17
Tagged units	17
Recorded audit verdicts	6
Discrimination records	14
Summary	`rfc/short/rfc5838.md`
Requirement shard	`rfc/requirements/rfc5838.md`
RFC text	`rfc/full/rfc5838.txt`

Enrolment

Enrolled: Support of Address Families in OSPFv3 (RFC 5838): 4 MET (non-default-AF AF-bit discard + base-AF ignore, AF-conformance route-computation gate, IPv4 forwarding-address AF-width, global-IPv6 virtual-link endpoints) + 2 single-polarity positive (base-AF no-reject path, IPv4 forwarding-address remaining-bits-zero) + 8 gap (AF-bit not set in LSAs, IPv4 Link-LSA link-local, section 2.7 per-AF MTU / M6-bit machinery) + 2 not-applicable (IPsec restricted to default IPv6-unicast AF, IANA 128-255 Standards-Action process)

What the public ledger says

Status: Experimental

What the ledger says is covered

AF-bit set in Hello/DD Options plus the AF-bit adjacency gate (non-default AF requires it, base IPv6-unicast AF ignores it), the RFC 5838 §2.1 Instance-ID-range to address-family mapping with one per-AF engine owning its LSDB/neighbors/SPF/install-family, IPv4-over-OSPFv3 prefix decode and route build, IPv4 forwarding-address encode/decode for AS-external and NSSA LSAs, and global-IPv6 virtual-link endpoints
requirements gated in rfc/short/rfc5838.md via ./le rfc check.

What the ledger says remains

Eight MUST gaps annotated in rfc/short/rfc5838.md: the AF-bit is not set in originated LSAs (RFC5838-2.2-1); an IPv4-AF Link-LSA carries no IPv4 link-local address (RFC5838-2.5-1); and the RFC 5838 §2.7 per-address-family MTU handling is unimplemented -- no separate AF-versus-IPv6 MTU, no IPv4 interface MTU, and no M6-bit (RFC5838-2.7-1, 2.7-2, 2.7-3, 2.7-4, 2.7-8, 2.7-11). Feature remains under OSPF experimental status.

Coverage

Bucket	Count	What it counts
Positive and negative tests	5	one part of the gated population
Annotated (including scoped evidence)	11	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	16	every gated MUST falls in exactly one bucket above

Positive and negative tests (5): RFC5838-2.3-1, RFC5838-2.4-1, RFC5838-2.6-1, RFC5838-2.6-2, RFC5838-2.8-1

Annotated (including scoped evidence) (11): RFC5838-2.2-1, RFC5838-2.4-2, RFC5838-2.5-1, RFC5838-2.7-1, RFC5838-2.7-2, RFC5838-2.7-3, RFC5838-2.7-4, RFC5838-2.7-8, RFC5838-2.7-11, RFC5838-4-1, RFC5838-5-3

Requirements

Requirement	Level	Section	Tests
`RFC5838-2.2-1`	When an OSPFv3 router is supporting AFs as described in this specification, it MUST set the AF-bit in the OSPFv3 Options field of Hello packets, Database Description packets, and LSAs. (§2.2)
	MUST	2.2	positive`no test`no positive test negative`no test`no negative test {gap}: the AF-bit is set in Hello and DD Options only; LSA origination never sets it -- encoder_v6.go:33 applies SetAF to the Hello/DD path only, and origination_v6.go:254 with origination_v6_link.go:51 build Router/Network/Link-LSA Options via neutralToV6Options, which omits OptAF
`RFC5838-2.3-1`	Prefixes that don't conform to the AF of an OSPFv3 instance MUST NOT be used in the route computation for that instance. (§2.3)
	MUST NOT	2.3	positive`unit/verifyTestIPv4OverV3BuildRoutes` negative`unit/verifyTestRFC5838NonConformingExternalPrefixNotInRouteComputation` negative`unit/verifyTestRFC5838NonConformingInterAreaPrefixNotInRouteComputation` negative`unit/verifyTestRFC5838NonConformingPrefixNotInRouteComputation`
`RFC5838-2.4-1`	When an OSPFv3 router participates in an AF (sets the AF-bit in the Options field), it MUST discard Hello packets having the AF- bit clear in the Options field. (§2.4)
	MUST	2.4	positive`unit/verifyTestAFBitGatesFullNonDefault` negative`unit/verifyTestAFBitGatesFullNonDefault`
`RFC5838-2.4-2`	The only exception is the Base IPv6 unicast AF, where this check MUST NOT be done (for backward compatibility). (§2.4)
	MUST NOT	2.4	positive`unit/verifyTestAFBitIgnoredDefaultAF` negative`no test`no negative test {single-polarity}: the default IPv6-unicast AF has no reject path -- afBitAccepted at multiaf.go:181 returns true immediately for e.af.isDefault, so a base-AF Hello is never dropped for a missing AF-bit and there is no negative behavior to exercise
`RFC5838-2.5-1`	the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero. (§2.5)
	MUST	2.5	positive`no test`no positive test negative`no test`no negative test {gap}: v6OriginateLinkLSA at origination_v6_link.go:42-48 always encodes an IPv6 link-local address in the Link-LSA link-local field and returns false without one, so an IPv4-AF Link-LSA never carries the interface IPv4 address in the leading 32 bits
`RFC5838-2.6-1`	For IPv4 unicast and IPv4 multicast AFs, the Forwarding Address in AS-external-LSAs and NSSA-LSAs MUST encode an IPv4 address. (§2.6)
	MUST	2.6	positive`unit/verifyTestRFC5838IPv4AFNSSAForwardingAddressIsIPv4` positive`unit/verifyTestRFC5838IPv4AFTranslatedForwardingAddressIsIPv4` negative`unit/verifyTestRFC5838IPv4AFNSSANeverEncodesIPv6ForwardingAddress` negative`unit/verifyTestRFC5838IPv4AFTranslatorRefusesIPv6ForwardingAddress`
`RFC5838-2.6-2`	the IPv4 Forwarding Address is advertised by placing it in the first 32 bits of the Forwarding Address field in AS-external-LSAs and NSSA-LSAs. The remaining bits MUST be set to zero. (§2.6)
	MUST	2.6	positive`unit/verifyTestRFC5838IPv4AFNSSAForwardingAddressIsIPv4` positive`unit/verifyTestRFC5838IPv4AFTranslatedForwardingAddressIsIPv4` negative`unit/verifyTestRFC5838IPv4AFTranslatorRefusesNonZeroTrailingBits`
`RFC5838-2.7-1`	For address families other than IPv6, both the MTU for the instance address family and the IPv6 MTU used for OSPFv3 maximum packet determination MUST be considered. (§2.7)
	MUST	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: ze tracks a single per-interface MTU -- neighbor/dd.go:170 sends cfg.InterfaceMTU and neighbor/dd.go:45 checks it -- with no separate address-family MTU versus IPv6 MTU, so the two are not considered independently
`RFC5838-2.7-2`	The MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family. (§2.7)
	MUST	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: the Database Description always carries the single cfg.InterfaceMTU at neighbor/dd.go:170 with no per-address-family MTU, so for a non-IPv6 AF whose MTU differs the DD does not carry the AF-specific MTU
`RFC5838-2.7-3`	For example, if the instance corresponds to an IPv4 address family, the IPv4 MTU for the interface MUST be specified in the interface MTU field. (§2.7)
	MUST	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: ze has no IPv4-address-family interface MTU; the DD MTU is the one configured interface MTU at neighbor/dd.go:170, never an IPv4-specific value
`RFC5838-2.7-4`	The value used for OSPFv3 maximum packet size determination MUST also be compatible for an adjacency to be established. (§2.7)
	MUST	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: the adjacency MTU-compatibility gate at neighbor/dd.go:45 compares the single interface MTU only; ze does not derive an IPv6-MTU-based maximum packet size distinct from the AF MTU per RFC 5838 §2.7
`RFC5838-2.7-8`	If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. (§2.7)
	MUST	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: ze implements no M6-bit -- a grep for m6 across internal/plugins/ospf returns nothing -- so the DD encoder at encoder_v6.go:90 never sets it for a non-IPv6 AF
`RFC5838-2.7-11`	If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Description packet against the receiving interface's IPv6 MTU. (§2.7)
	MUST NOT	2.7	positive`no test`no positive test negative`no test`no negative test {gap}: ze neither sets nor reads the M6-bit and performs only the single-MTU check at neighbor/dd.go:45, so the M6-conditioned suppression of an IPv6-MTU comparison is unimplemented
`RFC5838-2.8-1`	there MUST be a global IPv6 address associated with the virtual link so that OSPFv3 control packets are forwarded correctly by the intermediate hops between virtual link endpoints. (§2.8)
	MUST	2.8	positive`unit/verifyTestV6VirtualEndpointResolvesGlobalAddress` negative`unit/verifyTestRFC5838VirtualLinkRequiresLocalGlobalAddress` negative`unit/verifyTestV6VirtualEndpointRequiresGlobalAddress`
`RFC5838-4-1`	When multiple OSPFv3 instances use the same interface, they all MUST use the same Security Association (SA), since the SA selectors do not provide selection based on data in OSPFv3 Header fields (e.g., the Instance ID). (§4)
	MUST	4	positive`no test`no positive test negative`no test`no negative test {not-applicable}: ze runs OSPFv3 IPsec on the default IPv6-unicast AF only -- validateConfigAF at config.go:907-909 rejects an ipsec block on any non-IPv6 family -- so multiple AF instances never share an interface SA and the requirement's precondition never arises
`RFC5838-5-3`	Instance IDs in the range 128-255 are not assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC including an IANA Considerations section explicitly specifying the AF Instance IDs being assigned. (§5)
	MUST	5	positive`no test`no positive test negative`no test`no negative test {not-applicable}: this binds the IANA registration process, not an implementation; ze has no code path that assigns AF Instance IDs and it rejects Instance IDs above 127 for AF use at multiaf.go:71 and via ErrInstanceIDRange in config.go
`RFC5838-2.5-2`	An implementation SHOULD resolve layer 3 to layer 2 mappings via the Address Resolution Protocol (ARP) [ARP] or Neighbor Discovery (ND) [ND] for a DIA even if the IPv4 address is not on the same subnet as the router's interface IP address. (§2.5)
	SHOULD	2.5	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-5`	If the M6-bit is clear, the specified MTU SHOULD also be checked against the IPv6 MTU (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-6`	If the M6-bit is clear, the specified MTU SHOULD also be checked against the IPv6 MTU, and the Database Description packet SHOULD be rejected if the MTU is larger than the receiving interface's IPv6 MTU. (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-7`	An OSPFv3 router SHOULD NOT set the M6-bit if its IPv6 MTU and address family specific MTU are the same. (§2.7)
	SHOULD NOT	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-9`	If this TLV is present, it carries the IPv6 MTU that SHOULD be compared with the local IPv6 MTU. (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-10`	If this TLV is absent, the minimum IPv6 MTU of 1280 octets SHOULD be used for the comparison (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-12`	The Interface MTU SHOULD be set to 0 in Database Description packets sent over virtual links. (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-14`	Instances subsequent to the first are not processed, and the LLS inconsistency SHOULD be logged. (§2.7)
	SHOULD	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-5-2`	However, if it is being used for address families as described in this specification, the assignments herein SHOULD be honored. (§5)
	SHOULD	5	positive`no test`no positive test negative`no test`no negative test
`RFC5838-2.7-13`	Only one instance of the IPv6 MTU TLV MAY appear in the LLS block. (§2.7)
	MAY	2.7	positive`no test`no positive test negative`no test`no negative test
`RFC5838-5-1`	Note that the Instance ID field MAY be used for applications other than the support of multiple address families. (§5)
	MAY	5	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC5838-2.2-1` When an OSPFv3 router is supporting AFs as described in this specification, it MUST set the AF-bit in the OSPFv3 Options field of Hello packets, Database Description packets, and LSAs. (§2.2)	{gap}, no test	the AF-bit is set in Hello and DD Options only; LSA origination never sets it -- encoder_v6.go:33 applies SetAF to the Hello/DD path only, and origination_v6.go:254 with origination_v6_link.go:51 build Router/Network/Link-LSA Options via neutralToV6Options, which omits OptAF
`RFC5838-2.5-1` the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero. (§2.5)	{gap}, no test	v6OriginateLinkLSA at origination_v6_link.go:42-48 always encodes an IPv6 link-local address in the Link-LSA link-local field and returns false without one, so an IPv4-AF Link-LSA never carries the interface IPv4 address in the leading 32 bits
`RFC5838-2.7-1` For address families other than IPv6, both the MTU for the instance address family and the IPv6 MTU used for OSPFv3 maximum packet determination MUST be considered. (§2.7)	{gap}, no test	ze tracks a single per-interface MTU -- neighbor/dd.go:170 sends cfg.InterfaceMTU and neighbor/dd.go:45 checks it -- with no separate address-family MTU versus IPv6 MTU, so the two are not considered independently
`RFC5838-2.7-2` The MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family. (§2.7)	{gap}, no test	the Database Description always carries the single cfg.InterfaceMTU at neighbor/dd.go:170 with no per-address-family MTU, so for a non-IPv6 AF whose MTU differs the DD does not carry the AF-specific MTU
`RFC5838-2.7-3` For example, if the instance corresponds to an IPv4 address family, the IPv4 MTU for the interface MUST be specified in the interface MTU field. (§2.7)	{gap}, no test	ze has no IPv4-address-family interface MTU; the DD MTU is the one configured interface MTU at neighbor/dd.go:170, never an IPv4-specific value
`RFC5838-2.7-4` The value used for OSPFv3 maximum packet size determination MUST also be compatible for an adjacency to be established. (§2.7)	{gap}, no test	the adjacency MTU-compatibility gate at neighbor/dd.go:45 compares the single interface MTU only; ze does not derive an IPv6-MTU-based maximum packet size distinct from the AF MTU per RFC 5838 §2.7
`RFC5838-2.7-8` If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. (§2.7)	{gap}, no test	ze implements no M6-bit -- a grep for m6 across internal/plugins/ospf returns nothing -- so the DD encoder at encoder_v6.go:90 never sets it for a non-IPv6 AF
`RFC5838-2.7-11` If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Description packet against the receiving interface's IPv6 MTU. (§2.7)	{gap}, no test	ze neither sets nor reads the M6-bit and performs only the single-MTU check at neighbor/dd.go:45, so the M6-conditioned suppression of an IPv6-MTU comparison is unimplemented
`RFC5838-4-1` When multiple OSPFv3 instances use the same interface, they all MUST use the same Security Association (SA), since the SA selectors do not provide selection based on data in OSPFv3 Header fields (e.g., the Instance ID). (§4)	no test	no test carries this requirement id; annotated {not-applicable}: ze runs OSPFv3 IPsec on the default IPv6-unicast AF only -- validateConfigAF at config.go:907-909 rejects an ipsec block on any non-IPv6 family -- so multiple AF instances never share an interface SA and the requirement's precondition never arises
`RFC5838-5-3` Instance IDs in the range 128-255 are not assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC including an IANA Considerations section explicitly specifying the AF Instance IDs being assigned. (§5)	no test	no test carries this requirement id; annotated {not-applicable}: this binds the IANA registration process, not an implementation; ze has no code path that assigns AF Instance IDs and it rejects Instance IDs above 127 for AF use at multiaf.go:71 and via ErrInstanceIDRange in config.go

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.

`RFC5838-2.2-1`

When an OSPFv3 router is supporting AFs as described in this specification, it MUST set the AF-bit in the OSPFv3 Options field of Hello packets, Database Description packets, and LSAs. (§2.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.2-1, so no unit is bound to it.

`RFC5838-2.3-1`

Prefixes that don't conform to the AF of an OSPFv3 instance MUST NOT be used in the route computation for that instance. (§2.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-29 (independent judge, continuation 2). All three route-computation inputs on an IPv4-unicast AF now refuse a non-conforming (64-bit) prefix beside a conforming /24 that proves the reader ran: intra-area (TestRFC5838NonConformingPrefixNotInRouteComputation, v6BuildRoutes), inter-area (TestRFC5838NonConformingInterAreaPrefixNotInRouteComputation, v6SummaryReader yields exactly the /24), and AS-External plus NSSA (TestRFC5838NonConformingExternalPrefixNotInRouteComputation, v6ExternalReader accepts the /24, refuses the 64-bit). Revert records on v6PrefixToNetip, v6SummaryReader and v6ExternalReader. Positive TestIPv4OverV3BuildRoutes is exact but carries no record.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC5838NonConformingExternalPrefixNotInRouteComputation`	unit/verify	revert, verified
negative	`TestRFC5838NonConformingInterAreaPrefixNotInRouteComputation`	unit/verify	revert, verified
negative	`TestRFC5838NonConformingPrefixNotInRouteComputation`	unit/verify	revert, verified
positive	`TestIPv4OverV3BuildRoutes`	unit/verify	revert, verified

`RFC5838-2.4-1`

When an OSPFv3 router participates in an AF (sets the AF-bit in the Options field), it MUST discard Hello packets having the AF- bit clear in the Options field. (§2.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour (a): a non-default-AF instance accepting a Hello with the AF-bit clear. (b) TestAFBitGatesFullNonDefault dispatches that Hello on an IPv4-unicast instance and asserts neighborSnapshot() is empty (a processed Hello would create an Init neighbor), then the same Hello with SetAF() yields one neighbor, isolating the AF-bit as the only difference.

Polarity	Test	Kind and tier	Proof state
negative	`TestAFBitGatesFullNonDefault`	unit/verify	unproven
positive	`TestAFBitGatesFullNonDefault`	unit/verify	unproven

`RFC5838-2.4-2`

The only exception is the Base IPv6 unicast AF, where this check MUST NOT be done (for backward compatibility). (§2.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour (a): the base IPv6-unicast AF discarding a Hello whose AF-bit is clear. (b) TestAFBitIgnoredDefaultAF dispatches an AF-bit-less Hello to the default IPv6-unicast engine and asserts neighborSnapshot() has one row, so an applied AF-bit check goes red. Single-polarity marker holds (the base AF has no reject path).

Polarity	Test	Kind and tier	Proof state
positive	`TestAFBitIgnoredDefaultAF`	unit/verify	unproven

`RFC5838-2.5-1`

the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero. (§2.5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.5-1, so no unit is bound to it.

`RFC5838-2.6-1`

For IPv4 unicast and IPv4 multicast AFs, the Forwarding Address in AS-external-LSAs and NSSA-LSAs MUST encode an IPv4 address. (§2.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-29 (independent judge, continuation 2). Both LSA kinds that can carry an FA on an IPv4 AF are now proven both ways. NSSA-LSA origination: TestRFC5838IPv4AFNSSAForwardingAddressIsIPv4 / TestRFC5838IPv4AFNSSANeverEncodesIPv6ForwardingAddress (records on forwardingAddressForAF). AS-external-LSA: Ze's redistributed Type-5 (v6OriginateExternalLSA) carries no FA, and the translated Type-5 copies the Type-7 FA; TestRFC5838IPv4AFTranslatedForwardingAddressIsIPv4 reads 192.0.2.7 in the translated Type-5 for both IPv4 AFs, TestRFC5838IPv4AFTranslatorRefusesIPv6ForwardingAddress feeds a Type-7 with FA 2001:db8:9::2 and finds no translated Type-5. Producer checked: nssa.go translatableForwardingAddressV6 (D-8 fix) gates the copy on the AF with the RFC 5838 s2.6 quote; revert records on it, observed red.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC5838IPv4AFNSSANeverEncodesIPv6ForwardingAddress`	unit/verify	revert, verified
negative	`TestRFC5838IPv4AFTranslatorRefusesIPv6ForwardingAddress`	unit/verify	revert, verified
positive	`TestRFC5838IPv4AFNSSAForwardingAddressIsIPv4`	unit/verify	revert, verified
positive	`TestRFC5838IPv4AFTranslatedForwardingAddressIsIPv4`	unit/verify	revert, verified

`RFC5838-2.6-2`

the IPv4 Forwarding Address is advertised by placing it in the first 32 bits of the Forwarding Address field in AS-external-LSAs and NSSA-LSAs. The remaining bits MUST be set to zero. (§2.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-29 (independent judge, continuation 2). The {single-polarity} annotation is gone (the translation path could carry non-zero trailing bits, D-8). Positive: the originated NSSA-LSA and the translated AS-external-LSA each read all 16 FA bytes as 192.0.2.7 plus 96 zero bits, both IPv4 AFs. Negative: TestRFC5838IPv4AFTranslatorRefusesNonZeroTrailingBits feeds a Type-7 with 192.0.2.7 and bit 127 set and finds no translated Type-5, isolated (the same FA without the bit translates in the positive). Revert records on forwardingAddressForAF and translatableForwardingAddressV6.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC5838IPv4AFTranslatorRefusesNonZeroTrailingBits`	unit/verify	revert, verified
positive	`TestRFC5838IPv4AFNSSAForwardingAddressIsIPv4`	unit/verify	revert, verified
positive	`TestRFC5838IPv4AFTranslatedForwardingAddressIsIPv4`	unit/verify	revert, verified

`RFC5838-2.7-1`

For address families other than IPv6, both the MTU for the instance address family and the IPv6 MTU used for OSPFv3 maximum packet determination MUST be considered. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-1, so no unit is bound to it.

`RFC5838-2.7-2`

The MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-2, so no unit is bound to it.

`RFC5838-2.7-3`

For example, if the instance corresponds to an IPv4 address family, the IPv4 MTU for the interface MUST be specified in the interface MTU field. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-3, so no unit is bound to it.

`RFC5838-2.7-4`

The value used for OSPFv3 maximum packet size determination MUST also be compatible for an adjacency to be established. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-4, so no unit is bound to it.

`RFC5838-2.7-8`

If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-8, so no unit is bound to it.

`RFC5838-2.7-11`

If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Description packet against the receiving interface's IPv6 MTU. (§2.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-2.7-11, so no unit is bound to it.

`RFC5838-2.8-1`

there MUST be a global IPv6 address associated with the virtual link so that OSPFv3 control packets are forwarded correctly by the intermediate hops between virtual link endpoints. (§2.8)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-29. Positive TestV6VirtualEndpointResolvesGlobalAddress resolves global /128 LA addresses on both ends. Negatives cover both ends: the existing neighbor-side link-local-only case and new TestRFC5838VirtualLinkRequiresLocalGlobalAddress (this router advertises only fe80::1, neighbor global) which fails to resolve. v6ResolveVirtualEndpointLocked requires sok && dok and v6RouterGlobalAddr refuses non-global addresses; revert record on the resolver.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC5838VirtualLinkRequiresLocalGlobalAddress`	unit/verify	revert, verified
negative	`TestV6VirtualEndpointRequiresGlobalAddress`	unit/verify	revert, verified
positive	`TestV6VirtualEndpointResolvesGlobalAddress`	unit/verify	revert, verified

`RFC5838-4-1`

When multiple OSPFv3 instances use the same interface, they all MUST use the same Security Association (SA), since the SA selectors do not provide selection based on data in OSPFv3 Header fields (e.g., the Instance ID). (§4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-4-1, so no unit is bound to it.

`RFC5838-5-3`

Instance IDs in the range 128-255 are not assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC including an IANA Considerations section explicitly specifying the AF Instance IDs being assigned. (§5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC5838-5-3, so no unit is bound to it.

Extraction sign-off

Field	Value
Reviewer	claude
Signed off	2026-09-21
Register	rfc2119
Source	rfc/full/rfc5838.txt
Source fingerprint	1bfe0cda3cd218f9
Record	rfc/extraction/rfc5838.json
Mapped sentences	16
Declined as scope	0
Relocated to a spec, which Ze OWES	0
Unclassified	0

Sections

Section	Name	Sites	Disposition	Reason
`front`	not stated	0	walked	not stated
`1`	not stated	0	walked	not stated
`1.1`	not stated	0	walked	not stated
`1.2`	not stated	0	walked	not stated
`2`	not stated	0	walked	not stated
`2.1`	not stated	0	walked	not stated
`2.2`	not stated	1	walked	not stated
`2.3`	not stated	1	walked	not stated
`2.4`	not stated	2	walked	not stated
`2.5`	not stated	1	walked	not stated
`2.6`	not stated	2	walked	not stated
`2.7`	not stated	6	walked	not stated
`2.8`	not stated	1	walked	not stated
`3`	not stated	0	walked	not stated
`4`	not stated	1	walked	not stated
`5`	not stated	1	walked	not stated
`6`	not stated	0	walked	not stated
`6.1`	not stated	0	walked	not stated
`6.2`	not stated	0	walked	not stated
`A`	not stated	0	walked	not stated

Excluded sentences

The walk over RFC 5838 declined no sentence: every site it found is mapped to a requirement.

Superseded

No document obsoletes RFC 5838, so its obligations are stated where they were written.