Partial

RFC 5798 - Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Every requirement this repository extracted from RFC 5798, 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 ways72.9%43 of 59 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.8%4 of 59 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 59 gated MUSTs

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

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

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

Proven by a recorded break98.0%144 of 147 tagged units, 0 escaped and 2 lapsed

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 MUSTs59of 85 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 59 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 59 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 Ze5.1%3 of 59 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 declined3.4%2 of 59 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 all11.9%7 of 59 gated MUSTs

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

Audit verdicts47of 59 gated MUSTs judged

1 weak, wrong or unimplemented, 0 no longer current. Each is named below under its own requirement id

The 8 shares marked as a part above are the whole of the 59 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	bad	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	Partial
Enrolment	Enrolled
Requirements	85
Gated MUST-level	59
Not applicable, so out of scope	0
Declared gaps	7
Declared gaps a test demonstrates	0
Gated with no test	0
Nightly-only evidence	0
Test tags	147
Tagged units	147
Recorded audit verdicts	47
Discrimination records	146
Summary	`rfc/short/rfc5798.md`
Requirement shard	`rfc/requirements/rfc5798.md`
RFC text	`rfc/full/rfc5798.txt`

Enrolment

Enrolled: VRRP Version 3 for IPv4 and IPv6 (RFC 5798, obsoleted by RFC 9568): the VRRPv3 document ze speaks on the IPv4 wire only in a group configured `checksum rfc5798-compatible`; a default group speaks RFC 9568. Every one of its 59 gated requirements carries a {superseded} marker naming where the obligation lives in RFC 9568, and 55 of them are restated there unchanged, so ze implements them through the same producers rfc/short/rfc9568.md gates: internal/plugins/vrrp/packet (advert encode/decode, checksum), internal/plugins/vrrp/fsm (Initialize/Backup/Master), internal/plugins/vrrp/transport (proto 112, GTSM, GARP/NA). The row that is NOT a restatement is RFC5798-5.2.8-1: Section 5.2.8 puts a pseudo-header under the checksum for both families, RFC 9568 Section 5.2.8 removes it for IPv4, and ze transmits this document form only in a group configured `checksum rfc5798-compatible`, because keepalived and the pre-RFC-9568 base require it (pseudoSumV4 and FillChecksum, internal/plugins/vrrp/packet/checksum.go). Tagged under RFC5798 ids: 43 of the 59 gated MUSTs carry a positive and a negative test, 4 carry a positive test and a `{single-polarity}` annotation because the producer writes a constant no input changes, 3 are met below ze by the Linux forwarding and SLAAC paths, 2 are conditional on an optional feature ze declined, and 7 are `{gap}` rows ze owes.

What the public ledger says

Status: Partial

What the ledger says is covered

For IPv4, ze transmits the RFC 5798 pseudo-header checksum form only with checksum rfc5798-compatible, because that is what keepalived (proven on the wire: its own adverts use it) and the rest of the deployed base compute and require
a message-only advert is rejected by them as "Invalid VRRPv3 checksum". On receive, a group so configured accepts only this form, and a default group sends and accepts only the RFC 9568 message-only form.

What the ledger says remains

RFC 9568 Section 5.2.8 clarifies the IPv4 checksum as message-only (no pseudo-header), and that is what a ze VRRPv3 IPv4 group sends and accepts by default. A group configured checksum rfc5798-compatible sends and accepts only the RFC 5798 pseudo-header form instead, which keepalived and the pre-RFC 9568 deployed base require.

Enrolled 2026-09-01: rfc/short/rfc5798.md declares 85 requirements, 59 of them MUST-level, and every one carries a {superseded} marker naming where RFC 9568 states it. 43 of those 59 are proven under RFC5798 ids in both polarities. 4 carry a positive test and a {single-polarity} annotation, because the producer writes a constant no input changes: RFC5798-5.1.1.3-1, RFC5798-5.1.2.3-1, RFC5798-7.2-2 and RFC5798-7.2-4. RFC5798-5.1.2.3-1 is the weakest of those four, because its only evidence is an integration-gated test the privileged QEMU suite runs and ./le rfc discriminate-record cannot reach. 3 are met below ze and carry a {lower-layer} annotation: RFC5798-5.1.1.2-1 and RFC5798-5.1.2.2-1, where Linux consumes a link-local scope multicast datagram rather than forwarding it, and RFC5798-7.4-1, where Linux derives each device's Interface Identifier. 2 are conditional on an optional feature ze declined and carry a {feature-declined} annotation: RFC5798-8.4.2-1, the VRRPv2/VRRPv3 dual-send flag RFC 5798 Section 8.4.2 makes a MAY, and RFC5798-A.2-1, the Token Ring functional-address mode. 7 are {gap} rows ze owes: RFC5798-6.4.3-4 and RFC5798-8.2.3-1 (no ND Router Advertisement is sent for a virtual router, so there is no option set to configure either), RFC5798-7.4-2 (the virtual-MAC macvlan carries no addr_gen_mode, so Linux derives its link-local Interface Identifier from the virtual router MAC), RFC5798-8.1.3-1 (a proxy ARP reply on a VRRP router does not carry the virtual router MAC), RFC5798-8.2.2-2 and RFC5798-8.2.2-3 (ze authors no Neighbor Solicitation for a host and installs nothing that sources one from the virtual MAC), and RFC5798-7.1-3, where Section 7.1 makes the receiver discard an advertisement when the local router is the IPvX address owner and Decode (internal/plugins/vrrp/packet/validate.go) verifies only the VRID half, because RFC 9568 erratum 8298 lowers the address-owner half to a log. One RFC 5798 obligation is NOT a restatement: RFC5798-5.2.8-1 puts a pseudo-header under the checksum for both address families, which ze computes for IPv4 only in a group configured checksum rfc5798-compatible. RFC 5798 Section 5.2.8 cites the pseudo-header "as defined in Section 8.1 of [RFC2460]", an IPv6-only shape, so what ze and the deployed base compute for IPv4 is the classic IPv4 pseudo-header (pseudoSumV4, internal/plugins/vrrp/packet/checksum.go) rather than the shape that sentence names.

Coverage

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

Positive and negative tests (43): RFC5798-5.1.1.3-2, RFC5798-5.1.2.3-2, RFC5798-5.2.2-1, RFC5798-5.2.4-1, RFC5798-5.2.4-2, RFC5798-5.2.6-1, RFC5798-5.2.8-1, RFC5798-5.2.9-1, RFC5798-5.2.9-2, RFC5798-6.1-1, RFC5798-6.4.2-1, RFC5798-6.4.2-2, RFC5798-6.4.2-3, RFC5798-6.4.2-4, RFC5798-6.4.2-5, RFC5798-6.4.2-6, RFC5798-6.4.2-7, RFC5798-6.4.2-8, RFC5798-6.4.2-9, RFC5798-6.4.2-10, RFC5798-6.4.3-1, RFC5798-6.4.3-2, RFC5798-6.4.3-3, RFC5798-6.4.3-5, RFC5798-6.4.3-6, RFC5798-6.4.3-7, RFC5798-6.4.3-8, RFC5798-6.4.3-9, RFC5798-6.4.3-10, RFC5798-6.4.3-11, RFC5798-6.4.3-12, RFC5798-7.1-1, RFC5798-7.1-2, RFC5798-7.1-4, RFC5798-7.2-1, RFC5798-7.2-3, RFC5798-8.1.2-1, RFC5798-8.1.2-6, RFC5798-8.1.1-2, RFC5798-8.2.1-2, RFC5798-8.2.2-1, RFC5798-8.2.2-8, RFC5798-8.2.2-4

Annotated (including scoped evidence) (16): RFC5798-5.1.1.2-1, RFC5798-5.1.1.3-1, RFC5798-5.1.2.2-1, RFC5798-5.1.2.3-1, RFC5798-6.4.3-4, RFC5798-7.1-3, RFC5798-7.2-2, RFC5798-7.2-4, RFC5798-7.4-1, RFC5798-7.4-2, RFC5798-8.1.3-1, RFC5798-8.2.2-2, RFC5798-8.2.2-3, RFC5798-8.2.3-1, RFC5798-8.4.2-1, RFC5798-A.2-1

Requirements

Requirement	Level	Section	Tests
`RFC5798-5.1.1.2-1`	The IPv4 multicast address as assigned by the IANA for VRRP is: 224.0.0.18 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its TTL. (§5.1.1.2)
	MUST NOT	5.1.1.2	positive`no test`no positive test negative`no test`no negative test {lower-layer}: Linux forwarding plane; internal/plugins/fib/kernel/backend_linux.go::addRoute writes every route ze puts into the kernel FIB and it writes unicast next hops only, ze enables no multicast routing anywhere, and Linux consumes a datagram addressed to the 224.0.0.0/24 link-local scope group on its own input path instead of forwarding it, so no state ze installs decides this
`RFC5798-5.1.1.3-1`	The TTL MUST be set to 255. (§5.1.1.3)
	MUST	5.1.1.3	positive`unit/verifyTestSendAdvertV3IPv4HeaderTTLProtoDst` negative`no test`no negative test {single-polarity}: buildIPv4Header internal/plugins/vrrp/transport/transport.go writes the literal 255 into the TTL octet of every advertisement header it builds, so no configuration reaches another value; discarding a received TTL that is not 255 is the separate RFC5798-5.1.1.3-2
`RFC5798-5.1.1.3-2`	A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet. (§5.1.1.3, §7.1)
	MUST	5.1.1.3	positive`unit/verifyTestDecodeGoldenV3IPv4` negative`unit/verifyTestNegativeReferenceBugs`
`RFC5798-5.1.2.2-1`	The IPv6 multicast address assigned by the IANA for VRRP is: FF02:0:0:0:0:0:0:12 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its Hop Limit. (§5.1.2.2)
	MUST NOT	5.1.2.2	positive`no test`no positive test negative`no test`no negative test {lower-layer}: Linux forwarding plane; internal/plugins/fib/kernel/backend_linux.go::addRoute writes every route ze puts into the kernel FIB, ze enables no IPv6 multicast routing anywhere, and Linux consumes a datagram addressed to the ff02::/16 link-local scope group on its own input path instead of forwarding it, so no state ze installs decides this
`RFC5798-5.1.2.3-1`	The Hop Limit MUST be set to 255. (§5.1.2.3)
	MUST	5.1.2.3	positive`unit/verifyTestIntegrationOpenInstanceSocketOptions` negative`no test`no negative test {single-polarity}: the hop limit is a socket option, IPV6_MULTICAST_HOPS 255 set once in openV6 internal/plugins/vrrp/transport/backend_linux.go, so every advertisement leaving that socket carries 255 and no configuration reaches another value; discarding a received hop limit that is not 255 is the separate RFC5798-5.1.2.3-2. The one positive test is internal/plugins/vrrp/transport/transport_integration_linux_test.go, gated //go:build integration && linux and skipped without CAP_NET_RAW and CAP_NET_ADMIN, so it runs under the privileged QEMU suite and on an unprivileged host this requirement is proven by nothing
`RFC5798-5.1.2.3-2`	A VRRP router receiving a packet with the Hop Limit not equal to 255 MUST discard the packet. (§5.1.2.3, §7.1)
	MUST	5.1.2.3	positive`unit/verifyTestDecodeGoldenV3IPv6` negative`unit/verifyTestDecodeV3IPv6ChecksumAndHopLimit`
`RFC5798-5.2.2-1`	The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded. (§5.2.2)
	MUST	5.2.2	positive`unit/verifyTestDecodeGoldenV3IPv4` negative`unit/verifyTestValidationOrder`
`RFC5798-5.2.4-1`	The priority value for the VRRP router that owns the IPvX address associated with the virtual router MUST be 255 (decimal). (§5.2.4)
	MUST	5.2.4	positive`unit/verifyTestOwnerAutoDetection` negative`unit/verifyTestOwnerAutoDetection`
`RFC5798-5.2.4-2`	VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). (§5.2.4)
	MUST	5.2.4	positive`unit/verifyTestBoundaryPriority` positive`unit/verifyTestEffectivePriorityWithTracking` negative`unit/verifyTestBoundaryPriority`
`RFC5798-5.2.6-1`	This field MUST be set to zero on transmission and ignored on reception. (§5.2.6)
	MUST	5.2.6	positive`unit/verifyTestEncodeGoldenV3IPv4` positive`unit/verifyTestEncodeV3ReserveZeroOverDirtyBuffer` negative`unit/verifyTestDecodeV3ReserveIgnoredOnReceive`
`RFC5798-5.2.8-1`	The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field is set to zero. (§5.2.8, §7.1)
	MUST	5.2.8	positive`unit/verifyTestFillChecksumFamilies` positive`unit/verifyTestFillChecksumZeroesFieldAndCoversPseudoHeader` negative`unit/verifyTestDecodeV3IPv6ChecksumAndHopLimit` negative`unit/verifyTestFillChecksumZeroesFieldAndCoversPseudoHeader`
`RFC5798-5.2.9-1`	For IPv6, the first address must be the IPv6 link-local address associated with the virtual router. (§5.2.9, §6.1; lowercase "must" in the RFC)
	MUST	5.2.9	positive`unit/verifyTestAdvertParamsIPv6LeadWithLinkLocal` positive`unit/verifyTestSendAdvertIPv6LeadsWithLinkLocal` positive`unit/verifyTestValidateIPv6LinkLocal` negative`unit/verifyTestValidateIPv6LinkLocal`
`RFC5798-5.2.9-2`	This field contains either one or more IPv4 addresses, or one or more IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in one IPvX Address field. (§5.2.9)
	MUST NOT	5.2.9	positive`unit/verifyTestValidateVIPFamilyMatchesGroupFamily` negative`unit/verifyTestValidateVIPFamilyMatchesGroupFamily`
`RFC5798-6.1-1`	Note: IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped when Accept_Mode is False. (§6.1, §6.4.3)
	MUST NOT	6.1	positive`unit/verifyTestAcceptFilterAcceptsNeighborDiscoveryBeforeAnyDrop` negative`unit/verifyTestAcceptFilterAcceptsNeighborDiscoveryBeforeAnyDrop`
`RFC5798-6.4.2-1`	(310) + MUST NOT respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceStartupNonOwnerGoesBackup` negative`unit/verifyTestInstanceOwnerStartupGoesMaster`
`RFC5798-6.4.2-2`	(320) + MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 address(es) associated with the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice` negative`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice`
`RFC5798-6.4.2-3`	(325) + MUST NOT send ND Router Advertisement messages for the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceBackupSendsNoRouterAdvertisement` negative`unit/verifyTestInstanceBackupSendsNoRouterAdvertisement`
`RFC5798-6.4.2-4`	(335) - MUST discard packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestBackupDiscardFollowsTheState` positive`unit/verifyTestVRRPBackupDoesNotForwardVirtualMACFrames` negative`unit/verifyTestBackupDiscardFollowsTheState` negative`unit/verifyTestVRRPBackupDoesNotForwardVirtualMACFrames`
`RFC5798-6.4.2-5`	(340) - MUST NOT accept packets addressed to the IPvX address(es) associated with the virtual router. (§6.4.2)
	MUST NOT	6.4.2	positive`unit/verifyTestInstanceStartupNonOwnerGoesBackup` negative`unit/verifyTestInstanceOwnerStartupGoesMaster`
`RFC5798-6.4.2-6`	If a Shutdown event is received, then: (350) + Cancel the Master_Down_Timer (355) + Transition to the {Initialize} state (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-6.4.2-7`	If the Master_Down_Timer fires, then: (370) + Send an ADVERTISEMENT (375) + If the protected IPvX address is an IPv4 address, then: (380) * Broadcast a gratuitous ARP request on that interface containing the virtual router MAC address for each IPv4 address associated with the virtual router. (385) + else // ipv6 (390) * Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) associated with the virtual router. (395) * For each IPv6 address associated with the virtual router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the target address set to the IPv6 address of the virtual router, and the target link-layer address set to the virtual router MAC address. (400) +endif // was protected addr ipv4? (405) + Set the Adver_Timer to Advertisement_Interval (410) + Transition to the {Master} state (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestAnnounceMasterFramesPerAddress` positive`unit/verifyTestFSMMasterDownPromotion` positive`unit/verifyTestPromotionInstallsIPv6AddressesOnVirtualMACDevice` positive`unit/verifyTestPromotionSetsAdverTimerToOwnInterval` negative`unit/verifyTestFSMStaleTimerGenerationIgnored`
`RFC5798-6.4.2-8`	If the Priority in the ADVERTISEMENT is zero, then: (430) * Set the Master_Down_Timer to Skew_Time (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-6.4.2-9`	If Preempt_Mode is False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: (450) @ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (455) @ Recompute the Master_Down_Interval (460) @ Reset the Master_Down_Timer to Master_Down_Interval (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestV3BackupAdoptsIntervalOrDiscards` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestV3BackupAdoptsIntervalOrDiscards`
`RFC5798-6.4.2-10`	else // preempt was true or priority was less (470) @ Discard the ADVERTISEMENT (§6.4.2)
	MUST	6.4.2	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-6.4.3-1`	(610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.3, §8.1.2)
	MUST	6.4.3	positive`unit/verifyTestDataplaneApplyIPv4SetsRecipe` positive`unit/verifyTestPromotionInstallsIPv4AddressOnVirtualMACDevice` positive`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` negative`unit/verifyTestDataplaneRestoreOnLastGroup` negative`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`
`RFC5798-6.4.3-2`	(620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router. (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice` negative`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice`
`RFC5798-6.4.3-3`	(625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router. (§6.4.3, §8.2.2)
	MUST	6.4.3	positive`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice` negative`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice`
`RFC5798-6.4.3-4`	(630) ++ MUST send ND Router Advertisements for the virtual router. (§6.4.3)
	MUST	6.4.3	positive`no test`no positive test negative`no test`no negative test {gap}: ze runs IPv6 virtual routers and sends no Router Advertisement for them. The announcer's only IPv6 frame is the unsolicited Neighbor Advertisement, icmpv6TypeNA 136, built by BuildNA internal/plugins/vrrp/transport/na.go and selected by frameBuilder internal/plugins/vrrp/transport/transport.go, and no Router Advertisement builder and no RA send path exists under internal/plugins/vrrp
`RFC5798-6.4.3-5`	(645) - MUST forward packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestBackupDiscardFollowsTheState` positive`unit/verifyTestVRRPBackupDoesNotForwardVirtualMACFrames` negative`unit/verifyTestBackupDiscardFollowsTheState` negative`unit/verifyTestVRRPBackupDoesNotForwardVirtualMACFrames`
`RFC5798-6.4.3-6`	(650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestActiveAddressOwnerAcceptsWhateverAcceptModeSays` positive`unit/verifyTestActiveNonOwnerWithAcceptModeTrueAcceptsLocalDelivery` negative`unit/verifyTestActiveNonOwnerWithAcceptModeFalseSuppressesLocalDelivery`
`RFC5798-6.4.3-7`	MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets. (§6.4.3)
	MUST NOT	6.4.3	positive`unit/verifyTestActiveNonOwnerWithAcceptModeFalseSuppressesLocalDelivery` negative`unit/verifyTestActiveAddressOwnerAcceptsWhateverAcceptModeSays` negative`unit/verifyTestActiveNonOwnerWithAcceptModeTrueAcceptsLocalDelivery`
`RFC5798-6.4.3-8`	If a Shutdown event is received, then: (660) + Cancel the Adver_Timer (665) + Send an ADVERTISEMENT with Priority = 0 (670) + Transition to the {Initialize} state (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-6.4.3-9`	If the Adver_Timer fires, then: (685) + Send an ADVERTISEMENT (690) + Reset the Adver_Timer to Advertisement_Interval (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMStaleTimerGenerationIgnored`
`RFC5798-6.4.3-10`	If the Priority in the ADVERTISEMENT is zero, then: (710) -* Send an ADVERTISEMENT (715) -* Reset the Adver_Timer to Advertisement_Interval (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-6.4.3-11`	If the Priority in the ADVERTISEMENT is greater than the local Priority, (730) -* or (735) -* If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IPvX Address of the sender is greater than the local primary IPvX Address, then: (740) -@ Cancel Adver_Timer (745) -@ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (750) -@ Recompute the Skew_Time (755) @ Recompute the Master_Down_Interval (760) @ Set Master_Down_Timer to Master_Down_Interval (765) @ Transition to the {Backup} state (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` positive`unit/verifyTestInstanceIPv6ElectionUsesUnsignedOrder` positive`unit/verifyTestInstanceTieBreakComparesTheAdvertisementSource` negative`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestInstanceIPv6ElectionUsesUnsignedOrder` negative`unit/verifyTestInstanceTieBreakComparesTheAdvertisementSource`
`RFC5798-6.4.3-12`	else // new Master logic (775) @ Discard ADVERTISEMENT (§6.4.3)
	MUST	6.4.3	positive`unit/verifyTestFSMTransitionMatrix` negative`unit/verifyTestFSMTransitionMatrix`
`RFC5798-7.1-1`	- MUST verify that the VRRP version is 3. (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV3IPv4` negative`unit/verifyTestNegativeReferenceBugs`
`RFC5798-7.1-2`	- MUST verify that the received packet contains the complete VRRP packet (including fixed fields, and IPvX address). (§7.1)
	MUST	7.1	positive`unit/verifyTestDecodeGoldenV3IPv4` positive`unit/verifyTestDecodeV3DiscardsIncompletePacket` negative`unit/verifyTestDecodeV3DiscardsIncompletePacket` negative`unit/verifyTestNegativeReferenceBugs`
`RFC5798-7.1-3`	- MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). (§7.1)
	MUST	7.1	positive`no test`no positive test negative`no test`no negative test {gap}: Decode internal/plugins/vrrp/packet/validate.go verifies the VRID half of this check and ze implements no address-owner half, so an advertisement arriving for a VRID whose address the local router owns is processed rather than discarded. RFC 9568 erratum 8298 lowers that half to a SHOULD that logs and ze follows the successor, so the RFC 5798 MUST as published is unmet
`RFC5798-7.1-4`	If any one of the above checks fails, the receiver MUST discard the packet (§7.1)
	MUST	7.1	positive`unit/verifyTestInstanceRxFailedCheckIsDiscarded` positive`unit/verifyTestInstanceRxValidAdvertReachesFSM` negative`unit/verifyTestInstanceRxDecodeErrorMapsReason` negative`unit/verifyTestInstanceRxFailedCheckIsDiscarded`
`RFC5798-7.2-1`	The following operations MUST be performed when transmitting a VRRP packet: - Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum (§7.2)
	MUST	7.2	positive`unit/verifyTestEncodeGoldenV3IPv4` positive`unit/verifyTestSendAdvertFillsFieldsAndChecksum` positive`unit/verifyTestTransmittedAdvertFilledFromInstanceState` negative`unit/verifyTestBoundaryInterval`
`RFC5798-7.2-2`	If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual router MAC Address (§7.2)
	MUST	7.2	positive`unit/verifyTestConstants` positive`unit/verifyTestTxAdvertV4OnWire` positive`unit/verifyTestTxAdvertV6OnWire` negative`no test`no negative test {single-polarity}: the source link-layer address is the virtual router MAC that packet.VirtualMAC internal/plugins/vrrp/packet/packet.go derives from the family and the VRID, put on the wire by binding the tx socket to the macvlan created with that address (openV4 and openV6 internal/plugins/vrrp/transport/backend_linux.go), a derivation no input can make yield another MAC
`RFC5798-7.2-3`	If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual router MAC Address + Set the source IPv6 address to interface link-local IPv6 address (§7.2)
	MUST	7.2	positive`unit/verifyTestSendAdvertUsesParentPrimaryV4Source` positive`unit/verifyTestTxAdvertV4OnWire` positive`unit/verifyTestTxAdvertV6OnWire` negative`unit/verifyTestSendAdvertNoLinkLocalSkipsAndCounts` negative`unit/verifyTestSendAdvertNoPrimaryV4SkipsAndCounts`
`RFC5798-7.2-4`	Set the IPvX protocol to VRRP - Send the VRRP packet to the VRRP IPvX multicast group (§7.2)
	MUST	7.2	positive`unit/verifyTestSendAdvertV3IPv4HeaderTTLProtoDst` positive`unit/verifyTestTxAdvertV4OnWire` positive`unit/verifyTestTxAdvertV6OnWire` negative`no test`no negative test {single-polarity}: buildIPv4Header internal/plugins/vrrp/transport/transport.go writes the constant packet.ProtoNumber into the protocol octet and SendAdvert internal/plugins/vrrp/transport/backend_linux.go targets the constants packet.MulticastV4 and packet.MulticastV6, so no configuration reaches another protocol number or another destination
`RFC5798-7.4-1`	IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet Networks" [RFC2464]). (§7.4)
	MUST	7.4	positive`no test`no positive test negative`no test`no negative test {lower-layer}: Linux SLAAC; internal/plugins/vrrp/dataplane_linux.go::applyDataplaneSysctls is the only IPv6 state ze writes on a VRRP device and it writes accept_dad alone, while Linux derives each device's Interface Identifier from that device's MAC in the RFC 2464 manner this sentence names, so no value ze writes decides the derivation
`RFC5798-7.4-2`	They MUST NOT use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers. (§7.4)
	MUST NOT	7.4	positive`no test`no positive test negative`no test`no negative test {gap}: ze creates the per-group macvlan carrying the virtual router MAC and writes no addr_gen_mode on it, because applyDataplaneSysctls internal/plugins/vrrp/dataplane_linux.go writes accept_dad and nothing else on an IPv6 group, so Linux derives that device's link-local Interface Identifier from the virtual router MAC, which is the derivation this sentence forbids. Suppressing it, by writing addr_gen_mode on the IPv6 macvlan, is unbuilt
`RFC5798-8.1.2-1`	The Virtual Router Master MUST NOT respond with its physical MAC address in the ARP response. (§8.1.2)
	MUST NOT	8.1.2	positive`unit/verifyTestDataplaneApplyIPv4SetsRecipe` positive`unit/verifyTestOwnerFilterWiredOnPromotionForEveryFamily` positive`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` positive`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly` negative`unit/verifyTestDataplaneRestoreOnLastGroup` negative`unit/verifyTestOwnerFilterWiredOnPromotionForEveryFamily` negative`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` negative`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly`
`RFC5798-8.1.2-6`	When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router. (§8.1.2)
	MUST	8.1.2	positive`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` positive`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly` negative`unit/verifyTestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly` negative`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly`
`RFC5798-8.1.1-2`	If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. (§8.1.1; lowercase "must" in the RFC)
	MUST	8.1.1	positive`unit/verifyTestVRRPRedirectSourceFollowsVirtualMAC` negative`unit/verifyTestVRRPRedirectSourceFollowsVirtualMAC`
`RFC5798-8.2.1-2`	If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. (§8.2.1; lowercase "must" in the RFC)
	MUST	8.2.1	positive`unit/verifyTestVRRPIPv6RedirectFollowsVirtualMAC` negative`unit/verifyTestVRRPIPv6RedirectFollowsVirtualMAC`
`RFC5798-8.1.3-1`	If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the virtual router MAC address in the Proxy ARP message. (§8.1.3; lowercase "must" in the RFC)
	MUST	8.1.3	positive`no test`no positive test negative`no test`no negative test {gap}: ze offers proxy ARP, as the builtin proxy sysctl profile that writes net.ipv4.conf.<iface>.proxy_arp=1 internal/core/sysctl/profiles.go, and nothing makes a proxy ARP reply on a VRRP router carry the virtual router MAC: the kernel answers from the replying device's own address and ze installs no virtual-MAC proxy state, so the obligation is unbuilt rather than out of reach
`RFC5798-8.2.2-1`	The Virtual Router Master MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router. (§8.2.2)
	MUST NOT	8.2.2	positive`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice` positive`unit/verifyTestOwnerFilterWiredOnPromotionForEveryFamily` positive`unit/verifyTestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly` positive`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly` negative`unit/verifyTestInstanceIPv6VIPLivesOnVirtualMACDevice` negative`unit/verifyTestOwnerFilterWiredOnPromotionForEveryFamily` negative`unit/verifyTestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly` negative`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly`
`RFC5798-8.2.2-8`	When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Virtual Router Master MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router. (§8.2.2)
	MUST	8.2.2	positive`unit/verifyTestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly` positive`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly` negative`unit/verifyTestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly` negative`unit/verifyTestVRRPOwnerAnswersWithVirtualMACOnly`
`RFC5798-8.2.2-2`	When a Virtual Router Master sends an ND Neighbor Solicitation message for a host's IPv6 address, the Virtual Router Master MUST include the virtual MAC address for the virtual router if it sends a source link-layer address option in the neighbor solicitation message. (§8.2.2)
	MUST	8.2.2	positive`no test`no positive test negative`no test`no negative test {gap}: ze authors no Neighbor Solicitation -- the plugin's only ICMPv6 builder is BuildNA, type 136, internal/plugins/vrrp/transport/na.go -- and it installs nothing that makes a host solicitation source from the virtual-MAC macvlan, which doInstallVIPs internal/plugins/vrrp/instance.go gives the virtual address alone. The solicitation a Master sends for a host therefore leaves the parent, carrying the parent's own link-layer address
`RFC5798-8.2.2-3`	It MUST NOT use its physical MAC address in the source link-layer address option. (§8.2.2)
	MUST NOT	8.2.2	positive`no test`no positive test negative`no test`no negative test {gap}: the same unbuilt path as RFC5798-8.2.2-2. Ze authors no Neighbor Solicitation and installs nothing that keeps the physical MAC out of the source link-layer address option of one its stack sends for a host
`RFC5798-8.2.2-4`	o At system boot, when initializing interfaces for VRRP operation, all ND Router and Neighbor Advertisements and Solicitation messages must be delayed until both the IPv6 address and the virtual router MAC address are configured. (§8.2.2; lowercase "must" in the RFC)
	MUST	8.2.2	positive`unit/verifyTestEngineAnnouncesNothingBeforeTheVirtualMACDevice` positive`unit/verifyTestEngineWaitsForALateVirtualMACDevice` positive`unit/verifyTestInstanceDelaysAnnounceUntilParentUsable` negative`unit/verifyTestEngineAnnouncesNothingBeforeTheVirtualMACDevice` negative`unit/verifyTestEngineWaitsForALateVirtualMACDevice` negative`unit/verifyTestInstanceDelaysAnnounceUntilParentUsable`
`RFC5798-8.2.3-1`	The Backup routers must be configured to send the same Router Advertisement options as the address owner. (§8.2.3; lowercase "must" in the RFC)
	MUST	8.2.3	positive`no test`no positive test negative`no test`no negative test {gap}: the obligation rests on the Router Advertisement ze does not send, which is the gap at RFC5798-6.4.3-4. The vrrp group carries no Router Advertisement leaf at all -- applyGroupLeaves internal/plugins/vrrp/groups.go accepts vrid, virtual-address, priority, preempt, preempt-delay-seconds, advertise-interval-milliseconds, accept-mode and version only -- so there is no option set a Backup could be configured to match
`RFC5798-8.4.2-1`	An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second. (§8.4.2)
	MUST	8.4.2	positive`no test`no positive test negative`no test`no negative test {feature-declined}: "An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements"; ze offers no such flag, so no virtual router is ever configured that way and the condition this MUST rests on is never true. internal/plugins/vrrp/groups.go::parseVersion admits 2 or 3 and a group runs exactly that one version, which internal/plugins/vrrp/instance.go::doSendAdvert encodes
`RFC5798-A.2-1`	The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. (§A.2)
	MUST	A.2	positive`no test`no positive test negative`no test`no negative test {feature-declined}: "The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring"; ze supports VRRP over Ethernet only and is never a router supporting VRRP on Token Ring, so the condition this MUST names is never true. internal/plugins/vrrp/packet/packet.go::VirtualMAC derives the Ethernet 00-00-5E-00-01 and 00-00-5E-00-02 address from the VRID and carries no Token-Ring functional-address mapping
`RFC5798-7.1-5`	If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (§7.1)
	SHOULD	7.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-7.1-8`	MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. If the above check fails, the receiver SHOULD log the event (§7.1)
	SHOULD	7.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.1.1-1`	The IPv4 source address of an ICMP redirect should be the address that the end-host used when making its next-hop routing decision. (§8.1.1; lowercase "should" in the RFC)
	SHOULD	8.1.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.1.2-2`	When a VRRP router restarts or boots, it SHOULD NOT send any ARP messages using its physical MAC address for the IPv4 address it owns; it should only send ARP messages that include virtual MAC addresses. (§8.1.2)
	SHOULD NOT	8.1.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.1.2-3`	When configuring an interface, Virtual Router Master routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IPv4 address on that interface. (§8.1.2; lowercase "should" in the RFC)
	SHOULD	8.1.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.1.2-4`	At system boot, when initializing interfaces for VRRP operation, delay gratuitous ARP requests and ARP responses until both the IPv4 address and the virtual router MAC address are configured. (§8.1.2)
	SHOULD	8.1.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.1.2-5`	When, for example, ssh access to a particular VRRP router is required, an IP address known to belong to that router must be used. (§8.1.2; lowercase "must" inside a SHOULD-level bullet list)
	SHOULD	8.1.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.2.1-1`	The IPv6 source address of an ICMPv6 redirect should be the address that the end-host used when making its next-hop routing decision. (§8.2.1; lowercase "should" in the RFC)
	SHOULD	8.2.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.2.2-5`	When a VRRP router restarts or boots, it SHOULD NOT send any ND messages with its physical MAC address for the IPv6 address it owns; it should only send ND messages that include virtual MAC addresses. (§8.2.2)
	SHOULD NOT	8.2.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.2.2-6`	When configuring an interface, Virtual Router Master routers should send an unsolicited ND Neighbor Advertisement message containing the virtual router MAC address for the IPv6 address on that interface. (§8.2.2; lowercase "should" in the RFC)
	SHOULD	8.2.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.2.3-2`	Router Advertisement options that advertise special services (e.g., Home Agent Information Option) that are present in the address owner should not be sent by the address owner unless the Backup routers are prepared to assume these services in full and have a complete and synchronized database for this service. (§8.2.3; lowercase "should not" in the RFC)
	SHOULD NOT	8.2.3	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.3.1-1`	If it is not the address owner, a VRRP router SHOULD NOT forward packets addressed to the IPvX address for which it becomes Master. (§8.3.1)
	SHOULD NOT	8.3.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.3.2-1`	A priority value of 255 designates a particular router as the "IPvX address owner". Care must be taken not to configure more than one router on the link in this way for a single VRID. (§8.3.2; lowercase in the RFC)
	SHOULD	8.3.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.3.2-2`	When there are multiple Backup routers, their priority values should be uniformly distributed. For example, if one Backup router has the default priority of 100 and another Backup Router is added, a priority of 50 would be a better choice for it than 99 or 100, in order to facilitate faster convergence. (§8.3.2; lowercase in the RFC)
	SHOULD	8.3.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.2-2`	As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments. (§8.4.2)
	NOT RECOMMENDED	8.4.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.2-3`	When a virtual router is configured this way and is the Backup, it should time out based on the rate advertised by the Master; in the case of a VRRPv2 Master, this means it must translate the timeout value it receives (in seconds) into centiseconds. (§8.4.2)
	SHOULD	8.4.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.2-4`	Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it. (§8.4.2)
	SHOULD	8.4.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.3.1-1`	A VRRPv2 implementation should not be given a higher priority than a VRRPv2/VRRPv3 implementation it is interacting with if the VRRPv2/ VRRPv3 rate is sub-second. (§8.4.3.1)
	SHOULD NOT	8.4.3.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-A.1-1`	To avoid this, an implementation SHOULD configure the virtual router MAC address by adding a unicast MAC filter in the FDDI device, rather than changing its hardware MAC address. (§A.1)
	SHOULD	A.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-A.2-3`	For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469]. (§A.2; lowercase "should" in the RFC)
	SHOULD	A.2	positive`no test`no positive test negative`no test`no negative test {feature-declined}: "The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring"; Section A.2 recommends this encapsulation only for a router running VRRP over Token Ring, and ze supports VRRP over Ethernet only, so it never sends an advertisement onto a Token-Ring segment. internal/plugins/vrrp/packet/packet.go::VirtualMAC derives only the Ethernet 00-00-5E-00-01 and 00-00-5E-00-02 addresses and carries no Token-Ring mapping
`RFC5798-7.1-6`	If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event, and MAY indicate via network management that an error occurred. - MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. (§7.1)
	MAY	7.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-7.1-7`	MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. (§7.1)
	MAY	7.1	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.2.2-7`	Note that on a restarting Master router where the VRRP protected address is the interface address, (that is, priority 255) duplicate address detection (DAD) may fail, as the Backup router may answer that it owns the address. One solution is to not run DAD in this case. (§8.2.2)
	MAY	8.2.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.2-5`	An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. (§8.4.2)
	MAY	8.4.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-8.4.2-6`	It MAY report when a VRRPv3 Master is not sending VRRPv2 packets: that suggests they don't agree on whether they're supporting VRRPv2 routers. (§8.4.2)
	MAY	8.4.2	positive`no test`no positive test negative`no test`no negative test
`RFC5798-A.2-2`	The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. Additionally, routers MAY support the unicast mode of operation to take advantage of newer Token-Ring adapter implementations that support non-promiscuous reception for multiple unicast MAC addresses and to avoid both the multicast traffic and usage conflicts associated with the use of Token-Ring functional addresses. (§A.2)
	MAY	A.2	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC5798-5.1.1.2-1` The IPv4 multicast address as assigned by the IANA for VRRP is: 224.0.0.18 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its TTL. (§5.1.1.2)	no test	no test carries this requirement id; annotated {lower-layer}: Linux forwarding plane; internal/plugins/fib/kernel/backend_linux.go::addRoute writes every route ze puts into the kernel FIB and it writes unicast next hops only, ze enables no multicast routing anywhere, and Linux consumes a datagram addressed to the 224.0.0.0/24 link-local scope group on its own input path instead of forwarding it, so no state ze installs decides this
`RFC5798-5.1.2.2-1` The IPv6 multicast address assigned by the IANA for VRRP is: FF02:0:0:0:0:0:0:12 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its Hop Limit. (§5.1.2.2)	no test	no test carries this requirement id; annotated {lower-layer}: Linux forwarding plane; internal/plugins/fib/kernel/backend_linux.go::addRoute writes every route ze puts into the kernel FIB, ze enables no IPv6 multicast routing anywhere, and Linux consumes a datagram addressed to the ff02::/16 link-local scope group on its own input path instead of forwarding it, so no state ze installs decides this
`RFC5798-6.4.3-4` (630) ++ MUST send ND Router Advertisements for the virtual router. (§6.4.3)	{gap}, no test	ze runs IPv6 virtual routers and sends no Router Advertisement for them. The announcer's only IPv6 frame is the unsolicited Neighbor Advertisement, icmpv6TypeNA 136, built by BuildNA internal/plugins/vrrp/transport/na.go and selected by frameBuilder internal/plugins/vrrp/transport/transport.go, and no Router Advertisement builder and no RA send path exists under internal/plugins/vrrp
`RFC5798-7.1-3` - MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). (§7.1)	{gap}, no test	Decode internal/plugins/vrrp/packet/validate.go verifies the VRID half of this check and ze implements no address-owner half, so an advertisement arriving for a VRID whose address the local router owns is processed rather than discarded. RFC 9568 erratum 8298 lowers that half to a SHOULD that logs and ze follows the successor, so the RFC 5798 MUST as published is unmet
`RFC5798-7.4-1` IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet Networks" [RFC2464]). (§7.4)	no test	no test carries this requirement id; annotated {lower-layer}: Linux SLAAC; internal/plugins/vrrp/dataplane_linux.go::applyDataplaneSysctls is the only IPv6 state ze writes on a VRRP device and it writes accept_dad alone, while Linux derives each device's Interface Identifier from that device's MAC in the RFC 2464 manner this sentence names, so no value ze writes decides the derivation
`RFC5798-7.4-2` They MUST NOT use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers. (§7.4)	{gap}, no test	ze creates the per-group macvlan carrying the virtual router MAC and writes no addr_gen_mode on it, because applyDataplaneSysctls internal/plugins/vrrp/dataplane_linux.go writes accept_dad and nothing else on an IPv6 group, so Linux derives that device's link-local Interface Identifier from the virtual router MAC, which is the derivation this sentence forbids. Suppressing it, by writing addr_gen_mode on the IPv6 macvlan, is unbuilt
`RFC5798-8.1.3-1` If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the virtual router MAC address in the Proxy ARP message. (§8.1.3; lowercase "must" in the RFC)	{gap}, no test	ze offers proxy ARP, as the builtin proxy sysctl profile that writes net.ipv4.conf.<iface>.proxy_arp=1 internal/core/sysctl/profiles.go, and nothing makes a proxy ARP reply on a VRRP router carry the virtual router MAC: the kernel answers from the replying device's own address and ze installs no virtual-MAC proxy state, so the obligation is unbuilt rather than out of reach
`RFC5798-8.2.2-2` When a Virtual Router Master sends an ND Neighbor Solicitation message for a host's IPv6 address, the Virtual Router Master MUST include the virtual MAC address for the virtual router if it sends a source link-layer address option in the neighbor solicitation message. (§8.2.2)	{gap}, no test	ze authors no Neighbor Solicitation -- the plugin's only ICMPv6 builder is BuildNA, type 136, internal/plugins/vrrp/transport/na.go -- and it installs nothing that makes a host solicitation source from the virtual-MAC macvlan, which doInstallVIPs internal/plugins/vrrp/instance.go gives the virtual address alone. The solicitation a Master sends for a host therefore leaves the parent, carrying the parent's own link-layer address
`RFC5798-8.2.2-3` It MUST NOT use its physical MAC address in the source link-layer address option. (§8.2.2)	{gap}, no test	the same unbuilt path as RFC5798-8.2.2-2. Ze authors no Neighbor Solicitation and installs nothing that keeps the physical MAC out of the source link-layer address option of one its stack sends for a host
`RFC5798-8.2.3-1` The Backup routers must be configured to send the same Router Advertisement options as the address owner. (§8.2.3; lowercase "must" in the RFC)	{gap}, no test	the obligation rests on the Router Advertisement ze does not send, which is the gap at RFC5798-6.4.3-4. The vrrp group carries no Router Advertisement leaf at all -- applyGroupLeaves internal/plugins/vrrp/groups.go accepts vrid, virtual-address, priority, preempt, preempt-delay-seconds, advertise-interval-milliseconds, accept-mode and version only -- so there is no option set a Backup could be configured to match
`RFC5798-8.4.2-1` An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second. (§8.4.2)	no test	no test carries this requirement id; annotated {feature-declined}: "An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements"; ze offers no such flag, so no virtual router is ever configured that way and the condition this MUST rests on is never true. internal/plugins/vrrp/groups.go::parseVersion admits 2 or 3 and a group runs exactly that one version, which internal/plugins/vrrp/instance.go::doSendAdvert encodes
`RFC5798-A.2-1` The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. (§A.2)	no test	no test carries this requirement id; annotated {feature-declined}: "The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring"; ze supports VRRP over Ethernet only and is never a router supporting VRRP on Token Ring, so the condition this MUST names is never true. internal/plugins/vrrp/packet/packet.go::VirtualMAC derives the Ethernet 00-00-5E-00-01 and 00-00-5E-00-02 address from the VRID and carries no Token-Ring functional-address mapping

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.

`RFC5798-5.1.1.2-1`

The IPv4 multicast address as assigned by the IANA for VRRP is: 224.0.0.18 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its TTL. (§5.1.1.2)

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

No test carries RFC5798-5.1.1.2-1, so no unit is bound to it.

`RFC5798-5.1.1.3-1`

The TTL MUST be set to 255. (§5.1.1.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.1.1.3 says "The TTL MUST be set to 255." TestSendAdvertV3IPv4HeaderTTLProtoDst changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; it still requires frame[8] == 255. Single-polarity per the row annotation. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
positive	`TestSendAdvertV3IPv4HeaderTTLProtoDst`	unit/verify	revert, verified

`RFC5798-5.1.1.3-2`

A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet. (§5.1.1.3, §7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.1.1.3 says "A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet." TestDecodeGoldenV3IPv4 now decodes the RFC 9568 message-only golden G2 under the default-mode lookup instead of the pseudo-header golden G2c, and lost only the removed MsgOnlyChecksum assertion; the subtests of TestNegativeReferenceBugs other than N1 gained only the FillChecksum mode argument. The positive is still a fully conforming advert, the checksum check precedes the checks this row names so a wrong form would fail with ErrChecksum and not pass silently, and each negative still asserts its exact sentinel. N4 with TTL 64 still requires ErrTTL. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestNegativeReferenceBugs`	unit/verify	revert, verified
positive	`TestDecodeGoldenV3IPv4`	unit/verify	revert, verified

`RFC5798-5.1.2.2-1`

The IPv6 multicast address assigned by the IANA for VRRP is: FF02:0:0:0:0:0:0:12 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its Hop Limit. (§5.1.2.2)

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

No test carries RFC5798-5.1.2.2-1, so no unit is bound to it.

`RFC5798-5.1.2.3-1`

The Hop Limit MUST be set to 255. (§5.1.2.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. single-polarity by annotation: integration test reads IPV6_MULTICAST_HOPS 255 back from the tx socket; runs only under the privileged QEMU suite

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

`RFC5798-5.1.2.3-2`

A VRRP router receiving a packet with the Hop Limit not equal to 255 MUST discard the packet. (§5.1.2.3, §7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. golden v6 decode passes at hop limit 255; hop limit 64 asserts ErrTTL

Polarity	Test	Kind and tier	Proof state
negative	`TestDecodeV3IPv6ChecksumAndHopLimit`	unit/verify	revert, verified
positive	`TestDecodeGoldenV3IPv6`	unit/verify	revert, verified

`RFC5798-5.2.2-1`

The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded. (§5.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.2.2 says "The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded." TestDecodeGoldenV3IPv4 now decodes the RFC 9568 message-only golden G2 under the default-mode lookup instead of the pseudo-header golden G2c, and lost only the removed MsgOnlyChecksum assertion; the subtests of TestNegativeReferenceBugs other than N1 gained only the FillChecksum mode argument. The positive is still a fully conforming advert, the checksum check precedes the checks this row names so a wrong form would fail with ErrChecksum and not pass silently, and each negative still asserts its exact sentinel. Type 2 still requires ErrType before the VRID lookup. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestValidationOrder`	unit/verify	revert, verified
positive	`TestDecodeGoldenV3IPv4`	unit/verify	revert, verified

`RFC5798-5.2.4-1`

The priority value for the VRRP router that owns the IPvX address associated with the virtual router MUST be 255 (decimal). (§5.2.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. owner EffectivePriority(0)==255 from configured 120; non-owner keeps 100

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

`RFC5798-5.2.4-2`

VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). (§5.2.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): config range: TestBoundaryPriority accepts 1 and 254 and refuses 0 and 255; run-time: TestEffectivePriorityWithTracking (now tagged here) requires exact values including the floor at 1 for decrements equal to and past the priority (254/254, 100/100, 100/4064), so removing the clamp goes red. Record: revert EffectivePriority.

Polarity	Test	Kind and tier	Proof state
negative	`TestBoundaryPriority`	unit/verify	revert, verified
positive	`TestBoundaryPriority`	unit/verify	revert, verified
positive	`TestEffectivePriorityWithTracking`	unit/verify	revert, verified

`RFC5798-5.2.6-1`

This field MUST be set to zero on transmission and ignored on reception. (§5.2.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.2.6 says "This field MUST be set to zero on transmission and ignored on reception." TestEncodeGoldenV3IPv4 now runs a subtest per checksum mode, and each still requires the rsvd nibble to be zero and the exact golden bytes; TestEncodeV3ReserveZeroOverDirtyBuffer encodes over an all-0xFF buffer against the default-mode golden G2. The reception half is TestDecodeV3ReserveIgnoredOnReceive, unchanged. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestDecodeV3ReserveIgnoredOnReceive`	unit/verify	revert, verified
positive	`TestEncodeGoldenV3IPv4`	unit/verify	revert, verified
positive	`TestEncodeV3ReserveZeroOverDirtyBuffer`	unit/verify	revert, verified

`RFC5798-5.2.8-1`

The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field is set to zero. (§5.2.8, §7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.2.8 says "The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the ..." Ze now computes this form for IPv4 only in a group configured checksum rfc5798-compatible, because RFC 9568 Section 5.2.8, which obsoletes this text, says the IPv4 checksum "only includes the VRRP message"; the default IPv4 group neither sends nor accepts it, and the earlier sentence about dual-accept is withdrawn. TestFillChecksumFamilies (v3v4 under rfc5798-compatible) and TestFillChecksumZeroesFieldAndCoversPseudoHeader pin the IPv4 pseudo-header sum 0xDEFB and the IPv6 one in every mode; an overlay mutant forcing verifyReceived to the message-only form reddened the compatible-mode decodes. The only proof that a compatible group carries the mode from instance.doSendAdvert to the wire is the keepalived interop scenario, which no tag names. Enforced for the compatible mode only.

Polarity	Test	Kind and tier	Proof state
negative	`TestFillChecksumZeroesFieldAndCoversPseudoHeader`	unit/verify	revert, verified
negative	`TestDecodeV3IPv6ChecksumAndHopLimit`	unit/verify	revert, verified
positive	`TestFillChecksumFamilies`	unit/verify	revert, verified
positive	`TestFillChecksumZeroesFieldAndCoversPseudoHeader`	unit/verify	revert, verified

`RFC5798-5.2.9-1`

For IPv6, the first address must be the IPv6 link-local address associated with the virtual router. (§5.2.9, §6.1; lowercase "must" in the RFC)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 5.2.9 says "For IPv6, the first address must be the IPv6 link-local address associated with the virtual router." TestSendAdvertIPv6LeadsWithLinkLocal changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; octets 8-24 are still required to be fe80::1 ahead of 2001:db8::1. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestValidateIPv6LinkLocal`	unit/verify	revert, verified
positive	`TestValidateIPv6LinkLocal`	unit/verify	revert, verified
positive	`TestAdvertParamsIPv6LeadWithLinkLocal`	unit/verify	revert, verified
positive	`TestSendAdvertIPv6LeadsWithLinkLocal`	unit/verify	revert, verified

`RFC5798-5.2.9-2`

This field contains either one or more IPv4 addresses, or one or more IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in one IPvX Address field. (§5.2.9)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestValidateVIPFamilyMatchesGroupFamily now isolates both mixed-family cases: the IPv4 group lists 192.0.2.1 then 2001:db8::1, the IPv6 group lists fe80::1 then 192.0.2.1 (so the first-address-link-local rule cannot refuse it), and each refusal must carry the family error text; same-family lists validate. Records: revert validateGroup, both polarities.

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

`RFC5798-6.1-1`

Note: IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped when Accept_Mode is False. (§6.1, §6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. ICMPv6 135 and 136 accepts must precede the first drop of the accept-filter chain; the test fails if either is missing or placed after a drop

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

`RFC5798-6.4.2-1`

(310) + MUST NOT respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuations 1-2): Re-read: the unit's body is unchanged; only the 6.4.2 and 6.4.3 Virtual Router MAC proxy tags left it for TestVRRPBackupDoesNotForwardVirtualMACFrames, so the verdict stands. Prior note: Backup installs no VIP (parent carries arp_ignore=1, so nothing answers ARP for it); Master contrast installs it on the vMAC device

Polarity	Test	Kind and tier	Proof state
negative	`TestInstanceOwnerStartupGoesMaster`	unit/verify	revert, verified
positive	`TestInstanceStartupNonOwnerGoesBackup`	unit/verify	revert, verified

`RFC5798-6.4.2-2`

(320) + MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 address(es) associated with the virtual router. (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Backup installs no IPv6 VIP, Master installs it on the vMAC macvlan only; NS answering follows the kernel address

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

`RFC5798-6.4.2-3`

(325) + MUST NOT send ND Router Advertisement messages for the virtual router. (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Backup emits zero announcements; the Master's one announcement is BuildNA type 136, never 134

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

`RFC5798-6.4.2-4`

(335) - MUST discard packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuation 3): Wiring now proven on the host: TestBackupDiscardFollowsTheState drives the FSM and asserts the worker sets the discard on the virtual router MAC device at start (idle worker: on then off), entering Backup adds no call, promotion withdraws it once after the only install, and a higher-priority advert demotes and sets it again before the only removal (records observed red on doRemoveVIPs; the run revert was also observed red but the ledger keeps one record per unit/polarity). Wire effect: TestVRRPBackupDoesNotForwardVirtualMACFrames (QEMU guest) forwards a transit datagram sent to the Virtual Router MAC without the nft drop and stops it with it (records on backupFilterTables). The host unit's negative tag is a state contrast; the violating negative (no discard, frame forwarded) is the QEMU control.

Polarity	Test	Kind and tier	Proof state
negative	`TestBackupDiscardFollowsTheState`	unit/verify	revert, verified
negative	`TestVRRPBackupDoesNotForwardVirtualMACFrames`	unit/verify	revert, verified
positive	`TestBackupDiscardFollowsTheState`	unit/verify	revert, verified
positive	`TestVRRPBackupDoesNotForwardVirtualMACFrames`	unit/verify	revert, verified

`RFC5798-6.4.2-5`

(340) - MUST NOT accept packets addressed to the IPvX address(es) associated with the virtual router. (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuations 1-2): Re-read: the unit's body is unchanged; only the 6.4.2 and 6.4.3 Virtual Router MAC proxy tags left it for TestVRRPBackupDoesNotForwardVirtualMACFrames, so the verdict stands. Prior note: Backup installs no VIP so no packet to it is delivered locally; Master contrast installs it

Polarity	Test	Kind and tier	Proof state
negative	`TestInstanceOwnerStartupGoesMaster`	unit/verify	revert, verified
positive	`TestInstanceStartupNonOwnerGoesBackup`	unit/verify	revert, verified

`RFC5798-6.4.2-6`

If a Shutdown event is received, then: (350) + Cancel the Master_Down_Timer (355) + Transition to the {Initialize} state (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. matrix row backup/shutdown asserts exactly StopTimers + EmitStateChange to Initialize; a non-Shutdown event leaves Backup

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

`RFC5798-6.4.2-7`

If the Master_Down_Timer fires, then: (370) + Send an ADVERTISEMENT (375) + If the protected IPvX address is an IPv4 address, then: (380) * Broadcast a gratuitous ARP request on that interface containing the virtual router MAC address for each IPv4 address associated with the virtual router. (385) + else // ipv6 (390) * Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) associated with the virtual router. (395) * For each IPv6 address associated with the virtual router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the target address set to the IPv6 address of the virtual router, and the target link-layer address set to the virtual router MAC address. (400) +endif // was protected addr ipv4? (405) + Set the Adver_Timer to Advertisement_Interval (410) + Transition to the {Master} state (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp final judge 2026-09-29 (independent): earlier proof stands (promotion action list, StartAdvertTimer at the own interval, GARP per IPv4 VIP with the virtual router MAC, NA per IPv6 VIP R=1 S=0 O=1 TLL 00-00-5e-00-02-0a, stale-generation negative). The Solicited-Node clause is now asserted at Ze's boundary: TestPromotionInstallsIPv6AddressesOnVirtualMACDevice requires nothing installed in Backup and, on the Master_Down_Timer, exactly fe80::1 and 2001:db8::1 installed on the virtual-MAC device, never the parent -- the address add from which Linux addrconf joins each Solicited-Node group (record: doInstallVIPs). Kernel membership itself is not read.

Polarity	Test	Kind and tier	Proof state
negative	`TestFSMStaleTimerGenerationIgnored`	unit/verify	revert, verified
positive	`TestFSMMasterDownPromotion`	unit/verify	revert, verified
positive	`TestPromotionSetsAdverTimerToOwnInterval`	unit/verify	revert, verified
positive	`TestPromotionInstallsIPv6AddressesOnVirtualMACDevice`	unit/verify	revert, verified
positive	`TestAnnounceMasterFramesPerAddress`	unit/verify	revert, verified

`RFC5798-6.4.2-8`

If the Priority in the ADVERTISEMENT is zero, then: (430) * Set the Master_Down_Timer to Skew_Time (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Priority 0 advert arms StartMasterDownTimer(skewDur); non-zero arms mdDur

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

`RFC5798-6.4.2-9`

If Preempt_Mode is False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: (450) @ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (455) @ Recompute the Master_Down_Interval (460) @ Reset the Master_Down_Timer to Master_Down_Interval (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): TestV3BackupAdoptsIntervalOrDiscards: equal, greater and Preempt-off lower adverts carrying 4 s each set Master_Adver_Interval to 4000 and arm the literal 14.4375 s; Preempt-on lower yields nothing and keeps 1000.

Polarity	Test	Kind and tier	Proof state
negative	`TestFSMTransitionMatrix`	unit/verify	revert, verified
negative	`TestV3BackupAdoptsIntervalOrDiscards`	unit/verify	revert, verified
positive	`TestFSMTransitionMatrix`	unit/verify	revert, verified
positive	`TestV3BackupAdoptsIntervalOrDiscards`	unit/verify	revert, verified

`RFC5798-6.4.2-10`

else // preempt was true or priority was less (470) @ Discard the ADVERTISEMENT (§6.4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Preempt True and lower priority emits no actions; same advert with Preempt False adopts

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

`RFC5798-6.4.3-1`

(610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.3, §8.1.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp closure judge 2026-09-30 (independent) re-judged: the tagged units changed only by added RFC requirement tag comment lines for the new rows (8.1.2-6 / 8.2.2-8 / 8.2-4 / 8.1.1-2); test bodies byte-identical, records current, verdict unchanged. Prior note: vrrp judge 2026-09-29 (independent, continuation 3): Product install now proven: TestPromotionInstallsIPv4AddressOnVirtualMACDevice (v3 subtest) asserts a Backup installs nothing and the promoted non-owner makes exactly one install, on the virtual-MAC macvlan zv4-2-10 (never the parent), of exactly 192.0.2.1/24 (record observed red on doInstallVIPs). TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly (QEMU guest) proves that installed state answers ARP and that no reply is seen with the address removed (records on vipCIDRs). The dataplane_linux_test sysctl tags stay without records.

Polarity	Test	Kind and tier	Proof state
negative	`TestDataplaneRestoreOnLastGroup`	unit/verify	revert, verified
negative	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestDataplaneApplyIPv4SetsRecipe`	unit/verify	revert, verified
positive	`TestPromotionInstallsIPv4AddressOnVirtualMACDevice`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified

`RFC5798-6.4.3-2`

(620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router. (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Master installs the IPv6 VIP on the vMAC macvlan (kernel joins its solicited-node group); Backup installs nothing

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

`RFC5798-6.4.3-3`

(625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router. (§6.4.3, §8.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Master installs the IPv6 VIP on the vMAC macvlan so it answers NS; Backup installs nothing

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

`RFC5798-6.4.3-4`

(630) ++ MUST send ND Router Advertisements for the virtual router. (§6.4.3)

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

No test carries RFC5798-6.4.3-4, so no unit is bound to it.

`RFC5798-6.4.3-5`

(645) - MUST forward packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuation 3): Wiring now proven on the host: TestBackupDiscardFollowsTheState asserts promotion withdraws the discard exactly once and only after the address install, and that it holds before promotion and after demotion (records observed red on doInstallVIPs and doRemoveVIPs). Wire effect: TestVRRPBackupDoesNotForwardVirtualMACFrames (QEMU guest) forwards the datagram sent to the Virtual Router MAC once the filter is withdrawn and the address installed, and not while the filter holds (records on clearBackupFilter).

Polarity	Test	Kind and tier	Proof state
negative	`TestBackupDiscardFollowsTheState`	unit/verify	revert, verified
negative	`TestVRRPBackupDoesNotForwardVirtualMACFrames`	unit/verify	revert, verified
positive	`TestBackupDiscardFollowsTheState`	unit/verify	revert, verified
positive	`TestVRRPBackupDoesNotForwardVirtualMACFrames`	unit/verify	revert, verified

`RFC5798-6.4.3-6`

(650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): both admitting conditions and the refusal are asserted: TestActiveAddressOwnerAcceptsWhateverAcceptModeSays (owner, Accept_Mode False, now tagged here) requires exactly one filter with accept=true and the reported accept-mode true; TestActiveNonOwnerWithAcceptModeTrueAcceptsLocalDelivery covers Accept_Mode True; the non-owner Accept_Mode False negative requires accept=false. Record: revert EffectiveAcceptMode on the owner unit.

Polarity	Test	Kind and tier	Proof state
negative	`TestActiveNonOwnerWithAcceptModeFalseSuppressesLocalDelivery`	unit/verify	revert, verified
positive	`TestActiveAddressOwnerAcceptsWhateverAcceptModeSays`	unit/verify	revert, verified
positive	`TestActiveNonOwnerWithAcceptModeTrueAcceptsLocalDelivery`	unit/verify	revert, verified

`RFC5798-6.4.3-7`

MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets. (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent): Forbidden: a Master that is neither owner nor Accept_Mode True accepting packets to the VIP. TestActiveNonOwnerWithAcceptModeFalseSuppressesLocalDelivery requires accept=false; both exemptions are now tagged: Accept_Mode True (accept=true) and the address owner with Accept_Mode False (TestActiveAddressOwnerAcceptsWhateverAcceptModeSays, accept=true), so a suppression applied to the owner goes red. Record: revert EffectiveAcceptMode on the owner unit.

Polarity	Test	Kind and tier	Proof state
negative	`TestActiveAddressOwnerAcceptsWhateverAcceptModeSays`	unit/verify	revert, verified
negative	`TestActiveNonOwnerWithAcceptModeTrueAcceptsLocalDelivery`	unit/verify	revert, verified
positive	`TestActiveNonOwnerWithAcceptModeFalseSuppressesLocalDelivery`	unit/verify	revert, verified

`RFC5798-6.4.3-8`

If a Shutdown event is received, then: (660) + Cancel the Adver_Timer (665) + Send an ADVERTISEMENT with Priority = 0 (670) + Transition to the {Initialize} state (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. master/shutdown asserts StopTimers, SendAdvertZeroPriority, RemoveVIPs, Initialize; Backup shutdown sends no zero-priority advert

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

`RFC5798-6.4.3-9`

If the Adver_Timer fires, then: (685) + Send an ADVERTISEMENT (690) + Reset the Adver_Timer to Advertisement_Interval (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. armed-generation expiry sends an advert and re-arms at 1s; a stale generation does nothing

Polarity	Test	Kind and tier	Proof state
negative	`TestFSMStaleTimerGenerationIgnored`	unit/verify	revert, verified
positive	`TestFSMTransitionMatrix`	unit/verify	revert, verified

`RFC5798-6.4.3-10`

If the Priority in the ADVERTISEMENT is zero, then: (710) -* Send an ADVERTISEMENT (715) -* Reset the Adver_Timer to Advertisement_Interval (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Priority 0 advert sends an advert and re-arms the Adver_Timer; a losing non-zero advert does not re-arm

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

`RFC5798-6.4.3-11`

If the Priority in the ADVERTISEMENT is greater than the local Priority, (730) -* or (735) -* If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IPvX Address of the sender is greater than the local primary IPvX Address, then: (740) -@ Cancel Adver_Timer (745) -@ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (750) -@ Recompute the Skew_Time (755) @ Recompute the Master_Down_Interval (760) @ Set Master_Down_Timer to Master_Down_Interval (765) @ Transition to the {Backup} state (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuations 1-2): TestInstanceIPv6ElectionUsesUnsignedOrder closes the missing IPv6 operand: an IPv6 Master whose advertisement source is link-local yields to a higher-priority advert and to an equal-priority sender greater in the high octet (fe80::80 vs fe80::7f), asserting advert timer cancelled, the advert's 3000ms interval adopted, Skew_Time and Master_Down_Interval recomputed from it, down timer armed, Backup; the reverse pair, which a signed compare would rank greater, keeps Master, timer armed, 1000ms interval. With TestInstanceTieBreakComparesTheAdvertisementSource (IPv4 operand) and TestFSMTransitionMatrix (timer value). Records: senderWinsTieBreak, observed red.

Polarity	Test	Kind and tier	Proof state
negative	`TestFSMTransitionMatrix`	unit/verify	revert, verified
negative	`TestInstanceTieBreakComparesTheAdvertisementSource`	unit/verify	revert, verified
negative	`TestInstanceIPv6ElectionUsesUnsignedOrder`	unit/verify	revert, verified
positive	`TestFSMTransitionMatrix`	unit/verify	revert, verified
positive	`TestInstanceTieBreakComparesTheAdvertisementSource`	unit/verify	revert, verified
positive	`TestInstanceIPv6ElectionUsesUnsignedOrder`	unit/verify	revert, verified

`RFC5798-6.4.3-12`

else // new Master logic (775) @ Discard ADVERTISEMENT (§6.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. losing rows leave state and timers untouched; the extra SendAdvert they assert is RFC 9568 Section 6.4.3's added step, recorded on the row's superseded marker, and does not act on the advert's contents

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

`RFC5798-7.1-1`

- MUST verify that the VRRP version is 3. (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.1 says "MUST verify that the VRRP version is 3." TestDecodeGoldenV3IPv4 now decodes the RFC 9568 message-only golden G2 under the default-mode lookup instead of the pseudo-header golden G2c, and lost only the removed MsgOnlyChecksum assertion; the subtests of TestNegativeReferenceBugs other than N1 gained only the FillChecksum mode argument. The positive is still a fully conforming advert, the checksum check precedes the checks this row names so a wrong form would fail with ErrChecksum and not pass silently, and each negative still asserts its exact sentinel. N9 still requires ErrVersion for a v2 advert at a v3 group. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestNegativeReferenceBugs`	unit/verify	revert, verified
positive	`TestDecodeGoldenV3IPv4`	unit/verify	revert, verified

`RFC5798-7.1-2`

- MUST verify that the received packet contains the complete VRRP packet (including fixed fields, and IPvX address). (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.1 says "MUST verify that the received packet contains the complete VRRP packet (including fixed fields, and IPvX address)." TestDecodeGoldenV3IPv4 now decodes the RFC 9568 message-only golden G2 under the default-mode lookup instead of the pseudo-header golden G2c, and lost only the removed MsgOnlyChecksum assertion; the subtests of TestNegativeReferenceBugs other than N1 gained only the FillChecksum mode argument. The positive is still a fully conforming advert, the checksum check precedes the checks this row names so a wrong form would fail with ErrChecksum and not pass silently, and each negative still asserts its exact sentinel. TestDecodeV3DiscardsIncompletePacket switched its IPv4 golden to G2 and recomputes in the default form, so the truncation and short-address cases still fail on ErrTruncated or ErrLength and not on ErrChecksum. The earlier residual about the mis-aimed N2 tag stands. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestDecodeV3DiscardsIncompletePacket`	unit/verify	revert, verified
negative	`TestNegativeReferenceBugs`	unit/verify	revert, verified
positive	`TestDecodeV3DiscardsIncompletePacket`	unit/verify	revert, verified
positive	`TestDecodeGoldenV3IPv4`	unit/verify	revert, verified

`RFC5798-7.1-3`

- MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). (§7.1)

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

No test carries RFC5798-7.1-3, so no unit is bound to it.

`RFC5798-7.1-4`

If any one of the above checks fails, the receiver MUST discard the packet (§7.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.1 says "If any one of the above checks fails, the receiver MUST discard the packet". TestInstanceRxValidAdvertReachesFSM changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same. TestInstanceRxFailedCheckIsDiscarded is unchanged, and an overlay mutant giving instance.lookup the wrong checksum mode reddened both, so the discard path is still exercised end to end. The owner-check carve-out under erratum 8298 stands. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestInstanceRxDecodeErrorMapsReason`	unit/verify	revert, verified
negative	`TestInstanceRxFailedCheckIsDiscarded`	unit/verify	revert, verified
positive	`TestInstanceRxValidAdvertReachesFSM`	unit/verify	revert, verified
positive	`TestInstanceRxFailedCheckIsDiscarded`	unit/verify	revert, verified

`RFC5798-7.2-1`

The following operations MUST be performed when transmitting a VRRP packet: - Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum (§7.2)

Audit verdict: weak (the tests pass over code that does not enforce the requirement), fresh. Re-judged 2026-10-18 (independent auditor, after d2abad70ad). RFC 5798 Section 7.2 says "The following operations MUST be performed when transmitting a VRRP packet: - Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum", and Section 5.2.8 defines that checksum over "the entire VRRP message starting with the version field and a \"pseudo-header\"" for both families. Fill clause: proven. TestTransmittedAdvertFilledFromInstanceState reds when doSendAdvert sends the configured instead of the effective priority, TestSendAdvertFillsFieldsAndChecksum pins every field through encodeLocked, TestEncodeGoldenV3IPv4 pins WriteTo, and the TestBoundaryInterval negative pins Validate refusing an interval the field cannot carry. IPv4 checksum clause (opt-in rfc5798-compatible, since RFC 9568 obsoletes the default form): proven. Overlay mutants run 2026-10-18 over the whole vrrp tree: doSendAdvert hard-coded to ChecksumRFC9568 reds the compatible subtest of TestTransmittedAdvertFilledFromInstanceState (the gap the previous verdict reported is closed); encodeLocked ignoring p.Checksum, or skipping FillChecksum, reds TestSendAdvertFillsFieldsAndChecksum, whose expected sum the test computes itself; G2c 0xDEFB was re-derived independently. IPv6 checksum clause: unproven by any tagged unit. On IPv6 the kernel computes the checksum because openV6 (backend_linux.go) sets IPV6_CHECKSUM 6; the transport unit test uses a fake backend and its IPv6 frame carries no checksum, and the IPv6 run of TestTransmittedAdvertFilledFromInstanceState calls FillChecksum in the test body, not on the production path. Removing that setsockopt leaves every tagged test green (reasoned: only TestIntegrationOpenInstanceSocketOptions and TestIntegrationAdvertV6OnWire, integration-tagged QEMU units, read IPV6_CHECKSUM; the overlay run could not build because another session's internal/component/iface/config_apply.go has undefined applyVLANMTU). Fix: tag TestIntegrationOpenInstanceSocketOptions or TestIntegrationAdvertV6OnWire positive for this row and take its QEMU discrimination record. Summary nit: the {superseded} marker names only RFC9568-7.2-1, but this row also carries the checksum step whose successor is RFC9568-7.2-5. The discrimination records on this row are body-panic replacements and prove reachability only; the deciding logic is proven by the mutants above. No tagged unit is a QEMU-guest unit.

Polarity	Test	Kind and tier	Proof state
negative	`TestBoundaryInterval`	unit/verify	revert, verified
positive	`TestTransmittedAdvertFilledFromInstanceState`	unit/verify	revert, verified
positive	`TestEncodeGoldenV3IPv4`	unit/verify	revert, verified
positive	`TestSendAdvertFillsFieldsAndChecksum`	unit/verify	revert, verified

`RFC5798-7.2-2`

If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual router MAC Address (§7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.2 says "If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual ..." TestTxAdvertV4OnWire changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the captured source MAC is still compared with 00-00-5e-00-01-0a. Single-polarity per the row annotation. Verdict unchanged; the guest record is owed a re-record.

Polarity	Test	Kind and tier	Proof state
positive	`TestConstants`	unit/verify	revert, verified
positive	`TestTxAdvertV4OnWire`	unit/verify	revert, unit-changed (the tagged unit's behavior changed since the red was observed)
positive	`TestTxAdvertV6OnWire`	unit/verify	revert, verified

`RFC5798-7.2-3`

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.2 says "If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual ..." TestTxAdvertV4OnWire and TestSendAdvertNoLinkLocalSkipsAndCounts changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the IPv4 primary-source capture and the IPv6 no-link-local negative are unchanged. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestSendAdvertNoLinkLocalSkipsAndCounts`	unit/verify	revert, verified
negative	`TestSendAdvertNoPrimaryV4SkipsAndCounts`	unit/verify	revert, verified
positive	`TestTxAdvertV4OnWire`	unit/verify	revert, unit-changed (the tagged unit's behavior changed since the red was observed)
positive	`TestTxAdvertV6OnWire`	unit/verify	revert, verified
positive	`TestSendAdvertUsesParentPrimaryV4Source`	unit/verify	revert, verified

`RFC5798-7.2-4`

Set the IPvX protocol to VRRP - Send the VRRP packet to the VRRP IPvX multicast group (§7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 7.2 says "Set the IPvX protocol to VRRP - Send the VRRP packet to the VRRP IPvX multicast group". TestTxAdvertV4OnWire and TestSendAdvertV3IPv4HeaderTTLProtoDst changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; protocol 112 and 224.0.0.18 are still compared with literals. Single-polarity per the row annotation. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
positive	`TestTxAdvertV4OnWire`	unit/verify	revert, verified
positive	`TestTxAdvertV6OnWire`	unit/verify	revert, verified
positive	`TestSendAdvertV3IPv4HeaderTTLProtoDst`	unit/verify	revert, verified

`RFC5798-7.4-1`

IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet Networks" [RFC2464]). (§7.4)

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

No test carries RFC5798-7.4-1, so no unit is bound to it.

`RFC5798-7.4-2`

They MUST NOT use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers. (§7.4)

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

No test carries RFC5798-7.4-2, so no unit is bound to it.

`RFC5798-8.1.2-1`

The Virtual Router Master MUST NOT respond with its physical MAC address in the ARP response. (§8.1.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.1.2 says "The Virtual Router Master MUST NOT respond with its physical MAC address in the ARP response." TestVRRPOwnerAnswersWithVirtualMACOnly changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the ARP captures with and without the owner filter are unchanged. Verdict unchanged; the guest record is owed a re-record.

Polarity	Test	Kind and tier	Proof state
negative	`TestDataplaneRestoreOnLastGroup`	unit/verify	revert, verified
negative	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
negative	`TestOwnerFilterWiredOnPromotionForEveryFamily`	unit/verify	revert, verified
negative	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestDataplaneApplyIPv4SetsRecipe`	unit/verify	revert, verified
positive	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestOwnerFilterWiredOnPromotionForEveryFamily`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified

`RFC5798-8.1.2-6`

When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router. (§8.1.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.1.2 says "When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router." TestVRRPOwnerAnswersWithVirtualMACOnly changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the ARP captures with and without the owner filter are unchanged. Verdict unchanged; the guest record is owed a re-record.

Polarity	Test	Kind and tier	Proof state
negative	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
negative	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly`	unit/verify	revert, verified

`RFC5798-8.1.1-2`

If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. (§8.1.1; lowercase "must" in the RFC)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.1.1 says "If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address." TestVRRPRedirectSourceFollowsVirtualMAC changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the redirect-source capture and its physical-MAC control are unchanged. Verdict unchanged; the guest record is owed a re-record.

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

`RFC5798-8.2.1-2`

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.2.1 says "If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address." TestVRRPIPv6RedirectFollowsVirtualMAC changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the ICMPv6 redirect source capture and its physical-MAC control are unchanged. Verdict unchanged; the guest record is owed a re-record.

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

`RFC5798-8.1.3-1`

If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the virtual router MAC address in the Proxy ARP message. (§8.1.3; lowercase "must" in the RFC)

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

No test carries RFC5798-8.1.3-1, so no unit is bound to it.

`RFC5798-8.2.2-1`

The Virtual Router Master MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router. (§8.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.2.2 says "The Virtual Router Master MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router." TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly and TestVRRPOwnerAnswersWithVirtualMACOnly changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the Neighbor Advertisement captures and their physical-MAC controls are unchanged. Verdict unchanged; the guest records are owed a re-record.

Polarity	Test	Kind and tier	Proof state
negative	`TestInstanceIPv6VIPLivesOnVirtualMACDevice`	unit/verify	revert, verified
negative	`TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly`	unit/verify	revert, verified
negative	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
negative	`TestOwnerFilterWiredOnPromotionForEveryFamily`	unit/verify	revert, verified
positive	`TestInstanceIPv6VIPLivesOnVirtualMACDevice`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestOwnerFilterWiredOnPromotionForEveryFamily`	unit/verify	revert, verified

`RFC5798-8.2.2-8`

When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Virtual Router Master MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router. (§8.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after a78870fd39). RFC 5798 Section 8.2.2 says "When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Virtual Router Master MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router." TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly and TestVRRPOwnerAnswersWithVirtualMACOnly changed only by the checksum-mode plumbing (a Checksum: packet.ChecksumRFC9568 field added to the GroupSpec, AdvertParams or packet.Local literal, or the mode argument added to packet.FillChecksum); every assertion and every isolating input is byte-for-byte the same; the Neighbor Advertisement captures and their physical-MAC controls are unchanged. Verdict unchanged; the guest records are owed a re-record.

Polarity	Test	Kind and tier	Proof state
negative	`TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly`	unit/verify	revert, verified
negative	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestVRRPNonOwnerMasterAnswersNDWithVirtualMACOnly`	unit/verify	revert, verified
positive	`TestVRRPOwnerAnswersWithVirtualMACOnly`	unit/verify	revert, verified

`RFC5798-8.2.2-2`

When a Virtual Router Master sends an ND Neighbor Solicitation message for a host's IPv6 address, the Virtual Router Master MUST include the virtual MAC address for the virtual router if it sends a source link-layer address option in the neighbor solicitation message. (§8.2.2)

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

No test carries RFC5798-8.2.2-2, so no unit is bound to it.

`RFC5798-8.2.2-3`

It MUST NOT use its physical MAC address in the source link-layer address option. (§8.2.2)

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

No test carries RFC5798-8.2.2-3, so no unit is bound to it.

`RFC5798-8.2.2-4`

o At system boot, when initializing interfaces for VRRP operation, all ND Router and Neighbor Advertisements and Solicitation messages must be delayed until both the IPv6 address and the virtual router MAC address are configured. (§8.2.2; lowercase "must" in the RFC)

Audit verdict: enforced (the tests do what the requirement demands), fresh. vrrp judge 2026-09-29 (independent, continuations 1-2): TestEngineWaitsForALateVirtualMACDevice (ipv6) runs the live macvlanCreator.create over a registry that creates the device 30ms late and a transport that refuses an absent device: order is device, install, Neighbor Advertisement; a device that never appears gives no instance, install or NA. Deleting the wait reddens the positive (records on register.go create, observed red). With TestEngineAnnouncesNothingBeforeTheVirtualMACDevice and TestInstanceDelaysAnnounceUntilParentUsable (address half). Kernel-originated RA/NS are outside ze's announce path and not observed.

Polarity	Test	Kind and tier	Proof state
negative	`TestEngineWaitsForALateVirtualMACDevice`	unit/verify	revert, verified
negative	`TestEngineAnnouncesNothingBeforeTheVirtualMACDevice`	unit/verify	revert, verified
negative	`TestInstanceDelaysAnnounceUntilParentUsable`	unit/verify	revert, verified
positive	`TestEngineWaitsForALateVirtualMACDevice`	unit/verify	revert, verified
positive	`TestEngineAnnouncesNothingBeforeTheVirtualMACDevice`	unit/verify	revert, verified
positive	`TestInstanceDelaysAnnounceUntilParentUsable`	unit/verify	revert, verified

`RFC5798-8.2.3-1`

The Backup routers must be configured to send the same Router Advertisement options as the address owner. (§8.2.3; lowercase "must" in the RFC)

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

No test carries RFC5798-8.2.3-1, so no unit is bound to it.

`RFC5798-8.4.2-1`

An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second. (§8.4.2)

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

No test carries RFC5798-8.4.2-1, so no unit is bound to it.

`RFC5798-A.2-1`

The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. (§A.2)

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

No test carries RFC5798-A.2-1, so no unit is bound to it.

Extraction sign-off

Field	Value
Reviewer	claude-opus-5 (rfcgate-6 phase, rfc5798 walk)
Signed off	2026-09-01
Register	prose
Source	rfc/full/rfc5798.txt
Source fingerprint	e28505fbe523b3a8
Record	rfc/extraction/rfc5798.json
Mapped sentences	51
Declined as scope	11
Relocated to a spec, which Ze OWES	0
Unclassified	0

Sections

Section	Name	Sites	Disposition	Reason
`front`	not stated	2	skipped (front-matter)	Title block, abstract, status of this memo, copyright notice and table of contents. No obligation is stated before Section 1.
`1`	not stated	0	walked	not stated
`1.1`	not stated	0	walked	not stated
`1.2`	not stated	0	walked	not stated
`1.3`	not stated	0	walked	not stated
`1.4`	not stated	0	walked	not stated
`1.5`	not stated	0	walked	not stated
`1.6`	not stated	0	walked	not stated
`2`	not stated	1	walked	not stated
`2.1`	not stated	0	walked	not stated
`2.2`	not stated	0	walked	not stated
`2.3`	not stated	0	walked	not stated
`2.4`	not stated	0	walked	not stated
`2.5`	not stated	0	walked	not stated
`3`	not stated	1	walked	not stated
`4`	not stated	0	walked	not stated
`4.1`	not stated	1	walked	not stated
`4.2`	not stated	0	walked	not stated
`5`	not stated	0	walked	not stated
`5.1`	not stated	0	walked	not stated
`5.1.1`	not stated	0	walked	not stated
`5.1.1.1`	not stated	0	walked	not stated
`5.1.1.2`	not stated	1	walked	not stated
`5.1.1.3`	not stated	2	walked	not stated
`5.1.1.4`	not stated	0	walked	not stated
`5.1.2`	not stated	0	walked	not stated
`5.1.2.1`	not stated	0	walked	not stated
`5.1.2.2`	not stated	1	walked	not stated
`5.1.2.3`	not stated	2	walked	not stated
`5.1.2.4`	not stated	0	walked	not stated
`5.2`	not stated	0	walked	not stated
`5.2.1`	not stated	0	walked	not stated
`5.2.2`	not stated	1	walked	not stated
`5.2.3`	not stated	0	walked	not stated
`5.2.4`	not stated	2	walked	not stated
`5.2.5`	not stated	0	walked	not stated
`5.2.6`	not stated	1	walked	not stated
`5.2.7`	not stated	0	walked	not stated
`5.2.8`	not stated	0	walked	not stated
`5.2.9`	not stated	2	walked	not stated
`6`	not stated	0	walked	not stated
`6.1`	not stated	2	walked	not stated
`6.2`	not stated	0	walked	not stated
`6.3`	not stated	0	walked	not stated
`6.4`	not stated	0	walked	not stated
`6.4.1`	not stated	0	walked	not stated
`6.4.2`	not stated	6	walked	not stated
`6.4.3`	not stated	9	walked	not stated
`7`	not stated	0	walked	not stated
`7.1`	not stated	7	walked	not stated
`7.2`	not stated	1	walked	not stated
`7.3`	not stated	0	walked	not stated
`7.4`	not stated	2	walked	not stated
`8`	not stated	0	walked	not stated
`8.1`	not stated	0	walked	not stated
`8.1.1`	not stated	1	walked	not stated
`8.1.2`	not stated	3	walked	not stated
`8.1.3`	not stated	1	walked	not stated
`8.2`	not stated	0	walked	not stated
`8.2.1`	not stated	1	walked	not stated
`8.2.2`	not stated	5	walked	not stated
`8.2.3`	not stated	1	walked	not stated
`8.3`	not stated	0	walked	not stated
`8.3.1`	not stated	0	walked	not stated
`8.3.2`	not stated	1	walked	not stated
`8.4`	not stated	0	walked	not stated
`8.4.1`	not stated	0	walked	not stated
`8.4.2`	not stated	2	walked	not stated
`8.4.3`	not stated	0	walked	not stated
`8.4.3.1`	not stated	0	walked	not stated
`8.4.3.2`	not stated	0	walked	not stated
`9`	not stated	1	walked	not stated
`10`	Section 10, Contributors and Acknowledgments	0	skipped (acknowledgements)	Section 10, Contributors and Acknowledgments. It names the people who wrote the merged source documents.
`11`	Section 11, IANA Considerations	0	skipped (iana)	Section 11, IANA Considerations. It records the IPv4 and IPv6 multicast assignments and the protocol number already made for VRRP, and binds IANA rather than a speaker.
`12`	Section 12, References, its heading only	0	skipped (references)	Section 12, References, its heading only.
`12.1`	Normative reference list	0	skipped (references)	Normative reference list.
`12.2`	Informative reference list	0	skipped (references)	Informative reference list.
`A`	not stated	0	walked	not stated
`A.1`	not stated	0	walked	not stated
`A.2`	not stated	2	walked	not stated
`A.3`	not stated	0	walked	not stated

Excluded sentences

Site	Excluded kind	Reason	Quote
`front:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	The sentence is the IETF Trust Legal Provisions boilerplate that opens every RFC. It binds a party redistributing the document text, states no protocol behaviour, and the extractor did not strip it.	Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
`front:2`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	The site is a Table of Contents line, "Required Features ... 8 2.1.", captured by the prose scan because the heading it names contains the word Required. A contents line states nothing.	Required Features ...............................................8 2.1.
`2:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	The site is the section heading "Required Features" itself, matched on the word Required. A heading states no obligation; every feature it introduces is stated in Sections 2.1 to 2.5 and, normatively, in Sections 5 to 8.	Required Features
`3:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Section 3 is the protocol overview and the sentence states a deployment precondition, that an operator gives every VRRP router on the LAN the same VRID-to-address mapping. It is not a behaviour a speaker performs on a packet: no VRRP message carries or negotiates the mapping, and ze reads its own VRID and virtual addresses from operator configuration (applyGroupLeaves, internal/plugins/vrrp/groups.go, reading the vrid and virtual-address leaves of ze-vrrp-conf.yang). No normative section of RFC 5798 restates it.	The mapping between the VRID and its IPvX address(es) must be coordinated among all VRRP routers on a LAN.
`4.1:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Section 4.1 is a worked sample configuration. The sentence describes what that example needs, "In order to back up IPvX B, a second virtual router must be configured", and states no obligation on an implementation.	In order to back up IPvX B, a second virtual router must be configured.
`6.1:1`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The IPv6_Addresses parameter description restates the address-ordering rule of Section 5.2.9, which site 5.2.9:1 maps.	The first address must be the Link-Local address associated with the virtual router.
`6.4.2:1`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The sentence is the head of the Backup state list, "(300) While in this state, a VRRP router MUST do the following:". It states no behaviour of its own: it sets the obligation level for the bullets under it, each of which repeats MUST or MUST NOT and is a site of its own at 6.4.2:2 to 6.4.2:6. The steps it also binds that carry no keyword, (345) to (475), are declared in this section unsourced-ids.	(300) While in this state, a VRRP router MUST do the following:
`6.4.3:1`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The sentence is the head of the Master state list, "(600) While in this state, a VRRP router MUST do the following:", and states no behaviour of its own, exactly as 6.4.2:1 does for Backup. Its keyworded bullets are sites 6.4.3:2 to 6.4.3:9, and the steps it binds that carry no keyword, (655) to (780), are declared in this section unsourced-ids.	(600) While in this state, a VRRP router MUST do the following:
`6.4.3:6`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Step (635) restates the Accept_Mode note of Section 6.1, which site 6.1:2 maps.	(635) ++ If Accept_Mode is False: MUST NOT drop IPv6 Neighbor Solicitations and Neighbor Advertisements.
`9:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Section 9 states that VRRP needs no confidentiality: "there is no information in the VRRP messages that must be kept secret from other nodes on the LAN". The word sits inside a negative existential describing the absence of a need, not an obligation on a speaker.	Confidentiality is not necessary for the correct operation of VRRP, and there is no information in the VRRP messages that must be kept secret from other nodes on the LAN.
`A.2:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	The bullet explains why VRRP over Token Ring is difficult, that source-route bridges need cached source-route information updated when the Master moves. It describes a property of that medium and states no obligation on a VRRP implementation; the one Token Ring obligation is site A.2:2.	o In order to switch to a new Master located on a different bridge Token-Ring segment from the previous Master when using source- route bridges, a mechanism is required to update cached source- route information.

Superseded

RFC 5798 is obsoleted by RFC 9568.

Requirement	Disposition	Now stated at	Reason
`RFC5798-5.1.1.2-1` The IPv4 multicast address as assigned by the IANA for VRRP is: 224.0.0.18 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its TTL. (§5.1.1.2)	restated	RFC9568-5.1.1.2-1	RFC 9568 Section 5.1.1.2 keeps the rule for IPv4 word for word
`RFC5798-5.1.1.3-1` The TTL MUST be set to 255. (§5.1.1.3)	restated	RFC9568-5.1.1.3-1	RFC 9568 Section 5.1.1.3 keeps the IPv4 TTL of 255 on transmit
`RFC5798-5.1.1.3-2` A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet. (§5.1.1.3, §7.1)	restated	RFC9568-5.1.1.3-2	RFC 9568 Section 5.1.1.3 keeps the discard rule and Section 7.1 keeps the matching receive check
`RFC5798-5.1.2.2-1` The IPv6 multicast address assigned by the IANA for VRRP is: FF02:0:0:0:0:0:0:12 This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its Hop Limit. (§5.1.2.2)	restated	RFC9568-5.1.2.2-1	RFC 9568 Section 5.1.2.2 keeps the rule for the IPv6 group
`RFC5798-5.1.2.3-1` The Hop Limit MUST be set to 255. (§5.1.2.3)	restated	RFC9568-5.1.2.3-1	RFC 9568 Section 5.1.2.3 keeps the Hop Limit of 255 on transmit
`RFC5798-5.1.2.3-2` A VRRP router receiving a packet with the Hop Limit not equal to 255 MUST discard the packet. (§5.1.2.3, §7.1)	restated	RFC9568-5.1.2.3-2	RFC 9568 Section 5.1.2.3 keeps the discard rule and Section 7.1 keeps the matching receive check
`RFC5798-5.2.2-1` The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded. (§5.2.2)	restated	RFC9568-5.2.2-1	RFC 9568 Section 5.2.2 keeps ADVERTISEMENT as the only defined type and keeps the discard rule, and Section 7.1 adds an explicit receive check for it
`RFC5798-5.2.4-1` The priority value for the VRRP router that owns the IPvX address associated with the virtual router MUST be 255 (decimal). (§5.2.4)	restated	RFC9568-5.2.4-1	RFC 9568 Section 5.2.4 keeps Priority 255 for the address owner
`RFC5798-5.2.4-2` VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). (§5.2.4)	restated	RFC9568-5.2.4-2	RFC 9568 Section 5.2.4 keeps the 1 to 254 range for backup routers
`RFC5798-5.2.6-1` This field MUST be set to zero on transmission and ignored on reception. (§5.2.6)	restated	RFC9568-5.2.6-1	RFC 9568 Section 5.2.6 renames the field to Reserve and keeps both halves of the rule
`RFC5798-5.2.8-1` The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field is set to zero. (§5.2.8, §7.1)	restated	RFC9568-5.2.8-1	RFC 9568 Section 5.2.8 keeps the ones-complement arithmetic and CHANGES the coverage, stating the IPv4 checksum over the VRRP message alone and keeping the RFC 8200 Section 8.1 pseudo-header for IPv6 only. RFC 9568 Section 1.2 lists that as change 4. The two documents therefore disagree about the IPv4 checksum, and the deployed base computes this one
`RFC5798-5.2.9-1` For IPv6, the first address must be the IPv6 link-local address associated with the virtual router. (§5.2.9, §6.1; lowercase "must" in the RFC)	restated	RFC9568-5.2.9-1	RFC 9568 Section 5.2.9 states the same rule with an uppercase MUST, and erratum 8300 adds the matching receive check
`RFC5798-5.2.9-2` This field contains either one or more IPv4 addresses, or one or more IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in one IPvX Address field. (§5.2.9)	restated	RFC9568-5.2.9-2	RFC 9568 Section 5.2.9 states the rule as an address family that MUST be the same as the packet's IPvX header address family
`RFC5798-6.1-1` Note: IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped when Accept_Mode is False. (§6.1, §6.4.3)	restated	RFC9568-6.1-1	RFC 9568 Section 6.1 keeps the Accept_Mode note verbatim
`RFC5798-6.4.2-1` (310) + MUST NOT respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.2)	restated	RFC9568-6.4.2-1	RFC 9568 Section 6.4.2 keeps the rule and renames the state to Backup Router
`RFC5798-6.4.2-2` (320) + MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 address(es) associated with the virtual router. (§6.4.2)	restated	RFC9568-6.4.2-2	RFC 9568 Section 6.4.2 keeps the rule unchanged
`RFC5798-6.4.2-3` (325) + MUST NOT send ND Router Advertisement messages for the virtual router. (§6.4.2)	restated	RFC9568-6.4.2-3	RFC 9568 Section 6.4.2 keeps the rule unchanged
`RFC5798-6.4.2-4` (335) - MUST discard packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.2)	restated	RFC9568-6.4.2-4	RFC 9568 Section 6.4.2 keeps the discard unchanged
`RFC5798-6.4.2-5` (340) - MUST NOT accept packets addressed to the IPvX address(es) associated with the virtual router. (§6.4.2)	restated	RFC9568-6.4.2-5	RFC 9568 Section 6.4.2 keeps the rule unchanged
`RFC5798-6.4.2-6` If a Shutdown event is received, then: (350) + Cancel the Master_Down_Timer (355) + Transition to the {Initialize} state (§6.4.2)	restated	RFC9568-6.4.2-6	RFC 9568 Section 6.4.2 keeps the Shutdown transition and renames the timer to Active_Down_Timer
`RFC5798-6.4.2-7` If the Master_Down_Timer fires, then: (370) + Send an ADVERTISEMENT (375) + If the protected IPvX address is an IPv4 address, then: (380) * Broadcast a gratuitous ARP request on that interface containing the virtual router MAC address for each IPv4 address associated with the virtual router. (385) + else // ipv6 (390) * Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) associated with the virtual router. (395) * For each IPv6 address associated with the virtual router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the target address set to the IPv6 address of the virtual router, and the target link-layer address set to the virtual router MAC address. (400) +endif // was protected addr ipv4? (405) + Set the Adver_Timer to Advertisement_Interval (410) + Transition to the {Master} state (§6.4.2)	restated	RFC9568-6.4.2-7	RFC 9568 Section 6.4.2 keeps the whole sequence, renames the timer and the state, and erratum 7949 corrects the gratuitous ARP to carry the virtual router IPv4 address with the virtual router MAC as the target link-layer address
`RFC5798-6.4.2-8` If the Priority in the ADVERTISEMENT is zero, then: (430) * Set the Master_Down_Timer to Skew_Time (§6.4.2)	restated	RFC9568-6.4.2-8	RFC 9568 Section 6.4.2 keeps the Skew_Time rule for a Priority 0 advertisement
`RFC5798-6.4.2-9` If Preempt_Mode is False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: (450) @ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (455) @ Recompute the Master_Down_Interval (460) @ Reset the Master_Down_Timer to Master_Down_Interval (§6.4.2)	restated	RFC9568-6.4.2-9	RFC 9568 Section 6.4.2 keeps the rule and ADDS one step, recomputing Skew_Time beside Active_Down_Interval, which this document omits
`RFC5798-6.4.2-10` else // preempt was true or priority was less (470) @ Discard the ADVERTISEMENT (§6.4.2)	restated	RFC9568-6.4.2-10	RFC 9568 Section 6.4.2 keeps the discard unchanged
`RFC5798-6.4.3-1` (610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router. (§6.4.3, §8.1.2)	restated	RFC9568-6.4.3-1	RFC 9568 Section 6.4.3 keeps the ARP obligation and renames the state to Active Router
`RFC5798-6.4.3-2` (620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router. (§6.4.3)	restated	RFC9568-6.4.3-2	RFC 9568 Section 6.4.3 keeps the membership obligation unchanged
`RFC5798-6.4.3-3` (625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router. (§6.4.3, §8.2.2)	restated	RFC9568-6.4.3-3	RFC 9568 Section 6.4.3 keeps the obligation and ADDS that the Neighbor Advertisement carries the Router Flag set
`RFC5798-6.4.3-4` (630) ++ MUST send ND Router Advertisements for the virtual router. (§6.4.3)	restated	RFC9568-6.4.3-4	RFC 9568 Section 6.4.3 keeps the obligation unchanged
`RFC5798-6.4.3-5` (645) - MUST forward packets with a destination link-layer MAC address equal to the virtual router MAC address. (§6.4.3)	restated	RFC9568-6.4.3-5	RFC 9568 Section 6.4.3 keeps the forwarding obligation unchanged
`RFC5798-6.4.3-6` (650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. (§6.4.3)	restated	RFC9568-6.4.3-6	RFC 9568 Section 6.4.3 keeps both admitting conditions unchanged
`RFC5798-6.4.3-7` MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets. (§6.4.3)	restated	RFC9568-6.4.3-7	RFC 9568 Section 6.4.3 keeps the refusal unchanged
`RFC5798-6.4.3-8` If a Shutdown event is received, then: (660) + Cancel the Adver_Timer (665) + Send an ADVERTISEMENT with Priority = 0 (670) + Transition to the {Initialize} state (§6.4.3)	restated	RFC9568-6.4.3-8	RFC 9568 Section 6.4.3 keeps the Shutdown sequence unchanged
`RFC5798-6.4.3-9` If the Adver_Timer fires, then: (685) + Send an ADVERTISEMENT (690) + Reset the Adver_Timer to Advertisement_Interval (§6.4.3)	restated	RFC9568-6.4.3-9	RFC 9568 Section 6.4.3 keeps the timer-expiry behaviour unchanged
`RFC5798-6.4.3-10` If the Priority in the ADVERTISEMENT is zero, then: (710) -* Send an ADVERTISEMENT (715) -* Reset the Adver_Timer to Advertisement_Interval (§6.4.3)	restated	RFC9568-6.4.3-10	RFC 9568 Section 6.4.3 keeps the response to a Priority 0 advertisement unchanged
`RFC5798-6.4.3-11` If the Priority in the ADVERTISEMENT is greater than the local Priority, (730) -* or (735) -* If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IPvX Address of the sender is greater than the local primary IPvX Address, then: (740) -@ Cancel Adver_Timer (745) -@ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT (750) -@ Recompute the Skew_Time (755) @ Recompute the Master_Down_Interval (760) @ Set Master_Down_Timer to Master_Down_Interval (765) @ Transition to the {Backup} state (§6.4.3)	restated	RFC9568-6.4.3-11	RFC 9568 Section 6.4.3 keeps the whole sequence and states that the sender address comparison is an unsigned integer comparison in network byte order
`RFC5798-6.4.3-12` else // new Master logic (775) @ Discard ADVERTISEMENT (§6.4.3)	restated	RFC9568-6.4.3-12	RFC 9568 Section 6.4.3 keeps the discard and ADDS a step this document does not have, sending an advertisement immediately so learning bridges relearn the segment. RFC 9568 Section 1.2 lists that as change 5
`RFC5798-7.1-1` - MUST verify that the VRRP version is 3. (§7.1)	restated	RFC9568-7.1-1	RFC 9568 Section 7.1 keeps the version check
`RFC5798-7.1-2` - MUST verify that the received packet contains the complete VRRP packet (including fixed fields, and IPvX address). (§7.1)	restated	RFC9568-7.1-3	RFC 9568 Section 7.1 keeps the completeness check
`RFC5798-7.1-3` - MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)). (§7.1)	restated	RFC9568-7.1-4	RFC 9568 Section 7.1 keeps both halves as published, and erratum 8298 splits them, lowering the address-owner half to a SHOULD that logs rather than discards
`RFC5798-7.1-4` If any one of the above checks fails, the receiver MUST discard the packet (§7.1)	restated	RFC9568-7.1-6	RFC 9568 Section 7.1 keeps the discard on a failed mandatory check, with the SHOULD log and the MAY network-management indication beside it
`RFC5798-7.2-1` The following operations MUST be performed when transmitting a VRRP packet: - Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum (§7.2)	restated	RFC9568-7.2-1	RFC 9568 Section 7.2 keeps the fill-and-checksum step unchanged
`RFC5798-7.2-2` If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual router MAC Address (§7.2)	restated	RFC9568-7.2-2	RFC 9568 Section 7.2 keeps the virtual router MAC as the source link-layer address
`RFC5798-7.2-3` If the protected address is an IPv4 address, then: + Set the source MAC address to virtual router MAC Address + Set the source IPv4 address to interface primary IPv4 address - else // ipv6 + Set the source MAC address to virtual router MAC Address + Set the source IPv6 address to interface link-local IPv6 address (§7.2)	restated	RFC9568-7.2-3	RFC 9568 Section 7.2 keeps both source-address rules unchanged
`RFC5798-7.2-4` Set the IPvX protocol to VRRP - Send the VRRP packet to the VRRP IPvX multicast group (§7.2)	restated	RFC9568-7.2-4	RFC 9568 Section 7.2 keeps protocol 112 and the IPvX multicast destination
`RFC5798-7.4-1` IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet Networks" [RFC2464]). (§7.4)	dropped	not stated	RFC 9568 Section 7.4 replaces the sentence rather than restating it. It cites RFC 8064 and RFC 7217 as the default scheme for a stable SLAAC address and states no "normal manner" obligation, so no equivalent requirement remains
`RFC5798-7.4-2` They MUST NOT use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers. (§7.4)	restated	RFC9568-7.4-1	RFC 9568 Section 7.4 keeps the prohibition and restates it over the Net_Iface parameter of the RFC 7217 and RFC 8981 derivation algorithms
`RFC5798-8.1.2-1` The Virtual Router Master MUST NOT respond with its physical MAC address in the ARP response. (§8.1.2)	restated	RFC9568-8.1.2-1	RFC 9568 Section 8.1.2 keeps the prohibition unchanged
`RFC5798-8.1.2-6` When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router. (§8.1.2)	restated	RFC9568-8.1.2-6	RFC 9568 Section 8.1.2 keeps the obligation and names the Virtual Router Master the Active Router
`RFC5798-8.1.1-2` If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. (§8.1.1; lowercase "must" in the RFC)	restated	RFC9568-8.1.1-2	RFC 9568 Section 8.1.1 restates it for the Active Router, "then it must determine to which Virtual Router the packet was sent when selecting the redirect source address"
`RFC5798-8.2.1-2` If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. (§8.2.1; lowercase "must" in the RFC)	restated	RFC9568-8.2.1-2	RFC 9568 Section 8.2.1 restates it for the Active Router, "then it has to determine to which Virtual Router the packet was sent when selecting the redirect source address"
`RFC5798-8.1.3-1` If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the virtual router MAC address in the Proxy ARP message. (§8.1.3; lowercase "must" in the RFC)	restated	RFC9568-8.1.3-1	RFC 9568 Section 8.1.3 states the same obligation with an uppercase MUST
`RFC5798-8.2.2-1` The Virtual Router Master MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router. (§8.2.2)	restated	RFC9568-8.2.2-1	RFC 9568 Section 8.2.2 keeps the prohibition unchanged
`RFC5798-8.2.2-8` When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Virtual Router Master MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router. (§8.2.2)	restated	RFC9568-8.2.2-8	RFC 9568 Section 8.2.2 keeps the obligation and names the Virtual Router Master the Active Router
`RFC5798-8.2.2-2` When a Virtual Router Master sends an ND Neighbor Solicitation message for a host's IPv6 address, the Virtual Router Master MUST include the virtual MAC address for the virtual router if it sends a source link-layer address option in the neighbor solicitation message. (§8.2.2)	restated	RFC9568-8.2.2-2	RFC 9568 Section 8.2.2 keeps the obligation unchanged
`RFC5798-8.2.2-3` It MUST NOT use its physical MAC address in the source link-layer address option. (§8.2.2)	restated	RFC9568-8.2.2-3	RFC 9568 Section 8.2.2 keeps the prohibition unchanged
`RFC5798-8.2.2-4` o At system boot, when initializing interfaces for VRRP operation, all ND Router and Neighbor Advertisements and Solicitation messages must be delayed until both the IPv6 address and the virtual router MAC address are configured. (§8.2.2; lowercase "must" in the RFC)	restated	RFC9568-8.2.2-4	RFC 9568 Section 8.2.2 states the same delay with an uppercase MUST
`RFC5798-8.2.3-1` The Backup routers must be configured to send the same Router Advertisement options as the address owner. (§8.2.3; lowercase "must" in the RFC)	restated	RFC9568-8.2.3-1	RFC 9568 Section 8.2.3 states the same obligation with an uppercase MUST
`RFC5798-8.4.2-1` An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second. (§8.4.2)	restated	RFC9568-8.4.2-1	RFC 9568 Section 8.4.2 keeps the obligation unchanged
`RFC5798-A.2-1` The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. (§A.2)	dropped	not stated	RFC 9568 removes the legacy-media appendices. Its Section 1.2 lists as change 6 that the appendices describing operation over FDDI, Token Ring and ATM LAN Emulation were removed, so RFC 9568 states no functional-address obligation
`RFC5798-7.1-5` If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event (§7.1)	restated	RFC9568-7.1-7	RFC 9568 Section 7.1 keeps the log and adds rate-limiting to it
`RFC5798-7.1-8` MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. If the above check fails, the receiver SHOULD log the event (§7.1)	restated	RFC9568-7.1-9	RFC 9568 Section 7.1 keeps the log, adds rate-limiting, and states it in one sentence covering the Max Advertise Interval mismatch as well
`RFC5798-8.1.1-1` The IPv4 source address of an ICMP redirect should be the address that the end-host used when making its next-hop routing decision. (§8.1.1; lowercase "should" in the RFC)	restated	RFC9568-8.1.1-1	RFC 9568 Section 8.1.1 keeps the sentence for IPv4
`RFC5798-8.1.2-2` When a VRRP router restarts or boots, it SHOULD NOT send any ARP messages using its physical MAC address for the IPv4 address it owns; it should only send ARP messages that include virtual MAC addresses. (§8.1.2)	restated	RFC9568-8.1.2-3	RFC 9568 Section 8.1.2 keeps the rule unchanged
`RFC5798-8.1.2-3` When configuring an interface, Virtual Router Master routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IPv4 address on that interface. (§8.1.2; lowercase "should" in the RFC)	restated	RFC9568-8.1.2-4	RFC 9568 Section 8.1.2 keeps this half at SHOULD
`RFC5798-8.1.2-4` At system boot, when initializing interfaces for VRRP operation, delay gratuitous ARP requests and ARP responses until both the IPv4 address and the virtual router MAC address are configured. (§8.1.2)	restated	RFC9568-8.1.2-2	RFC 9568 Section 8.1.2 splits the boot bullet out and RAISES it to a MUST
`RFC5798-8.1.2-5` When, for example, ssh access to a particular VRRP router is required, an IP address known to belong to that router must be used. (§8.1.2; lowercase "must" inside a SHOULD-level bullet list)	restated	RFC9568-8.1.2-5	RFC 9568 Section 8.1.2 keeps the recommendation
`RFC5798-8.2.1-1` The IPv6 source address of an ICMPv6 redirect should be the address that the end-host used when making its next-hop routing decision. (§8.2.1; lowercase "should" in the RFC)	restated	RFC9568-8.2.1-1	RFC 9568 Section 8.2.1 keeps the recommendation
`RFC5798-8.2.2-5` When a VRRP router restarts or boots, it SHOULD NOT send any ND messages with its physical MAC address for the IPv6 address it owns; it should only send ND messages that include virtual MAC addresses. (§8.2.2)	restated	RFC9568-8.2.2-5	RFC 9568 Section 8.2.2 keeps the rule unchanged
`RFC5798-8.2.2-6` When configuring an interface, Virtual Router Master routers should send an unsolicited ND Neighbor Advertisement message containing the virtual router MAC address for the IPv6 address on that interface. (§8.2.2; lowercase "should" in the RFC)	restated	RFC9568-8.2.2-6	RFC 9568 Section 8.2.2 keeps the recommendation
`RFC5798-8.2.3-2` Router Advertisement options that advertise special services (e.g., Home Agent Information Option) that are present in the address owner should not be sent by the address owner unless the Backup routers are prepared to assume these services in full and have a complete and synchronized database for this service. (§8.2.3; lowercase "should not" in the RFC)	restated	RFC9568-8.2.3-2	RFC 9568 Section 8.2.3 keeps the recommendation
`RFC5798-8.3.1-1` If it is not the address owner, a VRRP router SHOULD NOT forward packets addressed to the IPvX address for which it becomes Master. (§8.3.1)	restated	RFC9568-8.3.1-1	RFC 9568 Section 8.3.1 keeps the rule and states it over both address families
`RFC5798-8.3.2-1` A priority value of 255 designates a particular router as the "IPvX address owner". Care must be taken not to configure more than one router on the link in this way for a single VRID. (§8.3.2; lowercase in the RFC)	restated	RFC9568-8.3.2-1	RFC 9568 Section 8.3.2 keeps the recommendation and adds a rate-limited log when several priority-255 advertisers are seen
`RFC5798-8.3.2-2` When there are multiple Backup routers, their priority values should be uniformly distributed. For example, if one Backup router has the default priority of 100 and another Backup Router is added, a priority of 50 would be a better choice for it than 99 or 100, in order to facilitate faster convergence. (§8.3.2; lowercase in the RFC)	restated	RFC9568-8.3.2-3	RFC 9568 Section 8.3.2 keeps the recommendation and states it as sufficiently different priorities
`RFC5798-8.4.2-2` As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments. (§8.4.2)	restated	RFC9568-8.4.2-5	RFC 9568 Section 8.4.2 keeps the same statement
`RFC5798-8.4.2-3` When a virtual router is configured this way and is the Backup, it should time out based on the rate advertised by the Master; in the case of a VRRPv2 Master, this means it must translate the timeout value it receives (in seconds) into centiseconds. (§8.4.2)	restated	RFC9568-8.4.2-2	RFC 9568 Section 8.4.2 RAISES both halves to MUST and splits them, keeping the timeout at RFC9568-8.4.2-2 and the seconds-to-centiseconds translation at RFC9568-8.4.2-3
`RFC5798-8.4.2-4` Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it. (§8.4.2)	restated	RFC9568-8.4.2-4	RFC 9568 Section 8.4.2 keeps the recommendation
`RFC5798-8.4.3.1-1` A VRRPv2 implementation should not be given a higher priority than a VRRPv2/VRRPv3 implementation it is interacting with if the VRRPv2/ VRRPv3 rate is sub-second. (§8.4.3.1)	restated	RFC9568-8.4.2.1.1-1	RFC 9568 renumbers the subsection to 8.4.2.1.1 and keeps the recommendation
`RFC5798-A.1-1` To avoid this, an implementation SHOULD configure the virtual router MAC address by adding a unicast MAC filter in the FDDI device, rather than changing its hardware MAC address. (§A.1)	dropped	not stated	RFC 9568 removes the legacy-media appendices. Its Section 1.2 lists as change 6 that the appendices describing operation over FDDI, Token Ring and ATM LAN Emulation were removed, so RFC 9568 states no unicast-MAC-filter recommendation
`RFC5798-A.2-3` For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469]. (§A.2; lowercase "should" in the RFC)	dropped	not stated	RFC 9568 removes the legacy-media appendices. Its Section 1.2 lists as change 6 that the appendices describing operation over FDDI, Token Ring and ATM LAN Emulation were removed, so RFC 9568 states no Token-Ring encapsulation recommendation
`RFC5798-7.1-6` If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event, and MAY indicate via network management that an error occurred. - MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. (§7.1)	restated	RFC9568-7.1-10	RFC 9568 Section 7.1 keeps the network-management indication as a MAY
`RFC5798-7.1-7` MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. (§7.1)	restated	RFC9568-7.1-11	RFC 9568 Section 7.1 keeps the address-list check as a MAY and renames the field to IPvX Addr Count
`RFC5798-8.2.2-7` Note that on a restarting Master router where the VRRP protected address is the interface address, (that is, priority 255) duplicate address detection (DAD) may fail, as the Backup router may answer that it owns the address. One solution is to not run DAD in this case. (§8.2.2)	restated	RFC9568-8.2.2-7	RFC 9568 Section 8.2.2 keeps the note
`RFC5798-8.4.2-5` An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. (§8.4.2)	restated	RFC9568-8.4.2-6	RFC 9568 Section 8.4.2 keeps the flag as a MAY
`RFC5798-8.4.2-6` It MAY report when a VRRPv3 Master is not sending VRRPv2 packets: that suggests they don't agree on whether they're supporting VRRPv2 routers. (§8.4.2)	restated	RFC9568-8.4.2-7	RFC 9568 Section 8.4.2 keeps the report as a MAY
`RFC5798-A.2-2` The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring. Additionally, routers MAY support the unicast mode of operation to take advantage of newer Token-Ring adapter implementations that support non-promiscuous reception for multiple unicast MAC addresses and to avoid both the multicast traffic and usage conflicts associated with the use of Token-Ring functional addresses. (§A.2)	dropped	not stated	RFC 9568 removes the legacy-media appendices. Its Section 1.2 lists as change 6 that the appendices describing operation over FDDI, Token Ring and ATM LAN Emulation were removed, so RFC 9568 states no unicast-mode permission